基于Xlinx的时序分析与约束（8）----关于时序路径、时钟悲观度和建立时间/保持时间的一些问题

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

写在前面

最近研究vivado里的时序分析路径时发现了3个很有意思的问题。经过一番查找资料后总算把问题搞明白了在这里分享给大家。

1、为什么同一条时序路径在报表里的值不一样

在如下文件建立的工程中

module test
(
    input               sys_clk	,
    input               rst  	,
    output reg [7:0]	cnt
);

always @(posedge sys_clk)begin
    if(rst)
        cnt <= 0;
    else
        cnt <= cnt + 1'b1;
end

endmodule

时序约束只做了主时钟约束约束时钟100M

create_clock -period 10.000 -name sys_clk -waveform {0.000 5.000} [get_ports sys_clk]

有一条建立时间的路径是这样的

左侧是源端时钟路径右侧是目的端的时钟路径
①是时钟从FPGA管脚进入后到IBUF在IBUF内部的延迟这段路径在源端和目的端就是同一条路径但是两者的时间增量却不相同源端是0.915ns而目的端是0.784ns
②是时钟IBUF出来后到BUFG的布线延迟这段路径在源端和目的端同样是相同一条路径但是两者的时间增量却不相同源端是1.693ns而目的端是1.604ns
③是时钟在BUFG内部的延迟这段路径在源端和目的端依然是同一条路径但是两者的时间增量却不相同源端是0.081ns而目的端是0.077ns
④是时钟从BUFG出来后分别到源端寄存器时钟端和目的端寄存器时钟端的布线延迟二者不是同一条路径但二者可能存在部分路径重合需要具体分析所以时间增量不同是正常的

所以现在问题来了 ①②③明明就是同一条路径但是为什么在源端报表和目的端报表的时间增量却不相同

上面是建立时间的路径分析这一诡异的情况同样出现在保持时间的路径分析下

哪怕都是源端时钟路径或者目的端时钟路径在建立时间的时序报表和保持时间的时序报表里也都不一样。比如源端的BUFG在建立时间分析时延迟是0.081ns但在保持时间分析时延迟却成了0.026ns。其他相同项也都有不同的时间延迟。

所以问题到底出在哪里

OCV 与 PVT

即便是同一种 FF在同一个芯片上不同操作条件下的延时都不尽相同我们称这种现象为 OCVon-chip variation。OCV 表示的是芯片内部的时序偏差虽然很细小但是也必须严格考虑到时序分析中去。

产生 OCV 的原因主要有 PVTProcess / Voltage / Temperature三个方面而 STA 要做的就是针对不同工艺角(Process Corner)下特定的时序模型来分析时序路径从而保证设计在任何条件下都能满足时序要求可以正常工作。通常 PVT 对芯片性能的影响如下图所示

不同的 PVT 条件组成了不同的 corner另外在数字电路设计中还要考虑 RC corner 的影响排列组合后就可能有超过十种的 corner 要分析。但是在 FPGA 设计中的静态时序分析一般仅考虑 Best Case最优情况和 Worst Case最差情况也称作 Fast Process Corner 和 Slow Process Corner分别对应极端的 PVT 条件。

Multi-Corner

Vivado 中的 STA 支持多角时序分析Multi-Corner Timing Analysis会对以上两种 corner 下的时序同时进行分析然后报告最差的情况。因为每个 corner 下的延时也会有一定的变化范围所以时序分析还会考虑每种 corner 下的最大延时和最小延时。

如果一个设计在 Best Case 和 Worst Case 下都能满足时序要求则可以推算出这个设计在其允许的任何操作条件下都能保持正常工作。

这里要提醒大家不要被 corner 的名字误导实际上同样一条路径可能在 Slow Corner 中满足时序却在 Fast Corner 中有时序违例。但是你在 Vivado 中看到的时序报告只会显示其对两种 corner 并行分析后选出的最差情况。

所以现在问题大概就有答案了由于不同的 PVT 条件可能会产生不同的路径延迟所以vivado选择的办法就是找到最优、最差两种极端路径在极端路径都满足时序要求的话就可以保证在所有情况都满足时序要求。

建立时间分析的时候使用的是Slow Corner模型保持时间分析的时候使用的是Fast Corner模型。所以才会出现同一条路径在做建立时间分析和保持时间分析时出现不同延迟值的情况。

建立时间报表分析分析的是max at slow process corner。在slow process corner模型下所有节点的时延都是最大的。在这种情况下如果能满足setup时间的话那么在其他模型就都可以满足保持时间报表分析分析的是min at fast process corner。在fast process corner模型下所有节点的时延都是最小的。在这种情况下如果能满足hold时间的话那么在其他模型就都可以满足。

同样的为了实现最极端情况的分析所以在

建立时间检查的最大延迟

针对源时钟路径和数据/复位路径累积延迟使用给定角点 (corner) 的最差情况延迟最慢延迟
针对目标时钟路径累积延迟同样使用该角点 (corner) 的最佳情况延迟最快延迟

保持时间检查的最小延迟

针对源时钟路径和数据/复位路径累积延迟使用给定角点 (corner) 的最佳情况延迟最快延迟。
针对目标时钟路径累积延迟同样使用该角点 (corner) 的最差情况延迟最慢延迟

也就是说源端路径的延迟和目的端路径的延迟是不一致的。

至此问题1解决。

2、时钟悲观度Clock Pessimism RemovalCPR是啥

在建立时间分析时我发现下面两条路径都存在一个clock path skew的值且两者还不一致。

clock path skew的概念我懂就是时钟到达源端和目的端两个寄存器的时间存在偏差嘛就像这样

时钟网络延时 Tskew 就是 Tc2d 与 Tc2s 之差即 Tskew=Tc2d - Tc2s。如下图

所以两条路径的Tskew不同也很正常毕竟走线不一样。

在分析下面的问题前我还是把这张经典的时序图请出来

Data Arrival Time = launch edge + Tclk1 + Tco +Tdata
Data Required Time = latch edge + Tclk2 - Tsu
Setup Slack = Data Required Time – Data Arrival Time

然后我分别点开了 Tskew的值就出现了这样两张图

可以看到vivado计算Tskew不光使用目的端的时钟延迟减掉源端的时钟延迟它还加上了一个Clock Pessimism RemovalCPR那么这个CPR是啥

在问题1的时候我们了解到为了分析最极端情况的路径延迟对于源端时钟的路径延迟和目的端时钟的路径延迟采用了不同的建模方式Corners。但是会有意外两条路径之间偶尔会有相同的路径嘛就像这样

相同的路径结果最后计算出来的路径延迟是不一样的这明显不合理不是所以xilinx就采用了时钟悲观度Clock Pessimism RemovalCPR这个概念用来补偿两条路径之间的相同部分。顺便多说一句CPR的xilinx的官方翻译是时钟消极因素移除出自xilinx文件c_ug906但是网上多用时钟悲观度这个翻译。

对于第一条路径path119

源端延迟是3.794ns目的端延迟是4.128ns4.128ns - 3.794ns = 0.334ns这和vivado补偿的CPR的值0.334ns是一致的这说明到源端寄存器和到目的端寄存器都是100%的共同路径。

最后时钟悲观度是作为一个增量加入到了目的端时钟路径上作为共同路径采用不同模型导致延迟差异的补偿。

再来看看第二条路径path 114

同样的源端延迟是3.794ns目的端延迟是4.128ns4.128ns - 3.794ns = 0.334ns这和vivado补偿的CPR的值0.306ns不一致的二者之间差了0.306ns - 0.334ns = -0.028ns这个值也就是Tskew 这说明到源端寄存器和到目的端寄存器的路径除了有共同部分外还有不相同的部分。

从FPGA管脚到 IBUF到net再到BUFG这条路径不管是源端还是目的端都是相同的源端延迟是0.915+1.693+0.081 = 2.689ns目的端延迟是0.784+1.604+0.077 = 2.465ns所以照理来说补偿值CPR应该是 2.689 - 2.465 = 0.224ns但是实际却补偿了0.306ns那么多出来的0.306 - 0.224 = 0.082ns是来自哪里

从BUFG到源端和目的端的时钟管脚之间各自都还有一段走线在源端这个值是1.440ns在目的端这个值是1.330ns如果这段走线都是共同路径的话那么在这一部分要补偿的CRP的值应该是 1.440-1.330 = 0.11ns但是我们前面算了这段实际补偿的CPR值是 0.082ns这说明这段路径仅有一部分是二者的共同路径共同路径的比例应该是 0.082/0.11 ≈ 74.5%。这说明剩下的25.5%就是源端时钟与目的端时钟的Skew值即0.11*25.4%≈ 0.028ns这与vivado计算的clock path skew值是一致的。

至此第二个问题也解决。

3、建立时间Tsu为啥是负的

建立时间Tsu的概念我们很熟悉了也很重要毕竟是整个时序分析的基础在这里再回顾一下

为了使寄存器稳定地采样到当前D端的数据D端数据必须满足建立时间和保持时间的要求

建立时间Setup Time缩写是 Tsu即在时钟上升沿之前数据必须稳定的最短时间
保持时间Hold Time缩写是 Th即在时钟上升沿之后数据必须稳定的最短时间

通俗来讲建立时间和保持时间就是在寄存器采样窗口中输入数据必须保持不变以免寄存器无法稳定采样。也就是说在我寄存器的采样窗口之前你输入数据就必须要保持稳定即输入数据不能来的太晚建立时间同样的你寄存器的输入数据也必须在我寄存器的采样窗口结束后才变化在此之前必须保持问题即输入数据不能走的太早保持时间。

建立时间和保持时间的示意图如下

建立时间和保持时间是寄存器的固定属性不同的FPGA器件都应该是一个不同的值且理论上这两个值都应该是正数。

现在依然来看path 119的时序报告

上图是计算数据要求到达时间的公式建立时间是0.059且是作为一个增量给加到数据要求到达时间里去的但是从更上面的公式我们又知道数据要求到达时间应该是这样计算的Data Required Time = latch edge + Tclk2 - Tsu也就是说理论上建立时间是应该作为一个负的增量加到数据要求到达时间的计算中即减去 Tsu 。

但报表中的Tsu显然是加上去了这说明在这个报表中 Tsu 实际上是个负数值。这就很奇怪了why

这种情况在芯片设计中很常见比如使用standard cell分析的是CELL外部的时序不过如果CELL内部clock的延迟大于data的延迟。假设这个延迟是delayCELL内部寄存器固有的setup时间为tsu则CELL的setup_time=tsu - delay当clock延迟足够大那么从CELL看建立时间就是负值。