How do you use report_analysis_coverage to prove every endpoint was checked across a multi-scenario signoff run?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
report_analysis_coverage (PT) reports how many endpoints were actually tested for each check type, setup, hold, and design rule checks, against how many exist in the design, which is the direct way to prove a signoff run covered everything rather than inferring it from a clean slack summary. In a multi-scenario run, several mode and corner combinations analyzed together, the merged version of this report rolls that same coverage question up across every scenario at once.
Technical Explanation
- The command counts endpoints in categories like tested-and-met, tested-and-violated, and untested, for each check type, so it answers "was this endpoint checked" separately from "did this endpoint pass."
report_analysis_coverage -status_details {untested met}(PT) style filtering lets you pull just the untested category, which is the list worth chasing down before declaring signoff coverage complete.- In a distributed multi-scenario analysis (DMSA, where PrimeTime runs many mode and corner scenarios in parallel and merges the results) run, the merged
report_analysis_coveragereflects coverage across the full scenario set, not just one corner. - Because a single scenario can look fully covered while a different scenario in the same run leaves a different subset of endpoints untested, only the merged, multi-scenario view can confirm every endpoint was checked in every scenario that matters.
- An endpoint can be untested for a specific reason, most often that it has no defined constraint reaching it, the same root cause an unconstrained-endpoint message reports, so this check and the unconstrained-endpoint check often point at the same underlying SDC gap from two different angles.
- Because coverage gaps do not show up as violations, only as missing entries, this report has to be checked deliberately as part of signoff; a summary that only lists violation counts will not reveal it.
- Coverage reporting is typically part of a final signoff checklist alongside the violation counts themselves, precisely because the two reports answer different questions and neither one substitutes for the other, and a checklist that skips it can pass review without anyone noticing the gap.
Common Mistake
The Trap: declaring a multi-scenario signoff run clean because every scenario's individual violation count reads zero, without running the merged report_analysis_coverage to confirm no endpoint was left untested in any of them.
- A per-scenario coverage gap can hide inside an otherwise-clean scenario if nobody checks coverage specifically, since an untested endpoint produces no violation to flag it.
- Assuming coverage is uniform across scenarios because it looked complete in the corner you happened to check first misses that different scenarios can leave different endpoints untested.
Follow-up Question & Model Response
If report_analysis_coverage shows one endpoint untested in only one of fifteen scenarios, is that a real signoff blocker?
Candidate Model Response: Yes, treat it as a blocker until the cause is understood, because a single untested endpoint in even one scenario means that specific mode-corner combination was never actually checked at that point, exactly the gap coverage reporting exists to catch. The next step is tracing why that one scenario differs, often a mode-specific set_case_analysis (SDC) or clock-gating condition disables the path only under that mode, leaving it genuinely unconstrained there. Once the cause is confirmed, either the constraint gets fixed so the endpoint is properly covered, or the team documents why that endpoint is legitimately excluded in that specific mode, but it cannot simply be left unexplained.
Practical Example
A signoff run covers 15 scenarios across 3 modes and 5 corners, and a merged report_analysis_coverage -status_details {untested met} (PT) shows one endpoint, u_pll/div_reg/D, untested in the low-power mode scenarios only, 5 out of 15. Tracing it shows the PLL divider's clock is defined with set_case_analysis 0 (SDC) disabling its clock source during low-power mode, which is a legitimate mode-specific gate, but the team had never documented that exclusion. The endpoint is added to a signed-off exceptions list with the reason recorded, so the next signoff run does not re-flag it as an unexplained gap, and the coverage report for future runs is expected to show it as explicitly excluded rather than simply untested.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising