We will keep referring to one map of the pipeline. Look at it before starting.
The four vertical bars are the four pipeline registers. The coloured chips flowing left-to-right are control signals; each drops off at the stage that uses it.
There are four pipeline registers (a wall sits between neighbouring stages, so 5 stages give 4 gaps):
IF/ID — between Fetch and Decode
ID/EX — between Decode and Execute
EX/MEM — between Execute and Memory
MEM/WB — between Memory and Write-back
There is no register after WB: WB writes into the register file, which is itself stateful storage. So the count is 4, not 5.
Recall Solution L1.2
Group them by the stage that uses the signal:
EX bundle (used in Execute): ALUSrc, ALUOp, RegDst
MEM bundle (used in Memory): MemRead, MemWrite, Branch
WB bundle (used in Write-back): RegWrite, MemtoReg
So EX consumes 3, MEM consumes 3, WB consumes 2.
Recall Solution L1.3
All signals are generated in ID (Decode). Only ID reads the opcode; by the time an instruction reaches EX/MEM/WB, the instruction word has been consumed and those stages see only data + already-latched control bits. So the decode happens once, in ID, and the results travel.
RegWrite is decoded in ID but used only in WB (3 stages later). It must survive every intermediate wall:
Latched into ID/EX (EX doesn't use it → carried).
Copied into EX/MEM (MEM doesn't use it → carried).
Copied into MEM/WB (this is the last wall before WB).
Used in WB to drive the register-file write-enable, writing the result into $t0.
So it lives in ID/EX, EX/MEM, MEM/WB — three registers — and is consumed in WB.
Recall Solution L2.2
Add each field that a later stage needs (anything not stored is lost when EX moves on):
WEX/MEM=ALU result32+store data32+branch target32+Zero1+dest reg #5+∣MEM∣3+∣WB∣2WEX/MEM=32+32+32+1+5+3+2=107bits.
Recall Solution L2.3
WMEM/WB=mem data32+ALU result32+dest reg #5+∣WB∣2=71bits.
Note MEM/WB is narrower than EX/MEM (71 < 107): it dropped the MEM bundle, the store data, the branch target, and the Zero flag — none of those are used in WB.
When lw's result reaches WB, the lw instruction was fetched 4 cycles ago; IF/ID now holds a different, younger instruction. Bits 20–16 of that instruction are some unrelated register number. So WB would write the loaded word into the wrong register — not $s0.
The fix (correct design): decode the 5-bit destination in ID and latch it ID/EX → EX/MEM → MEM/WB, so WB uses the older instruction's own target. See the dest-# chip travelling all the way to WB in the figure above.
Recall Solution L3.2
The branch target is computed by an adder in EX:
branch target=(PC+4)+(imm≪2).
The value PC+4 is generated in Fetch but needed in EX. If it only lived in IF/ID, it would be gone by EX and the target adder would have no first operand. So PC+4 rides IF/ID → ID/EX (→ EX/MEM if the branch is resolved in MEM), exactly like any other value produced early and consumed late.
Recall Solution L3.3
Sizes: ∣EX∣=3, ∣MEM∣=3, ∣WB∣=2.
ID/EX holds EX+MEM+WB =3+3+2=8 control bits.
EX/MEM holds MEM+WB =3+2=5 control bits (EX bundle consumed & dropped).
EX bundle (3 bits): stored only in ID/EX (consumed in EX) → 3×1=3.
MEM bundle (3 bits): stored in ID/EX and EX/MEM (consumed in MEM) → 3×2=6.
WB bundle (2 bits): stored in ID/EX, EX/MEM, MEM/WB (consumed in WB) → 2×3=6.
Total control flip-flops =3+6+6=15 bits.
Cross-check with the per-register sums: 8+5+2=15. ✓
Recall Solution L4.2
WID/EX=RegA32+RegB32+sign-ext imm32+PC+432+dest reg #5+EX+MEM+WB8WID/EX=32+32+32+32+5+8=141bits.
This is the widest of the pipeline registers — it stands right after decode and carries everything the downstream stages will ever need.
Recall Solution L4.3
First IF/ID:
WIF/ID=instruction32+PC+432=64bits.
Grand total:
Wtotal=64+141+107+71=383bits
of edge-triggered storage just for the pipeline registers (data + control), independent of the register file and memories.
(Reason across the whole design under constraints.)
Recall Solution L5.1
MulEnable is decoded in ID (opcode-derived, like all control) and consumed in EX. It must be preserved from ID until EX, i.e. latched into ID/EX only (1 bit). Since EX consumes it, it is dropped and never enters EX/MEM.
ID/EX grows by 1 bit (141→142).
EX/MEM, MEM/WB: unchanged.
This mirrors the existing EX bundle: born in ID, carried one wall, dropped after use.
Recall Solution L5.2
It must survive from ID until its last use (WB). So it is latched in ID/EX, EX/MEM, and MEM/WB — the same span as a WB-only signal, because "how far it travels" is set by its latest consumer, not by how many stages read it.
Flip-flop cost: 1×3=3 bits (one per register it passes through).
A WB-only signal costs the same 3 bits. Being read in MEM as well adds no storage — the wire is simply tapped in MEM en route.
Key principle: transport cost depends only on the last stage that needs the signal.
Recall Solution L5.3
Storage compare: carrying a 6-bit opcode in each of ID/EX, EX/MEM, MEM/WB costs 6×3=18 bits — more than the standard 15 bits. So it doesn't even save flip-flops here.
Correctness: it can be made to work (each stage re-decodes its own bundle from the carried opcode), but it duplicates the control-unit decode logic into every stage, adding combinational delay to each stage's critical path and complicating verification. The standard design decodes once in ID and merely transports the results — cheaper in bits and in logic.
Verdict: the lazy scheme is worse on both axes (18 > 15 bits, plus replicated decoders). The classic "decode once, transport" wins.
Recall Master summary (open only after finishing all levels)
4 registers, storing 383 bits total for 32-bit MIPS (64 + 141 + 107 + 71).
Control is decoded once in ID; 15 control flip-flops total across ID/EX (8), EX/MEM (5), MEM/WB (2).
A signal's storage span is set by its latest consumer; each register drops consumed bundles, so control width strictly shrinks 8>5>2.