A question about the asynchronous clear signal of dual clock FIFO

[Altera_Forum]

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 them are generated through the same PLL with the input clock of 30MHz.  The aclr signal of this FIFO is generated in the 90 MHz clock domain, which means it is synchronous with the 90 MHz clock and the aclr pulse width is 6 clock period of 90 MHz.  I turned on the Recovery/Removal analysis in the Quartus. And the final timing report shows that the Recovery timing requirement can not be achieved in many paths starting from this aclr signal.  According to the Quartus handbook, Recovery time is the minimum length of time the de-assertion of an asynchronous control signal, for example, clear and preset, must be stable before the next active clock edge. Whose edge does the next active clock edge here mean? the rising edge of the 90 MHz write clock or the 60 MHz read clock in my design?    Does this Recovery timing failure mean some data in the FIFO can not be cleared in one period of 90 MHz clock? If so, can I just ignore this Recovery timing failure since there is always a delay(about 1 us) between the assertion of aclr signal and next write FIFO operation in my design?  In addition, is there any requirement on the width of the aclr pulse? Is one write clock period enough?

[Altera_Forum]

If you're not writing to the FIFO out of reset, then you can put a false path on that. (set_false_path -from [get_keepers {reset_register_or_port}] -to [get_keepers {*dc_fifo_hierarchy*}] 

Also make sure you're not reading, or that read protection is on(which is on by default). The aclr can be very short, so one pulse should be fine.

[Altera_Forum]

Does this Recovery timing violation mean some data in the FIFO can not be cleared in one period of 90 MHz write clock?  

Assuming the write operation is started on the next clock edge right after the de-assertion of aclr signal, this recovery timing violation will lead to logic error. But, 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.  Is my understanding right?

[Altera_Forum]

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 and search for the TimeQuest User Guide. I did a write-up on recovery/removal violations there.

[Altera_Forum]

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