【第八章 时序检查 上】静态时序分析圣经翻译计划

本文由知乎赵俊军授权转载，知乎主页为https://www.zhihu.com/people/zhao-jun-jun-19

本章节将介绍静态时序分析所执行的一部分检查，这些检查旨在详尽地验证待分析设计的时序。

• 两项主要的检查是建立时间和保持时间检查。一旦在触发器的时钟引脚上定义了时钟，便会自动推断出该触发器的建立时间和保持时间检查。时序检查通常会在多个条件下执行，包括最差情况的慢速条件和最佳情况的快速条件。通常，最差情况的慢速条件对于建立时间检查很关键，而最佳情况的快速条件对于保持时间检查很关键(尽管也可以在最差情况的慢速条件下执行保持时间检查)。

• 本章节中的示例假定网络延迟为零，这样做是为了简化说明，并且不会更改所介绍的概念。

8.1 建立时间检查

建立时间检查会验证触发器时钟和数据引脚之间的时序关系，从而满足建立时间要求。换句话说，建立时间检查会确保在触发器输入时钟之前，数据在触发器的输入端可用。在时钟的有效沿到达触发器之前，数据应在一定时间内保持稳定，即触发器的建立时间，该要求将确保数据可靠地被捕获到触发器中。图8-1显示了典型触发器的建立时间要求，建立时间检查将验证触发器的建立时间要求。

通常，有一个发起触发器(用于发起数据的触发器)和捕获触发器(用于捕获数据的触发器)，这个捕获触发器的建立时间要求必须满足。建立时间检查将验证从发起触发器到捕获触发器的最长(或最大)路径，这两个触发器的时钟可以相同也可以不同。建立时间检查是从发起触发器中时钟的第一个有效沿到捕获触发器中时钟后面最接近的那个有效沿。建立时间检查将确保上一个时钟周期发起的数据准备好在一个周期后被捕获。

现在我们研究一个简单的示例，如图8-2所示，其中发起触发器和捕获触发器具有相同的时钟。时钟CLKM的第一个上升沿在Tlaunch时间后出现在发起触发器的时钟引脚上，由该时钟沿发起的数据出现在触发器UFF1的D引脚的所需时间为Tlaunch + Tck2q + Tdp。时钟CLKM的第二个上升沿(通常在一个周期后检查建立时间)出现在捕获触发器UFF1的时钟引脚上的时间为Tcycle + Tcapture。这两个时间之差必须大于触发器UFF1的建立时间要求，以确保触发器UFF1可靠地捕获数据。

建立时间检查可以用数学公式表示：

• Tlaunch + Tck2q + Tdp < Tcapture + Tcycle - Tsetup

其中Tlaunch是发起触发器UFF0的时钟树延迟，Tdp是组合逻辑数据路径的延迟，Tcycle是时钟周期，Tcapture是捕获触发器UFF1的时钟树延迟。

换句话说，数据到达捕获触发器D引脚所花费的总时间必须小于时钟传输到捕获触发器所花费的时间加上时钟周期再减去建立时间要求。

由于建立时间检查受到-max的约束，因此建立时间检查始终使用最长或最大的时序路径。出于同样的原因，通常在延迟最大的慢工艺角(slow corner)下执行建立时间检查。

8.1.1 触发器到触发器路径

以下是一份建立时间检查的路径报告：

该报告中显示发起触发器(由Startpoint指定)的实例名称为UFF0，由时钟CLKM的上升沿触发。捕获触发器(由Endpoint指定)为UFF1，也由时钟CLKM的上升沿触发。路径组(Path Group)显示它属于路径组CLKM。如上一章所述，设计中的所有路径都基于捕获触发器的时钟归类为路径组。路径类型(Path Type)显示此报告中的延迟均为最大路径延迟，表明这是建立时间检查。这是因为建立时间检查对应于通过逻辑的最大(或最长路径)延迟。注意，保持时间检查对应于通过逻辑的最小(或最短路径)延迟。

Incr列显示了指定端口或引脚的单元或网络延迟增量，Path列显示了数据实际到达和需要到达的路径累积延迟，这是用于此示例的时钟约束：

• create_clock -name CLKM -period 10 -waveform {0 5} [get_ports CLKM]

• set_clock_uncertainty -setup 0.3 [all_clocks]

• set_clock_transition -rise 0.2 [all_clocks]

• set_clock_transition -fall 0.15 [all_clocks]

数据发起路径需要0.26ns的延迟才能到达触发器UFF1的D引脚，这是捕获触发器输入端的到达时间。捕获边沿(建立时间检查时为一个周期)为10ns，为此时钟指定了0.3ns的时钟不确定度(clock uncertainty)，因此，有效时钟周期由于不确定度而减少了0.3ns。时钟不确定度包括由于时钟源抖动引起的周期变化以及用于分析的任何其它时序裕量。从总的捕获路径中还要减去触发器的建立时间0.04ns(library setup time)，得出数据需要到达的时间为9.66ns。由于数据实际到达时间为0.26ns，因此在此时序路径上有9.41ns的正裕量(slack)。请注意，所需到达时间和实际到达时间之差可能看起来是9.40ns，但是实际值是出现在报告中的9.41ns。之所以存在差异，是因为报表仅显示小数点后两位数字，而内部计算和存储的值比所报告的精度更高。

时序报告中的时钟网络延迟(clock network delay)是什么？为什么将其标记为理想(ideal)？时序报告中的这一行表明时钟树被认为是理想的，时钟路径中的任何缓冲器(buffer)都假定为零延迟。一旦构建了时钟树，就可以将时钟网络标记为“已传播”(propagated)，从而使得时钟路径显示实际延迟值，如下一个示例时序报告中所示：0.11ns延迟是发起时钟上的时钟网络延迟，而0.12ns延迟是捕获触发器上的时钟网络延迟。