Using Clock Control Blocks

Advantages of clock control blocks:

Some device families have clock control blocks, which are dedicated silicon configured with the altclkctrl megafunction to perform functions like shutting off clocks and multiplexing clocks.

Clock control blocks have advantages over logic resources for implementing on/off gating and clock muxes. You have to be more careful to avoid timing hazards like glitches when you have logic resources in a clock path. Logic in a clock path can result in more timing variation across process, voltage, and temperature than a clock control block would have. Logic in a clock path can cause duty cycle distortion. Clock control blocks provide the best method to shut off a clock for power reduction. It is recommended that you use clock control blocks instead of logic when possible.

Preventing glitches with combinational logic resources in the clock path:

Combinational logic can produce glitches on signals. This does not matter for signals in synchronous data paths because a positive setup slack means any glitches will settle out before the signal is latched into the destination register. However, combinational logic can create timing hazards in clock paths and in asynchronous paths like resets.

If a clock logic function requires more than one LUT or ALUT, there is a potential for glitches unless the logic is structured so that glitches cannot propagate through the logic to the final LUT output driving the clock. Clock muxes that are too large to fit in a single LUT or ALUT are an example where this applies.

A LUT or ALUT output will not glitch for a single input toggling. If, for example, you use a LUT to gate a clock with clock_out = clock_in AND enable, then clock_out will not glitch while enable is inactive even though clock_in continues to toggle.

A LUT or ALUT output might glitch if more than one input toggles at about the same time. Even if the second toggling input switches between two locations in the look-up-table RAM that have the same value for the output (making the input a logical don’t-care), the output can glitch as the toggling input switches between those two locations. This means that even a 2:1 mux implemented in a single LUT can have glitches on the output while the mux select is held constant. If a LUT implements a clock mux with inputs clk_a and clk_b, then toggling on clk_b can cause glitches on the clock mux output while input clk_a is selected. To avoid timing hazards, the clk_b input to the mux needs to be held static while clk_a is selected (and vice versa).

For a clock multiplexer or other clock logic function implemented in logic resources instead of in a clock control block, make sure that each LUT or ALUT has at most one input toggling at a given time. Below is what someone else wrote suggesting a way to do this for a 2:1 mux. You can use “keep” synthesis attributes, instantiate LCELL primitives, or use WYSIWYG primitives to control how the logic is broken down into individual LUTs or ALUTs.

Make sure each clock is gated prior to the mux to prevent glitches on the output. So:

   clk_a ---|
            +-----\    +-------+
            | AND  >---| LCELL |–-- mux_input_a
            +-----/    +-------+
enable_a ---|

   clk_b ---|
            +-----\    +-------+
            | AND  >---| LCELL |–-- mux_input_b
            +-----/    +-------+
enable_b ---|

The outputs of the LCELLs will feed the mux, and only the active clock will be toggling when it hits the mux as it will be the only enabled clock. The mapper will collapse the “extra” LCELL into the AND, but it will not collapse the AND functionality into the mux, giving you what you want.

Other timing hazards from combinational logic resources in the clock path:

Combinational logic in a clock path can create other timing issues like runt pulses, which might or might not matter for the design. For example, disturbances on the output of a clock multiplexer when the mux select lines change might be acceptable to the design. These timing hazards will not be covered here.

Duty cycle distortion from combinational logic resources in the clock path:

Logic in a clock path can cause duty cycle distortion. Delays through logic and routing can be different for falling edges and rising edges. The more logic there is in a clock path, the more potential there is for these falling-edge and rising-edge delay differences to add up to a significant amount of duty cycle distortion. For device technologies older than 65 nm, the timing analysis does not include rise/fall analysis. For Cyclone III and Stratix III, rise/fall analysis in TimeQuest will account for the duty cycle distortion, but it will still worsen the timing if both edges of the clock are used (for example, source register launching at the clock rising edge and destination register latching at the clock falling edge a half-cycle later with the duty cycle distortion being in the direction of reducing the clock high pulse width).

Clock multiplexer protection in synthesis:

Starting in version 7.1 for the original Stratix device family and newer families, Quartus II integrated synthesis has had clock multiplexer protection. The description for this setting in the “More Analysis & Synthesis Settings” dialog box says that this feature causes multiplexers in clock networks to be decomposed and mapped into trees of 2:1 muxes. It maintains the unateness of clock signals so that TimeQuest can analyze the clock edges properly. (Unateness has to do with how rising or falling edges on LUT inputs result in rising or falling edges on the output.) It also helps to balance the delay from each clock source to the destinations.

Clock multiplexer protection in versions 7.1 and 7.2 does not do anything to avoid timing hazards caused by the combinational logic. It is up to the user to implement techniques like the one illustrated above to prevent glitches even with clock multiplexer protection enabled.

Because clock multiplexer protection implements a large mux as a tree of 2:1 muxes, it increases the levels of logic in the clock path. The additional levels of logic increase the potential for duty cycle distortion. They also increase the total delay through the clock path, which increases the clock skew if there are synchronous cross-domain data paths going to or from the mux output clock domain. This skew does not matter if design guideline #2 is followed to avoid synchronous cross-domain paths.

TimeQuest for clock muxes:

Regardless of whether you implement a clock multiplexer in a clock control block or in logic resources, TimeQuest is the recommended timing analyzer. The Classic Timing Analyzer is limited in its support for clock muxes.

There are some TimeQuest clock multiplexer examples at For a more extensive set of examples, see the Altera Forum document mentioned in the first post of this thread.

Add picture from clipboard (Maximum size: 1 GB)