I have recently encountered a bug where the Altera FIFO v17.1 Megafunction is driving the "full" signal after a single word has been written.
I have noticed that this seems to be timing related. In the best case build, I've seen it occur once in ~400 reprograms. In the worst case, it occurs once ~30 reprograms. The rest of the time, the FIFO behaves as expected. It also does correlate with temperature. I see the error occur more often at higher temperatures. In all builds, my design meets timing closure and I have double checked my constraints closely. I have not added any custom false-path constraints in my design.
The FIFO is a single-clock FIFO with the following configuration:
I caught this behaviour in SignalTap.
![]()
I have edited in the signal names. At time 0, the fifo empty is driven, and my code drives a write request and supplies data on the data lines. This fifo is 512 words large, so while I understand that there is a latency between the data being written to the write port and read from the read, I would not expect the FIFO full to be asserted so soon.
I continue to write into the fifo. The write request signal is driven by a separate counter which keeps track of the number of writes that have occurred. It doesn't use the full. There is an overflow detect mechanism in the code that detects a write while it is full (that I used to discover this error).
I perform a read request every 7th cycle, and see that the fifo is dropping the 6 samples in-between (indicative that the fifo is behaving as if it's full, even though only a couple of samples have been written of the 512). I don't have this shown on this particular SignalTap instance but saw it previously at another debug stage.
As an example of a normal behaviour, here is what it looks like in the working case. In this example I have added the almost_full and almost_empty signals too.
![]()
This is the expected behaviour. After the first write, the full is not asserted and the wrreq continues to write data for the following 200 words. The read request reads every 7th word and continues to do so after the writes have been completed (until it empties the fifo, not seen here).
This is the behaviour seen >97% of the time the FPGA is reprogrammed. This error is occurring on a Cyclone IV E device and I'm using Quartus Prime Lite Edition, V 17.1.0, Build 590 in Linux Debian Jessie.
I have done a fair amount of searching and have found examples of a bug in cross-clock FIFOs and where FIFOs are small, but nowhere have I found a report of this happening on a larger, single clock fifo. Is this a known issue, or has anyone run into this before? My next step will be to contact Altera directly by opening a support ticket.
Thanks,
Stacey
I have noticed that this seems to be timing related. In the best case build, I've seen it occur once in ~400 reprograms. In the worst case, it occurs once ~30 reprograms. The rest of the time, the FIFO behaves as expected. It also does correlate with temperature. I see the error occur more often at higher temperatures. In all builds, my design meets timing closure and I have double checked my constraints closely. I have not added any custom false-path constraints in my design.
The FIFO is a single-clock FIFO with the following configuration:
| defparam | |
| scfifo_component.add_ram_output_register = "OFF", | |
| scfifo_component.intended_device_family = "Cyclone IV E", | |
| scfifo_component.lpm_numwords = 512, | |
| scfifo_component.lpm_showahead = "ON", | |
| scfifo_component.lpm_type = "scfifo", | |
| scfifo_component.lpm_width = 72, | |
| scfifo_component.lpm_widthu = 9, | |
| scfifo_component.overflow_checking = "ON", | |
| scfifo_component.underflow_checking = "ON", | |
| scfifo_component.use_eab = "ON"; |
I caught this behaviour in SignalTap.
I have edited in the signal names. At time 0, the fifo empty is driven, and my code drives a write request and supplies data on the data lines. This fifo is 512 words large, so while I understand that there is a latency between the data being written to the write port and read from the read, I would not expect the FIFO full to be asserted so soon.
I continue to write into the fifo. The write request signal is driven by a separate counter which keeps track of the number of writes that have occurred. It doesn't use the full. There is an overflow detect mechanism in the code that detects a write while it is full (that I used to discover this error).
I perform a read request every 7th cycle, and see that the fifo is dropping the 6 samples in-between (indicative that the fifo is behaving as if it's full, even though only a couple of samples have been written of the 512). I don't have this shown on this particular SignalTap instance but saw it previously at another debug stage.
As an example of a normal behaviour, here is what it looks like in the working case. In this example I have added the almost_full and almost_empty signals too.
This is the expected behaviour. After the first write, the full is not asserted and the wrreq continues to write data for the following 200 words. The read request reads every 7th word and continues to do so after the writes have been completed (until it empties the fifo, not seen here).
This is the behaviour seen >97% of the time the FPGA is reprogrammed. This error is occurring on a Cyclone IV E device and I'm using Quartus Prime Lite Edition, V 17.1.0, Build 590 in Linux Debian Jessie.
I have done a fair amount of searching and have found examples of a bug in cross-clock FIFOs and where FIFOs are small, but nowhere have I found a report of this happening on a larger, single clock fifo. Is this a known issue, or has anyone run into this before? My next step will be to contact Altera directly by opening a support ticket.
Thanks,
Stacey