So far our GPU has been living a lie. The cores of the last two lessons asked memory a question and got the answer one cycle later, every time, no matter how many lanes asked at once — a politeness no real memory has ever shown anyone. This lesson ends the fiction. The whole memory story of the GPU-compute module — scarce bandwidth, punishing latency, the coalescing discipline — exists because of one brutal ratio, and we now build that ratio into PrimerGPU honestly: eight requestors (2 dispatched cores × 4 lanes, each with an LSU) funnelling into two memory channels, each taking four cycles per transaction. Eight mouths, two straws. Everything interesting about GPU memory design is a response to exactly this picture.

The memory controller

Between the LSUs and the memory sits the controller, a referee with four duties:

• Per-channel request queues. Addresses are interleaved across channels in 4-word lines — channel = \lfloor \text{addr}/4 \rfloor \bmod 2 — and each channel keeps a queue, because eight requests can arrive in a cycle while a channel finishes one transaction per four;
• Round-robin arbitration. When several LSUs request the same channel in the same cycle, a rotating priority pointer decides who queues first — over time, nobody starves;
• Fixed latency service. A channel pops one transaction, grinds for 4 cycles, answers, pops the next. (Real DRAM latency varies wildly with row hits and refresh; our fixed 4 keeps the arithmetic honest without the chaos);
• Response routing by requestor ID. Every transaction carries a tag — which core, which lane — and the response follows the tag home. The answer to "whose data is this?" is written on the envelope, not inferred from timing.

And on the core side, the six-state FSM finally earns its WAIT room: REQUEST issues the lane requests and then the core stalls in WAIT until every response is home. Latency, which the previous lessons abstracted into a single polite cycle, is about to become the dominant line in every trace we print.

The floor plan

Follow one request through the picture: lane 2 of core 1 computes its address in REQUEST; the arbiter admits it to (say) channel 0's queue behind whoever arrived first; the channel serves it for 4 cycles; and the response — tagged (core 1, lane 2) — lands back in exactly that lane's data latch, while the core sits in WAIT counting its outstanding requests down to zero.

The baby coalescer

Now the twenty lines that the entire coalescing lesson promised were cheap. When a core's four lanes issue a memory instruction, their four addresses very often form a perfect run — in vector add, lane t of block b touches 4b + t: four consecutive words, aligned to a 4-word line. The coalescer checks precisely that:

One comparison per lane, one wide request instead of four narrow ones — a quarter of the transactions for the same data. And because a channel's cost is per transaction (4 cycles each, regardless of width), that factor of four lands directly on time-in-queue. Do the bandwidth accounting for our kernel: 8 threads each load a[i], load b[i], store c[i] — 24 words of traffic. Uncoalesced that is 24 transactions; coalesced, 6 (three per block). If the addresses had been scattered — strided, hashed, indirect — the check fails, the coalescer shrugs, and you pay full price: the hardware makes the well-behaved pattern cheap, but only the program can choose the pattern. That is why coalescing was taught as a software discipline: this circuit is the reason the discipline pays.

Measured, not asserted

The simulator now models all of it — queues, arbitration, latency, ID-routing, and a coalescer you can switch off. Both cores run vector add (8 elements, blocks 0 and 1), and we print what the machine measured: total cycles, transaction counts, channel utilisation, and a run-length trace of core 0's FSM so you can watch WAIT stretch:

Read the measurements. With the coalescer on: 90 cycles, 6 transactions, and the trace shows the two loads (i6, i8) and the store (i11) each stalling in WAIT ×5 — the 4-cycle latency plus the handoff, exactly as designed. With it off: the same 24 words take 24 transactions, each memory instruction's four requests queue up behind each other on one channel, WAIT stretches to 17 cycles, and the kernel slows from 90 to 126 cycles — a 40% slowdown from touching identical data in identical order, with only the transaction granularity changed. Notice the channels are busier too (48 cycles versus 12) while doing the same job: uncoalesced access doesn't just go slower, it burns the scarce resource harder. Coalescing measured, not asserted.