Yet Another RISC-V Implementation
YARVI2 is an FPGA-focused in-order scalar RISC-V softcore with branch prediction. The original, YARVI, was the first non-Berkely freely available RISC-V softcore implementation. YARVI2 is a complete rewrite for better performance.
YARVI2 is free and open hardware licensed under the ISC license (a license that is similar in terms to the MIT license or the 2-clause BSD license).
RV32I implemented and tested (regress with make comply test
)
Eight stage pipeline
YAGS branch predictor, jump, call, and return address predictor
Current performance
On a Lattice Semi ECP5 85F, speed grade 6 (as per make fmax ipc
):
On an Altera Cyclone-V A9 C8
Note, the ALU can run at 111 MHz, but the critical path is the CRS handling - this is a current focus. The YAGS Branch Prediction currently limits performance to ~ 85 MHz. One option is to pipeline YAGS, and partially hide the latency by decoupling the predictor from fetch.
loads have a two cycle latency and use will stall as needed (known as a load-use hazard)
loads that execute before a prior store to the same address has completed will be restarted (known as a load-hit-store hazard, has a 7 cycle penalty, needs two instruction separation to avoid)
We have eight stages:
result forwarding
v---+----+----+----+
s0 s1 s2 s3 s4 s5 s6 s7 s8
PC | IF1 | IF2 | RF | DE | EX | CM | WB | -
^--- stall -----/
^----- pipeline restarts ------/
Results can be forwarded from s5, s6, s7, or s8. There is a seven cycle mispredict penalty, same for load-hit-store. Loads take two cycles (one more than ALU) and can incur up to two stall cycles.
S8 isn't really a stage, but as we read registers in s3 any writes happening in s7 wouldn't be visible yet so we'll have to forward from s8.
Currently the pipeline can be restarted (and flushed) only from s6 and causes the clear of all valid bits.
The pipeline might be invalidated or restarted for several reasons:
Expect more performance, more features
High priority:
Planned:
Considering:
Wishlist: