A erratic phenomenon of FIFO in FPGA

[Altera_Forum]

Hello, 

I am using megawizard to generate a fifo of 8bitsx1024words in EP3C16. An interesting result occurs, when fifo is full(wrfull=1), it at the same time indicates that there is no data to read setting rdusedw=0. The result is caught by sigtapII analyzer.  can anyone help me to explain this phenomenon. thanks a lot.  g.p.cao

[Altera_Forum]

Fifos may show unpredictable behaviour if you write to a full one. Best practice is to optimise the operating point near the middle. If it gets full you must have logic to return back to this optimum point.  

 If your fifo is dc then check your reset operation.

[Altera_Forum]

f your fifo has power of 2 as the number of entries, than it 'rdusedw' will show 0, but it will also show 'full' (or 'rdfull' in case of a dcfifo) set to 1. if you prefix the the 'rdusedw' with this 'full' flag you get the exact representation. e.g. a 'full' fifo with 128 entries has "0000000" as the 'rdused' value, if you prefix the 'full' flag you get "10000000" which represents the 128. In dcfifo you can set set the "ADD_USEDW_MSB_BIT" to "ON" to get the correct 'rdusedw' representation directly. 

I advise you to read the user guides for the fifos thoroughly though, as there a few other pitfalls with latency and such, e.g. the 'full' flag may be one clock ahead of the 'rdusedw' value indicating "11111111" just before giving the correct "10000000".     --- Quote Start ---  Fifos may show unpredictable behaviour if you write to a full one. Best practice is to optimise the operating point near the middle. If it gets full you must have logic to return back to this optimum point.   If your fifo is dc then check your reset operation.  --- Quote End ---   You can write safely to full fifo, if you didn't turn off the OVERFLOW_CHECKING setting (which is default set to "ON"). 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

[Altera_Forum]

thank you very much, josyb and kaz.  

 ingdxdy

[Altera_Forum]

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.

[Altera_Forum]

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

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

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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';

[Altera_Forum]

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?

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

--- 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.