“Learning is not compulsory… neither is survival.” – W. Edwards Deming
New microprocessor designs often emerge from universities. But how often do processors go back into universities?
It’s a new decade, so a new processor is in fashion. Like hemlines and boy bands, processors rise and fall in popularity. There was the RISC Age. Then the VLIW Era. The Decade of DSPs. Now, it’s all RISC-V.
There are plenty of reasons for RISC-V’s popularity, but here’s one I hadn’t expected: It’s not ARM. Or x86. Or even MIPS, SPARC, 8051, Clipper, PowerPC, or PDP/11. Among a certain class of customers, RISC-V is the processor of choice almost by default.
Why? Because nobody owns it.
This little nugget of wisdom popped up several times over the past year as I’ve interviewed chip makers, software companies, researchers, VCs, startups, and various and sundry members of the tech-curious industry.
“Why did you choose RISC-V?”
“Because our research funding required it.”
“Huh? Your financial backers said you had to use RISC-V? That’s unusual.”
“No, because they said we can’t use a licensed CPU. That left RISC-V, by default.”
Some version of this conversation happens almost every time a startup is cooperating with a university, especially a European university. The university is happy to collaborate with industry insiders, and they have the grants, the research, and the talent pool to contribute. But there’s a catch. Their participation must be entanglement-free. No proprietary technology and no licensing fees.
The “proprietary” part leaves out x86 processors, and the “licensing” prohibition eliminates ARM, MIPS, and the other, uh, licensed CPU architectures. That leaves the field pretty much open to RISC-V, today’s predominant open-source processor design. Thus, startups and universities are increasingly basing their work on RISC-V because they have few legal alternatives.
I’m sure the more ardent RISC-V aficionados will jump in here to say it’s also because RISC-V is so flexible, extensible, powerful, modern, caring, good-looking, etc. But that’s not the case – at least, not with the companies and groups I’ve spoken with. They agree that RISC-V is adequate to their task – they have nothing against it – but that the choice came down to politics and lawyers, not technology, engineering, or performance. They use RISC-V simply because they have to.
GreenWaves and its GAP8 and GAP9 processors are one example of this. The company collaborates with the University of Bologna in Italy. The chip startup gets significant help from students and faculty at UniBo, but such cooperation requires “non-proprietary architectures,” according to CEO Martin Croome. And that, in turn, helped drive the decision to base GreenWaves’s GAP8 and GAP9 processors on RISC-V.
Same goes for Tachyum, but in a different way. Its ambitious Prodigy processor can execute several different processors’ instruction sets through emulation, including x86, ARM, and RISC-V. Why RISC-V? Legalities and licensing clearly weren’t deal-breakers, or else x86 and ARM wouldn’t be on the menu. But CEO Rado Danilak says some of his prospective customers are universities, and “academic contracts require RISC-V and prohibit x86. So, we did a RISC-V translator.”
The underlying rationale for these restrictions lies buried in contracts and funding records, but there are several potential reasons. For one, publicly funded institutions don’t want their research money spent on projects that lock them into a specific product. They may also be hesitant to funnel public money in a way that benefits a commercial for-profit entity. They may fear running afoul of licensing or patent laws, especially since such laws differ from place to place and product to product. Modifying or reverse-engineering a microprocessor is legally tricky, even if it’s just for experimentation purposes. And if you did wind up discovering or developing something from it, what then? You want to make sure your work will be unencumbered before you start, not discover the ugly truth afterwards.
A processor’s fortune and fame can rise and fall for a lot of random reasons. It’s rarely because it’s the best technical solution for a given task. Sometimes good software support helps sell CPU chips. Sometimes one big customer anoints a winner and others follow suit. Sometimes it’s an unusual business model, or pricing strategy, or just dumb luck. Like any form of evolution, unexpected outside factors can cull the herd and leave the survivors wondering, however appreciatively, what stroke of luck has left them standing. If it comes down to university guidelines or the funding stipulations in some benefactor’s will, so be it. May the hardiest processor win.
It’s simply not true that there are no legal alternatives to RISC-V if your sponsors require you to use an “entanglement-free” instruction set. There are a number of other choices, including OpenRISC, SPARCv8 (fairly widely used in Europe in the form of the LEON core), SuperH (including SH4 now). Proponents claim that POWER is now “more open than RISC-V” although I was unable to immediately find any implementations on github.
I’d contend that research projects are actively choosing RISC-V over these alternatives for reasons ranging from technical (various combinations of too complex, too low performance, no room to add new custom instructions, 32 bit-only) to RISC-V’s rapidly growing software ecosystem and pool of people experienced with it.
Of course there are other open-source and/or free choices. Always have been. But today, RISC-V seems to be the default choice among those alternatives, for all the reasons you and I enumerated.
Jim: there seems to be a misunderstanding about OpenPOWER, here. the OpenPOWER initiative was started internally and quietly many years ago (almost a decade), however to ensure that things were done correctly (not least because IBM is involved and has huge responsibilities to its Supercomputing customers), it just took a very long time. So long in fact that ironically the RISC-V initiative appeared to be first!
Thanks in part to that, with RISC-V announcing its existence before OpenPOWER, the “limelight” has fallen on RISC-V, yet there are areas where the lack of proper thought, consideration, review, and rejection of constructive feedback has led to conflict and mistakes in the establishment and ongoing running of RISC-V. The patent indemnification is not properly adequate, for example. This is an area where IBM’s two decades of experience and access to excellent lawyers shows through: OpenPOWER implementors gain the backing of IBM’s absolutely massive patent portfolio, and the EULA is properly designed to reflect that.
Another critical area – where Bruce does not have the correct information and has given you (and readers) an incorrect perspective – is that the OpenPOWER Foundation permits anyone to present Extensions to the ISA, even without having to join the Foundation. Eighteen months of reasonable in-good-faith and publicly documented enquiries to the RISC-V Foundation as to how to go about the same process were completely ignored, in direct violation of the responsibilities of a Trademark Holder, which is extremely serious.
Now, it turns out that “outsiders” (non-OPF Members) will not be able to participate in the review process by the OpenPOWER ISA Working Group (they will not be invited to the meeting), however at least they can submit the Extension. By contrast: RISC-V directly prevents and prohibits Extensions from being submitted without also joining the RISC-V Foundation.
This may not seem like it is a big deal, but it is actually a serious problem for certain classes of Business. Imagine that there is a Business which has, as its fundamental Business Objectives, a promise to its customers to engage in “Full Transparency”. This is absolutely critical for example in crytpo-currencies, where full audit and review of all source code and mathematics is essential and de-facto the norm.
With the processes and procedures and much more being entirely closed and secretive, to join the RISC-V Foundation just to submit Extensions would risk such a business being also accused of engaging in secrecy, fundamentally undermining the trust of its customers even before it has released a product. This is a serious conflict of interest!
By contrast although it is proceeding slowly, the OpenPOWER Foundation is listening to constructive feedback, and accepting the responsibility of engaging with outsiders with different perspectives and experience.
In other words, OpenPOWER is more inclusive of people from diverse backgrounds.
Combined with the existing stability of the OpenPOWER ecosystem, thanks to the pedigree and experience of its decades-long members including IBM, this is an extremely powerful combination.
Nice of you to give me a promotion Jim but I’m VP Marketing not CEO! And it’s worth mentioning that we collaborate with both UniBo and ETH Zurich. An open source ISA is essential though. Both from a licensing and technical flexibility standpoint.