vivado时序约束问题中的一些概念和总结方法（不断更新和补充）

参考链接1：https://forums.xilinx.com/t5/Vivado/vivado-%E4%B8%AD%E6%97%B6%E5%BA%8F%E9%97%AE%E9%A2%98/m-p/977551

请问intra-clock path 和inter-clock paths两个的区别是什么？分别针对的是什么类型的时序不满足？

下图是其中一条不满足的时序，请问如何定位解决？步骤是怎样的？

答：

intra-clock path: 同一个时钟域下的路径分析

inter-clock paths: 跨时钟域下的路径分析

你现在的路径是跨时钟域路径： requirement=0.5 ns, 明显过小，不合适; Clock Skew -3.448ns 明显过大，这两个时钟的路径差异极大.

你要考虑这两个时钟之间的路径是否能直接分析,  不行的话要用逻辑保证跨时钟域数据传输的正确性. (比如握手逻辑， 比如FIFO)

建议先看一下UG906的chapter 5 performing timing analysis

然后UG949的chapter 5 design closure

这条路径的问题：

1. Requirement 过小，你需要确认两个clock之间的关系， 看是否需要加set_false_path/set_max_delay/set_multicycle_path 之类的约束.

2. 时钟偏差太大是因为两个clock 的结构太不一样, 无法平衡.

你好，我想跟您问下，您所说的：“requirement=0.5 ns, 明显过小，不合适; Clock Skew -3.448ns 明显过大，”这个判断依据是什么呢？是经验值还是在相关文档上有说明？谢谢。

答：这个判断来自于经验，多调几次时序你就会有感觉了. 

Requirement 0.5ns 意味着什么？1ns 是1000Mhz； 0.5ns是2000Mhz; 这是什么概念，换算一下你也应该觉得这个要求很离谱了吧.

你可以观察一下你设计中的大多数路径，clock skew 是多少？500~600ps 已经算很大了. 以后你看到+/-3多ns, 你也会很警惕了. 

3.

答：请把下半段具体的路径也贴出来.

4 级逻辑的布线占了5.8+ns, 明显不正常，你选中这条路径在Device View 看一下，是不是绕线很严重，可能是拥塞导致的

继续问：

device view 中的绕线和拥塞怎么看？怎么分析的？

答：BRAM 的数据输出应该直接驱动寄存器再做其他处理, 而不是直接连接组合逻辑.
你在device View 中看到的是飞线，不是实际的走线. 要点一下上方的 routing resource 按钮. 
高亮的是逻辑资源的实际位置.

你设计中的跨时钟域路径都已经处理干净了吗？

反答：你指的跨时钟域路径处理干净是指把跨时钟的时序问题先解决掉？目前跨时钟域的时序问题没有解决

答：是的，跨时钟域路径不解决，设计中会有大量的WNS为较大负值的路径，工具可能就早早放弃对其他路径的优化了. 一些普通的路径也会有异常的表现.

5."我的数据都是reg到reg的流水线结构，为什么会出现WNS为负的情况？但是又可以生成bit文件，是否是因为slack不是很严重？该如何让WNS变为正的？时序路径原理图我看不太懂，这些名字好多都不知道是代表什么意思，该如何分析呢？"

reg到reg的结构不代表就一定能满足你的时钟周期要求，对于单个时钟域来说，简单讲当路径延时大于一个时钟周期的时候，WNS(建立时间检查)就为负，表示这条路径不满足时序要求。

时序不满足的条件下，bit文件仍然可以生成，但不代表这个bit文件是安全可用的。无论slack严不严重，严谨地说时序问题都是要解决的。

网表里的名字，跟RTL代码有一定的对应关系，但组合逻辑的名字，工具添加的成分较多不太容易识别，可以通过寄存器的名字辅助识别对应于RTL代码的哪个部分。这个需要经验积累摸索。

对于时序问题如何解决，建议先参考UG906学习如何解读timing report。然后可以参考UG949学习各种时序问题的原因和对应解决方案。