The Scenario Taxonomy: Legal, Boundary, Illegal, Concurrent

Ch2 produced a feature list: 23 items, decomposed from axil_regfile's spec. A feature list alone isn't a test plan yet — it says what the DUT promises, not what's worth trying against each promise. This chapter is the missing step: a four-category checklist for turning one feature into the scenarios that actually exercise it, run against every item ch2 produced. What comes out the other end is this module's real payoff — proof, not assertion, that a disciplined pass over the spec alone would have caught the same gaps Coverage's tooling later found by measurement.

Four categories, one per feature

• Legal — an access the spec fully supports. Not one instance of it: the full range of documented state and precondition combinations under which the DUT is supposed to behave, including the ones that differ from each other in ways easy to overlook.
• Boundary — a value or condition sitting exactly at, or just past, a limit the spec defines: the smallest or largest legal value, the first or last element of a range, the exact instant a threshold is crossed.
• Illegal — an access the spec says should not succeed, with a real, spec-mandated response (an error code, a rejection) rather than undefined behavior. Testing an illegal scenario isn't about breaking the DUT; it's about confirming the DUT correctly refuses it.
• Concurrent — more than one independently-timed event whose relative order or overlap the spec has rules about. Every legal ordering has to work, not just the one that happens to be easiest to drive.

These aren't always mutually exclusive — a value can sit exactly on a boundary and be illegal on the far side of it — but each one asks a different question of a feature, and a feature list run through all four surfaces scenarios a single pass never would.

Legal: more than one instance

Feature C5 from ch2's list — a DATA write increments COUNT only if ENABLE was set at the time — is a legal access either way; writing DATA is always allowed. But "legal" here isn't one scenario, it's two: DATA written while ENABLE=1 (the increment happens) and DATA written while ENABLE=0 (it doesn't). Both are documented, ordinary, fully legal behavior — and only the first one has ever run. Every CTRL write across this entire project sets ENABLE=1 before the first DATA write, every time, so the second legal case has never been exercised even once.

Feature C2 — CTRL.IRQ_CLR never being stored, never showing up on a later read — has the same shape. Reading CTRL back after writing it is a completely ordinary, legal access. It's also never happened: no test in this project's history has ever issued a CTRL read at all.

Neither of these needed an unusual input or a race condition to find. They needed the legal category taken seriously as more than a single representative example.

Boundary: where the count crosses

Feature C8 — irq asserts the instant COUNT reaches IRQ_THRESHOLD and stays asserted, level not edge, until cleared — is a genuine boundary condition: one write short of the threshold, irq must stay low; the write that reaches it, irq must rise; further writes past it, irq must stay high rather than pulse. This one is a positive result, not a gap: chapter 1's directed test crosses the threshold on its fourth write and confirms irq rises there, and uvm-advanced ch6's capstone drives COUNT to 6 — two past the threshold — confirming it stays asserted rather than behaving like an edge. The taxonomy doesn't only find gaps; running a feature through it here confirms a boundary this project actually got right.

Illegal: the scenario Coverage already measured

Features B2/B3, applied to axil_regfile's writable-address space, generate exactly three illegal scenarios: writing STATUS (mapped, read-only → SLVERR), writing COUNT (mapped, read-only → SLVERR), and writing an address nothing is mapped to (→ DECERR). None of the three has ever run. This is the same real gap dv-methodology ch3 found by measurement — the write case's SLVERR/DECERR arms reading zero hits in a line/branch report. Here, it's the same finding reached a different way: nobody needed to simulate anything to write these three scenarios down. Reading the register map's read/write column and asking "what happens on the access this row says isn't supported" produces them directly. A verification engineer working from this taxonomy before a single line of uvm-advanced ch1 was written would have had these three scenarios on the plan from day one — and would have caught, in a plan review, exactly what ch3's coverage report caught later, after simulation, at the higher cost ch1 of this module already named.

Concurrent: three scenarios, not one

Feature A5 — AW and W may arrive in either order, or together — generates three scenarios by itself: AW before W, W before AW, and both together. Only the third has ever run; every driver this project has written asserts awvalid and wvalid in the same cycle, always. This is the identical gap dv-methodology ch4 and ch5 found by measurement — aw_have/w_have never toggling, the AW_ONLY/W_ONLY FSM states never visited — reached here the same way the illegal-category gap was: by reading what the spec says is legal, not by running anything.

The concurrent category finds two more real gaps ch2's list already named, that Coverage's tooling never isolated at all:

• A7, the single-outstanding-transaction restriction — a new AW/W shouldn't be accepted while a previous write's B response is still outstanding. Testing it means holding BREADY low on purpose and attempting a second write while the first is still pending. Every driver this project has written holds BREADY high constantly, so s_axi_bvalid never actually stays asserted for more than an instant — this restriction has never been meaningfully exercised, and no chapter in the Coverage module built a check that would have noticed, since nothing in that module's functional or code coverage models isolated "a second AW/W arrives while BVALID is still high" as its own scenario.
• D2, reset asserted mid-transaction — every test in this project's history asserts reset exactly once, at the very start, and never again. Whether axil_regfile recovers cleanly from reset landing in the middle of an AW/W handshake or a pending B response has never been tried, and nothing in Coverage ch1-6 measured it either.

The connecting idea, stated outright

Every real gap Coverage's tooling found by measurement — STATUS/COUNT/unmapped writes (ch3's line/branch report), aw_have/w_have never toggling (ch4's toggle report, ch5's FSM report) — falls cleanly out of exactly two taxonomy categories, Illegal and Concurrent, applied to a feature list built from the spec alone. None of that required a simulator, a coverage tool, or axil_regfile's RTL to exist yet. It required reading the register map's read/write column and the protocol's independence rule, and asking the four questions this chapter opened with. That's the cost argument from ch1 made concrete: the same gaps, found on paper instead of in a report.

It cuts the other way too, and this matters as much as the first half: the concurrent category also surfaced A7 and D2 — real, checkable gaps that no chapter in the Coverage module actually caught, because nothing in that module's covergroup, line/branch, toggle, or FSM checks happened to isolate those specific scenarios either. Test planning and coverage measurement aren't redundant with each other. A good plan catches some real gaps before any code exists; a good coverage model catches others, including ones the plan's author didn't think to write down; and — as A7 and D2 show here — some gaps only get caught at all if someone runs the systematic exercise from both directions.

Summary

• The taxonomy has four categories: legal (the full documented behavioral range, not one example), boundary (values at or just past a defined limit), illegal (accesses the spec requires a real error response for), and concurrent (independently-timed events whose relative order matters).
• Running axil_regfile's feature list through Legal alone found two real gaps (DATA while ENABLE=0, reading CTRL back) that needed no unusual input at all — just the legal category taken as a range, not a single case.
• The threshold-crossing boundary scenario is a confirmed positive result, not a gap — this project's tests actually cover it, across two chapters.
• The illegal category reproduces dv-methodology ch3's real gap (writes to STATUS/COUNT/an unmapped address) directly from the spec, before any simulation exists.
• The concurrent category reproduces ch4/ch5's aw_have/w_have gap the same way, and finds two more (A7's backpressure scenario, D2's reset-mid-transaction) that no chapter in the Coverage module actually isolated — proof that planning and measurement catch different things, not the same thing twice.