Reading Setup/Hold Violation Messages

Chapter 8 · Section 8.1 · Timing-Violation Debug

Project thread — the counter and FSM carry $setup/$hold checks (2.5/3.2); this chapter root-causes their violations. 8.6 adds a clock-gated block, the next design element toward the mini-SoC.

1. Why Should I Learn This?

You can't debug a violation you can't read. The message is the starting point.

• It names the check (setup vs hold), instance/pin, clock edge, and margin miss.
• Reading it tells you which flop and path to examine.
• Misreading it (setup for hold, wrong pin) sends you down the wrong path.

This opens the chapter (8.2 setup, 8.3 hold, 8.4 real-vs-artifact, 8.5 notifiers, 8.6 clock gating).

2. Real Silicon Story — the hold bug debugged as a setup problem

An engineer saw a violation and assumed setup — and spent a day trying to slow the clock, which didn't help.

The message actually said $hold. A hold violation is data changing too soon after the edge — slowing the clock does nothing for it (hold is a MIN/fast-corner, path-race issue, 8.3). Reading the message's check field correctly would have pointed at a hold fix (path/skew), not a clock-period change. A day lost to not reading which check fired.

Lesson: the message tells you setup vs hold — and they have opposite fixes. Read the check field first; don't assume.

3. Concept — the five parts of a violation message

A representative $setup/$hold message decodes into:

• (1) Check — $setup, $hold, $recovery, $removal, $width. Which rule broke.
• (2) Instance + pin — the flop (u_cnt/q_reg[2]) and the data pin (D). Where.
• (3) Reference (clock) edge — posedge CK. Measured against which edge.
• (4) Margin miss — how far inside the window (e.g. 0.03ns before CK). How bad.
• (5) Notifier / effect — the notifier toggled → output X (2.5). What it did.

Reading it:

• Setup = data changed too close before the edge (arrived late).
• Hold = data changed too soon after the edge.
• The instance/pin is your endpoint; trace the data path back to the startpoint (8.2/8.3).
• The margin hints at severity (tiny miss vs large).

Framing (accuracy):

• The message reports one dynamic firing under this stimulus — a flag to investigate, not a timing proof.
• Format varies by tool — the five parts are universal even if the layout differs.
• STA is the exhaustive check (0.3); GLS messages are stimulus-limited (2.5).

4. Mental Model — a violation message is a police report

Read a violation message like a police report of an incident.

• What happened (the check: setup vs hold) — the type of incident.
• Where (instance + data pin) — the location (your endpoint).
• When (clock edge) — the timestamp it's measured against.
• How bad (margin) — the severity.
• Consequence (notifier → X) — the damage done.

You wouldn't investigate before reading the report; don't debug a violation before decoding its five fields.

5. Working Example — decoding a representative message

A representative violation message, annotated:

# Setup violation message — REPRESENTATIVE (format varies by tool)
"$setup violation at u_cnt/q_reg[2] (D): D changed 0.03ns before posedge CK (limit 0.05ns)"
#   |          |                 |     |                        |               |
#   (1)check   (2)instance       pin   (4)margin miss           (3)clock edge   limit
#   -> notifier toggled -> u_cnt/q_reg[2].Q = X   (5) effect (2.5)
# Read: SETUP problem at q_reg[2]'s D pin, data late by 0.02ns vs the posedge CK; output went X.

# Hold violation message — REPRESENTATIVE (note: opposite fix from setup!)
"$hold violation at u_cnt/q_reg[3] (D): D changed 0.01ns after posedge CK (limit 0.02ns)"
# Read: HOLD problem at q_reg[3] — data changed too SOON after the edge. Slowing the clock won't help.

Practical context (representative, tool-neutral):

# Decode any violation message (tool-neutral):
#   check?    $setup (arrived late) vs $hold (changed too soon) -> OPPOSITE fixes (8.2/8.3)
#   where?    instance + data pin = the ENDPOINT; trace the data path back to the startpoint
#   edge?     which clock edge it was measured against
#   margin?   how far inside the window (severity)
#   effect?   notifier -> output X (2.5) -> may propagate (Ch6)
# Remember: one firing under THIS stimulus (dynamic); STA is the exhaustive signoff.

A setup violation firing, as a real waveform:

6. Debugging Session — a message misread as setup (it was hold)

7. Common Mistakes

• Assuming setup without reading the check field. Hold is the opposite problem/fix.
• Ignoring the instance/pin. It's your endpoint to trace back from.
• Overlooking the margin. It hints at severity (tiny vs large miss).
• Treating the message as a proof. It's one dynamic firing under this stimulus (2.5).
• Assuming a fixed format. Layout varies by tool; the five parts are universal.

8. Industry Best Practices

• Decode all five parts (check, instance/pin, edge, margin, effect) before debugging.
• Read the check field first — setup vs hold set the direction.
• Use the instance/pin as the endpoint to trace the path (8.2/8.3).
• Note the margin for severity/triage.
• Correlate with STA — the message flags; STA proves (0.3).

Senior Engineer Thinking

• Beginner: "There's a timing violation — let me slow the clock."
• Senior: "Which check fired — setup or hold? A hold violation won't care about clock period. Let me read the message: check, pin, edge, margin, effect — then pick a direction."

The senior decodes the message's five parts (check first) before choosing a fix.

Silicon Impact

Reading violation messages correctly is what makes timing debug efficient and accurate. Misread the check (setup vs hold) and you apply the wrong remedy — wasting time and possibly masking the real issue. Miss the instance/pin and you trace the wrong path. The message is the entry point to catching real timing bugs (long paths, hold races, skew) before tape-out — and to dismissing artifacts (8.4) without churn. A team fluent in decoding these five parts turns a daunting violation log into a prioritized, correctly-directed bug list; a team that guesses burns days on wrong fixes. Precision starts at the message.

Engineering Checklist

• Decoded the check (setup vs hold — opposite fixes).
• Identified the instance + data pin (the endpoint).
• Noted the clock edge it's measured against.
• Read the margin miss (severity).
• Remembered it's one dynamic firing (flag, not proof) — correlate with STA.

Try Yourself

1. Run a design that produces a $setup violation; read the message's five parts.
2. Observe: identify the check, instance/pin, clock edge, margin, and the X effect.
3. Change: create a $hold violation (data changing just after the edge) and read its message.
4. Expect: the check field now says $hold — confirming that reading it (not assuming) is what distinguishes the two opposite problems.

Any free Verilog simulator with SDF timing checks emits these messages. No paid tool required.

Interview Perspective

• Weak: "A timing violation just means the timing is wrong somewhere."
• Good: "The message names the check (setup/hold), the instance and pin, the clock edge, and how far inside the window."
• Senior: "I decode five parts: check (setup vs hold — opposite fixes), instance/pin (my endpoint), clock edge, margin (severity), and effect (notifier → X). Reading the check field first keeps me from applying a setup fix to a hold problem. And it's one dynamic firing under my stimulus — a flag; STA is the exhaustive signoff."

9. Interview / Review Questions

10. Key Takeaways

• A timing-violation message is a structured report with five parts: the check ($setup/$hold/…), the instance + data pin, the clock edge, the margin miss, and the effect (notifier → X, 2.5).
• Read the check field first — setup (data arrived too late) and hold (data changed too soon after the edge) are opposite problems with opposite fixes.
• The instance/pin is your endpoint — trace the data path back to root-cause (8.2/8.3); the margin hints at severity.
• Message format varies by tool, but the five parts are universal.
• A message reports one dynamic firing under this stimulus — a flag to investigate, not a timing proof; STA is the exhaustive signoff (2.5/0.3). Next: 8.2 — root-causing a setup violation.

Quick Revision

Decode the violation message (5 parts): check ($setup vs $hold — OPPOSITE fixes), instance + data pin (endpoint), clock edge, margin miss (severity), effect (notifier → X). Setup = data late (more time helps); hold = data too soon after edge (path/skew — slowing clock won't help). Read the check FIRST. One dynamic firing (flag), not proof; STA signs off. Next: 8.2 — root-causing a setup violation.