- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, -AliLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you use the Altera DC fifo, they already contain an embedded false path constraint across the Clock Domain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ---- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ---- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I like the component approach. What would I put in my HDL-embedded sc though? Clock groups?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Isn't a DC Fifo a bit of an overkill for passing a single clear signal?

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page