异步FIFO设计详解：跨时钟域、格雷码与空满判断实践

1. 从跨时钟域说起：为什么绕不开异步FIFO

做过数字IC或FPGA开发的工程师，迟早都会撞上跨时钟域处理这堵墙。两个时钟域之间要传数据，最直接的办法是用握手协议——请求、应答、再请求，简单可靠但吞吐量上不去，每次传输都要等对方回应。数据量大、速率要求高的场景下，握手就跟不上节奏了，这时候就该异步FIFO登场。

异步FIFO（Asynchronous FIFO）解决的问题非常明确：在两个频率不同、相位无关的时钟域之间，安全、高效、不丢数据地搬运数据。它不需要双方时钟同步，也不需要等对方应答，数据写入和读出可以同时进行，像一个蓄水池一样把两个时钟域的速率差异缓冲掉。

这个组件在工程里几乎无处不在：跨时钟域的指令队列、通信接口的数据缓存、多个异步模块之间的数据交换、串并转换过程中的中间缓冲，全都离不开异步FIFO。换句话说，只要系统里存在两个以上异步时钟域且有数据需要跨域传输，异步FIFO就是最常用的方案，没有之一。

这篇内容我按自己的实践脉络来写：先讲清楚为什么设计必须用格雷码、为什么空满判断要那样写、FIFO深度到底怎么算，再给出完整可用的代码结构、仿真验证思路和工程中常见的坑。无论是刚接触跨时钟域的FPGA新手，还是需要自己搭异步FIFO的IC设计工程师，这篇文章都能帮你少走几条弯路。

2. 异步FIFO的整体架构与核心设计思路

2.1 架构拆解：四大部分各司其职

一个标准的异步FIFO，从顶层看由四个部分构成：双端口RAM存储阵列、写指针逻辑与写时钟域控制、读指针逻辑与读时钟域控制、以及跨时钟域的指针同步与空满状态生成逻辑。

双端口RAM是整个FIFO的数据仓储中心，一端连着写时钟域，一端连着读时钟域。写侧在每个写时钟上升沿把数据写入指针指向的地址，读侧在每个读时钟上升沿把当前地址的数据读出。RAM本身完全异步，两个端口独立工作，互不干扰。

写指针每写入一个数据就递增一次，当写满一圈回到初始位置时，写指针等于读指针，此时表示FIFO已经写满，不能再写入。读指针每读出一个数据也递增一次，当读空一圈回到初始位置时，读指针等于写指针，此时表示FIFO已读空，不能再读出。

问题来了：判断空满需要比较读指针和写指针，但这两个指针分别活在两个不同的时钟域里。你没法在写时钟域里直接去采样读指针的当前值——因为读指针在读时钟域里不停地变，直接采样很可能采到一个中间状态，这就是传说中的亚稳态问题。

所以设计上必须把对方的指针同步到自己时钟域来比较。写时钟域判断是否写满时，需要把读指针同步到写时钟域；读时钟域判断是否读空时，需要把写指针同步到读时钟域。同步过来的指针天然有时钟域延迟，所以异步FIFO的空满判断永远是保守的——可能出现明明还有空间却判断为“满”的情况，但绝不会出现已经满了还往里写导致数据覆盖的情况。宁可错杀，不可漏判，这个设计原则是整个异步FIFO可靠性的根基。

2.2 同步器是一切的基石

跨时钟域最怕亚稳态。所谓亚稳态，就是触发器在时钟沿到来的瞬间，输入信号正好处在跳变过程中，导致触发器的输出既不是0也不是1，而是一个中间电平，并且这个状态需要不确定的时间才能稳定下来。更危险的是，亚稳态还可能传递——下游触发器采样到这个不稳定输出，自己也跟着进入亚稳态，像多米诺骨牌一样扩散。

解决亚稳态的标准做法就是触发器同步链，也叫同步器。最常见的就是两级D触发器串联：数据从A时钟域过来，先打一拍进入第一个触发器，再打一拍进入第二个触发器，然后才用于后续逻辑。两级同步之后，亚稳态传播到后级的概率已经被指数级压低，在大多数工程场景下足够安全。

第一级触发器虽然仍可能进入亚稳态，但下一拍到来之前（通常是两个时钟周期的时间裕量），它大概率已经稳定下来了，第二级采到的就是稳定值。等效MTBF（平均无故障时间）可以达到几百上千年，工程上完全够用。

我常见的做法是在两级基础上再加一级，也就是三级同步器，用于高可靠性场景或者频率特别高的场合。但注意，同步器的级数并非越多越好——每一级都带来真正的延迟，这会让空满判断更加保守，直接缩小FIFO的有效工作区间。两级已经能满足绝大多数需求，除非你有特殊需求或者在做超高可靠性的设计，否则不用盲目加级数。

2.3 为什么格雷码是异步FIFO的必选项

假如同步器同步的是普通二进制指针——比如读指针从011变为100，三个bit同时翻转。但数字电路里bit翻转从来不是同时发生的，可能bit0先变、bit1后变、bit2最后变，于是同步器看到的是一个中间乱码状态：101、110、111都有可能。更要命的是，这个乱码状态被打到第二个触发器里并保持住，错误就被永久锁存了。

二进制指针跨时钟域同步，根本问题在于多位信号同时跳变，无法保证采样一致性。格雷码（Gray Code）就是针对这个问题来的——它的核心特性是相邻两个值之间只有一位bit发生变化。例如二进制011→100对应格雷码010→110，只有最高位变了，其余位不变。

这样就把“多位同时翻转导致采样混乱”的问题从根本上消灭了：跨时钟域采样时，最多只有一位信号在跳变，同步器采到的值要么是变化前的格雷码，要么是变化后的格雷码，绝不会出现第三种乱码状态。虽然可能采到旧值或新值，但至少值本身是正确的，不会出现凭空多出一个错误地址的情况。

格雷码只是让指针本身不被采错，但空的判断依然可能滞后一拍，满的判断也可能滞后一两拍——这正是前面说的“保守”策略的来源。稍后讲到空满生成逻辑时，这一点会体现得特别明显。

3. 格雷码转换与空满判断：藏在细节里的核心逻辑

3.1 二进制转格雷码的电路实现

二进制数转换为格雷码的规则非常简单：格雷码的最高位等于二进制数的最高位，其余每一位等于二进制数的对应位与其高一位的异或结果。写成公式就是：

gray[i] = bin[i] ^ bin[i+1] （i = 0, 1, ..., n-2） gray[n-1] = bin[n-1]

换算成Verilog代码就三行：

assign gray_write = (binary_write >> 1) ^ binary_write;

这里用了一个技巧：把一个数右移一位再与原数异或，一次就能完成所有位的转换。比如二进制数1101，右移一位变成0110，两者异或得1011，刚好就是1101对应的格雷码。这个写法比逐位异或简洁得多，实际工程里我基本都是这么写的。

很多刚接触的人会忽略一个问题：指针位宽到底取多少？比如FIFO深度为8，只需要3位地址，但指针必须用4位——因为判断空满需要额外一位状态位。这个状态位在格雷码里也发挥着作用，后面我会详细解释。

3.2 高两位判断法：空满其实比想象中简单

空满判断是整个异步FIFO设计的灵魂。用格雷码判断空满有两种常用方法，我在工程中一直用的是高两位判断法，它的逻辑直观、代码简洁，可靠度也足够。

先看空判断：当读指针同步到写时钟域之后，如果写指针和同步过来的读指针完全相等（包括充分扩展的高位），就说明FIFO已经空了，不能继续读。

再看满判断：当写指针和同步过来的读指针最高两位不同、其余位相同，就说明FIFO已经满了。为什么是“最高两位不同”？因为格雷码的计数特性——当写指针追着读指针走完一圈再次相遇时，格雷码的进位会体现为最高位的跳变。最高位不同、其余位相同，意味着写指针恰好比读指针多走了一整圈，也就是FIFO已经被写满了。

判断逻辑写出来就是这样的形式：

assign full = (write_gray[ADDR_WIDTH-1] != read_gray_sync[ADDR_WIDTH-1]) && (write_gray[ADDR_WIDTH-2] != read_gray_sync[ADDR_WIDTH-2]) && (write_gray[ADDR_WIDTH-3:0] == read_gray_sync[ADDR_WIDTH-3:0]);

这段代码一共就三行逻辑。但是要注意，这种判断法得到的空满信号是经过同步延迟的保守信号。写满信号在写时钟域产生，它依据的是同步过来的读指针，这个读指针可能已经比真实读指针落后了两拍。如果实际FIFO里还有空间但读指针同步还没到，就会提前报满——处理方式就是允许它提前报满，代价是FIFO实际工作深度会小于理论深度，这在下一篇讲深度计算时会专门分析。

3.3 指针位宽扩展：为什么深度为8的FIFO要4位指针

关于指针位宽，我当年第一次实现异步FIFO时踩过一个坑：以为深度为8的FIFO用3位指针就够了。实际用了4位指针之后才理解，那额外的一位不是给地址用的，是给状态判断用的。

FIFO深度为8意味着RAM数组有8个地址，从000到111，3位二进制地址就能覆盖。但如果只用3位指针，写一圈回来之后指针从111变成000，此时读写指针相等——可这到底代表空还是满？你根本区分不了，因为写满一圈和读空一圈在指针上看起来完全一样。

所以需要增加一个额外状态位来区分：指针从000到111为第一圈，从1000到1111为第二圈。写想想看这个场景：写指针和读指针同为0000时是空，但写指针为1000、读指针为0000时，虽然低位地址完全一样，实际却是写指针已经写了整整一圈，FIFO是满的。状态位就是用来区分这两种情况的关键。

因此一个深度为2^n的FIFO，指针位宽必须是n+1。这个多出来的高位不参与RAM地址索引，只参与空满判断。格雷码的转换也必须用完整的n+1位来做，不能只转换低n位，否则高位的跳变和低位没有形成格雷码特性，判断逻辑就会出错。

4. FIFO深度计算：不能拍脑袋，要算清楚

4.1 深度公式的推导过程

面试也好，实际项目也罢，最常被问到的一个问题就是：两个异步时钟域之间，数据突发长度为B，写时钟频率为fw，读时钟频率为fr，读写比率为R，FIFO深度到底要设多少？

这个问题的本质是：在突发传输期间，FIFO作为临时缓冲最多需要存下多少数据。突发开始时，FIFO假设是空的；突发进行中，数据以写速率进入、以读速率流出；突发结束时，堆积在FIFO里的数据量就是所需最小深度。最常见的计算公式如下：

剩余未读数据量 = B - (B / fw) * fr * R

展开整理一下，典型公式是：

FIFO深度 ≈ B - (B / fw) * fr * R

也就是突发长度减去突发持续时间内能读走的数据量。如果公式得出的是0或负数，理论上FIFO深度为1可能就够了（写一个读走一个）。但工程上不可能做到每次读写都正好咬合，所以建议至少留2到4拍的裕量。

4.2 一个案例的完整计算过程

我举个实际的例子来演算。假设写时钟频率为100MHz，读时钟频率为80MHz，读效率为50%（每两个读时钟周期读走一个数据），突发长度为120个数据。代入公式：

FIFO深度 = 120 - (120 / 100MHz) * 80MHz * 0.5 = 120 - 48 = 72

为了对齐到2的幂次，取128。加上安全裕量后，我实际会选深度为128的FIFO。如果你偷懒直接选64，突发还没结束FIFO就满了，数据只能丢失。这种错误在仿真阶段很难发现，往往要到上板联调或者跑到极端工况时才会爆出来。

还有个容易踩的坑：这些参数一定要到后仿真或者实测去确认，不能只看前仿真。前仿真里时钟相位关系、读写时序都是理想化的，延时参数没有加入，算出来的实际吞吐率会有偏差。前仿真说深度足足有余，后仿真一跑加上线延时、时钟偏斜，数据就可能悄悄溢出。

4.3 常用参数速查表

为了方便换算，我整理了工程里常见的参数对应关系。这个表基于上面同一公式、不同参数组合下的深度建议，你可以直接用：

要注意的是，实际工程里除了突发长度，还可能有背靠背的连续突发。一次突发刚结束，下一批数据马上又来，这种情况下公式里的B要把连续突发合并起来算，不然深度又会算小。

5. 完整代码实现：从模块划分到每一行信号

5.1 模块划分与端口定义

这里给出一份完整可用的Verilog实现。整个设计采用标准的分模块结构：顶层模块负责信号连接与参数定义；写指针模块在写时钟域内工作，负责生成写地址、写格雷码指针；读指针模块在读时钟域内工作，负责生成读地址、读格雷码指针；同步器模块完成二进制指针跨时钟域同步；双端口RAM模块执行真正的数据写入与读取。

先把参数和端口定义写好：

module async_fifo #( parameter DATA_WIDTH = 8, parameter ADDR_WIDTH = 4, // 深度为2^(ADDR_WIDTH-1)，这里的ADDR_WIDTH是二进制指针位宽 parameter SYNC_STAGES = 2 // 同步器级数 )( input wire rst_n, // 写端口 input wire wr_clk, input wire wr_en, input wire [DATA_WIDTH-1:0] din, output wire full, // 读端口 input wire rd_clk, input wire rd_en, output wire [DATA_WIDTH-1:0] dout, output wire empty );

注意我这里参数注释里专门写了一句：“ADDR_WIDTH是二进制指针位宽，不等于RAM地址位宽”。如果ADDR_WIDTH设为4，RAM深度就是8，实际地址位宽是3。很多工程编译不过的根因就在这里——RAM的深度参数和指针位宽参数搞混了。

5.2 核心代码逐段解析

重点代码并不长，我拆开来说。RAM阵列可以用几种方式实现——FPGA工程里用分布式RAM或BRAM的原语，ASIC流程里用库提供的SRAM编译器生成宏单元。下面这段采用行为级描述，逻辑上等价于一个标准双端口RAM：

reg [DATA_WIDTH-1:0] mem [0:(1<<(ADDR_WIDTH-1))-1]; // 写数据 always @(posedge wr_clk or negedge rst_n) begin if (!rst_n) ; // 保持 else if (wr_en && !full) mem[write_binary[ADDR_WIDTH-2:0]] <= din; end // 读数据 always @(posedge rd_clk or negedge rst_n) begin if (!rst_n) dout <= 0; else if (rd_en && !empty) dout <= mem[read_binary[ADDR_WIDTH-2:0]]; end

读写使能上必须用满信号和空信号去钳制。如果满信号来了还往下写，或者空信号来了还往下读，FIFO的正常工作状态就被打破了。用组合逻辑上的wr_en && !full来判断就足够了，时序上不会有问题。

指针模块负责把二进制指针加一后转换为格雷码：

wire [ADDR_WIDTH-1:0] write_binary_next = write_binary + (wr_en && !full); wire [ADDR_WIDTH-1:0] write_gray = (write_binary_next >> 1) ^ write_binary_next; always @(posedge wr_clk or negedge rst_n) begin if (!rst_n) begin write_binary <= 0; write_gray_reg <= 0; end else begin write_binary <= write_binary_next; write_gray_reg <= write_gray; end end

可能有人会问：格雷码指针是直接把“转换后的值”寄存，还是“寄存后的二进制”再转换？两种写法在逻辑上是等价的，因为二进制加一的进位到格雷码转换是组合逻辑，多花一个周期在一个时钟域内完全没关系。实际上我趋向于先寄存二进制指针，再用组合逻辑转换格雷码，这样格雷码时刻等于当前二进制指针的映射，不会因寄存器组合顺序多出一拍延迟。

再说同步器。同步器的写法就是两级（或三级）寄存器链：

// 写时钟域同步读格雷码指针 reg [ADDR_WIDTH-1:0] read_gray_sync [SYNC_STAGES-1:0]; always @(posedge wr_clk or negedge rst_n) begin if (!rst_n) begin read_gray_sync[0] <= 0; read_gray_sync[1] <= 0; end else begin read_gray_sync[0] <= read_gray; read_gray_sync[1] <= read_gray_sync[0]; end end wire [ADDR_WIDTH-1:0] read_gray_sync_out = read_gray_sync[SYNC_STAGES-1];

同步器输出的格雷码指针，还需要转换回二进制才能做高两位比较吗？不需要。空满判断直接基于格雷码本身的特性，不需要再转回二进制。这是格雷码的便利之处——高两位比较这种方法本身就是针对格雷码设计的。

空满判断逻辑汇总如下：

// 空判断：读写格雷码相等 assign empty = (write_gray_reg == read_gray_sync_out); // 满判断：高两位不同、其余位相同 assign full = (write_gray_reg[ADDR_WIDTH-1] != read_gray_sync_out[ADDR_WIDTH-1]) && (write_gray_reg[ADDR_WIDTH-2] != read_gray_sync_out[ADDR_WIDTH-2]) && (write_gray_reg[ADDR_WIDTH-3:0] == read_gray_sync_out[ADDR_WIDTH-3:0]);

请注意，空判断用的是同步到读时钟域的“写格雷码”和本地的“读格雷码”比较；满判断用的是同步到写时钟域的“读格雷码”和本地的“写格雷码”比较。方向不能搞反。空信号影响读操作，必须在读时钟域里生成；满信号影响写操作，必须在写时钟域里生成。

5.3 异步复位问题不能忽视

我上面代码里的复位都用了异步复位、同步释放的标准写法，用negde rst_n检测下降沿。

异步FIFO里复位信号本身也需要特殊处理——它同样是一个跨时钟域信号。复位释放的瞬间，所有寄存器的初值在各自时钟域内必须同时建立。如果读写两个时钟域对复位的释放时间不能保持一致，必然导致一个域已经退出复位开始工作，另一个域还在复位中，两边指针初始状态不一致，空满判断自然就错了。处理方法是做异步复位同步释放（Reset Synchronizer）。这玩意儿实现简单，就是一个移位寄存器，但对稳定性的提升立竿见影。在工程上我一直坚持给每个时钟域单独加复位同步器，这个习惯帮我挡掉过好几次上板后莫名其妙的状态错乱。

6. 仿真验证：异步FIFO怎么证明自己是对的

6.1 功能仿真的四类常规用例

异步FIFO的仿真验证，相比同步设计要复杂得多。常规设计对着波形肉眼查错就行，异步FIFO必须系统性地验证空满边界的各种场景。

我一般的仿真策略分四类：

写满测试：写端口连续写入超过FIFO深度的数据量，验证满信号在预期位置上拉，写使能被阻塞。等满拉高后，至少等两个读时钟周期（等同步器追上），再检查FIFO里的数据是否完整无覆盖。

读空测试：先写入一批数据，然后连续读出，验证空信号在最后一个数据读出的同时拉高，读使能被阻塞。注意看空信号从写入到拉高有没有一拍延迟——同步器引入的延迟会让空信号滞后一拍，这是正常的。

同时读写测试：读写同时进行，速率不同或相同，验证数据在边界条件下既不覆盖也不丢失。最好写一个自动比对模块：写入的数据带序号，读出的数据用于对比，自动报告错误。

随机停滞测试：用随机数发生器控制写使能和读使能的通断，模拟真实场景下的突发行为，长时间跑下来数据比对不报错才算及格。

6.2 一个简化的自检Testbench框架

Testbench里最核心的做法的构建一个数据比对机制。写侧写入时序编号（0,1,2,...），读侧读出后检查编号是否严格递增且连续。跳号对应数据丢失，重号对应数据重复，这两个都是致命错误。

代码框架如下：

// 写侧数据生成 integer write_cnt; always @(posedge wr_clk or negedge rst_n) begin if (!rst_n) write_cnt <= 0; else if (wr_en && !full) begin din <= write_cnt[7:0]; write_cnt <= write_cnt + 1; end end // 读侧数据校验 integer check_cnt; always @(posedge rd_clk or negedge rst_n) begin if (!rst_n) check_cnt <= 0; else if (rd_en && !empty) begin if (dout != check_cnt[7:0]) $error("Data mismatch at time %t: expect %0d, got %0d", $time, check_cnt[7:0], dout); check_cnt <= check_cnt + 1; end end

这种自动比对能显著提升验证效率。很多时候你在波形上看半天看不出问题，但比对器已经在仿真日志里准确标出了错误发生时刻和位置。

6.3 时序仿真的关键检查点

前仿真过了不等于时序收敛，以下几类时序问题最容易在前后仿真间暴露：

同步器建立时间违例：同步器第一级触发器的输入来自另一个时钟域，理论上无法做完美的时序约束。工程上一般用伪路径（False Path）或跨时钟域约束告诉综合工具“这条路别催时序”，让工具把精力放在同域时序上。

异步复位释放时序违例：复位释放后第一个时钟的建立时间容易违例。加了复位同步器后，这个风险可控，但还是要检查复位释放后前几个读写事件的行为。

满信号延迟导致的溢出：满信号从拉高到真正生效之间有同步延迟，如果测试里连续快速写又快速读，再快速写，你可能发现数据在满信号生效之前已经多写了几拍。这不是RTL逻辑错误，而是设计上就允许的保守行为，只是深度计算时必须把这个保守深度加上。

我踩过一次坑：前仿真全绿，后仿真加上所有延时后，数据在满信号附近多写了两拍，导致下一轮突发少了一个数据。当时排查了很久，最后定位到是同步器的延迟加上RAM写入延时的叠加效应。后来我的做法是：仿真验证的最后一轮，专门强制让写使能在满信号拉高后继续打两个时钟，确认业务逻辑能容忍这种情况。

7. 工程实战问题排查与设计优化

7.1 常见问题速查表

根据我多年调异步FIFO的经验，把工程里最常踩的几个坑整理成了一张速查表，按图索骥能省不少时间：

7.2 提升可靠性的三个进阶技巧

技巧一：握手信号包一层使能。有些场景下，读写数据本身没有有效标志，接收端不知道当前数据是否有效。这种情况下可以在数据通路的基础上加一个伴随信号，让数据带上自己的有效位，和FIFO一起入队。这样跨域的数据流本身就携带了同步信息，FIFO满空判断之外还能避免“读到空数据”的歧义。

技巧二：用读写指针差值做预警信号。标准异步FIFO只输出满和空两个标志。实际调试时，我们常常还需要“即将满”或“即将空”的信号，用来提前通知上游降速或下游准备。实现方式是在格雷码比较逻辑上增加一个偏移量判断——比如判断读写指针的格雷码差值是否达到深度减4。这个信号不参与数据正确性控制，只用于系统调度，调试时特别管用。

技巧三：写一个“深度监视器”。这个方法是我从一次棘手调试中总结出来的：在顶层模块里用两个计数器分别统计写请求和读请求的数量，两者的差值就是FIFO的实时占用深度。把这个值接入逻辑分析仪或系统总线，能非常直观地观测到FIFO内部行为。标准模块本身不输出这个信号，但它实在太有用了，我现在每次新建异步FIFO例化时都会顺手把它加上。

7.3 工具链上的建议

如果你在用第三方IP核生成异步FIFO（比如各种FPGA厂家的IP管理器），建议仔细看IP的配置说明。IP核生成的FIFO一般自带同步器、复位同步和空满逻辑，可靠性已经经过验证，省心很多。但IP核的透明度和可控性差，引脚信号含义、时序行为都是黑盒，一旦出问题很难从逻辑层面排查。我自己做ASIC项目时通常手写异步FIFO，做FPGA原型验证时优先用IP核，两者并不冲突——手写能掌握本质，IP核能节省时间，关键是搞清楚各自的边界和适用场景。

如果选择手写，建议在验证时除了跑完所有边界用例，再做一次跨时钟域的随机化验证。用约束随机的方式让写时钟域的写使能和读时钟域的读使能随机通断，长时间跑下来比对数据完整性，这比任何手写用例都能抓出更多隐藏问题。通常我会让这种随机验证跑至少100万个时钟周期，数据比对零错误才算通过。

8. 写在最后：我踩过的坑和沉淀下来的心得

异步FIFO这个模块看起来简单，十几行代码就能写完，但它处在两个时钟域的交界处，所有跨时钟域的问题都会在这里集中爆发。我早期在这个模块上反复栽跟头，几次定位到凌晨三点，最后发现都是同一个原理性问题：跨时钟域没有百分之百正确的采样，只有概率足够低的错误和足够保守的设计。

这些年沉淀下来几条认识：

第一条，工程师要执着于“方向”。判断空的时候，同步的是读时钟域拿到的写指针；判断满的时候，同步的是写时钟域拿到的读指针。这个方向写反，功能仿真大概率也提示不出来，直到上板跑到大数据量时才随机出错，定位极其痛苦。

第二条，深度计算宁可多不可少。同步器会引入延迟，会让满信号提前、空信号滞后，实际有效深度永远小于理论深度。计算深度之后，习惯性再加一级裕量，宁可多几十个存储单元，不愿在联调时抓耳挠腮。

第三条，验证要比实现更费时间。异步FIFO的RTL代码顶多半天写完，但完整的验证要占两三天时间——边界用例、随机用例、后仿真全要跑。这不只是流程要求，因为跨时钟域的设计，很多错误只在特定相位关系下才会出现，不带足够的随机性很难暴露出来。

如果你也正准备在自己的设计里加入异步FIFO，我的建议很简单：先用纸笔把深度算清楚，再把格雷码转换和空满判断的波形按时间轴手推一遍，最后才开始写代码。做完这些，代码本身反而成了一件水到渠成的事情。祝你的设计一次通过，不用通宵调时序。