a multi-cycle datapath

Instead of forcing every instruction into one giant cycle long enough for the worst case, a multi-cycle datapath chops each instruction into several short, equal steps — fetch, decode, execute, memory access, write-back — and runs each step in its own short clock cycle. A simple instruction can finish in fewer steps; only the instructions that genuinely need every step pay for all of them. The clock can now tick fast, because each tick only has to cover one short step, not the whole instruction.

Because the work is spread over several cycles, the design can REUSE hardware across those cycles. A single ALU can compute PC + 4 in one cycle and the branch target in a later cycle; one memory can serve the instruction fetch in cycle 1 and a data access in cycle 4. To remember a value between cycles, small extra registers are inserted to hold the in-flight result (the instruction register, the ALU output register, and so on). A finite-state machine (or microprogram) now sequences the steps, deciding which control signals to assert in each cycle.

The honest trade-offs: a multi-cycle CPU uses LESS hardware (fewer duplicated units) and a faster clock, and different instructions take different numbers of cycles — so an add might take 4 cycles and a load 5, rather than everything taking the single worst-case cycle. But each instruction is still finished before the next begins; there is no overlap yet. That overlap is the next idea, pipelining, which keeps the multi-cycle step structure but starts a new instruction every cycle. Multi-cycle is the bridge between the clean-but-wasteful single-cycle model and the high-performance pipeline.