Answer with mechanism, pitfall, regression check, and release judgment. At 10+ years, a correct definition is not enough.
Start with the failing metric and analysis context.
Explain the physical or constraint mechanism.
Name the cheapest evidence-gathering experiment.
Choose a bounded fix and state what it can regress.
Close with signoff, waiver, or escalation criteria.
[INT][PD]
Q: How do you prove an SDC is implementation-safe?
A:
Show zero unconstrained endpoints, validated generated clocks, audited exceptions, and version alignment across synthesis, PnR, and signoff.
FOLLOW-UP TRAP: Saying 'tool accepted SDC' without evidence.[INT][PD]
Q: When WNS improves but TNS worsens, what does it indicate?
A:
Likely over-focusing on a few worst paths while violating-path population grows; re-balance by group-level strategy.
FOLLOW-UP TRAP: Declaring closure based on WNS alone.[INT][PD]
Q: Why can setup closure regress after CTS even with same netlist?
A:
Clock insertion delay, skew distribution, and propagated clocks change path equations and corner sensitivities.
FOLLOW-UP TRAP: Assuming only data path matters.[INT][PD]
Q: What is your first action on a sudden unconstrained-path spike?
A:
Pin the exact SDC revision and diff clock/group/IO constraints against last known-good run.
FOLLOW-UP TRAP: Starting buffer ECOs immediately.[INT][PD]
Q: How do you prioritize path groups for late-stage closure?
A:
Rank by tapeout risk: external interfaces, safety-critical domains, violation density, and trend stagnation.
FOLLOW-UP TRAP: Sorting only by absolute worst slack.[INT][PD]
Q: What makes a false-path exception reviewable?
A:
Protocol or CDC proof, endpoint scope, owner approval, and a regression showing intended effect only.
FOLLOW-UP TRAP: One-line waiver without design intent.[INT][PD]
Q: How do you separate net-delay and cell-delay dominated setup failures?
A:
Use report decomposition; if net dominates, fix placement/route; if cell dominates, size/VT/logic architecture.
FOLLOW-UP TRAP: Applying one generic fix class everywhere.[INT][PD]
Q: When should useful skew be avoided?
A:
When neighboring hold margins are already thin or skew map is unstable across modes.
FOLLOW-UP TRAP: Using skew as first-line fix for all setup misses.[INT][PD]
Q: Why is IO timing often the last hidden risk?
A:
Boundary budgets are external contracts; stale input/output delays can mask integration failures until top-level runs.
FOLLOW-UP TRAP: Treating block-internal closure as sufficient.[INT][PD]
Q: What validates MCMM completeness?
A:
A signed matrix covering required corners/modes with explicit pass/fail metrics and no missing scenarios.
FOLLOW-UP TRAP: Running a few corners ad hoc.[INT][PD]
Q: How do you keep ECO timing loops safe?
A:
Constrain blast radius, archive changed objects, run incremental extraction, and regress all required modes.
FOLLOW-UP TRAP: Bundling unrelated ECOs for convenience.[INT][PD]
Q: What checks do you run on SPEF before trust?
A:
Coverage/unmatched objects, RC corner labeling, and path-delay correlation against routed estimates.
FOLLOW-UP TRAP: Ignoring SPEF warnings if runtime is high.[INT][PD]
Q: How do SI effects alter timing closure strategy?
A:
Critical path ordering can change after crosstalk delta delay, so group prioritization and fixes must be recomputed.
FOLLOW-UP TRAP: Reusing non-SI critical path list.[INT][PD]
Q: What belongs on a timing signoff dashboard?
A:
Per-corner/mode WNS/TNS, violating endpoints, path-group ownership, trend, waivers, and regression freshness.
FOLLOW-UP TRAP: Showing only one global WNS number.[INT][PD]
Q: How do you evaluate waiver quality?
A:
Each waiver needs scope, rationale, owner, expiry, and evidence that silicon risk is acceptable.
FOLLOW-UP TRAP: Permanent waivers with no expiry.[INT][PD]
Q: Why can generated-clock mistakes be catastrophic?
A:
They distort launch/capture relationships, creating false positives or hidden escapes across entire domains.
FOLLOW-UP TRAP: Treating generated clocks as optional.[INT][PD]
Q: What does endpoint churn reveal?
A:
High churn means instability in closure; fixes are not converging and root cause remains active.
FOLLOW-UP TRAP: Ignoring churn because WNS is green.[INT][PD]
Q: How do you communicate closure readiness to management?
A:
Use risk-bucket status by path group with trend and remaining actions, not raw report dumps.
FOLLOW-UP TRAP: Forwarding tool logs without synthesis.[INT][PD]
Q: Which two artifacts must always be paired in signoff timing?
A:
Correct liberty corner set and matching extracted parasitics for that corner/mode context.
FOLLOW-UP TRAP: Mixing corners to save runtime.[INT][PD]
Q: What is a strong interview framing for timing debug?
A:
METRIC -> HYPOTHESIS -> EXPERIMENT -> FIX -> REGRESSION with explicit corner/mode naming.
FOLLOW-UP TRAP: Listing commands without mechanism.Use each question as a two-minute mock. The target answer is not an essay; it is a structured closure response with a metric, mechanism, risk, and follow-up check.
MECHANISM: what physical effect or tool step is involved
WHEN: where it appears in the flow
PITFALL: one wrong junior answer
CHECK: report/map/checklist item that proves the answer5/5: metric, mechanism, experiment, regression, and release decision named without prompting.
4/5: technically correct and names regression, but misses ownership or escalation criteria.
3/5: correct concept but no decision framework.
1/5: tool command or buzzword with no mechanism.
Q&A bank pages in this course should be read like real closure review material. For a 10+ year PD engineer, the bar is not remembering terminology; it is making a release-quality decision under ambiguity.
Names the failing metric, corner/mode, database tag, and analysis switches before proposing a fix.
Separates data, constraint, physical, tool, and methodology root causes instead of treating all failures as optimization problems.
Chooses experiments by information gain and reversibility, not by habit.
States regression blast radius across timing, route, power, PV, DFT, package, and tapeout manifest.
Turns recurring failures into methodology guardrails, dashboards, or checklist items.
STAFF / PRINCIPAL CLOSURE NOTE
Context:
stage: <pre-CTS | post-CTS | post-route | post-fill | signoff>
tag: <database / netlist / SDC / library stack>
failing metric: <exact report line>
affected scope: <block / hierarchy / path group / power domain / region>
Hypotheses:
H1: <most likely physical or constraint mechanism>
H2: <competing explanation>
H3: <methodology or input-data issue>
Decision:
next experiment: <cheap check that can falsify H1>
fix candidate: <minimal reversible change>
rollback trigger: <metric that says the fix is wrong>
regression set: <timing / route / power / PV / DFT / package>
escalation owner: <team or reviewer>Timing closure is a signoff matrix problem, not a single worst-path problem. Explain not only the preferred fix, but what margin or schedule you are spending to get it.
What must RTL, synthesis, CAD, STA, DFT, package, IP, or foundry agree to before this decision is final?
Which artifact becomes the source of truth after the decision: report, waiver, manifest, ECO script, or methodology deck?
What is the cost of being wrong: one rerun, ECO churn, mask risk, performance loss, or silicon escape?
"The current blocker is <metric> in <corner/mode/stage>. The leading cause is <mechanism>. I recommend <fix> because it is bounded and reversible. The regression surface is <domains>. If it fails, we escalate to <owner> with <evidence>."Always connect the concept back to a measurable signoff artifact.
A fix is not complete until you can name the regression checks.
Optimizing by habit instead of reading the current report.
Forgetting that a local fix can regress timing, routing, power, or PV elsewhere.