OnChip Fifo Status Shows simultaneous FULL and EMPTY!

Altera_Forum · ‎03-10-2014

I have a simple Dual-Port 4k On-Chip FIFO, with the out/csr-port connected to the Nios avalon in qsys, and the in-port from external logic.

As a test, I have the input pumping incrementing data at 1Mhz, while the Nios runs at 50Mhz and continuously checks the CSR status and reads it into a buffer if status is not empty (i.e. bit 1 == 0)


altera_avalon_fifo_init(FIFO_0_OUT_CSR_BASE ,  0, 8, 1024 );
and
if ( 0 == ( *pCsrFifoStat & ALTERA_AVALON_FIFO_STATUS_E_MSK))
    fillBuffer  = *pFifoOut;

From the start, whenever Empty is high, so are the other flags (full, almost full , and almost empty (i.e. 0x0f). When 'empty' is 0 and a read is actually performed the status still doesn't look great (0x10 or 0x31 or 0xc0 or 0xc5, or 0xf0, etc). Strangely, this mechanism works enough for the buffer to show valid continuous data for the first ~5000 entries or so.

As it runs longer, however, data starts sporadically dropping with the status slowly drifting up: 0x5F, 0x7F, 0x9f, 0xAf, 0xCF, 0xEF with fewer and fewer 'not empty'

Finally, if I periodically pause the incomming data then everything works fine, and there's no gaps in the fifo buffer, unfortunately, I can't pause the data source in the real application!

Altera_Forum · ‎03-10-2014

Are both your fifo clocks ok? No glitches? Is your design properly constrained and does it meet all timing requirements?

You can also try and recompile your project after having deleted the db and incremental_db folders. I've seen weird things with the full and empty signals on generated FIFOs when Quartus re-uses parts of a previous compilation (at least on Quartus 10 and 11.1)

Altera_Forum · ‎03-11-2014

--- Quote Start ---

Are both your fifo clocks ok? No glitches? Is your design properly constrained and does it meet all timing requirements?

You can also try and recompile your project after having deleted the db and incremental_db folders. I've seen weird things with the full and empty signals on generated FIFOs when Quartus re-uses parts of a previous compilation (at least on Quartus 10 and 11.1)

--- Quote End ---

Everything is well constrained, but I am using the older 11.1 quartus. However, I'm using it in such a basic way that I doubt it's on their end.

The nios and fifo clocks come from a pll, however, originally, when I tried feeding the clock directly to the in-port of the fifo, the fifo never saw ANY data. I put the clock bridge in there since it seemed to make sense at the time, but actually, it should work without it so perhaps that's a clue.