芯片设计-CDC-AC_conv

报告设计中的聚合问题。聚合问题有可能会引起数据一致性（data coherency）问题，即同步前的数据与同步后的数据不一致。

AC_conv01
AC_conv01规则报告来自同一域的信号，这些信号在同一目标域中同步，并在任意数量的时序单元后聚合。即信号经过同步器+寄存器后聚合违例。

Ac_conv01有两种不同情况。

case1：

如下图，不同信号经过同步器后又经过不同数量的寄存器，最终在同一个逻辑门处聚合。

在上面例子中，第一根信号经过二级同步器后经过一个寄存器，第二个信号经过二级同步器后经过两个寄存器。这两个信号最终在同一个逻辑门处聚合。为什么这样会有问题？假设两个信号在clk1时钟域有00->11的跳变，那么经过clk2时钟域的一堆寄存器后，在逻辑门处看到信号会有00->10->11的跳变，显然这样是不行的。如果确保两根信号不会同时跳变，就没有问题，例如00->01或00->10的跳变就不会有问题。

case2 

同一个信号经过多个同步器后又经过不同数量的寄存器，最终在同一个逻辑门处聚合。这种情况与上述情况类似。如下图。

特殊情况下不会报违例：两个信号由同一个控制信号控制

如果spyglass报出违例，但通过检查发现设计没有问题，可使用 cdc_false_path , quasi_static, cdc_filter_conherency等命令约束。

AC_conv02

AC_conv02规则报告信号经过同步器后且在时序单元（a flip-flop, latch, or sequential library cell)）前聚合违例：如下图三种情况。

case1：

如下图，不同信号经过同步器后在同一个时序单元前聚合。

case2：

如下图，同一信号经过同步器后在同一个时序单元前聚合（后面的时序单元未画出）。

注意这里报告违例的地方与AC_conv01不同，仔细看两张图。一个是在寄存器之后聚合，一个是在寄存器之前聚合。这里为什么会出问题？假设clk1时钟与信号有011->100跳变，由于各个路径延时不同，经过同步器后可能会产生011->110->100等奇怪的跳变。如果这个信号是个计数器，那么这样同步肯定有问题。解决办法就是使用格雷码编码，在同步之前，先将二进制编码转换成格雷码，再经过同步器。可以参考异步FIFO中的格雷码指针同步。

case3：

如下图，格雷码和非格雷码信号经过同步器后在同一个逻辑门处聚合。

在使用格雷码的设计中，可以使用cdc_gen_unrelated_coherency参数生成SGDC文件，其中包含cdc_filter_coherency和gray_signals约束。如下所示，生成的文件包含Ac_conv02违规的约束，这些违规至少有一个向量总线以及一个或多个标量信号或一个或更多向量总线：

cdc_filter_coherency -unrelated <list of synchronizers converging in Ac_conv02>
gray_signals -name <vector-bus-in-above-constraint-if-applicable>
gray_signals -name <next-vector-bus-in-above-constraint-if-applicable>

在上述例子中，sync[0:3]是使用格雷码同步的信号，sync_1是经过二级同步器同步的信号，它们在同一个逻辑门处聚合，spyglass会报出这里违例。如果确定sync_1与sync[0:3]信号没有关系，即这样的设计没有问题，当cdc_gen_unrelated_coherency参数设置为yes时，可使用如下约束脚本：
cdc_filter_coherenct -unrelated sync[0:3] sync_1
gray_signals -nam sync[0:3]

AC_conv03

规则检查不同时钟域信号经过同一个时钟域同步器后聚合在一个net上（跟AC_conv02差不多）。

然而，该规则在不同域信号收敛的门之外停止检查。下图说明了这种情况：