今天华为面试题：异步FIFO读时钟是写时钟的100倍，或者写是读的100倍会出现什么问题？

等待高手哈！

不要在意，术业有专攻。面试的估计也就自己写过FIFO而已。
方案会出现这种问题，首先就不是一个好的设计。

觉得应该是会产生setup/hold时序问题吧。例如，在读时钟比写时钟快100倍的情况下，写满的标志位是在写时钟的时钟域下产生的，这时，就要对写指针和读指针进行比较，而读指针是在读时钟的时钟域下生成的，为了满足读时钟域的setup时序要求，那么读指针的产生就必须要在一个读时钟周期内完成，这时，读指针的变化就相对写时钟来说变化得太快，那么可能会在写时钟的setup/hold时序检查的窗口里面变化，就会在产生写满标志位时有setup/hold时序问题。

时钟差距这么大，感觉怪怪的，这种情况用RAM更简单吧

华为面试官也能问出这么没有水平的问题……或者小编没有把问题描述全面。纯粹从设计上看，异步FIFO读写时钟差异万倍也不会导致FIFO本身功能出错。你回答的是会出现什么现象，提问者觉得会出现什么错误问题，所以他不满意。确实只会出现你说的现象，不会有什么问题。

   读是写的100倍，直接拍过去都可以把它拍死了。写是读的100倍，一般来说是面试提问的人“脑子瓦特了”

（1）人家问这问题，不代表实际中会用，大家没必要评论这问题本身合不合理
（2）太快会导致 fast-》slow的 path 在throughput较大时，对于slow domain而言出现一堆timing的问题（transition, mata, etc.），甚至会导致slow domain看到的gary code变换后的指针和fast domain最新的值不匹配，就全挂了
(3)这种设计在架构上应该不会有。之前碰到即使8x clk -> 1x clk的时候，为了稳妥起见，最后的实现方式是：
   8x- > 4x -> 1x。

   请教大师，能讲详细点吗?

时钟差距太大，有可能会导致跨时钟域的，读写指针丢失数据

无语……你说的timing，transition等等问题，那是快时钟频率太高时序无法收敛而已，快慢时钟相差倍数并不是这个的问题根源。至于你说的快时钟到慢时钟，指针会漏掉，这是很正常的现象，但是漏掉指针如果导致FIFO功能出错，那就是你FIFO设计出错了。
异步FIFO需要保证空满信号及时报出，满了不要去写，空了不要去读。异步FIFO的空满由于异步传递延时的问题，只会出现提前报出虚空虚满的问题，而不会出现漏掉空满的问题。 满信号的产生是写时钟域下，当前周期写指针与两个写时钟周期前的读指针比较，如果判断满了，当下不会再写，但是读时钟域有可能在这两个周期有读动作，只会造成FIFO实际上被读出成非满状态，而此时即使报出满状态是没有关系的，这个时候就是虚满的状态。空状态与之类似，自己分析一下。

异步FIFO读写频率能不能相差百倍以上，自己写一个FIFO验证一下就完了，不要想当然觉得漏掉指针就一定有问题。

楼上正解，这个问题不知道要问什么。FIFO本身就是要解决这个跨时钟问题。

空读或满写呗

【1】这主题讨论的是，如果FIFO输入合法的前提下，FIFO的问题。我们至今不会让自己设计的FIFO因为FIFO自身原因指针跑飞，这是致命bug，也不知道你说的“属于正常”是怎么回事。async-FIFO的功能稳定性就在于你对Timing的控制能力，甚至都会涉及到Lib 里面使用哪些cell，满足哪些参数（transition之类的就是在这里使用的,调这个很费时间，有经验的一定会有体会）。想deliver稳定的能在较为极端状态下工作的async-FIFO，远不止几行所谓的RTL，或仅仅看功能性分析。【2】如果你说的是，FIFO因为使用不当而指针跑飞，然后再想办法软件容错或硬件容错，给FIFO的content或者PTR做retention之类的。这显然是另外一码事。
另外，工程师应该“淡定“一些，正如你名字一样，别动不动就“无语”，大家不懂得东西都很多。
cheers！

  如果你认为快到慢时钟同步过程中，漏掉指针会导致异步FIFO功能出错，实际上只要读写时钟相差两倍就一定会出现遗漏指针，那我请问你：异步FIFO的设计，是否应该限制读写时钟不能超过两倍呢?甚至，即使是相差两倍以内的异步时钟，同步过程中也可能漏掉指针，按照你的逻辑，异步FIFO压根就没法用。

以我有限的fifo知识来看，跨时钟时使用格雷码，并做适当的跨时钟处理，就可以避免所谓的指针丢失问题。而时序问题可就不好讨论了，是另外一个层面的关系，设计的面太多，不同的底层实现，不通的布局都会导致时序问题，这个和两边使用的时钟差别的程度好像没有什么关系。
另外请教，masaka_xlw ，
1）这种设计在架构上应该不会有。之前碰到即使8x clk -> 1x clk的时候，为了稳妥起见，最后的实现方式是：
   8x- > 4x -> 1x。
具体是什么考虑，能否说得详细一些?

不会有问题

就是类似于常见的结构中，在internal register 和 memory之间加Cache一样。设计的目标是，就FIFO本身而言，必须保证其current_state是 能被正确识别的， 所以为了增加FIFO工作的稳定度和流畅性，不会让两个速度差别太大的domain直接连在FIFO两端，而是通过内部的一个“FIFO Cache”。当然从使用者的角度，他是不知道这种所谓的cascaded FIFO里面还有一个缓冲。统计结果表明，差别为8x 的async-FIFO出问题的几率 要比 两个差别为4x的 async-FIFO出问题的几率 高3~4个数量级， 当然这和使用的工艺有关系，这个结果是40nm的。

再次请教，fifo的时钟问题可以分为3个部分，1）高速时钟部分X100，2)低速时钟部分X1，3)跨时钟部分。显然我们不是在讨论1，和2的部分，重点是跨时钟部分。对跨时钟部分而言，稳定性的根源应该是亚稳态。亚稳态无法根本消除，只能把发生的概率降低。您所说的X8比X2，X4高几个数量级问题是否指的是这个?

使用FIFO需要保证的就是别错误操作：满了不要去写，空了不要去读。FIFO自身需要保证的就是空满信号及时产生。除此以外，异步FIFO对工艺啥的，读写时钟频率倍数都没有限制。异步FIFO的verilog设计与工艺无关，别说40nm，28nm的SOC都不知流片多少颗了，一个异步FIFO都需要去挑lib cell类型的话，那SOC内的CPU核GPU视频核等复杂IP都得全定制了。
你的8x到1x中间插入4x做缓冲，应该是基于数据流功能性控制的要求，本质原因不会是异步FIFO的读写时钟频率差无法做到8倍。你们这样做的深层原因，你去了解清楚再跟大家交流，而不是拿出一个异步FIFO读写时钟频率倍数太大会导致FIFO出错的结论来误导大家。

异步fifo不就是做异步处理的吗，很好奇这个能出什么问题

我觉得如果读时钟是写时钟的100倍：如果想要读出不同组数据需要占用的资源太多了，要事先存储一百组FIFO，那么芯片内部的资源可能不够；写时钟是读时钟的100倍：除非不是需要每个数据都读出来，不然因为资源问题损失的数据也太多了。
等待大神指出错误。

我个人感觉是：
有人设计是用半满 满  半空 空， 这种乒乓构架， 不会因为工艺不同而不同的， 至于亚稳态， 你三级FF，可以解决。这种不会考虑数据速率跟带宽充分利用的。 芯片内部的DMA 比外设都高于8倍的。 不会搞什么 8 4 1 这种。
而有人用满 空 或al_full al_emp  这种只要考虑你fifo的深度，做到匹配， 基本就可以了， 也不会用到什么 8 4 1.
至于说到什么丢数据， 不是很正常的吗? 既然是 async-fifo 就会出现，syn—fifo也会出现，数据来不及搬走。 那软件或系统必须要考虑这个问题。一般硬件不会考虑的， 硬件只会考虑本模块是不是安全，数据速率互相是不是匹配。

从clk的角度，是这个意思。
亚稳态当然无法100%消除，但FIFO设计要从结构上使这个所谓的“meta-stability”概率的数量级尽量低。
你可以通过调整clk的结构，比如这个8x 4x 2x之类的。可以选择Threshold反应更快的cell用在CDC的path。也可以使用并行且独立的多条判断当前FIFO状态的电路。 甚至一些更高级的做法。
当然，所有的这些讨论点都聚焦在FIFO本身的设计，使FIFO“鲁棒”到可以假设任何输入都是合法的。
如果说“通过合理的使用，使FIFO不出问题”，这已经不属于FIFO设计的范畴了。

从clk的角度，是这个意思。
亚稳态当然无法100%消除，但FIFO设计要从结构上使这个所谓的“meta-stability”概率的数量级尽量低。
你可以通过调整clk的结构，比如这个8x 4x 2x之类的。可以选择Threshold反应更快的cell用在CDC的path。也可以使用并行且独立的多条判断当前FIFO状态的电路。 甚至一些更高级的做法。
当然，所有的这些讨论点都聚焦在FIFO本身的设计，使FIFO“鲁棒”到可以假设任何输入都是合法的。
如果说“通过合理的使用，使FIFO不出问题”，这已经不属于FIFO设计的范畴了。

   我也觉得不会有什么问题，异步FIFO就是处理跨时钟域的。只是系统的吞吐率会受到最慢的时钟域限制，那这个是时钟设计的问题。

感谢，清楚了！

mark收藏下

一侧的时钟同步较慢，有可能导致另一侧的地址同步错误， 格雷码转换问题，导致FIFO地址出现混乱。