set multicycle on derived clocks

I had one case where the clocks were a strange frequency(I think 4/5ths of each other) and we couldn't do it with multicycles. Instead use

set_max_delay -from [get_clocks {clkA}] -to [get_clocks {clkB}] 4.0

Where the value is whatever setup relationship you want. This will do the exact same analysis but you're directly entering a value instead of multicycle. (I was annoyed that we couldn't achieve it with Multicycles, but this works perfectly fine)

perfect. i was considering the same idea, but I was afraid this will not work the same

as multicycles.

Hi Rysc,

How will I do this if the 2 clocks are given as clock enables to the registers?

something like -from [get_fanouts {clkA}] or do I have to do more complex manipulation.

thanks.

Do you want all fanouts of clkA, i.e. it is only used as a clock enable? If so, then that is correct.

Note that multicycles and set_max/min_delay affect the same thing, which is the setup relationship. Multicycles do it in relation to the clock periods, so changing the clock also changes the setup relationship. If you use set_max_delay and the clock periods change, you need to change the value in your set_max_delay constraint.

The other things to be wary of with set_max_delay is that it overrides PLL phase-shifts and clock inversions, and so you have to factor that back in. For example, if you have two 10ns clocks and the launch clock is phase-shifted 2ns forward, the default setup relationship is 8ns, and a multicycle setup of 2 would make it 18ns. For set_max_delay, you would need to say its 18ns to emulate it.

The other one is if you had a clock domain that was 10ns and you wanted to say it was 20ns, so you might do "set_max_delay -from clk -to clk 20". That's correct for all rise->rise transfers and fall->fall transfers. But if there are rise->fall or vice-versa transfers, their default setup relationship was 5ns and you probably want to make it 15ns, not 20ns. Now, most cases are pretty straightforward and don't have these issues, but something to be aware of.

thanks rysc. My confusion on get_fanouts {CLKA} stems from the fact that

the register to register path is from Q of register 1 whose clock enable is CLKA

to D of register 2 whose clock enable is CLKB.

So I guess you are saying that the tool is smart enough to figure out that the constraint

is actually on the fanout path of register A ending on register B, even though we said

get_fanout on CLKA.

Throw it into a report_timing and see what happens, e.g.:

report_timing -setup -npaths 100 -pairs_only -from [get_fanouts {clkA}] -panel_name "Get Fanout Test"