Simple RISC-V core? - Page 1
Forum section: electronics / general

author: bson
author_rank: Unknown
timestamp: May 28, 2025, 01:20:34 am
content: I'm looking for a simple RISC-V core I can drop into an FPGA. That doesn't rely on internal buses, has basic integer instructions (don't need mul/div, though it would be nice it they're optional), has no pipelining, etc. Just an elementary 32-bit CPU I can use gcc/clang to generate code for, in a module with a generic rd/wr/address/data_in/data_out/etc style bus interface. If I want to use it with an internal bus I can trivially interface it. I don't want an 8-bitter (for code optimization purposes) but don't care if it implements 8-bit internal datapaths and executes in multiples of 4 clocks, if this makes it more compact.Everything I can find seems either like massive overkill for my needs, or it's only intended to be a simulation toy...

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 02:06:37 am
content: It would be helpful if you said what you've looked at. There are literally dozens and dozens of candidates.VexRISCV is one of the more widely-used ones, and is very configurable, but is probably in your "overkill" basket.SeRV is just about the smallest core in existence for any ISA, is used in multiple commercial products, uses 164 FFs in probably any kind of FPGA, 125 LUTs in Artix-7 or 198 LUTs in iCE40. It's bit-serial and uses 32 clock cycles for most instructions, 64 for shifts and branches.QeRV was recently officially merged into the main SeRV repo. It uses a 4 bit datapath for ~15% bigger size but 3x the speed.There will probably be an 8-bit datapath version at some point.SeRV uses two simplified Wishbone buses, one for instruction fetch and one for data. Both can be connected to the same dual-port RAM for von Neumann operation.

author: ataradov
author_rank: Super Contributor
timestamp: May 28, 2025, 02:57:47 am
content: I made one basically for the same set of requirements -https://github.com/ataradov/riscvBut everyone's detailed requirements are different, so have a look, it might work. I used it in a few projects, it seems to work fine. It was not specifically optimized for final size, but mostly for code readability.Also, it does not include any of the special registers or interrupt controller, since I see no point of any of that in FPGAs.

author: brucehoult
author_rank: Super Contributor
timestamp: May 28, 2025, 03:15:34 am
content: Quote from: ataradov on May 28, 2025, 02:57:47 amZicsr is an optional extension for a reason :-)As well as that kind of thing, SeRV does something sensible with valid RV32I instructions, but anything else it encounters is "don't care" and is probably different on every synthesis tool if not every time you build it!

author: laugensalm
author_rank: Regular Contributor
timestamp: May 28, 2025, 08:16:59 am
content: What language? On your selectors work you must.Almost anyone in here has written a proprietary RISC-V core by now and will probably recommend it. There are 100s and many approaches should be seen academically, as they tend to be a nightmare for functional safety or debugging. Time for a RISC-V AI-featured selector tool? Or just enter "RISC-V" on github and search by language...

author: iMo
author_rank: Super Contributor
timestamp: May 31, 2025, 09:32:10 am
content: This worked "almost straight" with me years back (and with some support of the creator Joerg).Can run up to ~128kB of C binary in the ice40UP5k (the C binary loaded from the flash into the 128kB on-chip sram independently of the FPGA's bitstream)..https://github.com/igor-m/Risc-V-on-FPGA-experiments

author: brucehoult
author_rank: Super Contributor
timestamp: May 31, 2025, 10:19:40 am
content: Quote from: iMo on May 31, 2025, 09:32:10 amIt all depends what you want of course.At that point you've basically got something that can run CP/M or similar, and it's not mush more work to be able to run Linux.My impression is most people who want a simple core plan to run a fixed program with a few dozen to a few hundred instructions -- basically a complex FSM, often.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 31, 2025, 03:29:01 pm
content: Quote from: brucehoult on May 31, 2025, 10:19:40 amThis is definitely me. I wanted a core that I could load a program into sram, reset, and it would run the program loop. Anything that looks like a "system on chip" is just getting in the way. While I do have some custom memory mapped IO, no standard peripherals are needed.In my case this was on a zynq so the arm professor could do any needed maintinence jobs, and also reload the sram for the processor to switch between different "control laws".I used vexriscv because I needed fairly high performance. But it was still simple to use: there is a whole scala build system that is a bit intimidating at first but in the end it just spits out a verilog file with a dozen or so ports. Instruction fetch bus, data load/store bus, interrupt and reset in, and various fault output signals. The interface is frankly less complex than the xilinx macro for an SRAM block or fifo.

author: betocool
author_rank: Regular Contributor
timestamp: June 01, 2025, 02:20:03 am
content: Most of the Risc-V implementations I've seen are in Verilog, except VexRiscV which I believe can be either Verilog or VHDL. There is a VexRiscV II now.I've used this: NeoRV32 (https://github.com/stnolting/neorv32). It is a complete SoC if you want, but you can just decide not to implement any of the peripherals. The examples and software framework make it easy to start with, I got a simple blinky up and running in 10 minutes. The documentation is top notch. Performance wise it's OK I guess, but not at the level of VexRiscV I don't think.Cheers,Alberto

author: iMo
author_rank: Super Contributor
timestamp: June 01, 2025, 07:35:41 am
content: Quote from: brucehoult on May 31, 2025, 10:19:40 am.. then the picorv32(small) is worth trying as well..

author: bson
author_rank: Unknown
timestamp: June 06, 2025, 09:15:40 pm
content: My use cases are extremely simple, and I think mostly fall in the "quick but handy hacks" category. An example is a test pattern generator, such as for an HDMI graphics controller. Just set a jumper or two to let a RV running some trivial code configure the device and put patterns in a frame buffer. Of course it can be done without a processor, just not as quickly or easily. Maybe display a test menu on a serial port and allow various tests or settings, maybe control register dumps. The only reason to have it in an FPGA is of course because the controller is implemented using it.Other examples might be to implement a USB device stack, or mostly anything that involves protocol layering or parsing/textual output. Like a VCP endpoint, but that would be at the very high end of complexity and almost certainly need external flash for the code.Maybe the dumbest use case would be to continuously collect internal state and log it to a serial or other 'trace' port - effectively printf's for an FPGA.

author: bson
author_rank: Unknown
timestamp: June 06, 2025, 09:39:59 pm
content: Quote from: iMo on June 01, 2025, 07:35:41 amI took a quick look, and this looks pretty good! Also, ataradov's looks promising.Thanks! Happy to hear I don't have to roll my own.I figured surely people had already done this before - it is a bit of a project after all, especially with comprehensive instruction tests.