RISC-V Evolves from Academic Teaching Platform into a Major Microprocessor Player

by Steven Leibson

“Don’t look back. Something might be gaining on you.” – Satchell Paige

Last week’s RISC-V Tech Symposium, held at the Computer History Museum in Mountain View, had all of the spirit of a tent revival meeting, which is appropriate because microprocessor ISA supporters tend to sound a lot like religious zealots. The open-source RISC-V ISA is no different in this respect. Although begun for the most grounded of purposes – the education of future processor designers – the RISC-V ISA is rapidly growing far beyond its origins and is bumping along the road to become a full-blown, commercial microprocessor ISA despite its open-source underpinnings. The underwriter of the worldwide series of RISC-V Tech Symposiums, SiFive, is one of the loudest cheerleaders for the RISC-V ISA’s trek towards commercial relevance and, perhaps, world dominance.

My July 19, 2018 EEJournal article titled “RISC-V Aims for World Domination” contains a long history of microprocessor ISAs. In this article, I quoted Dr. David Patterson, the professorial godfather of RISC-V, who said: “Why should there be open-source compilers but not open-source ISAs?” That article quoted Patterson as he discussed the idea that the open RISC-V ISA could be a cure to microprocessor ISAs’ hacking vulnerability. The quote came from a presentation Patterson made at the 2018 annual dinner meeting of the IEEE-CNSV (IEEE Consultants’ Network of Silicon Valley). Patterson concluded that presentation with a simple statement about RISC-V: “That’s my simple goal for RISC-V: world domination.”

Fast forward half a year to this month’s RISC-V Tech Symposium at the Computer History Museum. Several hundred people attended, and they didn’t come just for the bagels and fruit. They came to hear about the new ISA religion. Although they got plenty of that sort of verbiage from the SiFive presenters at the symposium, who promised the world including a solution to the slowing of Moore’s Law, attendees got a more sober and rational look at the state of RISC-V from Martin Fink, who was giving his first presentation as Interim CEO of the RISC-V Foundation. Fink is also the CTO at Western Digital (WD), a position he’s held for just over two years.

As a reminder, WD announced late last year that it was developing a RISC-V processor core (not an ISA, an IP core) called SweRV, which the company is putting into the open-source community. In addition, WD has developed an open-source, RISC-V instruction-set simulator for the SweRV processor core, and the company has initiated an open standard initiative for cache-coherent memory over a network to be used in RISC-V environments. WD is serious about RISC-V. The company’s press announcement about the processor core states, “Western Digital expects both the SweRV Core and SweRV ISS will help to accelerate the industry’s move to an open source instruction set architecture.”

In other words, WD has bought into the open-source RISC-V movement bigly, which should not come as a surprise. WD ships on the order of a billion processor cores per year in its storage products, so an open-source core implementation that WD manages and pays no royalties to use has got to be attractive.

During his keynote at the RISC-V Tech Symposium, Fink recounted a story about the first time he met Marc Andreesen. This was when Fink was a VP running a “small business unit” at HP. It was the Business Critical Systems group in Fort Collins, Colorado – my old HP stomping grounds – which was responsible for HP’s Integrity servers at the time. Andreesen had just joined HP’s Board of Directors. His “tag line” was “Software is eating the world.” This tag line “irked the heck out of” Fink, because he considered HP to be a $100 billion hardware company, no doubt because he was in charge of HP’s Integrity server line at the time.

Now that he’s the [Interim] CEO of the RISC-V foundation, Fink has revised Andreesen’s tag line for his own use. He proposed the following version:

“Silicon: The oxygen that allows software to breathe”

So it’s not all about the software, says Fink. It’s about the symbiotic relationship between hardware and software. Maybe this is a transcendental revelation to some people, but it seems to me that British computer scientist Maurice Wilkes had the same vision in the late 1940s while he and his team were developing the EDSAC and EDVAC programmable computers. Hardware/software co-development is actually a very old concept in computing. Wilkes and company certainly understood the symbiosis between hardware and software back then, although silicon had nothing to do with computing at the time. It was still the tube era.

In any case, Fink sees the RISC-V movement as a way to get back to the Wilkes’ model of optimizing hardware and software together. According to Fink, putting the RISC-V ISA into the hands of the open source community and modularizing the ISA unlocks the processor architecture and encourages more innovation.

Further, Fink sees the RISC-V movement as a step away from the polarized world of hardware and software today, as if the processor designers at Intel were ignoring the massive overhang of existing code. (OK, they did exactly that when it came to Itanium, see “News Flash: Itanic Still Sinking” and “Itanium Deathwatch Finally Over,” but, in general, processor designers pay a lot of attention to how well software runs on their machines.) Instead, Fink says, the RISC-V open-source movement is more of a win-win situation, where hardware and software both win.

Fink also said that there are farsighted development teams that are optimizing hardware and software together. “That’s why you’re seeing things like [Google’s] TPU chip,” he added. Google, which has money to burn, decided that it needed to build a proprietary AI chip specifically for machine learning. Google’s TPU version 3.0 consumes so much power that it needs water cooling.

My own take on Google’s TPU is that no commercial processor vendor is likely to stick 65,000 multipliers into a multiprocessor chip aimed at the general market. Few companies besides Google and governments have that much money to throw at a specific application problem, and not many can afford water cooling for their system designs, so I’m not convinced that Google’s TPU represents a good example of co-optimizing hardware and software in the real world where most of us live.

My eight years of experience at Tensilica, where I evangelized proprietary configurable processor cores, taught me that few engineering teams are looking to blaze a new path on the ISA landscape. That’s one more degree of freedom that they don’t have time to deal with, and most of them don’t feel the need to fiddle with ISAs. That’s not the perceived bottleneck, and not every company has the deep pockets and resources of a Google (or a WD for that matter).

Let’s get real, here. This concept of universal hardware/software optimization might sound nice, but there are some bedrock, practical, economic limitations being glossed over in the RISC-V zealotry and hype. Fortunately, that’s as religious as Fink got about RISC-V.

His keynote became more practical and realistic.

“Why RISC-V?” asked Fink. Current ISAs are decades old, he said, and “there are points in time where you need to make architectural leaps forward.” The slowing of Moore’s Law means that physics is not going to take us forward as fast as it once did. Instead, we will rely more on architectural advances coupled with software innovation.

OK, well that’s nice. I agree that the relentless journey along the Moore’s Law path has put architectural innovation on the back burner where it doesn’t belong. It’s good to look to system architecture for the next performance leaps, but the RISC-V ISA is not a revolutionary step beyond other RISC ISAs, despite the supposed decrepitude of those “decades-old” architectures.

From my perspective, the significant RISC-V contribution to our industry is the open-source nature of the ISA. Ecosystem vendors can pick up many IP and silicon vendors by joining the RISC-V team. Of course, they also pick up a huge set of vendors by jumping on the Arm Cortex teams, so I don’t see that as a significant differentiating factor for RISC-V – not from my vantage point. In addition, Wave Computing, the newest owner of poor old MIPS, recently announced that it would release the MIPS processor ISA to the open-source community through a program called MIPS Open. I certainly think you can give partial credit to the RISC-V movement for this turn of events.

Fink, a “server guy” at heart, then burst a few bubbles among the RISC-V zealots by saying:

“If your ambition is to replace a Xeon processor with a RISC-V processor in a server, just stop right there. That should not be your ambition. That should not be what you want to go after. There’s no point. You’re not going to get anywhere doing that.”

“But you can rethink the architecture of a server,” he continued. “How much main memory should there be in a server? How much storage is enabled? What kinds of silicon customizations can you make to optimize portions of the workload? Where are the hardware/software tradeoffs? That’s when you get to the magic and the power of what RISC-V can bring.”

Again, I strongly agree with Fink’s system-level optimization sentiments, but I’m failing to see the special nature of the modular RISC-V ISA that can break the bottleneck that’s been holding designers back from the flowering of processor-based ASIC design. My experiences at Tensilica and Cadence tell me that the processor ISA is not the major bottleneck. The real limiting factors are getting the development money, the engineering resources, the design and verification tools, and the development time needed to create an ASIC. Pick any processor core, make it free, and you’ll still find a ton of obstacles in the ASIC-development path. Even after attending the RISC-V Symposium, I fail to see how the open-source RISC-V bandwagon fundamentally changes the equation.

Fink continued: “Rethink the problem from the ground up. Don’t [design a system in] a certain way because that’s how it’s been done for the past 10, 20, 30, 40 years.” (We’re within two and a half years of the microprocessor’s 50th birthday, so soon you can soon add another decade to Fink’s list.) “If you’re going to design your system with a new ISA but a crusty old system architecture, your success will be limited, if you succeed at all,” he said.

Finally getting down to brass tacks, Fink enumerated his view of the RISC-V advantages:

It’s a modular ISA. The instruction set modules (integer, floating-point math, compressed instructions, vector instructions, etc.) are stable and locked in after ratification, which provides fixed targets for ecosystem developers. These locked-in instruction modules provide developers with a stable baseline. Next year’s RISC-V processor models will provide the same ISA, and any changes will be confined to new modules proposed by others or to proprietary modules that you develop yourself. That last bit is very Tensilica-like, and, as I’ve said above, the concept was not a big seller. However, I do strongly believe that ISA modularity is a “good thing” in the ASIC design sphere.

Using WD as an example, Fink reminded the audience that WD is making the SweRV RISC-V IP core available to the open-source community. However, WD intends to develop proprietary ISA modules with some number of specialized, custom instructions for specific storage applications. WD does not plan to share these specialized instructions with the open-source community. This approach allows WD to leverage the growing ecosystem for the standardized RISC-V platform while still allowing it to develop and leverage customized processors for a competitive edge.

The freedom to take this route sounds very nice in theory, but, as Fink said, WD will then need to manage the development-tool chain for these specialized processors, because they will have deviated from the standard ISA modules that the overall RISC-V ecosystem supports. From experience, I know that small development teams would love to develop specialized ASICs with architectures tailored to specific applications, but many of these companies not big enough to shoulder the burden of managing customized tool chains.

Again referencing my days as a Tensilica evangelist and channeling my inner Yogi Berra, the RISC-V bandwagon is like déjà vu all over again.