Data Hazards in Pipelining: Meaning, Types, and How CPUs Handle Them
In a pipelined processor, multiple instructions overlap in time (e.g., one instruction in IF, another in ID, another in EX, etc.). A data hazard occurs when the pipeline would need a value from an earlier instruction that is not yet available at the moment a later instruction needs it.
This is most often described using RAW/WAR/WAW ordering issues:
- Read-after-Write (RAW) hazards are the most common in in-order pipelines.
- [Write-after-Read (WAR)]{def="A write happens before an earlier read finishes (mostly in out-of-order)}} are relevant primarily to out-of-order execution.
- Write-after-Write (WAW) hazards can matter in out-of-order contexts and certain pipeline implementations.
Key idea
A pipeline must preserve the program’s apparent “as-if sequential” behavior. If instruction depends on a result produced by instruction , the CPU must either delay the dependent instruction (stall) or provide the value early (forwarding/bypassing).
Footnotes
-
Hazards in pipelined processors (conceptual overview) - Discusses pipelining and pipeline hazards (including data hazards). ↩
-
Data hazards (RAW, WAR, WAW) — general definition and relationship to out-of-order execution - Defines data hazard types and their ordering implications. ↩
-
Instruction pipeline (stages and how timing affects dependencies) - Describes pipeline stages and typical timing relationships that lead to hazards. ↩
Pipeline Hazards (Data Hazards) — forwarding vs stalling
Where data hazards come from
Pipelining overlaps instruction stages to increase throughput. Suppose an instruction needs a register value in the EX stage, but the producing instruction does not write the register until a later stage (like WB). The consumer instruction then cannot obtain the correct value in time, creating a data hazard. 2
Pipeline stages execute concurrently, so timing differences between “when a value is needed” and “when the value is produced” become critical.
Footnotes
-
Hazards in pipelined processors (conceptual overview) - Discusses pipelining and pipeline hazards (including data hazards). ↩
-
Instruction pipeline (stages and how timing affects dependencies) - Describes pipeline stages and typical timing relationships that lead to hazards. ↩
Pro Tip
When you see a dependent instruction like add r1, r2, r3 followed by sub r4, r1, r5, expect a RAW data hazard unless forwarding or stalls resolve it.
Types of data hazards (RAW, WAR, WAW)
RAW (Read-after-Write)
A RAW hazard happens when a later instruction reads a register/memory location before an earlier instruction’s write has completed. This is the dominant hazard type in classic in-order pipelines.
Mini-example (conceptual):
I1: produces value forR1I2: usesR1as a source operand immediately in the pipeline
If I2 reaches the stage where it needs R1 before I1 produces it, I2 reads the wrong (old) value.
WAR (Write-after-Read)
A WAR hazard occurs when a later write reaches completion before an earlier read has happened. This can occur when instructions execute out of order, allowing reordering to break the original dependency order.
WAW (Write-after-Write)
A WAW hazard occurs when two writes to the same destination complete in the wrong order relative to the program. Out-of-order execution can cause this if completion order is not constrained.
Footnotes
-
Data hazards (RAW, WAR, WAW) — general definition and relationship to out-of-order execution - Defines data hazard types and their ordering implications. ↩ ↩2 ↩3
-
Instruction pipeline (stages and how timing affects dependencies) - Describes pipeline stages and typical timing relationships that lead to hazards. ↩
Data hazards vs. other hazards
It’s easy to confuse data hazards with:
- Control hazards from control-flow changes.
- Structural hazards from resource conflicts.
Data hazards specifically involve operand/value dependencies between instructions.
Footnotes
-
Hazards in pipelined processors (conceptual overview) - Discusses pipelining and pipeline hazards (including data hazards). ↩
How a CPU resolves a data hazard (stall vs forwarding)
- 1Step 1
Compare the consumer instruction’s source registers with the producer instruction’s destination registers to determine whether the needed value is not yet available.
- 2Step 2
Identify in which pipeline stage the producing instruction’s result becomes available (e.g., ALU result in EX vs memory result in MEM vs register write in WB).
- 3Step 3
If the required value exists in an intermediate pipeline register, route it directly to the consumer’s input (common for ALU-to-EX dependencies).
- 4Step 4
If the value is not available early enough (e.g., a load-use situation where data returns later), hold the consumer in place for one or more cycles.
- 5Step 5
Confirm that the consumer uses the value corresponding to the correct program order, preserving sequential semantics.
Example timing intuition (why stalls happen)
Consider a typical 5-stage pipeline (IF, ID, EX, MEM, WB). An instruction that writes a register may not update the register file until WB, but a dependent instruction may need the operand earlier (e.g., EX). If forwarding paths do not supply the value early enough (or the value is only available after MEM), the pipeline must stall the dependent instruction.
Footnotes
-
Instruction pipeline (stages and how timing affects dependencies) - Describes pipeline stages and typical timing relationships that lead to hazards. ↩
Common dependency outcomes in pipelined execution
Relative frequency across typical in-order pipelines (qualitative)
FAQ: Common questions about data hazards
Data Hazards Quick Deck
Knowledge Check
In a pipelined CPU, what does a data hazard primarily mean?