What does a rigorous 'timing is clean' signoff declaration actually require, beyond a report showing zero violations?

Short Answer

A zero-violation summary only proves that whatever paths, corners, and checks the tool actually looked at came back clean — it says nothing about paths that were never constrained, corners that were never run, or exceptions that silently swallowed real risk. A rigorous signoff declaration means working through a full checklist — every mode-corner scenario, OCV/derating settings, crosstalk analysis, exception review, and unconstrained-endpoint checks — and confirming each one was genuinely covered, not just that the final number happened to read zero.

Technical Explanation

• check_timing (PT) has to be reviewed, not just run, before trusting any downstream report: it surfaces unconstrained endpoints, clocks with no valid source, and other structural SDC problems that would otherwise let entire portions of the design go unchecked while still reporting zero violations for those paths, since a path that was never analyzed cannot report a violation.
• Every MCMM scenario in the intended signoff session — every mode at every corner — has to actually be part of the session that produced the clean report; a clean report from a partial session (see command focus narrowed for convenience and never restored) is not evidence the full design is clean.
• OCV or AOCV/POCV derating settings have to be confirmed as actually configured to the intended methodology, not left at a permissive or default setting that understates real variation risk — report_timing_derate (PT) is how this gets checked, not assumed.
• Crosstalk analysis has to be confirmed as actually enabled and using real, tapeout-representative parasitics (from SPEF) rather than an approximate delay model appropriate only for early-stage estimation — a clean timing report generated without SI analysis enabled is not evidence the design is SI-clean.
• Timing exceptions [SDC: set_false_path, set_multicycle_path, set_case_analysis] need their own review pass, since an overly broad or mistakenly-scoped exception can make a real violation disappear from the report without actually fixing anything physical — report_exceptions (PT) is the way to audit what exceptions are actually in effect and where.
• Design rule checks (DRC) — max transition, max capacitance, max fanout — are a separate signoff dimension from setup/hold timing entirely, and a design can have zero setup/hold violations while still carrying DRC violations that indicate real electrical risk; these need their own explicit check, typically via report_constraint (PT).
• What breaks: declaring signoff clean based only on the headline zero-violation number, without working through this checklist, means any one of these unchecked dimensions can hide a real problem that only surfaces after tapeout, when the fix is far more expensive than it would have been during signoff review.

Follow-up Question & Model Response

"A colleague says the design is clean because report_global_timing shows zero violations across all scenarios. What two or three specific commands would you ask them to also show you before agreeing signoff is complete?"

Candidate Model Response: I would ask to see check_timing's output confirmed clean of unconstrained endpoints and invalid clocks, since that establishes the zero-violation number actually covers the whole design rather than silently excluding unanalyzed paths. I would ask for report_exceptions to confirm the false-path and multicycle exceptions in effect are still the ones intended, given the current netlist, rather than stale exceptions from an earlier design revision. And I would ask for report_constraint covering DRC checks (max transition, max capacitance, max fanout) specifically, since those are a distinct signoff dimension a clean setup/hold summary says nothing about.