Block tests prove each block works; only chip-level tests prove the blocks work together. The DMA passes its bench while wired to nothing, yet on NanoSoC its interrupt reaches the wrong controller input, its address port drops four bits, and its clock can be gated mid-access. Each of those passes its own block's bench, shows only when the blocks run together, and hangs real software. The ten planted bugs are listed in the NanoSoC tour and met again in the capstone. This section is the integrator's view of proving the whole chip: which tests exist only at the top, how many of each to run, what firmware runs in simulation and what it logs, how bandwidth and latency are measured against budgets, what gate-level and power-aware simulation add, when to move to emulation or an FPGA prototype, and what must be ready before first silicon. For the general theory of verification levels and reuse see the verification-first-principles course; this section teaches the concrete NanoSoC instance of every idea.
Topic | What it covers | After it you can... |
|---|---|---|
Levels, what only the chip can show, the top-level test list, reuse and regression | Place every test at its cheapest level and argue the top-level list is complete. | |
Register sweeps, address-map and interrupt wiring checks, reset and clock sanity; which planted bugs each catches | Write the connectivity checks that catch the NanoSoC wiring bugs before software does. | |
Running boot code against RTL, bench checkpoints and the ROM self-test, cost, speed and logging | Boot NanoSoC in simulation, read its bench checkpoints, and price the run. | |
Checking the bandwidth and latency table with traffic and counters; reading a miss | Prove the fabric meets its budgets or name the bottleneck with numbers. | |
What each finds, X-propagation, isolation and retention checks, reset-order bugs, cost | Say what gate-level and power-aware runs add over RTL and run the isolation checks. | |
Why and when to leave simulation, what changes in the design, speed against visibility | Decide what moves to a fast platform and what the move costs in fidelity. | |
What must exist before first silicon: boot path, debug access, test plan, lab setup, checklist | Run the readiness review and refuse to tape out with a gap in it. |
Suggested order: top to bottom. Strategy first, because it assigns every later test to its level; then connectivity, the cheapest tests, which catch the wiring, map, reset and power-intent bugs before software runs; then firmware, which exercises the connected chip as software sees it. Performance follows, because it needs the working boot path; gate-level and power-aware simulation sit beside it as the two expensive lenses used sparingly. Emulation and prototyping come after, as the answer when simulation is too slow; readiness closes the section, because its checklist consumes the evidence all the earlier topics produce.
Can a lower level show it — if yes, move it down — and does it cross an integration boundary (decode, crossing, power, software) that exists only at the top?