本页属于关于时序的系列文章之一。前面几页解释了时序计算背后的理论,讨论了时钟周期约束,展示了时序收敛(timing closure)的原则,并介绍了一些重要的 Tcl 命令。本页将讲解如何为特定路径(path)定义时序约束(timing constraints)。
引言
编写时序约束的目标是让它们短小、简洁、易于理解。这样可以降低混淆和出错的风险。如有可能,FPGA 内部路径的时序约束应当只由两类组成:时钟周期约束(例如 create_clock)和时钟组约束(例如 set_clock_groups)。
但往往特定路径需要特定规则。这些特定规则称为时序例外(Timing Exceptions)。正如其名称所示,这些时序约束的主要用途是覆盖已有的时序约束。它们也可以用来为原本没有任何时序要求的路径规定时序要求。
在 SDC 语法中,用于这些目的的命令主要有以下几条:
- set_false_path:告诉工具不应在被选中的路径上强制任何时序要求。
- set_max_delay:定义用于强制 tsetup 要求的参数。
- set_min_delay:定义用于强制 thold 要求的参数。
- set_multicycle_path:放宽由时钟使能(clock enable)信号控制的逻辑的时序要求。
使用不同语法的工具通常也有类似的命令。
这些命令的参数(除其他作用外)决定了它们影响哪些路径。下面将对此进行说明。
有两个相关主题在其它页面中讨论:
- I/O 时序约束有专门的一页。因此,这里的讨论仅限于在内部路径中使用这些命令,也就是从逻辑阵列中的时序元件出发、并在逻辑阵列中的时序元件结束的路径。
- set_multicycle_path 在专门的另一页中讨论。
伪路径(False Paths)
伪路径(false path)是工具因某条时序约束的要求而故意忽略的路径。换句话说,工具不会对伪路径强制任何时序要求,因为这是我们明确要求它这样做的。
不要把伪路径与无约束路径(unconstrained paths)混淆:后者是指工具没有任何相关时序约束的路径。与伪路径一样,工具不会对无约束路径强制任何时序要求,但原因不同:这不是刻意选择,而是工具不知道该施加什么要求。
FPGA 设计中不应该存在无约束路径。话虽如此,往往会有一些我们确实希望工具忽略的路径。这些路径应该通过时序约束明确标记为伪路径。理由如下:阅读时序报告时,我们应当始终看到无约束路径的数量为零。如果这个数字不是零,就应当去寻找错误。如果我们习惯了接受非零的无约束路径数量,就更容易忽略时序约束方面的问题。
所以,声明伪路径可能有两种原因:
- 如果不对路径作声明,工具就会对其强制执行时序要求;伪路径告诉工具忽略这条路径。
- 该路径本来就没有任何时序约束。在这种情况下,声明伪路径的目的只是让无约束路径数量保持为零。
从实际效果看,究竟属于上述哪种情况并不重要。凡是没有任何必要施加时序要求的路径,就应声明为伪路径。
把 set_false_path 用于时钟域交叉(clock domain crossing)是一个常见的错误。这个话题在后面会详细讨论。事实上,除了 I/O 端口之外,适合使用 set_false_path 的场景并不多。
为 set_false_path 选择路径
有很多方法可以指定这条命令作用于哪些路径。尽管可能性很多,但路径的选择通常依靠两个参数:-from 和 -to。例如:
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
在这个示例中,set_false_path 命令应用于从 source_reg 到 dest_reg 的路径。
注意,get_cells 为 -from 和 -to 找到的是代表逻辑元件的对象。上一页讨论过的其余命令也可以使用:get_pins、get_nets、get_ports 和 get_clocks。不过,每种 FPGA 工具对哪些对象可与 -from、-to 搭配使用,都有自己的规则。
要知道,工具对对象引用的解释不一定符合你的自然预期。工具也可能在不发出警告的情况下忽略其中某些或全部对象。事实上,如果 get_* 命令没有找到任何对象(例如因为搜索模式写错),时序例外就不会包含任何路径。这种情况甚至也可以完全不发出警告。
因此,务必使用时序报告来验证时序例外确实按预期生效。也就是说,正确的路径受到影响,时序分析也达到了其应有的目的(不强制时序要求)。
还有一个选择路径时有用的参数:-through。顾名思义,这个参数选择经过特定逻辑元件的路径。
值得花时间阅读官方文档,以便了解此命令的全部功能。例如,可以把命令效果限制为只针对时钟上升沿或下降沿,也可以把命令限制为只分析 tsetup 或只分析 thold。
set_false_path 命令至少需要 -from、-to 或 -through 之一作为参数(或某个其它含义类似的参数)。当有多个参数时,时序例外只作用于同时满足所有参数条件的路径。
set_false_path 的危险之处
伪路径的问题在于很容易出错。尤其是存在把比预期更多的路径纳入其中的风险。一旦发生这种情况,某些时序元件就可能工作不正常:我们误以为工具会保证它们的 tsu 和 thold 要求,但实际上,工具会表现得如同到达这些时序元件的路径都是伪路径一样,不会对它们做任何时序分析。这是一种危险的情况,因为当工具声称时序约束已经满足时,它会制造一种“一切正常”的假象。但现实中,有些触发器和其他时序元件正暴露在毫无保护的时序违例之下。
更麻烦的是,如果某条路径被声明为伪路径,这种声明通常具有最高优先级。因此,如果一条路径被意外声明为伪路径,它很可能压制其它要求相反的时序约束。即使 set_false_path 出现在之前,情况也常常如此。所以 set_false_path 实际上是在说:“这些就是伪路径,无论我之前要求过什么,或以后会要求什么。”
set_min_delay 和 set_max_delay
我先讨论了伪路径,因为它们会消除一组被选路径上的时序要求。但更多时候,我们需要的是规定时序要求,而不是取消它们。这正是 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。对这个时序例外的简短解释是:它类似于只针对特定路径的时钟周期约束(create_clock)。
回顾一下,当定义了时钟周期约束后,工具会自动强制执行必要的时序要求:为了满足 tsu 要求,相关路径的最大延迟会受到限制;同样,为了满足 thold,最小延迟也会受到限制。
在上面的例子中,set_max_delay 命令里出现的值是 3。这等效于一条时钟周期为 3 ns 的 create_clock 命令。但 set_max_delay 的影响只限于一组特定的路径。这就是区别。
至于 set_min_delay,情况略复杂一些,下面会有更多说明。
要注意,set_max_delay 这个命令名其实有误导性:这条命令并不直接定义路径本身的最大延迟。在上面的例子中,受影响路径的延迟并不会被限制在 3 ns。3 ns 这个值被用作时钟边沿之间允许的最大时间差。而且,这个时间差不是在时序元件的时钟输入端测量的,而是在这些时钟的源头测量的。这意味着 PLL、时钟缓冲器和时钟布线的延迟都会被计入计算:与时钟周期约束相似,时钟延迟同样会进入时序分析。
-from、-to、-through 等参数的含义与 set_false_path 相同。但一般来说,set_min_delay 和 set_max_delay 被视为对时钟周期约束的调整。因此,通常假设路径两端都是时序元件。所以 -from 和 -to 应指向同步元件。引用它们的方式有很多:代表该同步元件的 cell 对象、时钟对象等等。
set_min_delay 也有类似的情况:时钟周期约束的另一个结果是,工具必须满足 thold 要求。为此,工具会在同一个时钟或相关时钟(related clocks)之间的所有路径上强制最小延迟。如果某条路径的时序计算完全来自 create_clock,并且路径两端使用的是同一个时钟,那这就等价于一条取值为 0 的 set_min_delay。这体现了“同一个时钟边沿到达两个时序元件”这个假设。但这并不意味着这个时钟边沿真的同时到达两个时序元件。确切地说,是同一个时钟源头处的时钟边沿同时出发,而到达每个时序元件的延迟,都会像 tsetup 计算那样被计入。
set_min_delay 允许你调整到达第二个时序元件的时钟边沿的时刻。例如,上面的命令使这个时钟边沿晚 1 ns 到达第二个触发器。这样一来,thold 要求就更难满足:参见下面的时序报告示例。
使用 set_min_delay 和 set_max_delay 可能有两个原因:
- 工具原本强制执行的时序要求,对某一组特定路径来说不适用或不充分。例如,对于从亚稳态保护(metastability guard)开始的路径,可能需要将时序要求收得更紧。
- 这些路径本来没有可用的相关时序约束。如果你出于这个目的想用 set_max_delay,先问自己:你是不是更应该使用一条时钟周期约束,或者使用多周期路径(multicycle path)?
使用这两条命令时,一定要在时序报告中仔细检查相关路径的时序分析。尤其注意时钟路径在计算中扮演了什么角色。
本页底部给出了几个时序报告示例,展示 set_min_delay 和 set_max_delay 的结果。
对延迟进行更精确的控制
到目前为止,set_max_delay 和 set_min_delay 所能提供的控制程度,并不比时钟周期约束明显更好。但如果我们不希望时钟路径延迟影响我们对延迟的定义呢?如果我们想控制路径中某一具体区段的延迟呢?
有些 FPGA 工具不提供任何解决这类需求的方法。例如,Quartus 就没有这种可能(至少据我所知)。相比之下,Vivado 有一些特性。下面简要介绍这些特性。
其中一个特性是 datapath_only 选项:有时我们希望在使用 set_max_delay 时,时序计算不包括时钟路径。例如,如果一条路径位于无关时钟(unrelated clocks)之间,把时钟路径计入计算就没有意义。
使用 datapath_only 后,时序计算就当作两个同步元件的时钟路径延迟都为零来进行。因此,计算只包含路径上各逻辑元件的延迟。这些延迟之和必须小于 set_max_delay 命令中给出的数值(见下面的时序报告示例)。
所以,当 set_max_delay 与 datapath_only 一起使用时,它的含义更接近命令名本身所暗示的意思。不过要注意,路径仍然必须从同步元件开始,并在同步元件结束。
另外,datapath_only 还有一些怪癖:一旦使用它,工具就不会对相关路径强制任何与 thold 有关的要求。换句话说,工具表现得好似存在一条只针对 thold 场景的伪路径约束。即使为相关路径再加一条 set_min_delay 命令,这条命令也会被忽略。目前尚不清楚 Vivado 为什么拒绝在受 datapath_only 影响的路径上强制最小延迟。
datapath_only 在任何情况下都不能作为 set_min_delay 的参数使用。
一些容易误导人的特性
正如本节标题所暗示的,下面这些特性很可能并不会带来什么好处。如果你想跳过,可以直接进入下一节。
Vivado 允许做更高层次的控制:它可以对路径中某一具体区段的延迟施加限制。例如,如果把非时序元件用于 -from 和 -to,会发生什么?用于引脚和网络又会如何?set_min_delay 和 set_max_delay 又会做什么?
答案当然取决于使用哪款 FPGA 工具。工具可能会静默忽略这类约束,因为没有路径匹配这些要求。但 Vivado 不会忽略,尽管结果并不像人们自然预期的那样:Vivado 会把这种情况视为路径分段(path segmentation),并发出严重警告(critical warning)。在大多数情况下,使用这个特性所带来的麻烦并不划算。更详细的内容请参阅相关文档。
还有一个可能误导人的特性:Quartus 有一条名为 set_net_delay 的命令。它允许你为设计中不同逻辑元件之间的延迟定义最小值和最大值。但工具在实现过程中似乎并不会努力去满足这些时序要求,而是可以通过 report_net_delay(或 GUI)生成一份报告。因此,你可以从这份报告推断用 set_net_delay 定义的条件是否得到满足。所以,set_net_delay 可以用来获得信息,但作为时序约束并不有效。换句话说:set_max_delay 和 set_min_delay 作为时序约束是有效的,set_net_delay 则不是。
总之,普通而直接地使用 set_max_delay 和 set_min_delay 已经相当好了。看起来,唯一真正有趣的特性是 Vivado 的 datapath_only。
时序约束的优先级顺序
复杂时序约束的主要问题在于,一条路径往往会同时受多条约束影响。这些约束对同一条路径提出的时序要求往往是矛盾的。那么哪条约束胜出?
每款 FPGA 工具都有自己的规则来解决这类冲突。冲突的解决通常首先取决于约束的类型,但也可能受到其它因素影响,尤其是路径选择的具体程度。
对于基于 SDC 的时序约束,优先级取决于约束类型。例如,Vivado 按以下顺序解决冲突。命令按从高到低的优先级排列:
- set_clock_groups(相关时钟组与无关时钟组)
- set_false_path(伪路径)
- set_min_delay 和 set_max_delay(最小延迟与最大延迟)
- set_multicycle_path(多周期路径)
- create_clock(时钟周期)
注意,前两个命令(set_clock_groups 和 set_false_path)会制造伪路径,而且它们具有最高优先级。因此,务必确认没有任何路径被这些命令意外影响。这样的错误会静默地关闭相关路径上所有时序要求的强制执行。
当同一条路径被多次使用同一条命令时,约束内容更具体的命令胜出。例如,如果一条命令同时带有 -from 和 -to,而另一条命令只有 -from,则第一条命令胜出。另一个例子:如果一条命令基于逻辑元件定义路径(例如使用 get_cells),而另一条命令基于时钟定义路径(使用 get_clocks),则第一条命令胜出。
如果两条命令非常相似,在优先级上没有差别,则按出现顺序解决冲突:最后出现的命令胜出。
Quartus 以及其它基于 SDC 的工具也使用类似的优先级规则。
但无论你使用哪一种工具,最好都避免时序约束之间出现任何矛盾(除非是为了覆盖 create_clock)。复杂的时序约束正是最严重的错误容易滋生藏匿的地方。
在某些 FPGA 工具中,可以绕过上述优先级规则:使用 -reset_path 属性时,带有该属性的命令会覆盖其作用路径上此前已经存在的时序例外。例如:
set_max_delay -reset_path -from [get_cells source_reg] 2
结论
本页开头我说过,时序约束应当短小、简洁。加入时序例外后,时序约束不仅变得更长,也更加复杂和难以理解。因此,只在必要时使用时序例外,并且要小心撰写、保持整洁。
尽量以能够反映目的、表达背后思想的方式编写时序例外命令。FPGA 工具通常提供用于创建时序约束的 GUI 向导,可以作为起点。但在仔细思考清楚之前,不要直接使用向导生成的时序约束。即使这条约束在生成时是正确的,当逻辑设计不断演进、新的逻辑被加入时,它是否仍能忠实地工作?
始终阅读受时序例外影响路径的时序报告。如果一条路径同时受多条时序约束影响,这么做就更为重要。同时,也要为那些可能出现错误时序要求的路径创建专门的时序报告。
请记住:创建和阅读时序报告并不是浪费时间。无论你多么仔细地阅读文档(这始终是好事),错误仍然有可能出现。尤其是伪路径,它可能出现在你最意想不到的地方。
附加:时序报告示例
为了帮助理解 set_min_delay 和 set_max_delay,下面给出几个由 Vivado 生成的时序报告示例。
回顾一下,这些报告背后的 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 的周期约束一样。
还要注意,数据路径中的这个网络有着巨大的延迟:2.478 ns。这是 set_min_delay 命令的结果:工具被迫在这个网络上插入一个很长的延迟,以满足 thold 要求。
说到 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)。更多讨论参见关于多工艺角时序分析那一节。
第三个例子演示 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 的时序报告,我就不展示了,因为没有时序要求(最小延迟被当作伪路径处理)。
到这里,关于时序例外的总体讨论就结束了。下一页会继续讨论时钟域交叉中需要使用哪些时序例外。