DCFIFO not empty but rdusedw=0 ?! (Agilex)

[alexislms]

I had the unpleasant surprise to see a FIFO being full with 0 word, and being not empty with 0word inserted.

Possible cause:

For lpm_numwords=32, I set lpm_widthu to be 6. Nevertheless for 32 depths, I get a compilation error telling me lpm_widthu has to be 5.

101 digital electronics: 2^5=32, the values can go from 0 to 31, how a 5b word can represent the number 32?

Documentation from September 2010 Altera Corporation SCFIFO and DCFIFO Megafunctions:

Am I missing something?

[sstrell]

The document you posted says the upper limit must be less than or equal to, not just less than.  Maybe you missed that?  So with lpm_widthu = 5, lpm_numwords must be greater than 16 and less than or equal to 32.

[alexislms]

Thank you for your answer.

and less than or equal to 32 I set lpm_numwords value to 32. You agree that I did nothing out of specs, thank you for the confirmation.

Coming back to my question: how a 5b word can represent the number 32? (as you also wrote, 32 is a correct value for  lpm_numwords and lpm_widthu=5)

Without even debating that, does everybody consider acceptable to see a fifo full and non-empty with no word inserted (or at least the counter showing 0)? In the steady-state after 10s of clocks to have the *usedwd stable and respecting the specs.

Regards,

[sstrell]

You don't specify which device you're using, but the DCFIFO guide (v18.0) says this in the signal table for wrusedw:

"For Stratix, Stratix GX, and Cyclone devices, the FIFO Intel FPGA IP core shows full even before the number of words stored reaches its maximum value. Therefore, you must always refer to the full or wrfull port for valid write request operation, and the empty or rdempty port for valid read request operation regardless of the target device."

So I guess you only need 5 bits of wrusedw because when you get to 32, wrfull goes high and wrusedw goes back to 0.  wrfull is your "6th bit".

[alexislms]

Sorry about that, I edited the question, my device is Agilex.

The screenshot represents a steady state, anything timing related between the full signal and the wrusedw is irrelevant. The wrusedw is still wrong.

There are other cases we want to know the number of words inside the FIFO. I, of course, use the full signal to trigger correct write operations.

wrfull is your "6th bit"  That's quite an unacceptable workaround and I really don't understand how this kind of weird inconsistency design can be approved by an engineer.

Xilinx has been smarter with their XPM IPs and shows consistency by adding 1b width to the counter to always show the correct value.

How about the read side? rdusedw is actually the one I really use. Which signal becomes my 6th bit?

Why does it show it non-empty with 0 data in? (again, with the fifo being full at the same time and in a steady state)

Thank you for trying to help me but convincing me the inconsistent design and flaws are normal is a lost cause.

[sstrell · Accepted solution]

I'm just going by what I think is the most recent version of the guide:

https://www.intel.com/content/www/us/en/docs/programmable/683522/18-0/fifo-user-guide.html

Looking through it, I see the add_usedw_msb_bit option, which might be what you're looking for to see the correct value on rdusedw and wrusedw.

I don't know why the read side is showing empty when wrfull indicates it's full (which is strange), but check out the latest version of the guide and see if that helps.  You're looking at a 12 year old version of the doc.

[alexislms]

Good catch, indeed I used an old documentation because the formula isn't present in the new one.

It's just crazy that it rolls over to zero per design... I really thought we were done with such mistakes after the Ariane 5 rocket crash due to an overflow.

Fascinating, instead of fixing the IP for good and make it consistent, let's add a parameter as a workaround.

Thanks!

edit:

Actually the lpm_numwords' formula was changed in the new one, it's even more restrictive:

The value assigned must comply to the following equation: 2^LPM_WIDTHU

[ShengN_Intel]

Hi,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

[alexislms]

You must be kidding... add_usedw_msb_bit is only available on DCFIFO.

How on earth this could not be applicable to the SCFIFO too?! Seriously?!