--- Quote Start ---
the Rdusedw has to have a 2 clock latency in a DC fifo because it has to get the difference in the read and write counters that are in 2 difference clock domains, and needs to synchronise them - hence the extra clock.
--- Quote End ---
This doesn't explain. I am asking the latency from rdreq to rdusedw, so this can be done in one cycle no matter how long it takes to synchronize the write pointer into read domain. Even worse, this rdusedw is NOT flopped, so to close timing would require an extra cycle, making it 3-rdclk latency from rdreq.
--- Quote Start ---
As for timing problems with rdempty - what are you doing with this signal? doing some logic with it?
--- Quote End ---
I am using rdempty (along with rdusedw and q) to generate next rdreq. My FIFO stores different elements. For certain elements I must maintain atomicity, i.e. either don't send out anything or burst out the entire element back-to-back. So I use "read ahead" mode to check the data. If it's the header for atomic transfer, then I check rdusedw to make sure FIFO has the entire element. Otherwise I can read whenever rdempty is 0. So the logic is something like this:
rdreq = rdusedw > `ATOM_LEN || q[`TYPE] != `ATOM_TYPE && !rdempty;
Honored Contributor
