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

[Altera_Forum]

Hi All and sorry for the verbose subject. 

 I'm trying to close timing on a design which uses a lot of clock gating throughout the design. I believe the mapper does not read in a specified SDC file, but the fitter will use the SDC file during place and route. Are all constraints used by the fitter? I notice that some constraints, like create_clock, can take a net as an argument, but others, like false path, require a port, or register. Do I need to worry about one part of the tool reading my sdc correctly and the other not? I usually use commands in quartus_sta --shell to check if my syntax is correct before adding it to the sdc and re-running the fitter.  In general with clock gating, is it important to specify every clock in the sdc manually, whether it's a gated or inverted version, or is the tool smart enough to find them? It would be really helpful to know before doing this, as the clock gating is at many levels of hierarchy and it will need some work developing scripts to parse the rtl to catch them all.  Thanks a lot,  Steve

[Altera_Forum]

Where you absolutely must put a generated clock is for a ripple clock, i.e. one that goes through a register, as TimeQuest won't propagate clocks through registers. When you're gating clocks(going through logic), that is just a delay, and the clock will go through it. 

A classic example would be a 2:1 clock mux, where the select is driven by a registers.  - TimeQuest will propagate both clocks through the mux to all downstream logic and analyze the logic under both domains. - It will also analyze the worst case scenario where clkA feeds through the mux to launch registers and then clkB feeds the destinations(basically if you're switching on the fly). This is almost never wanted, so you need to cut timing between clkA and clkB, with something like: set_clock_groups -asynchronous -group {clkA} -group {clkB}  This could be part of a much larger set_clock_groups. - The path from the select is not analyzed as a clock, since it is through a register. So most people doing a clock mux like that would only have to constrain clkA and clkB with create_clock and then cut timing between them, and it does what they want. Why would you put create_generated_clock assignments on the output of the mux? The benefit is that it names the domains downstream from the mux, for cases you might want that. For example, if you add something like: create_generated_clock -name clkAmux -source clkA [get_cells {muxname|combout}] create_generated_clock -name clkBmux -source clkB [get_cells {muxname|combout}] So one benefit that isn't even related to constraints is that you can do: report_timing -to_clock clkAmux ... This allows you to analyze that logic separately. But you can also use it for constraints. For example, let's say there's a source register fed by clkA(not the muxed version) and a destination fed by clkB, and you wanted that to be timed. In the previous example, that path would be cut since you cut timing between clkA and clkB. By having clocks generated on the mux output, you can do: set_clock_groups -exclusive -group {clkAmux} -group {clkBmux} In this case, I've only cut timing between A and B after the mux, and the path directly fed by clkA and clkB would be analyzed. There are various combinations of this. (For example, you might want to cut timing from clkA to clkAmux, and you can do this now). It basically gives you more flexibility than the simpler case, although I find many people get by with the simpler case.

[Altera_Forum]

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

[Altera_Forum]

You can't have a clock in more than one -group within a single set_clock_groups assignment. (Not sure why, as it would be nice). Using multiple assignments, there are multiple ways to do it. I didn't follow exactly what you want so don't take these as literal solutions, but: 

1) You could cut clk3 from everyone else first: set_clock_groups -asynchronous -group {clk3} {clk0 clk1* clk2*} Note that I also used wildcards, which can help with readability, but has it's own dangers... Then do individual groups, like: set_clock_groups -asynchronous -group {clk1a} -group {clk1b} set_clock_groups -asynchronous -group {clk2a} -group {clk2b} This cuts timing between the multiple clocks coming out of a single mux, but leaves everything else related(the default), so clk0 is related to everything, clk1a is related to clk0 and clk2*, etc.   Is that close?

[Altera_Forum]

Yea, I think you got it, and I'm running that right now, since I got an error with what I previously posted. 

 Thanks,