the limitation of single-cycle design

Imagine paying every employee the same daily wage no matter how long their task takes, and setting that wage by the slowest task in the building. People doing two-minute jobs get paid as if they worked all day. That is the core flaw of a single-cycle processor: the clock period is fixed at the length of the slowest instruction, and every instruction — fast or slow — is charged that same long cycle.

Here is why, concretely. In a single-cycle design each instruction must complete within one clock tick, so the tick has to be long enough for the worst critical path through the datapath. That worst path is typically a load: fetch + register read + ALU address calculation + data-memory access + register write-back, perhaps 8 units of delay. An arithmetic instruction that needs only fetch + register read + ALU + write-back (say 6 units) and a branch (maybe 5 units) are both stretched to the same 8-unit cycle. The faster instructions gain nothing from being faster.

Two further costs make it worse. First, each hardware unit can be used only once per cycle, so the single-cycle design cannot reuse, for example, the same adder for both PC + 4 and a branch target — it needs separate adders, wasting hardware. Second, no instruction can ever beat the worst-case time, so even a program made entirely of quick adds runs at load speed. The fix is to stop charging everyone the worst-case wage: break execution into smaller steps (multi-cycle), letting simple instructions finish in fewer steps, and later overlap those steps across instructions (pipelining). The single-cycle's limitation is precisely the motivation for everything that follows.