本文整理自Xilinx公开课:Vivado时序收敛技术。
有些知识在公开课中讲的并不是很细,因此我又对齐进行了整理,分为了几篇文章。
有很多内容也在我的时序约束课程中讲到过,都是免费课程,大家可以在公众号上找到。(下面的链接中也有)
- 如何知道该约束哪些时钟?
使用report_clock_networks
指令或使用约束向导来查看有哪些主时钟需要约束和输入的主时钟是否被约束。
report_clock_networks -name primaryClock
- 如何检查时钟的约束?
使用report_clocks
指令,可以显示出所有约束时钟的周期、占空比等信息。
- 如何检查有关联的时钟?
使用report_clock_interaction
指令,需要特别注意那些unsafe
的时钟,也可以使用Implentation
下面的Report Clock Interaction
功能:
结果如下:
- 如何检查路径的requirement是否合理?
同样可以使用report_clock_interaction
指令,或者report_timing
指令,或者report_timing_summary
,可以看到WNS、TNS、WHS、THS、WPWS、TPWS这6个参数。
- WNS 表示最差建立时间负时序裕量 (Worst Negative Slack);对于跨时钟域而且WNS过小(比如小于100ps),一般都是因为没有对这两个时钟进行时序例外的约束,这时我们就要根据具体情况增加相应的约束。
- TNS 表示总的建立时间负时序裕量 (Total Negative Slack),也就是负时序裕量路径之和;
- WHS 表示最差保持时序裕量 (Worst Hold Slack);
- THS 表示总的保持时序裕量 (Total Hold Slack),也就是负保持时序裕量路径之和;
- WPWS表示最差脉冲宽度裕量;
- TPWS表示总的脉冲宽度裕量,也就是负脉冲宽度裕量路径之和
这里补充一点,即便有时序违规,程序运行时也不一定会出错,只是程序存在不稳定的可能性。
- 尽早定位问题
根据Baseline的基本理论,在进行综合和实现时,应该在每一步都检查WNS是否满足约束或者大于-300ps(这个数字是Baseline理论中提到的,具体原因查到之后再补充),只有满足这个条件后再进行下一阶段的设计实现过程,否则,应该继续在当前阶段或是退回到上一阶段调整后重跑设计,直到满足要求再继续。 一个很重要的原则是:越早发现和定位问题,越是可以通过少量的努力来达到更大范围的改进。
从综合到实现需要的过程如下:
synth_design -> opt_design -> place-design -> phys_opt_design -> route_design
那怎么让每一步的结果中都有时序报告呢?可以把Report Options的策略选择为Timing Closure Reports