Two 64 KB SRAMs hold the whole NanoSoC software world, yet neither the CPU nor the DMA ever touches a memory macro directly: each macro sits behind a wrapper, shares its test engine with the other bank, and carries repair and retention wiring the integrator must get right. This topic builds that subsystem: how to choose between a compiled macro and a fixed one, what the wrapper owns, and how test, repair and power control are shared without tangling the banks together. For the coding style that infers these memories see SRAM and ROM; for how macros are mapped at synthesis see Memory and Macro Inference.
Lesson | After it you can... |
|---|---|
Pick a compiler or a fixed macro and write the wrapper checks that catch a mismatch. | |
Share one test controller across both banks and budget test time and repair fuses. | |
Keep SRAM0 alive through sleep and prove the wake path returns its contents. |
Suggested order: top to bottom. Choose the macros and wrap them first, because test and power both attach to the wrapper boundary; then share the test engine; then keep one bank alive while the other sleeps. The error-coding topic next door assumes these wrappers exist and adds protection inside them.
Because the macro's port polarity, latency, byte enables, test ports and repair inputs differ from the fabric convention. The wrapper absorbs all of that so the macro can be swapped without touching the interconnect.