XiangShan VS riscv-boom

Are you calling for the government to pick a winner? The Chinese word for this fierce if at times chaotic competition is "juan". It worked for them in EV and PV. The outcome remains to be seen in chips and commercial space launches. But even their mostly (ex-)students-run open source Xiangshan RiscV project https://github.com/OpenXiangShan/XiangShan shows a remarkable level of sophistication.

> Certainly no RISC-V implementations that are in the hands of customers right now do any fusion and it doesn't seem to hurt their ability to match or exceed the performance of similar Arm cores (A55, A72).

You can play around with OpenXianShan though, they have a few fusion targets: https://github.com/OpenXiangShan/XiangShan/blob/master/src/m...

Most of the targets require the same destination, so it won't be able to fuse current codegen. I suppose there is still some time before compilers need to be ready, but it's not that much.

> Perhaps they will provide compiler patches if required.

I hope so, btw t-head seems to be still be trying to upstream XTheadVector: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/64278...

This is the most advanced open source risc-v implementation I'm awair of: https://github.com/OpenXiangShan/XiangShan

Maybe implement a big feature for a open source design? like vroom or xiangshan.

I did know about XiangShan, but not Aolai. Is it a Linux distribution?

If you are interested in high performance look into vroom , c910 and xianghan, maybe you could adopt one of them.

Looks like from Appendix D that only 2 bugs were found in BOOM:

> 1. Inaccurate instruction count when minstret is written by software

I don't know what that means, but having minstret written by software was definitely not something I ever tested. In general, perf counters are likely to be undertested.

> 2. Static rounding is ignored for fdiv.s and fsqrt.s

A mistake was made in only listening to the dynamic rounding mode for the fdiv/sqrt unit. This is one of those bugs that is trivially found if you test for it, but it turns out that no benchmarking ever cared about this and from all of the fuzzers I used when I worked on BOOM, NONE of them hit it (including commercial ones...). Ooops.

Fixed here: https://github.com/riscv-boom/riscv-boom/pull/629/files

The two most micro architecturally advanced cores that I know of are BOOM, an out of order RV64GC core with all the features you expect plus sort of weird fancy things like short forward branch predication, and VROOM, another out of order RV64GC core with things like uop fusion and a trace cache.

it is used in the Berkley Out-of-Order RISC-V processor: https://github.com/riscv-boom/riscv-boom

SonicBOOM: https://github.com/riscv-boom/riscv-boom

Some cores are open source and you can see for yourself.

Rename logic from BOOM, a RISC-V core written in a DSL embedded in Scala:

https://github.com/riscv-boom/riscv-boom/blob/1ef2bc6f6c98e5...

From RSD, a core designed for FPGAs written in SystemVerilog:

https://github.com/rsd-devel/rsd/blob/master/Processor/Src/R...

And then there's the recently open-sourced XuanTie C910, which contains this Verilog… which is completely unreadable. Seems like it was produced by some kind of code generator that they didn't open-source?

https://github.com/T-head-Semi/openc910/blob/d4a3b947ec9bb8f...

We don't have Sifive's specifically but we do have the open source cores they've historically used to design their cores: https://github.com/riscv-boom/riscv-boom https://github.com/chipsalliance/rocket-chip

If you look at the decoder (https://github.com/riscv-boom/riscv-boom/blob/master/src/main/scala/exu/decode.scala), you can see that the fence instructions are also marked as "unique" instructions. Only one "unique" instruction is allowed in the pipeline at a time.