Four lessons of parts; now the machine. This is the payoff lesson — the one where an ISA on paper, a lockstep core, a dealing dispatcher and a bottlenecked memory controller click together and PrimerGPU breathes: a kernel goes in one end and eight correct sums come out the other, with every one of the 93 cycles in between accounted for. We will watch the whole life of a launch — dispatch, lockstep fetch, per-lane index math, coalesced loads queueing, the honest stalls, stores, RET, done, kernel-complete — then interrogate the run like engineers: where did the cycles go? and what happens if we take pieces away? Three configurations, one truth about GPUs, and a self-check in the proper testbench tradition to prove none of it is wishful thinking.

The complete machine

Every box on this diagram is something you built: the contract it all serves, the cores from lesson two, the dispatcher from lesson three, the memory system from lesson four. The simulator below contains all of it in about 150 lines — dispatcher, both cores, queues, arbitration, coalescer — still the same two-phase settle-then-snap loop we started with back in the RTL module, just with a grander State.

THE run

The launch: vector add over 8 elements as 2 blocks of 4 threads, on 2 cores with the coalescer on. One line per cycle — each core's FSM state, each channel's countdown, and annotations when something happens. Then the accounting, and then the same kernel with pieces removed:

Now walk the trace like a guided tour — every phase of a kernel's life is in there:

• c00–c01, the launch: the dispatcher grants block 0 to core 0, then block 1 to core 1 — one grant per cycle, %blockIdx latched at each;
• c02–c39, the lockstep march: both cores tick FETCH→…→UPDATE through the index math and the base constants, core 1 forever one beat behind. At c07's UPDATE, eight threads across two cores have each computed a different i;
• c40–c44, memory gets real: both cores' first coalesced loads hit the channels — block 0's line lands on ch0, block 1's on ch1, served in parallel — while both cores sit visibly in WAIT;
• c56–c60 and c78–c82: the second load and the store replay the pattern — three memory instructions, three stalls, exactly as the memory lesson measured;
• c91–c93, the curtain: each core's RET raises done, the dispatcher counts 1/2 then 2/2, and kernel-complete fires at cycle 93 with c = [11, 22, \dots, 88].

Where the cycles went

The budget table is the honest heart of this lesson:

WAIT is the largest line — nearly double any other state — and that is with the coalescer doing its best; switch it off (config C) and waiting swells to roughly half of all core time. Meanwhile EXECUTE, the only state where mathematics actually happens, gets one cycle in seven. Our toy, built honestly, has independently discovered the central truth of GPU design: a GPU is a machine for surviving memory latency, and everything real GPUs add — warps in flight, caches, deeper coalescing, occupancy machinery — is aimed squarely at that 27%.

Three machines, one kernel

The comparison table quantifies the two big architectural ideas on our own machine, not by appeal to authority:

Halve the cores and the kernel takes 1.97× longer — block-level dispatch converting hardware directly into speed, the scalability contract paying out at N{=}2. Keep both cores but scatter the memory traffic into per-lane transactions and you lose 1.39× while moving the same 24 words. And in every configuration, the self-check passes: the final data memory is compared, word for word, against a reference computed by a plain software loop — the testbench discipline from the verification module, in miniature. A trace that looks right is an anecdote; a machine-checked equality against an independent model is evidence. The crown jewel is not that the trace is pretty — it is that line: self-check PASS.