Open-source soft-core RISC-V SoC with gdb support
1–10 of 20 posts
Re: Open-source soft-core RISC-V SoC with gdb support
#2Re: Open-source soft-core RISC-V SoC with gdb support
#3Re: Open-source soft-core RISC-V SoC with gdb support
#4Please forgive me the stupid question: How do people use this? What role does it play in your projects?
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.
Re: Open-source soft-core RISC-V SoC with gdb support
#5Please 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 read…
But it is rather redundant to say vhdl and softcore, plus there are no riscv hardcore yet on FPGA.
Re: Open-source soft-core RISC-V SoC with gdb support
#6Re: Open-source soft-core RISC-V SoC with gdb support
#7This one supports the standard RISC-V debug extensions and doesn’t require a custom version of openocd, but is there anything else?
Re: Open-source soft-core RISC-V SoC with gdb support
#8In 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?
I like that it is written in VHDL and provides an all-in-one package: cpu, soc and software
Re: Open-source soft-core RISC-V SoC with gdb support
#9Earlier quoted context omitted.
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 read…
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.
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.
Re: Open-source soft-core RISC-V SoC with gdb support
#10Please forgive me the stupid question: How do people use this? What role does it play in your projects?
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.