6 ms·

An FPGA-friendly 32-bit RISC-V CPU implementation

102 points by Dolu 9y ago

ajross 9y ago
Too 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?
- rjsw 9y ago
  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.
  - ajross 9y ago
    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...
    - monocasa 9y ago
      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.
      - finfet1 9y ago
        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.
        monocasa 9y ago
        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.
        finfet1 9y ago
        We're not talking about achieving on-die chip speeds at the picosecond range here. We're talking about interface specifications between the CPU and the DRAM, USB, etc -- these things can be designed for based on specs, and you don't need a trise/tfall equal to 10% of your FO4 inverter delay to achieve this. These are board level specifications which can be achieved with medium tier off the shelf components. And if they can't be achieved at the latest DDRX specs, then just design for one generation behind to at least get something going in the community.
      - ajross 9y ago
        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.
- Dolu 9y ago
  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 https://github.com/SpinalHDL/VexRiscv#briey-soc
  - duskwuff 9y ago
    For an FPGA implementation, it's often useful to hook the soft core into the FPGA's own JTAG controller, so that it's possible to program the FPGA and debug the core over a single connection. This is often not portable even between FPGAs, and certainly isn't portable to ASIC, but it makes development a lot easier, so...
    - Dolu 9y ago
      Yes i agree, would have been more convenent to use the integrated jtag of the FPGA, but i focused on making an universal solution first :)
  - zokier 9y ago
    Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?
    - Dolu 9y ago
      They aren't made for external com
    - monocasa 9y ago
      They are usable externally. The Realview boards use it to connect a CPU chip with an external northbridge, but it's really rare. Even in that case, it's just because the Realview board is meant to prototype SoCs with the help of an FPGA.
quigonjinn 9y ago
Kinda 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?
- baobrien 9y ago
  I'm not sure about the trend in general, but it looks like SpinalHDL is a fork of Chisel, the 'other' Scala-based HDL.
  - Dolu 9y ago
    Yes kind of, SpinalHDL is a from scratch fork
- rvense 9y ago
  Everybody wants a new HDL but there's no standard yet. Embedding it in your favourite language is the obvious solution, and hence there will be at least one per language.
  - Dolu 9y ago
    Yes a standard would be great, with all the feature provide by those embedded HDL, but i'm realy not sure the industry could make it. #systemverilog
- aseipp 9y ago
  Honestly, I'd wager it's because Verilog and VHDL suck in a lot of ways basically. They work, but almost anything has better abstraction and reuse capabilities, even embedded DSLs or bespoke compilers or whatever, and offer better feedback loops during development. REPLs help a lot when building big circuits out of smaller ones. Being able to use a package manager to grab and manage SoC/IP components is convenient, etc. Most of these DSLs tend to work at the level of RTL as opposed to something like "high level synthesis" where register usage is inferred, too (OpenCL, C, etc). So depending on how it's designed the results can be pretty close to hand-written code IME, without much overhead. They're more like "Super RTL" as opposed to real "high level" languages...
SoylentYellow 9y ago
What license are you releasing this under, if any?
- Dolu 9y ago
  Honnestly, i haven't realy think about it. Not a constraining one, but more something like : Do what ever you want with it, but if you find a bug, please tell me, and if you use it in a project which has a lot of money, please, share a bit with opensource guys, don't be too greedy ^^
vanjoe 9y ago
How do you manage cached and uncached memory accesses? There has been some discussion lately on the mailing lists about this
- Dolu 9y ago
  Cached an uncached memory access are currently staticaly specified by range : https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/VexRiscv/demo/Briey.scala#L234 https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/s... From 0xF000000 to 0xFFFFFFFF access will be uncached.

102 points by Dolu 9y ago

Too 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?

rjsw 9y ago
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.
- ajross 9y ago
  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...
  - monocasa 9y ago
    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.
    - finfet1 9y ago
      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.
      - monocasa 9y ago
        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.
        finfet1 9y ago
        We're not talking about achieving on-die chip speeds at the picosecond range here. We're talking about interface specifications between the CPU and the DRAM, USB, etc -- these things can be designed for based on specs, and you don't need a trise/tfall equal to 10% of your FO4 inverter delay to achieve this. These are board level specifications which can be achieved with medium tier off the shelf components. And if they can't be achieved at the latest DDRX specs, then just design for one generation behind to at least get something going in the community.
    - ajross 9y ago
      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.
Dolu 9y ago
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 https://github.com/SpinalHDL/VexRiscv#briey-soc
- duskwuff 9y ago
  For an FPGA implementation, it's often useful to hook the soft core into the FPGA's own JTAG controller, so that it's possible to program the FPGA and debug the core over a single connection. This is often not portable even between FPGAs, and certainly isn't portable to ASIC, but it makes development a lot easier, so...
  - Dolu 9y ago
    Yes i agree, would have been more convenent to use the integrated jtag of the FPGA, but i focused on making an universal solution first :)
- zokier 9y ago
  Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?
  - Dolu 9y ago
    They aren't made for external com
  - monocasa 9y ago
    They are usable externally. The Realview boards use it to connect a CPU chip with an external northbridge, but it's really rare. Even in that case, it's just because the Realview board is meant to prototype SoCs with the help of an FPGA.

quigonjinn 9y ago

Kinda 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?

baobrien 9y ago
I'm not sure about the trend in general, but it looks like SpinalHDL is a fork of Chisel, the 'other' Scala-based HDL.
- Dolu 9y ago
  Yes kind of, SpinalHDL is a from scratch fork
rvense 9y ago
Everybody wants a new HDL but there's no standard yet. Embedding it in your favourite language is the obvious solution, and hence there will be at least one per language.
- Dolu 9y ago
  Yes a standard would be great, with all the feature provide by those embedded HDL, but i'm realy not sure the industry could make it. #systemverilog
aseipp 9y ago
Honestly, I'd wager it's because Verilog and VHDL suck in a lot of ways basically. They work, but almost anything has better abstraction and reuse capabilities, even embedded DSLs or bespoke compilers or whatever, and offer better feedback loops during development. REPLs help a lot when building big circuits out of smaller ones. Being able to use a package manager to grab and manage SoC/IP components is convenient, etc. Most of these DSLs tend to work at the level of RTL as opposed to something like "high level synthesis" where register usage is inferred, too (OpenCL, C, etc). So depending on how it's designed the results can be pretty close to hand-written code IME, without much overhead. They're more like "Super RTL" as opposed to real "high level" languages...

SoylentYellow 9y ago

What license are you releasing this under, if any?

Dolu 9y ago
Honnestly, i haven't realy think about it. Not a constraining one, but more something like : Do what ever you want with it, but if you find a bug, please tell me, and if you use it in a project which has a lot of money, please, share a bit with opensource guys, don't be too greedy ^^

vanjoe 9y ago

How do you manage cached and uncached memory accesses? There has been some discussion lately on the mailing lists about this

Dolu 9y ago
Cached an uncached memory access are currently staticaly specified by range : https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/VexRiscv/demo/Briey.scala#L234 https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/s... From 0xF000000 to 0xFFFFFFFF access will be uncached.