Open-source soft-core RISC-V SoC with gdb support | Hacker News Reader

Open-source soft-core RISC-V SoC with gdb support

github.com

94 points_quarks_18 comments

In isolation, this seems like a decent CPU, but I wonder if there is any benefit in using this over using a VexRiscv, which seems to cover the same spectrum as this in terms of performance (from 2 to 5 pipeline stages) and features, yet requires less LUTs?

This one supports the standard RISC-V debug extensions and doesn’t require a custom version of openocd, but is there anything else?

It is hard to compare two RISC-V cores if they do not have similar configuration options. For example: what kind of ISA extensions, supported traps, custom extensions, CSRs, etc. does VexRiscv "SmallAndProductive" configuration include?

I like that it is written in VHDL and provides an all-in-one package: cpu, soc and software

The SmallAndProductive configuration can be found here: https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/s....

It’s a basic R32I configuration, without traps or branch prediction enabled, but with 5 pipeline stages and all bypass paths included, so it executes straight code at 1 instruction per clock.

The VexRiscv also comes with a bunch of full featured SOCs.

The VexRiscv is configurable to the extreme and it’s extremely easy to do so. There are tons of other configurations in the same directory, from even smaller to full Linux SMP configs. It’d be trivial to create one that has the same configuration as this one and compare.

SpinalHDL supports both Verilog and VHDL output, so you’re covered there as well.

It’s not native VHDL, of course, so if you want to understand the code at the VHDL level instead of just wanting to use a soft core CPU, it’s probably not for you.

Those who just need a CPU for a non-Scala environment (e.g. Litex) just pre-generate a whole bunch of configurations and then pick what they need for a certain use case.

The VexRiscv design methodology is pretty amazing as well. I wrote about it here: https://tomverbeure.github.io/rtl/2018/12/06/The-VexRiscV-CP....

Full-scale RISC-V soft-core microcontroller SoC with on-chip debugger compatible to openocd and GNU gdb

Is this project your personal work? That's what "Show HN" is for. Please see https://news.ycombinator.com/showhn.html.

Since there's no clear connection, I've taken Show HN out of the title now. But if it actually is your personal work, let us know and we'll be happy to put it back.

If it's not your work, it's still a fine submission, it just needs to not say "Show HN" in that case.

Why is "no clock gating" listed as a feature rather than a drawback? Isn't clock gating a power-saving feature?

Please forgive me the stupid question: How do people use this? What role does it play in your projects?

Soft cores are often used as a convenient abstraction layer in FPGAs for example. Rather than hand coding control plane in VHDL or Verilog, you can compile regular C and manage your device that way. But C compilers require a target architecture to compile to, so you need to pick one.

A side note. There are many options for soft cores and often you will see overengineered solutions because something is popular or ready off the shelf. You end up with powerful gadgets. Kind of like a toaster toothbrush: Both are useful on their own, but it’s a weird combination.

This is not at all what a softcore is to me. This simply means that it is not a cpu which takes physical space on the FPGA whether you use it or not, it would only takes some celle of the logical array if inferred.

But it is rather redundant to say vhdl and softcore, plus there are no riscv hardcore yet on FPGA.

> But it is rather redundant to say vhdl and softcore

I disagree. Firstly, there are many other hardware description languages (Verilog, migen, SpinalHDL for instance), and while they can more or less interoperate, one could prefer a given language depending on the context.

Secondly, vhdl can be synthesized, placed and routed as an ASIC "hard core" or more precisely "soft macro".

Yeah, you are right, I don't know of any FPGA (yet) shipping with hard RISC-V cores.

Lattice have some FPGA's with RISC-V cores in them IIRC

I thought so, too. I have read about the Lattice MACH-NX having a secure enclave based on a RISC-V CPU, but it seems like this is just a soft-core CPU as well.

https://www.microsemi.com/product-directory/soc-fpgas/5498-p...

Microsemi not lattice, my apologies

Microsemi have the PolarFireSOC which has 4x RISC-V hard cores in the FPGA. I have an eval board on my desk

Five. Four full-featured 64 bit cores with MMU, FPU, LInux capable-etc. Plus one 64 bit no MMU no FPU core for ... real time / microcontroller / whatever dedicated tasks.

FPGAs are "Field Programmable Gate Arrays". AKA, reprogrammable logic circuits. Some stuff is just better done using a processor than an FPGA.

Basically, when using an FPGA, you have a finite number of gates you can use: it's like saying "code anything you want, it must be less than 1k lines".

Sequential logic, that's very convoluted with lots of condition, and not performance-critical will be a very good fit for CPUs, while the FPGA remains useful for high-troughoutput, parallel work, and specialized computing elements.

So you can just have a processor plus an FPGA on the same board. But if you need a small fraction of an FPGA, you might as well use the rest to implement a CPU.

And instead of designing your own instruction set, compiler, debugger, etc, you might want to pick an existing one, preferably the best match to your requirements.

You can also modify the instruction set of the CPU to make use of more specific functionality you integrate on the FPGA. And implementing it this way makes it easier to share resources (registers, memory, peripherals).

Of course, there is a performance penalty (frequency and energy) compared to using a "real" transistor-based CPU, and that's one of the reasons manufacturers sometimes integrate ARM cores in their designs.

Now to more specifically answer your question: we investigate the performance impact of new logic-in-memory instructions, so a softcore is appealing: add custom instructions to the CPU, wire them using the FPGA. Run and compare.

But one could run this in production to do something like handle TCP/IP on the CPU, but put a specific custom DSP on the FPGA side.

I used small CPU cores if pretty much all my FPGA projects.

For example, if I need an I2C controller for a one-time configuration of some external device, instead of adding a a hardware controller, I just bit-bang an I2C protocol on the IO pins. Once, that configuration is done, the CPU is then used for some other small task.

The use of small embedded CPUs in FPGAs (or in ASICs too) is very common. The capacity of FPGAs is always increasing, and iterating a bug fix in hardware can take hours or even days. With a soft core CPU, updating the embedded firmware can take minutes. For ASICs, you'd need a silicon spin, of course.

Reply on news.ycombinator.com