I thought that microprocessor production and design was fraught with risk of infringing on other designers' patents (even for original ISAs). I can see that industry heavyweights have arrived to support RISC-V, so hopefully that comes with a team of professors/lawyers that could defend them. But, why now? Why couldn't this have happened sooner? Didn't Sun try to create an open SPARC processor design? What does RISC-V have that it didn't?
Is the intent for RISC-V to compete with modern high-end CPU designs, or do we just want to have royalty-free microprocessors for our embedded devices?
You might be surprised (at least I was) to learn that peripherals like hard drives and PCI-add-in cards usually have their own CPU executing their own software. Those processors are often MIPS/ARM/etc based and the manufacturer has to shell out to someone to be able to use that, even if they designed the processor themselves. I can see how this particular market is ripe for something like RISC-V. But does anyone expect RISC-V to really go head-to-head with Xeon, Opteron, ThunderX, Centriq?
I sound incredulous because this seems surprising to me, but I have no evidence to suggest whether it's as unlikely as I think. I've certainly seen open source software designs far superior to closed source ones, so maybe hardware design is no different?
The RISC-V team was very careful in establishing prior art for every design decision. The patents on ISAs tend to be on their quirks, so keeping things truly minimal helps avoid all of that complexity.
Like a lot of what Sun did, prior open chip designs weren't good enough. Academics starting with a clean slate and a 20+ years of additional experience gives RISC-V real advantages over MIPS and ARM.
The primary advantage is that RISC-V is truly RISC: they have a core ISA that is frozen but extendable. This means that they can have application-specific CPUs with intelligent fallback and full compatibility.
As to why now, well, they came up with RISC-V as a teaching ISA and started getting emails from industry asking why it had changed from last semester. It turns out that chip manufacturing has gotten cheap, with custom runs on 28nm processes going for $30K.
You are correct in that their early target market are co-processors and other niche components. Just getting a license from ARM is 10+ million dollars. But the biggest cost in building your own ISA is investment in software and tooling. RISC-V gives a common foundation for everyone to build on.
However, their intent is indeed to bring competition at every level. Their licensing scheme was chosen specifically to allow big players to create IP and keep the secret sauce to themselves, unlike SPARC V8 and OpenRISC.
Apple creates their own CPU and GPU designs, Google has custom hardware for machine learning, and Samsung is about to overtake Intel as the world's largest chip manufacturer. Why should they keep shelling out billions to ARM, Intel, and AMD just to use their ISA?
> Just getting a license from ARM is 10+ million dollars.
Which license? ARM offers several different models.
> Apple creates their own CPU and GPU designs, Google has custom hardware for machine learning, and Samsung is about to overtake Intel as the world's largest chip manufacturer. Why should they keep shelling out billions to ARM, Intel, and AMD just to use their ISA?
The Google hardware we know (TPU) for learning does not use ARM at all, so they would obviously pay nothing there. BigCo's like Apple or Samsung are probably ARM partners, so no per-design/unit fees.
Samsung Electronics may become the biggest chip manufacturer soon, but much like with smartphones that's only by turnover, not profit. But profit is what ultimately finances your R&D.
An interesting titbit is that even Intel and ARM are, at least on paper, partners.
>BigCo's like Apple or Samsung are probably ARM partners, so no per-design/unit fees.
Nope, all ARM licensees pay a per-unit royalty, regardless of their partnership level[0]. Being the biggest might help Apple and Samsung negotiate a slightly lower royalty rate, but by the end of the day it's still at least 1% of the chip's selling price.
> but by the end of the day it's still at least 1% of the chip's selling price.
Right, but you cannot just consider the difference in royalty fees between ARM and another ISA.
For example, the STM32F* chips cost between $0.60 (STM32F0) [0] and $19 (STM32F7) [1].
You can't just compare the royalty fee here when thinking of lost revenue for the manufacturer. The ARM ecosystem is huge, and if ST switched to another ISA, they would probably lose customers unless the new ISA had an ecosystem that was as good or better than ARM.
Yes, the royalty amount matters, but customer preferences also matter. I doubt any high volume ST customer would be willing to switch to an entirely new ISA without the kind of ecosystem that ARM has for a few pennies per chip. And who is going to pay for the development of the tools? Unless it's someone like RISC-V, then they're probably stuck developing it themselves. Kiss goodbye to all the money you "saved" by not paying ARM royalties.
Furthermore, if ST switched to a different ISA to save the ARM royalty, what makes you think they would pass along that savings to the customer?
Bluespec, AMD, Qualcomm, IBM, NVidia, Micron, NXP, Samsung and a few dozen other companies are all dues paying members of the RISC-V foundation. I think it's possible for them to create a new ecosystem, just give them time.
Apples and oranges. The companies that design the chips and pays royalties for IP are mostly fabless (with rare exceptions like Intel). The fabs are owned by separate entities like TSMC, Samsung, SMIC that specialize in the production itself. The fabs don't pay for CPU IP (they sometimes pay for some other basic IP to be able to offer them as standard to their customers, but that doesn't cover CPUs/GPUs).
About Samsung, they're on both sides but with separate legal entities.
The licensing cost IS usually significant to most fabless companies, who come in many sizes. Most are not as big as Apple or NVidia. The fabless model comes from the very high cost of a modern fab, it allows sharing a fab through many fabless design houses.
ARM has the reputation of being cheap, because the typical IT/software people compare them to Intel. And yes, compared to Intel most anyone is cheaper ;) But in the embedded space, which is cost sensitive, ARM is not cheap. It's like what IBM and Microsoft were in IT: nobody got fired for choosing them, and they come with a very powerful ecosystem. Something they make client pay for.
In front of ARM, one can find good technical competitors depending on the target market (MIPS, Cortus, Andes, Beyond Semi...). But MIPS ecosystem is smaller, and for the others waaaaay smaller.
RISC V has an opportunity in time to provide a good technology, backed by a strong ecosystem, for lower costs. In the embedded space at least, this is a very powerful combination.
The older OpenRISC had already found a few niches. For example, the management core in some of Allwinner's newer ARM SoCs is apparently OpenRISC, presumably because they didn't want to license another lower-end ARM core or something. Similarly, some Samsung TVs apparently use it.
For the costs, they do not only get the license to use the ISA, but the whole processor design, as in the "source code" to the whole processor. As a licensee, you place that design together with any other electronics you create (or license separately) on a chip to create the device you want.
Perhaps I'm misreading your comment, but Samsung is designing its own CPU these days. It doesn't license ARM's Cortex CPUs anymore (at least for the Galaxy S/Note series) - basically it's doing what Qualcomm and Apple are doing, too.
There are a number of things that make RISC-V different from OpenSPARC. One is that OpenSPARC is not a very scalable design, it could probably only ever work in servers and workstations, and workstations are essentially a monoculture.
Another reason is timing: manufacturing processes have effectively stopped yielding performance and power gains as the fundamental constraint (distance between components on chip) doesn't get any smaller. This means that in order to keep the pace up for any popular workload, many new microarchitectures will need to be created. RISC-V is amenable to a wide array of microarchitectural decisions, and doesn't carry the architectural baggage of ARM and MIPS licensing and technical quirks, or the impossible licensing of x86.
> But does anyone expect RISC-V to really go head-to-head with Xeon, Opteron, ThunderX, Centriq?
Except for Intel, none of these manufacturers have any reason to resist RISC-V. All of these vendors can directly port knowledge from one ISA to another. So really it becomes a matter of "will there be a demand for RISC-V hardware in the server and workstation markets?", and the answer to that is a firm "maybe".
I think that today, since most software is written in high level languages which are at least as abstract as C, there is little reason why a new ISA couldn't take hold in any of these markets if hardware vendors can promise good things to ISVs and to customers who write their own software.
At present, there is a considerable barrier to entry for new designers and manufacturers to approach ARM, POWER, and MIPS, and basically no hope of manufacturing an AMD64.
ARM is not the cuddly RISC architecture people think it is, it is in many ways nearly as quirky as x86, and therefore very expensive to enter and innovate on. Furthermore, it can take more than a year to negotiate an architectural license with ARM, your company or the market might no longer exist by the time you close the deal. POWER is not too far off on licensing, and it's not all that elegant either (though far more surmountable than ARM). MIPS lacks industry momentum and standardized high performance feature sets (wide vector compute, hardware security features), and its custodian company seems to barely acknowledge it exists.
All in all, nobody knows if it'll work out, but there are good reasons for RISC-V to succeed in the market. The challenges also seem surmountable.
> RISC-V is amenable to a wide array of microarchitectural decisions
As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space.
At this date, RISC-V has no fundamental advantage over any of these architectures and then has the fundamental disadvantage of not having access to their IP. You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work.
NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is.
AMD and Intel spend more money on research than you can even imagine, and it's not surprising that they manage to make x86 machines that lead in single-thread performance, but since Intel tried Itanium, you can tell their designers feel x86 is deficient. I mean, just imagine how much of their chips is just decode.
Also, not to get too childish, but ironically NVIDIA is one of the vendors who is shipping RISC-V in a lot of products. Soon enough, that Denver-style core is going to be sitting on a die right next to a RISC-V. ;- )
That's a good point about Nvidia adopting RISC-V. I didn't know that but for their application it's a good idea.
I'm not a Denver fan and at this point I think we can safely say Code Morphing has been tried. However, I wouldn't conclude that Denver means that ARM's instruction encoding is deficient. The optimizations that Denver provides would be impractical in any ISA.
Moreover architectures are meant to be implemented+optimized in many ways. You may not like x86 but planting that flag in the sand allowed Intel to innovate on the microarchitecture side while developers innovated on the application side knowing that x86 would still be there. It's the same value proposition that IBM offered with the original architecture, System 360.
Where I like x86 and where I don't like RISC-V is that x86 doesn't try to be perfect but rather to adapt over time. RISC-V tries to be perfect and indeed eschews many of the bad RISC ideas from the past (register windows, branch delay slots, tagged integers, ...) while then pig headedly avoiding an obvious feature shared by both x86 and ARM, condition codes. I've read their argument and found it unconvincing. Original ARM had way too much condition code support. I think ARMv8 strikes a nice balance that RISC-V should have followed.
The HP+Intel Itanium effort allowed AMD to propose their AMD64 extensions. That's been quite successful. I wish they'd taken the opportunity to trim more cruft. When ARM went 64b with ARMv8, they took that opportunity and the result is quite clean. I prefer it to RISC-V although I haven't written any RISC-V assembly.
ARMv8 tries to be a good instruction set architecture. To me, RISC-V tries to be the platonic ideal RISC ISA. I'll go with good.
Yeah, I agree that condition codes (and offset loads) are features, not bugs in x86 and ARM; also ARMv8 shows an effort to reduce the number of instructions which can respond to condition codes. Chris Celio has talked about some interesting ways to make up for the lack of these two features, and it seems quite convincing. If you're using the compressed instruction set (which all desktop/workstation type RISC-Vs and most microcontrollers support), then the decoder can implicitly fuse the add and the load, or various forms of conditions, and treat them as a single operation. AFAIK, the compiler backends already try to order the instructions to exploit this.
And yeah, I'm not utterly convinced by any argument about "purity" in ISAs, but in this case there's no question that it has helped a wider variety of people develop interesting and competitive chips in less time.
ARMv8 is a considerable step up in many ways from ARMv7 and earlier, but AArch64 retains user mode compatibility with ARMv7, which means that the more different AArch64 is, the harder it is to implement. In this way, every ARMv8 is also an ARMv7 (of course, sans all the supervisor/hypervisor instructions).
In many ways I like x86, and for the most part I like the vendors. I love that x86 has given Intel and AMD the opportunity to innovate so dramatically.
But just for a moment, imagine that instead of just Intel and AMD, the whole industry can put that same flag in the sand and have just one general purpose instruction set family.
You could have an 8088, a Cortex M0-M4, an ARC, an AVR, a PicoBlaze, a MicroBlaze, a SuperH, a MIPS, a Power, a LatticeMico, etc. but many of these architectures survive today because of a differential in licensing cost with ARM, not because of any technical prowess (and some of them are better in some ways, don't get me wrong!). Imagine that for the vast majority of these people, one ISA family would suffice, and the whole market could compete to bring new performance, power, and cost profiles to each market served by these cores. Then imagine that that same industry can easily start scaling up their designs to compete in the application processor market, and then perhaps in the workstation and server market, then perhaps the HPC market.
Just a thought though, I can't predict the future with any degree of certainty. I just think RISC-V is a whole lot more practical than you might think, just perhaps for people who have slightly different values from you (or from me, for that matter).
I think there's a lot of promise in that it is becoming the standard teaching ISA for universities throughout the United States, Canada, India, and elsewhere.
If there is a generation of new computer engineers coming out of school with research-grade FPGAs in their hands, and their thesis work can be commercialized in a matter of months rather than years, then you can imagine that there will be huge commercial output in RISC-V whether it catches on now or then.
I think that's when it will start to seem more attractive to you, there will be more investment in it and you can see some clear, immediate benefit aside from cost savings and licensing flexibility.
Based on these photos, I’d estimate instruction decoder takes about 10% of each core, and about 7% of the whole chip.
For Intel I was unable to find similar pics, but my estimation is 3-4% of the chip area. The instruction set is the same; the complexity should be comparable. But most Intel chips have like 50% of the area occupied by integrated graphics.
The micro-op cache size increased to 2048 from Intel's 1536 μops. His testing shows 5 instructions per clock cycle up from Intel's 4. There are limits to the ILP a scheduler can find; more in one area means more demand in another. This is no mean feat for AMD to pull off.
You're right, but key words here are "At this date". What you said could have been said exactly in the same way about Linux against commercial Unices about 15 years ago. It's a long game here, and we're only in the early phase. And it may not take that long, but we'll see.
Regarding technology, just as Linux initially the key is not having a technological advantage, but being cheaper and good enough. The improvements can come later, when the ecosystem gets bigger and more resources pours in.
RISC-V is thrown around like if it's an already working CPU but it is not. It is just a document describing an ISA, you can't compare it to Linux, it's a completely different thing.
There are a lot of costs in implementing an ISA and that includes: design, functional verification, physical implementation and software testing. All those steps together will require hundreds and hundreds of engineers, many expensive tools and thousands of man-hours. And once you are done, you will need to find be careful not to violate any patents while shipping your CPU to the end customer.
By paying a license fee to ARM, you get all these steps done for you plus with support.
Linux is something that you can download from kernel.org, compile overnight and get it booting right away. RISC-V is something that you need to build yourself.
When I did a presentation on RISC-V last year I counted 6 real implementations (full custom ASICs). Now granted only one or two of those you can buy, the others are research projects, but they do exist and they did produce real silicon. This year we should see a couple of 64 bit implementations, which is when it'll get really interesting.
There are of course multiple FPGA implementations (I have one about 2 feet away from me now), but they are very slow.
What kind of for free are you talking? The first commercial run RISC-V microcontroller SoC has fully-published RTL, and a company which will support you in adding it to your products (SiFive). Obviously people aren't going to give you the manufactured chips for free, but how close do you want it?
Linux didn't instantly become something you could download from kernel.org, compile overnight and get it booting right away. It took hundreds and hundreds of developers, thousands of man hours, financial investments from a large number of companies worldwide and many many years for Linux to become what it is today. All of this done while there were several existing commercial Unix variants which could have been licensed instead.
During its early years many scoffed at it as you have RISC-V. "It is a hobby OS. It will never be able to really compete with the likes of Solaris, HP-UX, and AIX. Heck, it won't even be able to compete with SCO and Unixware."
I'm not saying that RISC-V is an hobby project, I'm just saying that hardware development is nowhere comparable to software development.
You need much more support and verification while developing hardware then developing software. And while you can reuse the functional design (please note the keyword "functional"), the physical implementation needs to be redone from project to project.
ARM, Intel, AMD, Apple and Qualcomm have an army of engineers with all kinds of tools that go through all the steps of hardware design and implementation which you can't do as a side project at home using just your computer.
Linux is still a hobby OS. It's not a particularly wonderful example of software engineering. Its only real benefit is that it's free and comes with an ecosystem of other free software that kind of mostly works as long as you don't mind the occasional security horror, and can be used as-is or customised at relatively low cost.
That combination of features makes it appealing in a variety of business cases - for business reasons.
RISC-V can't be customised at relatively low cost. It's nominally free, but the freeness doesn't mean much in a business setting.
The total cost of developing a custom core remains beyond the reach of small companies.
Big companies already know there's an established ARM ecosystem with working compilers and a simple, risk-free, and relatively affordable business model.
"Linux is still a hobby OS. It's not a particularly wonderful example of software engineering. Its only real benefit is that it's free and comes with an ecosystem of other free software that kind of mostly works as long as you don't mind the occasional security horror, and can be used as-is or customised at relatively low cost."
That is complete nonsense. Linux, particularly Red Hat Enterprise Linux is as serious of a server OS as exists in the world today. Companies like IBM and Oracle would never embrace a "hobby" OS in an enterprise setting.
As for "occasional security horrors", sadly there is no OS of any flavor that is immune.
"So what business problem does RISC-V solve?"
For one thing, RISC-V offers the promise of fully open computer systems, without opaque black boxes anywhere providing potential back doors or other problems. The Intel AMT vulnerability is an excellent example of how that can go very wrong:
RISC-V also provides a playground for smaller entities (like university labs) wishing to experiment with innovative new hardware techniques like Unums. That's very valuable in its own right.
> and your advantage is that you're wearing organic cotton.
Open source hardware is not like organic cotton, it's more like having the kitchen, the tools and the ingredients to cook your own awesome meal vs going to a restaurant but never able to make any food yourself.
> does anyone expect RISC-V to really go head-to-head with Xeon, Opteron, ThunderX, Centriq?
Yes, and no. RISC-V is disruptive [1] to both ARM and x86. But before it can run (compete with Intel CPUs), it needs to crawl (compete with low-end ARM CPUs/microcontrollers). It could take a decade or more before RISC-V competes at the high-end. Basically think of it as following ARM's path but on a much more accelerated path (for many different reasons: much larger chip market these days, being open source and royalty-free, etc).
I think part of the accelerated path will be that we are reaching the limits of 'easy' (in the billions already) process improvements.
When everyone and his dog has 14nm you can't rely on process to keep you ahead, Ryzen has shown this partially recently, Broadwell level IPC on an Octacore processor for less than Intel sells a Quad core.
It's going to be a bloodbath as the middle eats into the top.
Is the intent for RISC-V to compete with modern high-end CPU designs, or do we just want to have royalty-free microprocessors for our embedded devices?
You might be surprised (at least I was) to learn that peripherals like hard drives and PCI-add-in cards usually have their own CPU executing their own software. Those processors are often MIPS/ARM/etc based and the manufacturer has to shell out to someone to be able to use that, even if they designed the processor themselves. I can see how this particular market is ripe for something like RISC-V. But does anyone expect RISC-V to really go head-to-head with Xeon, Opteron, ThunderX, Centriq?
I sound incredulous because this seems surprising to me, but I have no evidence to suggest whether it's as unlikely as I think. I've certainly seen open source software designs far superior to closed source ones, so maybe hardware design is no different?