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

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

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

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

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

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

2. 对所有不同名的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。

那么就有两个问题：

1. 为什么要做max_delay的检查

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

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

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

2. cdc maxDelay的原因及relax

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

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

二、保证功能的正确性

三、保证性能不受损失

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

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

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

要保证功能正确，就要求被同步的数据是准静态或静态数据，也就是说在电路中 可以保证只有在launchCLK数据稳定后，captureCLK才会使用(而不是稳定后才capture)这个数据。

• 有效信号握手同步，数据不做同步

握手信号的同步首先就需要2级同步器，其次握手本身可以保证数据同步过去是正确的，但是前提条件是在握手过程中，被同步数据不能改变。

多bit数据信号在后端尽量相同的布线

另一方面考虑握手越快越好，那就要求launch FF 和capture FF间maxDelay不要过大

• 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.1为什么要做maxDelay检查

1. maxDelay检查的总体要求是launch FF 和 capture FF的距离不要太远，整个Tco+走线延迟+组合路径延迟小于maxDelay设置的period， 这样capture clk的一个时钟周期内能够采样到变化的数据。

2. 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的虚空虚满特性并不影响功能实际并不会出错。

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

2.2 如果有不同名字的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.3 如果有异步电路不能满足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. 一些握手同步

有效信号先在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就没有意义了。