Vivado工程时序违背

此篇博客在于记录中报时序出错 , 尝试找方法改善、消除此问题 。下面就工程中遇到的情况进行总结(持续更新):昨晚网上找到"时序问题分析"(链接:)文档,提及造成时序问题的成因有:1)约束不完整-70%;2)路径过长-20%;3)逻辑过深-5%;4)不正确的过约束-5% 。解决方法对应分别是:1)约束主时钟;跨时钟域的约束;2)设计;3)修改逻辑;使用;4)删除过约束部分 。看完后只留下一个概念:绝大多数时序约束问题都是由于约束不完整 。
1.xdc约束问题
注:手头有两个工程,一份是当时开发PCIe工程(时序正常),另一份是加上工程其他功能模块的工程(时序违背) 。

Vivado工程时序违背

文章插图
图1:PCIe工程时序报告()
Vivado工程时序违背

文章插图
图2:完整工程时序报告()
想彻底消除那个失败的节点,对比两个工程PCIe部分的工程代码,发现两者的模块不一样,后者的模块被我整理过了,为了对比是否是我整理出的问题,我把前者的模块加载到后者的工程 , 发现这份完整工程中还是会报两个时序违背的路径(一条内联时钟路径+一条互联时钟路径,见下图3,4),因为是通过异步复位分别产生125M和250M的时钟 , 所以网表元素为异步复位D触发器 。
Vivado工程时序违背

文章插图
图3:内联时钟路径(250M-250M)报错
Vivado工程时序违背

文章插图
图4:互联时钟路径(125M-250M)报错
找到了是哪一个路径出问题 , 我找到相应模块下的信号 , 既然模块没改错那就去改xdc,对比发现两版工程的xdc关于内联/互联时钟的xdc约束,当时PCIe逻辑处理时钟已经降到62.5M了 , 以为250M时钟没用的所以并未在意 。图5是PCIe工程,时序正常,xdc对模块进行绝对路径下的时钟约束;图6是完整工程,时序违背,xdc是当时直接拷贝PCIe工程,但是因为当时已经把加了顶层模块而且例化名进行了规范化所以这部分xdc实际是识别不出的;图7是完整工程,时序正常 , xdc按照现在工程中模块的绝对路径约束125M、250M和跨时钟处理 。
Vivado工程时序违背

文章插图
图5:PCIe工程xdc约束(时序正常)
Vivado工程时序违背

文章插图
图6:完整工程xdc约束(时序违背)
Vivado工程时序违背

文章插图
图7:完整工程xdc约束(时序正常)
问题说到底还是文中最开始提及的,约束不正确导致了时序违背 。
---------------------------------------------------分----割----线------------------------------------------------------------
/*Ver. 2.0 补充了关于的问题*/
补充关于参考时钟缓冲器的通道约束问题 。在解决完setup/hold time时序违背后,工程在实现后会报严重警告“[ 17-55] ''at least one .[.xdc:line 109]”而第109行是对下边代码的约束,具体约束如下:“ LOC[ ]” 。
IBUFDS_GTE2 refclk_ibuf (.O(sys_clk), .ODIV2(), .I(sys_clk_PCIe_p), .CEB(1'b0), .IB(sys_clk_PCIe_n));
我一开始猜测是通道约错了 , 为此对比了KC705(见),ZC706以及现在工程开发所使用的,这三个平台下PCIe例程的xdc,下面对比一下三块开发板对的通道约束:
1.KC705—INST "" LOC = ;
Vivado工程时序违背

文章插图
2.ZC706— LOC[ ];
3.— LOC[ ](开发板自带的PCIe例程xdc).
现在的完整版工程关于参考时钟的约束是"X0Y3" , 我以为是约束问题,那就模仿开发板自带的例程,将通道约束改为" X0Y2" , 满心期待的跑一遍工程,结果发现还是报一样的严重警告,今天早上问了黑金技术人员,一直含含糊糊没能給出一个合理的解释 , 果然如导师所言,靠他人不如自己来得靠谱 。
跑完综合后我们打开,先找到PCIe金手指部分的约束,因为我们只用了模式,所以金手指中只有lane0以及差分时钟(参考时钟)那块进行通道约束了,整体截图见下图8 。
Vivado工程时序违背

文章插图
图8 PCIe金手指约束(只用了一条lane)
放大、/n通道约束那块 , 发现,即便工程xdc中对的约束是"X0Y2",但是图示中显示 cell的Site是" X0Y3",那说明应该保持原来的" X0Y3"约束,具体约束见下图9:
Vivado工程时序违背

文章插图
图、/n通道约束
改回" X0Y3"可还是会报错,这时我打开PCIe IP核的约束文件,发现对cell约束时有个例化绝对路径,如PCIe IP核的xdc对进行约束时 , 其约束代码如下:
set_property LOC PCIE_X0Y0 [get_cells inst/pcie_top_i/pcie_7x_i/pcie_block_i]
仔细看图9中最上边红色框框中对 cell的描述是"_7x/",那么基本断定是我约束时没有加上绝对路径的缘故,,因为原先PCIe工程是就在工程的顶层 , 不存在找不到这个cell,而后面与其他模块合并后的完整版工程,需要加上对pcie这块的顶层例化路径(即_7x)才能找到該cell 。下边重新对进行通道约束,将原来的" LOC[ ]"改为" LOC[ _7x/]",警告消失 。
还有一个问题就是为什么自带的开发板会把该信号约成"X0Y2",那是因为黑金技术人员引用了官方对A701开发板的约束,而黑金只是用了a7芯片开发出来的板子,其参考时钟通道约束是"X0Y3"而不应该照搬AC701的约束"X0Y2"(见) 。
【Vivado工程时序违背】总结:" LOC[ ]"这块约束有问题,官方的AC701对确实是X0Y2 , 但是只使用了a7的芯片,其通道约束是X0Y3 。黑金在开发 PCIe例程时xdc照搬了关于AC701平台PCIe开发的部分xdc 。其中部分引脚是有问题的,这个问题和lane通道约束也一样 , 不能完全参考AC701,官方A7(含 a7芯片和A701开发板)生成的IP核xdc关于高速通道lane0-lane3的约束是按顺序来的X0Y4/X0Y5/X0Y6/X0Y7;而黑金通道约束lane0-lane3是X0Y5/X0Y4/X0Y6/X0Y7,其中两个通道顺序出问题导致主机检测不到板卡 。