set multicycle on derived clocks

[Altera_Forum]

hi, I have 2 derived clocks of a base clock which divide by 2 and 3 (for e.g). 

If these go to clock enables of a source and sink register,  then I wish to do a multicycle on this register 2 register path in terms of the *base* clock. However set_multicycle only takes -start or -end and using either makes the constraint incorrect. In addition the command doesn't take a fractional value. Is there a way to solve it? Can I set multicycles in terms of a base clock when the "distance" between the launch and latch clocks is say an odd no. of cycles of the base clock?

[Altera_Forum]

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)

[Altera_Forum]

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

as multicycles.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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"