DCFIFO turns into LIFO

[Altera_Forum]

Hello, 

 I encountered a strange behaviour in one of my design in which I use a DCFIFO. The fifo is used to convert a 32 input to 8 bit output with rdclk different from wrclk.  The configurations of the fifo are: 32 bit input/8 bit output =>wrclk/rdclk ; best metastability protection selected(3 sync stage); asynchronous clear; show ahead fifo;none of circuity protection disabled.  I made the necessary (or which I thought necessary to be precise) time constraints: asynchronous clocks ( set_clock_groups -asynchronous with the two clocks involved in the fifo case being in different groups) and set_false_path copied from the SCFIFO/DCFIFO UG( although I understand that in Quartus 9 "the false path assignments are automatically added through the HDL-embedded Synopsis design constraint (SDC) commands when you compile your design")  After a time of good behaviour, I observed that the fifo doesn't work properly. Sometimes I have on the output side some extra bytes(it seams that I give fewer rdreq, although the last message send from the fifo, before this, was complete, and the ones after are "ok", having the correct content, shifted with the amount of bytes that apeared on the first error) and other times I observed a lifo behaviour.   Had anyone experienced something similar? or any ideas about the source of the problem?  Have a nice day, Alex

[Altera_Forum]

A DCFIFO doesn't behave unless you have at least a depth of 8 (or so).

[Altera_Forum]

I forgot to mention that the depth of the fifo is 4096 words( 16kB ). The maximum length of my messages is 1500 bytes, the clocks are 50MHz for writing and 25 MHz for reading, 1200 packets per second with some delays between) so I don't have an overflow.

[Altera_Forum]

What are your Input and output clocks? 

A few years ago I was using a DCFIFO on a Cyclone 1 where the rd clock and write clock were supposed to be the same frequency, but because they were derrived from different clock inputs, they had potential phase and PPM differences. (It was an onboard 28.93 MHZ crystal and a recovered 28.93 MHz clock from a fibre optic link). This was buffering video data. The DC FIFO was async reset at the end of every line. Over/underflow protection were turned on IIRC.  Every now and again, the data in the FIFO would repeat itself, looking like the read counter was overflowing. I fixed it by using a custom fifo that wouldnt allow data to be ready until it had a minimum number of values in the memory (I set it to about 8), so that I wouldnt get over/underuns.

[Altera_Forum]

The fifo is used for a MII communication (50 MHz input and 25 MHz output). For this particular project, I'm driving an ethernet PHY, so the wrclk is from the internal FPGA pll, and the rdclk is from the PHY. The fifo I mentioned is used for tx part, in which I have full control. First I write the message to this fifo, and after that I give the "send" command by writing the length of the message in a different fifo.  

I have a solution for this problem, knowing what the first useful byte must be, I can reset manually the fifo, but I disagree with this solution because by doing this I miss a packet. :|

[Altera_Forum]

Are You sure it's LIFO? If You're giving 0xAABBCCDD to the FIFO and reading 0xDD 0xCC 0xBB 0xAA on the read side, then this behavior is normal afaik.

[Altera_Forum]

I assume you are using a recent Cyclone III or IV FPGA. 

 You said that you put the metastability protection to 3 stages. Did you enter the value '3' in the component instantiation? If so, you only have 1 FF sync stage as from Cyclone II and Stratix II onwards a value of '2' gets deducted. Altera always surprises us in mysterious ways :rolleyes:

[Altera_Forum]

I'm using Cyclone III , and the value of "3" for sync stages is set from the megawizard GUI. I understand correctly that if I want a real value of 3, I must put the value in the GUI to 4?

[Altera_Forum]

No, the MegaWizard GUI sets the correct values . (I almost never use the MegaWizard for fifos or Rams)