One story in ten short lessons: each page delivers one artifact, and the next page builds on it. Read them in this order; every bench runs on Verilator 5.048 unless a page says otherwise.
# | Lesson | Path | Delivers | Runnable bench |
|---|---|---|---|---|
1 | Required | Rules R1 to R6, risk ranking, plan rows with done criteria | No | |
2 | Recommended | The controller and a directed bench with one scenario per rule | Yes | |
3 | Required | Policy layers, phases, abstract BFMs, bounded drivers | No | |
4 | Recommended | Proof that drivers and monitor agree before any checker is trusted | Yes | |
5 | Required | Checker ownership per rule, monitor order of work, ID assertion | Not run | |
6 | Recommended | A designless unit test: which checker must fire for each fault | Yes | |
7 | Required | Coverage rows CV1 to CV9, covergroups and cover properties | Not run | |
8 | Recommended | A closure curve over ten seeds and the reading of its holes | Yes | |
9 | Required | The six planted bugs and the complete self-checking bench | Yes | |
10 | Recommended | Which checker caught each bug, escapes, the sign-off review and known gaps | No |
Path says how much of the lesson a first pass needs. Required: the core of the capstone, read it. Recommended: most learners should read it, because it proves the previous page. Optional: reference, specialist or revision material. Pages 1, 3, 5, 7 and 9 tell the story on their own; the even pages are where it is proven by running it.
This capstone verifies a design with the traits that make senior interviews hard: two request ports, reads that come back out of order across IDs, byte-strobed writes, back-pressure on both sides, and a reset that can land in the middle of traffic. The design is small enough to read in one sitting and real enough to hide bugs.
It reuses the patterns from the earlier topics: policy layers and an abstract BFM from Reusable Testbench Architecture, the ID scoreboard and memory model from Checking Out-of-Order Traffic, and the coverage mirror from Coverage Modelling. Lessons 9 and 10 plant six bugs and show which checker catches each one, and when.
port 0 ──req──►┌──────────────────────────┐
port 1 ──req──►│ ooo_memctl #(BUG) │──rsp──► sink (back-pressure)
│ 16-word memory, strobes │
│ 8-entry read table │ in order per {port, id}
│ round-robin on contention│ any order across them
└──────────────────────────┘
policy items ─► abstract BFMs ─► pins ─► monitor ─► scoreboard + memory model
├──► coverage mirror (CV1-CV9)
└──► assertions: fairness, stability, no orphanThe design has a BUG parameter. BUG = 0 is correct; 1 to 6 select an ID swap, a dropped strobe, a lost response after reset, starvation, a duplicate response, and wrong ordering within an ID. Every bench that contains the design passes with BUG = 0 and was run against the planted bugs.
Order is only free across ordering domains. Within one {port, id} the spec promises request order, so each domain gets its own queue and every response is compared with the head of its queue. Searching for a match anywhere would accept a within-ID swap, which is one of the planted bugs.