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
- A Pipeline Hazard occurs when an Instruction depends on the result of a previous instruction. This can be managed using Operand Forwarding and a Pipeline Stall
- One common example is Read-After-Write(RAW) 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 theID
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 foradd
to calculate the branch parameter in theALU
stage. A 3-clock cycle delay occurs if it’s alw
instruction, as we must wait until theMEM
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.