Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

DC FIFO mis behaving

Hello,

I used the Quartus II v8.0SP1 Megawizard to create an asynchrounous (wrclk>rdclk) DCFIFO (for stratix II) with lookahead mode for reads. The problem that I am seeing is that on some occasions the when I provide a rdreq to acknowledge the data that I have read, the new data in the FIFO is not put on the Q output. It takes 2 rdreq to output one data value on the Q. In other words, once in two rdreq is missed by the DC FIFO. See the attached rdreq_dc_fifo_rejected.jpg.

The strange fact is that, the same JIC file works fine ( Q value changing for every rdreq when there is data in the DC FIFO) when I reset the board or stop and re-start the data transfer. See the attached rdreq_dc_fifo_fine.jpg.

I am really preplexed as to what the issue is. Can anyone guide me?

Thanks,

Bipin

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    A couple of things:

    - IS your rdreq sync'd to the rdclk? there seems to be some discrepancy within the first attachment.

    - Do you know if the data was written correctly? Reading the same data twice will not show any changes on the q signals.

    Just some thoughts...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    yes the rdreq is in sync with the rd clk and also the data is written only once correctly into the FIFO.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The discrepancy must be due to the signal tap sampling clock. If you use rdclk instead, it will be clearer to see what the fifo signals are doing.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    @ Ironmoose.

    Thanks for your comment. It is not a sampling issue as the signal tap clock is greater than 2 times the rdclk. Also saw the data replicated twice on the (display)terminal hooked to the board..
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I think you need to pull out the signals within the FIFO. Specifically the gray-code FIFOs, and perhaps the usedwords(you probably have to add this into your DCFIFO). If you view the gray-code FIFOs in gray-code format, you can get an idea of if they're advancing. If they're not moving(especially the read one), then your request is "being ignored". The next question would be why is it being ignored? I would look at the usedwords(specifically rdusedwords) to see if the FIFO is in the middle of its depth or near a full/empty boundary when the occurs(yes, the flags should tell you, but usedwords is a nice gauge...) The screenshots definitely look funny, but I've done enough of these that there should be a logic explanation, you just need to peel it back a little further(which is difficult since it's someone else's code and not overly readable). You might want to look at the FIFO in the RTL view to kind of get an idea what it's doing. If you get more screenshots, please post them.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    If your read clk is in synch with your data rd request line then you should see data coming out without problems if data is present. I've used the dcfifo's a lot, and every time I thought they were doing something wrong it was really me. They are very stable, so I would suspect something wrong in your logic before I would suspect their functioning. You probably want to make sure to you use the rdempty to verify that you have enough data in there to actually read. I haven't used the lookahead outputs before.