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

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

L1: LW   R2    0(R1)
SW   R2    0(R1)
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?

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.
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.