Software never sees the chip; it sees a header file, a linker script and a document, and it trusts all three completely. Making that trust safe is an integration deliverable in its own right: somebody has to own the hardware-software contract review, the driver bring-up order and the errata process, and on most projects that somebody is the integrator. This topic covers the software face of the NanoSoC map: headers generated from the same table as the decode, the rules for touching device memory that keep ordering honest, and how a hardware bug becomes a numbered erratum with a software workaround instead of folklore. For the driver-writing view see The Firmware Side: a C Driver and Generated Register Workflow.
Lesson | After it you can... |
|---|---|
Ship headers and documentation that cannot disagree with the decode. | |
State the rules every NanoSoC driver obeys when touching registers. | |
Record a hardware bug as an erratum with a workaround software can apply. |
Suggested order: top to bottom. Generate first, because the access rules quote the headers; then the rules; then what happens when the hardware breaks its own contract.
From the generated header, which is emitted from the same map table as the decode logic. The proof is the generation check: header and decode rebuilt from one table and asserted to agree.