Timing constraints, collection naming, tool flow, and clock gating

Hi Folks,

Rysc I want to thank you, this post has come in handy many times over the last few weeks of work I've been doing. I have an extension I was hoping to get some help with.

I have exactly the situation you described, where I have clock muxes with control signals that are quasi-static, and I don't want to analyze paths between a node using one mux input and a node using another. So if I had only two clocks I'd do as you describe. But say I have two 2:1 clock muxes and another main system clock. I want to cut timing between the inputs to the clock muxes but continue to analyze timing from those to the other paths. So if the main clock is clk0, the two generated clocks off of one mux are clk1a and clk1b, and the two generated clocks off of the second mux are clk2a and clk2b. And then I have clk3 which is totally asynchronous. Would I set it up like this?

set_clock_groups -exclusive -group {clk0 clk1a clk2a} -group {clk0 clk1a clk2b} -group {clk0 clk1b clk2a} -group {clk0 clk1b clk2b} -group {clk3}

Now if I have this right imagine I have way more than 2 clock muxes and it gets to be pretty long to enumerate, is there a better way to do this? I originally had

set_clock_groups -asynchronous -group {clk0} -group {clk3}

set_clock_groups -exclusive -group {clk1a} -group {clk1b}

and this started analyzing paths between clk1a and clk3...

Thanks a lot,

Steve