前言
最近认识一位行业前辈，经过他的一番指点，我对于 CDC 又有了更深入的认识，在这里记录一下。
本文主要讲多 bit CDC的问题，是这篇文章和这篇文章的拓展。
格雷码的具体用途
在上篇文章中，我曾经写到格雷码也可以用作 CDC 中数据的传输，具体操作就是本时钟域的数据转换成格雷码后在目标时钟域打两拍，但这种说法是片面的。
我们暂且不提为什么这种说法是片面的，首先提出一个假设：多 bit 数据在 CDC 中如果有多位数据同时发生翻转，那么 CDC 必定失败。有的同学可能就会问了：格雷码不是可靠性编码吗，每次都只有一位会发生变化，不会出现多位同时翻转吧？
这么想你就错了。
格雷码每次只有一位发生变化的前提是，数据是递增或递减的。对于一个4位的数据，当它从2变到3的时候，格雷码的变化为：0011 -> 0010，只有一位发生了变化；但当它从2变到7的时候，格雷码的变化为：0011 -> 0100，低3位都变了！
我们在 CDC 中传输数据时，数据之间的关系是不确定的，我们无法保证数据一定是递增或递减的，也就无法保证使用格雷码时只有一位会发生变化，因此在多 bit 的 CDC 中不能随便使用格雷码打两拍的方法。
那么，在什么时候可以使用格雷码呢？很简单，只要我们能保证传输的数据是递增或递减的就可以了。异步 FIFO 中地址的传输就是一个很好的例子。由于 FIFO 是一个先进先出，不支持随机读写的 Buffer，因此它地址的变化一定是递增的，这时我们在判断空的时候就可以在读时钟域使用打两拍的方式同步写时钟域的地址指针了，只要转换成格雷码就行。
格雷码的另外一个典型应用场景就是定时器。因为 SOC 里定时器为了保证稳定好用，一般会使用独立时钟，避免在 CPU 频率变化时受到影响。在这种情况下，定时器的读数也是可以用格雷码传递的。
除了这些少数场景，别的地方都不太能用的上格雷码，更何况计数器为了节省逻辑还有设计成不是自然数序列计数的，就更没有用武之地了。
为什么在 CDC 中不能有多位数据同时翻转？
谈完了格雷码的应用场景，我们来说明一下为什么我们最初的那个假设会成立。
又要提到我前一篇文章中讲到的内容了：如果多位数据同时翻转，会因为线延迟的原因产生几个中间的不定态。你想把0变成15，那中间经历的过程可能是：0 -> 1 -> 5 -> 7 -> 15。CDC 的潜台词是两个时钟没有任何固定时序关系，即使不考虑亚稳态问题，那么对面也可能看到 1 / 5 / 7这几个不定态中的一个，造成数据写入的错误。我们希望数据在目标时钟域中还是多比特同步的，因此不能采用直接打两拍的方式。
另一个例子就是 CPU 的内核和总线。假设内核和总线处于异步时钟域，总线上有一个 respond ，00表示OK，11表示重传，01表示error；本来respond 00 -> 11，结果 CPU 看到01，直接爆出一个异常，软件就进行异常处理了。
当然，多比特的 CDC 也不是绝对不能这样打拍。对于那些可以忍受数据出现过程值的场景就没有问题，典型例子就是模块参数。
总结
在实际的设计中，我们应该具体情况具体分析，明白其中的风险和原理。稳妥的做法就是按最高标准处理，因为设计不代表全部，设计加约束才是完整的；按最高标准设计意味着无论约束怎么改变，你的设计都是 golden 的；如果要做简化设计，那要么对软件使用方式提要求，要么对约束提要求，一起配合才能不出问题。