Forum Discussion
Honored ContributorMegawizard 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 12 Replies
Altera_ForumThe vectors look like that when you get a FIFO to over / underflow. If that is the case you could see the full or empty pulse shortly before the capture window. Equality comparators are cheaper than LT/GT's, so once you overflow it tends to stay that way.
It is downright difficult to provoke a metastability failure at 133, so it's unlikely to be synchronization related.- Altera_Forum
Bizarre indeed. Note that your read/write counters always increment, and the used words is just the difference between the two. Is it possible that, without protection circuitry, you've read past empty or written past full? This basically gets your counters to flip around each other, and so a read no longer moves the read counter toward your write counter(making the difference, rdusedwds get smaller), but it would be moving the read counter further away, making it get larger?
Can you make the two clocks outputs of a PLL? If so, they will be edge-aligned every third clock, and you no longer have to treat them as having asynchronous phases.
