Recap: one instruction, one tick of the clock
Across the last three guides you wired up a complete datapath — program counter, instruction memory, register file, ALU, data memory, a sign extender, and a fistful of multiplexers — and a control unit that reads the opcode and sets every control signal. The machine you ended up with is a single-cycle processor: each instruction starts and finishes inside one tick of the clock. Fetch, decode, register read, ALU, memory, write-back — the whole journey happens as signals ripple through the wires during one long clock period.
This is wonderfully simple to reason about: no instruction ever overlaps another, and the value in every register is exactly what you would predict at the end of each tick. It is the cleanest possible picture of a CPU, which is precisely why textbooks build it first. But simplicity has a price, and that price is hiding in plain sight inside the phrase 'one long clock period'.
The single-cycle limitation: the clock crawls to fit the worst case
Here is the catch. In a single-cycle design the clock period must be long enough for the slowest instruction to finish, because every instruction shares the one clock. Think about how far the signals must travel. An add only walks instruction memory, the register file, the ALU, and back to the register file. But a load walks instruction memory, the register file, the ALU (to compute the address), then data memory, then back to the register file — a noticeably longer chain. The longest of all these chains is the critical path, and it alone sets the clock.
The consequence is wasteful. Suppose a load takes 8 nanoseconds of signal travel but an add takes only 4. In a single-cycle machine the clock period is pinned at 8 ns for everyone, so every add wastes the second half of its cycle standing idle, all dressed up with nowhere to go. The fast instructions are dragged down to the speed of the slow ones. This is the single-cycle limitation: you pay the worst-case latency on every single instruction, even the trivial ones.
The multi-cycle idea: chop the work into short, equal steps
The escape is to make the clock fast and let an instruction take several ticks. A multi-cycle datapath slices the long journey into short stages — fetch, decode and register read, execute, memory access, write-back — and runs each in its own short clock cycle. The clock period now only has to fit the longest single stage (say the memory access), not the whole instruction. Crucially, an add can finish in 4 cycles while a load takes 5: each instruction spends only as many short cycles as it genuinely needs, instead of all paying the worst case.
To make this work, the datapath grows a few extra holding registers. Because the work now spans several cycles, intermediate values — the fetched instruction, the two values read from the register file, the ALU's output — must be latched into tiny internal registers so they survive into the next cycle instead of evaporating when the clock ticks. In exchange, the multi-cycle machine can now reuse one unit across cycles: a single ALU computes PC+4 in one cycle and the branch target in another, so you no longer need those extra dedicated adders. Fewer hardware units, used more times each.
Same load, two designs (illustrative latencies):
single-cycle: | fetch . decode . read . ALU . MEM . write | one 8 ns tick
add wastes half of that 8 ns tick (only needs ~4 ns)
multi-cycle: |fetch|decode|ALU |MEM |write| five ~2 ns ticks
add finishes in 4 of those short ticks, not 5
iron law: run time = instruction count x CPI x cycle time
single-cycle: CPI = 1 but cycle time = worst case (slow)
multi-cycle: CPI > 1 but cycle time = one short stage (fast)It is a trade, not a free win
Be honest about what multi-cycle buys you. It does not make any one instruction finish sooner in absolute time — it simply stops fast instructions from being held hostage by slow ones, and lets hardware be reused. The right way to keep score is the iron law of performance: run time equals instruction count times cycles per instruction times cycle time. Single-cycle has a CPI of exactly 1 but a cruelly long cycle time. Multi-cycle has a CPI greater than 1 (4 or 5 ticks per instruction) but a much shorter cycle time. Whether it wins depends on the actual numbers — a higher clock rate alone never guarantees speed; it is always the product of all three factors that matters.
And here is the deeper observation that powers the rest of this course. In the multi-cycle machine, while one instruction sits in the memory stage, the fetch hardware is idle. While another instruction uses the ALU, the memory unit is idle. The stages take turns but mostly stand around. If we could keep every stage busy at once — fetching one instruction while decoding the previous one while executing the one before that — we would get the throughput of doing five things at once. That overlap is exactly pipelining, the laundry-assembly-line idea that the next rung is built on. Multi-cycle is the bridge that takes you there.
Who issues the signals? Hardwired vs microprogrammed control
A multi-cycle datapath demands a smarter control unit. In single-cycle, control was a flat lookup: given the opcode, set this fixed bundle of signals for the whole tick. But multi-cycle control must produce a different bundle of signals every cycle — read registers now, drive the ALU next, write memory after — and it must remember which step it is on. So the control unit becomes a small finite-state machine: each state is one step of one instruction type, and the transitions march fetch to decode to execute to whichever step comes next for that opcode.
There are two classic ways to build that machine. Hardwired control bakes the state machine straight into logic gates and flip-flops — a custom circuit, designed by hand or synthesized, whose outputs are the control signals. It is fast and compact, but rigid: fixing a bug or adding an instruction means redesigning the circuit. The alternative, microprogramming, treats the control signals as data. Each step's bundle of signals is stored as one word — a microinstruction — in a small internal control memory, and a tiny sequencer just reads them out one after another, like a program-within-the-program that drives the real datapath.
Each has a home. Microprogramming made rich, complicated CISC instruction sets practical: a baroque instruction is just a longer microprogram, and you can patch control by rewriting microcode rather than re-spinning silicon. Hardwired control suits lean RISC machines where the small, regular instruction set keeps the logic simple and fast. The wider lesson, though, is the split between datapath and control itself: the datapath is the plumbing that moves and transforms data, and control is the orchestra conductor deciding when each pipe opens. Whether the conductor is a hand-built circuit or a stored microprogram, that separation is the seam where one CPU design ends and the next begins.