Why I will be using RISC-V in my next chip(adapteva.com)
adapteva.com
Why I will be using RISC-V in my next chip
http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip
13 comments
That'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.
How 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.
I 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-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.
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.
This 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!
Patterson 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.
I'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-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.)
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-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.)
Market success != technical merit. However, if you're willing to consider ARM a RISC (well, almost) then there's your market success. Alpha completely dominated the performance segment for years, but they fell behind for reasons that has nothing to do with CISC vs. RISC. At the time, x86 compatibility mattered more than it does today.
For people designing their own cores for whatever reason (there can be many, research and commercial), RISC-V is very attractive because of all the reasons already given, but it's obviously not the only option.
RISC-V is carefully designed compromise; it scales down to extremely cheap cores and up to superscalar. Like Alpha before it, extreme attention has been paid to avoid features/choices that would be bad for OoOE implementations. Some examples:
- rs1, rs2, rd fields are always in the same location and all register sources and destinations are explicit (makes decoding faster and you can start fetching/renaming without having decoded)
- there are no branch delay slots
- instructions produce at most a single result
- no condition codes etc (dependencies are explicit)
- the sign-bit for all immediate fields is in a fixed location (cheaper sign-extension)
and so forth.
I'm also a big fan of the conditional branch instruction which unlike the Alpha can compare two registers.
For people designing their own cores for whatever reason (there can be many, research and commercial), RISC-V is very attractive because of all the reasons already given, but it's obviously not the only option.
RISC-V is carefully designed compromise; it scales down to extremely cheap cores and up to superscalar. Like Alpha before it, extreme attention has been paid to avoid features/choices that would be bad for OoOE implementations. Some examples:
- rs1, rs2, rd fields are always in the same location and all register sources and destinations are explicit (makes decoding faster and you can start fetching/renaming without having decoded)
- there are no branch delay slots
- instructions produce at most a single result
- no condition codes etc (dependencies are explicit)
- the sign-bit for all immediate fields is in a fixed location (cheaper sign-extension)
and so forth.
I'm also a big fan of the conditional branch instruction which unlike the Alpha can compare two registers.
However, if you're willing to consider ARM a RISC (well, almost) then there's your market success.
ARM wasn't really a pure RISC from the beginning (e.g. multicycle instructions like LDM/STM, pre/post-increment addressing modes, built-in shifts), and I'd say the market success, especially more recently, is attributable to the fact that ARM cores are becoming more x86-like.
On the other hand, MIPS is the quintessential RISC, and hit as enjoyed some success, but was never really known much for amazing performance or efficiency. I suspect RISC-V will be similar, and all the cheap Chinese tablets/phones/etc. that are currently using MIPS may switch to RISC-V instead, although many are unlicensed clones so cost may not be a factor to them.
Alpha completely dominated the performance segment for years, but they fell behind for reasons that has nothing to do with CISC vs. RISC.
Alphas relied primarily on clock frequency to achieve their performance, and were very power-hungry as a result. This is absolutely the RISC philosophy of performance via simpler designs and increasing clock frequency, which stopped being viable long ago. A 200MHz 21064 can do 0.675DMIPS/MHz and consumes 30W, or 0.0225DMIPS/MHz/W; a Pentium (P5) 100MHz has 1.88DMIPS/MHz and consumes 10W, for 0.188DMIPS/MHz/W.
ARM wasn't really a pure RISC from the beginning (e.g. multicycle instructions like LDM/STM, pre/post-increment addressing modes, built-in shifts), and I'd say the market success, especially more recently, is attributable to the fact that ARM cores are becoming more x86-like.
On the other hand, MIPS is the quintessential RISC, and hit as enjoyed some success, but was never really known much for amazing performance or efficiency. I suspect RISC-V will be similar, and all the cheap Chinese tablets/phones/etc. that are currently using MIPS may switch to RISC-V instead, although many are unlicensed clones so cost may not be a factor to them.
Alpha completely dominated the performance segment for years, but they fell behind for reasons that has nothing to do with CISC vs. RISC.
Alphas relied primarily on clock frequency to achieve their performance, and were very power-hungry as a result. This is absolutely the RISC philosophy of performance via simpler designs and increasing clock frequency, which stopped being viable long ago. A 200MHz 21064 can do 0.675DMIPS/MHz and consumes 30W, or 0.0225DMIPS/MHz/W; a Pentium (P5) 100MHz has 1.88DMIPS/MHz and consumes 10W, for 0.188DMIPS/MHz/W.
This is getting off-topic, but ARMs success had nothing to do with RISC vs. CISC. It was that _Alpha_ engineers took their skill to the ARM ISA (which at the time had only very weak implementations). They created StrongARM which made people sit up and take notice. Intel ironically inherited the technology and continued developing it under the XScale name. So, yes, Intel in part created their own ARM problem.
I feel I have to repeat again that none of this had to do with RISC vs. CISC. It had to do with implementation and market muscle.
"Alphas relied primarily on clock frequency to achieve their performance, and were very power-hungry as a result"
So was the P4 and it failed, but Intel had enough capital to take a power efficiency clue from Transmeta and turn the ship 180 degrees.
What killed the Alpha was three things: delays in getting the new models out, the cost of staying in this game, and of course, the arrival of Itanic.
EDIT: An aside: the 64-bit extension of ARM is a completely new and different ISA called AArch64 which incidentally is a lot more RISC-like than the original ARM. IOW, it looks like the ARM designers disagree with you.
I feel I have to repeat again that none of this had to do with RISC vs. CISC. It had to do with implementation and market muscle.
"Alphas relied primarily on clock frequency to achieve their performance, and were very power-hungry as a result"
So was the P4 and it failed, but Intel had enough capital to take a power efficiency clue from Transmeta and turn the ship 180 degrees.
What killed the Alpha was three things: delays in getting the new models out, the cost of staying in this game, and of course, the arrival of Itanic.
EDIT: An aside: the 64-bit extension of ARM is a completely new and different ISA called AArch64 which incidentally is a lot more RISC-like than the original ARM. IOW, it looks like the ARM designers disagree with you.
What are you qualifications in computer architecture? You're arguing against pretty much everyone in the field.
> I'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.
You seem to be implying that there's RISC failed. If you ask anyone who mattered in computer architecture ranging from academics like Patterson who literally wrote the most used books in the field to Intel fellows, they'll all tell you that the essential point the RISC folks were making was proven right. This point being that RISC is requires less logic (=area,power) to implement, it's easier to write compilers for, processors have faster cycle times, and so on.
In the end though, it turned out the market valued software compatibility over performance. That, good marketing and a phenomenally efficient supply chain and fab resulted in Intel winning. But don't confuse this with CISC winning or RISC losing. If Intel had to do a clean slate design today, they'd do RISC themselves. In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.
> 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:
The benchmark performance depends only on how much effort is put into optimizing the implementation. Intel have on average maybe 200 architects and 200 more designers tweaking their processors for performance for the last 30 years. It is completely absurd to expect a team of 10 or so grad students to compete with them.
> I'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.
You seem to be implying that there's RISC failed. If you ask anyone who mattered in computer architecture ranging from academics like Patterson who literally wrote the most used books in the field to Intel fellows, they'll all tell you that the essential point the RISC folks were making was proven right. This point being that RISC is requires less logic (=area,power) to implement, it's easier to write compilers for, processors have faster cycle times, and so on.
In the end though, it turned out the market valued software compatibility over performance. That, good marketing and a phenomenally efficient supply chain and fab resulted in Intel winning. But don't confuse this with CISC winning or RISC losing. If Intel had to do a clean slate design today, they'd do RISC themselves. In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.
> 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:
The benchmark performance depends only on how much effort is put into optimizing the implementation. Intel have on average maybe 200 architects and 200 more designers tweaking their processors for performance for the last 30 years. It is completely absurd to expect a team of 10 or so grad students to compete with them.
You seem to be implying that there's RISC failed.
It did fail to deliver on all its promises.
RISC is requires less logic (=area,power) to implement
True, but ultimately it is overall energy usage that is important. A tiny low-power CPU with less performance will take longer to complete a task than a larger faster higher-power one, meaning it consumes more energy. That's what the article I linked to shows.
processors have faster cycle times
That's not necessarily a good thing, as Intel's failed NetBurst microarchitecture shows. Making a CPU with such short delays that it can run at upwards of 10GHz is futile, as power dissipation becomes a huge problem long before that.
In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.
If you're referring to the ARC4 in the Management Engine, I have a feeling that was chosen for reasons other than being RISC or otherwise.
It is completely absurd to expect a team of 10 or so grad students to compete with them.
I remember it said that RISC would be so simple and performant that such small teams could easily design CPUs which vastly outperform the big CISCs at much lower prices, so I don't think it's that absurd of an expectation.
It did fail to deliver on all its promises.
RISC is requires less logic (=area,power) to implement
True, but ultimately it is overall energy usage that is important. A tiny low-power CPU with less performance will take longer to complete a task than a larger faster higher-power one, meaning it consumes more energy. That's what the article I linked to shows.
processors have faster cycle times
That's not necessarily a good thing, as Intel's failed NetBurst microarchitecture shows. Making a CPU with such short delays that it can run at upwards of 10GHz is futile, as power dissipation becomes a huge problem long before that.
In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.
If you're referring to the ARC4 in the Management Engine, I have a feeling that was chosen for reasons other than being RISC or otherwise.
It is completely absurd to expect a team of 10 or so grad students to compete with them.
I remember it said that RISC would be so simple and performant that such small teams could easily design CPUs which vastly outperform the big CISCs at much lower prices, so I don't think it's that absurd of an expectation.
The reason they're dancing around the performance figures is because a) synthetic benchmarks like SPEC and CoreMark are of questionable value, and b) They don't have chips in customers' hands quite yet, so they can't be independently reproduced.
If you look at the current results for Rocket and BOOM, you'll find that these microarchitectures seem competitive with Cortex A5/A8 and Cortex A15 respectively at comparable frequencies.
In addition to this, they seem to have some significant amount of space savings on die. Power/performance ratios already seem to be better (likely due in part to smaller die area).
On a power-performance front, a bigger OoO RISC-V could likely be competitive in peak performance to an intel, though you'd have to find a market for that. There has also been a lot of discussion about a real vector machine extension, and that would likely wipe the floor with x86's packed SIMD if done right.
If you look at the current results for Rocket and BOOM, you'll find that these microarchitectures seem competitive with Cortex A5/A8 and Cortex A15 respectively at comparable frequencies.
In addition to this, they seem to have some significant amount of space savings on die. Power/performance ratios already seem to be better (likely due in part to smaller die area).
On a power-performance front, a bigger OoO RISC-V could likely be competitive in peak performance to an intel, though you'd have to find a market for that. There has also been a lot of discussion about a real vector machine extension, and that would likely wipe the floor with x86's packed SIMD if done right.
Much more importantly, an Intel design team has something like 1200 engineers working for 2-2.5 years on the next generation of an existing processor. I don't know about ARM, but I'd guess they probably something like a team of 200-300 people on working on each revision.There's no way a team of 10 or so grad students can hope to out-optimize them.
Also SPEC isn't a synthetic benchmark, it contains real applications like bzip2 and gcc.
Also SPEC isn't a synthetic benchmark, it contains real applications like bzip2 and gcc.
The problem with SPEC is it is a 1990's workstation benchmark suite... should my cell phone processor's design be guided by how quickly it can compile ia32 code? Or simulate quantum computers?
Sure, that's fair. I was just pedantic about the precise meaning of a "synthetic" benchmarks, which is a benchmark generated to mimic real code but isn't a real/useful application by itself.
But 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)?
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)?
No 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.
x86 uops are very wide, much wider than RISC instructions and more like VLIWs; P6 uops are 118 bits and I haven't easily found any description of the newer models but they are likely even wider.
The latest number I have is 157 bits in Intel Core (for a ROB entry).
Thinking about it, it is probably not difficult to create a x86 subset that is user mode compatible with most modern programs but lacks things like segmentation.
Can RISC-V be implemented in the on-board Xilinx Zynq 7020 FPGA of the A101040 (Epiphany III) Parallella?
Yes, 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 [2] https://github.com/ucb-bar/fpga-zynq
[1] https://github.com/ucb-bar/rocket-chip [2] https://github.com/ucb-bar/fpga-zynq
not to mention the smaller implementations like picorv32 and zscale/vscale.
Neat-o! Thanks :)
Definitely! Straightforward, especially if you use https://github.com/parallella/oh
Oh! Sweet!
Why do you want to do that? Isn't there a hard ARM core on the Zynq 7000s ?
Site seems slow and might go down: mirror
http://i.imgur.com/0FmTYcH.png
(Fullpage screenshot as Google cache lacked styling)
http://i.imgur.com/0FmTYcH.png
(Fullpage screenshot as Google cache lacked styling)
I'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.
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.
There'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.
Chisel? 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).
There'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.
Does anybody have a cached version of this? It keeps returning db errors.
Google Cache Link: https://webcache.googleusercontent.com/search?q=cache:http%3...
Could you also please make an open FPGA, based on this design?
https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-4...
https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-4...
I 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]
-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]
SIMD and VLIW are the future of microprocessors, and unfortunately it doesn't seem like this ISA will be able to support them.
RISC-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).
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).
VLIW 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.
Most 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.
In DSPs, sure, but not in general-purpose CPUs or GPUs.
I 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.
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.
VLIW is many times cheaper (in terms of power and area) than OoO. It is not going anywhere from the low budget range.
But 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.
nVidia Kepler and Maxwell (i.e. the two latest archs ATM) use VLIW instruction encoding
Do 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.
I 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
[1] https://github.com/NervanaSystems/maxas/wiki/Control-Codes
There'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.
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.
VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code.
The Itanium is a great example of this. Benchmarks that pushed the CPU to its limits looked amazing, but real-world performance with general-purpose code was awful. There just isn't enough parallelism in general-purpose code to justify extremely huge instruction bundles that will mostly be wasted with NOPs.
The Itanium is a great example of this. Benchmarks that pushed the CPU to its limits looked amazing, but real-world performance with general-purpose code was awful. There just isn't enough parallelism in general-purpose code to justify extremely huge instruction bundles that will mostly be wasted with NOPs.
"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?
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?
The point of VLIW is to eliminate the hazard detection and scheduling logic required by normal superscalar, but SMT would require much of that logic to be added back. So VLIW can't really use SMT. VLIW could use FGMT (e.g. barrel processor) or SoEMT, but those can't fill the empty issue slots caused by bad instruction mix.
The 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).
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).
I was just thinking that the the bad mixes might on average fill in the gaps to what the processor actually had for resources.
Even 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.
By 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.
We 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
False. http://hwacha.org/
Interesting project; no updates for a year. I wonder how the project is going?
We'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-2...
Hwacha Microarchitecture Manual: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2...
Preliminary Evaluation Results: 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-2...
Hwacha Vector-Fetch Architecture Manual: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2...
Hwacha Microarchitecture Manual: https://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-2...
Preliminary Evaluation Results: 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-2...
I 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.
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. :)