Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16602 Discussions

SDC File rules for Synchronizers

Altera_Forum
Honored Contributor II
3,354 Views

Hello All, 

I feel like this question has been asked before but I must not be searching for the right keywords. Do here it goes again: 

 

I have two clock domains in my design. One is the main system clock running at 200MHZ and the other is the ADC clock coming from the ADC running at 14.6MHZ. I use FIFOs to receive the data and pass it to the rest of the FPGA logic.  

 

At some point, the FPGA logic needs to clear the fifo and other associated registers in the ADC clock domain. So I put a two stage synchronizer between the reset signal from the 200MHz clock domain and the ADC clock domain. 

 

TimeQuest complains about not being able to meet timing into the first synchronizer stage register. 

 

What is the best way to tell the timing analyzer tool that I have a synchronizer? I defined clock groups for my system clock and adc clock and that made the error go away but I'm afraid that will lead to an under constrained design and mask future problems. 

 

Thanks, 

-Ali
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
1,749 Views

 

--- Quote Start ---  

 

What is the best way to tell the timing analyzer tool that I have a synchronizer? I defined clock groups for my system clock and adc clock and that made the error go away but I'm afraid that will lead to an under constrained design and mask future problems. 

 

--- Quote End ---  

 

If you are sure that the said synchronizer is the only clock domain crossing between these two clock domains, clock groups are the easiest way to do it.  

If you want the safest way, make your synchronizer a component and cut the timing path to the first synchronizer stage register using HDL-embedded sdc within that component. That way, whenever you need a CDC, you just "plug" that component and can be sure it affects only the single place you want it to.
0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

If you use the Altera DC fifo, they already contain an embedded false path constraint across the Clock Domain.

0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

 

--- Quote Start ---  

If you use the Altera DC fifo, they already contain an embedded false path constraint across the Clock Domain. 

--- Quote End ---  

 

 

Actually there is some ambiguity here. 

Altera dc fifo sdc does not include false path but max delay. Here is an example: 

 

proc apply_sdc_dcfifo {hier_path} {# gray_rdptr apply_sdc_dcfifo_rdptr $hier_path# gray_wrptr apply_sdc_dcfifo_wrptr $hier_path }# # common constraint setting proc# proc apply_sdc_dcfifo_for_ptrs {from_node_list to_node_list} {# control skew for bits set_max_skew -from $from_node_list -to $to_node_list -get_skew_value_from_clock_period src_clock_period -skew_value_multiplier 0.8# path delay (exception for net delay) if { ! } { set_net_delay -from $from_node_list -to $to_node_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8 }# relax setup and hold calculation set_max_delay -from $from_node_list -to $to_node_list 100 set_min_delay -from $from_node_list -to $to_node_list -100 }# # mstable propgation delay# proc apply_sdc_dcfifo_mstable_delay {from_node_list to_node_list} {# mstable delay if { ! } { set_net_delay -from $from_node_list -to $to_node_list -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8 } }# # rdptr constraints# proc apply_sdc_dcfifo_rdptr {hier_path} {# get from and to list set from_node_list set to_node_list apply_sdc_dcfifo_for_ptrs $from_node_list $to_node_list# mstable set from_node_mstable_list set to_node_mstable_list apply_sdc_dcfifo_mstable_delay $from_node_mstable_list $to_node_mstable_list }# # wrptr constraints# proc apply_sdc_dcfifo_wrptr {hier_path} {# control skew for bits set from_node_list set to_node_list apply_sdc_dcfifo_for_ptrs $from_node_list $to_node_list# mstable set from_node_mstable_list set to_node_mstable_list apply_sdc_dcfifo_mstable_delay $from_node_mstable_list $to_node_mstable_list } 

 

This raises question for set_clock_groups as it may (or not) override this sdc. I don't have answer here as I don't know how priorities work with TimeQuest
0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

I think for older families, and maybe older versions, Im fairly certain it was a false path - and false paths/clock groups have priority over anything else. At least this is what you got if you instantiated the DC FIFO yourself and didn't use the megawizard/IP catalog. 

 

For newer families they added to ability to use a max delay over a false path, probably because false paths are falling out of favour for max_delays and people were probably complaining they couldn't override the embedded constraints. Maybe DC fifo got this ability too. 

 

From the DCFIFO User Guide 18.0, Page 21: 

 

 

--- Quote Start ---  

 

Generate SDC File and 

disable embedded timing 

constraint (29)(30) 

 

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. 

 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

And to continue 

 

 

--- Quote Start ---  

 

When using the Intel Quartus Prime Timing Analyzer with a design that contains a 

DCFIFO block apply the following false paths to avoid timing failures in the 

synchronization registers: 

• For paths crossing from the write into the read domain, apply a false path 

assignment between the delayed_wrptr_g and rs_dgwp registers: 

set_false_path -from [get_registers 

{*dcfifo*delayed_wrptr_g 

[*]}] -to [get_registers 

{*dcfifo*rs_dgwp*}] 

• For paths crossing from the read into the write domain, apply a false path 

assignment between the rdptr_g and ws_dgrp registers: 

set_false_path -from [get_registers {*dcfifo*rdptr_g 

[*]}] -to 

[get_registers {*dcfifo*ws_dgrp*}] 

The false path assignments are automatically added through the HDL-embedded 

Synopsis design constraint (SDC) commands when you compile your design. The 

related message is shown under the Timing Analyzer report. 

 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

yes you right the old versions of dc fifo were set with false path. However dc fifo glitches and malfunctions are not uncommon and hard to analyse even by Altera support. The assumption is that a false path allows fitter to put registers miles apart and this may be the cause...so avoid it but clock groups may override this assumption. It is all vague isn't it?

0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

I like the component approach. What would I put in my HDL-embedded sc though? Clock groups?

0 Kudos
Altera_Forum
Honored Contributor II
1,749 Views

Isn't a DC Fifo a bit of an overkill for passing a single clear signal?

0 Kudos
Reply