What a Test Plan Is, and Why It Comes First

"How would you verify this block?" is one of the most common questions in a DV interview, and it's a trap for anyone who answers it with syntax. Naming covergroup and uvm_sequence answers a different question — how do you write a test, once you already know what to write. The actual question is earlier and harder: given nothing but a specification, how do you arrive at the list of scenarios worth testing, and know you haven't missed the ones that matter? That's what a test plan is, and it's the subject of this module.

What a test plan actually is

This track has already produced two documents against axil_regfile, and neither one is a test plan:

• Test code (uvm-advanced ch1-6) — the actual sequences, drivers, and directed writes that ran against the DUT. This is what got written.
• Coverage reports and the waiver log (dv-methodology ch1-6) — line/branch/toggle/FSM numbers and a judgment on each gap, produced by measuring what the test code above actually exercised. This is what got measured, after the fact.

A test plan is neither. It's the document that would have come before both — a mapping from the specification's features to the scenarios worth testing for each one, written from what the spec promises, not from what the RTL happens to do or what's convenient to automate. Test code executes a plan (or doesn't, if nobody wrote one). A coverage report checks whether execution actually matched intent. The plan is the only one of the three that states the intent in the first place.

Why it comes first

The concrete argument is cost, and it only gets worse the later a gap is found. A missing scenario caught while reading a test plan costs the time it takes to add a line to a document. The same gap caught by a coverage report, the way dv-methodology ch3-5 found axil_regfile's real ones, costs however long it takes to write, debug, and re-run a new test — after the fact, competing with whatever else that regression cycle needed. The same gap caught after tapeout costs a respin. None of those are hypothetical tiers; they're the same missing scenario, priced differently by how late it's found.

There's a second reason, less about cost and more about how verification teams actually work: a test plan is something a lead or a teammate can review before anyone starts writing code. Test code nobody reviewed the strategy behind is a bet that one engineer's instincts about what matters were complete — and a plan is what turns "trust me, I've got this DUT covered" into something checkable, by someone other than the person who wrote it, before weeks of test-writing are sunk into whatever direction they picked.

The hindsight this module is written with

This chapter can't pretend to plan axil_regfile blind — the reader has already seen it built and tested twice over, first in uvm-advanced ch1-6, then measured in dv-methodology ch1-6. Pretending otherwise would be a worse lesson, not a more honest one. Instead, this module reconstructs, deliberately, the test plan axil_regfile never actually got before uvm-advanced ch1 was written — using the finished DUT and its real, already-discovered gaps (writes to STATUS/COUNT/an unmapped address never tested, aw_have/w_have never toggled because every driver in this project's history sends AW and W together) as checkable evidence, not as spoilers to avoid. Chapter 3 puts this to direct use: it runs a systematic scenario-generation technique against axil_regfile's spec and checks its output against what Coverage's tooling actually found — a real answer to "would a disciplined test plan have caught this," not a hypothetical one.

What a test plan is not

Three boundaries worth being precise about, since blurring any of them is a common way test planning goes wrong in practice:

• Not a coverage model. A coverage model (dv-methodology ch2) is how you'd measure whether a plan's scenarios actually got exercised, in SystemVerilog, after tests exist to run. The plan comes first and says what should be tested and why; the coverage model operationalizes checking it later. Writing a covergroup is not the same activity as deciding what belongs in one.
• Not an unranked to-do list. "Test the write path, test the read path, test reset" is a list, not a plan — it's missing the why that lets someone else judge whether it's complete. A real test plan entry ties each scenario back to a specific spec requirement or a specific risk, which is exactly what makes it reviewable instead of just a personal reminder.
• Not derived from the RTL. A test plan built by reading axil_regfile's implementation and testing whatever it happens to do is testing the implementation against itself — it will pass every time by construction, and it will never catch a case where the RTL quietly does something the spec didn't promise. A test plan is built from the specification: what AXI4-Lite requires, what the register map promises, independent of how any particular RTL happens to satisfy it. Testing the contract, not the implementation, is what gives a test a chance of ever failing for the right reason.

The shape of a real test plan

Four pieces, each of which becomes its own chapter rather than staying abstract:

1. A feature list — every promise the spec makes, decomposed into concrete items (ch2).
2. Scenarios per feature — for each item, the legal, boundary, illegal, and concurrent cases worth testing, generated systematically rather than by whatever comes to mind first (ch3).
3. Priority — which scenarios get written first when time is limited, judged by risk rather than worked top to bottom (ch4).
4. Traceability — the thread connecting a spec requirement to a plan item to a coverage item to an actual test, and how the plan gets revised as real gaps surface rather than being written once and frozen (ch5).

Summary

• A test plan is a prospective, spec-derived document — what should be tested and why — distinct from the test code that executes it and the coverage report that checks whether execution matched intent.
• Cost is the argument for writing it first: the same missing scenario is cheapest to catch on paper and most expensive to catch after tapeout, with a coverage report and a debugged, re-run test sitting in between.
• A test plan is also a review artifact — it lets someone other than its author check the strategy before weeks of test-writing commit to it.
• This module reconstructs, in hindsight, the plan axil_regfile never got before it was built — using its real, already-known gaps as checkable evidence rather than pretending to plan blind.
• A test plan is built from the specification, not from the RTL's implementation — testing the contract a DUT promises to honor, not just whatever it happens to already do.