FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6356 Discussions

DCFIFO - Link to knowledge-base article broken

1 Solution
SyafieqS
Moderator
407 Views

Hi Sebbar,


Yes the KDB cannot be accessed as it had been removed. But here I paste the content for your reference.


Title

Why do I see incorrect functionality in hardware for my DCFIFO and Mixed-Width DCFIFO Megafunction?

Description


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.


Resolution

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.


View solution in original post

0 Kudos
2 Replies
SyafieqS
Moderator
408 Views

Hi Sebbar,


Yes the KDB cannot be accessed as it had been removed. But here I paste the content for your reference.


Title

Why do I see incorrect functionality in hardware for my DCFIFO and Mixed-Width DCFIFO Megafunction?

Description


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.


Resolution

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.


0 Kudos
SyafieqS
Moderator
384 Views

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.


0 Kudos
Reply