[ruslan]

Thanks, will check it. I'm playing with FPGAs for a couple of weeks only, RISCV was a starting force for me. Currently am trying to figure our which is better SpinalHDL or Chisel. I find SpinalHDL's syntax more convenient and less verbose, but Chisel has way larger support from HiFive surrounding community.

[ekiwi]

I think in general Chisel has more people working on it. However, most people using Chisel are targeting ASICs, thus Spinal HDL wins when it comes to supporting features that are important to FPGAs. Chisel also hasn't anything close to the awesome VexRiscV core which was developed for FPGAs. The most developed cores written in Chisel are much bigger and more complex as they target ASICs. See the chipyard repository which tries to lower the learning curve a little bit : https://github.com/ucb-bar/chipyard/

[ruslan]

This is very interesting. I thought Berkeley's BOOM is way more advanced implementation of RISCV than VexRiscV and it is written in Chisel3. Though I have not played with BOOM yet, cannot say how deeply can it be configured. But you seem right, BOOM does not look like most effective in terms of LUTs utilisation core. Another thing I also disliked in Chisel3 is dependancy on new intermediate representation of hardware (FIRRTL) which adds one more layer of abstraction and compilation.

[ekiwi]

> I thought Berkeley's BOOM is way more advanced implementation of RISCV than VexRiscV and it is written in Chisel3.

It is a lot more advanced and thus harder to get started with than VexRiscV.

> BOOM does not look like most effective in terms of LUTs utilisation core.

So the problem is also that the BOOM design is targeted at ASICs. The developers do not generally synthesize BOOM for FPGA. Only as a FireSim project which is using FPGAs to do fast simulations in order to get more accurate performance figures by running real world benchmarks (multiple MHz of target frequency). None of the developers are interested in using BOOM as a computer on an FPGA and thus no one has provided support for that.

> Another thing I also disliked in Chisel3 is dependancy on new intermediate representation of hardware (FIRRTL) which adds one more layer of abstraction and compilation.

I really enjoy working with firrtl. It is generally easy to inspect and quite human readable. With firrtl you can:

- automatically add coverage instrumentation:

  - for fuzzing: https://github.com/ekiwi/rfuzz/tree/master/instrumentation/src/rfuzz

  - for simulator independent coverage [wip]: https://github.com/freechipsproject/treadle/pull/263

- besides Verilog the firrtl compiler can generate SMTLib or btor2 file for model checking: https://github.com/chipsalliance/firrtl/tree/master/src/main...

- for ASIC development it is important to be able to replace all memories in your design with appropriate designs specific to the technology you target: https://chipyard.readthedocs.io/en/latest/Tools/Barstools.ht...

Adam's thesis has some more examples on what you can do with firrtl: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-...

There also might soon be a second implementation of a firrtl to Verilog compiler if you prefer C++ over Scala: https://github.com/llvm/circt

[ruslan]

Well, as I said this all stuff is very new to me, I do not understand many of the solutions, thanks for explaining. Using C++ as HDL is also interesting idea, for many this could lower the entry barrier.