cva6 VS litedram

Hello. I'm looking into implementing RISC-V on an FPGA for a school project. The two repos I'm looking into using are the Ariane and RocketChip repos. Both look actively maintained, but RocketChip has more recent releases, and it's used by this other repo that creates a block design in Vivado with the RISC-V RTL. However, we would also like to be able to make changes to the core, and I'm afraid that scala/Chisel might be difficult to learn. Ariane looks like SystemVerilog while RocketChip is mostly Chisel. Does any have recommendations on which RISC-V repo would be good to use for a project?

There are 108 RISC-V cores that have been created so far (according to this list), but only a couple are 64 bit, open source and powerful enough that you would want to use them (like Shakti, CVA6 and NutShell)

The source code of Ara as well as Ariane, also known as CVA6 is available on GitHub.

I made a post about this here not too long ago, but I think it would be really useful to come up with a Vivado benchmark, in the form of a standardized large and representative design. I was curious about Alder Lake performance too, and compared my new 12700K workstation against my laptop with this open source RISC-V CPU: https://github.com/openhwgroup/cva6

When the OpenHW Group was created in 2019, I had some hope that Alibaba or NXP (who are in the OpenHW Group) would release an open hardware RISC-V processor, but it looks like they are not making any public commits to the CVA6 core, so I doubt that we are ever going to see the source code of Alibaba's XT910 or NXP's Chassis RISC-V processor.

Ariane is now cva6 (it moved to a industry supported non-profit).

At this stage, it could make sense for e.g. universities to start developing peripherals & controllers targeted at ASIC rather than creating yet-another-core (https://riscv.org/exchange/cores-socs/ has 107 lines already for cores), leveraging an OSHW ASIC-proven core from e.g. the OpenHW group (https://github.com/openhwgroup/cva6). Manufacturing in not-so-old processes is affordable for teaching institutions (e.g. https://europractice-ic.com/ in Europe), and taping out working cores is no longer a 'new' thing (e.g. http://asic.ethz.ch/all/years.html ).

Looking at the github of the openhw group looks like the license is granting patents to the project. So it looks ok.

I could be wrong, but I don't think the LiteX DRAM PHY is using the UG586 block. Here's the Litex Series 7 DRAM PHY source code - it appears to be hardcoding the PHY logic. The Lattice ECP5 code in that directory does the same thing.

Try https://github.com/enjoy-digital/litedram with a RAW or FIFO interface. It is in Migen, a python DSL HDL, but you could just use the output.

You could try to implement a PCIe root complex for FOSS SoCs, connecting to e.g. Wishbone as the main bus. There's already some DDR3 controller (or this one) and USB Host controller out there, and even device-side PCIe, but no FOSS host-side PCIe that I know of. Probably quite a difficult job though, even sticking to the lower-speed PCIe 1.

So for instance (and AFAI understand...) the DDR2 sdram controller uses a generic PHY (https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/gensdrphy.py) , but the DDR3 one has to talk to some vendor-specific PHY (e.g. https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/s7ddrphy.py ). The controller itself is vendor-agnostic (https://github.com/enjoy-digital/litedram/blob/master/litedram/core/controller.py). On Xilinx FPGA it doesn't rely on MIG at all.