Report Timing Summary展示了设计是否符合时序,或者缺少了某些约束,可以在报告中各章节看到详细的内容。其他的时序报告提供更多的关于特殊情况的细节。
在给设计添加时序约束之前,必须理解时序分析的基础,以及相关的术语。
launch edge
:前一级时序单元产生数据时【源时钟source clock】的有效沿。
capture edge
:后一级时序单元捕获数据时【目的时钟destination clock】的有效沿。
source clock
:也称为launch clock。
destination clock
:也称为capture clock。
setup requirement
:launch edge和capture edge之间最严格的setup约束关系。
setup relationship
:经时序分析工具验证的setup 检查。
hold requirement
:launch edge和capture edge之间最严格的hold约束关系。
hold relationship
:经时序分析工具验证的hold 检查。
//*launch:不知道怎么翻,就是与源时钟同步的数据输出,准确来说不是“产生”,暂且翻译为产生吧。
时序路径为设计实例间的连接。在数字设计中,时序路径由一对【由同一时钟或两个不同时钟控制】的时序元素组成。
1. 常见的时序路径
从输入端口到到内部时序单元的路径,数据:
从一个时序单元到另一个时序单元的内部路径,数据:
从一个时序单元到输出端口的路径,数据:
从输入端口到输出端口的路径,数据:
2. 时序路径分段
每个时序路径分为三段:
源时钟路径
源时钟路径:源时钟 从【源点(通常是输入端口)】到 【启动时序单元的时钟引脚】的路径。
对于一个从输入端口(port)开始的时序路径,没有源时钟路径。
数据路径
数据路径:数据从路径起点(path startpoint)到路径终点(path endpoint)的传递路径。
目的时钟路径
目的时钟路径:目的时钟 从 【源点(通常是输入port)】 到 【捕获时序单元的时钟引脚】的路径。
对于一个在输出port结束的时序路径,没有目的时钟路径。
3. 产生(Launch)和捕获(Capture)边沿
当数据在时序单元或端口间传递时,数据:
在典型的时序路径中,数据在一个时钟周期内在两个时序单元之间传递,所以:
下面解释launch edge和capture edge如何在时序分析中定义建立和保持关系。
时序分析是一种静态验证,一旦在硬件上加载和运行设计的时序行为将是可预测的。它考虑了一系列的制造和环境变化,这些变化被组合到延时模型中,并根据timing corner和corner变化进行分组。对所有推荐的corner进行时序分析就足够了,对每个corner在最悲观的情况下执行所有的检查。例如,针对Xilinx FPGA设备的设计必须通过以下四个分析:
//?corner:n. 角落,拐角处;地区,偏僻处;困境,窘境,是不是指制造和环境的边界条件呢?
根据所执行的检查,将使用表示最差情况的延时。这就是为什么下面的检查和延时类型总是相关联:
*
插一节:
D触发器的控制信号(复位、置位)改变后需要时间来恢复状态确保下一个时钟沿有效,所以叫恢复时间。
///*/
当映射到各个corner时,这些检查变成:
来自不同corner的延时不会混合在同一路径上,所以slow的时候全部使slow,fast全为fast。
大多数情况下,建立或恢复违例发生在Slow corner延时,保持或移除违例发生在Fast corner延时。然而这并不总是正确的(特别是对于I/O时序),所以Xilinx建议在两种corner上同时执行这两种分析。
setup检查只在两个时钟之间最悲观的shtup关系上执行。默认情况下,这对应于launch边和capture边之间最小的正增量。例如,考虑两个对各自时钟上升沿敏感的触发器之间的路径。这条路径的launch和capture边缘只是时钟上升的边缘。
时钟如下定义:
则对应两种建立关系:setup(1) 和 setup(2):
clk0到clk1最小正增量位2ns,对应setup(2)。公周期是12ns,它对应的是两个时钟同时对齐之间的时间。
这些关系是在考虑理想时钟波形时建立的,即在插入 从时钟根到触发器时钟引脚的延时 之前。
重要:如果在这两个时钟的1000个周期中不能找到共同的周期,则使用这1000个周期中最差的设置关系进行时间分析。在这种情况下,这两个时钟被称为不可扩展时钟,或没有共同周期的时钟。这一分析很可能不符合最悲观的情况。必须检查这些时钟之间的路径,以评估它们的有效性,并确定是否可以将它们视为异步路径。
一旦已知路径要求,就可以引入路径延时、时钟不确定性和建立时间来计算松弛。典型松弛方程为:
数据需要的时间(setup) = 捕获边沿时间 + 目的时钟路径延时 - 时钟不确定性 - 建立时间
数据到达的时间(setup) = 产生边沿时间 + 源时钟路径延时 + 数据路径延时
裕量(setup) = 数据需要的时间) - 数据到达的时间
当数据早于需要的时间到达时裕量是正的。
recovery检查除了适用于异步引脚,如preset或clear。其他与setup检查类似。成立关系的方式与setup相同,裕量方程是相同的,除了使用恢复时间而不是建立时间。
保持检查(也叫做保持关系)。setup分析确保数据在最悲观(差)的场景下可以被捕获,而hold关系确保:
L1
产生的数据不能被C1
捕获。L2
产生的数据不能被C2
捕获。在hold分析期间,时序引擎只报告任意两个时钟之间最悲观的hold关系。最悲观的hold关系并不总是与最差的setup关系相关联。时序引擎必须检查所有可能的setup关系及其对应的hold关系,以确定最悲观的hold关系。
例如,setup关系示例中相同的路径。存在两种唯一的setup关系(S1,S2)。
下图每个建立关系(S1和S2)对应的保持关系(H1a、H1b和H2a、H2b)。其实就是1.当前产生沿与前一捕获沿(H1x)。 2.下一产生沿与当前捕获沿(H2x)。
最大保持要求为0纳秒,对应源时钟和目标时钟的第一个上升沿(其余为负)。
一旦路径要求已知,就引入路径延时、时钟不确定性和保持时间来计算裕量。典型裕量方程为:
数据需要的时间(hold) = 捕获边沿时间 + 目的时钟路径延时 - 时钟不确定性 + 保持时间
数据到达的时间(hold) = 产生边沿时间 + 源时钟路径延时 + 数据路径延时
裕量(hold) = 数据到达的时间 - 数据需要的时间
当数据晚于需要的时间到达时裕量时正的。
removal检查类似于保持检查,除了它适用于异步引脚,如preset或clear。成立关系的方式与hold相同,裕量方程是相同的,除了使用移除时间而不是保持时间。
路径要求表示时序路径的捕获边缘和产生边缘之间的时间差。
例如,当考虑与上一节相同的路径和时钟时,存在如下路径要求:
Setup Path Requirement (S1) = 1*T(clk1) - 0*T(clk0) = 4ns
Setup Path Requirement (S2) = 2*T(clk1) - 1*T(clk0) = 2ns
对应的保持关系为:
对应setup S1:
Hold Path Requirement (H1a) = (1-1)*T(clk1) - 0*T(clk0) = 0ns
Hold Path Requirement (H1b) = 1*T(clk1) - (0+1)*T(clk0) = -2ns
对应setup S2:
Hold Path Requirement (H2a) = (2-1)*T(clk1) - 1*T(clk0) = -2ns
Hold Path Requirement (H2b) = 2*T(clk1) - (1+1)*T(clk0) = -4ns
仅对两个最悲观的需求执行时间分析。在上面的例子中,这些是:
Setup Path Requirement (S2) = 2*T(clk1) - 1*T(clk0) = 2ns
Hold Path Requirement (H1a) = (1-1)*T(clk1) - 0*T(clk0) = 0ns
MMCM/PLL 相位偏移模式
由于时钟路径中的特殊硬件,时钟相移对应于相对于参考时钟的延时时钟波形。在Xilinx fpga中,时钟相移通常是由MMCM或PLL在输出时钟CLKOUT*_PHASE属性 是非零时引入的。
MMCM/PLL相移模式:
在时序分析期间,通过设置MMCM/PLL PHASESHIFT_MODE属性,可以用两种不同的方式对时钟相移建模,如下表所示。
PHASESHIFT_MODE属性 | 相移的模型 | 说明 |
---|---|---|
WAVEFORM | 时钟波形修改 | 通常需要Set_multicycle_path -setup约束来调整从相移时钟或到相移时钟的时钟域交叉路径的时序路径要求。 |
LATENCY | MMCM /锁相环插入延时 | 不需要额外的多周期路径约束。 |
Xilinx FPGA各系列默认的MMCM/PLL时钟移相模式有所不同。然而,默认模式可以由用户在每个PLL/MMCM的基础上重写。
使用PHASESHIFT_MODE=LATENCY在引入两个时钟之间的偏差以满足时序时特别方便。当将时钟相移设置为负、零或正时,不需要额外的多路路径约束来调整时序路径要求。
对于从7系列或UltraScale迁移到UltraScale+的设计,属性MMCM/PLL上没有设置PHASESHIFT_MODE,应用默认MMCM/PLL时钟移相被建模为LATENCY而不是WAVEFORM。在这种情况下,所有在遗留设计中为考虑时钟相移而指定的多周期路径约束都需要审查,通常是删除。这样的约束可以通过运行方法论检查(report_methodology)来轻松识别。TIMING-31标志时钟之间的多周期路径,其中一个时钟相移,并由一个MMCM/PLL生成,PHASESHIFT_MODE设置为LATENCY。
Clocking wizard 和 High Speed SelectIO™ Wizard 都提供选项以在每个MMCM/PLL强制时钟相移建模。属性PHASESHIFT_MODE会自动保存在IP XDC中。
时序报告中的相位偏移
正相移使源时钟边缘向前移动,使时钟边缘延时。负相移使源时钟边缘向后移动。对时钟波形的修改导致对源时钟和捕获时钟进行静态计时分析时使用潜在的不同时钟边缘。
Skew 和 Uncertainty都影响setup和hold的计算和裕量。
偏斜(skew)的定义:
时钟偏斜是指目的时钟路径和源时钟路径之间的延时差:
计算公式:
Tskewi,j = Tci- Tcj
时钟悲观补偿(Clock Pessimism Removal)
一个典型的时序路径报告显示了源和目标时钟路径的延时细节,从它们的根到时序单元时钟管脚。如下所述,虽然有一段公共的电路(Common clock Tree Section),但是分析时源时钟和目标时钟也用不同的延时进行分析。
这样计算的话比实际偏斜是偏大的,因为有一段公共部分是没有偏斜的。所以在公共部分上对应的延时差在偏斜计算中引入了一些额外的悲观影响。为了避免不真实的裕量计算,补偿的值称为时钟悲观消除(Clock Pessimism Removal CPR)。
Clock Pessimism Removal (CPR) = common clock circuitry (max delay - min delay)
CPR会根据所执行的分析类型增加或减少偏斜:
建立关系分析时,数据比时钟早到,所以为了补偿,会加到目标时钟的延时上。
保持关系分析时,数据比时钟晚到,减掉目标时钟的延时完成补偿。
Vivado Design Suite时序报告每个计时路径的时钟偏斜,如下所示(在此情况下hold分析):
Clock Path Skew: 0.301ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 2.581ns
Source Clock Delay (SCD): 2.133ns
Clock Pessimism Removal (CPR): 0.147ns
在许多情况下,CPR的准确性在布线之前和之后都会发生变化。例如,考虑一个时序路径,其中源时钟和目标时钟是相同的时钟,起点和终点时钟引脚由相同的时钟缓冲器驱动。
在布线之前,公共点是时钟网驱动,即时钟缓冲器输出引脚。CPR只补偿从时钟根到时钟缓冲器输出引脚的悲观影响。
在器件架构中,布线完成后的公共点是源和目的时钟路径共享的最后一个布线资源。这个公共点不在网表中表示,因此不能通过从时序报告中减去公共时钟电路延时差来直接补偿相应的CPR。时序引擎根据用户看不到的的器件信息计算CPR值。
乐观偏斜(Optimistic Skew)
Xilinx FPGA器件提供高级时钟资源,如专用时钟路由树和时钟修改块(CMB)。一些cmb可以通过使用锁相环路电路(PLL或MMCM)来补偿时钟树引入的延时。补偿量是基于锁相环反馈环路上的延时。
很多情况下,一个PLL(或MMCM)相同类型的缓冲区驱动多个时钟树,包括反馈环路。
由于器件可能很庞大,所有这些时钟树分支上的引入的延时并不总是与反馈环路延时匹配。当反馈环路延时大于源时钟或目标时钟延时时,由锁相环驱动的时钟变得过补偿。
在这种情况下,CPR的符号改变了,它有效地从裕量值中消除了乐观偏斜。这是必要的以确保在分析期间,任何时序路径时钟的公共节点上没有人为的偏斜。
建议: 在时序分析时总是使用CPR补偿,以保持裕量准确性和整体时序分析结果的质量
时钟不确定性(Clock Uncertainty)
时钟不确定性是任何一对时钟边缘之间可能的时间变化的总和。不确定性包括:
对于主时钟,抖动由set_input_jitter和set_system_jitter定义。对于时钟生成器,如MMCM和PLL,该工具根据用户指定的源时钟和配置的抖动计算抖动。对于其他生成的时钟(如基于触发器的时钟分频器),其抖动与其源时钟相同。
用户指定的时钟不确定性被添加到Vivado时序引擎计算的不确定性。对于生成的时钟(例如从MMCM、锁相环和基于触发器的时钟分频器),用户在源时钟上指定的不确定性不会通过时钟生成器传播。
时钟不确定性有两个目的:
脉冲宽度检查是对信号波形通过器件传播后到达硬件基元时的一些规则检查。它们通常与基元内部电路所规定的功能极限相对应。例如,DSP时钟针上的最小周期检查确保驱动DSP实例的时钟运行频率不高于内部DSP所容忍的频率。
脉宽检查不影响综合或实现。它们的分析必须在比特流生成之前执行一次,就像Vivado design Suite提供的任何其他设计规则检查一样。
当脉冲宽度违例发生时,它是由于不适当的时钟定义(脉冲宽度和周期检查)或不适当的时钟拓扑导致太多的倾斜(max_skew检查)。必须查看目标设备的Xilinx FPGA数据表,以了解发生冲突的基元的操作范围。在出现倾斜违例的情况下,必须简化时钟树或将时钟资源放置在更靠近违例引脚的位置。
时序路径报告提供所需的信息以理解导致时序违例的原因。
“Timing Path Summary”显示时序路径详细信息中的重要信息。可以查看它来找出违例的原因,而不必分析时序路径的细节。它包括裕量(slack)、路径要求(path requirement)、数据路径延时( datapath delay)、单元延时(cell delay)、布线延时(route delay)、时钟偏斜(clock skew)和时钟不确定性(clock uncertainty)。它不提供任何关于单元放置的信息。
例子:时序路径总结的文件头:
对应Vivado IDE的界面显示:
时序路径总结文件头各字段信息:
slack
:
正裕量表示路径满足路径要求,路径要求是由时序约束导出的。Slack计算方程依赖于所进行的分析。
- Max delay analysis (setup/recovery)
`slack = data required time - data arrival time`
- Min delay analysis (hold/removal)
`slack = data arrival time - data required time`
所需的数据和到达时间在计时路径报告的其他小节中计算和报告。
Source
:
结构:路径startpoint (产生数据的源时钟)。起始点通常是时序单元的时钟管脚或输入端口。
如果有的话,第二行显示时钟引脚的基元及其边缘灵敏度。它还提供时钟名称和时钟边缘定义(波形和周期)。
Destination
:
路径endpoint和捕获数据的目标时钟。终点通常是目的时序单元的输入数据管脚或输出端口。如果有,第二行显示时钟引脚的基元和边缘灵敏度。它还提供时钟名称和时钟边缘定义(波形和周期)。
Path Group
:
路径endpoint所属的timing group。这通常是由目标时钟定义的组,除了异步时序检查(恢复/移除),它被分组在async_defaulttiming group中。用户定义的组也会显示。它们便于进行报告。
Path Type
:
在此路径上执行的分析类型:
- Max: 表示使用最大延时值来计算数据路径延时,对应于setup和recovery分析。
- min: 表示使用最小延时值来计算数据路径延时,对应hold和removal分析。
这一行还显示了哪个Corner用于报告:Slow还是Fast
Requirement
:
当起点和终点由同一个时钟控制,或由没有相移的时钟控制时,定时路径要求通常为:
- 一个时钟周期用于setup/recovery分析。
- 0ns用于hold/removal分析。
当路径在两个不同时钟之间时,要求对应于任何源和目标时钟边缘之间的最小正差。这个值被定时异常约束覆盖,例如多周期路径,最大延时和最小延时。
Data Path Delay
:
通过路径的逻辑部分的累积延时。时钟延时被排除,除非时钟被用作数据。延时的类型与路径类型线所描述的相对应。
Logic Levels
:
路径的数据部分中包括的每种类型的基元的数量,不包括起点和终点单元。
Clock Path Skew
:
源时钟的发射边缘和目标时钟的捕获边缘之间引入的延时差,加上时钟悲观校正(如果有的话)。
Destination Clock Delay (DCD)
:
从目的时钟源点到路径终点的累计时延。
- 对于最大延时分析(setup/recovery),使用最小单元和网络延时值。
- 对于最小延时分析(hold/removal),使用最大延时值。
Source Clock Delay (SCD)
:
从时钟源点到路径起点的累计时延。
- 对于最大延时分析(setup/recovery),使用最大单元和网络延时值。
- 对于最小延时分析(hold/removal),使用最小延时值。
Clock Pessimism Removal (CPR)
:
由于源时钟和目标时钟即使在它们公共的电路上也有不同类型的延时而引起的额外时钟偏差的绝对量。
在消除这种额外的悲观情绪后,源时钟和目标时钟在它们的公共电路上没有任何偏差。
对于布线设计,最后一个公共时钟树节点通常位于时钟网使用的路由资源中,不报告在路径详细信息中。
Clock Uncertainty
:
任何一对时钟边之间可能的时间变化的总和。
不确定性包括计算的时钟抖动(系统的和离散的),由某些硬件基元引入的相位误差,以及用户在设计约束中指定的任何时钟不确定性(set_clock_uncertainty)。
用户时钟的不确定性是附加到Vivado IDE时序引擎计算的不确定性之上的。
Total System Jitter (TSJ)
:
总的系统抖动适用于源时钟和目标时钟。要全局修改系统抖动,请使用set_system_jitter约束。虚拟时钟是理想的,因此没有任何系统抖动。
Total Input Jitter (TIJ)
:
源时钟和目标时钟的总的输入抖动。
要分别定义每个主时钟的输入抖动,请使用set_input_jitter约束。Vivado IDE时序引擎根据主时钟抖动和所遍历的时钟资源计算生成的时钟输入抖动。默认情况下,虚拟时钟是理想的,因此没有任何抖动。
Discrete Jitter (DJ)
:
由硬件基元(如MMCM或PLL)引入的抖动量。
Vivado IDE定时引擎根据这些单元格的配置计算这个值。
Phase Error (PE)
:
由硬件基元(如MMCM或PLL)引入的两个时钟信号之间的相位变化量。
Vivado IDE定时引擎自动提供这个值,并将其添加到时钟不确定性中
User Uncertainty (UU)
:
由set_clock_uncertainty约束指定的附加不确定性。
根据时间限制、报告的路径和目标设备,其他行可以出现在计时路径摘要中:
Inter-SLR Compensation
:
仅Xilinx 7系列SSI设备安全报告穿越SLR边界的路径所需的额外裕度。
Input Delay
:
由输入端口上的set_input_delay约束指定的输入延时值。这一行没有显示不是从输入端口开始的路径。
Output Delay
:
由输出端口上的set_output_delay约束指定的输出延时值。这一行不显示没有结束到输出端口的路径。
Timing Exception
:
覆盖路径的事故需要异常。只有优先级最高的exception才会显示,因为它是唯一影响定时路径需求的exception。
报告的后半部分提供了路径所经过的单元、引脚、端口和网的更多细节。它分为三个部分:
源时钟路径(Source Clock Path):
由源时钟从source point到数据路径的startpoint所穿过的电路。对于从输入端口开始的路径,本节不存在。
数据路径(Data Path):
由数据从startpoint到endpoint所遍历的电路。
目的时钟路径(Destination Clock Path):
由目标时钟从其source point到数据路径endpoint时钟管脚所穿过的电路。
源时钟路径和数据路径部分一起工作。它们总是以相同类型的延时被报告:
它们共享从数据启动边缘时间开始的累积延时,并通过源时钟和数据路径累积延时。最终的累积延时值称为数据到达时间(data arrival time)。
目的时钟路径总是以与源时钟和数据路径相反的延时被报告。其初始累积延时值为数据捕获边缘在目的时钟源点上启动的时间。最终的累积延时值称为数据需要时间(data required time)。
报告的最后几行总结了裕量是如何计算的:
slack = data required time - data arrival time
slack = data arrival time - data required time
timing_report文件中的信息:
Vivado IDE图形界面显示:
使用标准流程时路径信息显示为5列,使用增量编译时显示为6列:
Location
:
单元或端口在设备上的位置
Delay Type
:
统一基元和特定的时序弧所遵循的路径。对于net,它显示扇出(fo)和它的状态。一个net可以是:
- Unplaced: 驱动和负载未放置
- Estimated: 驱动或负载或两者都被放置。根据估计报告一个部分完成布线的net。
- Routed: 驱动和负载都已经放置好,net已经完全布线完成。
Incr(ns) (text report) / Delay (IDE report)
:
与统一基本时序弧或net相关联的增量延时的值。它还可以显示约束,如输入/输出延时或时钟不确定性。
Path(ns) (text report) / Cumulative (IDE report)
:
每段路径后的累积延时。在给定的一行上,它的值是前一行的累积值+当前行的增量延时。
Netlist Resource(s) (text report) / Logical Resource (IDE report)
:
所遍历的网表对象的名称。
Pin Reuse (Incremental Compile only)
:
指示是否从引用运行中重用该路径。适用的值ROUTING, PLACEMENT, MOVED和NEW。
每一个递增的延时都与下列边缘感知之一相关:
边缘的初始意义是由用于分析的发射或捕获边缘决定的。它可以被沿着路径的任何单元反转,这取决于时序弧的性质。例如,反相器输入端的上升沿变为输出端的下降沿。
边缘感知有助于识别 来自沿源或目标时钟树的时钟反转沿 过紧的时序路径要求。
在深入了解时序分析的细节之前,重要的是要了解时序报告的哪一部分表明您的设计已经可以在硬件中运行了。
重要:在设计完全布局布线之后,Timing signoff 是分析实现结果的一个强制性步骤。
默认情况下,当使用Vivado Design Suite中的项目模式时时,运行会自动生成文本版本的Report Timing Summary。您还可以在内存中加载实现后的设计检查点之后以交互方式生成该报告。
重要:Report Timing Summary不包括总线偏斜约束。要报告总线倾斜约束,必须在命令行上单独运行report_bus_skew命令。这个命令没有GUI支持。
全面理解Timing Signoff Verification methodology,看《 UltraFast
Design Methodology Guide for the Vivado Design Suite(UG949)》