Hazard detection units

What Problem Does It Solve?

In a pipelined processor, multiple instructions execute simultaneously across different stages (IF, ID, EX, MEM WB). But what if instruction2 needs the result of instruction 1 before instruction 1 writes it back? Or what if a branch changes the PC while the pipeline already fetched wrong instructions?

The hazard detection unit is dedicated combinational logic that:

1. Monitors pipeline registers for dependencies
2. Generates control signals (stall, flush, forward)
3. Coordinates with the forwarding unit to resolve hazards

Why combinational? Decisions must happen within a single clock cycle—before the next clock edge commits wrong values.

Types of Hazards Detected

Architecture: Data Hazard Detection Logic

The Detection Combinational Circuit

The hazard detection unit sits in the ID stage and examines:

• ID/EX register: The instruction currently in EX
• EX/MEM register: The instruction currently in MEM
• MEM/WB register: The instruction currently in WB
• IF/ID register: The instruction currently in ID

Why ID stage? This is where we decode the instruction and know which registers it reads. We can detect dependencies before EX tries to use stale data.

Why this matters: Other data hazards can be resolved by forwarding (the forwarding unit handles those). The hazard detection unit only stalls when forwarding is impossible.

Stall Signal Generation

When the condition above is true, the hazard unit asserts:

• PCWrite = 0: Freeze the PC (don't fetch next instruction)
• IF/ID_Write = 0: Freeze IF/ID register (keep current instruction in ID)
• Control_Mux = 0: Insert a NOP (bubble) into ID/EX by zeroing all control signals

Why these three signals?

1. PCWrite=0: If we fetch the next instruction, we'd lose it when we finally advance
2. IF/ID_Write=0: Hold the dependent instruction in ID so it retries next cycle with correct data
3. Control_Mux=0: The instruction that was going to move from ID→EX must become a bubble (no operation) so it doesn't corrupt the pipeline

Architecture: Control Hazard Detection

Branch Resolution and Flushing

For branches, the hazard detection unit must:

1. Detect the branch early (ideally in ID by comparing registers)
2. Flush wrong-path instructions if branch is taken
3. Optionally predict (simple version: assume not-taken)

Optimization: Early branch resolution in ID

• Add comparison hardware in ID stage (instead of waiting for ALU in EX)
• Compute branch target in ID using an adder
• Reduces branch penalty from 3 cycles to 1 cycle

Interaction with Forwarding Unit

The hazard detection unit and forwarding unit are separate but coordinated:

| Unit | Purpose Placement | Action | |------|---------|--------|-----| | Forwarding Unit | Resolve hazards bypassing register file | EX stage | Muxes data from EX/MEM or MEM/WB directly into ALU inputs | | Hazard Detection Unit | Detect unsolvable hazards (load-use) | ID stage | Stalls pipeline when forwarding can't help |

Why separate?

• Forwarding is about data routing (mux selection)
• Hazard detection is about control flow (stall/flush signals)

Implementation Details

Simplified Verilog Sketch

module hazard_detection_unit(
    input [4:0] IF_ID_Rs, IF_ID_Rt,
    input [4:0] ID_EX_Rd,
    input ID_EX_MemRead,
    output reg Stall
);
    always @(*) begin
        // Load-use detection
        if (ID_EX_MemRead && 
            ((ID_EX_Rd == IF_ID_Rs) || (ID_EX_Rd == IF_ID_Rt))) begin
            Stall = 1;  // Assert stall signals
        end else begin
            Stall = 0;
        end
    end
endmodule

Why this works:

• Combinational (always @(*)) so output updates immediately
• Checks the one-cycle delay case where load is in EX and dependent instruction is in ID
• Real implementations also check for Rd != 0 (register 0 is hardwired to zero in MIPS)

Advanced: Handling Multiple Hazards

What if multiple hazards exist in the same cycle?

Priority rules:

1. Load-use hazard (stall) takes priority—must resolve first
2. Branch hazard (flush) applied after stall completes
3. Forwarding happens after stall, using the now-available data

Connections

• 5.2.8-Pipeline-registers: Hold the instruction and control signals between stages
• 5.2.9-Forwarding-unit: Resolves most data hazards without stalling
• 5.2.11-Branch-prediction: Reduces control hazard penalties (advanced topic)
• 5.2.7-Pipeline-control-signals: The signals (RegWrite, MemRead, etc.) that hazard detection examines
• 5.1.3-Control-unit: Generates the original control signals; hazard unit can override them (mux to NOP)

#flashcards/hardware

What does a hazard detection unit do in a pipelined processor? :: It monitors pipeline registers for data/control dependencies and generates stall or flush signals to prevent hazards from corrupting results. It coordinates with the forwarding unit to resolve hazards when possible.

Concept Map

Hinglish (regional understanding)