Three Types of Hazards

Three Types of Hazards

What are Pipeline Hazards?

Pipeline hazards are issues that disrupt the smooth flow of instructions through a CPU pipeline, causing delays or stalls. They reduce the efficiency of pipelining by preventing instructions from advancing as planned.

Why Hazards are Important

• Impact Performance: Hazards slow down instruction execution, reducing CPU throughput.

• Design Consideration: CPU architects must address hazards to maximize pipeline efficiency.

• Optimization: Understanding hazards helps in implementing solutions like forwarding, prediction, or scheduling.

Three Types of Pipeline Hazards

Hazards are classified into three categories: Data Hazards, Control Hazards, and Structural Hazards. Below is a detailed explanation of each.

1. Data Hazard

• Definition: Occurs when instructions depend on the results of previous instructions that are still in the pipeline, leading to incorrect data access.

• Types:

  • RAW (Read After Write): An instruction needs a result that a prior instruction hasn’t written yet (most common).

  • WAR (Write After Read): A later instruction writes to a register before an earlier instruction reads it.

  • WAW (Write After Write): Two instructions try to write to the same register in the wrong order.

• Example (RAW Hazard):

  ADD R1, R2, R3  ; R1 = R2 + R3
  SUB R4, R1, R5  ; R4 = R1 - R5

  • SUB needs R1 from ADD, but ADD is still in the pipeline (e.g., Execute stage).

• Solution:

  • Stalling: Pause the pipeline until the data is ready.

  • Forwarding (Bypassing): Pass the result directly to the dependent instruction.

  • Instruction Reordering: Compiler rearranges instructions to avoid dependencies.

2. Control Hazard

• Definition: Occurs when the pipeline cannot determine the next instruction due to a branch or jump (e.g., if-else or loops), causing a delay.

• Cause: Branch instructions (JUMP, BEQ) change the Program Counter (PC), but the correct address isn’t known until the branch is resolved (e.g., in Execute stage).

• Example:

  BEQ R1, R2, Label  ; Branch to Label if R1 = R2
  ADD R3, R4, R5     ; Next instruction

  • If the branch is taken, ADD should not execute, but it’s already fetched.

• Solution:

  • Branch Prediction: Guess the branch outcome (e.g., taken or not taken) and proceed.

  • Delayed Branching: Insert useful instructions (or NOPs) in the delay slot.

  • Flush Pipeline: Discard fetched instructions if the branch prediction is wrong.

  • Speculative Execution: Execute both paths and discard the wrong one.

3. Structural Hazard

• Definition: Occurs when multiple instructions compete for the same hardware resource (e.g., memory, ALU) at the same time.

• Cause: Limited resources in the CPU cannot support simultaneous access by pipeline stages.

• Example:

  • Two instructions in a 5-stage pipeline try to access memory in the same cycle:

    LOAD R1, 1000  ; Fetch data from memory
    ADD R2, R3, R4 ; Access memory for instruction fetch

    • Both need the memory unit, causing a conflict.

• Solution:

  • Resource Duplication: Add more hardware (e.g., separate instruction and data caches).

  • Stalling: Delay one instruction until the resource is free.

  • Pipeline Scheduling: Reorder instructions to avoid resource conflicts.

Example Breakdown

Consider a 5-stage pipeline (Fetch, Decode, Execute, Memory, Write Back):

• Data Hazard:

  • ADD R1, R2, R3 (in Execute) writes to R1.

  • SUB R4, R1, R5 (in Decode) needs R1, causing a stall unless forwarding is used.

• Control Hazard:

  • BEQ R1, R2, Label (in Execute) decides the branch.

  • Next instructions are fetched but may be discarded if the branch is taken, requiring a flush.

• Structural Hazard:

  • LOAD R1, 1000 (in Memory stage) and instruction fetch (in Fetch stage) both need memory, causing a stall.

Where Hazards Occur

• Pipelined CPUs: Common in RISC (e.g., ARM, MIPS) and CISC (e.g., x86) processors.

• High-Performance Systems: More stages increase hazard risks.

• Compilers: Must optimize code to minimize hazards.

• Real-Time Systems: Hazards can disrupt time-sensitive operations.

Why Hazards Matter in COA

• Performance Impact: Stalls and flushes reduce the benefits of pipelining.

• Design Complexity: CPUs need extra hardware (e.g., forwarding units, predictors) to mitigate hazards.

• Optimization: Understanding hazards guides better instruction scheduling and hardware design.

• Real-World Relevance: Affects speed in applications like gaming, AI, and servers.

Additional Insights

• Frequency:

  • Data hazards are most common due to frequent register dependencies.

  • Control hazards are significant in programs with many branches (e.g., loops).

  • Structural hazards are less common with modern resource-rich CPUs.

• Modern Mitigations:

  • Out-of-Order Execution: Reorders instructions dynamically to avoid stalls.

  • Superscalar Pipelines: Multiple pipelines reduce resource conflicts.

  • Cache Design: Separate instruction/data caches prevent memory conflicts.

• Limitations:

  • Mitigating hazards adds hardware complexity and power consumption.

  • Some hazards (e.g., unpredictable branches) are hard to eliminate completely.

• Compiler Role: Reorders instructions or inserts NOPs to reduce hazard occurrences.

Summary Table

Hazard Type	Cause	Solution
Data	Instruction depends on prior result.	Forwarding, stalling, reordering.
Control	Branch delays next instruction fetch.	Branch prediction, delayed branching.
Structural	Resource conflict between instructions.	Resource duplication, stalling.