Clock Gating & Gated-Clock Constraints

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

Clock Gating and Gated-Clock Constraints

Power matters as much as speed. One of the easiest ways to save power is to stop the clock when a block has nothing to do. A clock that keeps toggling wastes energy charging and discharging wires for no reason. Clock gating is the technique of switching the clock off to idle logic. This chapter explains how gated clocks work, how to constrain them in SDC (the timing constraint format), and why the gate must never produce a glitch. A gated clock is a clock that passes through a logic gate before reaching the registers. The gate has an enable signal. When the enable is on, the clock passes through. When the enable is off, the clock is blocked and the registers stop toggling. The simplest gate is an AND gate: clock AND enable. When enable is low, the output stays low and the clock is frozen. The tricky part is that the enable signal itself is timed. It must settle before the clock edge it controls, or the gate output can show a partial pulse, called a glitch. A glitch is a short, unwanted spike on the clock line. Registers cannot tell a glitch from a real edge, so they may capture garbage. The timing tool checks the enable against the clock to prevent this. That check is the heart of gated-clock constraints.

How the Clock Propagates Through the Gate

When you define a clock at an input port, the tool sends it forward through the logic. When the clock hits the gating cell, the tool carries it through to the gate output automatically. You do not need to redefine the clock after the gate. The clock that leaves the gate is the same clock, just enabled or blocked. This automatic propagation means the registers after the gate are still in the original clock's domain. They share its period and its waveform. The gate does not change the timing of the clock; it only allows or blocks pulses. So a register fed by a gated 3.84 ns clock still has a 3.84 ns period when the gate is open.

You can confirm the clock reached the registers by checking the clock network in a report. If the propagation stopped at the gate, the registers would have no clock and their paths would vanish from the analysis. That is a silent failure, so always verify that gated registers still see their clock.

The enable signal must be stable before the gating clock edge. If the gate is an AND, the enable must be steady before the rising edge, so the gate either fully passes or fully blocks the pulse. The tool checks this with a clock-gating setup check and a clock-gating hold check, much like a normal register, but the deadline is the gate's edge instead of a flip-flop edge.

For a clock-gating setup check on an AND gate, the enable must arrive before the clock's rising edge minus a small margin. For the hold check, the enable must stay stable after the falling edge so the gate does not chop a pulse short. The exact reference edges depend on whether the gate is AND-type or OR-type.

Say the gated clock has a period of 4.20 ns rising at 0 and falling at 2.10 ns. The enable feeds an AND gate. The setup check requires the enable to be valid before time 0 (the rising edge) minus the setup margin, say 0.18 ns, so the enable must settle by 3.84 ns into the prior cycle. The hold check keeps the enable stable until after the prior falling edge plus a margin. If the enable changes inside the high pulse, the gate can clip the clock and create a glitch.

The table shows that the gate type decides which edge the enable races against. Get the gate type wrong in your mental model and you constrain the wrong edge.

Integrated Clock-Gating Cells

Hand-built AND gates are risky because the enable can change at the wrong moment. To avoid glitches, designers use an integrated clock-gating cell, often shortened to a clock-gate cell. This is a special library cell that combines a latch and a gate. The latch holds the enable steady through the dangerous part of the clock cycle, so the enable can only change when the clock is in a safe state. A latch is a storage element that is transparent when its clock input is in one state and holds its value in the other. Inside the clock-gate cell, the latch captures the enable while the clock is low, then holds it while the clock is high. Because the enable is frozen during the high pulse, the output pulse is always full or fully absent. No glitch is possible.

# standard SDC — portable across compliant tools
# The clock flows through the integrated clock-gating cell.
create_clock -name clk_blk -period 5.36 \
-waveform {0 2.68} [get_ports clk_blk_in]
set_clock_uncertainty 0.21 [get_clocks clk_blk]

The timing tool understands these cells and applies the right checks automatically. The enable still has a setup and hold requirement against the cell's clock, but the internal latch widens the safe window. This makes the enable path easier to meet than a raw AND gate. Here is a worked timing view. The clock-gate cell runs on a 5.36 ns clock. The internal latch is transparent while the clock is low, from the falling edge at 2.68 ns to the next rising edge at 5.36 ns. The enable must be valid before the latch closes at the rising edge, minus the cell's setup of about 0.14 ns. So the enable deadline is 5.22 ns into the cycle. As long as the enable logic settles by then, the gate is glitch-free.

Why Gating Must Not Glitch

A glitch on a clock line is dangerous in a way that a glitch on a data line is not. Data glitches settle before the next clock edge and do no harm. A clock glitch is itself an edge. Every register on that clock sees it and may capture whatever is on its data input at that instant. The whole gated block can latch wrong values at once. This is why the enable timing is treated as strictly as register timing. The tool runs clock-gating setup and hold checks on every enable, and a violation there is as serious as a normal setup failure. If you see a clock-gating check failing by 0.30 ns, the fix is to speed up the enable logic or add pipeline stages so the enable settles sooner.

The propagation rule ties this together. Because the tool carries the clock through the gate, it knows the exact edge the enable must beat. If the clock did not propagate, the tool could not check the enable at all, and glitches would go undetected. So correct clock propagation through the gate is what makes the glitch check possible in the first place. A common error is forgetting to define the clock at the source, then defining a new clock at the gate output. That breaks the link between the enable and the real clock. The tool then checks the enable against the wrong waveform, or not at all. Always define the clock once at its true source and let it flow through the gate. It also pays to think about clock uncertainty on gated branches. Uncertainty is a small margin the tool subtracts to cover jitter and skew. A gated clock branch may have slightly different uncertainty than the ungated trunk, because the gate adds delay and can shift the edge. Setting an appropriate uncertainty on the gated clock keeps the enable check honest. Too little uncertainty makes the check optimistic; too much makes it needlessly hard to meet. Finally, remember that the enable logic is itself a timing path that must be balanced against the whole clock period. If the enable comes from far-away logic, it may need its own pipeline registers to settle in time. A common fix for a failing clock-gating check by, say, 0.36 ns is to register the enable one cycle earlier, giving it a full extra period to arrive. This trades a little latency in turning the block on or off for a clean, glitch-free gate.

Interview Q&A

through an enabled gate. When the enable is off, the registers stop toggling and stop wasting power. A gated 3.84 ns clock still has a 3.84 ns period when the gate is open.

source port and the tool propagates it through the gate automatically. The registers after the gate stay in the original clock's domain with the same period and waveform.

pulse, the gate can clip the clock and create a glitch. A glitch is itself an edge, so registers may capture garbage. The tool enforces this with clock-gating setup and hold checks.

holds the enable steady through the dangerous part of the cycle. The latch is transparent while the clock is low and holds while it is high, so the output pulse is always full or absent. This widens the safe window for the enable.

does no harm. A clock glitch is an edge itself, so every register on that line may capture wrong data at once. That is why enable timing is checked as strictly as register timing.

the link between the enable and the real clock. The tool then checks the enable against the wrong waveform or skips it. Always define the clock once at its true source and let it propagate through the gate.

Key Takeaways

• Clock gating blocks the clock to idle logic to save power; the clock is defined once at its source and propagates through the gate.
• The enable must settle before the gating edge, or the gate clips the pulse and creates a glitch.
• A clock glitch is an edge, so a whole gated block can capture wrong values at once.
• An integrated clock-gating cell uses an internal latch to hold the enable steady, widening the safe window and preventing glitches.
• Correct clock propagation through the gate is what lets the tool run the clock-gating setup and hold checks at all.