FIFO Simulation Oddities!

Is the simulation timing of the READ_ENABLE relative to the read clock the same for both instances?

Do you have output registers enabled/disabled in both ?

Rgds Andr=E9

Thanks for your replies:

John_H: Yes, on the correct FIFO (FIFO A) the DATA appears on FIFO A DATA_OUT one clock cycle (based on the FIFO A READ_CLK) after FIFO A READ_ENABLE is asserted. Similarly on the incorrect FIFO (FIFO B) the DATA appears on FIFO B DATA_OUT the same clock cycle (based on FIFO B READ_CLK) as FIFO B READ_ENABLE is asserted.

snipped-for-privacy@web.de: I created the Asynchronous FIFO using the Xilinx Coregen Wizard (with output registers disabled) and instantiated it twice in my design. My understanding is that because I am instatiating the same FIFO twice the two FIFOs therefore are identical (in terms of configuration parameters).

I have just found out that although in SIMULATION the behaviour of the two FIFOs are different in REAL LIFE (on the hardware using CHIPSCOPE PRO) both FIFO's behave the same (as per the datasheet, ie. as FIFO A is behaving in SIMULATION)

Regards,

Simon

My question was specifically where the READ_ENABLE is relative to the READ_CLK rising edge. It's easy have two signals that both appear in your graphical timing diagrams to be at the clock edge - identically - but in reality are on different sides of the clock edge. Are both READ_ENABLE signals amply before the rising edge of the clock?

My advice is that even in an asynchronous FIFO, each side should be properly synchronous to its own clock. Therefore Clock Enable should not change too close to its own clock edge. The two clocks can then be completely asynchronous to each other.

Peter Alfke, Xilinx Applications

I agree that this is the way it should be done; I think John_H is asking whether it in fact has been done in this case.

Bob Perlman Cambrian Design Works

Both FIFOs, and their respective READ_ENABLE signals, are manipulated from within STATE MACHINES (clocked on the rising edge of the respective READ_CLK's).

To add another twist to the situation, I have just regenerated the FIFO using Coregen and FIFO GENERATOR v 2.2 (instead of ASYNCHRONOUS FIFO v

Although this solves the problem, it does raise some interesting questions about why the ASYNCHRONOUS FIFO v6.1 simulation model appears to exhibit this strange behaviour. One distinct difference between the two FIFO instantiations is that in the case of FIFO A (the behaviourally correct FIFO) data is written at the faster clock rate and read and the slower clock rate. In the case of FIFO B data is written at the slower clock rate and read at the faster clock rate. Whether this situation highlights a "bug" in the simulation model or not I cannot deduce.

Regards,

Simon

For grins... For simulation... Delay the READ_ENABLE as seen by the FIFO by 1 nanosecond.

These kinds of problems you're seeing are just *so* often a simulation problem because your RTL isn't simulation-ready when combined with models that have delay elements included.

Suspect a difference between the clock signals to each; for example a simple assignment such as fifo_read_clock