Forum Discussion

MinzhiWang's avatar
MinzhiWang
Icon for Occasional Contributor rankOccasional Contributor
1 day ago

The DC_FIFO issue of Cyclone 10 GX devices

Hello Guys,

We are using 10CX220F780 and 10CX105F780 devices now. They are communicating thru XCVR. So one DC_FIFO is realized between RX received data and user logic fabric.

 

This DC FIFO operation always has problem during the first operating. But it will be normal during the second operating.

As the above image indicates, RX get data from XCVR and put them to FIFO. The write is ok, however, the reading has problem. Because the first read data is ZERO, this causes the following reads all halt.

I apply one more same operation, now it's ok, as following image:

As above image indicates, one data is put into FIFO, and it will be read out from this FIFO in time.

 

But why always the first time operating is not correct after power-up or re-configuring FPGA?

 

I did one test: FIFO's Rdreq is fix to high level. Then I got the following result:

As above image indicates, the first data x"40000000" can't be written into FIFO. So I always got ZERO for the first data. Buy how this can happen?  I kept detecting more deeply, as following image

As above image indicates, after Wreq valid, 2 clock cycles later, Usedw will change, and 2 more clock cycles later, empty signal will be changed to low level. 

This is the problem. Usedw and empty signals are changed too fast. I checked normal timing, UsedW should be changed 3 clock cycles later after Wreq valid, and empty should be changed 5 clock cycles later after Wreq valid.

Why can this happen? And always happen one time after power-up.

 

 

Best Regard

 

Core Logic

1 Reply

  • Ash_R_Altera's avatar
    Ash_R_Altera
    Icon for Regular Contributor rankRegular Contributor
    57 minutes ago

    Hi 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