Pipeline Hazards in Pipelining: Definitions and Types

In pipelined processors, multiple instructions overlap in time by using different hardware stages (e.g., fetch, decode, execute, memory, writeback). A pipeline improves throughput but introduces hazards—events where the pipeline cannot proceed “as if” each instruction had completed before the next one started. The result is typically a stall (bubble), flush, or re-routing of control flow.

Pipeline hazards are commonly classified into three types:

1. Structural hazards
2. Data hazards
3. Control hazards

A useful mental model is: each pipeline stage expects specific inputs at a cycle boundary; hazards violate that assumption, forcing the control logic to intervene.

Key terms you’ll use repeatedly

• stall
• forwarding
• flush
• branch prediction
• bubble

1) Structural Hazards (Resource Conflicts)

A structural hazard occurs when the pipeline needs a hardware component for multiple stages in the same cycle, but the component is not available in the needed number or configuration.

Example pattern (conceptual):

• Stage for instruction $I_k$ needs the ALU
• Stage for instruction $I_{k+1}$ also needs the same ALU in the same cycle
• If the design offers only one ALU instead of two, one stage must wait → stall.

How to reason about it:

• Structural hazards are about hardware capability, not about data timing or branch outcomes.
• If you resolve it by adding hardware (e.g., separate instruction and data memories in a Harvard design), the hazard disappears.

Key pipeline technique

Important: Structural hazards occur mainly in simpler designs; modern “classic” pipeline teaching models often assume enough resources so the main focus is data/control hazards.

2) Data Hazards (Operand Timing Dependencies)

A data hazard occurs when an instruction requires a value that is produced by an earlier instruction but has not yet reached the stage where it can be used.

Data hazards are the most studied because they directly affect the correctness and performance of pipelined execution.

2.1 Read After Write (RAW)

The most common data hazard is RAW (Read After Write).

Conceptual example:

• Instruction $I_1$ computes register $R1$
• Instruction $I_2$ needs $R1$ as an ALU input immediately
• If $I_2$ reaches Execute before $I_1$ has produced/written the value, $I_2$ uses stale data.

This is the typical cause of load-use stalls and the key target for forwarding.

2.2 Forwarding vs Stalling

A forwarding path can reduce stalls by supplying the needed value directly from an intermediate pipeline stage.

When forwarding cannot fully resolve the dependency (e.g., a load value may not be available early enough), the pipeline inserts a stall (bubble).

2.3 Write After Read (WAR) and Write After Write (WAW)

Classic in-order pipelines typically do not produce WAR/WAW hazards in the same way because:

• Instructions advance in order through stages (no out-of-order completion)
• Writes occur at a consistent stage timing

However, these hazards become relevant in out-of-order designs with register renaming, where the pipeline may allow reordering of completion/writeback.

For an in-order pipeline, focus primarily on RAW.

3) Control Hazards (Uncertainty in Branch/Jump)

A control hazard happens because the processor does not immediately know:

• whether a branch is taken or not taken
• the target address (especially for indirect jumps)
• therefore which instructions are on the correct path

While the pipeline speculatively fetches the next instructions, some may be wrong once the branch outcome is resolved—these must be handled via stalling and/or flushing.

Common causes

• Branch condition evaluation happens in a later stage than Fetch/Decode.
• Target computation may also be delayed.

Mitigation strategies

1. Branch prediction: continue fetching based on the guess
2. Flush when the guess is wrong
3. Delayed branching (historic/simple approach in some designs)

Visual summary: when each hazard happens