The pipeline works. It forwards, stalls and flushes, and it ran our test program perfectly. So: ship it? Not even close. "It ran my program" is to verification what "it compiled" is to software — a pulse, not a diagnosis. A CPU's state space is astronomical, its nastiest bugs live in the interactions (a forwarding path times a stall times an x0 corner), and a wrong CPU doesn't crash — it computes confidently incorrect numbers. This final lesson brings the whole verification arsenal — testbench discipline, constrained randomness, coverage, assertions — home to the machine we just built. CPUs, it turns out, have a superpower here: a CPU can run programs, so a CPU can test itself.

Self-checking programs

The cheapest tester is the device under test. Write a program that computes something, compares against the known answer using the CPU's own branch instruction, and steers to a pass or fail address. This is exactly how the official riscv-tests suite works — hundreds of tiny assembly programs, one per instruction behaviour, each ending in a self-grade:

The testbench only watches the pc: parked at fail means a bug; reaching the final store means all cases passed. Elegant — and subtly circular. The test uses ADDI, BEQ and JAL to grade ADD; if the graders themselves are broken, a test can "pass" for the wrong reason (a broken-everything CPU that never branches to fail looks suspiciously green). Self-checking programs are a superb smoke test and a lousy foundation — we need a referee standing outside the machine.

The golden model: co-simulation in lockstep

Here is the move that anchors real CPU verification — and the payoff of this module's oldest investment. Back in lesson 36 we wrote a single-cycle functional model: {pc, regs, mem} and a next(). That model is an instruction-set simulator (ISS) — an executable copy of the contract, so simple it is obviously right. Now run it in lockstep with the pipelined RTL: every time the pipeline retires an instruction from WB, let the ISS execute one instruction too, and compare architectural state — pc retired, every register. The instant they disagree you have not just "a bug somewhere" but the exact pc, register and cycle of first divergence. The complex machine is graded, retirement by retirement, by the simple one — which is why the single-cycle CPU was never a throwaway: slow-but-obvious is precisely what a referee should be.

Random programs, measured coverage

Lockstep comparison answers "is this run correct?" — but who supplies the runs? Hand-written tests exercise the hazards you already understand; the bug is, by definition, in one you don't. So generate programs randomly under constraints (the constrained-random idea, industrialised for CPUs by tools like riscv-dv): initialise every register first, keep load/store addresses in the legal range, then spray instructions with random destinations and sources. Dependent pairs, load-use chains, x0 destinations, the same register produced twice in a row — corner cases fall out of the generator at a rate no human matches. Random stimulus is only half the contract, though; the other half is measuring what you actually hit: bins for every instruction, every hazard distance (producer–consumer gap of 1, 2, 3), every forwarding path taken, every stall and flush — and the crosses that matter, like "load-use stall whose consumer also needs an EX/MEM forward on its other operand". Empty bin, missing test — regardless of how many millions of instructions happened to retire green.

The last layer sits inside the design: assertions that watch invariants on every cycle of every run, hand-written or random:

That first assertion is our old friend from the register-file lesson — the x0 invariant, now standing guard permanently. When a random program trips it, the failure fires at the violating cycle, not thousands of instructions later when the corruption surfaces.

The whole rig, running — and catching a planted bug

Everything above, in one executable: the lesson-36 model as ISS, the lesson-39 pipeline as the design under test, a constrained-random program generator, and a lockstep comparator. Then the experiment that makes it real: we inject the classic forwarding bug — dropping the rd != x0 qualification — and let the co-sim hunt it down:

Read the verdicts. The correct pipeline: 21 retirements, state matched at every one. The buggy pipeline runs the same program and diverges at pc = 68 — an addi x7, x0, 27 that should produce 27 produced 43, because the lw x0 one slot earlier (a load that discards its result into x0) was wrongly forwarded into the x0 read. Notice how much the report hands you: the pc, the register, both values — and the culprit sitting one instruction upstream. That is what "divergence = bug + exact location" means in practice. Try it yourself: change the seed, lengthen the program, or invent your own bug (break the EX/MEM priority, or forward from stores) and watch the referee catch it.

And with that, the project arc closes: a contract (lesson 34), a register file, a single-cycle machine that became our referee, a control unit, a pipeline, its hazards healed — and a verification rig that lets you change any of it and know, within seconds, whether the machine still honours the contract. That loop — edit, run, referee — is chip design in miniature.