Every address a program touches is a promise the hardware must keep: this range holds memory, that range holds registers, anything else is an error. The address map is that promise written down, and the decode logic is the hardware that keeps it, cycle by cycle. On NanoSoC the map fits on one table — a 16 KB boot ROM, two 64 KB SRAMs, seven peripheral slots and four holes — but it already contains every classic integration problem: windows that must be power-of-two sized and aligned, a DMA whose 8-bit address port repeats sixteen times inside its 4 KB slot, three regions where nothing answers, and one reserved hole where the wrong kind of nothing answers. This section teaches the map as an integrator owns it: as a contract with software that has to be checked by a script, generated into RTL and headers from one source, and defended at integration review.
Topic | What it covers | After it you can... |
|---|---|---|
Regions, attributes, alignment, holes, aliases and growth planning on the NanoSoC map | Read the NanoSoC map table, justify every base and size, and run the overlap and alignment checker. | |
Decode equations, two-level decode, generating decode from a map table, decode timing | Write the NanoSoC decode from the map table, generate matching RTL and headers, and cost a pipelined select. | |
DECERR versus SLVERR versus PSLVERR, default-slave design, and debugging hangs and mismatches | Predict the exact response for any NanoSoC address, design a default slave that cannot hang, and localise a decode bug. | |
Register block design, specification checking, banking across blocks and the classic register bugs | Design a register block, check its specification with a script, and avoid W1C and busy-write traps. | |
Secure versus non-secure regions, where the filters live, and testing the access-control matrix | State who may touch what, place both NanoSoC filters, and prove the test matrix complete. | |
Generated headers, access rules for drivers, and the errata process | Ship headers software can trust, state the driver rules, and record a bug as an erratum. | |
Standard component descriptions and generating the top level from one source | Describe a block once and generate wiring, decode and headers that agree. | |
Sweeps, reset and access-type checks, alias probing, and regression hooks | Verify the map against its model and freeze the planted bugs into permanent tests. |
Suggested order: top to bottom. Design the map first, because decode is just the map turned into gates; then implement the decode, because the error policy only makes sense once you know which decoder answers each hole; then the errors and responders. Register maps, security regions and the software contract follow, because each reads the map at a finer grain; automated assembly and verification close the section by generating and then proving the whole thing. Readers who already own a map can start at the second topic, and readers chasing a specific hang can start at the third and follow the links back. For the generic theory behind maps and decoding see Address Maps and Decoding; for the block-level decoder view see Address Decode.
Because software is built against it: link addresses, driver base pointers and headers all assume it. Changing the map after software exists breaks that build, so the map constrains both sides and has an owner and a version.