Foundations — Pipeline hazards — structural, data (RAW - WAR - WAW), control

Before you can understand hazards, you must understand the machine that has them. This page assumes nothing. We build each idea, anchor it to a picture, and only then use it.

1. What is an "instruction"?

Look at the parent note's example line:

ADD R1, R2, R3

Read it as: "add the contents of box R2 and box R3, put the answer in box R1." Those boxes (R1, R2, R3) are called registers — we define them next.

2. Registers — the CPU's tiny named boxes

Look at the figure: eight labelled boxes. ADD R1, R2, R3 reads boxes R2 and R3 (the yellow arrows out) and writes box R1 (the green arrow in).

WHY does the topic need this? Every data hazard in the parent note is a story about two instructions touching the same box in a clashing order. If you don't picture registers as shared boxes, the hazard names are just letters. (We spell out those names — RAW, WAR, WAW — in section 6, once the read/write ordering is on the table.)

3. The clock and the "clock cycle"

The parent note draws grids labelled c1 c2 c3 c4 c5. Each column is one tick of the clock. Think of it as a metronome: every "tick", every instruction on the assembly line advances exactly one stage.

4. The five stages — the stations on the assembly line

The parent note gives this table. Let's earn every row with a picture.

Look at the five stations left-to-right. An instruction is a car moving through them; it spends exactly one cycle at each. So one instruction takes 5 cycles start-to-finish. The number of stations has a name — call it $k$ (here $k=5$). We'll reuse $k$ when we talk speed.

Two tools appear here that you must not skip over:

• ALU = Arithmetic Logic Unit — the calculator circuit in the EX stage that actually adds, subtracts, compares. When the parent says "ALU computes result", picture the green EX station.
• The register file is touched twice: read in ID (early, cycle-ish 2) and written in WB (late, cycle-ish 5). Hold onto that read-early / write-late fact — it is the entire reason the two "name" hazards of section 6 are harmless in a simple pipeline.

5. Overlap — the picture of pipelining itself

Now the key move. Instead of waiting for instruction 1 to leave WB before starting instruction 2, we start instruction 2 the moment instruction 1 vacates the IF station.

This diagonal staircase is the pipeline. Read it as the parent's grid:

        c1  c2  c3  c4  c5
I1:     IF  ID  EX  MEM WB
I2:         IF  ID  EX  MEM
I3:             IF  ID  EX

WHY the topic needs this picture: a hazard is exactly a vertical slice of this staircase where two cars want the same thing at once. In cycle c4, one instruction is in MEM while another is in IF — glance down column c4 and you can see the collision the parent describes.

6. The three ideas a hazard can break

Now that the staircase exists, the parent note's three hazard families each break one silent assumption. Preview them (D2+ go deep).

First, the three data-hazard names, defined here before we ever use them again. Let instruction $i$ come before instruction $j$ in program order:

With those names in hand:

• Structural — two cars want the same station/hardware on the same beat → they can't both fit.
• Data — a later car needs a value an earlier car hasn't written yet (RAW), or writes clash by name (WAR / WAW).
• Control — a branch instruction decides which car enters IF next, but we've already fetched a guess.

7. The counting tools — symbols in the performance formulas

The parent derives $\text{CPI}=1+b\cdot m\cdot p$. Let's define every letter before it's used.

Where does the penalty $p$ come from? (Why $p=3$?) A branch only knows its answer once it reaches the stage that computes the comparison — in our pipeline that's the EX stage. But IF keeps fetching every beat. So between fetching the branch and resolving it, IF has already loaded the wrong guesses sitting in IF, ID, and EX-entry. Count those wasted fetches:

Look at the red column in the figure: the branch is in EX (c3); by then two wrong instructions have entered (IF at c2, ID/IF at c3) and must be flushed. Resolve-at-EX gives a penalty of $p=$ (stage where branch resolves) − (stage where it was fetched) cycles of wrong-path fetches — in this 5-stage design about $p\approx 3$. Resolve the branch earlier (move the compare into ID) and $p$ shrinks. That is why the parent picks $p=3$: it's the number of beats between fetch and resolution.

The extra term $b\cdot m\cdot p$ is exactly the "average stall cycles per instruction" from control hazards. Adding the analogous stall terms from structural and data hazards, and comparing to the $k$-stage ideal, gives the speedup $\frac{k}{1+(\text{total avg stalls})}$ — the parent's Speedup formula. That's why $k$ from section 4 reappears here.

8. Two "fix" tools you'll meet constantly

You don't need the details yet, but you need the names anchored to pictures so later pages don't ambush you.

• Forwarding (bypassing) — left of the figure. Instead of waiting for a value to reach WB, wire it directly from the EX output back to the next instruction's EX input (the green arrow jumping backward across the staircase). It moves data across space (stations), earlier than the register file would. See Forwarding and bypassing.
• Register renaming — right of the figure. When two instructions clash only because they reused the same box name (WAR/WAW), hand the second one a fresh physical box (R1 → P7). The clash vanishes because they no longer share a name. See Register renaming.

Prerequisite map

This feeds directly into the parent topic and later into Out-of-order execution and Tomasulo, Cache hierarchy (I-cache vs D-cache), and Amdahl's Law.

Equipment checklist