Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 50 of 9361. Foundations of Digital Logic and Computer ArchitectureFree lesson

Resolving Hazards in Pipelined Instruction Execution

You will identify and mitigate data and control hazards that arise when instructions depend on the results of preceding operations.

Resolving Hazards in Pipelined Instruction Execution

In this lesson, you will learn how to identify and resolve the timing conflicts, known as hazards, that prevent instructions from flowing smoothly through a processor pipeline.

When we use pipelining to increase throughput, we overlap the execution of multiple instructions. However, this creates a "hazard"—a situation where the next instruction cannot execute in the following clock cycle because it depends on an operation currently in progress.

Understanding Data Hazards

A data hazard occurs when an instruction needs the result of a previous instruction that hasn't finished writing to the register file yet. Consider this sequence:

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

The SUB instruction needs the value of R1. However, in a standard pipeline, the ADD instruction doesn't update R1 in the register file until its final stage. The SUB instruction will read an "stale" (old) value of R1 because the write-back hasn't occurred.

Mitigating the Hazard

We can resolve this using two primary techniques:

  1. Forwarding (Bypassing): This is the most efficient solution. We add extra data paths that "tap" the result directly from the ALU output before it is written to the register file, feeding it immediately into the input of the next instruction's ALU operation. We essentially "short-circuit" the slow register write process.
  2. Stalling (Bubbles): If forwarding isn't enough (like when a LOAD instruction is involved), the control unit must insert a "bubble" into the pipeline. This freezes the dependent instruction for one or more clock cycles, effectively delaying its execution until the required data is ready in the register file.

Understanding Control Hazards

A control hazard occurs during branches or jumps. The pipeline fetches the next instruction (the one immediately following the branch) before it knows if the branch is taken. If the branch is taken, that fetched instruction is wrong. We resolve this by flushing the pipeline (discarding the wrong instruction) or using branch prediction logic to guess the path.

Key Takeaway: Hazards break the smooth flow of a pipeline, but we maintain correctness by using forwarding to share data early or stalling to wait for data to become valid.