Spartan® Family FPGAs

[nickagian]

Hi!

I have a design in a SP605 board, where I read and write from/to the SDRAM through the ethernet interface. I have noticed a very weird situation with the read FIFO, which is depicted in the attached figure. These are waveforms captured with the ChipScope Analyzer. The interesting signals are the red ones.

Shortly presented, the normal series of events when I want to read from the memory is the following:

(1) I send a command enable signal to the MCB (at the McbCmdEnxSO) every time that the read FIFO is empty (McbRdEmptyxSI signal), as it can be seen at the 'X' cursor. As you see, the Burst length is 0x3F = 64 user words (32-bit each).

(2) I then wait, until the read FIFO is not empty any more (the McbRdEmptyxsI signal is de-asserted)

(3) Then I start sending read enable pulses (McbRdEnxSP signal) until the FIFO is empty again. At this point I go back to step (1), unless I have read all the data I wanted to.

The problem I am talking about can be seen at the 'O' cursor. Although I have sent a command at 'X' cursor to read 64 user words, after only 4 words have been read the McbRdEmptyxSI signal is asserted again! My FSM assumes the FIFO is indeed empty, sends again a new command, new data come to the FIFO and the result is that some clock cycles afterwards the data in the FIFO are messed-up. What is also weird, is that the McbRdEmptyxSI signal seems to be again de-asserted as soon as I have sent the command enable pulse, whereas it is obvious in the previous command enable pulse that there is some more time in between these two events.

Does anyone have any clue about this situation that could help me? Is it something to do with the FIFO? Or is it something else?

[nickagian]

I actually forgot to mention that this weird situation is not happening all the time but occasionally. Most of the time the process works as I want it to. I have confirmed it in ChipScope as well.

[austin · Accepted solution]

n,

The very nature of a FIFO is that it toggles its status as the data flows through it.  I would make sure your design is able to tolerate an "empty" condition, as that is perfectly legal, and expected (as the data flows through, regardless of fill rate, the FIFO may actually be 'empty').

For example, if you expect to get 64 bytes, and you are looking for data to be available at the FIFO output, I would disregard an empty if it happens before the 64 count is met.  I would also have a time-out timer, so that if you got a partial packet, you are able to reject it, and get the next full packet.

[gszakacs]

Since this only happens occasionally, it's likely that what you're seeing is a reduction in the

read rate due to refresh or else when you go past a row address boundary and need to

precharge a new row.  The MCB should tell you how many words are in the FIFO.  If you

look at it when your logic "works" you'll probably see that the number of words goes

up constantly because there is no gap in the read timing.  If you need to be sure that

your logic receives a new valid word from the FIFO with no gaps, you could wait until

there are 64 words reported by the MCB and then start reading.  Or you can just tie the

read enable true all the time, use the empty signal as an active low data valid, and

add your own FIFO to deal with the required data rate smoothing.

-- Gabor