Coverage is evidence about what has been exercised or observed. It is not a direct measurement of product quality. A high aggregate percentage can coexist with an untested recovery path, an inactive assertion, or a requirement that was never represented in the model.
Map coverage to intent
Every functional coverage point should trace to a requirement, risk, or review question. If nobody can explain the behavior a bin represents, the bin is a maintenance cost rather than sign-off evidence. Conversely, a requirement without a check and coverage strategy is an unmanaged verification obligation.
Code coverage highlights implementation that simulation did not execute. Functional coverage records specified scenarios and combinations. Assertion coverage records property attempts, successes, and failures according to tool semantics. Formal coverage can describe explored or proven logic. Review these as complementary views.
Design crosses around decisions
Cross coverage grows quickly. Cross only dimensions whose interaction changes expected behavior or risk: command and privilege, response and error state, packet type and backpressure, or power mode and interrupt. Avoid crossing fields merely because they are available.
- Must hit: required behavior with reachable stimulus and a checker.
- Must prove: invariant or bounded obligation assigned to formal analysis.
- Review: implementation-oriented coverage that requires engineering judgement.
- Exclude: unreachable, redundant, or non-product behavior with a documented rationale.
- Defer: accepted scope moved to a named later milestone.
Treat exclusions as controlled changes
Coverage exclusions alter the sign-off model. Store them in version control, include scope and justification, and require review. An exclusion should survive hierarchy and line-number changes where possible; fragile waivers can silently point at different logic after RTL edits.
Do not close a bin only because it is difficult to hit. First determine whether the requirement is unreachable, the stimulus model is wrong, observability is missing, or the design is incorrect. Difficult coverage often reveals a specification or architecture question.
Report residual risk
Aggregate percentages are useful trends but weak decisions. Report open high-risk features, unreviewed exclusions, inactive assertions, unstable tests, and requirements without evidence. Show movement by feature area rather than allowing easy bins to hide a stalled critical area.
Coverage closure is the process of explaining every important gap, not forcing every number to one hundred.
At sign-off, preserve the coverage model version, merged database inputs, exclusion set, review record, and mapping to requirements. UCIS can support interoperability of coverage data, but engineering meaning still comes from the plan and review.
Primary references
Need help applying these methods to a verification programme? Start a technical conversation.