Functional Coverage and Completion Criteria

Measure planned scenarios, cross important conditions, and close holes without confusing activity with correctness.

Measure the verification plan

Functional coverage measures whether planned situations have been observed. Unlike code coverage, it is defined by the team from product features and risks.

One hundred percent coverage does not prove that the DUT is correct. It only means every defined bin received a sample. A scoreboard and assertions are still needed to judge results.

Covergroups and coverpoints

covergroup command_cg @(posedge i_clk);
  option.per_instance = 1;
 
  cp_opcode: coverpoint i_opcode iff (i_valid && i_ready) {
    bins read  = {2'b00};
    bins write = {2'b01};
    bins flush = {2'b10};
    illegal_bins reserved = {2'b11};
  }
 
  cp_wait: coverpoint wait_cycles {
    bins none   = {0};
    bins short  = {[1:3]};
    bins long   = {[4:15]};
  }
 
  opcode_x_wait: cross cp_opcode, cp_wait;
endgroup

The covergroup samples on the rising edge. iff limits the coverpoint to real transfers. Bins group values according to the plan. illegal_bins reports a value that should not occur, though an assertion often provides a clearer message and error policy.

The cross checks that each command occurred with several wait lengths. Crosses can create many bins quickly, so combine only dimensions tied to a real risk or requirement.

Manual sampling

A covergroup can use sample() after a monitor reconstructs a complete transaction.

covergroup packet_cg with function sample(packet_t tr);
  cp_length: coverpoint tr.length {
    bins single = {1};
    bins small  = {[2:15]};
    bins large  = {[16:255]};
  }
endgroup

Sampling transactions rather than raw wires avoids counting values that the protocol never accepted.

Close a hole

When a bin remains empty, ask:

1. Is the scenario reachable?
2. Do stimulus constraints prevent it?
3. Does sampling happen at the right time?
4. Does the bin still match the specification?

The answer may be a directed test, adjusted random distribution, monitor fix, or justified exclusion. Changing bins only to raise the percentage does not improve verification.

Completion criterion

Closure combines passing tests, clean assertions, achieved coverage, and resolved bugs. Every coverage exclusion needs a checkable reason and should be reviewed after design changes.

Key points

• Functional coverage comes from the plan and product risks.
• A coverpoint measures one dimension, while a cross measures a useful combination.
• Sampling must correspond to a real transaction.
• A hole can come from stimulus, DUT, monitor, or an impossible bin.
• Coverage percentage does not prove result correctness.

📝 Test your knowledge - Chapter quiz