Multi-cycle datapath: Visual walkthrough — Hardware deep dive

Two shorthand names we will use throughout (defined here so no symbol is unearned):

$T_{s in g l e}$ = the clock period of a single-cycle machine — the length of one beat, which must cover an entire instruction.
$T_{m u l t i}$ = the clock period of a multi-cycle machine — the length of one short beat, which must cover only one step.

We will prove that $T_{m u l t i} = max (one step)$ is (usually) much smaller than $T_{s in g l e} = max (whole instruction)$ .

This is the picture-first companion to the parent note. Read that for the words; read this to see the derivation grow from nothing.

Before we start, four plain-word promises about symbols you will meet:

A clock is a heartbeat: a signal that flips high–low at a fixed rate. One full beat = one clock cycle. The time of one beat is the clock period $T$ (measured in picoseconds, ps — trillionths of a second).
ps just means picoseconds, a unit of time. Smaller $T$ = faster heartbeat = faster computer, if the number of beats doesn't grow too much.
A register here means a tiny box that remembers a number across clock beats. We give the important ones names: $PC, IR, A, B, ALUOut, MDR$ — each defined the moment it appears. ( $PC$ = Program Counter, the box holding the address of the instruction being run; we show its latch in Step 3.)
Bit-slice notation $IR [25 : 21]$ means "take bits number 25 down to 21 of the instruction register" — hardware numbers the wires of a value, bit 0 on the right, and the colon picks a range of those wires (here 5 wires). So $IR [25 : 0]$ = "the lowest 26 bits," and $IR [15 : 0]$ = "the lowest 16 bits." It is just picking a slice of the instruction's wires, nothing more.

Step 1 — The clock is chained to the slowest job

WHAT. Picture five jobs a load word (lw) does in sequence: read the instruction from memory, read registers, compute an address with the ALU, read data memory, write the register back. They happen back-to-back inside a single beat.

WHY. If the beat ended early, the last job wouldn't finish — the answer would be garbage. So the beat length must cover the whole chain: $T_{s in g l e} = IMem 200 + RegFile read 100 + ALU 200 + DMem 200 + RegFile write 100 = 800 ps$ Every under-brace is one functional unit's delay; the plus signs mean "and then" — the jobs are strictly one-after-another, so their times add. The total $800$ ps is the length of one long beat. (Throughout this page RegFile read and RegFile write are the two register-file operations, each costing $100$ ps.)

PICTURE. Figure s01 is one single-cycle beat drawn as a long grey bar, split left-to-right into its five labelled functional-unit delays (IMem 200, RegFile read 100, ALU 200, DMem 200, RegFile write 100). A yellow span across the top labels the whole thing "one 800 ps beat," and a pink note under the bar reminds us that even a plain add, which never touches data memory, is billed for the entire bar.

Step 2 — Chop the long job into balanced pieces

WHAT. We cut the lw bar at the natural seams between functional units, giving five slices: IF, ID, EX, MEM, WB (fetch, decode, execute, memory, write-back).

WHY. Each seam is a place where one unit finishes and hands off to the next. If we clock at each seam, the new period is $T_{m u l t i} = max_{step} (delay of that step)$ The $max$ symbol means "take the biggest of." We take the biggest step, not the biggest instruction — that is the whole trick. With our numbers the biggest single step turns out to be $400$ ps (we build up to that in Step 4), versus $800$ ps for the whole thing.

PICTURE. Figure s02 redraws the same lw bar, now sliced into five short beats (IF, ID, EX, MEM, WB) separated by dashed vertical "clock edge" lines. Each slice is a coloured block whose width is its delay; the tallest/widest (blue IF) slice is flagged as the one that will set the clock, with a yellow banner reading "clock fits the tallest slice."

Step 3 — Why we must add "sticky note" registers

WHAT. A combinational block (memory, ALU) shows its output only while its inputs are held steady. But at each clock edge we change its inputs to start the next slice. So an earlier slice's result would vanish. The $PC$ has the same problem: the value PC+4 computed during IF would evaporate unless we latch it back into the PC register.

WHY. We latch each intermediate result into an edge-triggered register — a box that captures its input at the clock edge and holds it steady all next beat. That way a later slice can still read what an earlier slice computed. Think sticky notes passed forward through time. The $PC$ latch is the sticky note for the address stream: IF writes PC+4 into it; if the instruction is a branch (EX) or jump (EX), that same PC latch is overwritten with the new target instead.

PICTURE. Figure s03 shows a value born in one beat (an ALU output) being "pinned" to the yellow $ALUOut$ sticky-note box at the clock edge (dashed yellow line), so the next beat can still read it. Below it, a blue box shows the same mechanism latching PC+4 into the $PC$ box; arrows point from each fading combinational output into its holding register, with a note "next beat can still read it."

Step 4 — Which step is the tallest? (finding the clock period)

WHAT. We measure every slice's delay with the parent's numbers, but now we budget every unit on each slice's critical path — including the pieces the parent note quietly left out. The delays: IMem/DMem = 200 ps, RegFile read = RegFile write = 100 ps, ALU / dedicated adder = 200 ps, sign-extension unit ≈ 10 ps, shift-left-2 (the tiny wiring/shifter that appends two zero bits) ≈ 10 ps, and the control FSM (the finite-state machine that decodes the step and drives every mux, register-enable and ALU-op signal) ≈ 50 ps.

Because control-signal generation and the shift/extend units sit on the path too, we add them where they belong:

Step	Work on the critical path	Delay (ps)
IF	IMem $200$ + PC+4 adder $200$ + control $50$	$\approx 450$
ID	RegFile read $100$ + sign-ext $10$ + control $50$	$\approx 160$
EX	ALU $200$ + shift-left-2 $10$ + control $50$	$\approx 260$
MEM	DMem $200$ + control $50$	$\approx 250$
WB	RegFile write $100$ + control $50$	$\approx 150$

WHY IF is now the tallest. Once we honestly budget the PC+4 adder (which the parent note omitted) and the control FSM (also omitted), the fetch slice — memory read and increment — becomes the critical one. The sign-extension and shift-left-2 units are small (≈10 ps each) but we write them down rather than pretend they vanish. So: $T_{m u l t i} = max (450, 160, 260, 250, 150) = 450 ps$ Each number under $max$ is a step's full critical-path delay including control logic; $max$ picks the largest, because the clock must be long enough for even the worst step. (This differs from the parent note's simplified $300$ ps precisely because we no longer drop the adder and the control-logic delays.)

PICTURE. Figure s04 plots the five step delays as vertical bars; the blue IF bar pokes highest at $450$ and a dashed yellow line at $450$ ps marks the clock period it forces. A pink arrow onto the IF bar spells out "IF = IMem 200 + PC+4 adder 200 + control 50," and small stacked labels show the sign-ext/shift/control add-ons on the other bars.

Step 5 — Different instructions use different numbers of beats

WHAT. Map each instruction onto only the slices it truly needs:

Instruction	Steps	# beats
`beq`	IF ID EX	3
`j` (jump)	IF ID EX	3
`add` (R-type)	IF ID EX WB	4
`sw`	IF ID EX MEM	4
`lw`	IF ID EX MEM WB	5

WHY R-type skips MEM. An add never touches data memory, so it jumps straight from EX (compute) to WB (write the answer back) — its 4th beat is WB, not MEM. A common trap is to think R-type writes in MEM; it does not, because there is no memory work to do.

WHERE the jump target is computed. A jump's target address is not an ALU calculation — it is built by wiring bits together: take the top 4 bits of the current PC, the 26 address bits from the instruction ( $IR [25 : 0]$ , i.e. the lowest 26 wires of the instruction), and two zero bits appended by the shift-left-2 unit, concatenated into a 32-bit address. This assembled target is written into the $PC$ latch during EX — that is exactly why j must reach the EX beat and so needs 3 beats, not fewer.

PICTURE. Figure s05 shows one row per instruction (lw, sw, add, beq, j); each row is five cells labelled IF ID EX MEM WB. Filled blue cells are beats used, hatched empty cells are skipped steps, and the beat count (5, 4, 4, 3, 3) is called out on the right of each row, with a note that j updates the PC in EX.

Reveal your understanding:

An add uses how many beats and which steps?

4 beats — IF, ID, EX, WB (MEM is skipped).

A beq uses how many beats and why so few?

3 — IF, ID, EX; the PC is updated in EX, and branches never read/write memory or the register file.

Where does a jump write its target and how is it formed?

In EX, into the PC latch; the target is bits concatenated (top 4 of PC, IR[25:0], then two zero bits from shift-left-2), not an ALU add — so j needs 3 beats.

Step 6 — Turn beats into real time (the CPI weighting)

WHAT. Take a real instruction mix and compute the average beats per instruction, then multiply by $T_{m u l t i}$ to get real time.

WHY multiply. Time = (number of beats) × (length of one beat). CPI is the average beats; $T_{m u l t i}$ is the beat length; their product is the average time per instruction.

WORKED (parent's mix). 25% loads (5), 10% stores (4), 45% R-type (4), 15% branch (3), 5% jump (3): $CPI = 0.25 (5) + 0.10 (4) + 0.45 (4) + 0.15 (3) + 0.05 (3) = 4.05$ Each term is $f_{i} \times c_{i}$ ; summing gives $4.05$ average beats per instruction.

PICTURE. Figure s06 stacks each type's contribution $f_{i} c_{i}$ as a coloured slab (lw 1.25, sw 0.40, R 1.80, beq 0.45, j 0.15); the total height of the stack is marked by a dashed yellow CPI = 4.05 line, each slab labelled with its $f_{i} \times c_{i}$ arithmetic.

Step 7 — The honest edge case: multi-cycle can be slower

WHAT. Compare total time for a program of $N$ instructions, where $N$ = the total number of instructions executed (the same program runs on both machines, so $N$ is identical for both). Using our fully-budgeted $T_{m u l t i} = 450$ ps: $\frac{T _{s in g l e} -total}{T _{m u l t i} -total} = \frac{N \cdot 800}{N \cdot CPI \cdot T _{m u l t i}} = \frac{800}{4.05 \times 450} = \frac{800}{1822.5} \approx 0.439$ The $N$ cancels because it is the same for both. $800$ ps is the single-cycle time per instruction; $4.05 \times 450 = 1822.5$ ps is the multi-cycle time per instruction.

WHY < 1 means slower. A ratio below 1 says single-cycle finishes in less time here. The culprit is the unbalanced $450$ -ps IF step (memory read + PC+4 adder + control on one path) — once you budget everything, the fetch stage dominates and multi-cycle is slower on raw time for this mix. Multi-cycle's guaranteed win is less hardware (one shared ALU, one shared memory); its speed win needs balanced steps or a memory delay that dwarfs everything else.

PICTURE. Figure s07 puts the two per-instruction times side by side — the grey single-cycle bar (800) clearly shorter than the pink multi-cycle bar (1822.5) — with a yellow arrow flagging the unbalanced IF stage (and the newly-counted PC+4 adder and control logic) as the reason.

The one-picture summary

Figure s08 compresses the whole derivation onto one board: the long grey single-cycle bar (800 ps) on top; below it the multi-cycle version sliced into five short beats with yellow sticky-note registers pinned between slices; an arrow marking the tallest slice (IF = 450, once the PC+4 adder and control logic are counted) as the one that sets the clock; and the bottom line reminding us that the sure win is shared ALU and memory, not raw speed.

Recall Feynman retelling — say it back in plain words

Imagine one worker who must do a five-chore errand (fetch, decode, compute, memory, write) before the boss's whistle blows. In the single-cycle shop the whistle only blows after the whole errand — so the whistle is slow ( $T_{s in g l e}$ ), and even a two-chore errand waits for the full slow whistle. In the multi-cycle shop we blow the whistle after each chore, so the whistle is fast ( $T_{m u l t i}$ ) — it only has to be as long as the longest single chore. Because chores now finish in different whistles, one hammer (the ALU) and one toolbox (memory) get reused across chores instead of buying several. To not lose work between whistles, the worker pins each finished chore's result on a sticky note (IR, A, B, ALUOut, MDR — and the PC itself, which pins the next address) for the next whistle to read. But be honest about every helper on a chore's path: fetch not only reads memory, it also runs the little PC+4 adder, and a tiny foreman (the control finite-state machine) must shout the right signals every single whistle — count all of them, and fetch turns out to be the fattest chore. Short errands (a branch, or a jump whose target is just bits wired together with two zero bits appended by the shift-left-2 in the compute chore) do three chores and leave early — no empty whistles. The catch: because that fat fetch chore stretches the whistle, this mix actually runs slower than single-cycle on raw time. So we never brag about whistle speed alone — we always compute total time = number of whistles × whistle length. Multi-cycle's sure prize is using far less hardware.

Visual walkthrough — Multi-cycle datapath