Why it matters

On the first day of NanoSoC bring-up, the ROM sets the stack pointer to 0x2001_0000 and jumps to 0x2000_0000. Both numbers are bets: the first bets that SRAM0 ends exactly where SRAM1 begins, the second bets that SRAM0 contains the loaded image and not a hole that answers with an error. Every driver makes the same kind of bet every time it touches a base address. The address map is where those bets are written down, and when it is wrong the symptom is never a polite message: the CPU fetches an error response from what the linker thought was memory, or a control write lands in a different block's register.

The core idea

A map is a short list of regions, and each region carries five promises. The base and size say which addresses belong to it. Access says what software may do: read-only, read-write, execute or no-execute. Cacheable says whether a cache may hold a copy; on NanoSoC only the instruction cache exists, so this attribute is really about the instruction side. Secure says which security state may enter; SRAM1 and the reset controller admit secure accesses only. Ordering says how strongly accesses are held in order: normal memory may be buffered and merged, while peripheral registers are device-type in the CPU memory attributes, meaning non-cacheable and non-bufferable, so two accesses to the device complete in program order.

The NanoSoC map is the worked example for the whole section, quoted exactly from the design specification:

Two details in that table do real work later. The stack top of 0x2001_0000 is one past the end of SRAM0, which is exactly the base of SRAM1: push the first word and it lands in the last word of SRAM0. And the peripheral window holds seven 4 KB slots out of sixteen, leaving slots 7 to 15, the 36 KB hole H3, for later peripherals without moving a single existing base.

Who owns the map and what changes it

The integrator owns the map, and ownership means three duties: every consumer derives from one source, every change is versioned, and no region moves once software depends on it. The consumers are the linker script that places code and data, the C headers that name the register bases, the decode logic in the interconnect, the verification memory model that decides which addresses are legal, and the documentation table. When these are generated from one map table they cannot disagree; when they are copied by hand they eventually do, and a register specification that has drifted from the RTL is the classic result, caught by a model-versus-RTL check and fixed by a single machine-readable source.

Three things legitimately change a map: a new peripheral that takes a reserved slot, a memory that outgrows its window, and a security review that re-partitions a region. All three are covered in the growth lesson of this topic. Anything else, a shifted base to make room or a resized window for convenience, breaks every consumer at once and is how a mature project learns to say no.

What the review looks for

• Every row has all five promises filled in: no region with a blank access, cacheable, secure or ordering column.

• Each consumer names the map version it was generated from, and all versions match.

• The reset vector, the stack top and the first fetch address each point at a mapped region with the right attributes.

Verify and debug

Read the map against the specification with a script, not by eye: the alignment and overlap checker in the next lesson exists for exactly this. Then check the three addresses the chip cannot boot without: the reset vector at 0x0000_0000 must be readable and executable, the stack top at 0x2001_0000 must be writable memory, and the image base at 0x2000_0000 must be the memory the loader filled. If any consumer disagrees about one of those, the map source wins and the consumer is regenerated.

Related topics

• Next: Sizes, Alignment and Power-of-Two Windows

• Implementing Address Decode

• Protocol First Principles: Address Maps and Decoding

• RTL: CSR Contract and Address Map