Description
This wiki page is dedicated to users that are using Intel PSG DCFIFO IP or dual clock FIFO IP. Timing constraints for the DCFIFO can be confusing and not implemented correctly leading to difficult problems to solve in the field when 1 in 100, 1 in 1,000, 1 in 10,000 failures are being seen or when failures are being seen across temperature testing.
The DCFIFO IP can be created with embedded RTL timing constraints or a generated SDC file. A description of both can be found here: ug_fifo.pdf
Many users that implement the DCFIFO have incorrectly created blanket false paths that cut valid timing paths within the DCFIFO. Although the DCFIFO is an effective way to bring data from one clock domain to another, if it is not properly constrained, data corruption can occur because of valid timing paths that were not properly analyzed.
The timing constraints generated either via embedded constraints or via sdc file MUST BE PROPERLY UNDERSTOOD before signing off design as timing clean. This article will cover DCFIFO implementations that do not synchronize the reset input to the DCFIFO as well as ones that synchronize the reset input ("Add circuit to synchronize aclr input with wrclk" and "Add circuit to synchronize aclr input with rdclk" as shown in the DCFIFO 2 tab of the DCFIFO IP). The DCFIFO has just one reset input which feeds both the write side and read side of the DCFIFO, thus there will always be a timing violation, likely recovery, associated with the reset into the DCFIFO regardless if the reset into the DCFIFO is synchronized to either the read side or the write side clock domain.
The example assumes a user is optimizing the DCFIFO as shown below.
Example
A design example was created to show two bad implementations of the DCFIFO in terms of timing vs. four good implementations of the DCFIFO. The four good implementations still require manual sdc constraints to false path from the external reset to the DCFIFO write or read side reset synchronization registers. Those constraints can be found in the project sdc file.
The design example was created using Quartus Standard version 18.1.
DCFIFO Timing 18.1.qar - See attached at the bottom of this article
In Top.v of the example, there are eight implementations of DCFIFO. Pins in/out to/from the top level are registered and then used as virtual pins in the design. Two IOPLLs are used in the design to create the asycnhronous write and read side clocks. Two instances of the IOPLL are used. Instance 1 feeds the two bad implementations of DCFIFO so it is clear which clock domains have timing errors that are bad and that should NEVER be false pathed. Rather, the DCFIFO should be designed with at least the write side or read side reset signal synchronized.
IOPLL instance 2 feeds the six correct DCFIFO implementations. Those six implementations require specific false paths as shown in the sdc file. NO OTHER FALSE PATHS should be manually created outside of what is shown in the example.
The example was migrated from 17.1 to 18.1 and now also implements two instances of mixed-width DCFIFO. One has the write side data width 4x wider than the read side data width. The other has the read side data width 4x wider than the write side data width. Please refer to the section below "IMPORTANT NOTE FOR DCFIFO MIXED WIDTH USERS" for more information.
The top-level reset in the design is a asynchronous into reset and synchronous out of reset circuit. This type of reset requires that the timing path from the reset be analyzed in relation to the clock at the synchronous elements asynchronous reset input pin. Intel PSG refers to recovery analysis on the asynchronous input pin analogous to performing setup analysis on a synchronous input. Similarly, Intel PSG refers to removal analysis on the asynchronous input pin analogous to performing hold analysis on a synchronous input.
MAKE SURE RECOVERY AND REMOVAL VIOLATIONS ARE CLEARLY UNDERSTOOD BEFORE creating false paths and eliminating these paths from timing analysis. More often than not, reset circuits have to come out synchronously, and masking the exit from reset can result in state machines coming up in invalid states.
Common Timing Violations
The following are examples of common destination recovery timing violations seen that can be seen when not synchronizing the aclr reset into the read side clock domain of the DCFIFO.
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_sm6:rdptr_g1p|counter1a*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_sm6:rdptr_g1p|parity*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_sm6:rdptr_g1p|sub_parity*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|alt_synch_pipe_0ol:rs_dgwp|dffpipe_hd9:dffpipe8|dffe9a[*]
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|alt_synch_pipe_0ol:rs_dgwp|dffpipe_hd9:dffpipe8|dffe10a[*]
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|altsyncram_juc1:fifo_ram|ram_block7a*~reg1
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst1|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|rdptr_g[*]
It is best to make sure you synchronize the aclr reset into the read side clock domain. Do not false path the above destination violations otherwise.
The following are examples of common destination recovery timing violations that can be seen when not synchronizing the aclr reset into the write side clock domain of the DCFIFO.
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_o4c:wrptr_g1p|counter4a*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_o4c:wrptr_g1p|parity*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|a_graycounter_o4c:wrptr_g1p|sub_parity6*
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|alt_synch_pipe_0ol:ws_dgrp|dffpipe_hd9:dffpipe8|dffe9a[*]
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|alt_synch_pipe_0ol:ws_dgrp|dffpipe_hd9:dffpipe8|dffe10a[*]
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|delayed_wrptr_g[*]
DCFIFO_no_aclr_sync:DCFIFO_no_aclr_sync_inst2|DCFIFO_no_aclr_sync_fifo_171_xk74hiq:fifo_0|dcfifo:dcfifo_component|dcfifo_iq52:auto_generated|wrptr_g[*]
It is best to make sure you synchonize the aclr reset into the write side clock domain. Do not false path the above destination violations otherwise.
IMPORTANT NOTE FOR DCFIFO MIXED WIDTH USERS
The DCFIFO mixed width configuration pre Quartus 18.0 does not correctly synchronize the reset into the read side address counter when the read side is smaller than the write side. In Quartus 17.1 and below, you may see recovery violations to the following read side counter:
DCFIFO_rdwr_aclr_sync_mixed_width:DCFIFO_rdwr_aclr_sync_mixed_width_inst|DCFIFO_rdwr_aclr_sync_mixed_width_fifo_171_c6gadny:fifo_0|dcfifo_mixed_widths:dcfifo_mixed_widths_component|dcfifo_nn52:auto_generated|cntr_7ld:cntr_b|counter_reg_bit*
The above should not be false pathed. The aclr signal on the DCFIFO is incorrectly brought directly to the read side counter even if the "Add circuit to synchronize aclr input to rdclk" is used as the option in the IP. This is a bug in the DCFIFO generation for mixed widths when the read side is smaller than the write side, for instance the write side it 256 bits wide and the read side is 16 bits wide. In cases where you are seeing the above, make sure the asychronous reset into the DCFIFO is synchronized to the write side, then change the external reset to be synchronized to the read side clock domain. You will see two recovery violations to the write side aclr synchronization registers and it is OK to false path them. For example:
set_false_path -from {reset_rd_sync2[1]} -to {DCFIFO_rdwr_aclr_sync_mixed_width2:DCFIFO_rdwr_aclr_sync_mixed_width2_inst|DCFIFO_rdwr_aclr_sync_mixed_width2_fifo_171_dl44gqi:fifo_0|dcfifo_mixed_widths:dcfifo_mixed_widths_component|dcfifo_8m52:auto_generated|dffpipe_3dc:wraclr|dffe1a[0]}
set_false_path -from {reset_rd_sync2[1]} -to {DCFIFO_rdwr_aclr_sync_mixed_width2:DCFIFO_rdwr_aclr_sync_mixed_width2_inst|DCFIFO_rdwr_aclr_sync_mixed_width2_fifo_171_dl44gqi:fifo_0|dcfifo_mixed_widths:dcfifo_mixed_widths_component|dcfifo_8m52:auto_generated|dffpipe_3dc:wraclr|dffe2a[0]}
In Quartus 18.0, the DCFIFO mixed width RTL generation was fixed to bring the read side synchronized aclr signal to the read side counter.
There is no timing issue when using DCFIFO mixed-width with read side data width larger than the write side. The write side counter correctly receives the aclr signal synchronized to the write side clock domain.
LOOK FOR THIS TYPE OF EMBEDDED SDC CONSTRAINT IN TIMEQUEST
Open up Quartus Timequest, then in tasks "Create Timing Netlist". Again in tasks, run the "Report SDC". In the Report, open the SDC Assignments folder and then look at the "Set False Path" table.
If you see something like this:
Where you see "HDL-embedded SDC_STATEMENT" and timing cuts from *rdptr_g* or *delayed_wrptr_g*, the IP is likely cutting all FIFO pointer paths incorrectly. This statement should NOT be in Timequest and indicates there could be a potential DCFIFO timing issue in the design. In some cases, designers have checked the "Generate SDC file and disable embedded timing constraint" box, but the above HDL-embedded SDC_STATEMENT is still showing up in Timequest.
In most cases, this is because the DCFIFO was instantiated directly in the RTL code. When instantiated directly, the following qsf must be added to ignore the embedded set_false_path statements as shown above.
set_global_assignment -name DISABLE_EMBEDDED_TIMING_CONSTRAINT ON
After adding the above qsf, a user must manually at SDC constraints to properly constrain the DCFIFO.
Why do I see incorrect functionality in hardware for my DCFIFO and Mixed-Width DCFIFO Megafunction?
If you have a design in the field and need to know if you are vulnerable to the above KDB link, refer to the below user guide and download the skew_report.tcl script.
FIFO Intel® FPGA IP User Guide
Go to section:
"Gray-Code Counter Transfer at the Clock Domain Crossing"
