13.6 Glitches: Unwanted Transient Pulses

Define a glitch as the observed effect of a hazard, explain when glitches matter functionally, and describe the ripple-counter and clock-gating examples where glitch-freedom is essential.

A glitch is a short, unwanted signal transition — a brief pulse or dip that shouldn't be there — caused by unequal propagation delays along different paths in a circuit. Where the Hazards lesson (13.5) describes the underlying circuit *condition* that makes a glitch possible (reconvergent paths with unequal delay), a glitch is the physically observed *event*: the actual transient pulse that appears on a real signal or in a simulation waveform. Understanding when a glitch is harmless and when it's a serious functional bug is one of the most practically important judgment calls in digital design.

Core concept: glitch as the observable symptom of a hazard

Every static or dynamic hazard, when it actually manifests during a real input transition with real (mismatched) gate delays, produces a glitch — the momentary incorrect pulse is the glitch. Not every hazard-capable circuit produces a visible glitch on every transition (if the two reconverging paths happen to have very close delays, the glitch pulse can be so narrow it's filtered out by downstream circuit response times), but the potential is always there whenever the underlying hazard condition exists, which is why hazard analysis (identifying the static/dynamic hazard conditions in a design) is done at the logic level even before any specific delay values are known.

Glitches aren't unique to the reconvergent-fan-out hazard mechanism — any situation with multiple, nearly-simultaneous input changes feeding a circuit (not just a single transitioning variable) can also produce glitchy, multiply-transitioning outputs before the circuit settles, which is part of why asynchronous circuits (with no clock to define a single settling point) are generally much harder to design correctly than synchronous ones.

When glitches matter: synchronous sampling vs. asynchronous/edge-sensitive use

In a well-designed fully synchronous system, a glitchy combinational signal that only feeds the data input of a flip-flop is usually harmless in practice: as long as the combinational logic has fully settled to its correct final value well before the flip-flop's setup-time window begins (i.e., the glitch resolves early enough within the clock period), the flip-flop only captures the correct, settled value at the clock edge and never 'sees' the earlier transient glitch at all. This is the standard justification for why combinational hazards, while worth understanding, are often not treated as showstopping bugs in purely synchronous designs — timing closure (ensuring the logic settles before the setup window) effectively neutralizes them.

Glitches become a genuine functional bug specifically when a glitchy signal drives something that reacts to *any* transition, not just a value sampled at one defined instant — an asynchronous clock, set, or reset input on a flip-flop, or (the classic textbook example) the clock input of a ripple/asynchronous counter, where each flip-flop's output directly clocks the next stage. In a ripple counter, the count value briefly passes through intermediate, incorrect binary patterns as the carry 'ripples' through each flip-flop's individual (non-simultaneous) propagation delay — not technically a hazard from reconvergent logic, but the same class of transient-incorrect-value problem, and the reason ripple counters are avoided in applications needing a glitch-free, instantaneously-valid count (synchronous counters, where every flip-flop is clocked simultaneously by the same clock edge, avoid this entirely).

A critical real-world case: clock gating

Clock gating — disabling a clock to a block of logic when that block isn't needed, to save dynamic power — is implemented at its simplest by ANDing the clock with an enable signal (gated_clk = clk AND enable). If the enable signal itself is glitchy or changes asynchronously relative to the clock, a glitch on the AND gate's output can look exactly like an unintended extra clock edge to every flip-flop downstream, potentially corrupting state by clocking in data at the wrong instant. Because of this, real clock-gating implementations never gate the clock with a raw combinational AND; they use a dedicated 'integrated clock gating' (ICG) cell built around a level-sensitive latch that only allows the enable signal to change the gated clock's behavior while the clock itself is already LOW (safely away from any active edge), guaranteeing the gated clock output is glitch-free by construction regardless of when the enable signal itself transitions.

Glitch-prone vs glitch-safe clock gating

UNSAFE:  gated_clk = clk & enable;   // raw AND — enable glitches propagate directly

SAFE (integrated clock gating, conceptual):
  latch_en = latch(enable, transparent while clk == 0)
  gated_clk = clk & latch_en;
  // enable can only affect gated_clk's behavior while clk is already LOW,
  // so no glitch on 'enable' can ever create a spurious extra clock edge

Code Examples

Between the stable states 011 and 100, the ripple counter's output briefly passes through 010 and 000 — neither of which is the correct count at any real moment in time — purely because each flip-flop stage only responds after the previous stage's propagation delay, not simultaneously. Any downstream logic sampling the count asynchronously during this ripple window would read a wrong, transient value; a synchronous counter (all bits clocked by the same edge at once) never exhibits this.

A ripple counter's count briefly passes through wrong intermediate values during every multi-bit transition — this is a real, observable glitch sequence, not just a theoretical hazard.

3-bit ripple (asynchronous) counter counting from 3 (011) to 4 (100):

Ideal instantaneous transition: 011 → 100

Actual ripple sequence (each bit toggles only after the previous
bit's own propagation delay has elapsed):
  011 → 010 → 000 → 100
  (bit0 toggles first: 011→010, then bit1 ripples: 010→000,
   then bit2 ripples: 000→100)

Important Rules

A glitch is the physically observed transient pulse produced by an underlying hazard condition (or by multiple simultaneous input changes).

A glitch on a signal feeding only a synchronous flip-flop's data input is usually harmless if the logic settles well before the setup window.

A glitch on a signal feeding an asynchronous clock/set/reset input, or a ripple-counter clock chain, can directly corrupt circuit state.

Real clock-gating designs use a latch-based integrated clock gating (ICG) cell, never a raw combinational AND, specifically to guarantee a glitch-free gated clock.

Power-saving clock gating in real chips

Nearly every modern low-power ASIC and FPGA design uses clock gating extensively to cut dynamic power (recall Pdynamic ≈ αCV²f from the CMOS lesson — a clock that isn't toggling contributes no dynamic power to that block) — but every synthesis tool automatically infers or requires dedicated, glitch-safe integrated clock gating cells rather than allowing a plain AND gate on a clock net, precisely because of the glitch-corrupting-state risk described above.

Implementing clock gating as a plain gated_clk = clk & enable AND gate, assuming any combinational glitch on enable is inconsequential.

Use a latch-based integrated clock gating cell that only lets enable take effect while the clock is already LOW, guaranteeing the gated output is glitch-free regardless of enable's own timing.

A raw AND gate passes through any glitch on 'enable' directly onto the gated clock line whenever the real clock happens to be HIGH at that moment, and downstream flip-flops cannot distinguish that glitch from a legitimate clock edge — this is a well-known, serious real-silicon bug class, which is exactly why dedicated ICG cells exist as a standard library element rather than engineers hand-rolling a simple AND gate.

Why is a glitch on an asynchronous reset input far more dangerous than the same glitch on a synchronous data input? A. Asynchronous reset inputs are electrically more fragile B. An asynchronous reset input reacts to any transition the instant it occurs, with no setup/hold window to filter out transient activity, so a glitch can trigger an unintended reset immediately — whereas a synchronous data input is only sampled at a specific clock edge, and a glitch that resolves before that edge is never captured C. Glitches never occur on data inputs, only on reset inputs D. Asynchronous resets are always disabled by default, so glitches there don't matter

B. An asynchronous reset input reacts to any transition the instant it occurs, with no setup/hold window to filter out transient activity, so a glitch can trigger an unintended reset immediately — whereas a synchronous data input is only sampled at a specific clock edge, and a glitch that resolves before that edge is never captured — Asynchronous inputs (like an async reset or an async clock) act immediately on any transition — there's no clocked sampling window to filter out a brief incorrect pulse. A synchronous data input, in contrast, is only 'read' at the active clock edge, so a glitch that has already resolved by then simply never gets captured, which is the core reason glitches on synchronous data paths are usually benign while glitches on asynchronous control inputs are genuinely dangerous.

Why do real chip designs use a latch-based integrated clock gating (ICG) cell instead of a simple gated_clk = clk & enable AND gate? A. AND gates are more expensive in silicon area than latches B. The latch ensures 'enable' can only affect the gated clock while the real clock is already LOW, so any glitch on 'enable' cannot create a spurious extra edge on the gated clock — a plain AND gate offers no such protection and would pass enable's glitches straight through whenever the clock happens to be HIGH C. Latches run at a lower voltage than AND gates, saving power D. ICG cells are required by law in all digital designs

B. The latch ensures 'enable' can only affect the gated clock while the real clock is already LOW, so any glitch on 'enable' cannot create a spurious extra edge on the gated clock — a plain AND gate offers no such protection and would pass enable's glitches straight through whenever the clock happens to be HIGH — The latch in an ICG cell is transparent (lets 'enable' pass through) only while the clock is LOW — safely away from any active clock edge — and holds its value (opaque) while the clock is HIGH, so any glitch on 'enable' that happens to occur while the clock is HIGH simply cannot reach and corrupt the gated clock output. A plain AND gate has no such timing protection and directly ANDs whatever 'enable' is doing, glitches included, with the real clock at all times.

Explain why a glitch on a purely combinational signal that feeds only the D input of a synchronous flip-flop (never its clock, set, or reset) is generally not a functional bug, using the concept of setup time.

A synchronous flip-flop only captures whatever value is present on its D input during the brief setup/hold window immediately surrounding the active clock edge — it has no mechanism to 'notice' or react to anything that happened on D earlier in the cycle. As long as the combinational logic driving D has fully settled to its correct, final value before that setup window begins (which is exactly what static timing analysis verifies), any earlier transient glitch is simply irrelevant — it happened and resolved before the flip-flop ever looked at the signal, so it can never be captured or propagated.

Think about what the flip-flop actually samples and when, relative to when the glitch occurs within the clock period.