Vivado时序问题分析

某年某月某日...

有些时候在写完代码之后呢，Vivado时序报红，Timing一栏有很多时序问题。

这种时候我们往往会想，明明用的时钟频率不算高，整个片子的资源用的也不算特别多，为什么会有这么多时序问题呢？

先说结论:

代码习惯不好，代码风格太差。

时序问题，很明显，是跟时钟息息相关的，对于某一个操作时钟，一旦其频率确定，其对于路径之间的最小时间要求也随之确定。

在写完代码后，随着资源使用的确定，布局布线的深入，则某些信号之间的路径延迟也随之确定，由于FPGA芯片中各个资源的原始布局都是确定的，那么对于资源的选取则至关重要，合理的资源选取将决定时序的优劣。

资源选取来源于哪里呢，最直观的就是代码。

下面分情况说明:

1，report methodology

在综合后，就可以report methodology，查看时钟存在的隐患，争取在设计前期就解决问题。

2，时钟约束

约束好主时钟对应的周期，管脚，除了特殊情况需要进行过约束外，一般管脚的时钟频率是多少就约多少。

3，跨时钟处理

对于跨时钟域的复位信号、单bit信号、多bit信号、数组等，使用xpm原语进行处理，或者用目标时钟信号打几拍

4，抓信号别跨时钟

抓取信号时，除了set up debug外，使用ila时，别跨时钟抓信号

5，Ram设置

Ram的设置中，最好勾选含有register的选项，有助于时序优化，ram避免直接级联，同时例化多个相同ram时对于ram输入作防优化处理

6，流水寄存器

一个信号用于多个状态的控制，或者状态机中，控制较为复杂，一个信号位宽较大，反复使用，也最好多使用几级寄存器进行流水，也就是常说的，没事多打两拍

7，Set false path

在使用Set false path时，不到万不得已，不对两个时钟域的信号进行整个Set false，而是只对单个信号进行set false，哪里冒出来了，就对哪里进行set false。

这样就可以防止某些确实存在的时序问题、需要改代码来解决的时序问题被隐藏，以免在调试的

后期，引起各种莫名其妙的问题，且不知道怎么去查。

8，set_max_delay

善于使用set_max_delay、set_min_delay、set_multicycle_p。

9，重定时(retiming)

感兴趣可去了解。

因此，在时序报红，也就是有时序问题时，需要从时序问题的本质出发，即是什么导致了时序问题。比如，RAM直接级联，判断条件过于复杂，跨时钟处理不合理，状态机过于复杂，信号位宽太大，相同信号驱动模块过多等。

另外，应尽可能少用时序例外约束，同时在使用时序例外约束时要使约束对象足够准确，这样一方面可以避免因为对象不匹配导致过多约束或遗漏约束的情形，另一方面也能有效缩短编译时间。

总之，代码风格在很大程度上决定了时序性能的好坏，决定了所写模块能达到的时钟频率上限。实现同样的功能，有些人写的代码处理时钟可以到100多MHz，而有些人可以到400多MHz。

审核编辑：汤梓红