Term · Verification & Validation
Code coverage
Automatically extracted metrics showing which parts of the RTL source were exercised by simulation, including line, branch, condition, toggle and FSM coverage. It needs no engineer to write it, but it can only report on code that exists, never on missing functionality.
- Also known as
- Structural coverage, Test coverage, Statement coverage, Branch coverage
- Type
- Term
- Domain
- Verification & Validation, Coverage
- Also relevant to
- Embedded Software & Tools
Notes
High code coverage with low functional coverage is the classic sign of stimulus that is broad but shallow.
Overview
Code coverage is a family of metrics, collected automatically by a simulator or formal tool, that records which parts of a design's source code were exercised during verification, such as lines, branches, expressions, signal toggles and state machine transitions. Verification teams use it to find logic that no test has reached, because code that never runs cannot show its bugs. It measures the implementation rather than the specification, so it covers only half of coverage closure, with functional coverage as the other half.
How it works
The tool instruments the RTL when it is compiled and counts activity during every run. Line or block coverage records whether each statement executed. Branch coverage checks that both outcomes of each if and case were taken. Expression or condition coverage checks that each term of a Boolean expression actually changed the result. Toggle coverage checks that every signal bit moved from 0 to 1 and back, and state machine coverage records which states and transitions were visited. Results from many runs are merged, and Accellera's Unified Coverage Interoperability Standard (UCIS) defines a common way to model and exchange that data between tools.
Engineers then review the holes. Some are genuine gaps, closed with new tests or changed constraints on random stimulus. Others are typically unreachable by design, such as defensive default branches or configuration logic tied off in this product, and these are usually excluded with a recorded reason. Formal tools can also report code coverage, but simulation and formal coverage do not mean quite the same thing, so merging them needs care.
The main limit is that code coverage can only judge code that exists. A feature that was never implemented leaves no line to miss, and full coverage says nothing about whether interactions between modules, simultaneous events or orderings of events were tested, or whether results were checked at all.
Examples
- A nightly regression on a DMA controller showing that an error recovery branch has never executed, which prompts a new directed test.
- Toggle coverage revealing that the upper bits of an address bus never change in any test.
- State machine coverage showing that a link training controller never takes its timeout transition.
- Coverage from thousands of regression runs merged into one report for a verification review.
- Avionics software teams measuring modified condition/decision coverage (MC/DC), which certification guidance for the most critical airborne code often requires.
Related terms
Part of the Verification & Validation glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 22 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
- Verification and Structural Coverage (Avionics lifecycle)
- Verification complete (Avionics lifecycle)
- Device Verification (FPGA chip lifecycle)
- Compiler, Runtime & Library Co-development (AI accelerator lifecycle)
- Full-Chip Verification (SoC lifecycle)
- Verification sign-off (AI accelerator lifecycle)
- and 2 more
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary