Forum Discussion
Occasional ContributorThe DC_FIFO issue of Cyclone 10 GX devices
Regular ContributorHi Minzhi,
Thank you for providing the detailed description and waveforms. I assume that the FIFO is configured to Normal mode.
This behavior typically occurs due to transceiver clock instability during power-up/reset or premature read requests before pointer synchronization is complete.
Probable root cause & recommendations:
1. Transceiver Clock Stability & Reset Sequencing (`rx_ready`):
- At power-up/reconfiguration, the transceiver CDR and PLL calibrate, during which `rx_clkout` can experience glitches or unstable frequencies before locking.
- Ensure the DCFIFO `aclr` (asynchronous reset) is held asserted until the Transceiver PHY Reset Controller asserts `rx_ready` (and both `wrclk` and `rdclk` are stable).
- After `aclr` is deasserted, wait at least 3 to 5 clock cycles before asserting `wrreq`.
2. Read Request (`rdreq`) Gating:
- Do not tie `rdreq` permanently high (`1'b1`). Asserting `rdreq` while `rdempty` is high causes FIFO underflow:
- In Normal Mode: Reading while empty results in invalid/zero data.
- Always qualify your read logic: only assert `rdreq` when `rdempty == 1'b0`.
3. Is it possible to bring the DC_FIFO signals 'aclr' and 'wrclk' also in the signal tap?
For more details on reset sequencing and timing requirements, please refer to the FIFO Intel FPGA IP User Guide on Altera.com.
Best regards,
Altera Applications Support
MinzhiWangHi Ash,
Thanks for you reply.
I think this issue doesn't relate with power-up issue. For our board has been powered on for long time when we want to operate FIFO. We have one look up table required to send to object FPGA from top-level thru DAQ and tranceiver. So you can see from previous SignalTap II images. The FIFO writing time interval is about 100 ns (Actually, our DAQ speed is only 10MHz.), and our system clock frequency is 100MHz. This look up table can be written correctly after this issue. This problem only happens when power-up/download new program. It means that we have to write this look up table two times, because the first time has this problem. We can't repeat this issue after it appears one time. If we want to repeat this issue, we have to power-up again, or download program again.
I apply 'rdreq' with '1' just for verifying FIFO writing operation. Our normal 'rdreq' signal is generated as you mentioned.
BTW, we don't open 'aclr' port for FIFO. And I don't think we can check 'wrclk' from signaltap, for sgnaltap clock frequency is equal to 'wrclk'.
Best Regrad
- Ash_R_Altera
Hi,
May I know which Quartus version is being used? Please share a smaller version of your design to replicate the issue on our side. Simulatable design is preferred.
Parallely on your side, I would like to see the DC_FIFO ports in the signal tap. Please add as many signals at the FIFO level, including 'aclr' to the signal tap and send us a screen shot. Additionally add XCVR rx_ready signal as well.
I didn't quite understood what you mean by "we don't open 'aclr' port". Do you mean you never assert and de-assert the 'aclr' port? Please clarify.
Regards,
Altera Tech Support
- MinzhiWang
Hi Ash,
- My Quartus Prime Pro version is 23.4.0.79.
- We don't use 'aclr' port. As following image indicate
Maybe, I can enable 'aclr' and use it for verification.
- My Quartus Prime Pro version is 23.4.0.79.
