The chip wakes with nothing but a reset vector and a small read-only memory, and from that it must reach a running image without trusting anything it has not verified. This section follows that path on NanoSoC: the SRAM and ROM macros the integrator wraps and shares test hardware across, the error coding that decides what a bad bit costs, the external memory controller the integrator would wire if the chip outgrew its banks, the boot ROM flow measured to the microsecond, the one-time-programmable fuses that carry trim and keys, the chain of trust that authenticates the first image, and the security partition that keeps secrets away from non-secure software. Every timing and address in these lessons comes from the NanoSoC reference table; anything the table does not define is labelled as a NanoSoC teaching value.
Topic | What it covers | After it you can... |
|---|---|---|
Memory compilers versus macros, wrappers, single-port banking, shared test and repair of the NanoSoC SRAM banks | Choose a macro or a compiler, write the wrapper checks, and plan shared MBIST and repair. | |
Parity versus ECC, error reporting paths to the CPU, scrubbing, what the interconnect returns on a bad access | Pick a protection code, wire its error signals to software, and budget a scrub rate. | |
Clocks, resets, calibration, address mapping and ordering for an external memory controller | List what an integrator wires and budgets for a controller, and say who owns initialisation. | |
Reset vector, boot-source select, and the NanoSoC boot flow with cycle counts and times | Walk the NanoSoC boot from reset release to the jump to SRAM0 and say where every microsecond goes. | |
Trim, boot configuration, keys and lifecycle storage, read-out timing and integration risks | Allocate fuse fields, sequence their read-out before first use, and name the integration risks. | |
Chain of trust, immutable ROM, and image authentication at a conceptual level | Describe what hardware must provide for secure boot, without any crypto parameters. | |
Secure and non-secure partition with the AxPROT filter, lifecycle states, debug locking, and the integrator checklist | Enforce the NanoSoC partition, manage lifecycle states, and check a design for the classic escapes. |
Suggested order: top to bottom. Memories first, because boot and security both assume the banks work; then error handling, which decides what a failing memory costs; then the external controller as the growth path; then the boot ROM flow, which uses everything so far; then fuses, which the boot flow reads; then secure boot, which authenticates the image; and finally the security architecture, which gathers every mechanism into one partition the integrator must defend. Readers chasing a hang can start at the boot topic, and readers answering an interview question on trust can start at the last two topics and follow the links back. For the generic ECC theory behind the second topic see ECC and SECDED; for the DRAM mechanism behind the third see SoC Integration, Verification and Bring-up.
Because the boot image lives in SRAM0, the boot code lives in ROM, the keys live in fuses, and every one of those memories has a wrapper, a test strategy and an error policy. Until the memories are integrated, there is nothing to boot from and nothing to trust.