The first weeks of integration never produce one bug at a time. The CPU hangs, the DMA data is wrong, an interrupt never arrives, a secure copy faults, and the wake sequence loops, and all five symptoms arrive in the same week. The interview question is the triage order: which failure do you chase first, what does each check prove, and when do you stop and suspect the test bench instead of the chip. This lesson runs that storm as a three-day timeline with decision points, using real NanoSoC failure modes throughout.
Day one, the CPU stalls at address zero with address-valid high and no response. Triage rule one says a hang that kills everything goes first. The decision point is the reset order: the CPU was released in the same step as the fabric, so the first fetch entered the clock-domain FIFO while the fabric was still in reset and was lost. Strong answer: check the release sequence first, because a fetch lost in reset explains a silent hang with no error, and the fix is staging the CPU release 8 system clocks plus 2 CPU clocks after the fabric. Weak answer: blame the ROM contents and spend the day dumping memory that was never fetched.
Day two brings two symptoms at once: a DMA copy comes out with bit 0 flipped, and the DMA interrupt never fires although DONE reads 1. The flipped bit with a correct count is an address overlap: the slot select was written for an 8 KB window, so a bridge-register write also hits the DMA key register. The dead interrupt with DONE set and the controller's RAW bit 1 clear is a mis-wired interrupt: the line is wired to spare input 6. The decision point is ordering by silence: the mis-wired interrupt corrupts nothing and waits, while the alias corrupts data through a second path, so the alias is fixed first. Strong answer: prove each with one observation, COUNT right with data wrong means the key changed, RAW bit 6 set means the wire moved. Weak answer: reprogram the DMA five ways hoping the symptom moves.
Day three adds the secure fault and the wake loop. A copy from SRAM1 faults every first beat while CPU reads work: the bridge issues non-secure because its NS bit resets to 1, and SRAM1 is secure-only. The fix is for secure software to clear that bit before the copy, and a strong answer adds the catch: the bridge's register slot is non-secure, so non-secure software can clear the bit too, which means the secure partition is not closed until that bit is writable from the secure side only. The wake loop, spuriously high CPU interrupt from the moment switchable power drops, is missing isolation on the two interrupt lines: 112 of 114 clamps present. The decision point is mechanism over coincidence: two new symptoms on the same day still get separate root causes, and the isolation audit (list every cross-domain net, count 114) is the check that ends the loop. Strong answer: the fault names the attribute, the loop names the missing clamps, and both fixes ship with the audit that would have caught them. Weak answer: one grand theory, usually power supply noise, explaining all five symptoms and fixing none.
# not-run: the triage order as a decision table, NanoSoC teaching values
1. Hang with no error -> check release order (CPU last: 8 T_sys + 2 T_cpu). Kills all.
2. Wrong data, count right -> check alias/key path (slot decode, 8-bit port). Corrupts silently.
3. Secure fault, first beat -> check AxPROT/NS attribute end to end. Blocks a feature.
4. Dead interrupt, DONE set -> check wiring table (RAW bit vs expected input). Waits safely.
5. Wake loop with X in gate-level sim -> audit isolation (114 clamps, 2 missing). Loops loudly.
Rule: lethal first, silent corruption second, blocked features third, waits last.The triage order is stated as a rule before the symptoms: lethal, silently corrupting, blocking, waiting.
Each diagnosis cites one distinguishing observation, not a reprogramming campaign.
Each fix ships with the audit that would have caught it: reset-order assertion, lint on port widths, IRQ table check, attribute matrix, isolation count.
Rehearse the storm as narration: five minutes per day, decision point stated before the answer. The checks that prove each diagnosis are the connectivity test forcing each interrupt and watching its RAW bit, the elaboration-time overlap check on base and size pairs, the directed non-secure access expecting SLVERR, and the power-aware simulation showing X where clamps are missing. A narrated storm that never names a check is a story, and stories score 2 on Evidence.
Because the alias corrupts data silently through a second path while the mis-wired interrupt only waits: DONE still reads 1, so polling works around it. Silent corruption always outranks a waitable nuisance.