Abstract


  • Problems that prevent next instruction form immediately following previous instruction

Pipeline Structural Hazard

  • Simultaneous use of a hardware resource which can be handle by Pipeline Stall or divide the stage into 2 parts, for example register stage can be divided into write and read. WB writes back first followed by ID reads

Pipeline Data Hazard

Pipeline Control Hazard

  • A situation that occurs in a pipeline when the flow of instructions is disrupted, usually due to a branch instruction (like jumps or conditional branches)

Performance hit!

We need to perform a Pipeline Flush, which results in losing the performance gains from Instruction-Level Parallelism. To minimise this, we can use Branch Prediction.

Solution 1: Early branch

For MIPS, a pipeline control hazard causes a 3-clock cycle delay due to pipeline flushing. A simple approach is to stall the pipeline for three clock cycles until the branch outcome is determined.

Early branching moves the branching decision from the MEM stage to the ID stage, resulting in only a 1-clock cycle delay because the branch decision is made during the second stage (ID).

However, if the branch parameter depends on an instruction like add, there will be a 2-clock cycle delay since we need to wait 1 clock cycle for add to calculate the branch parameter in the ALU stage. A 3-clock cycle delay occurs if it’s a lw instruction, as we must wait until the MEM stage.

Solution 2: Delayed branch

The idea is to move non-control-dependent instructions into the cycles needed to determine the branch outcome. This reordering is handled by the compiler, allowing the program to continue as long as the correctness of the program isn’t violated.

References