[HELP]problem with asynchronous fifo ip

because

How are you observing this?

Are you simulating (or have you simulated) it?

--------------------------------------- Posted through

You need to be careful with the asynchronous fifos in general. I am workin g on an artix7 design right now where I thought I could use an asynchronous fifo as a rate buffer but that turned out to be an epic fail. It worked b eautifully in the sim but erratically in the actual hardware. The asynchro nous FIFO does not simulate accurately so do not trust your sim. I ended u p changing the FIFO to synchronous and handling the asynchronous portion ou tside the FIFO and everything works beautifully.

I *think* your attempt to use the FIFO empty to gate your read enable makes sense as long as you are clocking it with the read clock. I can imagine t his may sim okay but fail in the lab.

My suggestion is to switch to a synchronous FIFO and handle the asynchronou s data outside of the FIFO. If you have to use the FIFO for asynchronous b uffering then maybe you could set a guard of written data, ie only read if the read data count is greater than five.... That should give you a buffer to avoid any reads of an empty fifo.

workin=

asynchronous=

b=

asynchro=

u=

ou=

makes=

t=

asynchronou=

b=

There used to be a problem with the Xilinx CoreGen simulation models for the Asynchronous FIFOs. The behavioural models were slightly wrong (and therefore mostly useless). The structural models were correct, so that is what we always used. They might have fixed the problem, but I wouldn't risk it!

--------------------------------------- Posted through

For some versions of FIFO, the behavioral models were seriously broken.

They were not cycle accurate.

They often failed to model optional flags like programmable full/empty.

They did not correctly model depth (read count, write count) outputs.

However getting back to the original question, if you use the "standard" FIFO then you need to remember that data is valid on the output one cycle after you assert read enable. If you don't account for this it can appear as if there are data errors every time the FIFO is allowed to go empty. If you want to use the data on the same cycle as you apply read enable, then you should generate the FIFO in "First-word fall-through (FWFT)" mode.

Other than that, my experience is that these FIFO's work quite well in hardware as long as your design meets timing.

for

is

risk

I agree that FWFT mode is often useful, and I have used it multiple times. Even so, it takes several clock cycles for the first written word to 'fall through', which is why simulation is so important for honing the control logic.

--------------------------------------- Posted through

We seem to have lost the OP along the way, but from the sound of the problem it had nothing to do with overall latency, which as you say is the same for "standard" or FWFT FIFO's. The difference is in the read latency, and since he has read enable tied to !empty, that's the latency that you need to look at. In the "standard" case data is valid one cycle after !empty going true. In the FWFT case data is valid on the same cycle that !empty goes true. If he's never seeing !empty go false then it doesn't matter. If !empty comes and goes, then you get errors from sampling data too early or too late.