Can DCFIFO rdreq and wrreq signal be valid simultaneously?

[Altera_Forum]

The rdclk and wrclk in my design is nearly the same frequency but not the same phase. I enabled the full and empty protect. My question is can rdreq and wrreq signal be valid simultaneously?

[Altera_Forum]

Yes. But they should be valid with respect to their individual clock domain. Meaning don't assert wrreq with the read domain clock and vice-versa. 

 Jake

[Altera_Forum]

Thanks! Jake

[Altera_Forum]

--- Quote Start ---  Yes. But they should be valid with respect to their individual clock domain. Meaning don't assert wrreq with the read domain clock and vice-versa.   Jake  --- Quote End ---   I have another question: can rdreq signal be always high? I met a problem that I set the rdreq signal to be '1' all the time, first the FIFO can work properly, after running for sometime it can not work successfully. I don't know if it is reason of rdreq signal. I simulated it with modelsim, it is OK.

[Altera_Forum]

You did say that you enabled the protection on the FIFO so there should be no issue with leaving rdreq asserted all the time. 

 Jake

[Altera_Forum]

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