The rubric is abstract until it grades a real answer, so this lesson works one question end to end: route the interrupt sources to the CPU and bound the worst-case latency. It is the classic interrupt-routing question, reduced to NanoSoC scale. The weak answer is what a nervous candidate says; the strong answer is the same content restructured into four parts with numbers. The critique scores both, dimension by dimension.
NanoSoC has six real interrupt sources into an 8-input controller with fixed priority, feeding one CPU input across a clock-domain crossing. Bound the worst-case latency from the DMA interrupt rising to the CPU seeing it, and say what could make an interrupt late or lost. Assume the DMA completion path: the source holds a level until software clears it, the controller runs on the 24 MHz peripheral clock, the CPU on 192 MHz.
The DMA interrupt goes into the controller, the controller tells the CPU, and the CPU handles it. It should be fast, maybe a few cycles. The priority is fixed so DMA at input 1 beats UART. Lost interrupts should not happen if the software is correct. This answer is not wrong anywhere and scores badly everywhere: no numbers, no mechanism, no alternative, no check. Assumption 1, Mechanism 1, Trade-off 0, Evidence 1: total 3 out of 16.
Assumption: DMA interrupt is input 1, second-highest priority, level-held until software clears DONE or ERR, controller on 24 MHz, CPU on 192 MHz, worst case means a higher-priority power interrupt is pending and the synchroniser alignment is worst. Mechanism: the level crosses into the peripheral domain through a two-flop synchroniser (2 slow clocks), the controller registers PENDING and raises its output (1 slow clock), the output crosses into the CPU domain through a two-flop synchroniser (2 fast clocks). Best case is 2 times 41.667 plus 41.667 plus 2 times 5.208, which is 135.4 ns or 26 CPU clocks; worst case adds one slow and one fast clock of alignment, 182.3 ns or 35 CPU clocks. If the power interrupt at input 0 is pending it wins, adding its handler time before the DMA handler runs. Trade-off: a pulse-synchroniser alternative would cross faster but a one-cycle pulse from the 96 MHz domain can be missed by the 24 MHz sampler, a classic lost-interrupt failure; the level plus sticky status costs two slow clocks of synchroniser delay and buys a loss-proof contract. Evidence: force the DMA interrupt with the power interrupt pending and measure output-to-CPU with the cycle counter, then sweep the phase between the 96 and 24 MHz clocks to observe the 135.4 to 182.3 ns window. Total: Assumption 3, Mechanism 4, Trade-off 3, Evidence 3, which is 13 out of 16.
t_per = 1 / 24e6
t_cpu = 1 / 192e6
# Mechanism: 2 slow sync + 1 slow register + 2 fast sync.
best = 2 * t_per + 1 * t_per + 2 * t_cpu
assert abs(best * 1e9 - 135.4) < 0.1, best
assert abs(best / t_cpu - 26) < 0.1, best / t_cpu
# Worst case adds one slow and one fast clock of alignment.
worst = best + t_per + t_cpu
assert abs(worst * 1e9 - 182.3) < 0.1, worst
assert abs(worst / t_cpu - 35) < 0.1, worst / t_cpu
# Trade-off check: a pulse shorter than 2 slow clocks can be missed.
pulse_ns = 1 / 96e6 * 1e9
assert pulse_ns < 2 * t_per * 1e9, "single fast pulse is invisible to slow sampler"
print(f"best {best * 1e9:.1f} ns (26 clocks), worst {worst * 1e9:.1f} ns (35 clocks)")
print(f"fast pulse {pulse_ns:.2f} ns < sampling window {2 * t_per * 1e9:.1f} ns: level needed")
print("PASS: latency window and level-vs-pulse trade-off recomputed")The weak answer loses on Assumption because it never states the clocks, the priority layout or what worst case means. It loses on Mechanism because goes into the controller names no synchroniser, no register, no cycle count. It scores 0 on Trade-off because no alternative exists. The strong answer earns its 4 on Mechanism by anticipating the loss modes: the pulse-miss case and the priority-preemption case are failure modes with checks, which is exactly the 4 anchor. Note what the strong answer does not do: it never leaves NanoSoC numbers, it never names a company or a product, and its follow-up defence is already written, because every claim has a check beside it.
Cover the strong answer and reproduce its four parts from the numbers alone: 2, 1, 2 and worst-plus-one. Then change one assumption, the DMA interrupt moves to input 5, and re-derive what breaks: priority inversion against input 1 traffic, longer worst case under load, same synchroniser window. If the re-derivation takes more than five minutes, the structure is memorised, not understood; rebuild it from the periods in the corner.
It extends Mechanism toward a 4: the level stays high until cleared, so a late clear delays deassertion but cannot lose the event; the cost is a spurious re-entry if the handler returns first, fixed by clearing before returning or reading back the clear through the posted path.