Reading a spec for coverable features

A coverage plan is a systematic transcription of the spec into measurable scenarios. Four extraction questions produce the feature list: what values each field takes, what combinations the logic acts on together, what sequences must occur in order, and what boundaries the text calls out.

Numbers in spec prose are coverage gold. Every explicit constant is a boundary the designers special-cased, and boundaries are where bugs live.

The plan table

The plan is a table, one row per feature, written before the covergroups. Each row carries enough to implement the measurement and enough to audit it later.

The ID is a stable handle that code comments and reports refer to. The feature column is one sentence plus the spec section it transcribes; the coverpoint column names the construct that implements it; the bins column lists the buckets, including planned illegal and ignore bins; and the priority drives weights, closing order and waiver scrutiny.

• Plan IDs are stable and boring: CV_LEN style, never renumbered, only appended.

• Covergroup elements carry the ID in a comment on the same line as the bin they implement.

• option.comment on the covergroup names the plan section it serves, so the report self-documents.

• Bin names echo the feature, not the value: timeout_recovery, not b3. Reports are read by people who did not write the code.

The listing below is not run in this course's checks: the open simulators do not count covergroups, so the lesson's bench counts it with the bins model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// not-run: Verilator 5.048 ignores covergroups (COVERIGN) and Icarus 13 has none; the bins model counts it
interface dma_cov_if(input logic clk);
  logic       desc_done;
  logic [1:0] btype;   // 0 INCR, 1 FIXED, 2 WRAP
  logic [4:0] blen;    // 1..16

  covergroup dma_cg @(posedge clk iff desc_done);
    option.comment = "coverage plan CV_LEN, CV_WRP — spec s7.2";

    cp_btype : coverpoint btype {
      bins incr  = {0};
      bins fixed = {1};
      bins wrap  = {2};
    }
    cp_len : coverpoint blen {       // CV_LEN
      bins one     = {1};            // CV_LEN: lower boundary
      bins mid     = {[2:15]};       // CV_LEN: interior
      bins max_len = {16};           // CV_LEN: upper boundary
    }
    x_wrap : cross cp_btype, cp_len {
      illegal_bins wrap_bad = binsof(cp_btype.wrap) &&
                              binsof(cp_len.one);   // CV_WRP: spec s7.2.1
    }
  endgroup
endinterface

Plan review before coding

The plan is reviewed as a document, with the spec open, before implementation. Reviewing a finished covergroup conflates intent with code, and intent mistakes found late invalidate regression data already collected.

1. Walk the spec section by section: does every must sentence have a plan row or a written reason it does not?

2. Are boundary values from spec prose present as named bins, not buried in ranges?

3. Is every cross justified by logic that actually examines the fields together?

4. Are priorities assigned, and do P1 rows cover the features whose failure is unshippable?

5. Are planned illegal and ignore bins listed up front, not improvised at 87%?

6. Can each row be measured from observable signals, or must instrumentation be requested now?

Testbench

The bench builds plan rows CV_LEN and CV_WRP with the bins model, next to the same length field written as one range bin, and runs a regression that sends every burst type with lengths 2 to 15 only.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// uses: covmodel
// Plan rows CV_LEN and CV_WRP as bins, against a single range bin, over a regression that never sends 1 or 16 beats.
module tb_dma_plan;
  cm_point cp_btype = new("cp_btype"), cp_len = new("cp_len  (CV_LEN)"), cp_range = new("cp_len  (one range bin)");
  cm_cross x_wrap;
  initial begin
    cp_btype.add("incr", 0, 0); cp_btype.add("fixed", 1, 1); cp_btype.add("wrap", 2, 2);
    cp_len.add("one", 1, 1);                  // CV_LEN: lower boundary
    cp_len.add("mid", 2, 15);                 // CV_LEN: interior
    cp_len.add("max_len", 16, 16);            // CV_LEN: upper boundary
    cp_range.add("len", 1, 16);               // "1 to 16 beats", transcribed as one range
    x_wrap = new("x_wrap  (CV_WRP)", cp_btype, cp_len);
    x_wrap.illegal(x_wrap.sel("wrap", "one"));                 // CV_WRP: spec s7.2.1
    // The regression: every burst type, lengths 2 to 15 only.
    for (int t = 0; t < 3; t++)
      for (int len = 2; len <= 15; len++) begin
        cp_btype.sample(t); cp_len.sample(len); cp_range.sample(len); x_wrap.sample();
      end
    cp_range.report(); cp_len.report(); x_wrap.report();
    if (cp_range.get_coverage() != 100.0 || cp_len.n_covered() != 1 || x_wrap.n_bins() != 8 || x_wrap.n_covered() != 3)
      $fatal(1, "FAIL: plan bins");
    $display("PASS: the range bin read 100%%; the planned bins named both untested boundaries");
    $finish;
  end
endmodule

  coverpoint cp_len  (one range bin): 100.00% (1 of 1 bins)
    len            42
  coverpoint cp_len  (CV_LEN): 33.33% (1 of 3 bins)  below goal 100
    one            0     <- hole
    mid            42
    max_len        0     <- hole
  cross x_wrap  (CV_WRP): 37.50% (3 of 8 bins)
    hole: <incr, one>
    hole: <incr, max_len>
    hole: <fixed, one>
    hole: <fixed, max_len>
    hole: <wrap, max_len>
PASS: the range bin read 100%; the planned bins named both untested boundaries

Related topics

• Covergroup basics

• Covergroup options and methods