Both ports of a SyncFIFO belong to the same control set, which means that the entire FIFO is always reset at once.

However, the ports of AsyncFIFO belong to different control sets, which means that, if either if the control sets includes a reset, only half of the FIFO will get reset; and as a result, stale data will be read.

In some cases, this problem may be alleviated by using a reset synchronizer: one port is chosen as the one that resets the entire FIFO, its reset signal is brought into the other clock domain, and used to reset either the entire clock domain, or only the port state. However, if the duration of the reset pulse at the leading port is shorter than the clock period of the following port, the following port will not be reset properly, and stale data will be read. In particular this happens if the clock to one of the ports is gated completely.

In some cases, this problem may be further alleviated by using asynchronous reset (of course, with synchronous release) for the entire clock domain of the following port. However, this carries the restriction that the entire domain has to be reset: since the assertion of the reset is not synchronized to the clock of the following port, it incurs metastability. Further, many FPGA elements will not be inferred from logic that is asynchronously reset, notably BRAMs and DSP blocks, severely penalizing this design.

It seems that there is no easy solution to the issue of resetting AsyncFIFO reliably in all circumstances, making it a completely safe design element that never spuriously produces stale data. I would suggest the following:

1. AsyncFIFO should not have a reset at all, that is, it should not have a signal whose stated purpose is to ensure that one or both pointers becomes zero.
2. The read side only of AsyncFIFO should have a synchronous clear signal that sets the read pointer to the same value as the write pointer, therefore flushing the buffer of any stale data that might be stuck there. Because AsyncFIFO reads are synchronous, this clear signal works regardless of how the read side is clocked. Because this clear signal operates entirely in the read domain, it works correctly regardless of how the write domain is clocked--the write clock could even be stopped completely.

This solves everything described above:

1. The two ports of AsyncFIFO are never reset, therefore neither of them is reset while the other is not. Therefore stale data is never read as a result of incorrectly sequenced reset.
2. When the leading clock domain resets the following clock domain to bring it into a well-defined state (in such case the FIFO could be full of garbage data), it is necessary to assert, simultaneously, all three of: following clock domain reset, clear signal of any FIFO read port in the leading clock domain (through an explicit connection), and clear signal of any FIFO read port in the following clock domain (the clear signal should be implicitly ORed with ResetSignal("read") in the FIFO). Therefore any garbage data is eliminated from FIFOs oriented in both directions before the reset is deasserted.

One possible logic bug with this scheme would be a case where the CDC FF chain inside AsyncFIFO is for some reason longer than the FF chain inside the reset synchronizer used to reset the following domain. Ideally, the CDC checker (#4) should flag any such cases.