Hazards in Pipeline Architecture: Types, Causes, and Examples

In pipelined processors, Pipeline hazard occurs when the next instruction depends on results or resources not yet available, or when control flow changes what should be fetched/decoded. Hazards are a core reason pipelines insert Stalls, Forwarding, or Pipeline flush.

Why hazards happen (conceptual)

A typical instruction pipeline overlaps stages (e.g., IF → ID → EX → MEM → WB). When instruction i+1 advances to a stage before instruction i has produced what i+1 needs, the pipeline must intervene. The three canonical categories are:

• Data hazards (e.g., RAW)
• Control hazards (branches/jumps)
• Structural hazards (resource conflicts)

3

Footnotes

1. Patterson & Hennessy, “Computer Organization and Design” (Pipeline hazards overview) https://github.com/DavidGekas/Patterson-Hennessy/blob/master/CA/CA07_Pipelining.pdf - Notes covering structural/data hazards and basic pipeline timing ↩

2. Stanford CS: “Pipeline Hazards” lecture notes (data/control hazards, load-use, flushing) https://web.stanford.edu/class/cs321/ - Course materials on pipelining and hazards (multiple lecture pages; concept coverage) ↩

3. GeeksforGeeks, “Pipeline Hazards in CPU (Structural, Data and Control)” https://www.geeksforgeeks.org/pipeline-hazards-structural-data-control/ - Clear breakdown of hazard types with examples and mitigation ideas ↩

Types of hazards with suitable examples

1) Data hazards

Data hazard happens due to instruction dependency and timing mismatch. The most common is RAW (Read After Write).

Classic 5-stage pipeline backdrop (MIPS-like)

A common pipeline model:

• IF: fetch instruction
• ID: decode/register read
• EX: execute/ALU
• MEM: memory access
• WB: write back to register file

Data hazards occur when dependent instructions are too close together. Textbook examples use register dependencies.

Example A: ALU-ALU dependency (RAW) → forwarding can fix

Consider:

• add r1, r2, r3 (produces r1)
• sub r4, r1, r5 (needs r1)

If sub reaches EX before add has written r1 to the register file, the value may not be available from the normal read path. With Forwarding, the pipeline can route the ALU output directly to the next instruction’s EX stage, avoiding a stall in many designs. This is a standard mitigation technique for RAW hazards. 3

Example B: Load-use hazard (RAW) → forwarding often not enough

Now:

• lw r1, 0(r2) (loads r1 from memory)
• add r3, r1, r4 (immediately uses loaded r1)

In a 5-stage pipeline, the loaded data typically becomes available after the MEM stage, but the dependent add may need it in EX one cycle earlier. Many classic pipelines therefore insert a stall (bubble) for one cycle (or use specialized designs). This is a canonical “load-use” data hazard example. 2

Key takeaways for data hazards

• RAW is the main worry.
• ALU result dependencies are often resolvable with forwarding.
• Load results may require stalls because memory data latency pushes availability later than EX needs it. 3

---

2) Control hazards

Control hazard occurs because the pipeline must decide which instruction to fetch next, but the decision may depend on data computed in a later stage (e.g., branch condition in EX) or on a branch prediction policy.

Example A: Branch decision late → wrong-path fetches

Assume a pipeline where:

• Branch target/condition is resolved in EX.
• Meanwhile, the pipeline continues fetching along the “fall-through” path.

If the branch is taken, instructions fetched during the delay become incorrect and must be removed using a Pipeline flush. Alternatively, branch prediction may guess correctly most of the time and reduce the penalty. These concepts are central in control hazard handling. 2

Example (conceptual):

1. beq r1, r2, L
2. Next cycle fetches instr_after_branch
3. If beq is taken, fetched instr_after_branch must be squashed.

Mitigations

• Static prediction (e.g., predict not-taken) or
• Dynamic prediction (e.g., 2-bit saturating counters) plus
• Flush on misprediction.

Control hazards and their mitigations are widely discussed in pipeline-control literature. 2

---

3) Structural hazards

Structural hazard occurs when the hardware is not capable of supporting the concurrent needs of multiple instructions in the same cycle.

Example A: Single memory for instruction fetch and data access

Classic pipeline designs assume separate instruction and data memories. If instead the processor uses one shared memory, then in a single cycle:

• IF wants to fetch the next instruction, while
• MEM wants to access data for a load/store.

If both must happen concurrently but the hardware provides only one memory port, the pipeline must delay one of them (stall). This is the canonical structural hazard example. 2

Mitigation

• Add/duplicate hardware resources (e.g., separate I-cache and D-cache),
• or multi-port memory,
• or schedule pipeline stage operations to avoid conflicts.

Structural hazards are eliminated by providing adequate resources (e.g., split instruction/data memory). 2

Footnotes

1. Patterson & Hennessy, “Computer Organization and Design” (Pipeline hazards overview) https://github.com/DavidGekas/Patterson-Hennessy/blob/master/CA/CA07_Pipelining.pdf - Notes covering structural/data hazards and basic pipeline timing ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Stanford CS: “Pipeline Hazards” lecture notes (data/control hazards, load-use, flushing) https://web.stanford.edu/class/cs321/ - Course materials on pipelining and hazards (multiple lecture pages; concept coverage) ↩ ↩² ↩³ ↩⁴ ↩⁵

3. GeeksforGeeks, “Pipeline Hazards in CPU (Structural, Data and Control)” https://www.geeksforgeeks.org/pipeline-hazards-structural-data-control/ - Clear breakdown of hazard types with examples and mitigation ideas ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶