Coverage Metrics¶

1. Introduction¶

In digital design verification, coverage metrics help us answer a key question:

How well have we tested our design?

Coverage tells us which parts of the design and the specification have been exercised by tests, and which parts are still untested. For this reason, coverage is a natural bridge between the Verification Plan and the Test Plan.

Without coverage metrics, it is impossible to know with confidence when verification is truly complete.

2. What Is Coverage?¶

Coverage is a metric collected during simulation that allows us to determine:

• Whether all functional requirements have been tested.
• Whether there are parts of the design (code or behavior) that were never exercised.

Coverage does not find bugs by itself, but it tells us where to look and what is missing in our verification effort.

3. Controllability and Observability¶

For a bug to be detected in simulation, three conditions must be satisfied:

1. The stimulus must activate the bug (controllability).
2. The effect of the bug must propagate to an observable output.
3. The testbench must observe and detect that effect.

Controllability¶

Controllability is the ability of the testbench to drive the design into a specific internal state through its inputs.

Examples:

• Activating a specific FSM state.
• Forcing a particular combination of input signals.

Observability¶

Observability is the ability to see, from outside the design, the effects of internal behavior.

A design may contain internal bugs that are never visible at the outputs unless the correct path is selected (for example, through a multiplexer or a sel signal).

Coverage helps identify these hidden scenarios.

4. Why One Coverage Metric Is Not Enough¶

It is important to understand that:

• 100% code coverage does not mean 100% functional verification
• 100% functional coverage does not mean 100% code coverage

This happens because:

• Code coverage measures which lines or structures were executed, not their functional meaning.
• Functional coverage measures which expected behaviors were exercised, but may miss RTL code not associated with explicit functional goals.

Therefore, real-world verification relies on both types of coverage.

5. Types of Coverage Metrics¶

From a practical point of view, coverage metrics are divided into two main categories:

5.1 Code Coverage (Implicit Coverage)¶

• Automatically generated by the simulation tool.
• Based on the RTL implementation.
• Common examples include:
• Line coverage
• Branch coverage
• Toggle coverage
• FSM coverage

Code coverage mainly answers the question:

Which parts of the code were executed?

5.2 Functional Coverage (Explicit Coverage)¶

• Defined manually by the verification engineer.
• Based on the functional specification.
• Answers questions such as:

Have all functional requirements been tested?

Functional coverage is essential in modern methodologies such as Constrained Random Verification (CRV).

6. Functional Coverage¶

The main goal of functional coverage is to measure verification progress with respect to the specification.

In other words, it helps answer:

• Were all requirements implemented?
• Were they exercised during simulation?

Important Characteristic¶

Functional coverage cannot be extracted automatically. This means:

• It requires careful planning.
• It may be incomplete if the coverage model is poorly defined.

7. Types of Functional Coverage¶

At a high level, the behavior of a design has two dimensions:

• Data
• Time

Therefore, there are two main types of functional coverage:

7.1 Data Coverage (Covergroups)¶

Measures signal or register values at a specific point in time.

Examples:

• Boundary values of an address bus.
• Combinations of control signals.
• Read and write operations.

In SystemVerilog, this is implemented using:

• covergroup
• coverpoint
• cross

This coverage answers:

Which values and combinations have been observed?

7.2 Temporal Coverage (Cover Properties / Assertions)¶

Measures sequences of events over time.

Examples:

• Bus handshake sequences.
• Legal state transitions.
• Read/write protocol behavior.

This is implemented using:

• SystemVerilog Assertions (SVA)
• cover property

This coverage answers:

Were the expected temporal sequences exercised?

8. Relationship Between Covergroups and Cover Properties¶

Both types of functional coverage are complementary:

• Covergroups verify what values occurred.
• Cover properties verify how and when they occurred.

A high-quality functional coverage model combines both approaches.

9. Typical Functional Coverage Flow¶

A common functional coverage flow consists of the following steps:

1. Define coverage goals from the specification.
2. Create the functional coverage model.
3. Run simulations (directed or random tests).
4. Collect coverage results.
5. Analyze coverage holes.
6. Decide corrective actions:
7. Add new tests
8. Refine random constraints
9. Fix design or testbench bugs
10. Mark unreachable functionality

10. Conclusion¶

Coverage metrics are essential to:

• Measure real verification progress.
• Link the specification, Verification Plan, and Test Plan.
• Avoid incomplete verification based only on intuition.

In summary:

Coverage does not replace the engineer — it guides engineering decisions.