赞
踩
要想进行时序分析和约束,我们需要理解时序引擎究竟是如何进行时序分析的,包括时序引擎如何进行建立分析(setup),保持分析(hold),恢复时间分析(recovery)和移除时间分析(removal)。
发起沿(launch edge,源时钟产生数据的有效时钟沿),捕获沿(capture edge,目的时钟捕获数据的有效时钟沿)。
时序引擎会找出发起时钟和捕获时钟的最小公共周期,然后在最小公共周期内找到所有发起时钟沿和捕获时钟沿的所有可能的情况,并在所有可能的情况中挑选出最小的建立时间需求(大于0),从而确定了Launch edge和Capture edge。
数据的建立要求时间 = 捕获沿 + 目的时钟路径延迟 - 时钟不确定性 - 建立时间
数据到达时间 = 产生沿 + 源时钟路径延迟 + 数据路径延迟
建立时间裕度 = 数据建立要求 - 最后一个到达的信号
- Setup Slack = (Capture edge – Launch edge)+ (destination clk delay – source clk delay)- Setup time - clk uncertainty – datapath delay
- Setup Slack = Setup Requirement(一定大于0) + clk skew – Tsu – Tclk uncertainty – Tlogic – Tnet - Tco
会导致Setup Slack为负数的影响因素如下:
建立时间需求过小,这种情况通常会在同步跨时钟域路径中出现,在同步跨时钟域路径中的源时钟频率与目的时钟频率的相位关系虽然是已知的,但是时序引擎默认选择的捕获沿通常都是错误的,需要用户通过多周期路径约束的方式手动修正建立时间需求。比如下图中,两个同频不同相的同步时钟,时序引擎默认选择的捕获沿是目的时钟第二个上升沿,导致建立时间需求非常小,最终肯定会导致时序违例。
通常情况下,同一个时钟下的时钟歪斜不应该超过300ps,同步跨时钟域路径的时钟歪斜不应该超过500ps,异步跨时钟域路径的时钟歪斜一般比较大,因为它们的时钟源不同。
当出现时钟歪斜大的情况时:
- 检查源时钟路径和目的时钟路径上是否干净,时钟路径上是否引入了组合逻辑,时钟路径是否使用了过多的BUFGCE,时钟路径上是否级联了多个BUFGCE导致时钟延时变大。
- 检查源时钟路径和目的时钟路径所经过的模块是否相同,比如源时钟路径上经过全局缓冲,PMMCM,但是目的时钟路径上只经过了全局缓冲。如下图所示,第一条路径的源时钟路径上有BUFGCE/MMCM/BUFGCE,而目的时钟路径上只有BUFGCE,所以源时钟路径和目的时钟路径的延时不同,导致时钟歪斜较大,应该尽量避免此类路径。第二条路径的源时钟和目的时钟都是来源于MMCM的不同的时钟,所以时钟歪斜较小。
当设计中使用Block(DSP/Block RAM等)时,应该要注意以下问题。对于以这些Block为时序路径的起点或终点的时序路径,这些Block的Tsu/Th/Tco都比普通的寄存器大,而且这些Block的布线延时和时钟歪斜比较大。
所以当使用这些Block作为时序路径的终点时,它的起点一定要是触发器,比如说一个Block RAM的写数据信号,输入进 Block 前最好打一拍。当使用这些 Block 作为时序路径的起点时,应该使用 Block 内部的输出寄存器,比如使用由 Block RAM 组成的FIFO时,尽量不要使用首字置出的,而使用打一拍后输出的,使用后者可以显著降低Tco。当时序路径为从一个 Block 到另一个Block 时,中间需要进行打拍操作。当使用这些Block的控制端口时,应该保证这些控制信号的低扇出,如使用由Block RAM组成的FIFO时,应该尽量降低读/写能信/地址信号的扇出。
一般情况下,逻辑延时与时序路径的逻辑层级数息息相关,逻辑层级是指时序路径的起点和终点之间组合逻辑单元(LUT)的个数,而逻辑层级多一级意味着多1个LUT的延时加1条连接LUT的网线延时。通常一级逻辑层级的延时标准是1个LUT加1根网线的总延迟为0.5ns,如果某条路径的逻辑级数大于时钟周期/0.5ns,那么这条路径就被称为长路径。常用的处理长路径的方案有两种:第一种,修改rtl代码,在长路径的逻辑中插入流水线,将长路径打破分为多条短路径;第二种,使用综合工具的retiming优化方式,retiming实际上是寄存器重定向,原理是当某条长路径的相邻路径的建立时间裕量较大,那么它可以调整中间寄存器的位置,来调整布线延迟,通过适当增加相邻路径的布线延迟而减少长路径的布线延迟,使得那些时序违例较小的长路径通过这种微调实现时序收敛。需要强调的是,这种方式优化的力度非常有限,它只适合时序违例较小的长路径,对于一些延时特别大的长路径而言,也是无力回天。
一般情况下,布线延迟与设计整体或局部模块的资源利用率以及拥塞程度息息相关。
在正常情况下,一条网线的延时小于1ns,在发生拥塞的区域,网线的延时可能达到若干ns,导致布线延时显著增加。为了解决布线延迟大,需要从降低资源利用率和降低拥塞程度下手,比如某个模块使用了大量的寄存器堆,占用了大量的资源,此时应该考虑使用Block RAM代替这些寄存器堆;某个模块使用了大量的数据选择器,此时应该考虑如何优化这些数据选择器;某个模块的控制信号扇出比较大,与其他模块的互联很重,此时应该考虑如何降低这些信号的扇出;某条时序路径的起点或终点是Block,由于Block的位置比较固定,所以Block的布线延迟会大一些。最后需要强调的是,一定要额外关注高扇出的网线也会对布线延时产生影响。
保持时间要求是以建立时间要求为基础的
保持时间要求有两种:
- 当前建立时间的发起沿产生的数据不能被当前建立时间的捕获沿的前一个有效沿捕
- 当前建立时间发起沿的下一个有效沿产生的数据不能被当前建立时间的捕获沿捕获
根据所有的建立时间需求找到所有的保持时间需求,并从保持时间需求(可正可负)中找到最大的保持时间需求。
数据的保持要求时间 = 捕获沿 + 目的时钟路径延迟 + 时钟不确定性 + 保持时间
数据到达时间 = 源时钟捕获沿 + 源时钟路径 + 数据通道延时
保持裕度 = 最早达到的信号 - 数据稳定要求
Holdup Slack = (lauch edge - capture edge) + (Tclka – Tclkb) + Tco + Tdata(Tlogic+Tnet) -Th
Holdup Slack = Tco + Tdata(Tlogic+Tnet) -Th - Holdup Requirement - clk skew
Hold up Slack为负的情况比较少见,当Setup Slack有较大裕量时,通常工具会自动插入延时来增加Hold up Slack。
①保持时间需求大于0(通常由时序引擎选择错误的捕获沿导致)
②时钟歪斜大于300ps(通常由时钟路径上的组合逻辑导致)
③Th过大(通常由时序路径终点为Block导致)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。