本文主要是介绍Vivado工程时序违背，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
此篇博客在于记录vivado中报时序出错，尝试找方法改善、消除此问题。下面就工程中遇到的情况进行总结（持续更新）：昨晚网上找到"vivado时序问题分析"（链接：https://wenku.baidu.com/view/e31e471a783e0912a2162ab3.html）文档，提及造成时序问题的成因有：1）约束不完整-70%；2）路径过长-20%；3）逻辑过深-5%；4）不正确的过约束-5%。解决方法对应分别是：1）约束主时钟；跨时钟域的约束；2）Pipeline设计；3）修改逻辑；使用Pipeline；4）删除过约束部分。看完后只留下一个概念：绝大多数时序约束问题都是由于约束不完整。
1.xdc约束问题
注：手头有两个工程，一份是当时开发PCIe工程（时序正常），另一份是加上工程其他功能模块的工程（时序违背）。
图1：PCIe工程时序报告（setup_time）
图2：完整工程时序报告（setup_time）
想彻底消除那个失败的节点，对比两个工程PCIe部分的工程代码，发现两者的pipe_clock模块不一样，后者的pipe_clock模块被我整理过了，为了对比是否是我整理出的问题，我把前者的pipe_clock模块加载到后者的工程，发现这份完整工程中还是会报两个时序违背的路径（一条内联时钟路径+一条互联时钟路径，见下图3,4），因为pclk_sel是通过异步复位分别产生125M和250M的时钟，所以网表元素为异步复位D触发器。
图3：内联时钟路径（250M-250M）报错
图4：互联时钟路径（125M-250M）报错
找到了是哪一个路径出问题，我找到相应模块下的信号，既然模块没改错那就去改xdc，对比发现两版工程的xdc关于内联/互联时钟的xdc约束，当时PCIe逻辑处理时钟已经降到62.5M了，以为250M时钟没用的所以并未在意。图5是PCIe工程，时序正常，xdc对pipe_clock模块进行绝对路径下的时钟约束；图6是完整工程，时序违背，xdc是当时直接拷贝PCIe工程，但是因为当时已经把加了顶层模块而且例化名进行了规范化所以这部分xdc实际是识别不出的；图7是完整工程，时序正常，xdc按照现在工程中pipe_clock模块的绝对路径约束125M、250M和跨时钟处理。
图5：PCIe工程xdc约束（时序正常）
图6：完整工程xdc约束（时序违背）
图7：完整工程xdc约束（时序正常）
问题说到底还是文中最开始提及的，约束不正确导致了时序违背。
---------------------------------------------------分----割----线------------------------------------------------------------
/*Ver. 2.0 补充了关于refclk_ibuf的问题*/
补充关于参考时钟缓冲器refclk_ibuf的通道约束问题。在解决完setup/hold time时序违背后，工程在实现后会报严重警告“[Common 17-55] 'set_property' expects at least one object.[.xdc:line 109]”而第109行是对下边代码的约束，具体约束如下：“set_property LOC IBUFDS_GTE2_X0Y3 [get_cells refclk_ibuf]”。
IBUFDS_GTE2 refclk_ibuf (.O(sys_clk), .ODIV2(), .I(sys_clk_PCIe_p), .CEB(1'b0), .IB(sys_clk_PCIe_n));我一开始猜测是通道约错了，为此对比了KC705（见Reference2），ZC706以及现在工程开发所使用的AC7103，这三个平台下PCIe例程的xdc，下面对比一下三块开发板对refclk_ibuf的通道约束：
1.KC705—INST "refclk_ibuf" LOC = IBUFDS_GTE2_X0Y3；
2.ZC706—set_property LOC IBUFDS_GTE2_X0Y6 [get_cells refclk_ibuf]；
3.AC7103—set_property LOC IBUFDS_GTE2_X0Y2 [get_cells refclk_ibuf]（开发板自带的PCIe例程xdc）.
现在的完整版工程关于参考时钟的约束是"X0Y3"，我以为是约束问题，那就模仿开发板自带的例程，将通道约束改为" X0Y2"，满心期待的跑一遍工程，结果发现还是报一样的严重警告，今天早上问了黑金技术人员，一直含含糊糊没能給出一个合理的解释，果然如导师所言，靠他人不如自己来得靠谱。
跑完综合后我们打开Flooplaning，先找到PCIe金手指部分的约束，因为我们只用了lane_x1模式，所以金手指中只有lane0以及差分时钟（参考时钟）那块进行通道约束了，整体截图见下图8。
图8 PCIe金手指约束(只用了一条lane)
放大refclk_ibuf、sys_clk_p/n通道约束那块，发现，即便工程xdc中对refclk_ibuf的约束是"X0Y2"，但是图示中显示refclk_ibuf cell的Site是" X0Y3"，那说明应该保持原来的" X0Y3"约束，具体约束Floorplaning见下图9：
图9 refclk_ibuf、sys_clk_p/n通道约束
改回" X0Y3"可还是会报错，这时我打开PCIe IP核的约束文件，发现对cell约束时有个例化绝对路径，如PCIe IP核的xdc对pcie_block进行约束时，其约束代码如下：
set_property LOC PCIE_X0Y0 [get_cells inst/pcie_top_i/pcie_7x_i/pcie_block_i]仔细看图9中最上边红色框框中对refclk_ibuf cell的描述是"U_xilinx_pcie_2_1_ep_7x/refclk_ibuf"，那么基本断定是我约束时没有加上绝对路径的缘故，，因为原先PCIe工程是refclk_ibuf就在工程的顶层，不存在找不到这个cell，而后面与其他模块合并后的完整版工程，需要加上对pcie这块的顶层例化路径（即U_xilinx_pcie_2_1_ep_7x）才能找到該cell。下边重新对refclk_ibuf进行通道约束，将原来的"set_property LOC IBUFDS_GTE2_X0Y3 [get_cells refclk_ibuf]"改为"set_property LOC IBUFDS_GTE2_X0Y3 [get_cells U_xilinx_pcie_2_1_ep_7x/refclk_ibuf]"，警告消失。
还有一个问题就是为什么AC7103自带的开发板会把该信号约成"X0Y2"，那是因为黑金技术人员引用了Xilinx官方对A701开发板的约束，而黑金只是用了a7芯片开发出来的AC7103板子，其参考时钟通道约束是"X0Y3"而不应该照搬AC701的约束"X0Y2"（见Reference3）。
总结："set_property LOC IBUFDS_GTE2_X0Y2 [get_cells refclk_ibuf]"这块约束有问题，Xilinx 官方的AC701对refclk_buf确实是X0Y2，但是AC7103只使用了a7的芯片，其通道约束是X0Y3。黑金在开发AC7103 PCIe例程时xdc照搬了Xilinx关于AC701平台PCIe开发的部分xdc。其中部分引脚是有问题的，这个问题和lane通道约束也一样，不能完全参考AC701，Xilinx官方A7（含Xilinx a7芯片和A701开发板）生成的IP核xdc关于高速通道lane0-lane3的约束是按顺序来的X0Y4/X0Y5/X0Y6/X0Y7；而黑金AC7103通道约束lane0-lane3是X0Y5/X0Y4/X0Y6/X0Y7，其中两个通道顺序出问题导致主机检测不到板卡。
/*End for Ver. 2.0 2018-7-16 17:03:51*/
Reference：
1.https://wenku.baidu.com/view/e31e471a783e0912a2162ab3.html；
2.https://blog.csdn.net/ssbls/article/details/55272114；
3.https://www.xilinx.com/support/answers/52487.html；
这篇关于Vivado工程时序违背的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
