lpm_fifo error

[Altera_Forum]

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!

[Altera_Forum]

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

[Altera_Forum]

nope the clocks are not defined as synchronized in the megawizard

[Altera_Forum]

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]

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]

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

[Altera_Forum]

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]

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]

That would make sense. Glad it's working.

[Altera_Forum]

--- 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?