A bit flips in SRAM1 and nothing notices until the wrong byte reaches the DMA output. Whether that day ends in a corrected statistic, a trapped exception or silent corruption was decided months earlier, when the integrator chose parity or ECC for each memory and wired each error signal somewhere software can see. This topic makes those two decisions on the NanoSoC banks: which code protects which memory, where each error goes, and how often idle words get swept for decay. NanoSoC itself ships without ECC, so every code width here is a labelled NanoSoC teaching value applied to the real banks. For the code mathematics see SECDED Encode and Syndrome; for when a code is worth its area see Failure Model and Protection Choice.
Lesson | After it you can... |
|---|---|
Choose parity, SECDED or no code per memory and price the check bits. | |
Wire correctable and uncorrectable errors to interrupts and the fabric response. | |
Budget a scrub rate and initialise every protected word before it is read. |
Suggested order: top to bottom. Choose the code first, because the reporting paths depend on what the code can detect; then wire the reports; then keep the protected words healthy with scrubbing and disciplined first access. The external-controller topic reuses the same reporting pattern for DRAM errors.
Because ROM is never written, SRAM0 holds the retained image, and SRAM1 holds DMA working data: their upset rates, write patterns and failure costs differ, so one code everywhere either wastes check bits or under-protects the image.