DenseChip

Part 5 · Functional Coverage · Intermediate

Hole Analysis

Reading merged reports, the four hole classes, the triage flow, and a worked triage of five example holes.

Reading a merged report

Hole analysis starts from the merged regression database — never a single seed. The report lists every bin with its merged hit count; a hole is a bin below its at_least threshold. Read holes grouped by covergroup and cross, because holes cluster: ten empty cells sharing one source bin usually mean one underlying cause, not ten.

diagram
MERGED REPORT (excerpt)            500 seeds merged

  dma_cg                                       87.5%  goal 100
    cp_len                                    100.0%
      one: 48211   mid: 1.2M   max_len: 9077
    cp_btype                                  100.0%
    x_shape                                    66.7%
      <incr,one,aligned>      : 3022
      <incr,max_len,unalign>  : 0      ◄── HOLE
      <wrap,mid,aligned>      : 18
      <fixed,one,unalign>     : 0      ◄── HOLE
      ...
  err_cg                                       60.0%  goal  90
    cp_err
      parity: 211   timeout: 0  ◄── HOLE   crc: 3

The four hole classes

  • UNREACHABLE — design or environment makes the scenario impossible. Action: ignore_bins/exclusion with documented reason. Not a test problem.

  • NEEDS-NEW-TEST — reachable, but no stimulus aims there. Action: directed test or new sequence.

  • NEEDS-CONSTRAINT-CHANGE — random stimulus could reach it but the distribution starves it. Action: retune constraints/weights, no new test.

  • WRONG-BIN — the coverage model is buggy: bad range, wrong signal, sampling at the wrong event. Action: fix the model; past data for that bin is void.

The triage flow

diagram
HOLE TRIAGE FLOW           (run per hole, cheapest test first)

  hole (merged hits < at_least)
        │
        ▼
  Q1: Is the bin definition correct?  (range, signal, sample event)
        ├─ NO ──► WRONG-BIN: fix model, invalidate old data for bin
        ▼ yes
  Q2: Is the scenario reachable?      (spec + designer + constraints)
        ├─ NO ──► UNREACHABLE: ignore_bins/exclusion + waiver doc
        ▼ yes
  Q3: Can current random stimulus produce it?
        ├─ YES, but rare ──► NEEDS-CONSTRAINT-CHANGE: retune dist /
        │                    inline constraints / more targeted seeds
        ▼ no
  Q4 ─────────────────────► NEEDS-NEW-TEST: directed test or
                             new sequence aimed at the hole

  Order matters: checking the bin (Q1) costs minutes; a directed
  test (Q4) costs days. Never pay Q4 prices for Q1 problems.

Q2 is the step that involves people: reachability questions are answered fastest by the designer, who knows whether the combination shares logic or is structurally cut off.

Worked triage — five holes

diagram
HOLE                          FINDING                        CLASS / ACTION
  ───────────────────────────────────────────────────────────────────────────
  1 <incr,max_len,unalign>      constraint file: addr aligned   NEEDS-CONSTRAINT-
    cross cell, 0 hits           to 4 in ALL sequences; spec     CHANGE: relax
                                 allows unaligned INCR           alignment in one seq
  2 cp_err.timeout, 0 hits      timeout = 10ms; tests run 1ms   NEEDS-NEW-TEST:
                                 sim time — can never fire       short-timeout cfg +
                                                                 directed timeout test
  3 <wrap,one,*> cells, 0 hits  spec s7.2.1: WRAP len-1         UNREACHABLE:
                                 forbidden; already illegal      these cells were auto
                                 elsewhere                       product — ignore_bins
  4 cp_occ.full64, 0 hits       bin coded {64} but occupancy    WRONG-BIN: fix to
                                 counter is 0..63 (full at 63    {63}; re-run — old
                                 with separate full flag)        cp_occ data suspect
  5 <fixed,one,unalign>, 18     present but below at_least=32   NEEDS-CONSTRAINT-
    hits (at_least = 32)         reachable, just rare            CHANGE: weight dist
                                                                 toward fixed bursts

What the worked triage shows

  • Five holes, four different classes — bulk-treating all holes as 'write more tests' would have wasted effort on 1, 3, 4, and 5.

  • Hole 4 is the dangerous one: the model was wrong, so the covergroup's past 'coverage' of that area was fiction.

  • Hole 5 is not empty — below-at_least bins are holes too, and the fix is distribution, not existence.

  • Hole 3 shows auto-product residue: pruning decided at plan time (previous lessons) would have prevented the triage cost.

Interview angle: "Coverage is stuck at 90% a week before tape-out — what do you do?" wants the triage flow, in order: verify the bins are right, split holes by reachability with the designer, prune the unreachable with documentation, steer constraints for the rare, and spend directed-test effort only on the remainder. Naming the four classes and the cheapest-first ordering is the senior signal.

Key takeaways

  • Triage from the merged database, grouped by cross — clustered holes share single causes.

  • Every hole lands in one of four classes: unreachable, needs-new-test, needs-constraint-change, wrong-bin.

  • Run the triage questions cheapest-first: model correctness, reachability, distribution, then directed tests.

  • Below-at_least bins are holes too — existence of hits is not sufficiency of hits.

Common pitfalls

  • Triaging from a single seed's report — half your 'holes' are already hit in other seeds.

  • Writing directed tests for unreachable cells — days of effort to hit a structurally impossible scenario.

  • Trusting hit counts from a wrong-bin — fixing the bin silently invalidates previously claimed coverage.

  • Triaging holes one by one when twenty share a source bin — fix the shared cause once.

Practice this lesson