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
MEMstage to theIDstage, 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 foraddto calculate the branch parameter in theALUstage. A 3-clock cycle delay occurs if it’s alwinstruction, as we must wait until theMEMstage.
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.