异步电路后端实现流程(cdc signOff 后端做什么)

1.一种后端异步电路的signOff流程

同步电路和异步电路分别signOff

对于同步电路,后端会分析sta setup/hold,这里不在赘述。在该scenario下 异步电路是不会分析,也不会关注异步电路之间的走线

在cdc scenario(mode)下sdc有一下设置:

  1. 将所有同名的clk之间的path都设为falsePath

          该scenario下不检查同步电路的sta

foreach_in_collection per_clk_cdc [get_clocks *_cdc] {
    set_false_path -from ${per_clk_cdc} -to ${per_clk_cdc}
}

     2.将所有的clk hold检查设为falsePath

        该scenario下不检查时钟之间的hold

set_false_path -hold -from [get_clocks *_cdc] -to [get_clocks *_cdc]

     3.对所有不同名的clk 做双向的max_delay检查

设 有clk_a,clk_b;周期分别为period_a和period_b,则两者之间最小的周期为period_min_ab,做一下max_delay检查

set period [expr ${period_min_ab} * ${cdc_ratio}];#normally, we can set cdc_ratio=0.7
set_max_delay -from clk_a to clk_b ${period} -ignore_clock_latency
set_max_delay -from clk_b to clk_a ${period} -ignore_clock_latency

以上约束的含义就是 对所有a to b和b to a的clk做两者之间快时钟周期的0.7倍 max_delay检查。

因为这是异步时钟域的检查,所以可以ignore 所有的clk latency。只关注dataPath的maxDelay

        在设置了max_delay的约束之后,综合和布局布线工具不一定能满足所有的约束,这时就会像setup检查一样出现violation【max_delay vio】,根据vio报告设计人员确认哪些需要后端去迭代或者手动去修,哪些不需要修改

        maxdelay和setup检查的path Type都是max,但不同的地方是,setup检查data required time是来自(clk path delay - lib setup) 时间;而maxdelay的data required time是设置的(maxDelay - lib setup)时间。

那么就有两个问题:

  1. 为什么要做max_delay的检查
  2. 如果有不同名字的clk 原本是同步时钟域 该怎么办
  3. 如果有异步电路不能满足0.7倍的fastclk maxDelay检查该怎么办?

带着这些问题我们进入下一节。

2.cdc maxDelay的原因及relax

任何异步处理有三方面需要考虑

一、防止或减少不定态的出现和传播

二、保证功能的正确性

三、保证性能不受损失

这里首先介绍异步处理的几种常见电路

2.1 基础异步处理电路

2.1.1 2级或以上的寄存器打拍(下面就以2级为例)

        寄存器打拍本身不能保证captureCLK的capture数据是正确的,只能降低不定态传播,要求同步器内和launchLCK的寄存器都尽量靠近

        要保证功能正确,就要求被同步的数据是准静态或静态数据,也就是说在电路中 可以保证只有在launchCLK域数据稳定后,captureCLK时钟域才会使用这个数据(而不是稳定后才capture,因为很难确认launch data何时稳定,只需要用的时候保证数据稳定了很长一段时间)。

2.1.2 有效信号同步,数据不做同步(Dmux)

        有效信号的同步首先就需要2级同步器,其次有效信号本身需要附加条件才可以保证数据同步过去是正确的,条件如下:

  1. 在有效信号同步过程中,被同步数据不能改变。
  2. 数据信号的变化到达dst寄存器时间要比有效信号同步器输出端稳定检测的延迟时间短
  3. 多bit数据信号在后端尽量相同的布线

        对于第二点,有效信号经过2级或3级同步器,到被dst稳定检测,相应需要1T(capclk)+T(setup-capclk)+T(hold-capclk)【2级同步器最快输出】或2T(capclk)+T(setup-capclk)+T(hold-capclk)【三级同步器最快输出】。所以data数据的跨clk maxDelay设为0.7 fastclk肯定是满足的。关键在于很多时候由于data maxDelay不满足0.7 fastclk.这时就可以根据第二点的要求来放松data maxDelay的限制。这也是2.4节 maxDelay Relax的理论基础。

2.1.3 grayCode做指针同步的异步FIFO

        grayCode同步是需要nbit的2级同步器,同时要求在captureCLK capture时最多只有1bit数据在变化,其他bit位全部稳定。比如虽然grayCode在launchCLK是最多一个clk变化1bit,但是如果前后两个launchCLK的2个bit的变化经过不同的delay同时到达了captureCLK,那么在captureCLK看到的就是两个bit同时变化,这样AsyncFIFO的虚空虚满就不正常,会出现fifo中的数据被错误覆盖或错误使用。

        另一方面,考虑性能不受影响 需要合理的设置异步fifo的深度

        现在的经验是如果里面的指针同步使用2级同步器,AsyncFifo深度设置为8,使用3级同步器,AsyncFifo的深度设置为10.在分析深度保证不断流的最差情况,是假设读写频率相同 相位差接近1个Tclk。这里的不断流是指,不停写afifo端不会因afifo full而被反压;读afifo端不会afifo empty而没有数据。不选择afifo两边有频率差的情况来分析是因为频率快的那一侧肯定不可能一直不断流,分析起来没有意义。

至于具体的计算过程,有时间再开贴分析。

多bitgrayCode指针信号在后端尽量相同的布线

2.2为什么要做maxDelay检查

  1. maxDelay检查的总体要求是launch FF 和 capture FF的距离不要太远,整个Tco+走线延迟+组合路径延迟小于maxDelay设置的period, 这样capture clk的一个时钟周期内能够采样到变化的数据。
  2. 同时保证了data比vld更早稳定
  3. maxDelay保证了格雷码同步的要求,即在captureCLK采样时,只有1个bit是不稳定的

假设grayCode从fastclk clk_a同步到slow clk_b,考虑最恶劣情况,在clk_a中连续两个时钟clk_a(n-1)和clk_a(n)时刻分别有2bit发生了变化,由于设置了maxDelay为fastCLk的0.7倍,那么在采样clk_a(n)的bit变化时,clk_a(n-1)的变化早就已经稳定了至少0.3period(clk_a)的时间。所以此时采样虽然有2bit变化,但clk_a(n-1)的变化已经稳定,实际上最多只有最新的bit变化可能没被正确采样,但是由于AsyncFiFo的虚空虚满特性并不影响功能实际并不会出错。

也可以用公式来描述:

设t0时刻src_gray_code[0]发生变化,t0+tf(tf为fastCLk的周期)时刻src_gray_code[1]发生变化,dst_clk在t0+x时刻第一次采样src_gray_code的变化,如果要满足此时两个bit都不满足dst_clk的setup,则需同时满足以下的条件

0<t_{0}+x-(t_{0}+a\times t_{f}) < t_{setup}

0<t_{0}+x-(t_{0}+t_{f}+b\times t_{f}) < t_{setup}

化简可得:

0<x-a\times t_{f} < t_{setup}

0<x-(1+b)\times t_{f}< t_{setup}

进一步需要满足下面两个条件

a\times t_{f} <x< t_{setup}+a\times t_{f}

(1+b)\times t_{f}<x< t_{setup}+(1+b)\times t_{f}

最终要求如下:

(1+b)\times t_{f}<x< t_{setup}+a\times t_{f} \rightarrow公式(1)

进一步:

 t_{setup}>(1+b-a)\times t_{f} \rightarrow公式(2)

其中a,b都是delay系数 最大0.7,所以最差情况下a=0.7,b=0要求:

t_{setup}>0.3\times t_{f} \rightarrow公式(3)

但在同一工艺下

t_{setup} <0.3 t_{f}是很容易满足的,这个结论和"clk_a(n-1)的变化早就已经稳定了至少0.3period(clk_a)的时间"一致。

这样公式(1,2,3)就是不可能满足的,所以在maxDelay的约束下 不可能在dst_clk采样的时候同时有两bit以上的变化不满足setup,也就是说最多只有1bit不满足setup,而单bit错采并不会引起功能错误。

同理可分析grayCode从slow clk_b同步到fast clk_a的情况。可以得到相同的结论,在任意captureCLK采样时刻,只有1bit是不稳定的,即使在两个captureCLK之间有多个bit的变化。

hold的分析也是一样 这里就不在赘述

2.3 如果有不同名字的clk 原本是同步时钟域 该怎么办

        如果clk_a0和clk_a1原本是同步时钟域,在cdc check时因为clk name不同而做了maxDelay的检查,如过clk_a0和clk_a1之间的maxDelay检查不能满足,那就要relax这种类型的检查,可以直接设

clk_a0 to clk_a1和clk_a1 to clk_a0的path为falsePath。

如果maxdelay检查没有问题,就无需关注。

2.4 如果有异步电路不能满足0.7倍的fastclk maxDelay检查该怎么办?

0.7倍的fastCLK周期 约束是相当严格的,很多情况下并不能满足,这时我们具体电路具体分析:

1.对于2级同步寄存器

        由于本来就是对准静态和静态的信号同步,信号基本没有变化,所以Launch FF到capture的FF并没有很严格的maxDelay需求,此时可以设置falsePath或者放宽该条path的maxDelay period。

2.regArray的asyncFIFO的数据存储阵列reg_data_array

        在launch clk写数据到reg_data_array,当读端通过地址指针grayCode同步后发现reg_data_array上不空时,可以在capture直接采样reg_data_array的输出。

        这里面可以看出来,grayCode同步到读端至少需要2个Tcaptureclk,所以对reg_data_array的maxdelay就可以放松至1.5T_capture,如果是3拍同步器可以放松至2T_capture.

3.Dmux同步

        有效信号先在clk_a打了一拍,在经过2级同步器同步到clk_b,再在clk_b打一拍,后使用。那么对应的data可以设置maxDelay为1T_launch+2T_capture+1ns。

这种常用在apbSync,nic里面的bridge的addr和data上。可以根据实际电路对这些cell进行relax

4.如果grayCode不能满足0.7 maxdelay

        这种情况下 只能靠后端来修timing,这个是必须meet的,否则grayCode就没有意义了。

5.握手同步

        这种可以看成是双向dmux同步,对data的maxDelay约束比Dmux同步更宽松。

  • 4
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值