与PCI Express端点相关的定时故障，K7 325T与160T相关

我正在使用Vivado 2018.1，System Verilog，带有325T FPGA的KC705开发板，以及带有160T FPGA，Xillybus和PCI Express端点v3.3的自定义目标板。
我有一个很好的项目，只要我为KC705上的325T构建它就能满足时序要求。
但是，当我更改为我们的自定义目标板上的160T时，项目不再符合时间要求。
我认为问题是由于某些东西的放置或缺乏时钟约束。
请注意，KC705解决方案使用8个PCIe通道。
定制板仅使用4个PCIe通道，不幸的是它使用非推荐的通道8个中的0-3而不是8个中的4-7个。我仍在使用干净的xdc方式来解决这个问题。
目前，在重新定制Xilinx PCIe v3.3 IP后，我手动将gtxe2_channel_i的位置从GTXE2_CHANNEL_X0Y7 ... X0Y4更改为GTXE2_CHANNEL_X0Y3 ... X0Y0。
当我使用Xilinx PCIe v3.3示例项目时，此编辑完成了这项工作。
构建的示例项目和我的linux主机通过lspci识别目标板。
但是，现在我在项目中有了额外的RTL，它不再符合时间要求。
我想知道，如果移动了GTX的位置，我还需要移动其他东西，这样就可以满足时机要求。
或者，我看到我的单个失败路由涉及pipe_clock模块中的MMCM。
我想知道我的问题是否未能设置时钟约束，或者我的移动事物是否已经在现有时钟约束的支持下移出了单元格。
最后，如果必须的话，我可以看一下在配置PCIe v3.3 IP时减慢一些时钟，但我宁愿不这样做。
虽然它只是单个信号失败时序，但它似乎涉及125MHz时钟和250MHz时钟，因此它在时序报告中出现两次，因为两个不同的路径具有不同的保持时间故障。
我会附上两个时间摘要。
请注意，路径＃181仅需0.513ns，但松弛率为-0.258。
为了得到非负的松弛，这条路径必须花费不可能的0.255ns。
在看到路线有多么短暂和简单之后，我称这是不可能的。
这是一个短距离低扇出的FDRE。
解决方案必须位于路径本身之外。
[编辑：请注意，此信号出现在源文件pcie_k7_vivado_pipe_clock.v中并且已指定“（* ASYNC_REG =”TRUE“，SHIFT_EXTRACT =”NO“*）”。
来源附件。
这或许意味着这个信号不应该满足时间吗？
我认为源也会导致失去定时失败。
否则，每当我跨越时钟边界时，我一直在使用set_false_path约束...]
pcie_k7_vivado_pipe_clock.v 22 KB



以下为原文

I'm using Vivado 2018.1, System Verilog, KC705 dev board with 325T FPGA, and custom target board with 160T FPGA, Xillybus, and PCI Express endpoint v3.3.

I have a project that builds fine and meets timing whenever I build it for the 325T that's on the KC705.  However, when I change to the 160T that's on our custom target board, the project no longer meets timing.  I believe the problem is due to EITHER the placement of something or the lack of a clock constraint.

Note that the KC705 solution uses 8 PCIe lanes.  The custom board uses only 4 PCIe lanes, and it unfortunately uses the non-recommended lanes 0-3 out of 8 rather than 4-7 out of 8.  I'm still working on a clean xdc way to address this.  For now, after recustomizing the Xilinx PCIe v3.3 IP, I go manually change the placement of gtxe2_channel_i's from GTXE2_CHANNEL_X0Y7...X0Y4 to GTXE2_CHANNEL_X0Y3...X0Y0.  When I was working with the Xilinx PCIe v3.3 example project, this edit did the job sufficiently.  That example project built and my linux host recognized the target board via lspci.

However, now that I have additional RTL in the project, it no longer meets timing.  I'm wondering if, having moved the location of the GTX's being used, I need to also move something else, and this will allow timing to be met.  Alternatively, I see that my single failing route is involving an MMCM in a pipe_clock module.  I wonder if my problem is failing to set a clock constraint, or if my moving things around has moved a the cells out from under the auspice of an existing clock constraint.  Finally, if I must, I can look at slowing down some clocks in the configure of the PCIe v3.3 IP, but I'd rather not do that.

While it's just a single signal that fails timing, it seems to be involved with both a 125MHz clock and a 250MHz clock such that it appears twice in the timing report, as two different paths with different hold time failures.  I'll attach BOTH timing summaries.

Note that the path #181 in question only takes 0.513ns, but the slack is -0.258.  In order to get non-negative slack, this path would have to take an impossible 0.255ns.  I call that impossible after seeing how short and simple the route is. It's a single FDRE with low fanout over short distance.  The solution must lie outside of the path itself.

[EDIT: Note that this signal appears in the source file pcie_k7_vivado_pipe_clock.v and has "(* ASYNC_REG = "TRUE", SHIFT_EXTRACT = "NO" *)" specified.  Source attached. Does this perhaps mean that this signal is not supposed to meet timing?  I would think the source would also lead to removing the timing failure.  Otherwise I've been using set_false_path constraint whenever I cross clock boundaries...]


            pcie_k7_vivado_pipe_clock.v ‏22 KB