A erratic phenomenon of FIFO in FPGA

--- Quote Start ---

You may be thinking of using fifo just as fixed memory for block processing.

But using fifo as "elastic" buffer for continuous stream processing and especially if the stream is bursty requires naturally that there is elasticity on both sides of operating point otherwise you get empty or full fifo repeatedly losing your stream continuity.

--- Quote End ---

Thanks, Kaz. Most work I do is in image processing, i.e. digital cameras, and that is like you say block oriented. I appreciate that in other systems you may have to keep a steady stream going.

thank you very much, kaz.

i think i do at last find the problem.

it is the writing clock that causes so much exotic phenomenon, i am sorry for my careless checking this signal.

thank you again for your patience and time.

ingdxdy

p.s. in fact, i donot trust simulation much. a lot of situations such as clock jitter, precise hareware timing cannot be simulated. i like running direclty and check with signaltap.

Thats ok. I use half full just because it is easy to check using one bit logic.

I have never seen fifos behaving like what you see. I think it is best to use simulation of fifo on its own as I mentioned before.

well, i am not clear what the speciall meaning is for half full reading.

in fact, i begin to read fifo when rdusedw=204. that's, if fifo buffers data greater than 204-byte, reading operation starts. or else, it is waiting.

it that not optimal?

It might help to do this short exercise:

write but do not read fifo until word count = 512 (MSB = '1') then start and continue reading.

clked process...
if fifo_words(9) = '1' then
    fifo_ready <= '1';
end if;
wr <= '1';
rd<= '1' when fifo_ready = '1' else '0';

--- Quote Start ---

The strange behaviour as seen by signaltap does not make sense.

You better simulate your fifo on its own before moving to hardware.

--- Quote End ---

thanks a lot for your replying, kaz.

are you mean signaltap is unbelievable?

i do believe that signaltap is more believable than simulation, because it gives the direct result when the hardware is really working.

as figure shows, rdusedw jumps from zero to ox3ff when i just write into 4 bytes. i originally suspect the write clock instability, but it is alright seen from oscilloscope. the clock configured in signaltap is same as write clock of fifo, there cannot be clock frequency problem. so what's the possible reason for such situation? i need some advice.

in reality, reading and writing clock frequency is same, when some quantity data is written into fifo, it will be read out. under normal circumstances, a full fifo cannot be happen, not to mention now a full fifo results when i just write into 4-byte.

--- Quote Start ---

Optimising the operating point to the middle may waste a lot of memory, I'd rather say you optimise you system to keep fifos empty, but make them big enough to handle the bursts

--- Quote End ---

You may be thinking of using fifo just as fixed memory for block processing.

But using fifo as "elastic" buffer for continuous stream processing and especially if the stream is bursty requires naturally that there is elasticity on both sides of operating point otherwise you get empty or full fifo repeatedly losing your stream continuity.

The strange behaviour as seen by signaltap does not make sense.

You better simulate your fifo on its own before moving to hardware.

Hello,

There is another problem when using FIFO.

when i write data into fifo, the rdusedw behaves strangely. as figure(grasped with signaltap) in the attachment shows, rdusedw(which has combined with wrfull as josyb directs) jumps to full(0x3ff) from zero disruptly when i only write 4 bytes into it.

the fifo is dual port with different read and write clock. reading and writing may occur simultaneously.

can anyone help me?

thanks a lot.

thank you very much, josyb and kaz.

ingdxdy