SRAM1 holds the material worth protecting on NanoSoC, and the reset controller can restart or power down the whole chip. If either answers the wrong caller, the failure is not corruption but disclosure or control. The map's Secure column is where that protection is specified, and like every other column it is only real if hardware enforces it and tests prove it. This lesson reads the column as a promise with named enforcers.
Every AXI address carries a protection sideband; on NanoSoC one bit of it separates the two worlds, with AxPROT bit 1 equal to zero meaning secure and one meaning non-secure. The map assigns each region to a column: the ROM, SRAM0 and every peripheral except the reset controller admit either state, while SRAM1 and the RSTPWR slot admit secure only. Privilege is the second classic attribute, privileged versus user, and NanoSoC is a useful honesty check here: the hardware wires and enforces security state only. No NanoSoC block receives a privilege signal, the APB has no protection port at all, so a privilege column in this map would be decoration. Record the attribute a design actually enforces, and treat any unenforced column as a finding.
Region | Secure-only? | Enforced by | Non-secure result |
|---|---|---|---|
BOOTROM | No | n/a | Reads normally. |
SRAM0 | No | n/a | Reads and writes normally. |
SRAM1 | Yes | Interconnect filter on AxPROT[1] | SLVERR, no data, from the fault responder. |
DMA and SBR slots | No | n/a | Registers accessible. |
UART, SPI, GPIO, INTC slots | No | n/a | Registers accessible. |
RSTPWR slot | Yes | Slot decoder per-slot check | SLVERR via PSLVERR. |
Holes H1, H2, H4 | n/a | Interconnect default slave | DECERR in either state. |
Hole H3 | n/a | APB default slave | SLVERR via PSLVERR in either state. |
Two consequences follow from the table. First, the response code separates existence from permission, as the error topic established: a hole answers DECERR in either state, and a mapped-but-forbidden region answers SLVERR rather than pretending not to exist. The two cases are distinguishable by code, deliberately; the codes describe what happened, not what to hide. Second, masters have security states too, not just slaves: the CPU issues secure accesses in its secure software, while the stream bridge issues accesses with the state its CTRL NS bit selects, so the same destination can be reachable for one master and forbidden for another. The next lesson places both checks and shows what happens when that bit resets the wrong way.
The map's security column names an enforcer for every secure-only row; an unenforced row is a review finding.
Every master's security state is documented, including how it is selected and what it resets to.
Privilege claims, if any, name the signal that carries them; on NanoSoC there is none and the table says so.
From non-secure software, read one word in each secure-only region and confirm SLVERR with no data returned; repeat from secure software and confirm data. Then check a hole from both states and confirm the same DECERR twice. If a secure-only region answers non-secure software with data, the filter is missing or wired to the wrong select; if it answers DECERR, the fault is being routed to the default slave instead of the fault responder, which is the inconsistency the decode topic was written to prevent.
RSTPWR sits behind the APB bridge, where refusals are raised as PSLVERR and converted by the bridge into AXI SLVERR. SRAM1 sits on the AXI side, where the fault responder answers SLVERR directly.