Forum Discussion
Altera_Forum
Honored Contributor
16 years agoLet me share something with you I found out about the DC-FIFO the hard way. It may or may not affect the issue of keeping read request asserted indefinitely. Internally, the DC-FIFO uses grey code to track position of it's read and write pointers relative to one another. Because there is a domain crossing here, there is a set of false path constraints that need to be implemented.
The trouble arises when the grey code signals that are false pathed have a high level of skew between the individual nets. In our case, this was probably exaserbated by the design having almost 90% utilization of the part. A high amount of skew on those traces could cause the grey code to appear out of order momentarily. When the read and write pointer locations are significantly different, this is not an issue (We predicted more than 8 locations of delta), but if you have an empty fifo and start populating the FIFO with data and use your NOT EMPTY to drive your RD_REQ for instance, you can get a "burp" where NOT EMPTY asserts, causing you to pull out a piece of data and in doing so, cause the NOT_EMPTY to de-assert for one clock, and then have it assert NOT EMPTy again. In our implementation, we loaded the FIFO at 200MHz data rate and read at 125MHz and made an "assumption" that once we got a NOT_EMPTY, it would remain so, until we had extracted a full packet from the FIFO. That turned out to not be the case.... so be careful. We had to work with Altera for about a month before we could prove it to everyone that this was actually happening.