Working Example: A Clock-Gated Block Violation

Chapter 8 · Section 8.6 · Timing-Violation Debug

Project thread — the design gains clock gating here (power management), on the counter/FSM datapath. A correctly-timed gated clock is the foundation the mini-SoC's power domains build on. Chapter 9 takes clock/reset domains and CDC as its whole subject.

1. Why Should I Learn This?

Clock gating is everywhere (power), and its timing failure mode is specific — and a perfect capstone.

• The ICG enable must be stable across the cell's window, or the gated clock glitches.
• The symptom (X on gated flops) exercises all of Ch8 (read, trace, triage, injection).
• It introduces clock gating, essential for the mini-SoC.

It integrates 8.1–8.5 on a real, common structure and closes the chapter.

2. Real Silicon Story — the block that Xed whenever it was enabled

A clock-gated block worked when always-on, but went X every time it was enabled mid-run.

The enable into the ICG cell was changing too close to the clock edge — violating the ICG's internal latch timing, so the gated clock glitched at enable time, and the gated flops captured on a bad clock → X. Registering the enable so it was stable across the ICG's window removed the glitch, and the block enabled cleanly.

Lesson: a clock-gated block that Xs on enable points at enable timing into the ICG — the enable must be stable across the cell's window, or the gated clock glitches.

3. Concept — clock gating and its timing failure

What clock gating is:

• An ICG cell gates the clock with an enable: gated clock ≈ clk AND enable.
• A naive AND would glitch if the enable changed while the clock was high — so the ICG uses an internal latch to sample the enable while the clock is low, producing a glitch-free gated clock.

The timing requirement:

• The enable must be stable across the ICG's timing window (the latch's setup/hold around the gating point).
• If the enable changes too close to the clock edge, the latch has a timing violation → the gated clock glitches → gated flops see a bad clock → X.

Applying the chapter:

• 8.1 Read: the message names the ICG/latch or a gated flop, the check, the edge, the margin.
• 8.2/8.3 Trace: is it the enable path (setup/hold into the ICG latch) or the gated flops?
• 8.4 Triage: real enable-late problem (design) vs artifact (TB toggled enable at the edge, 5.3)?
• 8.5 Injection: the gated-clock glitch injects X that floods the gated block (a flood from one enable-timing issue).

The fix:

• Make the enable stable across the ICG window — register the enable off a clean edge so it settles before the gating point.
• Confirm with STA (the arbiter of the ICG's timing, 0.3).

4. Mental Model — flip the light switch between blinks, not during one

The ICG is a light controlled by a switch (enable), and the clock is the light blinking.

• To change the switch cleanly, do it while the light is off (clock low) — the ICG's latch enforces this.
• Flip the switch exactly as the light blinks (enable near the edge) and you get a flicker — a glitched gated clock.
• The gated flops, watching the flickering light, can't tell a real blink from the flicker → X.
• Fix: decide the switch position early (register the enable) so it's settled before the next blink.

Change the enable in the quiet (clock-low) window, never on the edge.

5. Working Example — the ICG, the bad enable, and the fix

The clock-gated block (representative):

// Clock-gated block — REPRESENTATIVE. ICG gates clk with enable; gated flops on gclk.
icg u_icg (.clk(clk), .en(enable), .gclk(gclk));   // ICG: latch-based, glitch-free IF enable stable
always_ff @(posedge gclk) data_q <= data_d;         // gated flops clocked by gclk

The bug (enable changes too near the edge) and the fix:

// BUG — enable derived combinationally, changing too close to the clock edge:
assign enable = req & ~busy;        // glitchy/late enable -> ICG latch violation -> gclk glitch -> X
 
// FIX — register the enable off a clean edge so it is STABLE across the ICG window:
always_ff @(posedge clk) enable_q <= req & ~busy;   // settled enable
icg u_icg (.clk(clk), .en(enable_q), .gclk(gclk));  // stable enable -> clean gated clock

The chapter applied to this firing (representative):

# Debug the clock-gated block (applying Ch8, tool-neutral):
#   8.1 read:   message names the ICG latch / a gated flop, the check, edge, margin
#   8.2/8.3:    trace -- enable path (setup/hold into the ICG latch) or the gated flops?
#   8.4 triage: real (enable genuinely late) vs artifact (TB toggled enable at the edge, 5.3)?
#   8.5 inject: the gclk glitch injects X that FLOODS the gated block (one enable-timing source)
#   fix:        register the enable (stable across the ICG window); CONFIRM with STA

Practical context (representative, tool-neutral):

gls/
  netlist/blk.vg        # block with ICG-gated clock domain
  lib/cells.v           # ICG cell model (latch + timing checks)
  sdf/blk.sdf           # timing (Ch4)
  tb/tb_blk.v           # drives enable + clock
# Symptom: gated flops X whenever the block is enabled -> check ENABLE timing into the ICG
# Fix: register the enable off a clean clk edge (stable across the ICG window); STA confirms.

The gated-clock glitch on a bad enable, and the fix, as a real waveform:

6. Debugging Session — a gated block that Xs on enable

7. Common Mistakes

• Deriving the ICG enable combinationally. It can change too near the edge — register it.
• Assuming a naive AND gates the clock. Real clock gating uses a latch-based ICG (glitch-free if enable is stable).
• Not triaging TB-induced enable timing (5.3) vs a real enable-late problem (8.4).
• Counting the X flood as many bugs. One enable-timing source injects it (8.5).
• Skipping STA on the ICG. STA is the arbiter of the gating timing (0.3).

8. Industry Best Practices

• Register the ICG enable so it's stable across the cell's window.
• Use latch-based ICG cells (glitch-free), not naive AND gating.
• Triage enable firings real-vs-artifact (8.4) before fixing.
• Trace the X flood back to the gated-clock glitch (8.5).
• Confirm ICG timing with STA (the arbiter).

Senior Engineer Thinking

• Beginner: "The block Xs when enabled — the block logic is broken."
• Senior: "It's clock-gated — does the enable change near the clock edge? That glitches the gated clock and Xs the gated flops. I register the enable so it's stable across the ICG window, triage TB-vs-real, and confirm with STA."

The senior recognises a gated-block-X-on-enable as an ICG enable-timing problem and stabilises the enable.

Silicon Impact

Clock gating is pervasive (power), so its timing failure mode is a common, high-impact silicon bug: an ICG enable that isn't stable across the cell's window glitches the gated clock, and a glitched clock is catastrophic — gated flops capture on a bad edge, corrupting state whenever the block is enabled, an intermittent power-management-triggered failure (0.3). GLS is excellent at surfacing this (the gated-clock glitch and X flood are visible on enable), and the fix — register the enable — is cheap. This capstone shows the whole chapter working together: read the message, trace the enable path, triage real-vs-artifact, recognise the X-injection flood, and fix the source, with STA confirming the ICG timing. Getting clock-gating timing right is essential to a power-managed chip that stays functionally correct.

Engineering Checklist

• Confirmed the block is clock-gated and Xs on enable.
• Traced the enable timing into the ICG (glitched gated clock).
• Triaged real enable-late vs TB-induced enable timing (8.4/5.3).
• Registered the enable so it's stable across the ICG window.
• Confirmed ICG timing with STA; traced the X flood to the one source (8.5).

Try Yourself

1. Build an ICG-gated block; drive the enable so it changes near the clock edge — the gated clock glitches and the gated flops go X.
2. Observe: the X floods the block from the gated-clock glitch (8.5).
3. Change: register the enable (enable_q <= ...) so it's stable across the ICG window.
4. Expect: the gated clock is clean, the flops capture correctly, and the flood clears. Then triage: if you'd instead driven a stable enable but toggled it at the edge in the TB, the fix would be the stimulus (5.3).

Any free Verilog simulator with an ICG cell model and SDF timing checks reproduces this. No paid tool required.

Interview Perspective

• Weak: "A clock-gated block that Xs must have broken logic."
• Good: "Clock gating uses an ICG with an enable; if the enable changes too near the clock, the gated clock glitches and the gated flops go X."
• Senior: "I read the message, trace the enable path into the ICG latch, and triage real-vs-artifact. A gated block that Xs on enable is almost always enable timing — the ICG needs the enable stable across its window, so I register the enable. The gated-clock glitch injects X that floods the block (one source). STA confirms the ICG timing."

9. Interview / Review Questions

10. Key Takeaways

• Clock gating (power) uses an ICG cell — an enable plus an internal latch — to produce a glitch-free gated clock, but only if the enable is stable across the cell's timing window.
• The classic violation: the enable changes too close to the clock edge → the ICG latch has a timing violation → the gated clock glitches → gated flops see a bad clock and go X.
• Debug it with the whole chapter: read the message (8.1), trace the enable/gated-flop path (8.2/8.3), triage real (enable late) vs artifact (TB toggled enable at the edge, 5.3) (8.4), and recognise the X-injection flood (8.5).
• Fix: register the enable so it's stable across the ICG window (or fix the stimulus if TB-induced); STA confirms the ICG timing (the arbiter, 0.3).
• A gated block that Xs on enable is almost always enable timing into the ICG — one source, a flooding X. This closes Chapter 8; next, Chapter 9 takes CDC & asynchronous behaviour.

Quick Revision

Clock-gated block Xs on enable = enable timing into the ICG. An ICG (enable + latch) gives a glitch-free gated clock only if the enable is stable across its window; an enable changing near the edge glitches the gated clock → gated flops X (flood, 8.5). Debug via the chapter: read (8.1) → trace (8.2/8.3) → triage real-vs-artifact (8.4) → injection (8.5). Fix: register the enable (or fix TB stimulus, 5.3); STA confirms. Chapter 8 complete; next: Chapter 9 — CDC & asynchronous behaviour.