A tape-out is a one-way door and a bring-up with no plan loses days to avoidable order mistakes, such as probing the clock before checking the supply. The review that precedes both has to turn the evidence of this whole section into a decision; the general tape-out review is taught in the chip-signoff section, and this checklist keeps only the NanoSoC-specific items. Its one job is that decision: the order of the first tests, the bench they run on, and a checklist with one rule, that any open blocking item means no-go.
The first-day plan is the boot timeline run in order, one stage at a time, with the earlier stage proved before the next is trusted: supplies and the open-pin levels first, then reset, then the crystal and the clk_per toggle, then the UART banner, then the SPI load, then the loaded image. It reuses the pre-silicon tests: the reset-order, register-sweep and boot tests of this section are the same programs the lab runs from the loaded image, with the same names, so a failure on silicon reproduces in simulation by running the same test. The bench is the board for the pins the chip has: a 24 MHz crystal, the reset pin, a UART adapter set to the rate with its error known, an SPI flash holding the 8,192-byte image and its checksum (read with a 4-byte command, 8,196 bytes on the wire), two supplies each with its own current limit, and probes on reset, UART TX, SPI clock and chip-select.
The two rails are part of the bench. NanoSoC has vdd_core (0.9 V, which feeds the always-on domain directly and the switchable domain through the on-die header switch; there is no separate always-on supply pad) and vdd_io (the pad-cell supply, an illustrative 1.8 V). The expected RUN current on vdd_core is 82.74 mW / 0.9 V = 91.93 mA, with an illustrative peak of 183.87 mA (peak factor 2.0), so the core current limit is set above the peak and a power-up current near the limit means a short or a floating input, not a slow chip. The pad cells hold every driver off until the core supply is valid, so with only vdd_io up the pins show the pulls of the reset-state table, which is the first thing the plan checks. The pad pulls and the supplies are exactly the failures that no RTL or gate-level run shows: pad bug P1 (a pull-down on the chip-select pad), pad bug P2 (both vdd_io pairs adjacent, errors only when all 16 GPIO pads switch) and pad bug P3 (RESET_N without a pull-up), so the plan carries a step for each.
The checklist is a table of items, each with the evidence that closes it and a flag for whether it blocks. The rule is mechanical: all blocking items closed means go, any open blocking item means no-go, with the item named. NanoSoC carries two items that are open by construction. The first is the failure behaviour of the boot stages: the boot flow lists only the success steps and defines one failure, the checksum refusing the jump, and says nothing about what happens after the refusal (no print, no GPIO code, no defined loop), so a failed self-test and a hang look the same on the pins. The decision rule is to close it in the ROM content before tape-out, or to accept it in writing with the consequence. The second is the known security weakness: the SBR register slot is non-secure and its NS bit is writable, so non-secure software can make the SBR issue secure accesses and reach SRAM1. The review must keep that item open and blocking until the NS bit is made writable only from the secure side, or move the item to an accepted-risk list with the consequence in the software guide; it must not be quietly closed because the secure-access test passes for the cases tested.
Item | Evidence that closes it | Blocks? |
|---|---|---|
Boot ROM image final and the real image booted in RTL, gate-level and on a prototype | Three runs of the full-length boot with the timeline matched | Yes |
Wake path: RST_CAUSE read first, no SRAM0 clear on WAKE | Directed wake test with a preloaded pattern | Yes |
Reset release order and software-reset scope | Order assertion in every run; gate-level release skew | Yes |
Power sequences and all 114 isolation clamps | Power-aware run: isolate before reset before power-off; 114 of 114 present | Yes |
Defined failure behaviour for every boot stage (only the checksum refusal is defined on v1; nothing is defined after it) | ROM content reviewed; each failure shown on the pins in simulation; or an accepted-risk entry signed in writing | Yes, open on v1 |
Pad ring: every reset pull equals the idle level of its function, RESET_N has its pull-up, one vdd_io pair in each half of the ring (8 and 8 outputs against a limit of 8) | The reset-state check and the per-pair count pass; the pad pulls read correctly on the bench | Yes |
All ten planted bugs have a permanent named regression test | Test list with the bug each one catches | Yes |
Performance budgets checked, same-bank trap in the software guide | Bandwidth and latency table results | No |
Driver rules documented: write 0x3 to start, clear DONE and ERR with 0x6, one LEN variable, wait for BUSY | Software guide section reviewed | Yes |
Security partition: SBR NS bit not writable by non-secure code | Non-secure write to NS followed by an SBR access to SRAM1 must fail | Yes, open on v1 |
Bench built and the pin timeline rehearsed on the prototype | Scope capture matching the timeline | No |
# Go or no-go as a function of the checklist; each item has evidence and a flag.
# NanoSoC teaching values. The rule is mechanical so nobody argues it on the day.
FAIL = "failure behaviour for every boot stage"
SEC = "security: sbr ns not writable by non-secure code"
ITEMS = [
("rom image booted on rtl, gate-level, prototype", True, True),
("wake path directed test", True, True),
("reset order and sw reset scope", True, True),
("power sequences and 114 clamps", True, True),
(FAIL, False, True), # open on v1: only the checksum refusal is defined
("ten planted-bug regression tests", True, True),
("driver rules documented", True, True),
("pad ring: pulls, reset pull-up, vdd_io pairs", True, True),
(SEC, False, True), # open on v1
("performance budgets checked", True, False),
("bench rehearsed on prototype", False, False),
]
def decide(items):
blockers = [name for name, closed, blocking in items if blocking and not closed]
return ("GO", []) if not blockers else ("NO-GO", blockers)
def close(items, *names):
return [(n, True if n in names else c, b) for n, c, b in items]
verdict, blockers = decide(ITEMS)
assert verdict == "NO-GO" and blockers == [FAIL, SEC] # two named blockers
# closing one still leaves NO-GO naming the other; an open non-blocking item does not matter
assert decide(close(ITEMS, SEC)) == ("NO-GO", [FAIL])
assert decide(close(ITEMS, FAIL)) == ("NO-GO", [SEC])
closed = close(ITEMS, FAIL, SEC)
assert decide(closed) == ("GO", [])
# the check can fail: reopening a blocking item blocks again
reopened = [(n, False if n.startswith("wake") else c, b) for n, c, b in closed]
assert decide(reopened) == ("NO-GO", ["wake path directed test"])
# an item that is not a blocker cannot stop a release even when open
assert decide([("bench", False, False)]) == ("GO", [])
print(f"{len(ITEMS)} items, {sum(1 for _, _, b in ITEMS if b)} blocking; first verdict {verdict}: {len(blockers)} blockers")
print("PASS: two open blocking items give NO-GO naming both; closing one still blocks; closing both gives GO")Every blocking item has evidence that someone other than its owner has read, with the run identifiers in the checklist.
No item is closed by argument. A test that passes on the cases tested does not close an item whose cause is still in the design.
The first-day plan lists, for each step, the expected pin event, the pad it appears on, the instrument, the time window and what to do when it is missed.
Rehearse before silicon: run the first-day plan on the prototype with the real bench connectors and a scripted reset, and fix every plan step that cannot be followed as written. Rehearse the no-go too: introduce one planted bug in the prototype image and see that the checklist and the pin timeline together name it, because a review that cannot find a known bug will not find an unknown one. After silicon, close the loop: every first-day failure becomes a regression test and a checklist line for the next chip.
No. The test exercises the reset default and never tries the attack: non-secure software writing NS = 0 into the SBR slot and then copying SRAM1. The item closes only when that write is refused or the slot is secure-only, or when the risk is accepted in writing with the consequence in the software guide.