alexforencich
commented
2 years ago The FIFO uses a handshake synchronizer in frame FIFO mode. So in this case metastability doesn't matter as the synchronization path is via the wr_ptr_update(_sync) regs, and the source wr_ptr_sync_gray_reg is not updated until the acknowledgement comes back from the destination clock domain.
In frame FIFO mode, the grey coded sync doesn't work properly because it doesn't increment, it jumps by the whole frame size, which defeats the point of the gray code.
Basseuph
Devipriya1921
While going after the items reported by the CDC related DRCs of intel quartus 21.3, most of the items seem to be OK from an RTL perspective. But one item catched my eye, which is https://github.com/alexforencich/verilog-axis/blob/ce8dcdafe83af2ca610e353bb4cbb0e1afbed92b/rtl/axis_async_fifo.v#L225
I don't get the reason why it is OK in
FRAME_FIFOmode to read the first stage of the synchronisation chain of the write pointer.Another item is that in CDCs it is usually not a good idea to add logic in between the last flop of the source clock and the first flop of the destination clock, see https://github.com/alexforencich/verilog-axis/blob/ce8dcdafe83af2ca610e353bb4cbb0e1afbed92b/rtl/axis_async_fifo.v#L486-L487 The path (last flop in source clock) -> (first flop in destination clock) -> (second flop in destination clock) should be free of any logic to allow for shortest paths in between the flops to reduce the probability of metastability. This special is actually worse, because depending on the condition the input of the synchronizer chain is either driven by the source clock or the destination clock.