[HN Gopher] VexRiscv is a quadcore, Linux-capable RISC-V softcor...
___________________________________________________________________
VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA
Author : homarp
Score : 82 points
Date : 2020-05-21 19:28 UTC (3 hours ago)
(HTM) web link (antmicro.com)
(TXT) w3m dump (antmicro.com)
| lifeisstillgood wrote:
| How far down the road of something like nand2tetris can I take a
| FPGA ? Can I design my own system in verilog and flash it to a
| FPGA like this and effectively run on my own computer?
| teraflop wrote:
| Absolutely.
| ladberg wrote:
| Yep, that's the point of FPGAs. The easiest way to see is to
| synthesize it in an FPGA tool (e.g. Vivado) which you can
| probably do for free. Different FPGAs have different hardware
| resources, but for any small designs you can probably fit them
| on a cheap FPGA.
| non-entity wrote:
| Kind of off topic, but how much time is involved building
| processors with FPGA's, especially for modern architectures like
| RISC-V? I only have a very basic overview knowledge about FPGA's
| and almost none at the time about HDL's (I plan on learning!),
| but with the complexity involved in modern processors, I can't
| imagine this being a few weeks or even months or work.
| q3k wrote:
| RISC-V as an ISA is designed to be easy to implement. You can
| get a simple implementation in 3k lines of Verilog [1].
|
| That being said, there's a huge difference between a toy /
| simple multi-cycle machine-mode RISC-V core and one with a
| modern, performent microarchitecture (pipelined, super-scalar,
| multi-issue, cache coherent across multiple cores, with
| efficient branch prediction). There's also extra work to
| implement RISC-V extensions that let you run any 'real' code
| like Linux (which requires anything from simple ISA extensions
| to implementing the Privileged Instruction spec which dictates
| additional things like the MMU and interrupt controller).
|
| [1] -
| https://github.com/cliffordwolf/picorv32/blob/master/picorv3...
| gchadwick wrote:
| It depends what you want to do? Do you want to build a
| processor from scratch? A basic processor for core RISC-V is
| actually quite simple. The RISC-V I specification (all the core
| instructions not including multi/div, none of the privileged
| spec) is not complex.
|
| Implementing something like the story talks about is obviously
| far more complex.
|
| If you're mostly interested in putting together existing
| processors that can again can vary in complexity, there are
| some things with 'batteries included' where you can just spin
| up an FPGA image that works then go poking around, others where
| there will be significant work in integrating things into a
| working system.
|
| I'll give a plug to Ibex (https://github.com/lowRISC/ibex)
| which is the core I work on, it doesn't have an MMU and is
| targetted at embedded applications. It's a 'real' core, in that
| it's suitable for taping-out into a real system but still quite
| simple to understand. OpenTitan
| (https://github.com/lowRISC/opentitan) is a notable project
| we're also working on that uses it, it's an open source root of
| trust and will give you a working RISC-V SoC you can put on an
| FPGA, you can easily carve out the security things leaving you
| with a RISC-V core, some SRAM and various useful peripherals.
| [deleted]
| tasty_freeze wrote:
| 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?
| amelius wrote:
| Now the only problem left is to find an open-source-friendly FPGA
| manufacturer.
| rkagerer wrote:
| 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/a-peek-inside-
| that-i...
| zozbot234 wrote:
| Don't general purpose CPU's and mC's use replaceable microcode
| as part of the chip implementation? Shouldn't that boil down to
| the same thing?
| opencl wrote:
| Not in the desktop/server space but there are a few products
| like this. Xilinx has the Zynq line with 1-2 Cortex-A9 cores
| paired to an FPGA. Microsemi has their Cortex-M3 based
| Smartfusion line and is supposedly launching their Polarfire
| SoC with 4 RISC-V cores plus an FPGA later this year.
| throwaway4590 wrote:
| 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/
| magicalhippo wrote:
| 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/...
| mhh__ wrote:
| 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).
| Ductapemaster wrote:
| Worked with FPGAs at a past gig, and that is correct. There
| is heavy markup due to the accessibility of the parts.
| sneak wrote:
| Are there many applications that would benefit from having it
| on die versus across a few PCIe lanes? AFAIK putting it on a
| card would still grant it the same full speed DMA it would have
| being on-die with the CPU.
| wmf wrote:
| The benefit from putting it on-die is not speed but economy
| of scale.
| londons_explore wrote:
| With the transition of compute from performance focussed to
| performance per watt focussed (due to cooling usually being the
| limiting factor), the niche for the FPGA has almost vanished.
|
| There are very very very few compute tasks where an FPGA solves
| a problem with better performance per watt than both a CPU and
| a GPU.
|
| I would bet that emulating a RISC-V program on x64 is far more
| power efficient than running a RISC-V core on an FPGA for
| example.
| monocasa wrote:
| There's a lot of use cases today where perf per watt doesn't
| matter.
| londons_explore wrote:
| Name some... Any task where perf per dollar matters also
| boils down to perf per watt, since watts cost dollars...
| monocasa wrote:
| Say, robotics where the difference between an FPGA and
| something else is way overshadowed by the motors.
|
| Or really basically anywhere that has you interacting
| with the real world directly connected to your compute,
| and not just compute off in a datacenter.
| anonymousDan wrote:
| I thought FPGAs were more power efficient than GPUs for many
| ML applications for example (CNNs aside)?
| londons_explore wrote:
| For unusual ML architectures, like 1 bit precision, that
| might be true.
|
| For anything using floating point maths, it isn't true.
| tverbeure wrote:
| 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 'horizontally'
| per feature instead the traditional 'vertical' way that is
| pipeline-stage oriented.
|
| It makes it possible to implement all aspects of, say, a new
| instruction in one file, instead of spreading it over many
| different files.
|
| I've written about that here:
| https://tomverbeure.github.io/rtl/2018/12/06/The-VexRiscV-CP....
| acrossthepond10 wrote:
| 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 read and write to DRAM or Flash Memory. So what are the
| barriers that prevent the hardware from being able to do this?
|
| 2. Its exciting to see projects like Symbiflow making great
| progress, but after reading some expert opinions[1] it seems like
| an extremely difficult challenge to attempt to reverse engineer
| hardware from commercial FPGA vendors who wish to keep their
| designs closed in order to protect their IP and compete. So my
| question is wouldn't it be a more feasible goal to construct
| fully open FPGA platform from scratch, just like RISC-V is doing
| with CPUs? What would the obstacles be here?
|
| Thanks!
|
| [1]
| https://www.reddit.com/r/FPGA/comments/a5pzs5/prediction_ope...
| tverbeure wrote:
| 1. Most higher capacity FPGA have a features called "partial
| reconfiguration" where you can reload a part of the FPGA with a
| new bitstream. This new part can usually come from anywhere
| (PCIe, SPI, ...)
|
| 2. RISC-V is a ISA. It's not an implementation. You can
| implemented it on FPGA or ASIC. When you implement a RISC-V on
| an FPGA, it will cost you between $2 and maximum a few $1000 in
| silicon. FPGA technology itself is something that can only
| reasonably be implemented in an ASIC. The initial cost of an
| ASIC can go anywhere from $100K (on a very old process) to
| multiple millions.
| mhh__ wrote:
| 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 because of
| this - Symbiflow (i.e. Trellis etc.) have got the bulk of the
| bitstream done (apart from specialized blocks like those for
| DSP), but you need to have good algorithms to decide what to do
| with that bitstream e.g. a fully open source flow requires
| intricate timing analysis.
| amelius wrote:
| 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.
| mhh__ wrote:
| 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.
| dhanna wrote:
| Is Dolu1990 the primary developer of everything SpinalHDL
| related?
|
| I'm genuinely impressed with his effort.
| eebynight wrote:
| The fact that it fits in the 35T version with room to spare is
| pretty huge, especially since certain packages of the 35T start
| as low as $35 for a single chip, no MOQ.
|
| I could see myself dropping one of these on a homemade project if
| I ever spend the time making a reliable reflow oven...
| tverbeure wrote:
| If you're happy that it fits in a 35T, you'll be ecstatic to
| learn that a single VexRiscv fits comfortably in a Cyclone II
| EP2C5 FPGA. :-)
|
| It's hard to find an FPGA that's too small to fit one.
| gchadwick wrote:
| Worth mentioning SymbiFlow: https://symbiflow.github.io/, it's a
| fully open-source flow for FPGAs, Xilinx support (targetting the
| Arty A7 that the project in this story uses for instance) is on
| the way so hopefully won't be long until you can build a
| opensource RISC-V SoC that can run Linux entirely on open source
| tooling.
___________________________________________________________________
(page generated 2020-05-21 23:00 UTC)