What does a rigorous 'timing is clean' signoff declaration actually require, beyond a report showing zero violations?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Technical Explanation
A trustworthy signoff requires working through a full checklist of analysis dimensions — corners, OCV/derating, crosstalk, MCMM scenarios, exceptions — and confirming each is genuinely covered, because any unchecked box represents a silent risk that a green, zero-violation report will not reveal on its own.
Timing-path Reasoning
A report showing zero violations only reflects what was actually analyzed; it says nothing about coverage gaps such as unanalyzed PVT/temperature-inversion corners, missing OCV/AOCV/POCV derating, uncredited CRPR pessimism, crosstalk contributors not properly windowed, RC corners not matched to net topology, or MCMM scenarios not fully enumerated. A green report with an unchecked box is not a trustworthy signoff — it just hasn't found the gap yet, meaning the absence of reported violations can reflect incomplete analysis rather than a genuinely clean design.
Command
report_analysis_coverageSwitch-by-switch
report_analysis_coverage summarizes setup/hold/no-change/min-period/recovery/
removal/min-pulse-width/clock-separation/clock-gating setup&hold/output setup&hold/
max-skew checks as Met/Violated/Untested. -status_details {untested} lists details for
untested checks specifically. -check_type {setup} restricts the summary to a given check
type. -exclude_untested removes untested checks from the summary. -sort_by slack
orders results by slack value. The recommended flow is link_design -> check_timing ->
report_analysis_coverage -> rest of analysis, ensuring coverage gaps are caught before
deeper analysis proceeds.Expected Result
A rigorous signoff run confirms, via report_analysis_coverage and the broader checklist, that every relevant check type is actually exercised (Met or Violated, not Untested) and that every applicable pessimism-recovery and corner-coverage mechanism (CRPR, AOCV/POCV, appropriate RC corners, full MCMM scenario set) has been applied, before declaring the design clean.
Failure Symptoms
A design later found to have silicon issues despite a 'clean' signoff report often traces back to an untested check category, a skipped corner, or an unapplied derate/CRPR mechanism that the zero-violation report never surfaced because it simply wasn't analyzed.
Root Cause
Equating 'no reported violations' with 'no risk,' when a report can only show what was actually checked — any check category left Untested, or any analysis dimension (corner, scenario, derate) omitted from the flow, is an invisible gap in the signoff.
Mentor Note — Debugging Procedure
Run link_design, then check_timing, then report_analysis_coverage as the very first steps, review any Untested entries via -status_details untested, and work through the full trustworthiness checklist (corners, OCV/AOCV/POCV, CRPR, crosstalk, RC corners, MCMM scenarios, exceptions) confirming each is genuinely checked before treating a zero-violation report as final. Any UNCHECKED box is a silent risk — a green, zero-violation report is not a trustworthy signoff by itself, it just means the tool hasn't yet been asked the question that would reveal the gap.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising