Honored ContributorI have a clock input that may be at 25 or 150 mhz and some of the modules in my fpga are only utilized when the system is operating at 25mhz. What sdc constraints could I use to avoid the 25mhz modules having to meet timing at 150mhz?
Honored ContributorHard to say exactly without knowing how it's constrained. Assuming you have a 25MHz and 150MHz constraint on the input, so all the logic is constrained at both frequencies, then for the relevant blocks you probably want to lower the requirement with something like:
set_max_delay -from {slow_blk|*} -to {slow_blk|*} 40.0 If you have any logic that uses falling edge clock, then it's probably safer to cover that with: set_max_delay -rise_from {slow_blk|*} -rise_to {slow_blk|*} 40.0 set_max_delay -fall_from {slow_blk|*} -fall_to {slow_blk|*} 40.0 set_max_delay -rise_from {slow_blk|*} -fall_to {slow_blk|*} 20.0 set_max_delay -fall_from {slow_blk|*} -rise_to {slow_blk|*} 20.0 (The hold time could also be loosened with a set_min_delay, but I'm assuming the hold requirement of 0ns is correct). This also assumes you don't have any multicycle paths in these blocks.Honored Contributorisn't there a way to set the clock group exclusive along those paths that won't be touched by the 150mhz?
Honored Contributorset_clock_groups only works on clocks. (Ideally you could put a generated clock on the clock going into each block to create a separate clock out of it, but I'm pretty sure that won't work, as the clock gets "flattened" to a single net driving all the clock ports).
The other thought would be to do a set_false_path using clock and node filters(like report_timing has -from_clock and -from), so you could cut paths constrained to the faster clock within those blocks, but set_false_path doesn't have those.Honored ContributorI ended up doing this and it worked fine except it won't check the output of the slow module when data from it is clocked into the faster portion but not a critical issue for me as I don't try to do any work on that stage. Still if there's a better method I'd be interested. I wasn't sure if I'd need to do a false path from the slowclk to everything but the slowmodule and maybe it might speed up timing analysis but didn't cause any strange timing errors by not doing it.
# define 2 versions of the same clk create_clock -name {fastclk} -period 6.8 [get_ports {clk}] create_clock -name {slowclk} -period 12.5 [get_ports {clk}] # avoid incorrect timing checks from output of slow module back into faster running stages set_clock_groups -asynchronous -group [get_clocks { fastclk }] -group [get_clocks {slowclk}] # mark false paths on fast clk to the slower module set_false_path -from {fastclk} -to {slowmodule|*} # maybe I should do false path from slowclk to everything but the slowmodule?Honored ContributorGood one. Kind of mixing clock/node transfers. You could add the reverse to get the output paths:
set_false_path -from {slowmodule|*} -to {fastclk} I would also clarify the clock: set_false_path -from {slowmodule|*} -to [get_clocks fastclk] Probably doesn't make any difference, but if you had a node called fastclk, it might false path to that and not the domain.Honored ContributorThanks Rysc, sounds like a good way to clean it up.
