Silicon comes back with bugs. The difference between a respin and a shipped product is often a software workaround, and the difference between a workaround and folklore is whether it is written down where driver authors will find it, against the map version it applies to. Errata handling is part of the hardware-software contract; this lesson defines the smallest honest process.
An erratum entry has six fields: an identifier, the symptom as software observes it, the root cause in hardware terms, the silicon revisions affected, the workaround stated as a driver rule, and the verification that proves the workaround. The lifecycle matters as much as the fields: an entry is opened when a bug is confirmed, the workaround is reviewed like code, the entry is closed only when fixed silicon is verified or the workaround becomes permanent documentation. Workarounds are recorded against the map and register specification versions, because a workaround for one revision applied blindly to another is how fixed hardware acquires phantom restrictions.
Three of NanoSoC's documented DMA behaviours are usage restrictions, recorded in the table below. A fourth entry shows the genuine erratum shape for contrast: a true silicon deviation, the 8 KB decode window found in the verification topic, where an early revision's DMA select covered two slots. Note the difference in kind: restrictions describe hardware working as specified but surprising every driver, while an erratum describes hardware deviating from its specification, and only the erratum can be closed by a silicon fix. The DMA's silent-write behaviour becomes: symptom, a reprogrammed job runs with stale LEN or KEY and no error; cause, writes ignored while BUSY by design; workaround, poll BUSY to zero before touching LEN or KEY. The sticky-ERR behaviour becomes: symptom, the interrupt never drops after a failed job followed by a good one; cause, GO clears DONE but not ERR; workaround, clear both bits by writing 0x6 to STATUS after every job. The CTRL behaviour becomes: symptom, the completion interrupt never arrives; cause, every CTRL write stores bit 1 into IRQ_EN, so writing 0x1 disarms it; workaround, always write 0x3 to start with the interrupt enabled. Note that all three are specified behaviours rather than silicon defects; the recording discipline treats them identically, because from the driver's seat a surprising specification and a bug feel exactly the same.
Usage restrictions and known traps (hardware working as specified):
Entry | Symptom | Driver rule (workaround) |
|---|---|---|
NSC-001 busy-ignored writes | New LEN or KEY has no effect, no error | Wait for BUSY = 0 before writing LEN or KEY |
NSC-002 sticky ERR | Interrupt stuck after a failed then good job | Write 0x6 to STATUS after every job |
NSC-003 CTRL stores IRQ_EN | No completion interrupt after starting | Write 0x3 to CTRL (IRQ_EN set) to start |
A genuine erratum, by contrast, deviates from the specification. Illustrative example in the same format: ERR-104, 8 KB DMA decode window, revisions A only. Symptom: after any SBR CTRL write, DMA output data has bit 0 flipped with COUNT correct. Cause: the DMA slot select covered slots 0 and 1, so the SBR write also wrote DMA KEY with value 1. Workaround: none safe in software on revision A; avoid combined SBR and DMA use, fixed in revision B by decoding addr[15:12]. Verification: the cross-talk regression test of the verification topic fails on revision A samples and passes on revision B. Only this kind of entry closes with a silicon fix; the three restrictions above are permanent documentation.
Every confirmed hardware bug has an entry with all six fields before the next software release, not after it.
Workarounds are stated as testable driver rules and linked from the register documentation the driver author reads.
Entries name affected revisions and the map version; a workaround that outlives its silicon is reviewed, not inherited silently.
Each workaround gets a test that fails without it: start a job with CTRL written as 0x1 and watch the interrupt never fire, then apply the rule and watch it arrive. A workaround without such a test decays into superstition within two releases. Keep the errata list versioned with the map, so a software build can state exactly which entries it implements.
Because the contract is what software experiences, not what the specification intended. A behaviour that reliably surprises every driver author belongs in the recorded list with a rule. They are filed as usage restrictions rather than errata, because only a deviation from the specification is an erratum and only an erratum can close with a silicon fix.