Risk-Based Prioritization: What to Write First

Ch3 ran axil_regfile's feature list through four categories and came out with a real, prioritized-looking list of open scenarios — except it isn't prioritized at all yet. It's just a list, in whatever order the categories happened to be presented. A schedule is never long enough to write every scenario at once, and working the list top to bottom, in the order it was generated, is not a plan — it's an accident wearing a plan's clothes. This chapter is the judgment call that turns the list into a sequence.

Two axes, not one

Risk is likelihood times impact, and it's worth keeping the two apart rather than reaching for a single gut feeling of "this seems important":

• Likelihood — how probable is it that a real bug is sitting in this area, undetected. Informed by how structurally delicate the logic involved actually is, whether this specific area has already produced a known bug (the single strongest signal available, when it exists), and whether the scenario belongs to a category with a track record of hiding bugs — independent/concurrent handshake logic and reset/recovery paths are both well-known for this across real verification projects, not just this one.
• Impact — how bad it is if a bug in this area slips through undetected. Informed by blast radius (shared bus infrastructure a bug can affect versus one register's private, contained behavior), whether the scenario touches the DUT's core stated contract or a peripheral detail, and how easy the failure would be to notice if it did happen — a loud, obvious failure is less dangerous than a quiet, plausible-looking wrong answer.

Neither axis is the same thing as how cheap a scenario is to write — that distinction matters enough to come back to at the end of this chapter.

Scoring the real open gaps

Every row below is one of ch3's actual findings, not an invented example:

Scenario	Likelihood	Impact	Why
AW/W arrive on different cycles	High	High	This exact RTL region already produced a real, shipped bug: the combinational-loop issue uvm-advanced ch1 found and fixed lived in the same AW/W latch logic. The specific case that logic exists to handle — arrival on different cycles — has never been exercised even once, so there's zero empirical confidence in it, on top of a region already known to be delicate. A bug here sits in shared write-path infrastructure, not one register's private behavior.
A7: new AW/W while a B response is outstanding	Medium-High	High	Delicate registered-state logic in the same general write-path region, though structurally simpler than the AW/W latch itself. If broken, a master's transaction could be silently dropped or corrupted under backpressure — the same shared-infrastructure blast radius as the row above.
D2: reset mid-transaction	Low-Medium	High	The reset block itself is the least structurally delicate logic on this list — one if (!aresetn). But a broken recovery path can wedge the bus, and since AXI is shared infrastructure, that can hang everything else on the interconnect, not just this peripheral. Reset-recovery bugs are also a well-known category for being missed, for the exact reason this project's own tests show: reset gets asserted once, at time zero, out of habit, and never revisited.
DATA write while ENABLE=0	Low	Medium-High	The RTL is one plain conditional (if (ctrl_enable) count_reg <= count_reg + 1;), about as structurally simple as this DUT gets. But ENABLE gating the counter is this peripheral's entire stated purpose — a silent violation here would undermine every downstream assumption about when irq can and can't assert.
Write to STATUS/COUNT/an unmapped address	Medium	Low-Medium	Mechanical case-statement logic with three distinct arms, each independently capable of being wrong. A wrong response code is visible, though — software is meant to see and react to SLVERR/DECERR, so a bug here doesn't hide quietly the way a silently-wrong counter would.
Reading CTRL back	Low	Low	About as simple as RTL behavior gets in this DUT, and contained to one register's readback — the kind of bug that would almost certainly surface the first time anyone tried to read CTRL back for any reason, not just this scenario.

No row above uses a manufactured numeric score, on purpose — a 1-5 scale multiplied out to a tidy priority number looks more rigorous than a plain High/Medium/Low table, but it isn't; it just hides the same judgment call behind false precision. The reasoning in the "why" column is the actual argument. The label is a summary of it, not a substitute for it.

What this changes, practically

Ranked by risk alone, the order is: AW/W independence, then A7's backpressure scenario, then reset-mid-transaction, then the ENABLE-gated DATA write, then the illegal-address writes, then CTRL readback last. That's a real ordering, and it's not the same one Coverage ch6 reached from a completely different angle — cost to close.

Coverage ch6 already established the cost side of this exact set of gaps: the STATUS/COUNT/unmapped-address writes close with four lines of directed test, no new infrastructure. The AW/W-independence gap and A7's backpressure scenario both need new sequence or driver capability that doesn't exist yet — genuinely more expensive to close, not just lower on a to-do list. Risk-order and cost-order disagree here, on purpose, and a real schedule has to hold both at once rather than picking one and ignoring the other.

The resolution isn't "risk wins" or "cost wins" — it's sequencing by lead time as well as by risk. The AW/W-independence work is both the highest-risk item on the list and the one with the longest runway before it can produce a passing test, since the driver capability has to exist first. Starting it early, even though it won't be the first thing to show a green result, is what keeps it from still being open when the schedule runs out — a genuinely common failure mode, where the riskiest item gets pushed to "later" precisely because it's the most expensive one to start, and later never quite arrives. The cheap, lower-risk items — STATUS/COUNT/unmapped writes, the ENABLE-gated DATA write — get written in parallel, not instead: real, quick risk reduction that doesn't wait on anything else finishing first.

Summary

• Risk is likelihood times impact, evaluated separately — a scenario can be low-likelihood and still high-priority if the impact of missing it is severe, and vice versa.
• The strongest evidence for likelihood, when it exists, is a real bug this exact area of the design already produced — axil_regfile's AW/W latch logic has one, from uvm-advanced ch1, which is why the still-untested case in that same logic ranks highest here.
• Impact scales with blast radius: a bug in shared bus-handshake infrastructure can affect more than the peripheral it lives in, which is why reset-mid-transaction ranks high on impact despite comparatively simple, low-likelihood RTL.
• A manufactured numeric score isn't more rigorous than a well-reasoned High/Medium/Low table — it just hides the same judgment behind false precision.
• Risk-order and cost-to-close order can disagree, and both matter: the highest-risk item here is also the most expensive to close, which argues for starting it earliest, in parallel with the cheap wins, rather than picking one ordering and ignoring the other.