[HELP]problem with asynchronous fifo ip

[zl502593045]

Hi,all,
I have some problem and I need help.I am using fifo ip core of sparta
3a.The write clk is 125MHz.I set read enable <= !empty.When I use read cl
with 100MHz, it can read data from fifo correctly and continuously becaus
write clk >read clk.But when I use 150MHz as the read clk, the data rea
from fifo is wrong.The read valid is discontinuously because write clk
read clk.
My question is the problem comes due to the 150MHz is too fast fo
spartan 3a or the method using read enable <= !empty is irrationally?
Thank you very much!



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Chris]

You need to be careful with the asynchronous fifos in general. I am working 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 beautifully in the sim but erratically in the actual hardware. The asynchronous FIFO does not simulate accurately so do not trust your sim. I ended up changing the FIFO to synchronous and handling the asynchronous portion outside 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 this may sim okay but fail in the lab.

My suggestion is to switch to a synchronous FIFO and handle the asynchronous data outside of the FIFO. If you have to use the FIFO for asynchronous buffering 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.

 

[RCIngham]

Hi,all,
I have some problem and I need help.I am using fifo ip core of spartan
3a.The write clk is 125MHz.I set read enable <= !empty.When I use rea
clk
with 100MHz, it can read data from fifo correctly and continuousl
because
write clk >read clk.But when I use 150MHz as the read clk, the data read
from fifo is wrong.The read valid is discontinuously because write clk
read clk.
My question is the problem comes due to the 150MHz is too fast for
spartan 3a or the method using read enable <= !empty is irrationally?
Thank you very much!

How are you observing this?

Are you simulating (or have you simulated) it?


---------------------------------------
Posted through http://www.FPGARelated.com

 

[RCIngham]

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

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

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

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


---------------------------------------
Posted through http://www.FPGARelated.com

 

[GaborSzakacs]

RCIngham wrote:

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!

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.

--
Gabor

 

[GaborSzakacs]

RCIngham wrote:

RCIngham wrote:
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!
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.

--
Gabor

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.

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.

--
Gabor