get_coverage vs get_inst_coverage interpretation

Puzzle

Difficulty: Medium · Puzzle 4 of 6 · Topic: Coverage Closure and Sampling Timing Puzzles

Compute each instance and overall coverage, then map which API reports which number.

Code

covergroup cg with function sample(bit mode);
  option.per_instance = 1;
  cp_mode: coverpoint mode {
    bins off = {0};
    bins on  = {1};
  }
endgroup

initial begin
  cg c0 = new();
  cg c1 = new();
  c0.sample(0);
  c0.sample(1);
  c1.sample(0);
end

Hint

With per_instance=1, instance and type numbers are intentionally different.

Step-by-step solution

1) c0 hits both bins -> c0.get_inst_coverage() = 100%.
2) c1 hits one bin -> c1.get_inst_coverage() = 50%.
3) Type get_coverage aggregates instance results -> (100 + 50)/2 = 75%.
4) Therefore get_coverage and get_inst_coverage answer different questions.

Answer

Answer: Instance coverage: c0=100%, c1=50%; type coverage: 75%. Use get_inst_coverage for per-instance holes, get_coverage for aggregate status.

Why candidates get it wrong

A single aggregate number can hide bad actors when one instance is strong and another is weak.

Interviewer follow-up

What dashboard would you build to prevent signoff on 75% aggregate with a 50% critical instance?

Related topics

• Back to Coverage Closure and Sampling Timing Puzzles

• Functional Coverage Puzzles section