Root-Causing a Hold Violation

Chapter 8 · Section 8.3 · Timing-Violation Debug

Project thread — a hold race between the counter's flops (or the FSM's), or clock skew across them, is the classic hold problem. This lesson traces one; 8.4 then separates real violations from artifacts.

1. Why Should I Learn This?

Hold is the "does data hold long enough?" question — and it behaves unlike setup in a way that trips people up.

• Hold = data too soon after the edge → path-race / skew, not a period problem.
• Slowing the clock does nothing for hold — a common wasted fix.
• Hold is worst at the fast / min-delay corner (3.4/4.4).

Getting hold right (opposite of setup, 8.2) completes the two core violation types.

2. Real Silicon Story — the hold bug that slowing the clock couldn't fix

A hold violation was "fixed" by slowing the clock — and it stayed. Cycle after cycle, the same violation.

Hold is period-independent. The data was reaching the capture flop too soon after the edge because of a short path (and some clock skew), and changing the period doesn't change either. The real fix was to add delay to the short path (buffers) and address the skew. Slowing the clock only wasted a build.

Lesson: slowing the clock never fixes hold. Hold is a path-race/skew problem — add delay to the short path or fix the skew.

3. Concept — what a hold violation is, and its causes

Definition:

• Hold = data must stay stable after the clock edge; a violation is data changing inside the hold window → the flop captured the new value too soon (3.2).

Why period-independent:

• Hold compares launch-to-capture arrival against the same edge — the clock period cancels out. Slowing the clock does not help.

Root causes (trace to decide):

• Too-short combinational path (real): data races to the capture flop with too little delay.
• Clock skew (real): the capture clock arrives later than the launch clock, shrinking the effective hold margin.
• Wrong corner (artifact/lens): hold is worst at the fast / MIN corner — a slow-corner run hides it (3.4/4.4).
• Edge-aligned stimulus (artifact): the testbench changed the input at/just after the edge → self-inflicted hold miss (5.3).

The fix:

• Add delay to the short path (hold-buffer insertion) or fix the clock skew — not the period.
• Confirm real hold with STA at the fast corner.

Scope: hold is judged exhaustively by STA at the fast corner — the GLS firing is a stimulus-specific flag (2.5/0.3).

4. Mental Model — the baton passed before the runner let go

Hold is a relay race where the launch flop passes a baton (data) to the capture flop, timed by the clock.

• The capture runner must hold the old baton until the whistle (edge) — then take the new one.
• Hold violation = the new baton arrived too fast, snatched before the old handoff completed.
• Why? The handoff path was too short (data raced over) or the whistle reached the capture runner late (clock skew).
• Slowing the whole race (clock period) doesn't help — both runners slow together; the relative timing (short path, skew) is unchanged.
• Fix: make the handoff path longer (add delay) or align the whistles (fix skew).

It's a relative-timing problem, immune to the overall pace.

5. Working Example — tracing a hold race

The hold message and the short path/skew it points to:

# Hold violation — REPRESENTATIVE (8.1)
"$hold at u_cnt/q_reg[3] (D): D changed 0.01ns after posedge CK (limit 0.02ns)"
# Endpoint = q_reg[3].D. Data changed too SOON after the edge. Trace the SHORT path / skew:

// A too-short path racing to the capture flop — REPRESENTATIVE
// launch flop -> (almost no logic) -> capture flop's D  -> data arrives too fast after the edge
DFFRX1 u_launch (.D(x), .CK(clk),      .Q(a));
DFFRX1 u_capture(.D(a), .CK(clk_skew), .Q(q));   // short path a->D + clk_skew late -> HOLD race
// Fix: add delay to the a->D path (hold buffers) or fix clk_skew. NOT the period.

# Hold checklist for THIS firing (tool-neutral):
#   period:  slowing the clock does NOTHING (hold is period-independent)
#   corner:  fast/MIN? (hold worst here, 3.4/4.4)  a slow-corner run HIDES it
#   path:    too-short combinational path? -> add delay (hold buffers)
#   skew:    capture clock later than launch? -> fix clock skew
#   stimulus: input changed at/just after the edge? -> TB-induced (5.3)
#   real?    STA at the FAST corner confirms a genuine hold/skew issue

Practical context (representative, tool-neutral):

# Root-cause a hold violation (tool-neutral):
#   1) endpoint from the message (8.1)
#   2) DON'T slow the clock — hold is period-independent
#   3) trace the SHORT path (too little delay) and check CLOCK SKEW (capture late)
#   4) corner: hold worst at FAST/MIN (3.4/4.4) — slow-corner run hides it
#   5) fix: add delay (hold buffers) / fix skew; CONFIRM with STA at the fast corner

A hold violation from a short path, as a real waveform:

6. Debugging Session — a hold violation "fixed" by slowing the clock

7. Common Mistakes

• Slowing the clock to fix hold. Hold is period-independent — it won't help.
• Debugging hold at the slow corner. Hold is worst at the fast/MIN corner (3.4/4.4).
• Ignoring clock skew. A late capture clock causes hold violations.
• Missing edge-aligned stimulus. A TB-induced hold miss looks real (5.3).
• Treating the GLS firing as the proof. STA at the fast corner signs off (0.3).

8. Industry Best Practices

• Fix hold by adding delay / correcting skew — never by clock period.
• Use the fast/MIN corner for hold (right lens, 3.4/4.4).
• Check clock skew between launch and capture flops.
• Rule out edge-aligned stimulus (5.3) before blaming the design.
• Confirm real hold with STA (fast corner); don't waive a real race.

Senior Engineer Thinking

• Beginner: "Hold violation — I'll slow the clock like I do for setup."
• Senior: "Hold is period-independent — the clock won't touch it. Is the path too short, or is the capture clock skewed late? I add delay or fix skew, at the fast corner, and confirm with STA."

The senior knows hold is a relative-timing race and fixes path/skew, not the period.

Silicon Impact

A real hold violation is one of the most dangerous timing bugs: unlike setup, it cannot be fixed by slowing the clock, so a design with a hold race fails at every frequency — and it manifests at the fast corner (cold, high-voltage, fast process) as a capture of the wrong data, an intermittent, hard-to-reproduce silicon failure (0.3). Because slowing the clock is the reflex, hold bugs are often mis-fixed and shipped. Root-causing correctly — recognising period-independence, checking short paths and clock skew, using the fast corner, confirming with STA — is what leads to the right fix (hold buffers, skew correction) and keeps a truly period-immune failure off the tape-out.

Engineering Checklist

• Confirmed the check is hold (not setup, 8.1) — period-independent.
• Did not slow the clock to fix it.
• Traced the short path and checked clock skew (capture late).
• Used the fast/MIN corner (hold's worst case, 3.4/4.4).
• Fixed with added delay / skew correction, confirmed by STA (fast corner).

Try Yourself

1. Build a launch→capture flop pair with a very short path (and a slightly late capture clock); run at the fast corner — a $hold violation fires.
2. Observe: D changes too soon after the edge; the data raced through.
3. Change: slow the clock — the violation stays (period-independent).
4. Expect: now add delay to the path (or fix the skew) — the violation clears. Prove that path/skew, not the period, is the fix; confirm with STA at the fast corner.

Any free Verilog simulator with SDF timing checks reproduces a hold violation. No paid tool required.

Interview Perspective

• Weak: "A hold violation — slow the clock to fix it."
• Good: "Hold is data changing too soon after the edge; it's period-independent, so you add delay to the short path or fix clock skew."
• Senior: "Hold is a relative-timing race — the period cancels, so slowing the clock does nothing. I check the short path and clock skew (capture clock late), use the fast/MIN corner, and fix with hold buffers or skew correction, confirmed by STA at the fast corner. The GLS firing is a stimulus-specific flag."

9. Interview / Review Questions

10. Key Takeaways

• A hold violation is the opposite of setup: data changed too soon after the clock edge, inside the hold window — the flop captured the new value too early (3.2).
• Hold is period-independent — slowing the clock never fixes it; it is a path-race / clock-skew problem.
• Causes: a too-short combinational path (data races through) or clock skew (capture clock late), worst at the fast / min-delay corner (3.4/4.4).
• Fix by adding delay to the short path (hold buffers) or correcting the skew — not the clock period; a fast-corner run and STA at the fast corner confirm a real hold race.
• The GLS firing is a stimulus-specific flag — don't waive a real hold race; STA is the exhaustive signoff (2.5/0.3). Next: 8.4 — real violations vs simulation artifacts.

Quick Revision

Hold violation = data too SOON after the edge (inside the hold window). Period-independent — slowing the clock NEVER helps. Causes: too-short path or clock skew (capture late), worst at the FAST/MIN corner (3.4/4.4). Fix: add delay (hold buffers) / correct skew — not the period. Confirm real with STA (fast corner); the GLS firing is a flag. Next: 8.4 — real violations vs artifacts.