Forum Discussion

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

A question about the asynchronous clear signal of dual clock FIFO

Hi, I used a MegaWizard generated dual clock FIFO in a design. FIFO width is 16 bits and its depth is 2048. The write and read clock of this FIFO is 90 MHz and 60 MHz respectively. Both of the...
Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

--- Quote Start ---

The important part is correct: "if there are several idle clock between the de-assertion of aclr signal and write operation, this timing violation doesn't matter and can be just ignored."

The first part as to why is not. It's saying that the reset de-assertion, which is driven by a clock edge, can't reach all the destinations in one clock cycle. So it's not the data in the fifo or anything like that, but the actual reset signal. Go to www.alterawiki.com (http://www.alterawiki.com) and search for the TimeQuest User Guide. I did a write-up on recovery/removal violations there.

--- Quote End ---

Hi Rysc,

Just stumbled on to this thread and had some follow up questions/clarifcations:

The document "SCFIFO and DCFIFO IP Cores User Guide" (2014.12.17) states

"The wrreq signal must be low when the DCFIFO comes out of reset (the instant when the aclr signal is deasserted) at the rising edge of the write clock to avoid a race condition between write and reset. If this condition cannot be guaranteed in your design, the aclr signal needs to be synchronized with the write clock. This can be done by setting the Add circuit to synchronize 'aclr' input with 'wrclk' option from the FIFO parameter editor, or setting the WRITE_ACLR_SYNCH parameter to ON"

and

"You may safely ignore warnings that represent transfers from aclr to the read side clock domain. To ensure that the design meets timing, enable the ACLR synchronizer for both read and write domains"

1. Given that the wrfull signal is asserted while the FIFO is coming out of reset when the WRITE_ACLR_SYNC parameter is set to "ON" (As a side note my simulations do not show this behaviour) Is the intention that we use the wrfull signal to determine when it is safe to assert wrreq to ensure that the condition outlined in the former reference in the user guide does not present a problem? Or does setting this parameter to ON mean that we don't have to worry about wrreq assertions at all when the FIFO is coming out of reset -ie- we just let the FIFO disregard the ones it is not ready for?

2. And on that note is the wrfull signal also held high while reset is asserted - surely it must be?

3. I am getting recovery timing failures errors from the aclr input to things on the write clock domain inside my FIFO. Can I "safely ignore (set false paths) these warnings" if I have implemented whichever steps above work out to be OK?

BTW: Long time fan!

Thanks