Due to an incorrect embedded timing constraint you may see incorrect DCFIFO IP behavior in hardware.
The erroneous timing constraint (which is embedded in the DCFIFO code) incorrectly sets a false_path assignment for the gray coded transfer between the read and write clock domains.
Although hardware failures are extremely unlikely, it is possible that the skew across these gray coded domain transfers could be large enough that corruption could occur in the receiving clock domain.
The probability of a hardware failures increases as the logic utilization and DCFIFO clock rates increase.
If your design is affected, Altera recommends the following workaround. Note that upgrading to the Quartus® Prime software v15.1 and onwards is needed for the workaround. The workaround is applicable for the below device families only:
• Cyclone® V
• Arria® II GX
• Arria V and Arria V GZ
• Stratix® IV
• Stratix V
• MAX® 10
Please follow the steps below to correctly constrain and optimize the gray coded domain transfers:
1) Apply the following assignment in your Quartus Prime Settings file(.qsf):
set_global_assignment -name DISABLE_EMBEDDED_TIMING_CONSTRAINT ON
2) Ensure that there are no user created clock_groups or false_path assignments to cut timing for paths crossing these clock domains.
Use the "report_clock_transfers" report to identify if a false_path assignment exists for the clock domain crossing in question.
3) Apply the following timing constraints:
For DCFIFO, <user hierarchy> = <full_path>|dcfifo_component|*auto_generated
For Mixed-Width DCFIFO, <user hierarchy> = <full_path>|dcfifo_mixed_widths_component|*auto_generated
set from_node_rdptr_list [get_keepers <user hierarchy>|rdptr_g*]
set to_node_rdptr_list [get_keepers <user hierarchy>|ws_dgrp|dffpipe*|dffe*]
set_max_skew -from $from_node_rdptr_list -to $to_node_rdptr_list -get_skew_value_from_clock_period src_clock_period -skew_value_multiplier 0.8
set_net_delay -from $from_node_rdptr_list -to $to_node_rdptr_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
set_max_delay -from $from_node_rdptr_list -to $to_node_rdptr_list 100
set_min_delay -from $from_node_rdptr_list -to $to_node_rdptr_list -100
set from_node_wrptr_list [get_keepers <user hierarchy>|delayed_wrptr_g*]
set to_node_wrptr_list [get_keepers <user hierarchy>|rs_dgwp|dffpipe*|dffe*]
set_max_skew -from $from_node_wrptr_list -to $to_node_wrptr_list -get_skew_value_from_clock_period src_clock_period -skew_value_multiplier 0.8
set_net_delay -from $from_node_wrptr_list -to $to_node_wrptr_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
set_max_delay -from $from_node_wrptr_list -to $to_node_wrptr_list 100
set_min_delay -from $from_node_wrptr_list -to $to_node_wrptr_list -100
set from_node_mstable_ws_list [get_keepers <user hierarchy>|ws_dgrp|dffpipe*|dffe*]
set to_node_mstable_ws_list [get_keepers <user hierarchy>|ws_dgrp|dffpipe*|dffe*]
set_net_delay -from $from_node_mstable_ws_list -to $to_node_mstable_ws_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
set from_node_mstable_rs_list [get_keepers <user hierarchy>|rs_dgwp|dffpipe*|dffe*]
set to_node_mstable_rs_list [get_keepers <user hierarchy>|rs_dgwp|dffpipe*|dffe*]
set_net_delay -from $from_node_mstable_rs_list -to $to_node_mstable_rs_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
4) Use the report_max_skew and report_net_delay reports in the TimeQuest II Timing Analyzer to verify that timing is closed.
For Arria 10 devices and onwards, the “Generate SDC file and disable embedded timing constraint” parameter under Timing Constraint section is checked by default. This allows you to bypass embedded timing constraints that uses set_false_path in the synchronization registers. A user configurable SDC file is generated automatically when DCFIFO is instantiated from the IP Catalog. New timing constraints consist of set_net_delay, set_max_skew, set_min_delay and set_ max_delay are used to constraint the design properly.