Megawizard FIFO problem: Write and read request filling FIFO!

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?

The 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.

Rysc/Gsynth,

Do you have the chance to let this run with other frequencies ? other fre-relations? Could you figure out a time pattern of the corrupted data ? Which device is it ?

Just out of curiosity, your first post says the overflow circuitry is not enabled, but your second post says it is. Can you tap out the actual counters in the FIFOs(rather than used words, which is a calculated based on the counters). That was we can tell whether the counters are in the wrong spot or the calculations of usedwds is off. In fact, I would grab as many registers as you can out of the FIFO and compare good rdreqs to bad rdreqs. I would be extremely suprised if this is a device issue:

Ditto Rysc - it's not going to be the device hardware. You might want to spec the clocks to something very fast (e.g. 1GHz) to make sure there isn't some typo / rounding error where 133 divided by 4 turns into 32, etc.

Well this is a nice coincidence, but I just talked to someone else who was seeing something similar. They were doing constant writes(no reads), and their write counter which was incrementing suddenly started decrementing. What device are you targeting and what version of Quartus.

Thanks for your help. I have solved the problem.

Strange. A glitch can cause consecutive clock edges faster than the system runs(as well as other issues), causing things to jump to bad states. For example, there are gray-coded counters incrementing, and a glitch could easily cause them to jump to the incorrect state. That being said, it seems like the used words should jump to the wrong value but from there increment/decrement in the correct direction. I don't think there's any sort of state-machine, i.e. anything dependent on the previous state(besides the gray counters themselves). But glad to hear it's working and nice job finding it. That's the type of thing someone like me would spend forever in the part trying to capture/debug.

So I knew about gray counters about as much as everyone else, they follow a count sequence that only flips one bit at a time. So I made an asynch FIFO and created a simple simulation where I could see the gray code counters increment. Looking in the RTL view, there is a parity register, a count register and decode/encode logic to calculate the next state. The parity register basically toggles between 0 and 1, which makes sense. So I added an assignment to have the parity register power-up to 1 and reran the simulation.