BeginnerQuestion 85 of 95Source: Synopsys PrimeTime User Guide: Reporting the Analysis Coverage

What does report_analysis_coverage check that a slack report alone does not?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_analysis_coverage (PT) reports what fraction of the design's paths and endpoints were actually included in the timing run, broken down by exception type and clock group. A design can show a completely clean report_constraint (PT) result and still hide real risk if large parts of it were excluded, disabled, or never constrained in the first place.

A pie chart of endpoint coverage: 80% real setup/hold checks, 14% legitimate exceptions, 6% unconstrained, with the unconstrained slice highlighted. — Technical Reference DiagramWhat does report_analysis_coverage check that a slack report alone does not?

Technical Explanation

A clean slack report only covers the paths the tool was told to check — coverage tells you how much of the design that really is.

report_analysis_coverage (PT) breaks the design down by category — how many endpoints are covered by real setup/hold checks, how many are excluded by exceptions, and how many have no constraint at all.
A false path or a set_disable_timing (SDC) call removes a path from analysis; the path itself does not go away, only PrimeTime's obligation to check it.
If too many real paths get excluded — for example, an over-broad set_false_path (SDC) meant for one case but written to match many — the coverage number quietly drops without any VIOLATED line ever appearing.
The report also flags clock groups or modes that received zero coverage, which usually points to a missing mode setup rather than a genuinely clean corner.
Coverage is a separate axis from slack: a 100% MET report_constraint result with only 60% analysis coverage is not the same as a 100% MET result with 99% coverage.
Signoff teams track this number alongside WNS and TNS precisely because a shrinking coverage percentage is invisible in a slack-only view.

Common Mistake

The Trap: reading an all-MET report_constraint result as proof the design is clean.

A path excluded by a mistaken false path never shows up as VIOLATED — it simply never gets checked, so the report looks perfect.
The only way to catch this is to check coverage directly, not to trust the absence of violations.

Follow-up Question & Model Response

If report_analysis_coverage shows 100% coverage, does that guarantee the exceptions themselves — the false paths and multicycle paths — are all written correctly?

Candidate Model Response: No, coverage only confirms that every endpoint was assigned to some category — real check, legitimate exception, or genuinely unconstrained. It cannot tell you whether a set_false_path (SDC) command was written correctly for the case it was meant to cover; a path can be 100% covered by an exception and still be the wrong exception. Verifying that requires reviewing the exception's -from/-through/-to (SDC) arguments against the actual functional intent, which is a design-review step, not something the coverage report checks automatically. Coverage answers whether a path was looked at, not whether it was looked at correctly.

Practical Example

A block reports 94% analysis coverage. Digging into the breakdown, the missing 6% turns out to be one clock domain where a designer left a debug-only set_false_path -from [get_clocks scan_clk] (SDC) command in the production SDC file, quietly excluding real functional paths that happened to share a startpoint with the scan clock.

Complete STA Handbook