Why does this branch data hazard happen during the instruction decode stage?

Question

Suppose I have the following MIPS code on a CPU with forwarding enabled:

L1: LW   R2    0(R1)
    ADDI R2    R2    2
    SW   R2    0(R1) 
    ADDI R1    R1    8
    SUB  R4    R1    R3
    BNEZ R4    L1

The last two lines are of importance for me.

My intuition is that the output to R4 is calculated during the EX stage of the pipeline, and should be ready in time for the BNEZ instruction to EX in the next cycle. However, I'm getting this output from WinMIPS64:

Why is there a hazard during the ID stage? Forwarding is enabled, so it ought to know R4 will be available at the next stage of the pipeline, when it needs to evaluate if R4 == 0, but it still adds a bubble.

What am I missing here?

Answer 1

In the MIPS pipeline, for branches and jumps, all of the arithmetic is done in the instruction decode portion of the pipeline. See this MIPS handbook pg. 9, or this handy UCSD ppt. explaining the rationale for this design choice on slide 14.

It used to be the case that all of that stuff would happen during the EXE stage, and the program counter would be updated in the MEM stage; however, by adding hardware to evaluate those things during the ID stage, an incorrect branch prediction only comes with a 1 cycle penalty.

See the difference visualized here:

Evaluating the condition during EXE and updating the PC during MEM:

Vs. Evaluating the condition and updating the PCduring ID

Thus, in my original question, the reason there's a RAW hazard during the ID stage is because the R4 operand isn't ready in time to be evaluated during the ID stage. Using the old architecture, the hazard would be avoided, but an incorrect branch prediction would result in a far worse stall.