01signal.com

Timing exceptions

此页面属于关于 timing的一系列页面。前几页解释了 timing 计算背后的理论,讨论了 clock period constraint,展示了 timing closure的原理,并介绍了一些重要的 Tcl 命令。本页解释了如何为特定的 paths定义 timing constraints 。

介绍

编写 timing constraints 的目标是它们应该简短、简洁且易于理解。这减少了混淆和错误的风险。如果可能, FPGA内部 paths 的 timing constraints 应该只包含两种类型: clock period constraints (例如 create_clock)和 clock group constraints (例如set_clock_groups )。

但通常,特定的 paths 需要特定的规则。这些特定规则称为 Timing Exceptions。顾名思义,这些 timing constraints 主要用于覆盖现有的 timing constraints。它们还可以用于指定 paths 的 timing 要求,否则 paths 将没有任何此类要求。

SDC 语法中用于这些目的的命令主要是:

使用不同语法的工具可能具有相似的命令。

这些命令的 arguments 定义(除其他外)应该影响哪个 paths 。这在下面解释。

在其他页面上讨论了两个相关主题:

False Paths

false path是工具忽略的 path ,因为 timing constraint 请求它。换句话说,这些工具故意不在 false path上强制执行任何 timing 要求,因为这是我们告诉他们要做的。

这不应与unconstrained paths混淆: 这些是 paths ,工具没有任何 timing constraint 。就像 false paths一样,这些工具不会对这些 paths强制执行任何 timing 要求,但原因不同: 缺乏执行不是一种选择,但工具不知道应用什么要求。

FPGA design中不应该有 unconstrained paths 。也就是说,我们通常希望工具忽略 paths 。这些 paths 应该凭借 timing constraints标记为 false path 。理由: 当我们读取 timing report时,我们应该总是看到 unconstrained paths 的数字为零。如果这个数字不为零,我们应该寻找错误。如果我们习惯于接受 unconstrained paths的非零数字,就更容易忽略 timing constraints的问题。

所以声明 false paths可能有两个原因:

实际上,这些场景中的哪一个生效并不重要。如果 path不需要 timing 要求,则应将其声明为 false path。

将 set_false_path 与 clock domain crossings联系起来使用是一个常见的错误。稍后将更详细地讨论该主题。事实上,除了 I/O ports之外,使用 set_false_path是正确的情况并不多。

为 set_false_path选择 paths

有多种方法可以选择命令适用于哪个 paths 。尽管有多种可能性,但 paths 的选择通常是通过两个 arguments完成的: -from 和 -to。例如:

set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]

在此示例中, set_false_path 命令应用于 path ,它从名称为 @source 的 register 开始,到名称为 @dest的 register 结束。

请注意, get_cells 提供 -from 和 -to , objects 代表 logic elements。也可以使用上一页中讨论的其他命令: get_pins、 get_nets、 get_ports 和 get_clocks。但是,关于 -from 和 -to可以接受的使用,每个 FPGA 工具都有自己的规则。

请注意,这些工具可能不会像人们自然期望的那样解释对 objects 的引用。这些工具也可能忽略部分或全部 objects ,而不发布 warning。事实上,如果 get_* 命令没有找到 objects (例如,由于 search pattern中的错误),则 timing exception中不包含 path 。即使没有 warning也可能发生这种情况。

因此,使用 timing report 验证 timing exceptions 是否按预期应用非常重要。这意味着正确的 paths 受到影响,并且 timing 计算实现其准确目的(不强制执行 timing 要求)。

选择 paths还有一个有用的 argument : -through。顾名思义,这个 argument 选择 paths ,经过特定的 logic elements。

值得花时间阅读官方文档以了解所有功能。例如,也可以将命令的效果限制为仅 rising clock edges 或 falling clock edges。另一种可能性是将命令限制为仅分析 tsetup 或仅分析 thold

set_false_path 命令需要 -from、 -to 或 -through 中的至少一个作为 argument (或具有相似含义的不同 argument )。当有多个 argument时, timing exception 只适用于满足所有 arguments条件的 paths 。

set_false_path的危险

false paths 的问题是很容易出错。特别是,存在包含比预期更多的 paths 的风险。出现这种情况时,有 sequential elements 可能无法正常运行: 我们错误地认为这些工具可以保证它们对 tsu 和 thold的要求。但实际上,这些工具将 paths 到这些 sequential elements 视为 false paths。因此,这些工具不会为它们进行任何 timing 计算。这是一个危险的情况,因为当工具显示 timing constraints 已实现时,它会产生一切正常的错觉。但实际上有 flip-flops 和其他 sequential elements 在没有任何保护的情况下暴露于 timing 违规。

更糟糕的是,如果将 path 声明为 false path,则此声明通常具有最高优先级。因此,如果 path 被意外声明为 false path,这可能会否决其他要求相反的 timing constraints 。即使 set_false_path 出现在另一个 timing constraint之前,这通常也是如此。所以 set_false_path 被解释为“这些是 false paths,不管我之前需要什么或以后需要什么”。

set_min_delay 和 set_max_delay

我从讨论 false paths开始,它消除了一组选定的 paths的 timing 要求。通常,需要指定 timing 要求,而不是取消它们。这是通过 set_min_delay 和 set_max_delay完成的。例如,考虑这个 Verilog 代码:

reg x, y;

always @(posedge clk)
  y <= x;

还有 timing constraints:

set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3
set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1

那么这些命令的含义是什么?让我们从 set_max_delay开始。这个 timing exception 的简短解释是它类似于 clock period constraint (create_clock),仅适用于特定的 paths 。

回想一下,定义 clock period constraint 时,工具会自动强制执行必要的 timing 要求: 相关 paths 的最大 delays 受到限制以满足 tsetup 要求。同样,最小的 delays 代表 thold受到限制。

在上面的示例中, set_max_delay 命令中出现的值是 3。这等效于 create_clock 命令用于等于 3 ns的 clock period 。但 set_max_delay的影响力仅限于特定的 paths群体。这就是区别。

关于 set_min_delay,它有点复杂,所以在下面详细介绍。

请注意, set_max_delay 命令的名称具有误导性: 此命令不直接定义 path 本身的最大 delay 。受影响的 paths 的 delay 并没有被上面例子中的命令限制为 3 ns 。 3 ns 值用作 clock edges之间允许的时间差。而这个时间差并不是在 synchronous elements的 clock inputs上测得的,而是在这些 clocks的原点测得的。这意味着 PLLs、 clock buffers 和 clock routing 中的 delays 都包含在计算中: 与 clock period constraint类似, timing analysis也考虑到了 clock delays 。

-from、 -to、 -through 等 arguments 的含义与 set_false_path相同。但总的来说, set_min_delay 和 set_max_delay 是作为 clock period constraint的调整。据此,通常假设 path的两边都有 sequential elements 。因此, -from 和 -to 应该代表 synchronous elements。有很多方法可以引用这些: 代表 synchronous element 本身的 cell object 、 clock object等等。

关于 set_min_delay,还有一个类似的故事: clock period constraint 的另一个结果是工具必须满足 thold 要求。为此,工具在相同 clock 或related clocks之间的所有 paths 上强制执行最小 delays 。如果 path 的 timing 计算仅是 create_clock 的结果(两边具有相同的 clock ),则这相当于值为零的 set_min_delay 。这反映了相同的 clock edge 到达两个 sequential elements的想法。但是,这并不意味着这个 clock edge 与这些 sequential elements同时到达。相反,每个 sequential element 的 clock edges 在 clock的原点同时开始。在计算中考虑了从每个 clock的原点到 sequential element 的 delay (类似于 tsetup的计算方式)。

set_min_delay 允许调整到达第二个 sequential element的 clock edge 的时间。例如,上面的命令使这个 clock edge 稍后通过 1 ns 到达第二个 flip-flop。这使得 thold 的 timing 要求更难满足: 请参阅下面的 timing report 示例。

使用 set_min_delay 和 set_max_delay可能有两个原因:

使用这两个命令时,一定要在 timing reports中仔细检查 paths 的 timing 计算。尤其要注意 clock path 在计算中是如何发挥作用的。

本页底部有 timing reports 的例子,展示了 set_min_delay 和 set_max_delay的结果。

delay控制更精准

set_max_delay 和 set_min_delay 提供的控制级别并不明显优于 clock period constraint (如目前所示)。但是如果我们不想让 clock path delay 干扰我们对 delay的定义呢?如果我们想控制 path的某个 segment 的 delay 呢?

一些 FPGA 工具不为这些需求提供任何解决方案。例如, Quartus 不提供这种可能性(据我所知)。另一方面, Vivado有一些特性,我将简要讨论一下。

其中一项功能是 datapath_only 选项: 有时需要使用 set_max_delay ,以便 timing 计算不包括 clock paths。比如 path 介于 unrelated clocks之间,考虑 clock paths 就没有意义了。

当使用 datapath_only 时, timing 的计算就像两个 synchronous elements 的 clock path delay 都为零一样。因此,计算仅包含 path的 logic elements 的 delays 。这些 delays 的总和必须小于 set_max_delay 命令中给出的数字(参见下面的 timing report 示例)。

所以当 set_max_delay 与 datapath_only一起使用时,其含义更接近于该命令的名称所暗示的含义。但请注意, path 必须仍以 synchronous element开始和结束。

此外, datapath_only 有一些特点: 如果使用它,这些工具将不会对相关 paths的 thold 执行任何 timing 要求。换句话说,这些工具的行为就好像有一个仅应用于 thold 场景的 false path constraint 。即使为相关的 paths添加了 set_min_delay 命令,该命令也会被忽略。目前尚不清楚为什么 Vivado 拒绝在受 datapath_only影响的 paths 上执行最小的 delay 。

datapath_only 在任何场景下都不能作为 argument 到 set_min_delay 来使用。

误导性特征

正如本节标题所暗示的,这些是一些不太可能有任何好处的可能性。请随意跳到下一节。

Vivado 允许更高级别的控制: 可以对 path的特定 segment 的 delay 实施限制。例如,如果将不是 sequential elements 的 logic elements 与 -from 和 -to一起使用,会发生什么情况? pins 和 nets怎么样? set_min_delay 和 set_max_delay 会做什么?

当然,这取决于使用哪种 FPGA 工具。这些工具可能会默默地忽略此类 constraints,因为没有 paths 符合要求。但是 Vivado 并没有忽略这样的 constraints,尽管结果不是人们自然期望的: Vivado 将此情况视为“path segmentation”并发出 critical warning 作为响应。在大多数情况下,不值得使用此功能带来的并发症。有关更多信息,请参阅文档。

这是另一个可能会产生误导的特征: Quartus 有一个名为 set_net_delay的命令。它允许在 design中的不同 logic elements 之间定义最小和最大 delay 。但是,这些工具似乎并未尝试在 implementation期间实现这些 timing 要求。相反,可以使用“report_net_delay”(或 GUI)生成报告。因此,如果满足使用 set_net_delay 定义的条件,则可以从此报告中推断出。所以 set_net_delay 可以用来获取信息,但是作为 timing constraint就没有用了。换句话说: set_max_delay 和 set_min_delay 与 timing constraints一样有效,但 set_net_delay 则不然。

总之,它并没有比使用 set_max_delay 和 set_min_delay的简单方法好多少。看起来,唯一有趣的功能是 Vivado的 datapath_only。

timing constraints的优先顺序

复杂 timing constraints 的主要问题是经常有 paths 受到不止一个 constraint的影响。这些 constraints 通常对这些 paths具有矛盾的 timing 要求。那么哪个 constraint 赢了呢?

每个 FPGA 工具都有自己的规则来解决此类冲突。它通常主要取决于 constraint的类型。其他因素也可能发挥作用,特别是 paths选择的特殊性。

对于基于 SDC的 timing constraints ,优先级取决于 constraint的类型。例如, Vivado 根据此优先顺序解决冲突。命令从最高优先级到最低优先级列出:

请注意,前两个命令(set_clock_groups 和 set_false_path)创建 false paths,它们具有最高优先级。因此,验证没有 path 受到这些命令的错误影响尤为重要。这样的错误会悄无声息地关闭相关 paths上所有 timing 要求的执行。

当对同一 path多次使用同一命令时,最具体的命令优先。例如,如果一个命令有“-from”和“-to”,但第二个命令只有“-from”,则第一个命令获胜。另一个例子: 如果一个命令定义基于 logic elements 的 paths (例如使用 get_cells),而第二个命令定义基于 clocks 的 paths (使用 get_clocks),则第一个命令获胜。

如果两个命令非常相似以至于优先级没有差异,则出现的顺序可以解决冲突: 最后一个命令获胜。

Quartus 和其他基于 SDC的工具使用类似的优先规则。

但无论您使用哪种工具,最好避免 timing constraints 之间的任何矛盾(否决 create_clock除外)。复杂的 timing constraints 是破坏性错误滋生的地方。

使用一些 FPGA 工具,可以绕过优先级规则: 通过使用 -reset_path 选项,当前命令在它适用的所有 paths 上否决先前的 timing exceptions 。例如:

set_max_delay -reset_path -from [get_cells source_reg] 2

结论

我在本页开始时说 timing constraints 应该简短、简洁。通过添加 timing exceptions, timing constraints 不仅变得更长,而且更加复杂和难以理解。所以必要时使用 timing exceptions ,但要小心编写并保持整洁。

尝试以反映其目的并表达其背后思想的方式编写 timing exception 命令。 FPGA 工具通常提供 GUI wizards 来创建 timing constraints。它们可以作为一个有用的起点。但是,在仔细考虑之前,不要使用由 wizard 创建的 timing constraint 。即使这个 constraint 在创建时是正确的,即使 logic design 进化并添加了新的 logic ,它还会继续忠实地工作吗?

对于受 timing exception影响的 paths ,请始终阅读 timing reports 。如果一个 path不止一个 timing constraints ,这个就更重要了。还为可能具有不正确的 timing 要求的 paths 创建特定的 timing reports 。

记住: 创建和阅读 timing reports 并不是浪费时间。无论您多么仔细地阅读文档(这总是一个好主意),总会有出错的机会。特别是, false paths 可能出现在最意想不到的地方。

奖金: timing reports的例子

为了帮助理解 set_min_delay 和 set_max_delay,这些是用 Vivado创建的几个 timing reports 。

从上面回想一下,这些报告背后的 Verilog 代码是:

always @(posedge clk)
  y <= x;

还有 timing constraints:

set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3
set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1

tsetup的报告:

Slack (MET) :             0.360ns  (required time - arrival time)
  Source:                 x_reg/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            y_reg/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:            3.000ns  (MaxDelay Path 3.000ns)
  Data Path Delay:        2.617ns  (logic 0.139ns (5.311%)  route 2.478ns (94.689%))
  Logic Levels:           0
  Clock Path Skew:        -0.053ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.644ns
    Source Clock Delay      (SCD):    3.224ns
    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.392ns (routing 0.002ns, distribution 1.390ns)
  Clock Net Delay (Destination): 1.216ns (routing 0.002ns, distribution 1.214ns)
  Timing Exception:       MaxDelay Path 3.000ns

    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=4, routed)           1.392     3.224    clk_IBUF_BUFG
    SLICE_X49Y57         FDRE                                         r  x_reg/C
  -------------------------------------------------------------------    -------------------
    SLICE_X49Y57         FDRE (Prop_DFF_SLICEL_C_Q)
                                                      0.139     3.363 r  x_reg/Q
                         net (fo=2, routed)           2.478     5.841    x
    SLICE_X49Y57         FDRE                                         r  y_reg/D
  -------------------------------------------------------------------    -------------------

                         max delay                    3.000     3.000
    AG12                                              0.000     3.000 r  clk (IN)
                         net (fo=0)                   0.000     3.000    clk_IBUF_inst/I
    AG12                 INBUF (Prop_INBUF_HRIO_PAD_O)
                                                      0.515     3.515 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.066     3.581    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.034     3.615 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.722     4.337    clk_IBUF
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.091     4.428 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=4, routed)           1.216     5.644    clk_IBUF_BUFG
    SLICE_X49Y57         FDRE                                         r  y_reg/C
                         clock pessimism              0.527     6.171
                         clock uncertainty           -0.035     6.136
    SLICE_X49Y57         FDRE (Setup_EFF2_SLICEL_C_D)
                                                      0.065     6.201    y_reg
  -------------------------------------------------------------------
                         required time                          6.201
                         arrival time                          -5.841
  -------------------------------------------------------------------
                         slack                                  0.360

请注意, delay的值 (3 ns) 用作第二个 flip-flop的 clock path 的开始时间。换句话说,就好像 3 ns有 period constraint 一样。

另请注意, data path 中的 net 有一个巨大的 delay: 2.478 ns。这是 set_min_delay 命令的结果: 为了满足 thold 的要求,工具被迫在这个 net 上插入一个长的 delay 。

说到这里,这是 thold的 timing report :

Slack (MET) :             0.057ns  (arrival time - required time)
  Source:                 x_reg/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            y_reg/D
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Path Group:             clk
  Path Type:              Hold (Min at Fast Process Corner)
  Requirement:            1.000ns  (MinDelay Path 1.000ns)
  Data Path Delay:        1.141ns  (logic 0.049ns (4.294%)  route 1.092ns (95.706%))
  Logic Levels:           0
  Clock Path Skew:        0.029ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    1.684ns
    Source Clock Delay      (SCD):    1.258ns
    Clock Pessimism Removal (CPR):    0.398ns
  Clock Net Delay (Source):      0.502ns (routing 0.002ns, distribution 0.500ns)
  Clock Net Delay (Destination): 0.585ns (routing 0.002ns, distribution 0.583ns)
  Timing Exception:       MinDelay Path 1.000ns

    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.339     0.339 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.025     0.364    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.015     0.379 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.350     0.729    clk_IBUF
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.027     0.756 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=4, routed)           0.502     1.258    clk_IBUF_BUFG
    SLICE_X49Y57         FDRE                                         r  x_reg/C
  -------------------------------------------------------------------    -------------------
    SLICE_X49Y57         FDRE (Prop_DFF_SLICEL_C_Q)
                                                      0.049     1.307 r  x_reg/Q
                         net (fo=2, routed)           1.092     2.399    x
    SLICE_X49Y57         FDRE                                         r  y_reg/D
  -------------------------------------------------------------------    -------------------

                         min delay                    1.000     1.000
    AG12                                              0.000     1.000 r  clk (IN)
                         net (fo=0)                   0.000     1.000    clk_IBUF_inst/I
    AG12                 INBUF (Prop_INBUF_HRIO_PAD_O)
                                                      0.595     1.595 r  clk_IBUF_inst/INBUF_INST/O
                         net (fo=1, routed)           0.042     1.637    clk_IBUF_inst/OUT
    AG12                 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
                                                      0.022     1.659 r  clk_IBUF_inst/IBUFCTRL_INST/O
                         net (fo=1, routed)           0.409     2.068    clk_IBUF
    BUFGCE_X1Y0          BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.031     2.099 r  clk_IBUF_BUFG_inst/O
    X2Y0 (CLOCK_ROOT)    net (fo=4, routed)           0.585     2.684    clk_IBUF_BUFG
    SLICE_X49Y57         FDRE                                         r  y_reg/C
                         clock pessimism             -0.398     2.286
    SLICE_X49Y57         FDRE (Hold_EFF2_SLICEL_C_D)
                                                      0.055     2.341    y_reg
  -------------------------------------------------------------------
                         required time                         -2.341
                         arrival time                           2.399
  -------------------------------------------------------------------
                         slack                                  0.057

再次注意, delay的值 (1 ns) 用作第二个 flip-flop的 clock path 的开始时间。当没有 set_min_delay 命令(即只有一个 clock period constraint)时,这是 0 ns。

data path 中 net 的 delay 为 1.092 ns。这刚好可以满足 thold 的要求。为什么之前是 2.478 ns ?因为 tsetup 的最坏情况计算是针对“Max at Slow Process Corner”完成的。因此 2.478 ns 是相关 net可能最长的 delay ,而 1.092 ns 是可能最短的 delay (“Min at Fast Process Corner”)。有关更多信息,请参阅有关 Multi-corner timing analysis的讨论

第三个例子演示的是 datapath_only,所以 constraint 是:

set_max_delay -datapath_only -from [get_cells x_reg] -to [get_cells y_reg] 3

没有 set_min_delay,因为它无论如何都会被忽略(即使它写在 set_max_delay 命令之后)。

tsetup 的报告现在是:

Slack (MET) :             2.482ns  (required time - arrival time)
  Source:                 x_reg/C
                            (rising edge-triggered cell FDRE clocked by clk  {rise@0.000ns fall@2.000ns period=4.000ns})
  Destination:            y_reg/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:            3.000ns  (MaxDelay Path 3.000ns)
  Data Path Delay:        0.583ns  (logic 0.139ns (23.842%)  route 0.444ns (76.158%))
  Logic Levels:           0
  Timing Exception:       MaxDelay Path 3.000ns -datapath_only

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
    SLICE_X49Y57                                      0.000     0.000 r  x_reg/C
    SLICE_X49Y57         FDRE (Prop_DFF_SLICEL_C_Q)
                                                      0.139     0.139 r  x_reg/Q
                         net (fo=2, routed)           0.444     0.583    x
    SLICE_X49Y57         FDRE                                         r  y_reg/D
  -------------------------------------------------------------------    -------------------

                         max delay                    3.000     3.000
    SLICE_X49Y57         FDRE (Setup_EFF2_SLICEL_C_D)
                                                      0.065     3.065    y_reg
  -------------------------------------------------------------------
                         required time                          3.065
                         arrival time                          -0.583
  -------------------------------------------------------------------
                         slack                                  2.482

请注意,此 timing report 的结构与之前相同,但已删除与 clock paths 相关的所有内容。

net 的 delay 很小,因为工具没有理由插入长 delay: 没有 thold 要求。

而且我没有显示 thold的 timing report ,因为没有 timing 要求(最小的 delay 被视为 false path)。


关于 timing exceptions的一般性讨论到此结束。下一页继续介绍 clock domain crossing所必需的 timing exceptions 。

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