01signal.com

clock period constraint 及其 timing analysis

此页面属于关于 timing的一系列页面上一页介绍了 timing constraints背后的理论基础。下一步是看看这个理论是如何应用的。

概述

本页介绍了最重要的 timing constraint,它定义了 clock的频率。接下来是 timing report对 path分析的详细示例。

timing report的分析细节似乎是一个高级话题,但事实并非如此: timing constraints 的目的是控制工具对 design的 timing 分析,设置必须满足的准确要求。因此,为了了解 timing constraints,有必要研究 timing analysis。 timing analysis 显示在 timing reports中。

此外,仅编写 timing constraints 是远远不够的。能够验证这些 constraints 在 design上是否正常工作非常重要。只有深入了解 timing report才能进行这样的验证。如果没有这样的理解,很容易误以为 timing constraints 没有达到他们的目的,然后想知道为什么 logic design 不能正常工作。

所有 FPGA 工具都将 timing reports 生成为文本文件,这些是此处显示的报告。这些工具还有一个图形界面,用于查看完全相同的信息。这个图形界面有时很有用,有时会让人困惑,因此使用文本报告是重要的第一步。

period constraint

最有用的 timing constraint 是 period constraint: 它通知工具有关 clock signal的频率。

例如,假设 logic design 仅由这个 Verilog module组成:

module top(
  input clk,
  input foo,
  output reg bar_reg);

  reg foo_reg;
  reg bar;

   always @(posedge clk)
     begin
	foo_reg <= foo;
	bar <= !foo_reg;
	bar_reg <= bar;
     end
endmodule

从 Verilog 可以看出 @clk 是作为 clock使用的,而这个 signal 是外接的 port (即 FPGA上接了一个物理 pin )。

如果 @clk的频率是 250 MHz (4 ns),则需要如下所示的 timing constraint :

create_clock -period 4 -name clk [get_ports clk]

该命令的含义如下: “ I/O port 处有一个 clock 叫 @clk。这个 clock的 period 是 4 ns。如果有其他 timing constraints 会引用这个 clock,他们会为此使用名称'clk'”。

笔记:

Timing analysis

我们现在将查看 Vivado的 timing analysis ,以了解 path 的 setup 要求,从 @foo_reg 开始到 @bar结束。换句话说,这是这个 Verilog 表达式的结果 path :

bar <= !foo_reg;

这里展示的 timing analysis 由三部分组成,在 timing report 中出现的顺序是这样的:

  1. 一个 header,里面包含了 path的 timing analysis的总结,以及一些额外的信息。
  2. 计算从 clock edge 到第二个 flip-flop (本例中为@bar )的 input 出现稳定的 logic state 所花费的时间。
  3. 计算发现第二个 flip-flop 的 input 何时必须稳定才能满足 timing 要求。

下面分别对这三个部分进行展示和描述。请注意,在 timing report中,这些部分之间没有可见的分隔符。特别是,从 timing report 看,第二部分结束和第三部分开始的地方并不明显。本报告的读者可以从其内容中认出第三部分的开头。

尽管此处显示的是 Vivado的 timing report ,但 Quartus 和其他几个 FPGA 工具也采用了相同的方法。在其他工具的 timing reports 中写入的信息通常会略有不同。然而,这些报告背后的理论是相同的。因此,通过此示例对其他 FPGA 工具也有帮助。

我们将跳过 timing report中的第一部分,并在讨论前两部分后回到这部分。按此顺序解释报告更容易。但首先,一些一般性的话。

timing analysis的攻略

上一页显示的简单 static timing analysis 不同,真正的 timing analysis 需要考虑到 clock的缺陷。为此, delay 计算从 clock的原点开始,例如 clock的物理 input pin 。这不同于简单的 data path delay 计算(如前一页所示),后者只考虑 data path的 delay 。

所以现在理论实验如下: 在 clock的原点用 clock edge 启动秒表。让这个秒表继续,因为这个 clock edge 行进到第一个 flip-flop 并激活它。继续测量此 flip-flop 更新其 output的时间,并跟随更新的 signal 到达目的地。当这个 signal 到达第二个 flip-flop时停止秒表。

下一步是检查结果是否良好。对于 tsu 要求,这意味着 signal 相对于下一个 clock edge来得足够快。

但这是第二个 flip-flop上的 clock edge 。什么时候到?

为了查明这一点,秒表再次启动,同时启动 clock原点的下一个 clock edge 。当第二个 clock edge 到达第二个 flip-flop时秒表停止。所以起点是一样的,只是 clock edge 晚了, clock edge 的终点不一样了。

经过这个理论实验,我们知道 clock edge 何时到达第二个 flip-flop。为了满足 tsu 的要求,这个 flip-flop的 input 相对于这个 clock edge必须要足够早的稳定。

第一个理论实验的秒表显示 data 何时稳定在第二个 flip-flop。第二个实验的秒表显示 clock edge 到达同一 flip-flop的时间。剩下的就是比较这两个数字,并检查差异是否大于 tsu的要求。

使用此方法可以考虑与 clock 相关的不确定性,因为它允许在两个理论实验中应用最坏情况。对于 setup time 计算,所有 delays 的上限用于秒表第一次实验的计算。结果,计算显示 signal 可以到达第二个 flip-flop的 input 的最晚可能时间。但是对于秒表的第二次实验,使用了所有 delays 的下限。结果是第二个 clock edge 到达第二个 flip-flop的最早可能时间。

所以针对 signal 尽量晚到, clock edge 尽量早到的场景进行计算。如果在这些条件下满足 setup time 要求,则毫无疑问始终满足此要求。

对于 hold time 计算,则相反: 第一个实验使用最小 delays ,第二个实验使用最大 delays 。

source path 计算

如上所述, timing report 的第一部分稍后展示。所以我们现在来看 timing analysis的第二部分: source path 计算。它由两个 segments组成:

这两个 segments 一起计算从 rising edge 在 FPGA的外部 clock pin 到 data 到达第二个 flip-flop的时间。

这是 timing report中的相关部分:

Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk rise edge)        0.000     0.000 r
    AG12                                              0.000     0.000 r  clk (IN)
                         net (fo=0)                   0.000     0.000    clk_IBUF_inst/I
    AG12                 INBUF (Prop_INBUF_HRIO_PAD_O)
                                                      0.738     0.738 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.105     0.843    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.049     0.892 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.839     1.731    clk_IBUF
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.101     1.832 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=3, routed)           1.389     3.221    clk_IBUF_BUFG
    SLICE_X49Y58         FDRE                                         r  foo_reg_reg/C
  -------------------------------------------------------------------    -------------------
    SLICE_X49Y58         FDRE (Prop_EFF2_SLICEL_C_Q)
                                                      0.138     3.359 f  foo_reg_reg/Q
                         net (fo=1, routed)           0.241     3.600    foo_reg
    SLICE_X49Y58         LUT1 (Prop_D5LUT_SLICEL_I0_O)
                                                      0.244     3.844 r  bar__0_i_1/O
                         net (fo=1, routed)           0.046     3.890    p_0_in
    SLICE_X49Y58         FDRE                                         r  bar_reg__0/D
  -------------------------------------------------------------------    -------------------

此部分中的每一行代表一个 logic element 或一根电线。当“Delay type”为“net”时,该行对应一根线。所有此类 delays 都是 routing delays,即 signal 从一个 logic element 传播到另一个所花费的时间。

名为“Incr”的列显示 path 中的每个元素贡献了多少 delay 。 “Path”列显示了到那时为止的总 delay 。

中间的水平线标志着 Source Clock Path 的结束和 Data Path的开始。下面我们就来详细了解一下这两款 paths中的 delays 。

前七个 delays 与 input pin相关,也就是 AG12 (这是这个 pin的物理位置)。根据这份报告,与这个 pin 相关的 input pin 和 logic 总共贡献了 1.731 ns的 delay 。

global clock buffer 从其 input 到 output贡献了另一个 0.101 ns 。接下来是 global clock的 routing delay ,数量比较多: 1.389 ns。这是 clock signal 达到 @foo_reg的 clock input所需的时间。之所以用这么大的 delay ,是因为用了一个 global clock buffer 和一个 clock tree 来配这个 signal。这些 routing resources 旨在将 clock 分配到 FPGA 的大部分,同时将相同的 delay 分配到所有目的地。因此有一个大的 delay,即使 clock 只到达几个目的地,就像在这个例子中( clock 的 fan-out 只是 3)。

至此, clock 终于到达了包含 flip-flop的 slice ,本例中为 SLICE_X49Y58 。所以这是 Source Clock Path的结束。报告中的水平线表示 Data Path的开头。在上一页的示例中,这是简单的 static timing analysis 开始的地方。

在右侧的 Netlist Resources 列中,它在水平线上方的行中显示“foo_reg_reg/C”,并在该行之后显示“foo_reg_reg/Q”。所以横线后面的那一行肯定是 @foo_reg的 flip-flop 的 clock to output delay (从 C 到 Q)。这个 delay 就是 0.138 ns。 “FDRE”表示 Flip-flop 、 Data、 Reset 、 Enable。

接下来是 routing delay 到 LUT (0.241 ns), LUT (0.244 ns) 内的 propagation delay 和 routing delay 到第二个 flip-flop (0.046 ns)。 routing delays 非常小,因为所有东西都装在一个 slice中。

总结这部分, clock edge 从外部 pin 到第一个 flip-flop的 clock input 花费了 3.221 ns 。然后使用 0.669 ns ,直到更新的 signal 到达第二个 flip-flop的 input (3.890 − 3.221 = 0.669 ns)。总的来说,从外部 pin 上的 clock edge 到最终目的地稳定的 signal (第二个 flip-flop的 data input)的时间是 3.890 ns (最多,这是最坏情况的计算)。

所以现在是时候问问这是否足够快了。是否满足 setup time 要求?

Destination Clock Path

第二次计算的目的是找出 clock edge 从外部 pin 移动到第二个 flip-flop的 clock input的速度。

请注意, clock path的目的地是第二个 flip-flop。这不应与之前计算的 clock path混淆,其中目的地是第一个 flip-flop。

还有其他显着差异:

timing analysis (Destination Clock Path)的第三部分如下:

(clock clk rise edge)        4.000     4.000 r
    AG12                                              0.000     4.000 r  clk (IN)
                         net (fo=0)                   0.000     4.000    clk_IBUF_inst/I
    AG12                 INBUF (Prop_INBUF_HRIO_PAD_O)
                                                      0.515     4.515 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.066     4.581    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.034     4.615 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.722     5.337    clk_IBUF
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.091     5.428 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=3, routed)           1.218     6.646    clk_IBUF_BUFG
    SLICE_X49Y58         FDRE                                         r  bar_reg__0/C
                         clock pessimism              0.527     7.173
                         clock uncertainty           -0.035     7.138
    SLICE_X49Y58         FDRE (Setup_DFF2_SLICEL_C_D)
                                                      0.067     7.205    bar_reg__0
  -------------------------------------------------------------------
                         required time                          7.205
                         arrival time                          -3.890
  -------------------------------------------------------------------
                         slack                                  3.315

工具选择将 @foo_reg 和 @bar 放在同一个 slice上,所以在这个具体案例中,本次分析的 clock path 与第一个分析相同。据此不难看出, logic elements 的顺序和前面分析的完全一样,一直到横线。在这个序列之后,有两个 timing parameters 对计算进行调整: Clock pessimism 和 clock uncertainty。这些将在本页底部单独讨论。

在最后一次计算的前一行,我们有第二个 clock edge 可以到达的最早时间: clock edge后 7.138 ns 。 setup time 的要求是 data signal 必须在这个 clock edge之前稳定。 tsu 指定多少。所以为了得到 data 必须稳定的最晚时间, clock的到达时间减去 tsu

在上例中, tsu 为负,等于 −0.067 ns。因此,最终结果是 7.138 − (−0.067) = 7.205 ns。换句话说, data 必须稳定在第一个 clock edge之后的第二个 flip-flop ,不迟于 7.205 ns 。

在之前的计算中,结果是 data 稳定在这个 clock edge之后的 3.890 ns ,最差。所以这已经足够好了,有余量: 要求和保证之间的区别是 7.205 − 3.890 = 3.315 ns。也就是说, slack 就是 3.315 ns。

timing analysis总结

现在是时候回到 path的 timing report的第一部分了。这部分出现在上面显示的计算之前,它总结了主要结果。此外,本次 header 明确了此次计算中出现的几个数值。

所以请记住,这是 path 的 timing analysis 的开始方式:

Slack (MET) :             3.315ns  (required time - arrival time)
  Source:                 foo_reg_reg/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            bar_reg__0/D
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Path Group:             clk
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            4.000ns  (clk rise@4.000ns - clk rise@0.000ns)
  Data Path Delay:        0.669ns  (logic 0.382ns (57.100%)  route 0.287ns (42.900%))
  Logic Levels:           1  (LUT1=1)
  Clock Path Skew:        -0.048ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.646ns = ( 6.646 - 4.000 )
    Source Clock Delay      (SCD):    3.221ns
    Clock Pessimism Removal (CPR):    0.527ns
  Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns
  Clock Net Delay (Source):      1.389ns (routing 0.002ns, distribution 1.387ns)
  Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)

这部分由许多不同的信息组成,所以我将一一介绍。所以从第一行开始:

Slack (MET) :             3.315ns  (required time - arrival time)

这表示已实现 timing constraint (met),还有剩余时间 (slack), 3.315 ns。

Source:                 foo_reg_reg/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            bar_reg__0/D
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})

这些行说明检查了哪个 data path 。这是由该 path ( Source 和 Destination)的开始位置和结束位置定义的。 data path 起始于 foo_reg_reg/C,也就是 @foo_reg的 clock input 。这个 path 结束于 bar_reg__0/D的 data input 。

还有就是提到了“clk”,描述的是它的 waveform 。请注意,“clk”是指与 create_clock一起赋予 clock 的名称。在此示例中,“clk”也是 clock signal的名称。但是,如果在 timing constraint的“-name”参数中使用了另一个名称,则该名称将出现在 timing report中,而不管 signal的名称如何。在这个 timing report的例子中,所有提到“clk”的地方都是如此。

Path Group:             clk

这里的 Path Group 是“clk”,说明之所以考察这个 path 是同名的 timing constraint 。

Path Type:              Setup (Max at Slow Process Corner)

Path Type 是 Setup。这意味着检查了 setup time 要求。 “Max at Slow Process Corner”表示最大 delays 用于 data path 的计算(第一次计算)。 Corner 在本文中的含义解释如下。

Requirement:            4.000ns  (clk rise@4.000ns - clk rise@0.000ns)

回想一下,上面描述的两个理论实验中的每一个都启动了一个假想的秒表。 “Requirement”是秒表启动时的时差。在这种情况下, timing constraint需要 clock period ,即 4 ns。

Data Path Delay:        0.669ns  (logic 0.382ns (57.100%)  route 0.287ns (42.900%))

Data Path Delay 是第一次计算横线后所有 delays 的总和(即 data path的 delays )。

在这一行中, delay 也分别显示为 logic 和 route。这显示了在 logic elements 上花费了多少时间,在这些 logic elements之间的电线上花费了多少时间。一般的经验法则是 delay 的大约 60% 应该在 logic上,其余的在 routing上。因此,本例中的 path 显示正常情况。

如果 routing的 delay 所占比例明显更大,则可能表明存在问题,特别是如果 path 未能达到 timing constraint。下一页在讨论 thold分析的部分对此有更多介绍。

Logic Levels:           1  (LUT1=1)

data path 由单个 LUT组成,因此 logic levels 的数量为 1。

Clock Path Skew:        -0.048ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.646ns = ( 6.646 - 4.000 )
    Source Clock Delay      (SCD):    3.221ns
    Clock Pessimism Removal (CPR):    0.527ns

Clock Path Skew 是同一个 clock edge 到达两个 flip-flops的时间差。这是计算得出的最坏情况,其中包括在一个 clock path中使用最大的 delays ,在另一个 clock path中使用最小的 delays 。请参阅下面名为“Clock pessimism removal”的部分,其中解释了这些行背后的算法。

Clock Uncertainty:      0.035ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.000ns
    Discrete Jitter          (DJ):    0.000ns
    Phase Error              (PE):    0.000ns

请参阅下面名为“Clock uncertainty”的部分。这些行显示了 clock uncertainty 的计算方式。这个计算的结果, 0.035 ns,是不切实际的乐观。发生这种情况是因为在 timing constraint中没有指定 jitter ,因此工具假定 jitter 为零。除此之外,直接使用外部 clock (即 FPGA内部没有 PLL ),所以几乎没有 jitter 的来源可以解释。

尽管在 timing constraint中不指定外部 clock的 jitter 是错误的,但通常都是这样做的。这很少是问题的根源,因为与 timing 计算中考虑的其他因素相比, jitter 通常较小。

Clock Net Delay (Source):      1.389ns (routing 0.002ns, distribution 1.387ns)
  Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)

这些是 clock signal 本身的 delays ,从 clock buffer 的 output 到 flip-flops的 clock inputs。在这个例子中,没有太多信息可以从这些数字中获取。

Multi-corner timing analysis

所有 logic elements 的 delay 取决于一些未知参数,例如温度和 supply voltage。此外,术语“process”用于指代 FPGA生产过程中的错误。尽管每个 FPGA 都经过测试以确保它符合 datasheet,但每个 logic element的行为仍然存在一些不确定性。

FPGA 工具在几个极端场景中为每个 path 执行 timing analysis ,称为“corners”。例如,一种情况可以是允许的最低温度,结合最快的 process (即当 FPGA 恰好是用低 delays制造的)。第二种情况可能是最高温度与最快的 process相结合。第三和第四种情况使用最慢的 process重复此操作。

所以在这个例子中, timing analysis 是针对两个参数的极端条件进行的: 温度和 process。这称为 four-corner timing analysis。但这只是执行 multi-corner timing analysis的众多可能性之一。每个 FPGA 工具都以不同的方式执行 timing analysis 。

但无论工具选择检查哪个 corners ,最坏的情况始终被认为是 timing analysis的结果。换句话说,这些工具会为每个 corner计算 slack ,并且计算的是最低的 slack 。

这些工具经过编程,可以为每个 FPGA执行足够的 multi-corner timing analysis ,因此无需深入了解该主题。但是在读取 timing report时,重要的是要检查它是否与单个 corner相关,或者它是否是所有 corners 的汇总(即最坏情况)。存在混淆的可能性,尤其是 Quartus

接下来讨论Clock pessimism removal 和 Clock uncertainty 。这些都是比较高级的话题。如果您对 timing 计算的更详细信息不感兴趣,可以跳到本系列的下一页

Clock pessimism removal

由于两个 flip-flops 在同一个 slice上的巧合,因此可以比较 clock path delays 的计算(即 clock edge 到达 slice的时间)。第二次计算,这次是 2.646 ns,因为计算从 4 ns 开始,到 6.646 ns结束,所以 6.646 − 4 = 2.646 ns。在前面的计算中,结果是 3.221 ns。 0.575 ns的这个区别。

造成这种差异的原因是第一次计算使用了最大的 delays ,第二次计算使用了最小的 delays 。最小的 delays 和最大的 delays 之间的差异代表了一个事实,即由于制造过程中的自然误差, delays 并不准确。因此,如果 clock path 到第一个 flip-flop 与 clock path 到第二个 flip-flop完全不同,则必须考虑最坏的情况。这种最坏的情况是第一个 path 的所有 delays 都是允许的最大值,而第二个 path 的所有 delays 都是允许的最小值。这就是所谓的 clock pessimism

请注意,这与温度或一个物理 FPGA 与另一个物理 FPGA 之间的差异无关: 两种计算都是针对相同的温度和制造过程进行的。这种差异是因为 segment 中的每个 delay 都有一个符合 FPGA规格的 tolerance 。

但是,当两个 paths中的 clock path 相同时,为什么 clock pessimism 是计算的一部分?答案是这样做是错误的。这就是为什么在 Destination Clock Path中有一行标题为“clock pessimism”的原因。此行将 0.527 ns 添加到 delay 以补偿此错误。标题实际上应该是“clock pessimism removal”(CPR)。

因此, clock pessimism removal 背后的想法是消除 clock path 的最小 delay 和最大 delay 之间不必要的差异,这些差异在两种计算中都是相同的。该工具比较了两个计算的 clock paths ,并找到了两个 paths共有的 segment 。 delays (在共享的 segment中)中所有差异的总和是应该删除的 clock pessimism 。

如上所述, clock paths 的区别在于 0.575 ns。但是应用的 clock pessimism 只是 0.527 ns。因此 0.048 ns的减少幅度较小。原因是在 slice 内部有一个 clock path 的小 segment ,这对两种计算都不常见: slice 内部的一根电线连接到第一个 flip-flop ,第二根电线连接到第二个 flip-flop。这两条线的 delays 可以不同。

Clock uncertainty

在 timing 计算中, 0.035 ns 从 clock path的计算中减去。这使得 timing 计算更加严格。

Clock uncertainty 解释了每两个 clock edges之间的随机时间。这种随机性称为 clock jitter,是各种噪声源和电子设备随机行为的结果。

从计算中减少 0.035 ns 表示即使 clock period 在 timing constraint (create_clock) 中定义为 4 ns ,但实际上这个 clock period 是随机的。因此,两个 clock edges 之间的时间可以更短。短了多少?在此计算中,假设两个 clock edges 之间的时间永远不会小于 3.965 ns (4−0.035 = 3.965 ns)。

这个假设是否成立?这是一个很难回答的问题,因为 clock jitter 的估计是一个复杂的主题,远远超出了关于 timing constraints的讨论范围。尽管如此,还是建议进一步研究这个主题,因为 clock jitter 可能是 logic design中各种问题的根源,而与 timing constraints无关。


关于 clock period constraint的两页中的第一页到此结束。下一页还有更多内容需要学习...

此页面由英文自动翻译。 如果有不清楚的地方,请参考原始页面
Copyright © 2021-2024. All rights reserved. (6f913017)