不枉初心,砥砺前行

皮皮祥的博客

欢迎留言,评论

导航

FPGA之如何进行时序分析和约束

请问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学习各种时序问题的原因和对应解决方案。

posted on 2022-05-09 16:03  皮皮祥  阅读(1209)  评论(0编辑  收藏  举报