Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

antmicro.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#31

Post by amelius »

mhh__ wrote: post #26
acrossthepond10 wrote: post #22

FPGA Noob here. I have 2 questions about FPGA's that I'm hoping someone here can help me out with: 1. For the FPGAs i've looked at, you seem to have to initially configure them before being able to run your programs on them, kind of like EEPROM. I feel it would be much more interesting from a reconfigurable computing perspective if the devices were able to programatically re-configure on the fly as easily as it is to…

1. I'm not sure what you mean but remember that FPGAs don't run programs as per se (HDL gets compiled to logic, not instructions). The bitstream can be modified, it just gets loaded from some flash. I'm not sure where it's done, but it's possible. 2. The obstacles are billions and billions of R&D (and you'd need similar amounts to get a fab pick up the phone too). Reverse engineering the bitstream is also difficult b…

Regarding 2: the question was about an open-source solution, so I think that "billions and billions of R&D" will translate to just a lot of time spent and no literal cost, e.g. just like GCC is free as in beer.

It is true that getting a wafer fabricated will cost a lot of money (in the millions maybe?) but this may be money well spent because the resulting FPGA design can be used over and over. I think this would be in the reach of perhaps some universities or government technology centers, if someone could formulate the case for it.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#32

Post by zozbot234 »

rkagerer wrote: post #12

I'm disappointed today's general purpose CPU's and microcontrollers don't come with some integrated FPGA space, similar to how you have SRAM and other peripherals. Intel talked about it a few years back [1] but I'm not sure anything materialized. The closest I've seen in popular chips is a few gates worth of programmable logic. Are there any hidden gems I've missed out on? [1] https://www.nextplatform.com/2018/05/24/…

Don't general purpose CPU's and μC's use replaceable microcode as part of the chip implementation? Shouldn't that boil down to the same thing?

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#33

Post by Ductapemaster »

mhh__ wrote: post #28
magicalhippo wrote: post #20

Earlier quoted context omitted.

Well Xilinx has the Zynq-7000 SoC[1], featuring an ARM Cortex-A9 CPU along with a potentially quite large FPGA. Not exactly cheap though, at least in small quantities[2] [1]: https://www.xilinx.com/products/silicon-devices/soc/zynq-700... [2]: https://www.digikey.com/products/en/integrated-circuits-ics/...

Intel has the Cyclone V range. Also, I've never done it myself but I've read that digikey prices are almost never the actual price for FPGAs even in relatively small quantities (haggling with avnet).

Worked with FPGAs at a past gig, and that is correct. There is heavy markup due to the accessibility of the parts.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#34

Post by throwaway4590 »

rkagerer wrote: post #12

I'm disappointed today's general purpose CPU's and microcontrollers don't come with some integrated FPGA space, similar to how you have SRAM and other peripherals. Intel talked about it a few years back [1] but I'm not sure anything materialized. The closest I've seen in popular chips is a few gates worth of programmable logic. Are there any hidden gems I've missed out on? [1] https://www.nextplatform.com/2018/05/24/…

They have the patents to do even better than that and create hierarchies of miniature programmable fabric, similar to the concept of L1-L4 caches except for FPGA designs [0]. Unfortunately, they don't have the organizational willpower to do true innovation though. From what I have heard, significant portions of the designs for their processor lines are not understood by any current or recent employees. There is a tremendous amount of legacy "code" and fear of changing things that may break backwards compatibility. There is no vision at the top, their process lead is gone, and the architecture team is patching decades of bad security without simplifying designs.

It seems like they are just riding out their market share for as long as they can, which could be a while. Intel has a really strong brand.

[0] https://patents.google.com/patent/US10310868B2/

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#35

Post by mhh__ »

amelius wrote: post #31
mhh__ wrote: post #26

Earlier quoted context omitted.

1. I'm not sure what you mean but remember that FPGAs don't run programs as per se (HDL gets compiled to logic, not instructions). The bitstream can be modified, it just gets loaded from some flash. I'm not sure where it's done, but it's possible. 2. The obstacles are billions and billions of R&D (and you'd need similar amounts to get a fab pick up the phone too). Reverse engineering the bitstream is also difficult b…

Regarding 2: the question was about an open-source solution, so I think that "billions and billions of R&D" will translate to just a lot of time spent and no literal cost, e.g. just like GCC is free as in beer. It is true that getting a wafer fabricated will cost a lot of money (in the millions maybe?) but this may be money well spent because the resulting FPGA design can be used over and over. I think this would be…

Nearly all the cool stuff in GCC and LLVM is paid for by companies (paying the salaries of developers). The software could definitely be done in this way (Symbiflow is very very nice), but keep in mind that developing an FPGA will require a lot of hardware and bums in seats.

The question is similar in scale to building an open source Intel core i7 - it's not impossible but keep in mind that an FPGA big enough (for example) to prototype any subsections of the CPU let alone the whole thing would cost hundreds of thousands.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#36

Post by klysm »

tverbeure wrote: post #13

One of the most interesting aspects of the VexRiscv is the way it's implemented. The VexRiscv is written with SpinalHDL, a hardware description library in Scala. But that's not the main thing: in additional to Verilog and VHDL, there are other ways to write RTL, from Python to Scala to Haskell. What's really special is that the VexRiscv is constructed from a large number of plugins that split up the design 'horizonta…

This is somewhat orthogonal to what you are saying, but I’ve wondered for a while if it’s possible to achieve vertical and horizontal abstraction at the same time. When you are working on the actual implementations, horizontal style is clearly preferable, but if you want to change the abstraction, the vertical style is much easier. The limitation of just one being accessible at a time seems to purely be a consequence of the fact that we use the same representation for reading and writing code. Why can’t I switch from vertical to horizontal mode when reading code? Maybe it’s even possible to switch when writing?? With a plug-in like structure you certainly get some benefits but at the same time you can let go of a nice global view - it would be nice to have both.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#37

Post by tverbeure »

klysm wrote: post #36
tverbeure wrote: post #13

One of the most interesting aspects of the VexRiscv is the way it's implemented. The VexRiscv is written with SpinalHDL, a hardware description library in Scala. But that's not the main thing: in additional to Verilog and VHDL, there are other ways to write RTL, from Python to Scala to Haskell. What's really special is that the VexRiscv is constructed from a large number of plugins that split up the design 'horizonta…

This is somewhat orthogonal to what you are saying, but I’ve wondered for a while if it’s possible to achieve vertical and horizontal abstraction at the same time. When you are working on the actual implementations, horizontal style is clearly preferable, but if you want to change the abstraction, the vertical style is much easier. The limitation of just one being accessible at a time seems to purely be a consequence…

In a way, the VexRiscv is already implemented in both directions:

While stages are specified individually, you can declare those stages to collapse together.

The VexRiscv can be specified to be between 2 and 5 stages.

In terms of readability, you still have the 5 stages separated out within the same file.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#39

Post by tverbeure »

tasty_freeze wrote: post #24

I didn't find what clock rate it runs at. It mentions booting linux in 4 seconds, but that is hard to extrapolate into a core clock frequency. 100 MHz? 200 MHz? higher?

I’ve clocked a VexRiscv at 80 MHz on a very old Cyclone II.

On a modern FPGA, 300 to 400MHz should be possible, depending on configuration: caches and branch predictors tends to reduce the clock speed.

You can find some results here: https://github.com/SpinalHDL/VexRiscv#area-usage-and-maximal...

None of those numbers are for the fastest FPGAs.

Re: VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

#40

Post by variaga »

mhh__ wrote: post #28
magicalhippo wrote: post #20

Earlier quoted context omitted.

Well Xilinx has the Zynq-7000 SoC[1], featuring an ARM Cortex-A9 CPU along with a potentially quite large FPGA. Not exactly cheap though, at least in small quantities[2] [1]: https://www.xilinx.com/products/silicon-devices/soc/zynq-700... [2]: https://www.digikey.com/products/en/integrated-circuits-ics/...

Intel has the Cyclone V range. Also, I've never done it myself but I've read that digikey prices are almost never the actual price for FPGAs even in relatively small quantities (haggling with avnet).

Can confirm. The only time I've ever been quoted list price for an FPGA from a distributor (other than digikey) was when our purchasing agent managed to personally enrage the sales guy.

We still didn't end up _paying_ list price (after I made the purchasing guy apologize - no details, but he was 100% in the wrong).

Post reply on HN