1. 为什么跨时钟域是数字IC设计中绕不开的坎
做数字IC设计这几年，我面试过不少人，也带过不少新人，发现一个很有意思的现象：简历上写着“熟悉异步FIFO设计”的候选人，追问到“为什么格雷码判空满能保证安全”时，往往就开始含糊其辞了。这不怪大家，因为跨时钟域处理本来就是数字IC设计里为数不多的、既要懂电路物理本质、又要懂工程妥协艺术的领域。
先把这个话题的适用范围说清楚。所谓的“同步时钟”和“异步时钟”，指的并不是晶振数量，而是时钟之间是否存在确定的相位关系。如果两个时钟来自同一个PLL、频率相同或成整数倍、相位对齐，或者即使有偏移但关系可以预测，那它们是同步时钟，数据在它们之间传递时通常只需要时序约束就行。但如果是两个独立晶振、两个独立PLL出来的时钟，或者频率比不是整数倍，那它们就是异步时钟——相位完全随机、频率可能有微小漂移，数据在它们之间传输时就会踩进亚稳态这个坑。
这里面的关键在于：亚稳态一旦出现，不仅当前这一拍的数据是错的，还可能把错误传播到后面的逻辑里。从工程角度看，一个触发器能恢复回稳态，但恢复时间是不确定的；从功能角度看，你在另一个时钟域里拿到一个“不高不低”的电平，下游组合逻辑可能把它当0也可能当1，甚至不同路径上的逻辑会得到相反的结果——这才是最致命的，因为这种不一致会撕裂整个设计的状态。
所以跨时钟域处理，本质上做的事情只有一件：把不确定性控制住，让它不扩散。同步器解决“单bit电平”的不确定，脉冲同步器解决“单bit事件”的不确定，异步FIFO解决“多bit数据”的不确定，握手协议解决“数据与请求/应答时序关联”的不确定。这篇文章我打算从最基础的亚稳态讲起，一路讲到异步FIFO的格雷码判空满，最后整理一份面试和工程都能用的速查。标题写了“待更”，说明这本身就是一个长期更新的系列，我会一步步把它写完。
2. 先从根源说起：亚稳态到底是什么、为什么它会传播
2.1 建立时间和保持时间窗口里发生了什么
每个触发器都有两个时间参数：建立时间（setup time，简称Tsu）和保持时间（hold time，简称Th）。数据必须在时钟沿到来前的Tsu时间内稳定，并且一直保持到时钟沿之后的Th时间，触发器才能可靠地采样到正确值。
如果你把数据的变化点恰好扔进了Tsu到Th这个窗口里，触发器内部的锁存节点就会进入一种介于0和1之间的中间状态——这就是亚稳态。从波形图上看，Q端既不是干净的高电平也不是干净的低电平，而是一个“诡异的中间电压”，并且这个电压还会振荡一段时间才稳定下来。稳定下来后的值可能是0也可能是1，完全不可预测。
这里最容易被忽略的一点是：亚稳态的恢复时间是没有上届的。虽然绝大多数情况下触发器会在几十皮秒到几纳秒内恢复，但理论上是无限长。这意味着你在下一个时钟沿采样它的时候，它可能已经稳定了，也可能还在振荡——你怎么等都不安全。
2.2 单bit亚稳态和总线亚稳态的差异
很多人以为亚稳态只是个“单bit问题”，大不了这一位错了。但如果亚稳态信号进入的是一个多位总线的使能端，或者进入组合逻辑后分叉成多条路径，问题就大了。
举个实际例子。假设一个8bit计数器要从快时钟域传到慢时钟域，你直接让8bit信号穿过时钟域，每个bit各自打两拍。在采样窗口内，8个bit可能有的被采到新值、有的被采到旧值，于是慢时钟域看到一个“四不像”的中间值——比如计数器从127跳到128，你却收到了0xFF。这种错误不是“数据晚了一拍”的问题，而是数据本身被完全破坏了。
所以单bit和多bit的处理方法是截然不同的。单bit适合用同步器或脉冲同步器，多bit要么用异步FIFO、要么用握手协议、要么用格雷码编码后的指针。如果你试图用一个“万能方案”处理所有跨时钟域场景，大概率会在某个极端情况下翻车。
2.3 亚稳态的平均无故障时间：MTBF怎么算
面试里问MTBF的题目不少，但真正让面试官满意的答案，通常需要你理解公式里每一项的含义。两级同步器的MTBF近似公式：
MTBF ≈ e^(t_r / τ) / (T_0 · f_clk · f_data)
其中：
- t_r：同步器允许的额外解决时间（resolve time），即从采样到下一拍之间的时间余量
- τ：触发器的亚稳态时间常数，工艺库里有，典型值几皮秒
- T_0：触发器的亚稳态窗口参数，典型值几百飞秒到几皮秒
- f_clk：采样时钟频率
- f_data：异步数据的变化频率
从这个公式能读出几个工程结论：
- t_r越长，MTBF呈指数级增长。这就是为什么高可靠性设计会用三级同步器而不是两级——多出来的一拍让解决时间翻倍，可靠性提升好几个数量级。
- 数据变化频率越高，亚稳态越频繁。所以“信号平时几乎不变，偶尔变一次”和“每个周期都在翻转”这两种情况，需要的同步器级数是不同的。
- 工艺越先进，τ越小，亚稳态恢复越快。但这不代表你可以不用同步器，因为先进工艺下时序余量也更紧张。
我做过的某个MCU项目里，32kHz的低速时钟域和64MHz的高速时钟域之间有个唤醒信号，用的就是两级同步器，MTBF算出来远超芯片寿命。但如果这个信号是高频翻转的——比如PWM输出——那两级同步器就不够看了，得专门设计。
3. 单bit跨时钟域的经典方案：两级同步器原理与边界
3.1 两级同步器为什么是“两级”而不是“一级”
两级同步器是跨时钟域处理里最基本的单元，结构非常简单：异步信号进来，先打一拍到同步时钟域，再打一拍输出。
第一级触发器的输入是异步信号，它可能会进入亚稳态。大多数情况下，第一级触发器会在一个时钟周期内恢复稳定。第二级触发器的作用，就是在“第一级可能还在振荡”的时间段之后，再去采样一次，此时第一级的输出基本已经稳定了。所以第二级触发器采到一个亚稳态信号的概率，约等于“亚稳态持续超过一个时钟周期”的概率，这个概率极其低。
为什么不直接用一级？因为一级同步器只是把异步信号变成了同步时钟域的寄存器输出，但它本身仍然可能输出亚稳态电平，下游逻辑没法安全使用。为什么不用三级？三级确实更保险，但代价是多一拍延迟，而且对绝大多数应用来说两级已经绰绰有余。只有在可靠性要求极高的场景下（比如航天、汽车安全），才会考虑用三级。
3.2 写RTL时容易被忽略的细节
两级同步器的RTL代码很简单：
module sync_2ff #( parameter WIDTH = 1 ) ( input wire clk, input wire rst_n, input wire [WIDTH-1:0] async_in, output wire [WIDTH-1:0] sync_out ); reg [WIDTH-1:0] sync_ff1; reg [WIDTH-1:0] sync_ff2; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin sync_ff1 <= {WIDTH{1'b0}}; sync_ff2 <= {WIDTH{1'b0}}; end else begin sync_ff1 <= async_in; sync_ff2 <= sync_ff1; end end assign sync_out = sync_ff2; endmodule但代码只是最表层的，真正的坑在约束和后端实现里：
- 必须在SDC里对同步器路径设false path或set_clock_groups。否则工具会试图去约束这条根本无法满足的跨时钟路径，导致时序收敛困难甚至乱优化。你见过综合工具报出一堆“violation”结果你一查全是CDC路径吗？这里的原因就是没有正确定义异步时钟关系。
- 同步器的两个触发器必须放得很近。如果布局时把两级触发器放得太远，从第一级Q端到第二级D端的走线延迟太大，第二级采样的裕量就会变小，亚稳态逃逸概率反而上升。后端实现时通常需要加set_multicycle_path或者专门的同步器单元。
- 复位值要慎用。如果同步器输出给的是异步复位信号，那没问题；但如果是普通数据信号，复位时同步器输出0，不等于输入端就是0，这个逻辑关系要设计清楚，别让复位信号本身也变成异步问题。
- 务必加综合属性。用
(* async_reg = "true" *)声明这两个寄存器，防止综合工具把它们当普通寄存器合并、复制或者优化掉。
3.3 两级同步器不能处理的场景
两级同步器能处理的是“电平信号”，也就是信号会保持足够长时间、直到对端能采到它。它不适合处理如下两种场景：
场景一：脉冲信号。快时钟域一个仅维持一个周期的高脉冲，如果直接同步到慢时钟域，慢时钟很可能根本采不到这个脉冲——它出现的时候慢时钟沿还没来，等慢时钟沿来时脉冲已经消失了。这种场景需要“脉冲同步器”，我们下一节讲。
场景二：多bit并行数据。哪怕你把8bit数据各打两拍，也无法保证8个bit同步变化。实际上快时钟域的8bit从“全0”变到“全1”时，每个bit到达慢时钟域采样寄存器的时间不可能完全一致，结果是慢时钟域可能采样到部分新值、部分旧值。这不是亚稳态问题，而是数据一致性问题，需要靠FIFO或握手来解决。
判断能不能用两级同步器，有个简单的实用标准：发送端的信号变化间隔，是否远大于接收端的采样周期？如果答案是肯定的，并且信号是单bit电平，那么两级同步器就是你的最优解。
4. 脉冲同步器和握手协议：事件跨时钟域的两种思路
4.1 快时钟到慢时钟：脉冲同步器的经典结构
如果快时钟域有一个单周期脉冲需要传到慢时钟域，直接打两拍大概率会丢脉冲。这时常用的方法是把“脉冲”变成“电平”传过去，再在对端把电平还原成脉冲。
经典的脉冲同步器结构包含四个部分：
- 发送端脉冲转电平：用一个Toggle触发器，每个脉冲到来时翻转一次输出电平。
- 两级同步器：把这个缓慢变化的电平信号同步到接收时钟域。
- 接收端电平转脉冲：对同步后的电平信号打一拍，检测上升沿或边沿，产生单周期脉冲。
- 反馈（如果需要）：某些设计里接收端还要反馈一个确认信号给发送端，确保电平变化被正确接收后再发下一个。这其实就是握手的雏形。
RTL核心代码如下：
// 发送端：脉冲转电平 reg toggle_ff; always @(posedge clk_a or negedge rst_n) begin if (!rst_n) toggle_ff <= 1'b0; else if (pulse_a) toggle_ff <= ~toggle_ff; end // 接收端：两级同步 + 边沿检测 reg sync_ff1, sync_ff2, sync_ff3; always @(posedge clk_b or negedge rst_n) begin if (!rst_n) begin sync_ff1 <= 1'b0; sync_ff2 <= 1'b0; sync_ff3 <= 1'b0; end else begin sync_ff1 <= toggle_ff; sync_ff2 <= sync_ff1; sync_ff3 <= sync_ff2; end end assign pulse_b = sync_ff2 & ~sync_ff3;这个结构能工作的前提是：两个脉冲之间至少间隔接收时钟两个周期以上，否则电平翻转可能合并，导致漏检或重复检测。如果发送端可能连续快速发脉冲，必须在发送端做流量控制，比如等待接收端的“收到”反馈。
4.2 慢时钟到快时钟：直接打两拍通常就够
慢时钟域的信号本来就比快时钟域“宽”，所以慢时钟域的脉冲传到快时钟域后，通常能持续多个快时钟周期，快时钟域打两拍肯定能采到。但要注意一个问题：慢时钟域信号宽度如果恰好只比快时钟域一拍多一点，极端情况下可能采样两拍后正好错过沿——概率极低但并非为零。严谨的设计里仍建议用脉冲同步器统一处理，只是这种场景下两级同步器往往也能凑合。
另一个更隐蔽的问题是：慢时钟域的信号变化频率不高，但它和快时钟沿之间的相位关系是随机的，所以两级同步器的第一级仍然可能发生亚稳态。别因为“慢到快没风险”就松懈，亚稳态的风险来自事件和采样沿的相位随机性，而不是来自谁的频率高。
4.3 握手协议：请求应答四步走的工程本质
如果需要在两个时钟域之间传多bit数据，但数据量不大、频率不高，用异步FIFO显得过重，用裸同步器又不可靠，这时可以用握手协议。
四段式握手（full handshake）的工作流程：
- 发送域把数据放到总线上，然后拉高req信号。
- 接收域同步req（两级同步器），确认无误后采样数据总线，然后拉高ack信号。
- 发送域同步ack，确认接收完成，拉低req，表示可以发下一笔。
- 接收域同步req的低电平，确认发送端已经撤销请求，拉低ack，回到初始状态。
这里最关键的一点是：接收域采样数据总线的时刻，必须是在同步后的req信号稳定为高之后。也就是说，req经过了至少两个接收时钟周期的同步延迟，此时数据总线早已稳定，接收域可以安全采样。
握手协议的优点是通用性强、逻辑简单、不需要FIFO深度规划。缺点是传输延迟很大——请求同步要两拍、反馈同步要两拍、撤销请求再同步要两拍……来回加起来可能有七八拍甚至更多。所以握手协议适合小数据量、低吞吐场景，不适合高速流式传输。
4.4 握手协议的工程雷区
握手协议看起来简单，实际项目里翻车的概率反而不低：
- 数据信号也要约束。数据总线虽然不需要同步，但它必须在接收域的采样窗口内保持稳定。实现上通常要求发送域在req拉高之前就把数据准备好，并且保持到ack回来。这个时序如果做不好，就会采样到毛刺。
- req和ack必须是电平信号。很多人习惯用脉冲做握手，这在跨时钟域里是灾难——脉冲可能被漏采。一定要用电平握手，或者把脉冲先转成电平。
- 状态机的跨时钟域路径要收敛。握手状态机里的req/ack信号在进状态机之前必须先经过同步器，不能直接把异步信号送进状态机做组合逻辑判断。
- 握手的性能瓶颈：从req拉高到看到ack拉高，最坏情况要经过“接收域两级同步 + 发送域两级同步”共四拍延迟。如果应用要求低延迟，就得考虑异步FIFO。
5. 多bit数据跨时钟域的核心方案：异步FIFO的设计
5.1 为什么异步FIFO是多bit流的“默认答案”
多bit数据流、高吞吐、连续传输——这种场景下握手协议的效率太低，直接同步多bit数据又会撕裂数据一致性。异步FIFO几乎是唯一的标准解。
异步FIFO的精髓在于：数据本身不进行跨时钟域同步，真正跨时钟域的只有读写指针。数据从写端口写入SRAM，从读端口读出，只要读写地址不冲突，数据就是安全的。而读写指针的跨时钟域比较，则通过格雷码编码来保证安全。
读指针经过两级同步器进入写时钟域后，与写指针比较产生full信号；写指针经过两级同步器进入读时钟域后，与读指针比较产生empty信号。因为格雷码的相邻状态只有1bit变化，所以同步时最多只有一位处于亚稳态，而这位一旦稳定，指针要么是旧值、要么是新值，绝不会出现“非格雷码的非法值”。
5.2 格雷码的数学性质与代码实现
普通二进制计数在多bit翻转时，同步器采样到的中间状态完全不可控。格雷码则保证每次状态变化只有1bit翻转。对应到FIFO指针上，就是深度为2^N的FIFO，指针用N位格雷码表示（实际需要N bit，但内部还需要一个额外的位用于区分满和空，后面说）。
一个FIFO深度为2^N的经典设计，指针位宽为N+1。最高位用于区分“读完一圈”的状态，低N位用于寻址。写指针和读指针都采用格雷码，比较规则是：
- 读空条件：读指针经过同步后，等于当前写指针的格雷码值，即读追上了写。
- 写满条件：写指针追赶读指针又超过一圈，即写指针的最高位不同于读指针的最高位，而其余位完全相同。
这个条件写成RTL：
// 空条件 assign empty = (rd_ptr_gray == wr_ptr_gray_sync); // 满条件 assign full = (wr_ptr_gray == {~rd_ptr_gray_sync[ADDR_WIDTH], rd_ptr_gray_sync[ADDR_WIDTH-1:0]});实际工程中，我见过不少人在这个条件上栽跟头。满条件的理解是：写指针跑得比读指针快了一整圈。如果不扩展最高位，深度为8的FIFO，读指针走到7、写指针走到7，你会误判为“空”，但其实写指针是第二次到达7，此时FIFO是满的。增加最高位后，写指针为1_111，读指针为0_111，最高位不同、其余位相同，于是正确判满。
5.3 读写指针的同步延迟和悲观机制
异步FIFO判断空满不是绝对精确的，而是“悲观”的。因为指针同步需要时间，所以：
- 空信号可能偏悲观：读时钟域拿到的写指针是“两个读时钟周期之前的写指针”，如果此刻读指针刚好追上它，读时钟域会认为FIFO空了（实际上写端可能刚写入新数据）。这种“虚假空”不会导致数据错误，只会让读端暂停一拍，但这是安全的。
- 满信号可能偏悲观：同理，写时钟域拿到的读指针是滞后的，可能认为FIFO满了（实际还有空间）。这种“虚假满”导致写端停写，同样安全。
这种悲观机制是异步FIFO能跑起来的基础：宁可错判空满，绝不错发数据。把同步器的不可靠性转化为“宁可慢一点也不能错”的工程行为，这是异步FIFO设计中最核心的哲学。
5.4 异步FIFO的参数计算和应用建议
选多少深度？这需要根据“写突发长度”和“读突发长度”来算。
一个粗略的公式：
FIFO深度 ≥ 写突发长度 - 读突发长度
更精确的计算要考虑读延迟。比如写入端在一个突发里连续写N个数据，读出端每拍最多读1个，但从“EMPTY拉低”到“首笔数据可用”之间存在读延迟latency（通常为2~3拍）。这时最小深度大约是：
FIFO深度 = N - (N / f_write_clk * f_read_clk) 的整数部分 + latency + 余量
实际操作中，我会先根据吞吐需求估算一个初值，然后用仿真验证：在极端背压场景下发最长的突发，观察depth是否够用。前后仿真都过了，再回头看面积——FIFO深度宁可多给一点，也别在流量峰值时打满导致丢数。面积换功能安全，在CDC设计里永远是划算的买卖。
5.5 异步FIFO后端实现的关键：时序约束
RTL写得再漂亮，约束做不好异步FIFO依然会出问题。异步FIFO里有几条关键路径必须正确约束：
- 写指针到读时钟域同步器的路径：这是真正的异步路径，需要设为false path或者set_clock_groups -asynchronous。
- 读指针到写时钟域同步器的路径：同上。
- 格雷码指针到RAM地址译码器的路径：这条路径在各自时钟域内部，必须有正常的时序约束，不能用false path。
此外，现在的综合工具基本都能自动识别异步FIFO结构（比如Design Compiler里的cdc_async_fifo），但工程师依然要手写约束做兜底。我的习惯是：在RTL里手动例化同步器并加上async_reg属性，让工具尽量不干预这些寄存器的位置和优化，这比完全依赖工具自动识别要稳得多。
6. 跨时钟域设计与验证流程：从RTL到后端的完整闭环
6.1 RTL设计阶段的CDC规范
很多公司在CDC设计上有明确的RTL规范，我总结几条最实用的：
- 所有跨时钟域的同步器必须由统一风格的模块封装，禁止到处手写打两拍。统一封装的好处是约束可以集中管理，review代码时一眼能找到所有CDC点。
- 数据信号和它们的使能/握手信号要成组跨越时钟域，不要只处理数据却不处理控制信号。
- 时钟信号不能通过寄存器逻辑分频后再当异步时钟用。时钟必须由PLL/MMCM等专用时钟资源产生，逻辑时钟分频会引入毛刺，属于严重的时钟问题。
- 异步信号进入同步器之前不能再经过组合逻辑。比如你不能让异步信号先经过一个反相器再进同步器——最好直接连到同步器的D端，如果确实需要逻辑，必须在发送时钟域里先处理好。
6.2 验证阶段的CDC检查方法
RTL写完后，光靠功能仿真发现不了所有CDC问题，因为仿真器默认触发器是理想器件，不会对你展示亚稳态。如果没有特殊手段，RTL功能仿真里跨时钟域路径看起来永远是“对的”，这就极其危险。好在主流流程里有三道关卡：
第一道：CDC静态检查工具。比如Cadence的Meridian CDC、Synopsys的SpyGlass CDC，它们会做结构化检查，报出每条跨时钟路径、检查是否有同步器、检查握手逻辑是否完备。工具能抓出很多人工审查容易漏的问题，比如“这个寄存器被两个不同时钟域的时钟驱动”“这条路径跨越时钟域但没有同步器”。这是最省力的手段。
第二道：形式化CDC验证。有些团队会再用形式化工具证明同步器的管线正确性，确认异步FIFO的空满逻辑完备。这一般是大型芯片项目才会做，但对设计质量确实有很大帮助。
第三道：带亚稳态注入的仿真。在仿真环境里给异步信号加上随机延迟，甚至用$rose配合随机slew来模拟亚稳态窗口。这种仿真比普通功能仿真更能暴露采样时序问题。用SystemVerilog的随机延迟来做约束随机激励，是我比较推荐的做法。
6.3 后端布局布线阶段的CDC注意事项
到了综合和布局布线阶段，CDC问题照样会冒出来，常见的有：
- 同步器寄存器被布局工具拉开。现代布局工具通常能识别同步器结构并自动拉近，但前提是RTL里加了
async_reg属性。如果忘记加，工具可能把两级触发器放得很远，导致解决时间不足。 - 时钟树偏差影响同步器。同步器前一级和后一级如果时钟到达时间差异大，同样会影响有效解决时间。
- 跨时钟域路径被错误约束。如果SDC里把异步路径设成了需要满足setup/hold的路径，工具会为了收敛而插入大量buffer，浪费面积甚至无法收敛。反过来如果该约束的路径没约束，工具又可能把同步器的位置优化到完全不可控。
所以我的建议是：后端约束文件和RTL设计同步review，不要在布局布线阶段才想起来检查CDC约束。等工具报出几十条violation再回头看RTL，改起来不仅痛苦，还可能引入新的功能问题。
6.4 面试常见的跨时钟域问题速查
这部分送给准备数字IC面试的朋友。跨时钟域几乎是每一轮技术面试的必考板块，我按出现频率整理如下：
Q1：亚稳态是什么？如何消除？回答要点：亚稳态是触发器在setup/hold窗口内采样导致输出处于中间态的现象。无法完全消除，只能降低概率。方法包括：两级/三级同步器，降低数据变化频率，提高同步器解决时间，使用专用同步器单元。
Q2：两级同步器为什么能降低亚稳态？回答要点：第一级可能进入亚稳态，但大多数情况下在一个时钟周期内恢复；第二级在下一拍采样时，第一级输出已稳定。只有在亚稳态持续时间超过一个时钟周期时，第二级才会采到亚稳态，这个概率极低。
Q3：快时钟域到慢时钟域传脉冲怎么处理？回答要点：用脉冲同步器，脉冲转电平-同步-电平转脉冲。直接打两拍会漏采脉冲。
Q4：格雷码的优势是什么？为什么异步FIFO用格雷码？回答要点：相邻状态只有1bit变化，同步时最多一位亚稳态，不会产生非法组合值，因此判空满是安全的。
Q5：什么是异步FIFO的空满“悲观机制”？回答要点：因为指针同步需要时间，空满信号可能滞后/提前，但方向都是安全的方向——宁可判空/判满，也不发错数据。
Q6：两级同步器和三级同步器的选择依据？回答要点：取决于MTBF要求。三级同步器解决时间更长，MTBF指数级提升，但代价是增加延迟。普通消费电子两级足够，高可靠性场景考虑三级。
Q7：握手协议的缺点？回答要点：延迟大。从发送请求到确认完成，至少要经过多次两级同步周期；所以不适合高吞吐、连续数据流。
Q8：数据总线跨时钟域为什么不直接打两拍？回答要点：因为是多bit，每个bit的到达时间不一致，采样结果可能是非法组合值，数据被完全破坏。必须用异步FIFO或握手协议保持数据一致性。
7. 工程中的额外提醒与后续更新方向
跨时钟域处理是个典型的“看起来简单、做起来容易翻车”的领域。从我个人的经验来看，绝大多数CDC问题都不是因为原理没搞懂，而是在每一个小细节上妥协了一点点：这里忘了加约束、那里漏了一个属性、这里把异步信号顺手经过了一个组合逻辑……每一个都是小问题，但串在一起就会变成功能故障或者芯片回片后偶发失效。
做跨时钟域设计，我的核心体会是四个字：如履薄冰。每一个跨时钟域的信号都要白纸黑字记下来：它是什么类型，用哪种同步方案，约束加在哪个文件里，验证是怎么覆盖的。做到这个程度，基本就不会出大问题。
这篇文章里我把单bit电平同步、脉冲同步、握手协议、异步FIFO四大块都过了一遍。标题里写着“待更”，后续我打算补几个方向：一是复用CDCs在验证阶段的具体操作流程和脚本经验；二是结合异步FIFO的“实际数据流场景”讲一个完整案例；三是最新EDA工具里CDC自动化分析的能力边界。如果你在项目中遇到过什么奇葩的跨时钟域问题，欢迎在评论区留言，我看到会结合自己的经验补充进去。
