Control Hazards

A control hazard arises when an instruction can not execute in its planned clock cycle because the instruction that was fetched is not the one needed. This occurs if the pipeline executes an instruction which is later determined to be not branched to by the instruction flow.

An example while doing laundry would be within the task to clean the uniform of a football team. Based on how dirty the laundry is, you need to determine how much detergent and which water temperature is needed to clean the laundry properly without wearing out the uniform. In our laundry pipeline, we would have to wait until the second stage to examine the dry uniform to see if it is clean enough or if we need to change the washer setup.

For control hazards there are 2 possible solutions:

• Stall
  We operate sequentially until the first load is dry and repeat until we have the right formula.
  This solution works, but is very slow.
• Predict
We predict that we have the right formula for our task and wash the second load while waiting for the first one to dry.
This solution does not slow down the pipeline when guessing correctly. However, if we guess wrong, we need to redo the load washed before.

In a processor pipeline, the equivalent decision is the conditional branch instruction (beq). The problem is that the pipeline can not know to which instruction it should branch to at the time the next instruction is about to be loaded into the pipeline, since the beq instruction only passed the instruction fetch (IF) stage.

Possible solutions are again:

• Stall
  We wait until the pipeline determines the outcome of the branch and knows what instruction adress to fetch from.
• Predict
  We use prediction to handle conditional branches. A simple approach is to predict that conditional branches will always be untaken. The pipeline proceeds, if correctly predicted, but is stalled when conditional branches are taken. Analogously, we could predict that conditional branches will always be taken or something inbetween.

There are several other approaches on when and how to predict a branch as untaken or taken, e. g. by keeping track of recent branch outcomes to predict upcoming ones.
In either case, the control logic for executing branch predictions is rather complex and moves away from our approach to keep an abstract view on pipelining and datapath, why this topic remains lightly touched.

« Data Hazards