Why do I see incorrect functionality in hardware when using the dcfifo IP in a Cyclone IV E FPGA design?

[MJost3]

In my design targeting a Cyclone IV E FPGA I use several dcfifo FIFOs. I observed that the first write/read FIFO transaction (after the FPGA is configured) sometimes fails in hardware. In such an error case, the output signals of the FIFO (i.e. q, empty, usedw etc.) behave completely unexpected; see the attached signaltap plot. For instance, the FIFOs fill level wrusedw jumps from 0x00 to 0x3F after the first write transaction.

Notes:

• I don't use the aclr port
• I use the show-ahead mode
• The input width is 32 bytes, the output width 8 bytes
• The wrclk is 100 MHz, the rdclk 50 MHz (clocks are synchronized)

[RichardTanSY_Intel]

"sometimes fails in hardware" - may I know is there any specific condition that it fail/pass?

Is your project got write timing sdc and close timing?

[MJost3]

Hi Shyan ,

• The test was performed at room temperature.
• It is always the first transaction that fails. I rebooted the FPGA using an automated script and approx. at every 100th reboot the first transaction fails.
• I could not reproduce this error if I reset the FIFOs at start-up using the aclr port. However, the datasheet claims that using the aclr port is optional.
• The design successfully compiled without any timing violations (I did not specifiy specific timing constraints for these FIFOs since they are provided by Altera. Is this correct?

Thanks for looking at it,

Best, Michael

[RichardTanSY_Intel]

Hi Michael,

Could you help to share the .sdc file so we can check on this?

[MJost3]

Hi Shyan,

attached you find all .sdc files we used in this project.

Except the "i214_pld.sdc", "altera_avalon_half_rate_bridge_constraints.sdc" and "spi_fram.sdc" all sdc files were automatically generated by Quartus Tool.

[RichardTanSY_Intel]

I found this kdb.

https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd02232015_507.html

It seems that additional constrain need to be added. As I do not have a design to test out, could you try to add this in manually per kdb written?

Or, could you share your design so I can duplicate the issue?

[MJost3]

Hi,

I followed the guidance described in the kdb link. Unfortunately, the issue is still there.

However, I found workaround that seems to work: When adding the aclr port of the FIFO and resetting the FIFO at start-up the issue could not be observed anymore.

It seems that the aclr port is needed, altough the data sheet does not state that (the aclr port is optional).