Forum Discussion

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

lpm_fifo error

Fifo specification

lpm_dcfifo showahead 8 bit in 32 bit out 8bit x 2048 Size

40 Mhz writeclk

85 Mhz readclk

Fifo created with megawizard

Quartus 7.2sp3

underflow and overflow protection is ON

Fifo gets an "underflow" wordcounter goes from "0" to highest value

FIFO think it has data but data has not been clocked in yet....

This happens randomly.... could be after 2000 bytes or 100000 bytes...

Find a signaltap analysis attached.

Edited:

Find a second file attached... it shows a test with an empty flag at 8 words and lower... here the fifo empties itself without any read signal! :eek:

Please help me find a solution to this problem!

9 Replies

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

    Could it be, that you defined the clocks as synchronized, but they actually don't meet the timing requirements?

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

    What are your write pointers doing? Do you read out bad data(as if it really flipped to the other side) or do you read the correct data, as so the only problem is the rdusedwds, not the actual read transaction?

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

    The data that is read is corrupt.... the read side continues to read until the counters are back to normal then the reading goes back to good data...

    Take a good look at the second attachment =)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    the write pointer are ticking while the read is "stuck" :S what could be wrong?

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

    Could you correlate the last statement(about the write pointer ticking) with the previous statement(that the read counter flips and reads back to 0)? I'm sure they're related, just not sure how you're seeing them.

    Can you attach the Megafunction? I doubt it will show anything, but just a thought. As a note, the asynchronous FIFO is probably used in 90% of Altera FPGA designs, since everyone has to handle transfering data between asynchronous clocks, so I have a lot of confidence in the core. (I'm just throwing that out there in case you're concerned that it's something intrinsic to the FIFO.) If you can grab all the flags, as well as a lot of the internal registers to the FIFO in SignalTap at the time of the failure, something might show up.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    I think I found out what the problem was... the wreq was not properly held during a positive edge on the wrclk, causing the FIFO to jump to an undefined state!

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

    --- Quote Start ---

    ... the wreq was not properly held during a positive edge on the wrclk...

    --- Quote End ---

    That sounds like something that should have been reported by a timing violation. Did you get a reported violation? Or did you not have the wrclk constrained or not have the write request synchronized to the write clock?