Exclusions & Waivers

What may legitimately be excluded

An exclusion removes a bin, cell, or hierarchy from the closure goal. It is the correct tool exactly when the scenario cannot or need not occur — and a falsification of the metric in every other case. The legitimacy test is simple: would hitting this bin teach us anything the plan wants to know? If yes, it stays.

Legitimate exclusion criteria

• Structurally unreachable — tied-off inputs, hardware config not present in this product, dead modes confirmed by the designer.

• Spec-forbidden combinations that are separately checked — the illegal_bins or assertion provides the evidence; the cross cell is pruned from the goal.

• Out-of-scope hierarchy — vendor IP verified by its supplier, behavioral models, test harness internals.

• Deferred features — explicitly not in this release, with the plan row marked deferred (and revived next release).

• Auto-product residue — cross cells generated by the tool that no plan row ever demanded (better: prune in the model with ignore_bins).

// Prefer pruning IN THE MODEL, where it is versioned with the code:
x_mode : cross cp_cfg, cp_op {
  // EXCL-014: dual-channel ops impossible in single-channel SKU.
  // Approved: rsharma 2026-04-02. Spec s2.1 table 2-1.
  ignore_bins single_sku = binsof(cp_cfg.single_ch) &&
                           binsof(cp_op.dual_op);
}

Waiver documentation discipline

A waiver is the audit record behind an exclusion. The rule of thumb: a waiver must let a stranger, a year later, decide whether the exclusion is still valid — without finding the people involved.

WAIVER RECORD — minimum fields

  id        : EXCL-014                    (stable, referenced from code)
  target    : dma_cg::x_mode <single_ch, dual_op>  (exact bins/cells)
  reason    : single-channel SKU has no dual-op datapath
  evidence  : spec s2.1 table 2-1; designer confirmation (link)
  class     : structurally unreachable
  approved  : verification lead + designer, 2026-04-02
  expires   : re-review at next SKU addition / next major spec rev
  ─────────────────────────────────────────────────────────────────
  WHO approved, WHY, and a LINK TO SPEC are the non-negotiable three.
  An exclusion nobody can defend a year later is a hole wearing a costume.

Exclusion-file hygiene

• Version-control the exclusion file with the testbench — it is part of the coverage model, and its diff history is audit evidence.

• One exclusion per entry with its waiver ID — no wildcard patterns that silently swallow future bins.

• Re-validate on RTL or spec change: yesterday's unreachable can become reachable when a tie-off is removed.

• Track the exclusion count as a metric — a rising curve near a deadline is itself a review finding.

• Prefer ignore_bins in the model over tool-side exclusion files where possible — code review sees the former by default.

The deadline bulk-exclusion failure mode

Every verification organization has the story: Friday before sign-off, coverage is at 93%, and a bulk exclusion of 'miscellaneous unreachable crosses' lands the report at 100%. Months later a silicon bug traces to a cell inside that bulk exclusion — reachable all along, just never analyzed.

TWO ROADS TO "100%"

  honest closure                      bulk exclusion at deadline
  ──────────────────                  ──────────────────────────
  93% + 7% triaged:                   93% + 7% excluded as a block
    4% steered & closed                 no per-cell analysis
    2% directed & closed                no designer confirmation
    1% waived, each documented          one commit, 400 cells
         │                                   │
         ▼                                   ▼
  every zero-hit cell has a           unknown number of reachable,
  name, an owner, a reason            untested scenarios shipped
                                             │
                                             ▼
                                      the silicon bug post-mortem
                                      finds the exclusion commit

Interview angle: "When is it OK to exclude coverage?" separates process maturity cleanly. Senior answers give the criteria (unreachable, separately-checked, out-of-scope, deferred), insist on per-item waivers with approver and spec link, and volunteer the deadline-bulk-exclusion anti-pattern unprompted. A follow-up worth preparing: "who should be allowed to approve a waiver?" — at minimum the verification lead plus the designer of the affected logic, never the engineer closing the number alone.

Key takeaways

• Exclude only what cannot or need not occur: unreachable, separately-checked, out-of-scope, or formally deferred.

• Every exclusion carries a waiver: who approved, why, spec link, and when it gets re-reviewed.

• Keep exclusions in version control — ideally as ignore_bins in the model where code review sees them.

• Exclusion count over time is a sign-off metric; a spike at deadline is a finding, not a fix.

Common pitfalls

• Bulk exclusions under deadline pressure — statistically guaranteed to hide reachable, untested scenarios.

• Waivers that say 'not needed' with no spec reference — indefensible at audit, invisible at post-mortem.

• Wildcard exclusion patterns — they silently swallow bins added by future model changes.

• Never re-reviewing exclusions after RTL changes — a removed tie-off turns 'unreachable' into 'untested'.