← All tutorials

DV Methodology

Practical verification wisdom: test-planning mindset, coverage-driven judgment, and debugging intuition.

  1. 01Coverage in One Page: Functional vs. Code CoverageDraw the line between functional coverage (what you declare you care about) and code coverage (what a tool automatically measures from the RTL) -- a common interview question and the anchor for this whole module -- before any covergroup syntax at all.
  2. 02Functional Coverage in Depth: bins, Crosses, and OptionsThe covergroup/coverpoint syntax ch1 deferred, in full: explicit bins, illegal_bins, ignore_bins, transition bins, cross coverage with illegal combinations, option.at_least/weight/goal, and get_coverage() vs. get_inst_coverage() -- built into a real coverage model for axil_regfile's address space and response codes.
  3. 03Code Coverage: Line and BranchWhat a real line/branch coverage report actually shows, down to individual statements and case arms -- built against axil_regfile's write-response logic and this site's own real test history, including a genuine, still-open gap: neither error response has ever been tested on the write path.
  4. 04Code Coverage: ToggleBit-level 0->1/1->0 activity, entirely orthogonal to control flow -- and a real finding in axil_regfile's own test history: the AW/W independence logic ch1 called out as genuinely hard has literally never toggled, and s_axi_wstrb has been driven to one constant value in every test this site has ever written.
  5. 05Code Coverage: FSMState coverage and transition coverage, given precise vocabulary and reframed directly onto axil_regfile's aw_have/w_have latching logic -- including one state this design makes structurally impossible to reach, and the same real gap ch4's toggle report found, now visible a third way.
  6. 06Coverage-Driven Verification: Closing the LoopNo new syntax -- what a verification engineer actually does with everything ch1-5 found: merge coverage across a regression, judge each gap as genuine, structurally impossible, or low-value, close what's worth closing, and write down the rest as a waiver instead of silently ignoring it.
  7. 07What a Test Plan Is, and Why It Comes FirstThe interview question behind 'how would you verify this block': not what tests to write, but what a test plan is before any of them exist -- a spec-derived, prospective document, distinct from the test code and the coverage report this track has already built for axil_regfile.
  8. 08From Spec to Feature ListA repeatable technique for decomposing a specification into a feature list without relying on whatever's obvious -- applied directly to axil_regfile's AXI4-Lite grounding and register map, producing a list already visibly broader than anything any test in this project has actually run.
  9. 09The Scenario Taxonomy: Legal, Boundary, Illegal, ConcurrentThe four-category checklist for turning a feature into scenarios, run against axil_regfile's 23-item feature list from ch2 -- and the module's actual payoff: this taxonomy, applied to the spec alone, would have flagged the exact real gaps Coverage's tooling later found by measurement, plus a few it never isolated at all.
  10. 10Risk-Based Prioritization: What to Write FirstNot every scenario ch3's taxonomy produced is equally worth writing first. A likelihood/impact framework, applied to axil_regfile's real open gaps -- including the strongest possible evidence for one of them: this exact area of RTL already produced a real, shipped bug.
  11. 11The Test Plan as a Living, Traceable DocumentClosing the module: a chain linking spec requirement to plan item to coverage item to actual test, traced against axil_regfile's real open gaps -- and a verification plan that absorbs new information from measurement and from its own planning process, rather than being written once and frozen.
  12. 12Where a Failure Lives: Four Places to Check FirstThe interview question behind 'walk me through how you'd debug a failing test': before touching a waveform, a failure can only structurally live in one of four places -- the DUT, the testbench, the environment, or nowhere at all -- grounded in three real, already-documented incidents on axil_regfile.
  13. 13Reading the Failure SignatureBefore the deep diagnostic work, how a failure presents is already a hint toward which of ch1's four categories it belongs to -- immediate and deterministic, order-dependent, failing before simulation even starts, or matching a spec-defined outcome exactly -- grounded in how axil_regfile's three real incidents actually first looked.
  14. 14The Diagnostic Method: Isolate, Instrument, Hypothesize, ConfirmThe repeatable four-step process that actually confirms a hypothesis ch2's signature-reading only suggested -- taught by comparing how it played out differently for a real structural bug and a real timing bug, both already documented on axil_regfile, without retelling either incident in full.
  15. 15Writing the Bug Down, and Closing the LoopA confirmed root cause isn't the end of a debugging session -- a good write-up is, using uvm-advanced ch1's own already-published bug callout as the worked example. Closes this module, and the whole dv-methodology track, by tracing spec to plan to coverage to test to bug to written record and back into the plan.