In this lesson, you will learn how the architectural choice between single-cycle and multi-cycle design forces a trade-off between hardware resource simplicity and control logic sophistication.
The Single-Cycle Approach: Efficiency Through Simplicity
In a single-cycle design, every instruction must complete its entire journey—from fetch to write-back—within one clock pulse. Because the clock period is determined by the slowest possible instruction (usually the load word instruction), the hardware is intentionally "flat." You don't need temporary registers between stages because everything happens simultaneously in one go.
- Hardware Complexity: High functional unit duplication. You often need separate adders for incrementing the PC and performing ALU calculations because they must happen at the same time.
- Control Complexity: Low. Since the path is fixed, the control unit is essentially a static decoder.
The Multi-Cycle Approach: Resource Sharing
Multi-cycle design breaks instructions into smaller, discrete steps (like fetch, decode, execute, memory, write-back). Because these steps occur over multiple clock cycles, we can reuse hardware components. For example, a single ALU can be used to increment the PC in one cycle and perform an arithmetic operation in the next.
- Hardware Complexity: Low. By sharing functional units (like the ALU and memory), we reduce the overall transistor count.
- Control Complexity: High. Because one hardware unit now performs multiple tasks at different times, you need a Finite State Machine (FSM) to track "where" each instruction is in its journey. You also need "inter-stage" registers (hidden buffers) to hold data between cycles.
Visualizing the Trade-off
Single-Cycle: [Instruction -> Execution] in 1 cycle (Long clock period)
Multi-Cycle: [Step 1] -> [Step 2] -> [Step 3] (Short clock period, more steps)
In the multi-cycle model, we pay for a faster clock speed by adding the complexity of an FSM and extra registers to "remember" the state of an instruction from one cycle to the next. In the single-cycle model, we save on the FSM complexity but pay for it with a slower clock that must wait for the longest path to finish.
Key Takeaway: Single-cycle designs favor simple control logic at the expense of hardware duplication, while multi-cycle designs prioritize hardware reuse at the expense of complex state-based control.