The NEORV32 Risc-V Processor - Page 1
Forum section: electronics / general

author: betocool
author_rank: Regular Contributor
timestamp: June 21, 2022, 01:59:21 am
content: 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 intohttps://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

author: brucehoult
author_rank: Super Contributor
timestamp: June 21, 2022, 03:34:23 am
content: 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

author: betocool
author_rank: Regular Contributor
timestamp: June 21, 2022, 04:16:14 am
content: 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

author: miken
author_rank: Regular Contributor
timestamp: June 21, 2022, 05:30:08 am
content: 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

author: laugensalm
author_rank: Regular Contributor
timestamp: June 21, 2022, 07:19:26 am
content: 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.

author: pbernardi
author_rank: Contributor
timestamp: June 27, 2022, 12:59:52 am
content: One could also take a look at DarkRiscV:https://opencores.org/projects/darkriscvhttps://github.com/darklife/darkriscvA small and compact RISCV implementation, the original version was made in one night! Still an active project, with periodic updates.

author: dolbeau
author_rank: Regular Contributor
timestamp: July 01, 2022, 10:00:10 am
content: Quote from: betocool on June 21, 2022, 01:59:21 amLitex is a SoC generator, it can wrap several different cores (some in SMP) and supply a lot of optional peripherals. There's repo to help generate a Linux-bootable SoC (such aslinux-on-litex-vexriscv.QuoteThat's what I usually use, because it's extremely configurable. I've used it both as a SMP Linux test platform starting with quad-core RV32GC and adding parts of B, K and testing some stuff from P. At the other end I've used it as a micro-controller RV32I running some bare-metal code, customized to improve bandwidth usage by using a 128-bits Wishbone bypass interface to a 128-bits LiteDRAM controller (DDR3) and some custom 64-bits load/store (using pair of 32-bits registers).If you want something faster, Vex has a newer, superscalar OoO brother,NaxRiscv.

author: brucehoult
author_rank: Super Contributor
timestamp: July 01, 2022, 10:50:24 am
content: I've been following NaxRISCV for a little while. It's improving all the time, but it still got a fair bit lower benchmark IPC than WD SWeRV and SiFive U7 dual-issue in-order cores. Maybe it can do higher frequency to make up for it, I'm not sure.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 01, 2022, 05:52:47 pm
content: The NEORV32 is good, well written and well documented.The downside is the performance - with an average CPI of 3-4, it's meh, so keep this in mind when comparing with other RISC-V soft cores. And comparing to actual silicon, a NEORV32 clocked at say, 100 MHz, will be very, very far in terms of performance from say, a SiFive FE310 clocked at the same frequency. Just so you know what to expect.With that in mind, it can still be pretty useful.

author: brucehoult
author_rank: Super Contributor
timestamp: July 01, 2022, 11:51:06 pm
content: I don't know about NEORV32, but an explicit part of the design of PicoRV32 was that if the other parts of your FPGA design allow clocking at 300 or 400 MHz then you don't have to put the CPU core in a different clock domain -- it just takes 3 or 4 cycles pre instruction and sits there happily doing its 100 or whatever MIPS.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 02, 2022, 12:47:14 am
content: Quote from: brucehoult on July 01, 2022, 11:51:06 pmYes, but I don't think the NEORV32 can be clocked nearly as fast as this, at least not on "modest" FPGAs. Maybe on the Virtex series. =)They show something like 108 MHz Fmax on the Cyclone IV (or V?) IIRC.

author: dolbeau
author_rank: Regular Contributor
timestamp: July 05, 2022, 11:11:12 am
content: Quote from: brucehoult on July 01, 2022, 10:50:24 amWell, Nax has been a single-person job for less than a year; the fact it can reasonably be compared to commercial offerings is already an impressive result :-) Also, it's highly configurable, can be either RV32 or RV64, and is free.

author: brucehoult
author_rank: Super Contributor
timestamp: July 05, 2022, 12:01:07 pm
content: Quote from: dolbeau on July 05, 2022, 11:11:12 amFair enough.Here's a single-person about a year OoO RISC-V core that can do up to 8 instructions per clock and currently gets 6.5 DMIPS/MHz (vs NaxRiscv 2.94). This is quite close to the 6.5 for SiFive's P550 core, due to appear in Intel's "Horse Creek" platform shortly.http://www.moonbaseotago.com/GPL3, which some people count as free.

author: dolbeau
author_rank: Regular Contributor
timestamp: July 05, 2022, 12:32:32 pm
content: Quote from: brucehoult on July 05, 2022, 12:01:07 pmOh, nice! Didn't know that one.Fast, but quoting the architectural presentation (as I can't find any specific numbers for e.g. LUT usage):QuoteOuch. VU9P are not exactly cheap - quick googling suggests they are 5-digits in small quantity. NaxRiscv will fit in a sub-$100 mid-range Artix-7, and with 4x the clock (presumably, they are targeting ASICs rather than FPGAs so the trade-offs and targeted clock are quite different).With the number of RISC-V (soft-)core now available, there should be something adequate for most use cases.(edit: typo)

author: brucehoult
author_rank: Super Contributor
timestamp: July 05, 2022, 09:58:18 pm
content: Quote from: dolbeau on July 05, 2022, 12:32:32 pmRight. It's a big OoO core. I don't know how you'd make a useful small OoO core :-)SiFive were able to prototype E31 and single U54 and U74 cores in an Arty (only just in the case of U74). To prototype the whole 5-core U54-MC for the HiFive Unleashed a $3500 VC707 FPGA board was needed (now $5244). For the U74-MC in the HiFive Unmatched a $7000 (in 2019) a VCU118 was needed (well, they were $7000 in 2017, now the Xilinx site says $8394 and Digikey says $9496 and out of stock)If I recall correctly, the VCU118 is enough for a single U84 / P550 core.I'm not pointing to Vroom to say "Hey, you should use this in your $100 FPGA" but "this is what a one-person team can do". And, yeah, it will be aimed at ASIC implementation once completed.

author: betocool
author_rank: Regular Contributor
timestamp: July 06, 2022, 01:07:39 pm
content: What do you guys mean by OoO?Cheers,Alberto

author: brucehoult
author_rank: Super Contributor
timestamp: July 06, 2022, 01:20:40 pm
content: Quote from: betocool on July 06, 2022, 01:07:39 pmOut of Order.Instructions don't execute in the same order they are in the program. They go into some kind of big pool of instructions and at each clock cycle instructions are checked to see if their input data is ready (e.g. reads from memory, possibly cache misses, or long instructions such as multiple or divide) and one or more of the ready instructions are sent to execution units, depending on how many execution units you have.In current x86 and ARM CPUs this instruction pool is typically something like 192 or 224 instructions in size or even more -- Apple's M1 appears to be something like 630.

author: laugensalm
author_rank: Regular Contributor
timestamp: July 06, 2022, 01:34:05 pm
content: Stepping in: Check for 'out of order' execution. It's roughly speaking a hardware based rescheduling of instructions of different classes that can run in parallel on multiple resource instances while minimizing pipeline stalls. For instance, there could be an arithmetic insn, like ADD, plus a branch depending on a condition that was met earlier (independent from the ADD operands). Those could be executed simultaneously.Since RISC-V has still inherited plenty from old MIPS concepts (aside from branch delay slot), there's some material to read from the MIPS 10k CPU designs that still applies.However OoO introduces some complexity that makes it close to impossible for devs@home to get full verification coverage, therefore there's caveats with such designs (as we had to learn from the intel archs).I doubt designs of that sort really pay off on FPGAs due to their longer pipelines and way more logic congestion, so, I'd second this is rather for prototyping with an ASIC in mind, eventually.

author: DiTBho
author_rank: Super Contributor
timestamp: July 06, 2022, 02:00:41 pm
content: Why people is always so boringly interested at performance?!? WHY!??Jesus, Pipeline and Cache are evil, especially for hobby stuff, especially when you don't have the effort/time to carry their bad effect, and you randomly see topics over topics about people asking "why my debugger behaves so weird .... " it's due to the pipeline, it's due to the cache....oh, so why do people insist with that bloody stuff? Why?A softcore without pipeline is not inferior, it's better by several hundred of magnitude, starting with "because it's simple", ending to "because it doesn't add any bad-side effect"Don't you hear me? I will make t-shirts with that message

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 06, 2022, 06:18:58 pm
content: Quote from: brucehoult on July 06, 2022, 01:20:40 pmWow.

author: brucehoult
author_rank: Super Contributor
timestamp: July 07, 2022, 03:02:50 am
content: Quote from: DiTBho on July 06, 2022, 02:00:41 pmIf that actually happens then that's simply a bug in the implementation.The ISA specifies the semantics of programs (except timing), and if some "clever" microarchitecture fails to implement those semantics correctly and transparently then that microarchitecture is buggy. Not that that has never happened, but when it does it's clearly a bug, and fixable in a revised hardware design.DRAM access times haven't increased all that much since the 1970s, so if we didn't have caches and pipelines and branch prediction and OoO our desktop PCs would still be running at maybe 16 MIPS total on shared RAM instead of 5-10 billion IPS per core.When you're controlling physical things outside the computer you need to have enough performance to do the job, it needs to reliably meet deadlines without glitches, and being 2x or 10x or 100x faster doesn't bring any benefit.But there are lots of applications where being 500x faster, on average, is a huge advantage, even if it's without 100% predictable timing in any particular instance.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 07, 2022, 04:16:43 am
content: Quote from: brucehoult on July 07, 2022, 03:02:50 amAlso, for those same physical things a computer that runs 90% of the speed need to meet deadlines is completely worthless.Quote from: DiTBhoCache and pipelining are essential to getting high performance out of modern processors. While they (especially cache) do make it difficult to give exact timing values, in many cases a "unpredictable" cached, pipelined CPU will have a worst case performance that is orders of magnitude faster than if it were running on a simple non pipelined CPU. I'm not talking about a pathalogical program designed to have a cache miss and/or pipeline flush on every cycle, but for a specific program that you actually care about you can often calculate the cache miss rate and show that it will never miss a deadline.I'm working on a hard realtime system that has many deadlines measured in nanoseconds. I'm using tightly coupled memory with no cache, but without a pipelined core it would be completely impossible. Furthermore, while the process is hard real time, the more performance I can get, the more complex logic the users can implement, so more is better. I'd love to use an OoO superscalar core, but those don't fit particularly well on most FPGAs.

author: asmi
author_rank: Super Contributor
timestamp: July 07, 2022, 05:36:50 am
content: Quote from: DiTBho on July 06, 2022, 02:00:41 pmMan, you're sooooo out of touch with reality, it's not even funny. ALL MCUs designed in the last decade (or even more) are pipelined! If you don't know how to debug pipeline, you'd better figure it out, and fast!

author: DiTBho
author_rank: Super Contributor
timestamp: July 07, 2022, 07:22:48 am
content: Quote from: asmi on July 07, 2022, 05:36:50 amI am tired to see comments like this.Really this forum it's gotten so f*cking depressing recently that answering is gotten so f*cking frustrating, especially when you comment with pleasantness and you get answers where the purpose is nothing but to demotivate those who aim for simplicity.Not mentioning thatevery single university projectis multi-cycles-based rather pipeline-based.Not mentioning thatevery single projectthat aims for real-time and cycle-precision is multi-cycles-based rather then pipeline-based.Not mentioning thatevery single projectwhen you have to deal with pipeline needs "critic code" and instructions like { sync, isync, fence, ... } which (in every PowerPC book) are described as "voodoo black magic code"etcAll idiots and sooooooooooooooooooo out of touch with reality, I guess.But, frankly I don't care. I am going to finish my coffee, take my bicycle and run for 90 Km to the lake. I will also have a swim with girls in bikini, you can stay here pumping your ego, and have fun with whatever you believe it's funny

author: DiTBho
author_rank: Super Contributor
timestamp: July 07, 2022, 07:25:16 am
content: Quote from: ejeffrey on July 07, 2022, 04:16:43 amOh, well, 60Mhz clock, 6 stage multi-cycles, it means 10Mhz per instruction.It's enough for my real-time needs.

author: laugensalm
author_rank: Regular Contributor
timestamp: July 07, 2022, 08:27:24 am
content: Quote from: DiTBho on July 07, 2022, 07:22:48 amYou may have to accept the fact that there is a majority of 'old farts' here who have designed CPUs and know what they're talking about.Multi-cycling does not mean it's simpler, and your statement on realtime and black magic simply is not correct. You might want to read on some DSP architectures like Blackfin (instruction set designed by Intel). And there are pipelined RISC-V with deterministic cycle counts.Pipelining is no black magic, but yes, you've got to deal with hazards. Something that is taught in an introduction to the classic MIPS architecture. The most complicated thing is to sort out the in circuit debugging in conjunction with external exception/interrupt events. Something where most (academic) projects show a big FAIL.There's also a reason why most vendor specific architectures (NIOS, Mico32, ...) is designed similar: The concept just runs very well on an FPGA and can be implemented very minimally. On the other hand, multi cycle approaches can in some cases turn into a badly balanced logic and even cause more power consumption than the pipelined variant. Been there, done that.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 07, 2022, 06:40:09 pm
content: Just because something is harder to implement doesn't mean it's crap. With that reasoning, we wouldn't be talking on a web forum.The only "reasonable" part of DiTBho's point, IMO, is that if *they* don't feel *they* can safely implement a pipelined CPU, and it's for a professional project with a hard deadline, then they probably shouldn't even try.That said, knowing your limits is great. Doesn't mean you should not try to overcome them. Else you're just going to stagnate.As to determining the benefits of a CPU being able to process several times as many instructions for a given clock frequency, even a 4-year old can understand that.Of course, as always with engineering, if you don't NEED the performance, you may consider whether it's worth the trouble. But that's engineering 101. (And still try having some kind of long-term vision - just because some architecture is not strictly *needed* right now doesn't mean it won't be in a few months/years from now, and having to do it all over again may have excessive and unjustified extra cost. But al this is again engineering 101, nothing new here.)

author: DiTBho
author_rank: Super Contributor
timestamp: July 07, 2022, 11:20:49 pm
content: Quote from: SiliconWizard on July 07, 2022, 06:40:09 pmWhen I say that this forum is frustrating ... isn't it? Well, I said just that because people in this forum are obsessed by performance, it doesn't mean that simpler solutions are crap, neither that if you don't do pipelined stuff you are a donkey.

author: brucehoult
author_rank: Super Contributor
timestamp: July 07, 2022, 11:27:23 pm
content: Quote from: DiTBho on July 07, 2022, 11:20:49 pmAnd if your requirements are simple enough you might just use an FSM and forget this Turing-complete stuff, неправда?

author: DiTBho
author_rank: Super Contributor
timestamp: July 08, 2022, 12:01:36 am
content: Quote from: brucehoult on July 07, 2022, 11:27:23 pmAt least it won't be affected by PacMan, which explotis Cache-miss and Pipeline-branch prediction errors

author: dolbeau
author_rank: Regular Contributor
timestamp: July 08, 2022, 09:32:21 am
content: Quote from: DiTBho on July 07, 2022, 07:22:48 amThe original Stanford MIPS was pipelined (became MIPS R2000).The Berkeley RISC was pipelined (became SPARC).Fast forward to the present, Ariane (became CVA6) and RI5CY (became cv32e40p) are pipelined.QuoteEven the smaller Arm Cortex-R, the R4, is pipelined.QuoteThose instructions are not required for pipelines, but for multiprocessors.

author: DiTBho
author_rank: Super Contributor
timestamp: July 08, 2022, 01:18:28 pm
content: Quote from: dolbeau on July 08, 2022, 09:32:21 amUniversity projects like SPIM, MARS, and laboratory projects assigned to students: all multi-cycles!

author: DiTBho
author_rank: Super Contributor
timestamp: July 08, 2022, 01:29:19 pm
content: Quote from: dolbeau on July 08, 2022, 09:32:21 amSuperscalars need them, as well as Multitreads need themcustom designs with non-superscalars and LIFO/FIFO memory mapped devices may need "pipeline-dedicate instructions" to mitigate.Talking about the RISC-V ISA, there are implementations that use a "relaxed memory model" where the order of loads and stores performed by one thread may be different when seen by another. This is done to enable techniques to increase memory system performance.Because again we are all obsessed by performance, aren't we? sure we are, and gain, FENCE is the only thing that can save your day.

author: brucehoult
author_rank: Super Contributor
timestamp: July 08, 2022, 11:59:34 pm
content: Quote from: DiTBho on July 08, 2022, 01:29:19 pmNot by another thread. By another CPU.

author: DiTBho
author_rank: Super Contributor
timestamp: July 09, 2022, 01:13:22 am
content: Quote from: brucehoult on July 08, 2022, 11:59:34 pmSame CPU with resources replication

author: brucehoult
author_rank: Super Contributor
timestamp: July 09, 2022, 01:53:19 am
content: Quote from: DiTBho on July 09, 2022, 01:13:22 amWhat do you mean by that?RISC-V caches must appear to software  to be physically-indexed, physically-tagged, so even if another thread accesses the same RAM at a different virtual address the correct data is seen. many implementations use virtually-indexed L1 cache so the cache access can proceed in parallel with the TLB lookup, but as long as the associative "way" size is no larger than a VM page the effect it the same. i.e. a 16 KB L1 cache must have at least 4 ways, a 32 KB L1 cache must have at least 8 ways etc. L2/L3 cache waits for TLB so can have fewer ways.

author: betocool
author_rank: Regular Contributor
timestamp: July 09, 2022, 03:13:12 am
content: The reasons for me to use this processor are in no particular order:- Documentation is pretty good, as well as examples- Support from the mantainer is top notch. I've been working with him this week in getting to execute code from an SPI flash on my dev kit by changing the bootloader. After a few misses and some bugs we found, it's working.- Performance wise... we'll see... very early days still, but if I can get an audio signal ADC'd and DAC'd, that will be a good start.With the above in mind, I've felt that other implementations are more "academic" oriented, if that makes sense, in terms of creating big constructs but in a more complex way, aimed at FPGA developers rather than µC users/developers. It's fun to add a new peripheral to your micro, I love that flexibility, but after that's done some of us would want to just use the construct, flash a binary, debug the code, and be done with the project until the next one comes along.The above is my opinion, based on observation. I'm not belittling the work other groups have done, I'm a big fan of open source, but at times it's very hard to get through the initial barrier in new projects.Cheers,Alberto