Functional coverage

Notes

The quality of a functional coverage model is limited by the imagination of whoever wrote it, which is its central weakness.

Overview

Functional coverage is a user-defined measure of which specified behaviours of a design a testbench has actually exercised, such as particular field values, operating modes, transaction types and combinations of them. Verification engineers write it from the test plan, typically as SystemVerilog covergroups, so it tracks progress against the specification rather than against the code. It complements code coverage, which is extracted automatically and cannot reveal features that were never implemented.

How it works

Engineers turn each feature in the verification plan into coverage items. In SystemVerilog, whose coverage constructs are part of the IEEE 1800 language, a covergroup is sampled on an event such as a clock edge or a completed transaction. Each coverpoint watches a signal or expression and sorts the values seen into bins, for example short, typical and maximum packet lengths. A cross records combinations of coverpoints, such as every packet length on every port. Options set how many hits each bin needs and the coverage goal.

During regression the simulator counts hits per bin and reports the share of bins filled, per covergroup and overall. Teams use the results to steer constrained random stimulus: a cross that stays empty shows that the constraints rarely produce that combination, so they are adjusted or a directed test is added. Assertion coverage, which records whether a temporal sequence ever occurred, is often tracked alongside.

The model is only as good as the plan behind it. A missing coverpoint leaves an untested feature invisible, and crosses of several coverpoints can grow very large and become expensive to fill and review. Functional coverage also cannot show whether every line of RTL ran, so teams track it together with code coverage.

Examples

• A covergroup on an APB interface whose coverpoints on the address and write data buses show how varied the stimulus has been.
• A cross on a cache controller confirming that each line state has been seen with every type of incoming request.
• A report showing that the largest packet size was never sent on one port, which leads to a change in the random constraints.
• Coverage results from many simulation runs merged into one view of progress against the verification plan.

Why it matters

Functional coverage is the main way a verification team shows that every feature in its plan has been tested, so design verification engineers, coverage closure engineers and verification leads report it at reviews and use it as a sign-off criterion. Because people write it, it reflects their judgement of what matters, and reviewing the coverage model against the specification is part of the work.

Related terms

• Covergroup
• Cross coverage
• Code coverage
• Coverage closure

Where it appears on the Hub

Used on 15 pages of the Hub. In each group, the pages that mention it most come first.