From Spec to Feature List

Ch1 named a feature list as the first of a test plan's four pieces: every promise the spec makes, decomposed into concrete items. "Decomposed" is doing real work in that sentence — a feature list isn't a summary of the spec, and it isn't whatever three or four bullet points come to mind after a first read. This chapter is a technique for the difference between those two things, applied directly to axil_regfile's spec (uvm-advanced ch1).

The trap: testing only what's obvious

A first pass at axil_regfile's spec, done quickly, tends to produce something like: test writes, test reads, test the interrupt. That list isn't wrong, exactly — every word of it is true — but it's a summary, not a decomposition, and a summary hides exactly the material a real feature list exists to surface. "Test writes" quietly stands in for at least half a dozen genuinely distinct behaviors: which register got written, whether the address was even mapped, whether that register supports writes at all, what response code each case produces, and whether some other piece of state changes as a side effect. Working from the three-bullet version, a verification engineer would feel done well before they actually were.

A repeatable technique: three questions per section

Read the specification section by section — not the RTL, which only shows what one particular implementation happened to do — and ask three questions of each one:

1. What does this section assert must always be true? An invariant, a rule, a guaranteed behavior — the most direct kind of feature.
2. What does this section explicitly say is not supported? An absence is worth writing down too — not because it needs a test, but because naming it on the list is what tells a reviewer it was considered and deliberately excluded, instead of just forgotten.
3. Does this interact with something described elsewhere in the spec? Features rarely live in isolation. The richest scenarios tend to sit at the boundary between two of them, not inside either one alone — and those are exactly the items a section-by-section read, taken one section at a time, is most likely to miss.

Applying it to axil_regfile

The protocol section

AXI4-Lite's own text (uvm-advanced ch1) supplies invariants directly: every channel completes a transfer only on the edge where its VALID and READY are both high; the side asserting VALID must never wait for READY, while the side asserting READY may legally wait for VALID (question 1). It also says outright what's missing — no AWLEN/ARLEN, no burst state machine at all (question 2), which matters precisely because it means nobody should spend time hunting for burst behavior that was never meant to exist. And it states an interaction directly: AW and W are independent, arriving in either order or together, with BVALID withheld until both have shown up (question 3) — a rule that only makes sense as a relationship between two channels, not a property of either one.

The register map section

Same three questions, now against axil_regfile's own register table. Each register's read/write legality is an invariant (question 1). The response-code rules are too: OKAY for a legal access, SLVERR for a mapped register that doesn't support the direction attempted, DECERR for an address with nothing mapped there at all — and the protocol section's own aside that AXI4-Lite drops EXOKAY entirely is exactly the kind of explicit absence question 2 is looking for. Question 3 is where this section pays off hardest: CTRL's ENABLE bit and DATA's write behavior look, read separately, like two unrelated rows in a table — but the spec states that a DATA write only increments COUNT if ENABLE was set at the time. That's not a feature of CTRL and it's not a feature of DATA; it only exists at the seam between them, and a feature list built register-by-register, without asking question 3, walks right past it.

The list this produces

Twenty-three items, organized the way the spec itself is organized rather than the way any one test happened to exercise them:

A — Channels and handshake

#	Feature
A1	Each channel completes a transfer only on an edge where its VALID and READY are both high
A2	This slave's VALID signals (BVALID, RVALID) must never wait for their READY before asserting
A3	This slave's READY signals (AWREADY, WREADY, ARREADY) may legally wait for VALID, or assert early
A4	No burst signals exist — every transaction is exactly one beat
A5	AW and W may arrive in either order, or together; the slave must correctly latch whichever arrives first
A6	BVALID must not assert until both AW and W have arrived
A7	A new AW/W is not accepted while a previous write's B response is still outstanding
A8	AR→RVALID has one cycle of latency; RVALID stays asserted until RREADY

B — Responses

#	Feature
B1	OKAY on a legal, successful access
B2	SLVERR on a mapped register that doesn't support the direction attempted
B3	DECERR on any address with nothing mapped there
B4	EXOKAY does not exist in this protocol

C — Register behavior

#	Feature
C1	CTRL.ENABLE (bit 0) is read/write and persists across writes and reads
C2	CTRL.IRQ_CLR (bit 1) is a one-shot pulse on write — never stored, never reflected on a later read
C3	CTRL writes are whole-word: a single write specifies both bits' new values at once
C4	STATUS mirrors irq's live value; read-only
C5	A DATA write updates data_reg unconditionally, but increments COUNT only if ENABLE was set at the time of the write
C6	A DATA read returns the last value written to data_reg, not COUNT
C7	A COUNT read returns the internal counter; COUNT is read-only
C8	irq asserts the instant COUNT reaches IRQ_THRESHOLD and stays asserted (level, not edge) until COUNT is cleared
C9	IRQ_THRESHOLD is a build-time parameter — a configuration axis, not one fixed number

D — Reset

#	Feature
D1	Every piece of DUT state returns to its defined value when aresetn deasserts
D2	Reset may assert mid-transaction, not only at time zero

Already broader than anything tested so far

Sitting next to this list, a few items already look thin against this project's actual test history — C5's ENABLE-gated increment, for one, given that every CTRL write across this entire project has set ENABLE=1 before a single DATA write ever ran. That's not this chapter's conclusion to draw in full — chapter 3 runs every item on this list through a systematic scenario check and compares the result against what Coverage's tooling already found. What matters here is narrower and more mechanical: the list itself has to exist, complete and specific, before anyone can ask which parts of it were actually tested.

Summary

• A feature list is a decomposition of the specification, not a summary of it — "test writes, test reads" hides half a dozen genuinely distinct behaviors inside three words.
• Reading a spec section by section and asking three questions of each one — what must always be true, what's explicitly absent, what interacts with something else — surfaces material a quick read skips.
• Naming an explicit absence (no burst signals, no EXOKAY) isn't busywork; it's what shows a reviewer the gap was considered and excluded on purpose, not forgotten.
• The richest features often live at the seam between two spec sections read in isolation — axil_regfile's ENABLE-gated DATA increment doesn't belong to either register alone.
• axil_regfile's spec decomposes into 23 concrete items across four groups (channels/handshake, responses, register behavior, reset) — a list built from the spec, independent of what any test has actually run.