The contract is signed; now we build the machine that honours it. A PrimerGPU core is the smallest hardware embodiment of the SIMT bargain we studied in the streaming multiprocessor: one program counter, one fetch unit and one decoder — feeding four lanes that execute every instruction in lockstep. Four threads, one brain. The entire economy of a GPU is visible in that ratio: the expensive thinking machinery (what should happen next?) is bought once and amortised, while the cheap doing machinery (ALUs, registers) is stamped out per thread. This lesson wires it up — a control FSM, a shared front end, and four almost-identical lane columns whose one difference turns out to be everything.

The six-state heartbeat

Our core is a multi-cycle machine: each instruction walks through six FSM states, one per clock. This is deliberately humbler than a pipeline — states, not stages — because the capstone's goal is a machine you can watch think:

• FETCH — read the instruction word at PC from program memory;
• DECODE — split it into opcode and fields (pure combinational unpacking — our boring encoding table pays off here);
• REQUEST — for LDR/STR, each lane computes its own address and issues a memory request;
• WAIT — hold until the memory answers. For now memory replies in one cycle; in two lessons, when the memory system becomes real, this state is where cores will visibly idle — the FSM already has the waiting room built;
• EXECUTE — all four ALUs compute, all at once, on their own lane's registers;
• UPDATE — commit: write results into the lane register files, set the flags, advance (or branch) the shared PC.

In SystemVerilog the spine is a dozen lines:

Every instruction visits every state — even a NOP strolls through the memory states doing nothing. Wasteful? Slightly. Simple enough to trust completely? Absolutely — and when the dispatcher and memory controller arrive in the next lessons, this predictable six-beat rhythm is what will make whole-machine traces readable.

The floor plan

Here is the whole core as a block diagram — watch how little of it is "thinking" and how much is "doing":

The four columns come from a generate loop — hardware's version of stamping out copies — and the loop variable itself becomes each lane's identity:

Read the thread_idx line twice: the elaboration-time constant l is baked into lane l's register file as the value its R15 forever returns. Silicon has no loop at runtime — there are simply four register files, physically wired to answer "who are you?" four different ways. That single wiring difference is what makes the shared instruction stream compute four different array indices, fetch four different elements, and store four different sums. Everything else in the columns is copy-paste.

Predication — and one honest shortcut

Control flow is where lockstep gets philosophically interesting. CMP executes in every lane, and each lane keeps its own N/Z/P flags — lane 0 might record "negative" while lane 3 records "positive", because they compared different data. So what should BRnzp do when the lanes disagree? There is only one PC — the lanes cannot go separate ways.

Real GPUs answer with divergence machinery: mask off the lanes that didn't take the branch, run both paths one after the other, reconverge — the elaborate apparatus of branch divergence and reconvergence. Our toy takes a documented shortcut: PrimerGPU branches when lane 0's predicate holds, and the other lanes follow. This is honest for the kernels we run — vector add has no branches at all, and matmul's loop condition depends only on the loop counter, which is uniform (identical in every lane, since it never touches R15) — so lane 0 speaks for everyone. But be clear about what we gave up: a kernel that branches on per-thread data would silently do the wrong thing in lanes 1–3. Real divergence support is the single biggest gap between our core and a real SM, and it is first on the upgrade list in the final lesson's gap audit.

The core in the simulator

Now the payoff for learning the two-phase pattern back in the sequential-logic lesson: the whole core is one State object and one next() function — settle, then snap. State is the FSM state, the PC, the instruction register, four lanes of registers, and memory. Below, one core runs the lesson-72 vector-add kernel (rebased for 4 elements: a@0, b@4, c@8) as one 4-thread block. Watch the FSM tick through its six beats, and watch the lane brackets — four different values from one instruction, every time:

Read the trace like a hardware engineer. Cycle 11's ADD R0, R0, R15 commits R0 = [0, 1, 2, 3] — four different indices from one instruction, the index magic happening live. Cycle 41's LDR returns [10, 20, 30, 40] — four different memory words from one opcode. And the whole 13-instruction kernel lands on exactly 13 \times 6 = 78 cycles with c = [11, 22, 33, 44]. One core down. Next lesson: a dispatcher that feeds blocks to several of them.