Different types of coverage in Metric Driven Verification (MDV)

Categories:

Metric Driven Verification (MDV) depends heavily on different types of coverages to quantify and close verification progress. It ensures not just that simulation ran, but the right scenarios, conditions, and design behaviors were exercised and validated.

Different types of coverages include:

1. CODE COVERAGE

Code coverage tells how much of the RTL code is exercised during simulation. Different types of code coverage include:

TypeWhat it measuresExample
Line coverage
(Statement coverage)
Checks whether each executable line or statement of code is executed at least once or not during simulation.Did the “if (a && b)” line execute?
Toggle coverageVerifies that every individual bit of a net, register, and logic toggles from 0 to 1 and from 1 to 0 during simulation.Did signal “clk_enable” toggle from 0->1 and 1->0?
Condition coverage
(Expression covergae)
Measures whether each boolean expression within a decision has evaluated to both true and false.In “if (a && b)”, did both “a” and “b” independently become 0 and 1?
Branch coverage
(Decision coverage)
Ensures that each possible branch of a control structure (like if-else, case, etc.) is exercised.In “if-else”, whether both “if” and “else” are exercised or not.
FSM coverage
(Finite State Machine coverage)
Measures whether all states and state transitions in a state machine were visited.If a state machine has 2 states: Idle and Active. FSM coverage measures whether the state becomes Idle and Active at some point in the simulation, and Idle -> Active and Active -> Idle transitions happen or not.
Path coverageMeasures whether all possible paths through a block of code have been exercised or not.Did the program follow all the possible paths through nested “if-else” blocks?

Example

module simple_example(input logic a, b, clk, output logic y);
  
  always_ff @(posedge clk) begin
    if (a) 
      y <= 1;
    else if (b)
      y <= 0;
    else
      y <= y;
  end

endmodule
Code segmentType of covergaeExplanation
always_ff @(posedge clk) beginLine coverageIs the process entered during simulation?
if (a)Branch coverage + Condition coverageDid “a” become both true and false? Was this branch taken?
else if (b)Branch coverage + Condition coverageDid “b” become both true and false? Was this branch taken?
elseBranch covergaeBranch coverage
y <= 1; , y <= 0; , y <= y;Line coverageWere these assignments executed during simulation?
y signal togglingToggle coverageDid “y” toggle from 0→1 and from 1→0 during simulation?

2. FUNCTIONAL COVERAGE

Functional coverage ensures all features and scenarios specified in the functional specification are exercised. Functional coverage is written using 3 main components:

  • Covergroups: Defined in SystemVerilog to track the occurrence of interesting events.
  • Coverpoints: Specific variables or conditions to cover.
  • Cross Coverage: Combinations of multiple coverpoints.

Example

covergroup cg @(posedge clk);
  coverpoint packet_size {
    bins small = {0,1};
    bins medium = {2,3,4};
    bins large = {[5:10]};
  }
endgroup

Here in the above code, we’ve created a small functional coverage model to monitor whether different types of packets are used during simulation or not. We’re covering small, medium, and large packet sizes.

NOTE: I will try to create a separate post related to Functional coverage in the future.

3. ASSERTION COVERAGE

Assertion Coverage checks if SystemVerilog Assertions (SVA) have been triggered during simulation and whether they pass or fail.
Immediate Assertions: Checked instantly.
Concurrent Assertions: Time-based sequence checking.

Example

assert property ( @(posedge clk) req |-> ##[1:3] grant );

Tracks how often req “was” followed by “grant" within 1 to 3 cycles.
Assertion coverage helps identify dead code or logic that never triggers.

NOTE: I will try to create a separate post related to Assertion coverage in the future.

4. TESTPLAN COVERAGE

Test plan or vPlan coverage tells whether all planned features are covered by the simulation or not. In simple words, this is coverage of planned verification features against the written testcases.

  • Requirement Mapping: Every requirement/feature should be covered by at least one test or a functional coverage, or code coverage. This mapping purely depends on the verification engineer, how they want to verify a requirement.
  • Progress Monitoring: Shows coverage against the planned verification checklist.

vManager or similar tools map tests to functional features and track their status.

NOTE: I will try to create a separate post related to Testplan coverage in the future.

5. Formal Coverage

When using formal verification tools, additional types of coverage appear. Some key concepts of Fomal coverage are:

  • Proof Coverage: How much of the design was proven correct.
  • Cone of Influence (COI) Coverage: What part of the design impacts a given property.
  • Bound Coverage: Whether properties were fully proven or just bounded.

Formal coverage helps in exhaustive verification, where simulation might miss corner cases.

NOTE: I will try to create a separate post related to Fornal coverage in the future.

Is Code coverage and Functional coverage the same?

Code coverage and Functional coverage are not the same. Read Functional Coverage here.
Code coverage shows “Did RTL code get activated or not?” whereas Functional coverage shows “Did real scenarios and use cases happen or not?”.
Both are needed for full verification closure.

Example Coverage report summary

Below is a realistic sample coverage report you might see from a tool like VCS, Questa, or Vmanager.


| Coverage Summary |

Coverage TypeAchieved (%)Goal (%)Status
Line Coverage98.5%95%Pass
Branch Coverage96.7%95%Pass
Expression Coverage94.2%90%Pass
Toggle Coverage93.5%90%Pass
FSM State Coverage100%100%Pass
Functional Coverage88.0%95%Fail
Assertion Coverage92.3%90%Pass

Overall Coverage Score: 93.3%
Regression Status: INCOMPLETE – Functional Coverage Shortfall

Conclusion

Metric-Driven Verification requires a comprehensive view across different coverage types to ensure that designs are fully tested, validated, and production-ready. No single coverage type alone is sufficient — full verification closure needs code, functional, assertion, and formal coverage combined with detailed analysis and gap closure strategies.



2 Responses

Leave a Reply

Your email address will not be published. Required fields are marked *