• 注册
  • 查看作者
  • 时钟树综合skew和uncertainty的前世今生

    时钟树综合skew和uncertainty的前世今生

     

    为什么数字后端实现中要做时钟树综合这一步?

    时钟作为数字IC中最重要的信号,几乎每一个芯片实现环节都需要针对时钟信号做很多特殊的处理。对于一个同步电路设计,所有的寄存器的CK都连着同一个时钟。这就意味着这个时钟有着特别大的fanout(扇出)。对于后端实现中,cts阶段就有一步专门用来解决时钟信号高扇出的问题。

    上图就是最原始简单的时钟树示意图。理论上,在前端看来,一个时钟信号到达各个reg的时间是一致的(同时到达),但现实是残酷的,从时钟源头到不同的DFF端,时钟所走的路径显然会不一样,而走每条路径都是需要第一定时间的,路径不同必然需要的时间不同,这就导致时钟源到不同DFF时钟总输入端的延时差异,这个延时差异就被定义为Skew(时钟偏移,时钟偏差)。这个skew的存在会对DFF的时序造成影响,比较坏的情况可能会使得DFF的setup或hold时序要求无法满足。为了减少这种skew对时序的影响,在自动布局布线时,需要对时钟进行高扇出优化,这一步处理称之为时钟树综合(CTS)。经过时钟树综合后的电路布局一般呈现相对规整的时钟分叉,理想的时钟树分枝如下图:

    这时问题来了,CTS一般是在自动布局布线的后端流程里完成的,那时才考虑时序平衡问题有点晚了。如何在早期如逻辑综合时就开始处理合平衡时钟树的时序问题呢?在逻辑综合阶段,默认情况下时钟信号都被当中理想时钟来处理(Ideal),为了提前模拟真实时钟信号对时序的影响,就需要人为的设置一些时钟属性,其中主要的就是这种时钟偏差Skew。Skew对setup和hold的检查的影响,可能有利也可能有害,但是在逻辑综合阶段,我们都是当中有害来处理,以避免综合的时序结果过于乐观。

    在DesignCompiler中,是通过clock uncertainty(时钟不确定性)来体现这种时钟属性,但是,clock uncertainty可以不完全等价于clock skew, 其他时钟的一些属性也可以附加在这个变量上,比如时钟抖动(Jitter)。Jitter指的就是时钟周期的偏差,主要由时钟源Pll本身来决定,比如定义时钟周期为10ns,但是由于pll的精度问题,不能保证每个时钟周期都是严格等于10ns,可能在10±0.1ns范围内变化,这0.1ns的微小偏差也会对时序产生影响。同时,利用这个clock uncertainty变量,还可以再附加一些时序余量(Margin),以约束综合工具对关键路径进行充分的综合。虽然现在的自动布局布线工具也可以优化时序,但综合工具的对时序的优化方法和力度更强。

    另外,由于逻辑综合只考虑Setup的约束和优化,所以这里的clock uncertainty也只是针对setup的约束。

    因此,Synopsys 的Student Guide明确指出:clockuncertainty =  clock skew  + clock jitter  +   Margin。在Design Compiler中,对应的Tcl命令为:

    set_clock_uncertainty-setup  0.2  [get_clocks CLK]

    实际应用中,该值是一个经验值(10~20%时钟周期),比如根据APR的反馈CTS可以做到的最小skew,pll测试的时钟抖动,最后timing signoff时需要留的margin等。也因此,在CTS之后,我们可以继续保留clock uncertainty,但此时的clock skew已经真实存在,无须人为的设置,可以适当减掉该部分值。比如:

    set_propagated_clock [get_clocks CLK]  set_clock_uncertainty -setup  0.05 [get_clocks CLK]

    这种做法,使得前后端保持一致的时钟周期,通过调整clock_uncertainty来对不同实现环节的时序约束进行调整。

  • 1
  • 0
  • 0
  • 3.8k
  • 请登录之后再进行评论

    登录
  • 单栏布局 侧栏位置: