时序检查

Posted 2022-09-27 KuoGavin

文章目录

• • 8.1 建立时间检查(Setup Timing Check)
  • • 8.1.1 触发器到触发器路径(Flip-flop to Flip-flop Path)
    • 8.1.2 输入到寄存器路径(Input to Flip-flop Path)

---

---

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

• 两项主要的检查是建立时间和保持时间检查。一旦在触发器的时钟引脚上定义了时钟，便会自动推断出该触发器的建立时间和保持时间检查。时序检查通常会在多个条件下执行，包括最差情况的慢速条件和最佳情况的快速条件。通常，最差情况的慢速条件对于建立时间检查很关键，而最佳情况的快速条件对于保持时间检查很关键(尽管也可以在最差情况的慢速条件下执行保持时间检查)。
• 本章节中的示例假定网络延迟为零，这样做是为了简化说明，并且不会更改所介绍的概念。

---

---

8.1 建立时间检查(Setup Timing Check)

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

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

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

建立时间检查可以数学表达为：

$$T_{launch}+T_{ck2q}+T_{dp}<T_{capture}+T_{cycle}-T_{setup}$$

建立时间检查的要求也即是：$$T_{setup}<(T_{capture}+T_{cycle})-(T_{launch}+T_{ck2q}+T_{dp})$$

其中$T_{launch}$是发起触发器$UFF0$的时钟树延迟，$T_{dp}$是组合逻辑数据路径的延迟，$T_{cycle}$是时钟周期，$T_{capture}$是捕获触发器$UFF1$的时钟树延迟。

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

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

---

8.1.1 触发器到触发器路径(Flip-flop to Flip-flop Path)

这里有一个建立时间检查的报告：

该报告中显示发起触发器(由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$延迟是捕获触发器上的时钟网络延迟。

时序路径报告中可以选择包含扩展的时钟路径，即带有明确显示的时钟树。以下是一个例子：

注意到出现在上面路径报告中的时钟缓冲器$UCKUBF0,UCKBUF1$和$UCKBUF2$，提供了时钟树延迟是如何计算得到的。

如何计算第一个时钟单元$UCKBUF0$的延迟呢？如前几章所述，单元延迟是根据单元的输入过渡时间和输出电容来计算的。因此，问题是在时钟树的第一个单元的输入处指定了多大的过渡时间，可以使用set_input_transition命令明确指定第一个时钟单元输入引脚上的过渡时间(或压摆)。

set_input_transition -rise 0.3 [get_ports CLKM]
set_input_transition -fall 0.45 [get_ports CLKM]

在上述的set_input_transition命令中，我们将输入上升过渡时间指定为了$0.3ns$，将下降过渡时间指定为$0.45ns$。在没有该命令约束的情况下，将在时钟树的源端假设存在理想的压摆，这意味着上升和下降过渡时间均为$0ns$。

时序报告中的r和f字符表示时钟或数据信号的上升沿(和下降沿)。上一个时序路径报告中显示了一条从$UFF0/Q$的下降沿开始到$UFF1/D$的上升沿结束的路径。由于$UFF1/D$可以为$0$或$1$，因此也可以有一条路径在$UFF1/D$的下降沿结束。以下就是这样一条路径：

注意，触发器时钟引脚的边沿(称为有效边沿)保持不变。它只能是上升或下降有效沿，具体取决于触发器是由上升沿触发的还是由下降沿触发的。

什么是时钟源延迟(clock source latency)？ 这也被称为插入延迟(insertion delay)，是时钟从其源端传播到待分析设计的时钟定义点所花费的时间，如图8-3所示，这对应于设计之外的时钟树延迟。例如，如果该设计是较大模块的一部分，则时钟源延迟是指直到待分析设计时钟引脚为止的时钟树延迟。可以使用set_clock_latency命令明确指定此延迟。

set_clock_latency -source -rise 0.7 [get_clocks CLKM]
set_clock_latency -source -fall 0.65 [get_clocks CLKM]

在没有上述命令的情况下，将假定延迟为$0$，这是早期路径报告中使用的假设。请注意，源延迟不会影响设计内部的路径，并且它们具有相同的发起时钟和捕获时钟，这是因为发起时钟路径和捕获时钟路径都会加上一段相同的延迟。但是，这种延迟确实会影响经过待分析设计输入和输出的时序路径。

如果没有-source选项，则set_clock_latency命令将定义时钟网络延迟，这是从$DUA$中时钟定义点到触发器的时钟引脚的延迟。时钟网络延迟用于在建立时钟树之前(即在时钟树