737 FSM based RISC-V Pipeline Hazard Resolver :: Quicker, easier and cheaper to make your own chip!

FSM based RISC-V Pipeline Hazard Resolver

Credits

We gratefully acknowledge the Centre of Excellence (CoE) in Integrated Circuits and Systems (ICAS) and Department of Electronics and Communication (ECE) for providing the necessary resources and guidance. Special thanks to Dr. H V Ravish Aradhya (HOD-ECE), Dr. K S Geetha (Vice Principal) and Dr. K N Subramanya (Principal) for their constant support and encouragement to carry out this Tiny Tapeout SKY25a submission.

How it works

The FSM continuously observes the pipeline to detect hazards that could disrupt correct instruction execution. It has six states: Normal (Nor) for hazard-free execution, Control (Con) for handling branches, Flush for clearing mispredicted instructions, Data (Dat) when a read-after-write conflict is detected, StaN for multi-cycle stalls caused by unresolved data hazards, and StaSin for single-cycle stalls due to structural conflicts.

->Control Hazard occur when a branch instruction enters the pipeline, the FSM transitions from Nor to Con and freezes the program counter to prevent new instructions from being fetched. If the branch resolves correctly, the FSM returns to Nor. If the prediction is wrong, the FSM goes into Flush for one cycle, asserting the flush signal to clear wrong-path instructions before resuming execution.

->Data hazards are detected whenever one instruction needs data that has not yet been written back by a previous instruction. If forwarding hardware is available, the FSM allows immediate continuation by staying in Nor. If forwarding is unavailable, the FSM first enters Dat and then moves to StaN, where it holds the pipeline in a multi-cycle stall until the data dependency is cleared.

->Structural hazards occur when two instructions require the same hardware resource at the same time, for example, a memory access and an ALU operation sharing a single data bus. In this case, the FSM transitions into StaSin, freezing the program counter for one cycle or until the conflict is resolved.

Outputs are generated based on the current state. pc_freeze is asserted during stalls and branch waits to stop the fetch stage. do_flush is asserted for one cycle when a mispredicted branch is detected to clear invalid instructions. resolved is high only during Nor, indicating hazard-free execution. Reset is synchronous and active-low; when asserted, the FSM always returns to Nor, ensuring safe startup.

How to test

The FSM is tested in simulation by generating sequences that mimic hazards and observing the resulting transitions. When branch instructions are applied the machine should move into the control state and then either return to normal or pass through the flush state depending on the correctness of the prediction. When data hazards are applied with forwarding enabled the FSM must remain in normal operation, while disabling forwarding should cause it to move into the data detection and stall states until the hazard clears. Structural hazards are verified by forcing a resource conflict and checking that the FSM enters the single-stall state before resuming normal execution. Reset is tested by asserting the reset signal during different states and confirming that the FSM always returns to normal. Simulation waveforms make it possible to verify that the program counter freeze, flush, and resolved outputs behave exactly as intended.

External hardware

The design is self-contained and requires only a clock and a synchronous active-low reset to operate. It connects to the rest of the processor pipeline through simple control signals. The hazard indicators for branches, data dependencies, and structural conflicts are generated by the pipeline itself and are received as inputs by the FSM. In return the FSM drives outputs that freeze the program counter, trigger flushes, and signal when execution is hazard free. No additional external components are required. In an FPGA environment the FSM can be integrated directly into the processor control path, with its outputs optionally connected to LEDs or a logic analyzer for visibility. In an ASIC implementation it becomes part of the pipeline control logic, interacting entirely within the chip without the need for external hardware.

#	Input	Output
0
1
2	ui_in[2]
3	ui_in[3]
4	ui_in[4]
5	ui_in[5]	uo_out[5]
6	ui_in[6]	uo_out[6]
7	ui_in[7]	uo_out[7]

737 FSM based RISC-V Pipeline Hazard Resolver