The select logic stands between the address arriving and the slave being chosen, so its delay adds directly to every access. On NanoSoC the whole decision fits in one 96 MHz system cycle with room to spare, but the same structure at a higher clock, or with forty slaves instead of four, stops fitting. The integrator then faces a real trade: pipeline the select and pay a cycle on every access, or keep it combinational and fight the timing. This lesson prices both sides with the specification's latency table.
A select is a wide equality comparator, and its cost grows with the number of windows and the width of the compare. Four windows of 16 to 18 bits each are a handful of gates with shallow logic depth; forty windows with region-dependent lengths and side-effect flags, a classic whiteboard topic, is a much deeper cone that fans into every slave's mux. Pipelining registers the select, which cuts the combinational depth at the cost of one extra cycle before the slave sees a stable choice. Throughput is unchanged, one decision per cycle still flows, but every transaction's latency grows by the pipeline depth.
# not-run: registered-select cost from the specification latency table, NanoSoC teaching values
One T_sys at 96 MHz = 10.4167 ns. One T_cpu at 192 MHz = 5.2083 ns.
CPU single-word SRAM read today: 7 T_sys + 4 T_cpu = 72.9167 + 20.8333 = 93.75 ns.
With one registered select stage: +1 T_sys = +10.4167 ns -> 104.17 ns (20 T_cpu).
CPU register read on the clk_sys APB segment: 125 ns -> 135.42 ns.
Throughput unchanged: the pipeline still retires one select per cycle once full.Ten nanoseconds per access is the price, paid on every load, store and fetch that crosses the interconnect. Against it stands the alternative: a deeper combinational cone that either closes timing with bigger, hotter gates or fails outright. The decision rule is quantitative. If the decode cone meets timing with margin at the target corner, keep it combinational; NanoSoC at 96 MHz with four windows is firmly in this camp. If the cone is the critical path across corners, or if adding the next window would make it so, register the select and budget the extra cycle in the latency spreadsheet before committing.
The timing report names the decode cone explicitly, with its depth and its margin, not just a passing top-level number.
The latency budget used by the boot and performance lessons includes the pipeline stage if one exists.
Adding one more window is priced before it is approved: compare width, cone depth and the pipeline alternative.
Confirm the pipeline accounting with the latency table: take the single-word SRAM read at 93.75 ns, add one system cycle, and check that measured access latency moves to about 104 ns in simulation. Then check that sustained burst throughput does not move at all; if it drops, the pipeline handshake is stalling instead of flowing, which is a bridge bug wearing a decode disguise. The ordering lesson of the fabric section explains why the pipeline must never reorder transactions while it holds them.
The polling loop pays per transaction: 64 times 10.42 ns, about 667 ns more. The burst pays once for its address phase: one extra T_sys, 10.42 ns, not sixteen. Sustained throughput does not change, because the pipeline retires one select per cycle once full; only the first beat is later.