Electronics > FPGA

The NEORV32 Risc-V Processor

(1/8) > >>

betocool:
Hi all,

I searched through the forum just to make sure I'm not repeating someone else's information, it turns out the term "neorv32" appears only once, on a post I made last year, and just in passing. As luck would have it, I was redirected to the NeoRV32 project in my interest to get a soft Risc-V processor into an FPGA. I'd looked at Litex, VexRiscV, PicoRV32, and while they were ok, documentation was either lacking, you'd need to invest A LOT of time to get something decent up and running, or dabble in Migen which is a Python way of describing hardware. Mainly it all felt a bit cumbersome.

But back on track, I went and looked into https://www.neorv32.org/, and looked at both the user manual and the datasheet.

This is so far the best and most understandable Risc-V implementation I've come across. After investing some time in reading the details, I was able to have a program compiled and up and running in minutes, both in Xilinx and Altera dev kits. The community also seems very open to questions, somehow, and this is my own personal opinion, the documentation and help seem less obscure than some other open source projects I've come across.

The official repo has test examples based on hardware and software. There are a few simple tools that help you getting that C code flashed into the FPGA as well, so your design is persistent. All the code is well documented and very well written, IMO.

If you're looking to get a Risc-V processor running on an FPGA, have a look at this, a very good place to get started. I'm curious to see what you guys think if you get around to it.

Cheers,

Alberto

brucehoult:
I haven't tried it, but the docs make it look well done.

I'm led to believe that LiteX (https://github.com/enjoy-digital/litex) wraps all kinds of cores, not only RISC-V in a SoC for FPGA and makes it easy to get them going. Neorv32 is just one of the supported cores. There are also Cortex-M1, Zynq7000 (C-A9), OpenRISC in addition to more than a dozen RISC-V cores.

https://github.com/enjoy-digital/litex/tree/master/litex/soc/cores/cpu

betocool:
I have not looked into Litex in detail, but I did run one example, and it was as easy as "python --run --processor..." or something along those lines. In that sense it does work out of the box. Trying to make sense of what was happening in the background and how the modules are all tied up together is a bit more difficult, and let's face it, the documentation for Litex is rather lax in that sense.

I will look into Litex more in the future, and yes, they do have a wrapper for the NeoRV32 core, so it'd be interesting to see how that may add components like SDRAM and DDR3 memories and such. I suppose once you understand what happens in the background things will get easier.

Cheers,

Alberto

miken:
I agree, the NEORV32 seems like the friendliest RISC-V core to adopt. (As long as you're not allergic to VHDL.) I'm using it for my SQRL Acorn example projects.

The documentation is lighter on some of the features but since it's open source it's easy enough to investigate exactly how things work. And there are good SW examples for us hardware people to abuse ;D

laugensalm:
I've evaluated a few RISC-V implementations in VHDL, indeed, this is so far the only well-advertised implementation that seems to be compliant, unfortunately it did not exist back then, however, its predecessor, 'neo430' could be integrated into an opensource SoC generator ('masocist') quite effectively.
The `f32c` and `potato` implementations did not pass the regression tests, in fact, a specific implementation of the f32c required a modified toolchain, I don't know if this is still the case, but it was unacceptable back then.
From a technical point of view, the neorv32 does not use the full potential of the RISC-V architecture with respect to pipelining, but normally this is not an issue.
The big plus with decent OpenSource VHDL implementations that are running with GHDL is that you can legally distribute an executable of a virtual chip (i.e. not violating the GPL), plus: passing GHDL raises chances to be portable among different FPGA architectures, provided that the toolchain eats VHDL. The neo430 synthesized with the OpenSource toolchain yosys through the ghdl plugin, I'm quite sure neorv32 would, too.

Navigation

[0] Message Index

[#] Next page