Overview
A pipeline hazard is a condition in a pipelined microprocessor that may require the pipeline to stall rather than make normal program-execution progress in a given cycle. In the cited verification work, a pipelined processor cycle is allowed to correspond to zero steps of the sequential ISA model when the pipeline stalls to handle a hazard condition.[1]
Pipeline hazards matter because pipelined implementations overlap multiple instructions for performance while still needing to implement the same sequential semantics specified by the instruction set architecture (ISA). Interlocking and data forwarding are used so that the overlapped execution remains faithful to the ISA model.[2]
Data hazards and stalls
The evidence describes a STALL pipeline variant in which no data forwarding is used. In that design, an instruction can stall in the decode stage for up to three cycles whenever an instruction farther down the pipeline imposes a data hazard.[3]
This shows a typical hazard-handling pattern:
- a later pipeline stage contains an instruction whose result or effect is needed by an earlier-stage instruction;
- the earlier-stage instruction cannot safely proceed immediately;
- the pipeline control logic stalls the affected instruction until the dependency is resolved.[3]
Forwarding as mitigation
The evidence also describes an LF pipeline variant that adds a forwarding path between the data-memory output and the pipeline register feeding the data-memory input. This added forwarding path allows some load/use hazards to be resolved by data forwarding rather than by stalling.[4]
Thus, forwarding is a hazard-mitigation mechanism: it can reduce the number of stalls required for some hazard cases, but the cited evidence only states this explicitly for some forms of load/use hazards.[4]
Verification relevance
Pipeline hazards are also relevant to formal verification. Burch-Dill correspondence checking can prove a safety property: each cycle of the pipelined processor has an effect consistent with some number of steps of the ISA model. Because the number of ISA steps may be zero, a stalled cycle can still satisfy the safety property.[5]
However, safety alone is insufficient to rule out a processor that never makes forward progress. The cited report therefore states that liveness must also be verified: the processor must not reach a state where it never makes forward progress, and the pipeline must not stall indefinitely.[6]
Related control events
The same evidence distinguishes hazard-related stalls from instruction cancellation due to branch misprediction. In the described pipeline variants, branches may be predicted not taken or predicted by a backward-taken/forward-not-taken rule, and up to two instructions are canceled if the branch is mispredicted.[7]
[1]: See citation "Hazard conditions can cause pipeline stalls". [2]: See citation "Pipelining overlaps instructions while preserving ISA semantics". [3]: See citation "Data hazards can stall decode for up to three cycles". [4]: See citation "Forwarding can resolve some load/use hazards". [5]: See citation "Safety checking can allow zero ISA steps during stalls". [6]: See citation "Liveness is needed to rule out indefinite stalls". [7]: See citation "Mispredicted branches can cancel instructions".