本页属于有关时序（timing）的一系列页面。前面的页面解释了时序计算背后的理论,讨论了时钟周期约束（clock period constraint）,展示了时序收敛（timing closure）的原理,并介绍了几个重要的 Tcl 命令。本页解释了如何为特定的路径（paths）定义时序约束（timing constraints）。
介绍
编写时序约束的目标是它们应该简短、简洁且易于理解。这减少了混淆和错误的风险。如果可能， FPGA内部路径的时序约束应该只包含两种类型： 时钟周期约束（例如 create_clock）和 clock group 约束（例如set_clock_groups ）。
但通常，特定的路径需要特定的规则。这些特定规则称为 Timing Exceptions。顾名思义，这些时序约束主要用于覆盖现有的时序约束。它们还可以用于指定路径的时序要求，否则路径将没有任何此类要求。
SDC 语法中用于这些目的的命令主要有这些:
- set_false_path： 通知工具不应在选定的路径上强制执行任何时序要求。
- set_max_delay： 定义执行 tsetup的要求。
- set_min_delay： 定义执行 thold的要求。
- set_multicycle_path： 放宽由时钟使能信号（clock enable signal）控制的逻辑的要求。
使用不同语法的工具可能具有类似的命令。
这些命令的 arguments 定义(除其他外)哪条路径（paths）应受到影响。这将在下面解释。
在其他页面上讨论了两个相关主题：
- I/O 时序约束有单独的页面。因此,下面的讨论仅限于使用这些命令和内部路径(即路径从逻辑阵列（logic fabric）中的时序逻辑元件（sequential logic element）穿梭而过)。
- set_multicycle_path 在不同的单独页面上讨论。
False Paths
false path是工具忽略的路径，因为时序约束请求它。换句话说，这些工具故意不在 false path上强制执行任何时序要求，因为这是我们告诉他们要做的。
这不应与unconstrained paths混淆： 这些是路径，工具没有任何时序约束。就像 false paths一样，这些工具不会对这些路径强制执行任何时序要求，但原因不同： 缺乏执行不是一种选择，但工具不知道应用什么要求。
FPGA 设计中不应该有 unconstrained paths 。也就是说，我们通常希望工具忽略路径。这些路径应该凭借时序约束标记为 false path 。理由： 当我们读取时序报告（timing report）时，我们应该总是看到 unconstrained paths 的数字为零。如果这个数字不为零，我们应该寻找错误。如果我们习惯于接受 unconstrained paths的非零数字，就更容易忽略时序约束的问题。
所以声明 false paths可能有两个原因：
- 否则，当工具会在路径上强制执行时序要求时， false path 会告诉工具忽略路径。
- 当没有时序约束时,路径可用。在这种情况下, false path 的作用只是保持 unconstrained paths 的数量为零。
实际上,这两种情况都无所谓。如果路径上不需要时序要求（timing requirements）,则应将其声明为 false path。
将 set_false_path 与跨时钟域（clock domain crossings）联系起来使用是一个常见的错误。稍后将更详细地讨论该主题。事实上，除了 I/O 端口之外，使用 set_false_path是正确的情况并不多。
为 set_false_path选择路径
有很多方法可以选择命令适用于哪条路径。尽管可能性范围很广,但路径的选择通常通过两 arguments来完成: -from 和 -to。例如：
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
在此示例中, set_false_path 命令应用于路径,从 @source 寄存器开始并结束于 @dest 寄存器。
请注意, get_cells 提供 -from 和 -to ,对象（objects）代表逻辑单元（logic elements）。上一页讨论过的其他命令也可以使用: get_pins、 get_nets、 get_ports 和 get_clocks。但是,每个 FPGA 工具都有自己的规则,规定哪些内容可以与 -from 和 -to一起使用。
请注意,这些工具可能不会像人们自然期望的那样解释对对象的引用。这些工具还可能忽略部分或全部对象而不发出警告。事实上,如果 get_* 命令没有找到对象(例如由于 search pattern中的错误),则 timing exception中不会包含路径。即使这种情况也可能发生而不发出警告。
因此,使用时序报告来验证 timing exceptions 是否按预期应用非常重要。这意味着正确的路径受到影响,并且时序分析（timing analysis）实现了其准确的目的(不强制执行时序要求)。
选择路径还有一个有用的 argument ： -through。顾名思义，这 argument 选择路径，经过特定的逻辑单元。
值得花时间阅读官方文档,以便了解所有功能。例如,也可以将命令的效果限制为仅对上升沿（rising clock edges）或下降沿（falling clock edges）进行分析。另一种可能性是将命令限制为仅对 tsetup 或仅对 thold进行分析。
set_false_path 命令要求 -from、 -to 或 -through 中至少有一个作为 argument (或具有类似含义的不同 argument )。当有多 argument时, timing exception 仅适用于满足所有 arguments条件的路径。
set_false_path的危险
false paths 的问题是很容易出错。特别是，存在包含比预期更多的路径的风险。出现这种情况时，有时序逻辑元件可能无法正常运行： 我们错误地期望这些工具保证满足 tsu 和 thold的要求。但实际上,这些工具的行为就像路径到这些时序逻辑元件是 false paths一样。因此,这些工具不会为它们制作任何时序分析。这是一种危险的情况,因为当工具说时序约束已实现时,它会造成一种一切都正常的假象。但实际上,触发器（flip-flops）和其他时序逻辑元件暴露在时序违反（timing violations）下而没有任何保护。
更糟糕的是，如果将路径声明为 false path，则此声明通常具有最高优先级。因此，如果路径被意外声明为 false path，这可能会否决其他要求相反的时序约束。即使 set_false_path 出现在另一个时序约束（timing constraint）之前，这通常也是如此。所以 set_false_path 被解释为“这些是 false paths，不管我之前需要什么或以后需要什么”。
set_min_delay 和 set_max_delay
我首先讨论了 false paths,它消除了一组选定的路径中的时序要求。通常,需要指定时序要求,而不是取消它们。这是通过 set_min_delay 和 set_max_delay完成的。例如,考虑这 Verilog 代码:
reg x, y;
always @(posedge clk)
y <= x;
还有时序约束：
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 的简短解释是它类似于时钟周期约束(create_clock),仅适用于特定的路径。
回想一下,当定义时钟周期约束时,工具会自动强制执行必要的时序要求: 相关路径的最大时延（delays）受到限制以满足 tsetup 要求。同样，最小的时延代表 thold受到限制。
在上面的例子中, set_max_delay 命令中出现的值是 3。这相当于 create_clock 命令等于时钟周期（clock period）,等于 3 ns。但 set_max_delay的影响仅限于特定的路径组。这就是区别。
关于 set_min_delay，它有点复杂，所以在下面详细介绍。
请注意, set_max_delay 命令的名称具有误导性: 这个命令并不直接定义路径本身的最大时延。受影响的路径的时延并不像上例中那样通过命令限制 3 ns 。 3 ns 值用作时钟边沿（clock edges）之间允许的时间差。并且这个时间差不是在同步逻辑单元（synchronous elements）的时钟输入处测量的,而是在这些时钟的原点处测量的。这意味着锁相环（PLLs）、时钟缓冲器（clock buffers）和时钟布线（clock routing）的时延都包含在计算中: 与时钟周期约束类似，时序分析也考虑到了时钟时延（clock delays）。
-from、 -to、 -through 等 arguments 的含义与 set_false_path相同。但总的来说， set_min_delay 和 set_max_delay 是作为时钟周期约束的调整。据此，通常假设路径的两边都有时序逻辑元件。因此， -from 和 -to 应该代表同步逻辑单元。有很多方法可以引用这些： 代表同步逻辑单元本身的 cell 对象、时钟对象（clock object）等等。
关于 set_min_delay，还有一个类似的故事： 时钟周期约束的另一个结果是工具必须满足 thold 要求。为此，工具在相同时钟或related 时钟之间的所有路径上强制执行最小时延。如果路径的时序计算仅是 create_clock 的结果（两边具有相同的时钟），则这相当于值为零的 set_min_delay 。这反映了相同的时钟边沿到达两个时序逻辑元件（sequential elements）的想法。但是，这并不意味着这个时钟边沿（clock edge）与这些时序逻辑元件同时到达。相反，每个时序逻辑元件的时钟边沿在时钟的原点同时开始。在计算中考虑了从每个时钟的原点到时序逻辑元件的时延（类似于 tsetup的计算方式）。
set_min_delay 允许调整到达第二个时序逻辑元件的时钟边沿的时间。例如,上面的命令使得这个时钟边沿比第二个触发器（flip-flop）的 1 ns 晚到达。这使得 thold 的时序要求更难满足: 请参阅下面的时序报告示例。
使用 set_min_delay 和 set_max_delay可能有两个原因：
- 当工具强制执行的时序要求不足以满足一组特定的路径时。例如,当时序要求需要更严格地遵守从 metastability guard开始的路径时。
- 路径没有相关的时序约束时。如果您想为此目的使用 set_max_delay ，请问问自己是否不需要时钟周期约束或multi-cycle 路径 。
当使用这两个命令时,一定要仔细检查时序报告和路径的时序分析。特别要注意时钟路径（clock path）在计算中是如何发挥作用的。
本页底部有时序报告的例子，展示了 set_min_delay 和 set_max_delay的结果。
时延控制更精准
set_max_delay 和 set_min_delay 提供的控制级别并不明显优于时钟周期约束（如目前所示）。但是如果我们不想让时钟路径时延（clock path delay）干扰我们对时延的定义呢？如果我们想控制路径的某个段的时延呢？
有些 FPGA 工具无法满足这些需求。例如, Quartus 就不提供这种可能性(据我所知)。另一方面, Vivado具有一些功能,我将简要讨论一下。
其中一项功能是 datapath_only 选项： 有时需要使用 set_max_delay ，以便时序计算不包括时钟路径。比如路径介于 unrelated clocks之间，考虑时钟路径就没有意义了。
当使用 datapath_only 时,时序的计算方式是假设两个同步逻辑单元（synchronous elements）中的时钟路径时延为零。因此,计算仅包括路径中的逻辑单元中的时延。这些时延的总和必须小于 set_max_delay 命令中给出的数字(参见下面的时序报告示例)。
因此,当 set_max_delay 与 datapath_only一起使用时,其含义更接近于 command's 名称所暗示的含义。但请注意,路径仍必须以同步逻辑单元开始和结束。
此外， datapath_only 有一些特点： 如果使用,工具将不会强制执行与相关路径的 thold 有关的任何时序要求。换句话说,工具的行为就像存在一个仅应用于 thold 场景的 false path 约束。即使为相关路径添加了 set_min_delay 命令,也会忽略此命令。目前尚不清楚为什么 Vivado 拒绝在受 datapath_only影响的路径上强制执行最小时延。
datapath_only 在任何场景下都不能作为 argument 到 set_min_delay 来使用。
误导性特征
正如本节标题所暗示的，这些是一些不太可能有任何好处的可能性。请随意跳到下一节。
Vivado 允许更高级别的控制： 可以对路径的特定段的时延实施限制。例如，如果将不是时序逻辑元件的逻辑单元与 -from 和 -to一起使用，会发生什么情况？引脚和网络（nets）怎么样？ set_min_delay 和 set_max_delay 会做什么？
当然,这取决于使用哪种 FPGA 工具。工具可能会默默忽略此类约束（constraints）,因为没有路径符合要求。但 Vivado 不会忽略此类约束,尽管结果并非人们自然期望的那样: Vivado 将此情况视为“path segmentation”并发出 critical warning 作为响应。在大多数情况下，不值得使用此功能带来的并发症。有关更多信息，请参阅文档。
这是另一个可能会产生误导的特征： Quartus 有一个称为 set_net_delay的命令。它允许在设计中的不同逻辑单元之间定义最小和最大时延。但是,看起来工具并没有尝试在实现（implementation）期间实现这些时序要求。相反,可以使用“report_net_delay”(或使用图形用户界面（GUI）)生成报告（report）。因此,如果满足使用 set_net_delay 定义的条件,则可以从此报告推断出来。因此, set_net_delay 可用于获取信息,但它作为时序约束则无用。换句话说: set_max_delay 和 set_min_delay 与时序约束一样有效，但 set_net_delay 则不然。
总之，它并没有比使用 set_max_delay 和 set_min_delay的简单方法好多少。看起来，唯一有趣的功能是 Vivado的 datapath_only。
时序约束的优先顺序
复杂时序约束的主要问题是,通常有路径受多个约束（constraint）影响。这些约束通常与时序要求相矛盾,与这些路径相矛盾。那么哪个约束会胜出呢?
每个 FPGA 工具都有自己的规则来解决此类冲突。它通常主要取决于约束的类型。其他因素也可能发挥作用,特别是路径的选择特异性。
对于基于 SDC的时序约束,优先级取决于约束的类型。例如, Vivado 根据此优先级顺序解决冲突。命令的优先级从高到低依次为:
- set_clock_groups （ related 时钟和 unrelated 时钟组）
- set_false_path (false path)
- set_min_delay 和 set_max_delay （minimum delays 和 maximum delays）
- set_multicycle_path (multicycle 路径)
- create_clock (时钟周期)
请注意,前两个命令(set_clock_groups 和 set_false_path)创建了 false paths,它们具有最高优先级。因此,验证路径是否受到这些命令的错误影响尤为重要。这样的错误会默默关闭相关路径上所有时序要求的执行。
当同一个命令多次用于同一条路径时,最具体的命令获胜。例如,如果一个命令有“-from”和“-to”,但第二个命令只有“-from”,则第一个命令获胜。另一个示例: 如果一个命令根据逻辑单元定义路径(例如使用 get_cells),并且第二个命令根据时钟定义路径(使用 get_clocks),则第一个命令获胜。
如果两个命令非常相似,优先级没有差异,则出现的顺序可以解决冲突: 最后的命令获胜。
Quartus 和其他基于 SDC的工具使用类似的优先规则。
但无论您使用哪种工具，最好避免时序约束之间的任何矛盾（否决 create_clock除外）。复杂的时序约束是破坏性错误滋生的地方。
使用一些 FPGA 工具,可以解决优先级规则: 通过使用 -reset_path 属性,使用此属性（attribute）的命令将覆盖其适用的所有路径上的前一 timing exceptions 。例如:
set_max_delay -reset_path -from [get_cells source_reg] 2
结论
我在本页开始时说时序约束应该简短、简洁。通过添加 timing exceptions，时序约束不仅变得更长，而且更加复杂和难以理解。所以必要时使用 timing exceptions ，但要小心编写并保持整洁。
尝试以反映其目的并表达其背后想法的方式编写 timing exception 命令。 FPGA 工具通常提供用于创建时序约束的图形用户界面 wizards （GUI wizards）。它们可以作为起点。但在仔细考虑之前,不要使用由 wizard 创建的时序约束。即使这个约束在创建时是正确的,当逻辑设计进化并添加新的逻辑时,它是否还会继续忠实地工作?
对于受 timing exception影响的路径，请始终阅读时序报告。如果一条路径不止一个时序约束，这个就更重要了。还为可能具有不正确的时序要求的路径创建特定的时序报告。
记住： 创建和阅读时序报告并不是浪费时间。无论您多么仔细地阅读文档（这总是一个好主意），总会有出错的机会。特别是， false paths 可能出现在最意想不到的地方。
奖金： 时序报告的例子
为了帮助理解 set_min_delay 和 set_max_delay，这些是用 Vivado创建的几个时序报告（timing reports）。
回想一下上面提到的这些报告背后的 Verilog 代码是:
always @(posedge clk)
y <= x;
还有时序约束：
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
请注意，时延的值 (3 ns) 用作第二个触发器的时钟路径的开始时间。换句话说，就好像 3 ns有 period 约束一样。
另请注意，数据路径（data path）中的网络有一个巨大的时延： 2.478 ns。这是 set_min_delay 命令的结果: 为了满足 thold 的要求，工具被迫在这个网络（net）上插入一个长的时延。
说到这里，这是 thold的时序报告：
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
再次注意,时延的值(1 ns)用作第二个触发器的时钟路径的开始时间。当没有 set_min_delay 命令(即只有时钟周期约束)时,这是 0 ns。
数据路径中网络的时延为 1.092 ns。这刚好可以满足 thold 的要求。为什么之前是 2.478 ns ？因为 tsetup 的最坏情况计算是针对“Max at Slow Process Corner”完成的。因此 2.478 ns 是相关网络可能最长的时延，而 1.092 ns 是可能最短的时延（“Min at Fast Process Corner”）。有关更多信息，请参阅有关 Multi-corner 时序分析的讨论。
第三个例子演示的是 datapath_only，所以约束是：
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
请注意，此时序报告的结构与之前相同，但已删除与时钟路径相关的所有内容。
网络的时延很小，因为工具没有理由插入长时延： 没有 thold 要求。
我没有显示 thold的时序报告,因为没有时序要求(最小的时延被视为 false path)。
关于 timing exceptions的一般性讨论到此结束。下一页继续介绍跨时钟域所必需的 timing exceptions 。