---

参考文献
[1]Static Timing Analysis for Nanometer Designs A Practical Approach

一、时序路径组

  静态时序分析STA会分析设计中的所有时序路径，每个路径都有一个起点和终点。

  如图7-26所示，在 STA 中，时序路径是根据有效的起点和终点来划分的。

• 有效的路径起点：输入端口、同步器件的时钟引脚（如触发器的CK端口）
• 有效的路径终点：输出端口、同步器件的数据输入引脚（触发器的D端口）
    因此，有效的时序路径包括：
• 从输入端口到输出端口。
• 从输入端口到触发器或存储器的数据输入引脚。
• 从一个触发器或存储器的时钟引脚到另一个触发器或存储器的数据输入引脚。
• 从一个触发器或存储器的时钟引脚到输出端口。
    图7-26中有效的时序路径包括
• 输入端口 A 到输出端口 Z
• 输入端口 A 到触发器 UFFA 的 D 引脚
• 触发器 UFFA 的 CK 引脚到触发器 UFFB 的 D 引脚
• 触发器 UFFB 的 CK 引脚到输出端口 Z
    时序路径可以根据与路径终点相关的时钟分类为不同时序路径组（path groups）。因此，每个时钟都有一组与之相关的时序路径。还有一个默认时序路径组，其中包括了所有非时钟（异步）路径。
  

  在图 7-27 的示例中，时序路径分组为：

• CLKA 组：输入端口 A 到触发器 UFFA 的 D 引脚
• CLKB 组：触发器 UFFA 的 CK 引脚到触发器 UFFB 的 D 引脚
• 默认组：输入端口 A 到输出端口 Z、触发器 UFFB 的 CK 引脚到输出端口 Z
    静态时序分析和报告通常分别在每个时序路径组中单独执行。

二、建立时间检查

  在时钟的有效沿到达触发器之前，数据应在一定时间（触发器的建立时间）内保持稳定，该要求将确保数据可靠地被捕获到触发器中。图 8-1 显示了典型触发器的建立时间要求，建立时间检查将验证触发器的建立时间要求。通常，有一个发起触发器（用于发起数据的触发器）和捕获触发器用于捕获数据的触发器），这个捕获触发器的建立时间要求必须满足。建立时间检查将验证从发起触发器到捕获触发器的最长（或最大）路径，这两个触发器的时钟可以相同也可以不同。建立时间检查是从发起触发器中时钟的第一个有效沿到捕获触发器中时钟后面最接近的那个有效沿。建立时间检查将确保上一个时钟周期发起的数据准备好在一个周期后被捕获。

  如图 8-2 所示，其中发起触发器和捕获触发器具有相同的时钟。时钟 CLKM 的第一个上升沿在 Tlaunch 时间后出现在发起触发器的时钟引脚上，由该时钟沿发起的数据出现在触发器 UFF1 的 D 引脚的所需时间为 Tlaunch + Tck2q + Tdp。时钟CLKM 的第二个上升沿（通常在一个周期后检查建立时间）出现在捕获触发器 UFF1 的时钟引脚上的时间为 Tcycle + Tcapture。这两个时间之差必须大于触发器 UFF1 的建立时间要求，以确保触发器 UFF1可靠地捕获数据。
  建立时间检查可以用数学公式表达为
$$T_{launch}+T_{ck2q}+T_{dp}<T_{capture}+T_{cycle}-T_{setup}$$
  其中，$T_{launch}$ 是发起触发器 UFF0 的时钟树延迟，T_{ck2q}是发射触发器的时钟到输出延迟, $T_{dp}$ 是组合逻辑路径的延迟， $T_{cycle}$ 是时钟周期， $T_{capture}$ 是捕获触发器 UFF1 的时钟树延迟。

  总得来说，为了保证数据被捕获触发器正确采样，必须要满足建立时间检查，也就是数据到达捕获触发器 D 引脚所花费的总时间必须小于时钟传输到捕获触发器所花费的时间加上时钟周期再减去建立时间要求。
  由于建立时间检查受到-max 的约束，因此建立时间检查始终使用最长或最大的时序路径。出于同样的原因，通常在延迟最大的慢工艺角（slow corner）下执行建立时间检查。第一部分提到，时序路径分为四类，以下分别分析。

1. 触发器到触发器路径

  以下是一份触发器到触发器时序路径是建立时间检查报告。

  该报告中显示发起触发器（由 Startpoint 指定）的实例名称为UFF0，由时钟 CLKM 的上升沿触发。捕获触发器（由 Endpoint 指定）为 UFF1，也由时钟 CLKM 的上升沿触发。路径组（PathGroup）显示它属于路径组 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 cuncertainty），因此，有效时钟周期由于不确定度而减少了 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 延迟是捕获触发器上的时钟网络延迟。

  时序路径报告中可以选择包含扩展的时钟路径，即带有明确显示的时钟树。以下是一个例子.路径报告中的 UCKBUF0、 UCKBUF1 和 UCKBUF2 都是时钟缓冲器，提供了有关如何计算时钟树延迟的详细信息。

  此外，这里还需要关注以下概念。

1）时钟单元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 的下降沿结束。以下就是这样一条路径：

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

2）时钟源延迟（clock source latency）

  时钟源延迟（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 中时钟定义点到触发器的时钟引脚的延迟。时钟网络延迟用于在建立时钟树之前（即在时钟树综合之前）对通过时钟路径的延迟进行建模。一旦建立了时钟树并标记为了“已传播”（propagated），便会忽略此时钟网络延迟约束。

2. 输入到触发器路径

1) 虚拟时钟的输入路径

  以下是一个通过输入端口到触发器的路径报告示例，图 8-4 给出了与输入路径有关的原理图和时钟波形。

  首先要注意的是第一行中的 input port clocked by VIRTUAL_CLKM。如 7.9 节中所述，该时钟可以被认为是驱动设计输入端口 INA 的虚拟触发器，该虚拟触发器的时钟为 VIRTUAL_CLKM。此外，从该虚拟触发器的时钟引脚到输入端口 INA的最大延迟指定为 2.55ns，在报告中显示为 input external delay。可以使用以下 SDC 命令指定这些参数：

create_clock -name VIRTUAL_CLKM -period 10 -waveform {0 5}
set_input_delay -clock VIRTUAL_CLKM -max 2.55 [get_ports INA]

  注意，虚拟时钟 VIRTUAL_CLKM 的定义没有与设计中任何引脚相关，这是因为它是在设计之外定义的（它是虚拟的）。输入延迟约束set_input_delay 指定了相对于虚拟时钟的延迟。

  输入路径从端口 INA 开始，如何计算连接到端口 INA 的第一个单元UINV1 的延迟呢？一种方法是指定输入端口 INA 的驱动单元，该驱动单元用于确定驱动强度，从而确定端口 INA 上的压摆，然后用于计算单元 UINV1 的延迟。在输入端口 INA 上没有任何压摆约束的情况下，将假定端口上的过渡是理想的，即过渡时间为 0ns。输入延迟的设置详细可见

set_driving_cell -lib_cell BUFF -library lib0131wc[get_ports INA]

  图 8-4 还展示了如何进行建立时间检查。数据必须到达 UFF2 / D 的时间为 9.85ns，但是数据实际到达的时间为 2.65ns，因此该报告显示该路径的正裕量为 7.2ns。

2) 具有实际时钟的输入路径

  输入延迟也可以相对于实际时钟来指定，并不一定必须相对于虚拟时钟来指定。实际时钟可以是设计中的内部引脚或者输入端口上的时钟，图 8-5 描绘了一个示例，其中相对于输入端口 CLKP 上的时钟指定了端口 CIN 上的输入延迟约束。此延迟约束为：

set_input_delay -clock CLKP -max 4.3 [get_ports CIN]

3. 触发器到输出路径

  与上述输入端口约束类似，可以相对于虚拟时钟或设计中的内部时钟来约束输出端口，或者可以相对于实际的输入时钟端口或输出时钟端口来约束输出端口。以下是一个示例，相对于虚拟时钟约束了输出引脚 ROUT，输出约束如下：

set_output_delay -clock VIRTUAL_CLKP -max 5.1 [get_ports ROUT]
set_load 0.02 [get_ports ROUT]

  为了确定最后一个单元连接到输出端口的延迟，需要指定该端口上的负载，上面使用了 set_load 命令来指定输出负载。请注意，端口ROUT 可能在 DUA 内部具有负载，而 set_load 约束指定的是额外的负载，即来自 DUA 外部的负载。在没有 set_load 命令约束的情况下，将假定外部负载的值为 0（这可能不现实，因为该设计很可能会在其它设计中使用）。下图 8-6 显示了具有虚拟时钟的虚拟触发器的时序路径：

  注意，指定的输出延迟在报告中显示为 output external delay，其作用类似于虚拟触发器所需的建立时间。输出延迟的设置详情可见

4. 输入到输出路径

  设计也可以具有从输入端口到输出端口的纯组合逻辑路径。可以像我们前面看到的输入和输出路径一样，对路径进行约束和时序分析。下图 8-7 显示了这种路径的一个示例，虚拟时钟同时用于指定输入和输出端口上的约束，以下是输入和输出延迟约束：

set_input_delay -clock VIRTUAL_CLKM -max 3.6 [get_ports INB]
set_output_delay -clock VIRTUAL_CLKM -max 5.8 [get_ports POUT]

  以下是一个时序路径报告，它经过从输入 INB 到输出 POUT 的组合逻辑。请注意，任何内部时钟延迟（如果存在）都不会对该路径报告产生影响。