读懂用好Timing Report

静态时序分析

静态时序分析（Static Timing Analysis）简称STA，采用穷尽的分析方法来提取出整个电路存在的所有时序路径，计算信号在这些路径上的传播延时，检查信号的建立和保持时间是否满足时序要求，通过对最大路径延时和最小路径延时的分析，找出违背时序约束的错误并报告。

STA 不需要输入向量就能穷尽所有的路径，且运行速度很快、占用内存较少、覆盖率极高，不仅可以对芯片设计进行全面的时序功能检查，而且该可以利用时序分析的结果来优化设计。所以STA不仅是数字集成电路设计Timing Sign-off的必备手段，也越来越多地被用到设计的验证调试工作中。

STA在FPGA设计中也一样重要，但不同于一般数字集成电路的设计，FPGA设计中的静态时序分析工具一般都整合在芯片厂商提供的实现工具中。在Vivado中甚至没有一个独立的界面，而是通过几个特定的时序报告命令来实现。

OCV与PVT

即便是同一种FF，在同一个芯片上不同操作条件下的延时都不尽相同，我们称这种现象为OCV（on-chip variation）。OCV 表示的是芯片内部的时序偏差，虽然很细小，但是也必须严格考虑到时序分析中去。

产生OCV 的原因主要有PVT（Process / Voltage / Temperature）三个方面，而STA 要做的就是针对不同工艺角(Process Corner)下特定的时序模型来分析时序路径，从而保证设计在任何条件下都能满足时序要求，可以正常工作。

通常PVT 对芯片性能的影响如下图所示

不同的PVT 条件组成了不同的corner，另外在数字电路设计中还要考虑RC corner的影响，排列组合后就可能有超过十种的corner要分析。但是在FPGA设计中静态时序分析一般仅考虑Best Case和Worst Case，也称作Fast Process Corner 和Slow Process Corner，分别对应极端的PVT条件。

Multi-Corner

Vivado中的STA支持多角时序分析（Multi-Corner Analysis），会对以上两种corner下的时序同时进行分析，然后报告最差的情况。因为每个corner下的延时也会有一定的变化范围，所以时序分析还会考虑corner下的最大延时和最小延时。

如果一个设计在Best Case和Worse Case下都能满足时序要求，则可以推算这个设计在其允许的任何操作条件下都能保持正常工作。

有特殊需要的情况下，可以在Vivado中通过config_timing_corner -corner<Slow|Fast> -delay_type <none|min|max|min_max>来选择将某种corner引用于setup或hold的分析。在Report Timing Summary和Report Timing的图形化界面也可以通过Timing Setting对corner做调整。

这样最大化考虑OCV的时序分析方法在处理同一条路径的共同时钟路径时也会应用不同的延时数据，从而会得出更为悲观的数据，为了真实反映路径延时情况，这部分延时必须被纠正，这就是CRPR（Clock Reconvergence Pessimism Removal）。

仔细.察时序报告便可以发送在报告路径的Slack之前有一行显示clock pessimism 已经被考虑在内，在进行Setup Check时会加上一定的clock pessimism，而Hold Check时则会减去一定的clock pessimism。

下图显示了CRPR的来源以及在Vivado时序报告中的具体体现。

时序命令与报告

Vivado 中用于时序分析的命令主要有以下两条，且都有对应的图形化设置界面

• Report_timing_summary主要用于实现后的timing sigh-off
• Report_timing主要用于交互式的约束验证以及更细致具体的时序报告与分析

report_timing_summary

在Vivado IDE 中点击Report Timing Summary 后可以改变报告的内容，例如每个时钟域报告的路径条数，是否setup 和hold 全都报告等等。每改变一个选项都可以看到窗口下方的Command 一栏显示出对应的Tcl 命令。修改完设置后可以直接按OK 键确认执行，也可以拷贝Command 栏显示的命令到Tcl 脚本中稍后执行。

report_timing

report_timing是更具体的时序报告命令，经常用来报告某一条或是某些共享特定节点点的路径。用户可以在设计的任何阶段使用report_timing，甚至是一边设置XDC，一边用其来验证约束的可行性与优先级。在Vivado IDE中可以由Tools>Timing>Report Timing调出其图形化设置窗口。

与report_timing_summary类似，调整选项后对应的Tcl命令也会在Command栏生成，在Targets一栏还可以设置需要报告路径的起始点/途经点/结束点，可以三个都设置或是仅设置其中任何一项，每一项都支持通配符匹配甚至是正则表达式查找。report_timing报告出的路径延时与report_timing_summary中具体到每根路径上的报告一致，可以以此为依据帮助我们定位时序失败的原因。

用report_timing 来报告时序其实.有一些更常见的应用场景，用来帮助我们.置和验证约束，尤其是那些时序例外约束。

举例来说，在设计过程中我们约束了一条或数条多周期约束，不同于UCF 必须读入约束后重跑设计，我们可以直接在Tcl Console 中输入这条XDC，无需重跑设计，直接用report_timing 来验.。在随之显示的时序报告Summary 部分可以看到Timing Exception 后列出这条路径被设置了怎样的时序例外约束（注意，不加额外option时，以下两条命令都仅.对setup check） 。

单纯的一条多周期约束没有什么特别，但是如果使用了通配符后的时序例外有重叠的情况下，Vivado会根据优先级来决定对某条路径应用怎样的约束。当设计较大，XDC较多时，一边设置XDC一边用report_timing来验证就变得尤其重要。另外，仅仅输入report_timing而不加任何option，Vivado便会报告出时序违例最严重的那条路径，方便我们快速了解当前设计的WNS，找到最差的那条路径。在验证I/O约束时也常常用到report_timing，只要指定-from某个输入或是-to某个输出便可以快速验.当前设.在接口上的时序。

get_timing_paths

除了上述两个大家比较熟悉的时序报告命令，Vivado中还提供一个get_timing_paths的命令，可以根据指定的条件找到一些特定的路径。我们可以利用其返回值中的一些属性来快速定位设计中的问题。

例如逻辑级数这个影响FPGA性能的一大因素，因为.常隐藏在时序报告后很难被发现。在Vivado中，除了借助综合后的报告来找到那些可能因为逻辑级数较高而导致致的时序难满足的路径外，还有一个更直接的办法，可以一次性报告出设计中那些高逻辑级数的路径，方便我们有针对性的深入分析和优化。

下图这个例子报告了时序最差的10条路径的逻辑级数。需要注意的是，在综合后和在布局布线后用一样的脚本报告出的结果会稍有不同，对逻辑级数较为关注的情况，还是建议以综合后的结果为主要依据。