Pulse Rejection & Glitch Behaviour

Chapter 3 · Section 3.5 · Timing Basics for GLS

Project thread — the counter's increment logic (2.6) can glitch as carries ripple. This lesson shows when those glitches are swallowed and when they reach a flop; it closes Chapter 3, and Chapter 4 (SDF) makes the delays — and thus the pulse widths — real.

1. Why Should I Learn This?

Combinational logic glitches. Whether a glitch matters depends on delay-driven pulse rejection.

• Inertial delay (the default) swallows pulses narrower than the gate delay.
• A glitch that propagates to a flop near the clock edge can cause X or a wrong capture.
• Pulse width scales with real delays — so glitch behaviour can change between pre- and post-layout, and between corners.

This closes the timing-basics chapter and sets up why SDF-annotated (real-delay) runs matter (Chapter 4).

2. Real Silicon Story — the glitch the zero-delay run never showed

A zero-delay gate run of the counter's increment logic looked clean — outputs settled instantly, no glitches.

With real delays annotated, unequal path lengths in the carry chain produced a brief glitch on a decode output. It was wide enough to survive the receiving gate's inertial delay, propagated, and landed close to a capture edge — driving a flop to X.

Lesson: glitches are a delay phenomenon. A zero-delay run cannot show them; a real-delay run can. Whether a glitch survives depends on its width versus the gate delay (inertial rejection).

3. Concept — inertial vs transport, and pulse rejection

Two delay semantics:

• Inertial delay (Verilog default): a pulse narrower than the delay is rejected. Models a gate too slow to pass a spike shorter than its own switching time.
• Transport delay: passes every pulse, just shifted in time. Used to model ideal wires/paths where narrow pulses do travel.

Pulse rejection controls:

• The specify PATHPULSE$ sets the reject limit (pulses below → swallowed) and error limit (pulses between → pass as X, flagging uncertainty).
• Below reject → gone; between reject and error → X; above error → propagates as a clean pulse.

Glitches:

• A glitch is a brief, unintended transition from unequal path delays converging on a gate.
• Whether it survives depends on its width vs the downstream cell delay (inertial).
• A surviving glitch near a clock edge can fire a timing check → X (notifier), or cause a wrong capture.

Scope: inertial rejection is a modelling choice; pulse widths scale with real delays (SDF, corner). A clean run does not prove timing (0.3).

4. Mental Model — a heavy door that ignores quick taps

An inertial gate is like a heavy door: a quick tap doesn't move it, but a sustained push does.

• A glitch is a quick tap — if it's shorter than the door's inertia (the gate delay), nothing happens (rejected).
• A wider pulse is a sustained push — the door swings (propagates).
• Transport delay is a weightless door — every tap passes.

Real gates are heavy doors (inertial). And the "tap length" that matters is measured against the real delay — so it changes with SDF and corner.

5. Working Example — PATHPULSE, and a glitch-rejection waveform

A representative specify with pulse limits:

// Cell with inertial delay + PATHPULSE limits — REPRESENTATIVE, tool-neutral
module AND2X1 (Y, A, B);
  output Y; input A, B;
  and (Y, A, B);
  specify
    (A => Y) = 0;                    // arc (placeholder -> SDF, 3.1)
    (B => Y) = 0;
    // reject pulses below the reject limit; pass as X between reject and error limits
    (PATHPULSE$ = (0, 0));           // representative: real limits scale with the SDF delay
  endspecify
endmodule

Practical context (representative, tool-neutral):

# Glitch visibility depends on the run mode:
netlist + cell models (NO SDF)   -> zero-delay -> no glitches visible
netlist + cell models + SDF      -> real delays -> glitches appear, inertial rejection active
# Post-layout SDF (3.3) + slow/fast corner (3.4) change glitch WIDTHS -> what survives changes.

Narrow glitch rejected, wider glitch propagated — a real waveform:

6. Debugging Session — a glitch masked by zero-delay (and by inertial rejection)

7. Common Mistakes

• Debugging glitches in a zero-delay run. Glitches need unequal real delays — annotate SDF first.
• Assuming inertial rejection makes glitches safe. A wide-enough glitch propagates — and widths change with corner/layout.
• Confusing inertial and transport. Inertial (default) rejects narrow pulses; transport passes all.
• Ignoring corner/layout effects on pulse width. What is rejected at one corner may survive at another (3.3/3.4).
• Treating a glitch-free run as a timing proof. STA (all corners) is signoff (0.3).

8. Industry Best Practices

• Investigate glitches with real (SDF) delays — and across relevant corners.
• Fix hazards at the source (balance paths, register signals) — don't lean on inertial rejection.
• Know your delay mode: inertial by default; use transport only deliberately.
• Remember pulse width is delay-relative — post-layout and corner shifts change what survives.
• STA closes timing; GLS shows the functional effect of a surviving glitch.

Senior Engineer Thinking

• Beginner: "No glitches in the gate run, so the logic is clean."
• Senior: "Was that zero-delay? Glitches need unequal real delays — I need an SDF run, at the corners where pulse widths are widest. And inertial rejection only hides glitches narrower than the gate delay."

The senior debugs glitches with real delays, mindful that width vs delay (and corner/layout) decides survival.

Silicon Impact

A glitch captured by a flop is a real functional failure — a spurious count, a false trigger, a corrupted state. Because glitch survival depends on pulse width vs delay, it is corner- and layout-dependent: a glitch harmlessly rejected in one condition can propagate and be captured in another, producing intermittent, hard-to-reproduce silicon bugs. Zero-delay and single-corner runs can miss these entirely. Real-delay GLS across relevant corners reveals the functional effect; STA proves the timing margins. Relying on inertial rejection to "clean up" glitches is trusting a modelling default to hide a hazard that silicon may not hide.

Engineering Checklist

• Investigated glitches in a real-delay (SDF) run, not zero-delay.
• Checked the corners/layout where pulse widths are widest (3.3/3.4).
• Fixed genuine hazards at the source, not via inertial rejection.
• Confirmed the delay mode (inertial default vs deliberate transport).
• Relied on STA (all corners) for timing closure.

Try Yourself

1. Build the representative AND2X1 with a small real delay and drive its inputs so unequal arrivals create a narrow glitch on Y.
2. Observe: the narrow glitch is rejected (inertial) — Y stays flat.
3. Change: widen the glitch (larger input skew) so it exceeds the gate delay, and route Y to a flop's D near a clock edge.
4. Expect: the wider glitch propagates and can drive Q to X. Prove that survival depends on width vs delay.

Any free Verilog simulator models inertial delay and glitch rejection. Real PATHPULSE limits come from the .lib/SDF (vendor/PDK), but the mechanism is identical. No paid tool required.

Interview Perspective

• Weak: "Gates just delay signals."
• Good: "Verilog's default inertial delay rejects pulses narrower than the gate delay; transport delay passes all pulses."
• Senior: "Glitches come from unequal real path delays, so zero-delay runs can't show them. Inertial rejection swallows glitches narrower than the gate delay, but a wider one propagates and can drive a flop to X near a clock edge. Pulse width is delay-relative, so survival changes with corner and layout — and a clean run isn't a timing proof; STA is."

9. Interview / Review Questions

10. Key Takeaways

• Cell delay also governs pulse survival: inertial delay (Verilog default) rejects pulses narrower than the gate delay; transport delay passes all pulses.
• Glitches come from unequal path delays — so a zero-delay run cannot show them; they appear only with real (SDF) delays.
• Whether a glitch survives depends on its width vs the downstream cell delay (tunable via specify PATHPULSE); a surviving glitch near a clock edge can drive a flop to X or cause a wrong capture.
• Pulse width is delay-relative, so glitch behaviour changes with corner (3.4) and post-layout net delay (3.3) — check the relevant conditions.
• Inertial rejection is a modelling choice, and a glitch-free run does not prove timing — STA (all corners) is signoff (0.3). This closes Chapter 3; next, Chapter 4 makes these delays real via SDF annotation.

Quick Revision

Inertial delay (default) rejects pulses narrower than the gate delay; transport passes all. Glitches need unequal real delays — invisible in zero-delay runs. Survival = width vs cell delay (PATHPULSE); a surviving glitch near a clock edge → Q = X/wrong capture. Widths scale with corner + layout, so check relevant conditions. Inertial rejection is a modelling choice; a clean run ≠ timing proof (STA is). Chapter 3 complete; next: Chapter 4 — SDF annotation.