System Logic

[sdressler]

Hi,

I'm having a design utilizing FIFOs generated by Coregen 13.3 and FIFO Generator v8.3.

My design runs at 150 MHz, the FIFOs are using a common clock. Each FIFO is 32 Bits wide and 128 Datawords deep. Now I'm using these FIFOs to connect them to a large Bus (64 Bit, so I'm using 2 FIFOs in parallel). When simulating the design everything works fine. However on the real hardware (Xilinx Virtex-5 LX330, Speedgrade -2) the FIFOs always losing the first two datawords that are written to it.

Are there any suggestions regarding this problem?

Thanks,

Sebastian

[gszakacs]

When you say it works in simulation, are you using the "structural" FIFO models?  The

"behavioral" models are known to be broken, or at least not cycle-accurate.  Usually

you'll get a warning message when you start a simulation if you have included the

behavioral models.

When you are talking about the first two words, is that every time the FIFO becomes empty?

Or just after the FIFO has been reset?  Do you mean the first two 64-bit words?

How did you deal with the flags when you used two FIFO's side by side?  Are you

using the flags from both cores, or assuming that the flags will match?

Did you generate the FIFO as common clock?  Or did you generate a dual clock FIFO and

tie the two clocks together?  The latter may cause issues.

A lot of questions and not many answers...

-- Gabor

[rcingham]

"I'm using 2 FIFOs in parallel"

Why?
Why not set the 'Write Width' parameter to 64 bits?

And Gabor is absolutely right about always using Structural models for FIFOs.

[sdressler]

Sorry for not being precise enough with my question.

Regarding simulation: I am using the structural models. I know that there is a lack of accuracy with behavioral models.

The two words are alway lost when the FIFO is empty and I'm starting to write. Write operation is as follows:

           __    __    __    __    __    __
CLK   : __|  |__|  |__|  |__|  |__|  |__|  |__
                       _________________
WR_EN : ______________|                 |_____

DATA  : XXXXXXXXXXXXXX|DATA1|DATA2|DATA3|XXXXX

DATA1 and DATA2 are lost when reading the FIFO, although the FIFO User Guide suggests that writing this way must work. Losing the datawords always happens when the FIFO is empty, all other datawords are not lost.

I assume that the two FIFOs are synchronous, i. e. asserting RD_EN at the same time should lead to synchronous assertion of the VALID flag. So I am not doing some additional synchronisation to make sure that the flags are set synchronous.

The FIFOs are generated with a common clock. I did use two separate FIFOs since I observed exactly the same behaviour when using a single 64 Bit FIFO. I assumed that something did not go so within PAR and tried to split the big FIFO up into two smaller ones.

Regards,

Sebastian

[eteam00]

The two words are alway lost when the FIFO is empty and I'm starting to write.

Please explain what you mean by "words are lost".  Is this possibly a problem related to unwritten (uninitialised) memory, or FIFO output register which has not been clocked or reset?

-- Bob Elkind

[sdressler]

As an example, when I'm writing 8 datawords into the FIFO on reading from the FIFO the first two words never appear on the output bus, thus it seems that the FIFO only holds 6 of the 8 datawords.

Edit: The outputs of the FIFOs are not registered, in simulation the read latency is one cycle.

[gszakacs · Accepted solution]

Since this only happens in the real hardware, I would suggest using ChipScope to debug it.

It's fairly easy to find the nets in a CoreGen IP core using the hierarchy pane of the ChipScope

inserter.  Make sure you look at all of the control signals including those you don't think are

important (like reset), since differences in hardware behavior often come from signals not

doing what you thought they would.  You don't need a lot of depth in the ChipScope core, and

you certainly don't need to hook up all 64 data bits, just hook up enough bits to see what's going

in and coming out.  My guess would be that you'll find that the reset or read enable signals

are active some time when you didn't expect it.

-- Gabor

[sdressler]

Thanks for the help. I used ChipScope and noticed that WR_EN and the DATA were showing a latency of one clock cycle. In addition to that the writing to the FIFOs is not consecutive and therefore sometimes zeros are written to it. Removing the latency solved the problem, but I'm wondering why this wasn't shown in the simulator.

Thanks,

Sebastian

[rcingham]

Is there a lot of logic/muxes on the WR_EN or DATA signals just before they are fed to the FIFO?

[sdressler]

It depends on what a lot of logic is. The WR_EN signal is generated as follows:

done_flag <= and_reduce(std_logic_vector(count) xnor mc_addr_gen_count_to_in);
valid_rq <= mc_addr_gen_rq_in and not done_flag;

Note, that *_in are input signals and valid_rq is basically the input for WR_EN. count and mc_addr_gen_count_to_in are each 48 Bits wide.