Control Hazard

computer-architecture

Definition

Control Hazard

A control hazard is a pipelined hazard in which the next instruction to fetch is not yet known.

This usually happens for branch or jump instructions, because the processor must first determine whether control flow continues with the sequential next instruction or with a different target address.

In a classic pipeline, this is often harder than a data hazard, because the processor may only know in the execute stage whether the branch is taken.

Branch case

Branch resolved late

Consider a classic five-stage pipeline with fetch, decode, execute, memory access, and write-back.

If a branch is resolved only in the execute stage, then the instructions after the branch may already have passed through the fetch stage before the branch decision is known.

So if the branch is taken, those younger instructions are wrong and must be flushed.

Handling

Flushing wrong-path instructions

A standard response is to let the branch continue until its decision is known in the execute stage, and then flush the instructions that were fetched from the wrong path.

In the classic five-stage case, this often means that two following instructions may already be in fetch and decode and must be discarded if the branch is taken.

Flushing Logic

Flushing Logic

If a branch is taken in the execute stage, then the younger instructions currently in the fetch and decode path are wrong and must be flushed.

A common implementation does this by clearing the affected pipeline registers.

In a standard five-stage pipeline, one often uses:

$$\mathrm{FlushD}=\mathrm{PCSrcE}$$ $$\mathrm{FlushE}=\mathrm{lwStall}\vee \mathrm{PCSrcE}$$

Here $\mathrm{PCSrcE}$ means that the next program counter value is selected from the branch target in the execute stage.

So:

• FlushD removes the wrong-path instruction that is currently in decode;
• FlushE is asserted both for load-use stalls and for taken branches.

Example

Taken branch

Consider the instruction sequence:

beq s1, s2, L1
sub s8, t1, s3
or  s9, t6, s5
...
L1: add s7, s3, s4

If beq is taken, the processor should jump to L1. But if the branch decision is only known in the execute stage, then sub and or may already have been fetched.

These instructions lie on the wrong path, so they must be flushed. After that, fetching continues at L1.