15The Control Unit is a ROM

At the end of last chapter I asked you to look one last time at who was still deciding. The machine could branch now. It could loop until a counter hit zero, or choose one path over another. And yet every one of those choices was really being made by a human hand. Yours. Across twelve chapters you have been sitting at the control panel, raising the control lines in the right order: drive the PC onto the bus here, latch the MAR there, enable the ALU, catch the result in register A. It felt like thinking. But watch yourself do it and you'll notice something deflating. You never actually chose anything. Every single time, you followed a fixed rule: for this opcode, on this step, with these flags — raise exactly these lines. Same situation in, same lines out. No judgement, no memory of what came before. Now, most tellings of this chapter spend the punchline right here: a fixed rule that maps an input straight to an output, with no memory of its own, is a lookup table. I'm going to say it and then take it straight back, because that sentence skips a step, and the skipped step is the whole chapter. So here is all I'll promise. The machine's entire "brain" — the thing that has been quietly running the show — is not some new kind of hardware we've been putting off. It's furniture you already built, back in Chapter 11: a ROM, the same decode-and-OR array you wired up to light a display. What I won't hand you is the reason. Why the situation has to be an address, and why the lines to raise are exactly its stored word — that part you're going to say out loud before I do. The rest is us earning it: building the machine's sense of time, packing the situation into an address, and reading the finished table with our own hands.

01You have been the control unit

Let's start by catching ourselves in the act. Here is the machine you've built, stripped down to its control lines — the little switches that steer everything. There are out-enables that push a value onto the bus, load-enables that latch it somewhere, and the ALU's op select. To run even one micro-operation, you raise these lines in a precise order. Do it by hand below. Push the buttons to walk a value from RAM into register A, and notice that you are the thing making it happen.

Now the uncomfortable part. It felt like you were deciding, but you weren't. You were obeying a script you could write down in advance. Watch. I'll hand you a situation — an opcode, a step number, and the current flags — and ask you to pick which control lines to raise. There are exactly two flags, by the way, and you built them last chapter: Z for zero and C for carry. One bit each, set by the last ALU operation, then just sitting there waiting to be read. Commit to your answer, then reveal the "correct" one. They'll match every time, because there was never a choice. The situation alone forces the lines.

Sit with what that means. The output depends only on the present situation. It never depends on anything the machine remembers, on mood, or on history. Same three inputs in, same bundle of lines out, forever. So here's the sentence from the top, and here's the step it skips. A fixed, memoryless map from an input pattern to an output pattern is a truth table. That much is forced. Calling it a lookup table is not forced. A lookup table is one way to build a truth table, and we haven't earned that choice yet. Hold the two words apart for a few paragraphs. You have built the shape twice already — the seven-segment decoder in Chapter 11 (a 4-bit code in, seven segment-bits out) and the addressing logic of RAM. Line all three up and they are the same shape.

So let's do the thing that makes "fixed rule" stop being a phrase and start being an object. Count the rows. The opcode is 4 bits wide, so there are at most 16 of them. The flags are 2 bits, so 4 combinations. And the step? We haven't built it yet, so borrow one number from me and we'll earn it in a few paragraphs: it runs to 5 values. Multiply. 16 × 5 × 4 = 320 rows. That's it. That is the machine's entire mind, and it would fit on two printed pages. Not an infinity, not a metaphor — a list you could read on the train. Which leaves exactly one question, and it's an engineering question rather than a philosophical one: once the table is written down, what do you make it out of? You can freeze it into gates, a tangle of AND and OR that computes each output straight from the input bits. Or you can store it, row by row, and read the row back when you need it. Both are fixed. Both are memoryless. Both hand back bit-identical answers. Keep both doors open. We'll come back and choose.

So the destination is already in view: the control unit is going to be a table in silicon. But a table needs a clean input, and right now one third of our situation is missing. The machine knows its opcode (it's in the instruction register) and it knows its flags. But it has no idea which step it's on. LDA takes several beats, and nothing in the datapath tells it whether this is the first beat or the fourth. Before we can build the table, we have to give the machine a sense of when.

02The step counter — a sense of when

Here's the missing organ, and it's almost embarrassingly small: a microstep counter. It's a tiny register that just counts 0, 1, 2, 3, 4. Then, instead of climbing to 5, it snaps straight back to 0 to begin the next instruction. Five states, on a loop. It's the machine's answer to the question "where am I inside the current instruction?" Tick it and watch it march and reset.

Where does its clock come from? It doesn't need its own, and this is the quietly beautiful part. The same clock edge that latches a value into a datapath register also ticks the step counter forward. One rising edge does two jobs at once. The datapath does the work of this step, and the counter advances to point at the next one. So the machine's sense of time comes for free, riding the very clock that's already driving everything. Watch a single edge do both.

Now let's spend the counter's first two states, because they're identical for every instruction the machine will ever run. This is the fetch. On step 0, the program counter holds the address of the instruction we're about to run, so we copy that address into the MAR — the register that tells RAM which cell to look at. One out-enable, one load-enable, done. That's the whole of step 0.

Step 1 is where two things happen on one beat. RAM now hands back the instruction byte, and we latch it into the instruction register. But on that same edge, we also nudge the PC up by one, so it already points at the next instruction. We could have spent a whole separate state just incrementing the PC. We don't need to, so we fold the PC++ into the IR-load and save a beat. Be careful about what that merge buys, though. It is not the reason the counter has the length it has. It's a discount, applied evenly to every instruction: each one comes out one beat shorter than it would have been. That is why our toy is a five-state machine rather than a six-state one, and why the counter runs 0→4 and not 0→5. But the rule that decides that number in the first place is a different rule, and we'll meet it in a few paragraphs.

Here's a subtlety worth catching before it trips you later. During those two fetch steps, the machine asserts a fixed set of control lines. It does so without knowing what instruction it's running. It can't know, because the opcode only arrives in the IR at the end of step 1. So the fetch prefix is opcode-blind by necessity. Pick any opcode you like below and confirm that steps 0 and 1 come out byte-for-byte identical no matter what you chose.

Two steps down, always the same. Whatever the instruction turns out to be, the machine has now fetched it. The opcode is sitting in the IR, the flags are set from the last operation, and the step counter reads 2. From here on, the steps finally get to care what the opcode is. That's where the interesting part lives.

Before it does, though, we should be straight about what the opcodes are — and I owe you an apology, because I've been sliding between names. Here's the roster, one name each, and these are the names I'll hold to. LDA: load register A from a cell in RAM. (One of the panels labels it LOAD. Same instruction.) STORE: write A back out to a cell. LDI: load A with a constant carried inside the instruction itself, so there's no RAM read to wait on. ADD and SUB: run the ALU and catch the result in A. These are the long ones; they need all five beats. JMP: overwrite the PC with a new address. JZ and JC: the same, but only if the zero or the carry flag is set. (The predict panel up at the top called the first of these JMPZ. Same instruction.) NOP: assert nothing and go round again. The opcode field is 4 bits, so there's room for sixteen instructions and we use a fraction of that. Which 4-bit code goes to which instruction is a free choice, and nothing downstream cares, so long as we choose once and never change our minds.

03Fetch, decode, execute

One naming note first, because the panels are about to switch dialects on you. The step counter's states are conventionally written T0, T1, T2. The T is for timing. T3 means step 3, and that's the whole of it, so when a caption says T0–T4, read it as steps 0 to 4. Now: you'll hear the machine's whole rhythm named in three words — fetch, decode, execute — and it's worth being honest about where each one lives. Fetch is steps 0–1, the part you just built. Execute is steps 2 onward, coming next. But decode? Look for it and you won't find a step for it anywhere. That's not an oversight. Decode isn't an action the machine does. It's the invisible instant the opcode gets turned into control lines — the table lookup itself. Here's the loop with decode drawn where it actually happens: in the wires, not on the clock.

Let's make execute concrete with one instruction, and read it the way the control unit does — not as "what LDA means," but as which control lines light up on each step. Step through LDA's full five-beat life below. Steps 0–1 are the shared fetch. Steps 2–3 do the real work: drive the operand to the MAR, then RAM's data into A. Step 4 asserts nothing at all. Read the word of control lines as it changes beat by beat.

And now the rule that turns reading into checking. The bus is one set of wires, and a wire can hold exactly one value at a time. So every legal beat obeys one law: at most one out-enable. Two drivers pushing at once isn't a clever trick, it's a short, and you can watch it fight in the very first panel of this chapter. Load-enables are the opposite. Raise as many as you like. Everything hanging off the bus sees the same value, so any number of registers can catch it on the same edge. That isn't a loophole — it's the whole reason step 1 works, where RAM drives once and the IR and the PC's count-enable both act on that one beat. So from here on, don't just watch the lamps. Scan each beat, count the out-enables, and if you ever find two, either I've made a mistake or that row isn't a row.

You just read LDA out one beat at a time. Five control words, in order, each one doing a single tiny thing. That column is a program, written in the machine's smallest instructions — one per beat, a level below LDA itself. So it earns the prefix: it is a microprogram. Now put two of them side by side and the shape of the whole thing jumps out. Here are the microprograms for LDA and ADD, aligned step for step. Notice that steps 0 and 1 are letter-for-letter identical — the shared fetch we just proved is opcode-blind. The two only diverge at step 2, the moment execute begins. The opcode's entire job is to steer the back half of the sequence.

Which raises a fair question: why five steps, exactly? Not four, not eight. The answer is a rule that governs every stepped machine: the counter is only ever as long as its longest instruction. One counter serves all of them, and it can only be built one length. Most of our opcodes finish well before step 4. But at least one needs every beat, and that one sets the ceiling for all of them. Here that one is ADD, and now the fetch merge comes back to collect. ADD needs five beats. It would have needed six if we hadn't folded PC++ into step 1. So the two facts stack instead of competing: the longest instruction picks the number, and the merge shaves one beat off it, and off every other instruction too. Compare the instructions' lengths below and watch the tallest bar fix the counter's size.

So what happens to a short instruction — one that's completely finished by step 2? It doesn't get to reset early. The counter still marches to 4 before wrapping. The leftover steps simply assert no control lines. They're no-ops, empty beats where the machine does nothing but wait for the counter to come around. Watch a short instruction finish its work and then idle out the tail.

Now we have everything the table needs as input: the opcode (from the IR), the step (from the microstep counter), and the flags (from last chapter). Three fields, fully known on every beat. Time to build the table.

04The control unit is a ROM

So: three fields, each finite, each known on every beat. Glue them end to end, which is all concatenation means, and three things become one binary number. The order is a free choice. It just has to be the same choice every beat. The opcode is 4 bits and takes the top. The step is 3 bits (enough to count 0–4) and sits in the middle. The flags are 2 bits (zero and carry) and sit at the bottom. So the situation is now one 9-bit address: opcode×32 + step×4 + flags, a plain number from 0 to 511. Now stop. A 9-bit pattern goes in. A fixed bundle of lines has to come out. You have built exactly one device with that shape: hand it an address, get back a stored word. Name it before you scroll. It's the ROM from Chapter 11. We never made the control rule be a ROM. It already was one. Set each field below and watch the address assemble.

And the word the ROM stores at that address? It's the bundle of control lines to raise, one bit per line: 1 means "assert this line," 0 means "leave it alone." That's the entire trick, and it's why the reveal lands. The situation is an address, the control signals are a word, and "decoding an instruction" is nothing more exotic than a memory read. Feed an address in below, and read the control lines out.

I want to be careful here, because "decode is just a lookup" can sound like a cheap trick. So let me show it's a genuine engineering choice with a real alternative. You could build this control logic the hardwired way: a custom tangle of AND/OR gates, minimized by hand, that computes each control line directly from the situation bits. Or you could build it the microcoded way: drop the answers into a ROM and look them up. Flip between the two below. They produce the identical control word, but one is frozen in gates and the other is just data you could rewrite.

Before we wire it up, there's a question you should feel scratching. Look at ADD's execute beat. The ROM raises the ALU's op-select to "add" and, in the same control word, raises register A's load-enable. Same beat. So what does A catch — the sum, or whatever garbage was on the ALU's output while it was still settling? Commit to an answer before you read on. If you said garbage, you've made the one assumption that breaks here: you heard same beat as same instant. It isn't. A beat is an interval, not a moment. The control word goes up at the start of the beat, and the ALU spends that beat settling, because that's all combinational logic ever does — chase its inputs until it catches them. The register doesn't look until the end, on the clock edge. By then the ALU has been holding a stable sum for most of the beat. Nothing races, because the two things you thought were simultaneous are separated by the entire width of a beat. That separation is exactly what the clock period is for.

Wire that ROM's output straight to the control lines and step back, because the machine is now complete. The step counter names the beat, the ROM reads the situation and asserts the lines, the datapath obeys, and the edge advances the counter. Around it goes, with no human hand anywhere. That is the split we just watched, said once more in the machine's own words: some control lines act the instant the ROM asserts them. The ALU's op select is combinational — flip it and the result changes live. The registers, though, only capture their inputs on the clock edge; they're sequential. The microprogram is written assuming exactly that split. Watch the finished machine run itself.

That is the keystone of the entire course, so let it settle: the CPU's brain is the same decode-and-OR ROM you built to light up a seven-segment display. Nothing more. Now let's actually read the table it stores, and meet the one ugly compromise a raw ROM forces on us.

05Reading the control ROM

The best way to understand the table is to drive it. Pick an opcode, then scrub the step counter from 0 to 4, and watch which control lines the ROM asserts at each beat. You're reading the machine's microprogram straight off the silicon. Every instruction is just a little vertical strip of this table.

Here's the compromise. Our address includes the two flag bits, but for almost every instruction, the flags don't matter. LDA does the same thing whether the zero flag is set or not. A smart design would say "for LDA, don't care about the flags." But a raw ROM has no way to say that. Every address is a distinct row with its own stored word. So each instruction has to be written into the ROM four times over, once for each combination of the two flags, with identical words in all four copies. Only JZ and JC ever put those four copies to real use. See the duplication below.

Zoom out to the whole table and you can see the waste as a pattern. There are vast blocks of identical rows (the four flag-copies), plus rows that can never be addressed at all. Steps 5, 6, and 7 don't exist in a five-state machine, so those addresses are don't-cares — dead storage. Real designs don't tolerate this. They replace the raw ROM with a PLA (a programmable logic array that does honour don't-cares), or they minimize the logic, or they mask the flag bits out of the address for instructions that ignore them. Here's a slice of the control-ROM table — six opcodes across the eight step-addresses, one flag-copy each — its redundant and unreachable regions shaded — the map you carry out of this chapter.

That's Chapter 15. The machine's "brain" turned out to be no new invention at all. It's just a microstep counter to supply a sense of when, plus a ROM addressed by opcode ‖ step ‖ flags whose stored word is the control lines to raise. Fetch is the shared, opcode-blind prefix; decode is the invisible ROM read; execute is the back half the opcode steers. The whole thing runs with no hand on the panel. The one scar is the raw ROM's inability to say "don't care," which real designs sand off with a PLA, minimization, or address-masking. So the machine now runs itself. That leaves one last, vertiginous question — the one that turns this whole toy into a computer. The instructions the ROM decodes are just bytes sitting in RAM. The data those instructions chew on are also just bytes sitting in RAM. So what, exactly, is the difference between code and data? Hold that thought. The answer — that there isn't one — is where we go next.