An FPGA-friendly 32-bit RISC-V CPU implementation
1–10 of 44 posts
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#2Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem.
The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#3Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?
I'm not sure that is fair.
FPGA tools come with a lot of IP that may make use of hard blocks such as memory or network controllers. If you look at ARM SoCs, the peripherals are often bought in from IP libraries.
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#4Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?
I'm not sure that is fair. FPGA tools come with a lot of IP that may make use of hard blocks such as memory or network controllers. If you look at ARM SoCs, the peripherals are often bought in from IP libraries.
Sort of exactly my point: ARM SoCs mate a proprietary CPU implementation from an existing ecosystem with a bunch of proprietary IP blocks from that same ecosystem (that in practice tend to make up the bulk of the silicon area). Our "open" hardware excitement is limited to replacing the former while putting our heads in the sand about the latter, which IMHO is more important if you want to actually get any benefit (beyond "I made a CPU!" of course).
ARM and x86 may be proprietary designs, but their behavior is excruciatingly well specified and understood. If you want high quality open hardware, someone needs to start replacing the rather less well-specified/understood implementations of DRAM and I2C and SPI and USB and...
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#5Too many people jumping into the "I wanna design a CPU too!" pool. Not nearly enough designing the needed microcontroller peripherals to have a working open hardware ecosystem. The JTAG debugging hooks are a nice touch for a FPGA product though. Do the existing RISC-V silicon implementations not provide this?
Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax.
Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 interconnect, some slave like GPIO, UART, Timer, VGA. It's not incredible, but it's already a starting point ^^ See https://github.com/SpinalHDL/VexRiscv#briey-soc
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#6Earlier quoted context omitted.
I'm not sure that is fair. FPGA tools come with a lot of IP that may make use of hard blocks such as memory or network controllers. If you look at ARM SoCs, the peripherals are often bought in from IP libraries.
Sort of exactly my point: ARM SoCs mate a proprietary CPU implementation from an existing ecosystem with a bunch of proprietary IP blocks from that same ecosystem (that in practice tend to make up the bulk of the silicon area). Our "open" hardware excitement is limited to replacing the former while putting our heads in the sand about the latter, which IMHO is more important if you want to actually get any benefit (be…
Parts of DRAM, USB, and GPIO controllers at least are probably going to stay closed for the short term. The analog properties of their PHYs are per process hard blocks typically that the fabs are super into keeping locked up.
I2C and SPI are pretty trivial though, I've written HDL for both of those. SPI is literally just a shift register and an chip enable signal.
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#7Earlier quoted context omitted.
Sort of exactly my point: ARM SoCs mate a proprietary CPU implementation from an existing ecosystem with a bunch of proprietary IP blocks from that same ecosystem (that in practice tend to make up the bulk of the silicon area). Our "open" hardware excitement is limited to replacing the former while putting our heads in the sand about the latter, which IMHO is more important if you want to actually get any benefit (be…
Parts of DRAM, USB, and GPIO controllers at least are probably going to stay closed for the short term. The analog properties of their PHYs are per process hard blocks typically that the fabs are super into keeping locked up. I2C and SPI are pretty trivial though, I've written HDL for both of those. SPI is literally just a shift register and an chip enable signal.
Perhaps a solution would be if the verilog cpu project provided a few specific model numbers for each part (obviously, choosing ones that are commonly available and lesser cost), so that public contributors can work towards a common implementation for said part.
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#8Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#9Earlier quoted context omitted.
Parts of DRAM, USB, and GPIO controllers at least are probably going to stay closed for the short term. The analog properties of their PHYs are per process hard blocks typically that the fabs are super into keeping locked up. I2C and SPI are pretty trivial though, I've written HDL for both of those. SPI is literally just a shift register and an chip enable signal.
Perhaps a solution would be if the verilog cpu project provided a few specific model numbers for each part (obviously, choosing ones that are commonly available and lesser cost), so that public contributors can work towards a common implementation for said part.
I mean, the issue is that you're not going to find the specifications for the PHY stuff anywhere. There's no model numbers to clone. It's literally things like how do you etch out capacitors in the fab's process? What's the electrical properties of their different dopants? There's not really any models to clone without cloning the whole fab.
Our best option IMO is to wait until Moore's law hits more of a standstill, when fabs become more of a commodity and they're less secretive about the underlying process rules.
Re: An FPGA-friendly 32-bit RISC-V CPU implementation
#10Earlier quoted context omitted.
Sort of exactly my point: ARM SoCs mate a proprietary CPU implementation from an existing ecosystem with a bunch of proprietary IP blocks from that same ecosystem (that in practice tend to make up the bulk of the silicon area). Our "open" hardware excitement is limited to replacing the former while putting our heads in the sand about the latter, which IMHO is more important if you want to actually get any benefit (be…
Parts of DRAM, USB, and GPIO controllers at least are probably going to stay closed for the short term. The analog properties of their PHYs are per process hard blocks typically that the fabs are super into keeping locked up. I2C and SPI are pretty trivial though, I've written HDL for both of those. SPI is literally just a shift register and an chip enable signal.
USB has an actual PHY hardware spec for exactly that reason. And I'm not sure I buy your GPIO argument, not a hardware engineer but I've known several who all swear never to use fab-supplied GPIO blocks.
It may well be that DRAM's analog requirements are fab-specific (though I'd be a little surprised if it were that bad: these are full swing classic bus signals), but nonetheless most of the complexity in these controllers is in the logic side: clocking, refresh, bank mapping, ECC, etc... That's all stuff we could (and should) be writing in open source HDL.