Control hazards with jumps and branches

I've talked about the data hazards in a previous installment, now let's talk about control hazards. A control hazard is when we need to find the destination of a jump or a branch and can't fetch any new instruction until this destination is known.

When a branch instruction is fetched, it must then be decoded in the second cycle before the condition can be evaluated in the Execute stage during the third cycle. Only then can the CPU determine the new value for the PC.

The same happens with jump instructions: the destination of a JAL instruction is the sum of the current PC and an immediate value, the destination of a JALR instruction is the sum of a general purpose register and an immediate value. In both cases, this addition can only be performed after the instruction has been decoded.

But if the instruction is a jump or if it is a branch that must be taken, it means that the previous stages of the pipeline contain instructions that should not be executed. The processor needs to have a way to abort them before they reach any point where they could commit a change in the state of the machine. This operation is called "Flushing" the pipeline.

The signal for that is generated when the instruction moves from the Execute stage to the Mem stage.

Flush signal

If the instruction is a jump or a branch that is taken, the signal Flush@EX is active during the first half of the cycle, and is used to clear all the pipeline registers in previous stages IF/ID and ID/EX. phi2 is the complement of the clock signal. It goes high when the clock goes low, and in this case it is used to reset the flip-flop that sends the flush signal in the middle of the cycle. We don't want this signal to stay active for too long, or we would risk clearing the next instruction when it is fetched if the timing gets too tight!

In the case of a branch instruction that is not taken, the processor simply does nothing and continues as if it was a NOP instruction.

Anything else ?

I have only mentionned jumps and branches here, but there will be other reasons for the flow of instructions to be interrupted: interrupts, exceptions (maybe), breakpoints, and system calls, also known in the RISC-V world as environment calls. But these need the introduction of another bit of hardware in the processor, the Control and Status Registers (CSRs).

This post is part 9 of the "RiscV" series:

  1. A RISC-V processor from logic circuits
  2. Astorisc architecture overview: pipeline
  3. Astorisc: The pipeline stages and hazards
  4. Astorisc: Building blocks and components
  5. Just a few components ordered
  6. Astorisc: The simulation begins
  7. Of data hazards, bypasses and stalls
  8. I want a hardware multiplier
  9. Control hazards with jumps and branches
  10. A word on function calls and returns