Forum Discussion

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

Megawizard FIFO problem: Write and read request filling FIFO!

Hi,

Well this has to be the most bizarre problem I've ever encountered. I've found that the read request signal to the fifo occasionally results in the fifo used counter to be incremented and the data output corrupted. The fifo works normally for what i'd say to be several thousand read/write operations before the problem occurs.

I've implemented a megawizard fifo with the following specs:

Size: 64 words

Width: 32-bits

Read Clock: 133Mhz

Write Clock: 33.25Mhz (derived from read clock)

Clock sync: 2-stage clock synchronization (for asynchronous read and write clocks)

FIFO mode: Legacy

Memory: M4K

Optimised for: Speed

No overflow protection circuitry has been disabled.

I've attached a jpg of the signal tap capture and also a zip file containing the vector wavefile (VWF).

I'm using TimeQuest analyser and Quartus 7.2. Using the multicorner analysis TimeQuest does not report any timing violations.

I've defined the two clocks as the following in my SDC:

create_clock -name sclk -period 7.519 -waveform { 0.000 3.759 }  

create_generated_clock -name sclk_1_4 -source  -divide_by 4 

I chose the 2-stage synchronizer for the FIFO read/write operations as a precaution for any phase difference between the clocks that might cause a problem.

I can't think of anything else obvious. Any comments or suggestions would be appreciated.

Evan.

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hey Rysc,

    Now I can sleep at night! I was curious to as how something as seemingly robust as the FIFOs could malfunction in such a way. I'm grateful, as at the moment I didn't have the time to investigate (project overdue). Its reassuring to know that there was a logical explanation. I think I've learnt a valuable lesson and thats not to discount meta-stability for any problem, and the value of real scope!

    Kind regards,

    Evan.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Yeah, it was really bothering me, as I assumed the counters always counted up. Note that technically this isn't a metastability issue(where a register goes metastable), but a glitch(extra clock edge faster than the design will run at), causing the parity bit to get out of alignment with the count value. I was thinking it could be more robust without the parity value(and just do an XOR decode of the count value), which would make it always count up. This would make the design larger and slower, and the bottom line is that I've never seen a design that can handle clock glitches. So though the FIFO pointer might not count backwards, the counter would still jump to an incorrect value, state-machines would jump to bad states, etc. I often under-appreciate how dependent everything is on a good clock.