Slack issue in dual clock FIFO

[Altera_Forum]

Hi. 

I have dual clk fifo in my project for Stratix V. Write clk - 250 MHz, read clk - 100 MHz. Fifo has aclr signal that is equal to wr_rst OR rd_rst. wr_rst is synchronous to 250 MHz, rd_rst is synchronous to 100 MHz. Fifo has following parameters: .rdsync_delaypipe (4), .wrsync_delaypipe (4)  .write_aclr_synch ("ON"), .read_aclr_synch ("ON") Adding them, I try to synchronize aclr with both clocks. But TimeQuest reports about slack problems. It tolds that some fifo internal registers (rdptr, counters, etc.), clocked by 100 MHz, are violated with reset, clocked by 250 MHz. What can I do or can I ignore that slack?  Thanks.

[Altera_Forum]

1) That seems wrong, as the internal counters should be reset by the reset circuitry generated by your settings. 

2) Technically, the read side of the FIFO is usually a don't care as far as Recovery/Removal analysis. The reason is that the read logic doesn't change out of reset because the FIFO is empty. The only condition where it could be a problem is if you disabled the read protection circuitry and were issuing a read at the same time you come out of reset, which I've never seen done and seems like a bad idea all around.

[Altera_Forum]

--- Quote Start ---  1) That seems wrong, as the internal counters should be reset by the reset circuitry generated by your settings. 2) Technically, the read side of the FIFO is usually a don't care as far as Recovery/Removal analysis. The reason is that the read logic doesn't change out of reset because the FIFO is empty. The only condition where it could be a problem is if you disabled the read protection circuitry and were issuing a read at the same time you come out of reset, which I've never seen done and seems like a bad idea all around.  --- Quote End ---    Thanks for answering. I think I was wrong about violation of counters, maybe I saw results of previous compilations without fifo parameters above. Now I built the design and see violations in registers like that: fifo|dffpipe_3dc:rdaclr|dffe10a[0]. But "pipe" is synchronizer, I think it is normal that a metastability is in first synchro stage. Can I set a false path there?

[Altera_Forum]

--- Quote Start ---  Thanks for answering. I think I was wrong about violation of counters, maybe I saw results of previous compilations without fifo parameters above. Now I built the design and see violations in registers like that: fifo|dffpipe_3dc:rdaclr|dffe10a[0]. But "pipe" is synchronizer, I think it is normal that a metastability is in first synchro stage. Can I set a false path there?  --- Quote End ---    You have some 4 synchroniser chains: one for fifo pointers bridge (4 stages, either way) one for rd areset and one for wr areset(possibly two stages)  moreover you have also synchronised reset on both clocks through OR before arriving at fifo (this not necessary as you are duplicating what the tool is doing and in theory you can't usually synchronise to both clocks at same time, the OR will also add delay and create a timing path that is irrelevant).  so in short I suggest you do not use that OR logic.  BTW, if your input rate and output rate have known relationship you can avoid fifo and use dual port ram without the issues of clock domain crosssing.  @Rysc:  I have doubts about your point 2 above. The fifo being empty is irrelevant. The rd pointer once reset will force a zero on its register but but the adder (D input to register) will be any value). Historically fifos were provided with one reset option (either wr or read and this caused problems, hence the new feature of rd reset and wr reset synchronised internally).

[Altera_Forum]

hatter: yes, you can cut the path to the synchronizer. Altera doesn't do that just in case you feed it with a reset and the same domain and want it to be timed, but it can be cut. 

 kaz: I'm not sure I follow what you mean about the D input to the counter. The counter is not enabled to increment since all reads are disabled, so it doesn't matter what is at the D input since it will be ignored.

[Altera_Forum]

Note that Altera originally just added an option to synchronize the write side, since that was deemed all that was necessary for the reasons stated above. But most users didn't understand why the read didn't need to have its reset synchronized too and kept asking why we didn't do it. Rather than constantly explain it, it's easier to just add the ~2 registers for read side synchronization.

[Altera_Forum]

--- Quote Start ---  Note that Altera originally just added an option to synchronize the write side, since that was deemed all that was necessary for the reasons stated above. But most users didn't understand why the read didn't need to have its reset synchronized too and kept asking why we didn't do it. Rather than constantly explain it, it's easier to just add the ~2 registers for read side synchronization.  --- Quote End ---    The case of OP is having wr_reset separate from rd_reset. In this case both resets need to comply with timing at deassertion (recovery/removal). Imagine the case when the write clock is 4 times faster than read clock; the fifo may not be empty by the time rd_reset is deasserted and will soon increment.  If reset is only synchronised to write clock and then applied to both sides then yes and provided the user does not read immediately there is no need to worry about recovery/removal at rd side but then it is up to the tool to automatically set false path in such hidden corner.  In fact I see the new fifo desin of separate wr/rd reset as a potential pitfall unless the user is aware of internal delay of rd reset and take that into account when activating the rd logic.

[Altera_Forum]

kaz, good points.

[Altera_Forum]

One thing to note on this subject, especially around dual-clock fifos and resets is that FIFO reset clears the flags and usedwds asynchronously as I understand it. This means that if you have logic, say a state machine in the read domain looking at rdusedwds that is not reset with the FIFO you need to re-register the rdusedwds (or provide some other method of handling this case) in the read domain to keep from glitching it since rdusedwds may be cleared asynchronously. Last I checked, the sync circuit Altera adds to the FIFOs does not cover this condition. I see this situation a lot with high-speed link bring-up or hot-plugging.

[Altera_Forum]

An asynchronous reset(even if it's synchronized) should generally only be used to reset an entire domain(and usually an entire device or something on that scale) and not as logic. Static timing analysis does not time the logic being asynchronously reset to downstream logic that is not being reset, so you're always susceptible to this unless reseting everything. (If it did time it, closing timing would be significantly more difficult. For example, if you had 10ns period and a data path from reg A to reg B that was 8ns long, so it met timing, but now asynchronously reset A but not B and expected that to work synchronously and not glitch, then reset -> A -> B would all have to be less than 10ns, so now two paths would have to be under your clock period instead of just one.)