静态时序分析STA——8.2 时序检查（保持时间检查）

---

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

三、保持时间检查

  保持时间检查可确保正在变化的触发器输出值不会传递到捕获触发器、并在捕获触发器有机会捕获其原始值之前重写（overwrite）其输出。该检查基于触发器的保持时间要求，触发器的保持时间要求规定在时钟的有效沿之后的指定时间段内，被锁存的数据应保持稳定。图8-9 给出了典型触发器的保持时间要求：

  就像建立时间检查一样，是在发起触发器（发起数据的触发器）和捕获触发器（捕获数据的触发器以及必须满足其保持时间要求的触发器）之间进行保持时间检查的。这两个触发器的时钟可以相同也可以不同，保持时间检查从发起触发器时钟的一个有效沿到捕获触发器中相同的时钟沿。因此，保持时间检查与时钟周期无关，保持时间检查会在捕获触发器时钟的每个有效沿上执行。
  现在我们来看一个简单的示例，如图 8-10 所示，其中发起触发器和捕获触发器具有相同的时钟。

  考虑时钟 CLKM 的第二个上升沿。时钟上升沿发起的数据需要Tlaunch + Tck2q + Tdp 时间到达捕获触发器 UFF1 的 D 引脚。时钟的同一边沿需要 Tcapture 时间才能到达捕获触发器的时钟引脚，目的是使捕获触发器在下一个时钟周期捕获来自发起触发器的数据。如果在同一时钟周期内捕获数据，则捕获触发器中的预期数据（来自上一个时钟周期）将被覆盖，因此保持时间检查旨在确保捕获触发器中的目标数据不会被覆盖。保持时间检查可验证这两个时间之差（捕获触发器的数据到达时间和时钟到达时间）必须大于捕获触发器的保持时间，这样触发器上的数据才不会被覆盖，并且捕获到可靠的数据。
  保持时间检查可以用数学公式表示为：
$$T_{launch}+T_{ck2q}+T_{dp}>T_{capture}+T_{hold}$$
  其中 $T_{launch}$ 是发起触发器的时钟树延迟，$T_{dp}$ 是组合逻辑数据路径中的延迟， $T_{capture}$ 是捕获触发器的时钟树延迟。换句话说，**由时钟边沿发起的数据到达捕获触发器 D 引脚所需的总时间必须大于时钟同一边沿到达捕获触发器所需的时间加上保持时间。**这样可以确保 UFF1/ D 保持稳定状态，直到触发器的时钟引脚 UFF1 / CK 时钟上升沿之后的保持时间为止。
  保持时间检查对捕获触发器的数据路径施加了最小值（-min）约束，需要确定到捕获触发器 D 引脚的最快路径。这意味着将始终使用最短时序路径来进行保持时间检查，同样，通常在快速工艺角下进行保持时间检查。
  即使设计中只有一个时钟，时钟树也会导致时钟在发起触发器和捕获触发器处的到达时间大不相同。为了确保可靠的数据捕获，捕获触发器的时钟沿必须在数据可改变之前到达。保持时间检查可确保（见图8-11）：

• 当前数据发起时钟沿（Setup launch edge）的下一个（subsequent）时钟沿发起的数据不被当前数据捕获时钟沿（Setup receiving edge）所捕获。
• 当前数据发起时钟沿发起的数据不被当前数据捕获时钟沿的前一个（Preceding）时钟沿所捕获。
  

  如果发起时钟和捕获时钟都属于同一时钟域，则这两个保持时间检查实质上是相同的。但是，当发起时钟和捕获时钟处于不同频率或处于不同时钟域时，以上两个保持时间检查就有可能是不同的。在这种情况下，最差的保持时间检查就是所要报告的检查。上图 8-11 说明了这两个保持时间检查。
  UFF0 是发起触发器， UFF1 是捕获触发器。建立时间检查在这一个数据发起时钟沿（Setup launch edge）和这一个数据捕获时钟沿（Setup receiving edge）之间。下一个数据发起时钟沿（Subsequent launch edge）不得以太快的速度传播数据，因为这可能会导致这一个数据捕获时钟沿没有时间可靠地捕获这一个数据。此外，这一个数据发起时钟沿同样不得以太快的速度传播数据，因为这可能会导致前一个数据捕获时钟沿（Preceding eceiving edge）没有时间可靠地捕获前一个数据。在上述各种情况中，最差情况的保持时间检查对应于最严格的保持时间检查。
  注意：虽然建立时间违例会导致设计的工作频率降低，但保持时间违例会“杀死”（kill）设计，即设计在任何频率下都无法运行。因此，了解保持时间检查并解决任何违例行为非常重要。

1. 触发器到触发器路径

  基于图 8-2 中示例说明触发器到触发器的保持时间路径。以下是一份保持时间检查的路径报告。

  **注意，路径类型（Path Type）为最小值(min)，表示使用了最短路径的单元延迟值，这对应于保持时间检查。库保持时间（library hold time）指定了触发器 UFF1 的保持时间。触发器的保持时间也可以为负。**请注意，发起和捕获路径都是从时钟 CLKM 的上升沿（触发器的有效沿）开始计算的。时序报告显示，新数据最早可以到达 UFF1、同时又可以安全地捕获上一个时钟周期数据的时间为0.19ns。由于新数据的实际到达时间为 0.33ns，因此报告显示正的保持时间裕量（slack）为 0.14ns。
  图 8-12 显示了时钟信号到达发起和捕获触发器时钟引脚的时间，以及数据在捕获触发器处的最早允许到达时间和实际到达时间。由于数据实际到达的时间晚于数据所需到达的时间（允许的最早到达时间），因此满足保持时间要求。

注意：建立时间和保持时间的时序报告计算裕量值的方式有所不同。在建立时间报告中，会计算数据实际到达时间和数据需要到达时间，然后将需要到达时间减去实际到达时间，从而得到建立时间的裕量值。但是，在保持时间报告中，当我们把需要到达时间减去实际到达时间后，负的结果将转化为正的裕量值（表示满足保持时间要求），而正的结果将转化为负的裕量值（表示保持时间违例）。

2. 输入到触发器路径

虚拟时钟

  接下来介绍输入端口的保持时间检查。有关示例，请参见图 8-4。使用虚拟时钟将输入端口上的最小延迟指定为：

set_input_delay -clock VIRTUAL_CLKM -min 1.1 [get_ports INA]

  以下是一份保持时间检查的路径报告：

  input external delay 中的值为输入延迟约束命令中的指定值。在 0时刻的 VIRTUAL_CLKM 上升沿和 CLKM 上升沿之间进行保持时间检查。 UFF2 在不违反其保持时间的情况下捕获数据所需的到达时间为0.25ns，这表明数据应在 0.25ns 之后到达。由于数据实际上在 1.2ns才到达，因此显示出 0.95ns 的正裕量。

3. 触发器到输出路径

  示例见图 8-6，输出端口延迟约束为：

set_output_delay -clock VIRTUAL_CLKP -min 2.5 [get_ports ROUT]

  输出延迟也是相对于虚拟时钟指定的，这是另一份保持时间检查的路径报告：

  注意， output external delay 中的值为输出延迟约束命令中的指定值。

实际时钟

  有一条输出端口保持时间检查的路径，如图 8-13 所示，最小输出延迟是相对于实际时钟指定的。

set_output_delay -clock CLKP -min 3.5 [get_ports QOUT]
set_load 0.55 [get_ports QOUT]

  以下是保持时间报告：

  保持时间检查是在时钟 CLKP 的上升沿（触发器的有效沿）处执行的。以上报告表明，这条触发器到输出的路径保持时间的正裕量为4.46ns。

4. 输入到输出路径

  对输入到输出路径的保持时间检查，如图 8-7 所示。端口的约束为

set_load -pin_load 0.15 [get_ports POUT]
set_output_delay -clock VIRTUAL_CLKM -min 3.2 [get_ports POUT]
set_input_delay -clock VIRTUAL_CLKM -min 1.8 [get_ports INB]
set_input_transition 0.8 [get_ports INB]

注意：Input tranition和output capacitance会影响器件模型的延迟，通过查表计算得到。

  输入端口和输出端口上的延迟约束是相对于虚拟时钟指定的，因此，保持时间检查是在该虚拟时钟的上升沿（有效沿）处执行的。