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

本文主要是介绍异步电路后端实现流程(cdc signOff 后端做什么)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

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

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

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

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

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

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

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

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)时间。

那么就有两个问题：

为什么要做max_delay的检查
如果有不同名字的clk 原本是同步时钟域该怎么办
如果有异步电路不能满足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级同步器，其次有效信号本身需要附加条件才可以保证数据同步过去是正确的，条件如下：

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

对于第二点，有效信号经过2级或3级同步器，到被dst稳定检测，相应需要1T(capclk)+或2T(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。有时间再开贴分析。

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

2.2为什么要做maxDelay检查

maxDelay检查的总体要求是launch FF 和 capture FF的距离不要太远，整个Tco+走线延迟+组合路径延迟小于maxDelay设置的period，这样capture clk的一个时钟周期内能够采样到变化的数据。
同时保证了data比vld更早稳定
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}$