First silicon arrives once. The day it does, the lab can see a handful of pins and whatever the boot ROM prints (on NanoSoC v1 that is the banner and nothing else), and the ROM cannot be changed. Everything that would have made that day productive has to exist months earlier: a timeline of what the pins should do, a way in when the CPU is stuck, a test plan in an order that isolates faults, a bench that matches the board (two supply rails, the pad pulls), and evidence that each earlier topic of this section actually ran. This topic is the pre-silicon readiness review for NanoSoC. For the bring-up flow itself, the day-zero checklist and the debug of silicon failures, follow the links to the Bring-up and Hardware Debug courses; this topic is the integrator's side of the hand-off. The ten planted bugs and the three pad bugs it uses are listed in the NanoSoC tour.
Lesson | After it you can... |
|---|---|
Write the pin-level timeline of a good boot and check the UART setting against the host. | |
State what the lab can observe on NanoSoC, map a silent pin to a boot stage, and find the gaps. | |
Order the first-day tests, set up the bench, and run a go or no-go review that blocks on open items. |
Suggested order: top to bottom. The timeline first, because every later check is a comparison against it; then what can be observed when the timeline is not met; then the plan, the bench and the checklist that turn the evidence of the whole section into a decision.
It is the first code that runs, it prints the only text the lab sees (the banner), and it is read-only: a flaw in it cannot be patched and may need a mask change. Its content must be verified on RTL, gate-level and a prototype before tape-out.