异步电路后端实现流程(cdc signOff 后端做什么)
一种后端异步电路的signOff流程
同步电路和异步电路分别signOff
对于同步电路，后端会分析sta setup/hold，这里不在赘述。在该scenario下 异步电路是不会分析，也不会关注异步电路之间的走线
在cdc scenario(mode)下sdc有一下设置：
将所有同名的clk之间的path都设为falsePath
该scenario下不检查同步电路的sta
对所有不同名的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。
那么就有两个问题：
为什么要做max_delay的检查
如果有不同名字的clk 原本是同步时钟域 该怎么办
如果有异步电路不能满足0.7倍的fastclk maxDelay检查该怎么办？
带着这些问题我们进入下一节。
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检查
maxDelay检查的总体要求是launch FF 和 capture FF的距离不要太远，整个Tco+走线延迟+组合路径延迟小于maxDelay设置的period， 这样capture clk的一个时钟周期内能够采样到变化的数据。
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周期 约束是相当严格的，很多情况下并不能满足，这时我们具体电路具体分析：
对于2级同步寄存器
由于本来就是对准静态和静态的信号同步，信号基本没有变化，所以Launch FF到capture的FF并没有很严格的maxDelay需求，此时可以设置falsePath或者放宽该条path的maxDelay period。
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.
一些握手同步
有效信号先在clk_a打了一拍，在经过2级同步器同步到clk_b,再在clk_b打一拍，后使用。那么对应的data可以设置maxDelay为1T_launch+2T_capture+1ns。
这种常用在apbSync,nic里面的bridge的addr和data上。可以根据实际电路对这些cell进行relax
如果grayCode不能满足0.7 maxdelay
这种情况下 只能靠后端来修timing，这个是必须meet的，否则grayCode就没有意义了。