9 ms·
Why I will be using RISC-V in my next chip
- dbdjxjcnd 11y agoSIMD and VLIW are the future of microprocessors, and unfortunately it doesn't seem like this ISA will be able to support them.
- creshal 11y agoRISC-V has a vector mode that can be used for SIMD applications. VLIW has been the future since the 80s, and we're still waiting for the magic wonder compilers that can actually spit out efficient VLIW code. Even GPUs have abandoned VLIW (AMD TeraScale) in favour of RISC (Nvidia, AMD GCN).
- _yosefk 11y agoVLIW DSPs are in every phone. VLIW CPUs are almost certainly a bad idea and as to GPUs, AFAIK VLIW needs to coexist with barrel threading there which might create problems. But VLIW certainly has its place.
- creshal 11y agoIn DSPs, sure, but not in general-purpose CPUs or GPUs.
- adapteva 11y agoMost DSP archs came out of thr 90's and many of the cores today are a reflection of that trend (ceva etc). I worked on the TigerSharc DSP for 8 years and can tell you that from an implementation standpoint they can be a nightmare! Not sure they do have a viable place long term from an economical perspective.
- wsxcde 11y agoI suspect the DSP makers just use VLIW because of interia. They probably don't have the money or incentive to revisit their old decisions. Also wouldn't you say that most of the stuff that used to be implemented on DSPs is now moving into ASICs? I wouldn't be so sure that VLIWs are going to be around forever.
- sklogic 11y agoVLIW is many times cheaper (in terms of power and area) than OoO. It is not going anywhere from the low budget range.
- wsxcde 11y agoBut VLIW and OoO aren't the only two design points. The renewed interest in traditional inorder vector processors. In any case, I do think the point of DSPs was to be area/power efficient for certain specialized algorithms, and a lot of these are just becoming ASICs/specialized accelerators today.
- Marat_Dukhan 11y agonVidia Kepler and Maxwell (i.e. the two latest archs ATM) use VLIW instruction encoding
- creshal 11y agoDo they? I can't find anything about it. VLIW for GPUs is always only mentioned in the context of AMD TeraScale – which has been obsoleted in favour of a RISC architecture five years ago.
- Marat_Dukhan 11y agoI guess that's because unlike AMD, nVidia doesn't officially document the GPU instruction set. But if you disassemble .cubin with nvdisasm, you'd see that code of Kepler/Maxwell is organized in bundles of 4/8 words, where the first word doesn't encode any instruction. Here is what Scott Gray of Nervana Systems, who developed a native assembler for Maxwell, write about it[1]: "Starting with the Kepler architecture Nvidia has been moving some control logic off of the chip and into kernel instructions which are determined by the assembler. This makes sense since it cuts down on die space and power usage, plus the assembler has access to the whole program and can make more globally optimal decisions about things like scheduling and other control aspects. The op codes are already pretty densely packed so Nvidia added a new type of op which is a pure control code. On Kepler there is 1 control instruction for every 7 operational instructions. Maxwell added additional control capabilities and so has 1 control for every 3 instructions." [1] https://github.com/NervanaSystems/maxas/wiki/Control-Codes https://github.com/NervanaSystems/maxas/wiki/Control-Codes
- cmrx64 11y agoFalse. http://hwacha.org/ http://hwacha.org/
- analognoise 11y agoInteresting project; no updates for a year. I wonder how the project is going?
- sagark 11y agoWe've recently released a couple of tech reports on Hwacha: Hwacha Vector-Fetch Architecture Manual: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.pdf https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2... Hwacha Microarchitecture Manual: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.pdf https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2... Preliminary Evaluation Results: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-264.pdf https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2... M.S. Thesis on Mixed Precision in Hwacha: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-265.pdf https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2...
- analognoise 11y agoInteresting project; no updates for a year. I wonder how the project is going?
- _chris_ 11y agoThere's a chapter in the current RISC-V manual that explains how you could make a RISC-V-like VLIW ISA. But VLIW is most certainly NOT the "future". VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code. And the concept of baking into your ISA what the designer believes is the "perfect functional unit mix" is an anti-pattern. What's the perfect mix depends on the benchmark, and it changes from basic block to basic block. A history of failed VLIW projects can attest to this. A dynamic superscalar is far superior, even in power-efficiency.
- protomyth 11y ago"VLIW demands an even "mix" of instruction types,and it's hugely incompatible with general-purpose application core." Has anyone ever done a study / experiment of a VLIW with multiple hardware threads and how that would impact the need for an even mix?
- _chris_ 11y agoThe studies I've seen have shown that the FU mix is heavily skewed and changing on every basic block, particularly when you offload the DLP to a more efficient vector/SIMD unit. I'm not sure I see how MT would solve the mix problem, if each thread gets an issue cycle (and each thread itself has a bad mix).
- protomyth 11y agoI was just thinking that the the bad mixes might on average fill in the gaps to what the processor actually had for resources.
- creshal 11y agoEven GPUs, which have arguably far more predictable instruction mixes, struggled massively to get a useful utilization on VLIW architectures – AMD tried two different ones from 2006 to 2011 before they finally gave up on the concept and started using RISC architectures like Nvidia had been using all the time.
- legulere 11y agoBy what I've been told, VLIW makes only really sense in some use cases such as DSP processors. With general purpose computing it happens way too often that you can't find enough instructions that are independent of each other. For the case where it is possible to execute instructions in parallel, you can make your CPU superscalar. The simple nature of the RISC-V ISA probably should make supercalarability easy and performant.
- zhemao 11y agoWe already have a RISC-V superscalar out-of-order core, the Berkeley Out-of-Order Machine (BOOM). https://github.com/ucb-bar/riscv-boom https://github.com/ucb-bar/riscv-boom
- nickpsecurity 11y agoGood that they're getting on the bandwagon as they're already popular with maker types. I also like the serendipity where this post led me to an equally exciting one: http://www.adapteva.com/announcements/an-open-source-8gbps-low-latency-chip-to-chip-interface/ http://www.adapteva.com/announcements/an-open-source-8gbps-l... Love that they developed and open-sourced a 8Gbps, 1us, I/O interface. That might come in handy. :)
- stolsvik 11y agoGPL License - kills all hope.
- adapteva 11y agoNope, it's now MIT license!!
- nickpsecurity 11y agoI didn't check licensing for GPL because I figure you knew better on HW. Glad you people chose wisely. :)
- purpled_haze 11y agoEven though it isn't GPL anymore, how exactly would it kill all hope?
- nickpsecurity 11y agoHow much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you're going to need something that integrates with proprietary if you want them to build on it. There's still the possibility of a LGPL-style thing where at least re-synthesized or optimized versions of the open-source part must be re-released. However, forcing that for I.P. it integrates with would kill adoption by any provider unless they like operating at six to eight digit losses. Annually.
- mdergosits 11y agoThat's awesome! RISC-V seems like a well defined ISA that allows for lots of extensions. Seems like a perfect fit for a board like the parallella.
- daniel-cussen 11y agoDoes anybody have a cached version of this? It keeps returning db errors.
- azdle 11y agoGoogle Cache Link: https://webcache.googleusercontent.com/search?q=cache:http%3A%2F%2Fwww.adapteva.com%2Fandreas-blog%2Fwhy-i-will-be-using-the-risc-v-in-my-next-chip https://webcache.googleusercontent.com/search?q=cache:http%3...
- PuffinBlue 11y agoSite seems slow and might go down: mirror http://i.imgur.com/0FmTYcH.png http://i.imgur.com/0FmTYcH.png (Fullpage screenshot as Google cache lacked styling)
- browser-bob 11y agohttps://archive.is/iEfhg https://archive.is/iEfhg
- browser-bob 11y agoCan RISC-V be implemented in the on-board Xilinx Zynq 7020 FPGA of the A101040 (Epiphany III) Parallella?
- adapteva 11y agoDefinitely! Straightforward, especially if you use https://github.com/parallella/oh https://github.com/parallella/oh
- browser-bob 11y agoOh! Sweet!
- zhemao 11y agoYes, definitely. Berkeley's open-source Rocket[1] core can already be programmed onto the Zedboard and ZC706[2], which also use Zynq 7000 series FPGAs. Getting it to work on the Parallela should just be a matter of changing the clock constraints and pin settings and finding a configuration that will fit on the FPGA. [1] https://github.com/ucb-bar/rocket-chip https://github.com/ucb-bar/rocket-chip [2] https://github.com/ucb-bar/fpga-zynq https://github.com/ucb-bar/fpga-zynq
- cmrx64 11y agonot to mention the smaller implementations like picorv32 and zscale/vscale.
- browser-bob 11y agoNeat-o! Thanks :)
- gluggymug 11y agoWhy do you want to do that? Isn't there a hard ARM core on the Zynq 7000s ?
- WhitneyLand 11y agoHow does RISC-V get around the issue of patent mine fields? For example we've seen its really difficult to make a competitive codec without infringing and even when it's accomplished there is lingering doubt until it's challenged. I hope this situation is somehow much different.
- _chris_ 11y agoThis is why they have a RISC-V foundation, made up of big and small companies (Google, Oracle, HPE, etc.). Most (all?) of the RISC-V ISA is stuff that is out of patent and has a lineage going back more than 20 years. This issue is definitely important and it's not being ignored!
- adapteva 11y agoI am sure the RISC-V core team has a much better answer. Their mission statement is a good start. https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-1... The good news is that RISC has been around since the early 80's so any killer hardware patent will likely have expired by now. Note that the RISC-V ISA is separate from any hardware implementations. If you get fancy with your micro-architecture you can definitely trample on one of the 1000's of micro-architecture patents filed across the industry.
- wsxcde 11y agoPatterson says they've tried their best to make sure it doesn't infringe on patents they know about but they obviously can't provide any guarantees.
- codebook 11y agoI'm still not sure whether RISC-V will be one of main stream microprocessor in the industry field. 1. Still the core is not yet solid. 2. Not much powerful debugging tools exist. 3. Chisel itself. Every engineer who is willing to use RISC-V should understand output of chisel source code in order to do ECO or some other low level jobs. 4. BSD itself. It is strong and also weakness. There's no way to merge revision into main repository. It will not be quite trouble if RISC-V remains as it is. But will be a big problem if RISC-V evolves by its own development team. I hoped this RISC-V becomes mainstream processor since I attended the lecture from Mr.Yunsup Lee 4 years ago. I really want to say "I was wrong at that moment" after all.
- _chris_ 11y agoChisel? There are dozens of non-Chisel RISC-V cores out there already (and many more that are closed source and being used by companies like Bluespec and Rumble).
- zhemao 11y agoThere's a distinction between the RISC-V ISA and our open source processor implementations. The ISA is an open standard that anyone can make an implementation of. There are many RISC-V implementations out there. Most of them are not based on our RocketChip codebase and use Verilog, not Chisel.
- userbinator 11y agoI'm surprised to see a lot of RISC proponents still around, because I think it's quite clear that things didn't quite work out the way they thought it would --- the vision of cheap, simple, high-performance CPUs just didn't happen. Thus I'm not of the opinion that another "MIPS, but free" architecture is such a good idea. Benchmarks are controversial but by most measures the RISC-V performance should be “good enough” for most use cases In my experience, statements like this really mean "it's actually really bad, but we don't want to say that"... after all, who would call benchmarks "controversial" if they were winning? There do tend to be few comparative benchmarks, but here's one that shows how ARM and x86 are competitive, but MIPS is behind in energy efficiency: http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient http://www.extremetech.com/extreme/188396-the-final-isa-show... Even modern ARM cores, an architecture that started out being very RISC, use microinstruction-based translation in their front end and probably have more in common with Intel's microarchitectures than MIPS and the like. I think a "CISC-V" could be more interesting - something x86-like (AFAIK the remaining patents are only on the Pentium and above instruction set extensions, and those may expire soon, so 486 and below are now public-domain ISAs) with a small dense instruction set, but extended in a different direction. "x86, but free". ("ARM, but free" would likely not work for legal reasons.)
- e12e 11y agoBut aren't modern Intel and AMD CPUs internally RISC(-like)? It seems like we have great compilers for CISC targets, and can make great RISC CPUs that process CISC instruction sets really well? Perhaps the issue is that the internals of eg. modern Intel CPUs are locked up at Intel, so the missing step from CISC assembly to efficient RISC is missing (while we've got high-level/C/C++ to CISC covered)?
- Marat_Dukhan 11y agoNo they aren't internally RISC. On big Intel & AMD cores "ADD reg, mem" translates to a single uop. On Intel Atom even "ADD mem, reg" translates to a single uop. In fact, it is mostly legacy instructions (e.g. binary-coded decimal arithmetic) that are translated into multiple uops.
- krupan 11y agoJust one question, is it pronounced "risk five" or "risk vee?"
- microcolonel 11y agoFive.
- bjconlan 11y agoI think my biggest concern is big blue, I'm sure they will have an eagle eye on this and make sure that as soon as someone accidentally adds support that falls close to one of their patients it will stifle the energy and progress of the community. The further they slide into the abyss the more desperation will drive moves like this... But only time will tell.
- melted 11y agoThere's no way any of this will remain "free" though. Established players won't allow it, you'll have to license their patent portfolios to make anything at all.
- chei0aiV 11y agoCould you also please make an open FPGA, based on this design? https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43.html https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-4...
- adapteva 11y agoI had the pleasure of meeting Professor Ranjit Manohar of Cornell a few years ago. He was the founder of Achronix, an FPGA startup. He said: -only 2% of the standard FPGA fabric does useful work.. & -the really expensive part to develop is the IO (too many standards) Having an open FPGA is a a good start, but it will only be truly useful if the IO and the optimization is brought up to date with modern fpgas. Today's fpgas are really structured asics. Very much for an open fpga, but let's not underestimate the investments made by fpga companies to get to the current state of the art. Building platforms is very expensive [ref mythical man month]