A chip-level test for DCRouter's SoC is a short C program. It writes DCRouter's CTRL register through the processor's bus, programs two DMA engines to copy buffers through the router to memory, waits for their completion interrupts, and compares the destination buffers with the sources. It finishes in a few seconds of simulated time after hours of wall-clock time. It found, in its first run, that the chip's address map put DCRouter's registers at the wrong base address.
What do chip-level, software-driven tests check that block tests cannot?
The obvious chip-level test reuses block-level stimulus at the chip boundary: drive packets into the chip's pins and check what comes out. Much of the chip is not reachable that way; its blocks are configured and fed by the processor, and the bugs at this level are in the configuration sequences, the address maps, the interrupts and the data flows between blocks. The natural stimulus at chip level is software.
Chip-level tests check | Block tests cannot, because |
|---|---|
Address maps and register access from the processor | Block tests drive registers directly, at the addresses they assume |
Configuration sequences across blocks (order, timing, dependencies) | Each block test configures only its own block |
Data flows end to end (memory to DMA to router to memory) | Neighbours were models |
Interrupts, their routing and their handling | Interrupt controllers and handlers are absent |
Clock, reset and power sequencing across the chip | Block tests have one clock and one reset |
Boot and the first software on the chip | No processor, no firmware |
Test integration, not block corners: one or two data flows per feature, with real configuration; corners stay at block level.
Self-checking in software, visible to the testbench: the program compares results and reports pass or fail through a mailbox or register the testbench reads.
Keep block checkers on: reused monitors and assertions localise failures inside long software runs (lesson 8.3).
Describe test intent once: the Portable Test and Stimulus Standard lets the same scenario target simulation, embedded software, emulation and silicon (fact V11).
Reuse the tests later: the same programs run in emulation (Part 10) and on the first silicon (Part 11).
Practice | Purpose |
|---|---|
Bare-metal C tests for each integration feature | Configuration, data flow and interrupts verified with real software |
A shared test library and hardware abstraction layer | Tests portable from simulation to emulation to silicon |
Chip-level plans listing only cross-block features | Slow cycles spent where only the chip can help (lesson 8.2) |
A team (illustrative) ported hundreds of block-level register tests to C and ran them at chip level, spending weeks of simulation re-checking reset values already proved at block level. The one integration bug that mattered, two blocks sharing an interrupt line that the interrupt controller treated as edge-triggered, was found late because the chip-level budget had gone on the ports. A short interrupt-routing test per block would have found it in the first week.
Block tests write DCRouter's registers directly at the addresses they assume; the base address exists only in the chip's address map.
A failure deep inside a long software run is reported at the router's pins with the broken rule named, instead of as a wrong buffer at the end.
Chip-level tests are often software on the chip's processor: configure, move data, check memory.
They check integration: address maps, configuration sequences, data flows, interrupts, power, boot.
Keep block checkers on, avoid repeating block corners, and reuse the tests in emulation and silicon.