RISC-V Design · All levels

Coverage-Driven Verification: Debug Playbook

Debug Playbook for Coverage-Driven Verification.

Debug playbook

Debug Playbook for Coverage-Driven Verification is anchored on Risk-weighted closure across functional coverage, assertion coverage, code coverage, and bug escape trend.. Convert observations into mechanism-backed decisions with explicit ownership.

Freeze workload seed, binary, compiler, firmware, and platform setup.
Find earliest persistent mechanism failure in the timeline.
Build one reduced reproducer for dominant hypothesis.
Patch minimal fix with explicit rollback gate.
Rerun correctness + performance + power matrix.

Decision tree

diagram

ROOT CAUSE TREE - Coverage-Driven Verification

Risk-weighted closure across functional coverage, assertion coverage, code coverage, and bug escape trend. regressed
          |
   reproducible on fixed seed?
      /                 \
    no                   yes
    |                     |
env/tool drift       first failing domain?
                     /        |         \
                  decode    execute    memory/MMU
                    |         |            |
               control map  bypass/FU   TLB/walk/perm
                    |
         privilege/CSR side effects checked?

Stop at first confirmed mechanism, then assign explicit owner + fix proof.

Review memo template

diagram

RISC-V REVIEW MEMO - Verification & Debug / Coverage-Driven Verification

1. Symptom
   - Failing metric: Risk-weighted closure across functional coverage, assertion coverage, code coverage, and bug escape trend.
   - Failing workload slice: <name>
   - Triggering mode: <privilege/virtualization/interrupt/cache/boot>
   - Build and runtime tags: <toolchain/firmware/RTL revision>

2. Mechanism hypothesis
   - Primary mechanism: Coverage-driven verification converts architecture risk into measurable closure targets for instructions, privilege modes, interrupts, memory ordering, and exception sequencing. Constrained-random stimulus and scenario weighting should be guided by uncovered bins and historical bug classes, not only raw percentage goals. Signoff readiness combines stable regressions, reviewed exclusions, and evidence that critical cross-products are hit under realistic contention so final quality is based on demonstrated behavior breadth.
   - Competing hypotheses: <decode control / hazard / MMU / privilege / integration>
   - Missing evidence: <trace/counter/proof/report>

3. Proposed action
   - Smallest reversible change: <RTL/compiler/runtime/config>
   - Expected movement: <throughput/latency/tail/perf-per-watt>
   - Regression risk: correctness, security, power, timing, software compatibility

4. Signoff
   - Required artifact: Verification closure report with risk bins, uncovered-item action plan, and signoff recommendation.
   - Required owners: CPU verification lead, quality/signoff owner, CPU architect, program manager
   - Final decision: ship, bounded rollout, rollback, or escalate

Practice this lesson