This lesson has one job: trace irq_dma from the wire inside the DMA block to the CPU's first handler fetch, naming every stage it passes through. The journey crosses a power boundary, two clock domains and one output register, and each stage adds delay the driver cannot wish away. When a deadline is missed later, this trace is the map the debugger walks; without it, every stage is a suspect and none can be cleared.
The irq starts as combinational logic inside the DMA: irq_en ANDed with DONE or ERR, an active-high level with no pulse anywhere. From there it passes the isolation clamp on the PD_SW boundary, which is transparent while power is on and holds the line at 0 while power is off. Then comes crossing X5, a two-flop synchroniser into clk_per inside the controller, costing two controller periods, followed by the INTC output register, one more controller period. Then crossing X6, a two-flop synchroniser into clk_cpu at the CPU, costing two CPU periods. The CPU samples its interrupt input and takes the exception a cycle later. Every stage is a level stage: nothing here is edge-detected, rearmed or acknowledged on the way, which is why the source must hold the level until software clears the status.
The waveform below is simulation output for the wave source of this topic: a held level travelling through both synchronisers and the output register to the CPU take. One slot is one cycle of clk_per. The clock periods are teaching stand-ins, 10 ns, 40 ns and 5 ns, keeping the exact 4:1 and 2:1 ratios of the real 96, 24 and 192 MHz clocks.
How to read it: irq_dma rises in slot 1 and is held until the last slot, where the testbench drops it to stand for software clearing the source. The synchronised s2 lane rises one slot later, in slot 2: the source changed between two clk_per edges, so the first flop captures it at the very next edge and s2 follows one edge after that, which is two clock edges but only one sampled slot. intc_out and irq_cpu rise together in slot 3: the X6 flops run on the 5 ns teaching clock, so they settle inside one clk_per slot and this view cannot separate them. isr_active rises in slot 4. After its first transition no lane toggles until irq_dma falls at the end, which is the visible signature of a level-based path. The one-CPU-cycle gap between irq_cpu and the take is too small to see at this slot scale. If any lane pulsed instead of holding, the source would be sending an edge through level machinery, and the hold-rule lesson of the previous topic says exactly how that ends.
The irq_dma-to-irq_cpu journey is bounded at 135.4 ns best and 182.3 ns worst. The best case lines every edge up: two controller periods of sync (83.33 ns), one controller period of output register (41.67 ns) and two CPU periods of sync (10.42 ns), totalling 26 CPU cycles. The worst case adds one controller period and one CPU period of edge misalignment, when the rising level just misses a sampling edge on both crossings, totalling 35 CPU cycles. The spread is nearly 47 ns, a third of the budget, and it comes from alignment alone: nothing is broken in the worst case, the edges simply fall badly.
# not-run: NanoSoC teaching values
T_per = 41.667 ns, T_cpu = 5.208 ns
best = 2 x T_per + 1 x T_per + 2 x T_cpu = 83.33 + 41.67 + 10.42 = 135.4 ns (26 T_cpu)
worst = best + 1 x T_per + 1 x T_cpu = 135.4 + 41.67 + 5.21 = 182.3 ns (35 T_cpu)The path drawing names the clamp, both synchronisers and the output register, with the domain of every flop.
The latency bound quoted in the integration spec matches the NanoSoC reference figures: 135.4 ns best, 182.3 ns worst, alignment as the only spread.
No combinational shortcut bypasses either synchroniser, and no edge detector sits anywhere on the path.
Measure the path in simulation with the source forced and watch each lane rise in order: irq, synchronised RAW, controller output, CPU input. If RAW sets but the controller output never rises, the input is masked or the output register is held in reset. If the CPU input rises but no handler runs, the CPU's own interrupt enable is off, which is a software problem with a hardware signature: every lane in this lesson's waveform is correct.
Yes: the CPU enters the handler while the level holds. irq_dma falls only when the handler clears the DMA status bit, after entry, which is why the take logic must tolerate an interrupt that is still asserted.