Although the async FIFO ensures that the SRAM is never written in the same place as it currently being read, in a synthesized SRAM, it is theoretically possible that changes resulting from the write can propagate to the output either because the FIFO is empty and a write is being done to where the read is currently pointing or simply because the MUX that is MUXing among register items is glitchy. It is thus theoretically possible, depending on synthesis results, for async writes to cause temporary glitches at inopportune times that violate setup and hold time of the destination flops. A more stable solution would be to add a hardened data gate that prevents data changes from propagating when a read is not being performed.
https://github.com/bespoke-silicon-group/basejump_stl/blob/fa50804e78143c5b16c6d4010f9513083e8ef286/bsg_async/bsg_async_fifo.v#L61
Although the async FIFO ensures that the SRAM is never written in the same place as it currently being read, in a synthesized SRAM, it is theoretically possible that changes resulting from the write can propagate to the output either because the FIFO is empty and a write is being done to where the read is currently pointing or simply because the MUX that is MUXing among register items is glitchy. It is thus theoretically possible, depending on synthesis results, for async writes to cause temporary glitches at inopportune times that violate setup and hold time of the destination flops. A more stable solution would be to add a hardened data gate that prevents data changes from propagating when a read is not being performed.