Tape-out is twelve weeks before first silicon. One team spends those weeks relaxing. Another ports its emulation test programs to run from the chip's boot flash, writes scripts to read DCRouter's status and error counters through the debug port, prepares a board with a programmable supply and a temperature chamber, and lists every feature that pre-silicon covered weakly. When the chips arrive, the second team is running tests by lunchtime; the first spends a month getting there.
What would you prepare before first silicon?
The obvious plan waits for silicon and then works out how to test it. By then it is too late to add the one thing silicon debug most needs, visibility, because visibility must be designed into the chip. And every week spent writing test programs and scripts after silicon arrives is a week of the most valuable, most expensive validation time lost.
Area | What to prepare |
|---|---|
Design for debug | Debug access (JTAG, fact V13), trace buffers, performance and event counters, scan dump capability, status registers for hidden state (lesson 3.6) |
Test content | Bare-metal test programs from chip-level verification and emulation (lesson 8.5), ready to boot; stress and soak programs; compliance suites |
Lab infrastructure | Validation boards, programmable supplies, clock sources, temperature control, protocol analysers, scripts to drive it all |
Plan and priorities | What pre-silicon verified weakly or not at all; risk-ranked silicon test plan; who debugs what; the errata process (lesson 11.6) |
Item | Content |
|---|---|
Bring-up checks | Read CTRL reset value, write and read registers, one packet per input, sleep and wake once |
Pre-silicon gaps to target first | F25 low power disabled, F28 reset mid-traffic, F26 throughput (lesson 9.8); counter saturation on ERR_CNT0, 1, 3 |
Test programs carried over | The software-driven DMA-through-router tests (lesson 8.5); a soak test moving data for hours with checksums |
Debug features to use | STATUS lock and sleep bits; ERR_CNT and PKT_CNT; a trace of DCRouter's pins if the SoC provides one; a credit count in STATUS, if the designer added it (lesson 3.6) |
Characterisation | Throughput and error-free operation across voltage, temperature and frequency (lesson 11.5) |
Portable tests: programs written for chip-level simulation and emulation run unchanged on silicon (fact V11).
Expected results: reference models and checksums computed pre-silicon tell silicon tests what correct looks like.
The evidence ledger: what was proved, tested, waived or left open tells validation where to look hardest (Part 14).
The Bug Zoo idea: a list of how this design is likely to fail guides which symptoms to watch for.
Practice | Purpose |
|---|---|
Debug-feature reviews during design | Visibility built in while it is cheap |
Silicon test content developed on emulation | Tests proven before the chip exists |
Bring-up rehearsals on FPGA prototypes | Boards, scripts and procedures debugged early |
A silicon validation plan derived from the verification plan's gaps | Silicon time spent where pre-silicon was weakest |
A team (illustrative) had excellent pre-silicon verification and no debug features beyond JTAG boundary scan. A rare silicon hang in a cache controller could be reproduced only after hours of traffic, and nothing in the chip recorded what the controller had been doing. Root cause took six weeks of experiments. A small trace buffer on the controller's request interface, a few hundred flip-flops, would have shown the last transactions before the hang.
They are the features pre-silicon verification left without evidence or with only partial evidence (lesson 9.8), so silicon is the first chance to test them.
Portable bare-metal test programs and their expected results, if written for the chip's processor rather than a testbench.
First silicon's productivity is decided before tape-out.
Prepare debug features, test content, lab infrastructure and a risk-ranked silicon plan.
Derive the silicon plan from what pre-silicon verification left open.