Conflicts in the Instruction Pipeline: Pipeline Hazards and How They’re Resolved

An instruction pipeline overlaps multiple instructions in time by executing different stages (e.g., fetch, decode, execute, memory, writeback). When two or more instructions compete in ways the pipeline cannot satisfy simultaneously, the pipeline experiences conflicts, usually called hazards: Data hazard, Structural hazard, and Control hazard. These hazards reduce throughput and may require stalling, forwarding, or flushing.

A useful mental model is: each pipeline stage advances every cycle, but hazards break the assumption that “each stage can always proceed independently.” Mermaid view of conflict types:

Key idea: hazards are about timing and availability

For a 5-stage pipeline, the critical question is: by the cycle when instruction $I_k$ needs an operand or the next PC, is the required value already available?

• In data hazards, an operand (register value or result) is not ready at the needed stage, causing a stall or using techniques like forwarding. Forwarding reduces stalls by routing results directly to dependent inputs.
• In structural hazards, some pipeline stages try to use the same hardware (e.g., a single memory port), so one must wait.
• In control hazards, the pipeline doesn’t yet know the correct next instruction address until a branch decision, so speculative fetch may be wrong and must be squashed (flushed). Pipeline flush corrects control flow.

Data hazards (operand dependencies)

A data hazard occurs when instruction $I_k$ depends on the result of instruction $I_{k-1}$ (or earlier) but the producer’s value is not yet available when the consumer needs it. Common subtypes include:

• RAW hazard: the most common case; typically handled by stalling or forwarding.
• Write-after-read (WAR): less common in in-order pipelines, but matters in certain out-of-order designs.
• Write-after-write (WAW): also primarily an out-of-order concern.

In an in-order pipeline, RAW hazards dominate: the dependent instruction either:

1. waits (stall) until the value is written back, or
2. receives the value via Forwarding.

Callout summary:

Data hazards are fundamentally about result timing—where is the producing instruction’s output relative to the consuming instruction’s needed stage?

Structural hazards (resource conflicts)

A structural hazard arises when the pipeline design reuses the same hardware resource across multiple stages during the same cycle. Classic examples include:

• Single-ported memory: instruction fetch and data memory access overlap, competing for the same port.
• Shared execution units: two instructions in different pipeline stages require the same functional unit at once.

Resolution approaches:

• Duplicate resources (e.g., separate instruction and data caches/ports).
• Insert stalls/bubbles when contention occurs.

Key point: structural hazards are design-time constraints. If the microarchitecture cannot physically support simultaneous stage operations, hazards appear even when there are no data/control dependencies.

Control hazards (branches and jumps)

A control hazard occurs because the next instruction depends on the outcome of a branch/jump. In many pipelines, the decision is determined only after some stage (e.g., execute), but the fetch stage has already loaded subsequent sequential instructions.

Common consequences:

• Speculative fetch: fetching instructions that might not be on the correct path.
• Flush: if speculation is wrong, wrong-path instructions are discarded.

Resolution techniques:

• Stall on branch (simplest; often costly).
• Static branch prediction and dynamic predictors.
• Pipeline flush when the predictor is wrong.

A control-flow view of speculation and flush: