RISC-V Shanghai 二

This is my second (二 in Chinese) post about the 6th RISC-V workshop held in early May.

I covered the panel sessions and my overview of the state of the nation of RISC-V in RISC-V 6th Workshop. Today's post covers some of the other presentations. There was way more in three days than I can easily summarize in a few blog posts, so if you really want to dig into the details, you can (or will be able to) find the slides and videos of the presentations on the RISC-V website.

Andes

The first day of the workshop proper opened with Charlie Su of Andes Technology. If you haven't heard of them, then you don't live in Taiwan. Before I joined Cadence, they were one of the subscribers to Semiwiki that I covered, and so I have written about their product line and know them well. They are a Taiwanese company that has its own line of microprocessors. Their licensees, who mostly are also in Taiwan and China, shipped 450M chips containing their cores, which I believe is only slightly less than MIPS. They have new cores that are based on RISC-V. Charlie was asked how long it had taken to switch instruction sets: "weeks, months, years?". Months, it seems, and most of the effort was not the processor core itself, but the software tools (such as compilers) that needed to be extensively updated. One outcome of that is that Andes is the second most active contributor to the gcc toolchain projects.

Privileged ISA

Andrew Waterman, who is one of the original creators of RISC-V, works at SiFive, and is chair of the privileged ISA spec task group, gave an update on the privileged architecture. Only the non-privileged "user" instruction set architecture has been frozen. However, the privileged architecture is "more or less stable". The current version keeps compatibility with the previous in machine-mode, and any future releases should be compatible with this one except in the hypervisor area, which hasn't been fully defined yet.

The RISC-V architecture has three privilege levels, user (U-mode), supervisor (S-mode), and machine (M-mode) modes. You can build processors that support the following combinations:

• M (only) for simple embedded systems that run trusted application code with no memory protection (beyond trapping non-existent memory addresses); very low cost to implement
• M and U for embedded systems with memory protection
• M, S, and U for systems running paged virtual memory operating systems such as Linux or Windows

NVIDIA Keynote

The first day's keynote was by Frans Sijstermans of NVIDIA about why and how they had selected RISC-V as the replacement architecture for their proprietary embedded microcontroller that is the control engine for their video engines, called Falcon (FAst Logic CONtroller). He said, based on public data, they have shipped about 3B of them. He emphasized that this was never a toy project; if it went wrong they would be in trouble since every chip NVIDIA sells has at least one Falcon on it.

The main reason to replace Falcon was that the software just started setting up a few registers and had gradually got more complex. Now the software teams wanted to run third-party software, such as security stacks. And the lack of 64-bit was a problem.

Eventually, someone told him about RISC-V and he decided to look at it. He looked at RISC-V Rocket (written in Chisel "that we don’t like since it doesn’t fit in our flows"). RISC-V would also give them scalability to do things like very small designs where they would have said "Falcon is too big" and high-end big CPUs where they wouldn't even consider Falcon but RISC-V would at least be an option.

One thing he was asked is whether using RISC-V and contributing to the ecosystem would be enabling their competition. He is Dutch, and they have a "polder" model for maintaining all the dikes and ditches that keep the land from flooding (much of the Netherlands is below sea level). Even when villages were at war, they would have to cooperate to maintain the drainage. RISC-V means that their work can be used by their competitors (not so good) but that they can influence the direction (good). So they decided to chair the memory model WG and the security WG.

The first tapeout will be the end of this year, with production next year. It happens to be a discrete GPU but that is basically coincidence, since it will go in every product. That is just the first.

SiFive

SiFive announced their semiconductor products last year. The new announcement was around IP, basically the IP that is in their semiconductor products is now available for use in other designs. It is not completely free (it is royalty free). Jack said that this side of the business came from people who looked at the Berkeley Rocket project, which is available to anyone, and said "I want a commercial license."

SiFive are trying to change the way IP is sold, making it easy to play with and evaluate. He pointed out that the current IP industry makes it very hard to get information, even harder to get RTL before purchasing, and then negotiations take 6-12 months and end up with a 100+ page license agreement. On the other hand, if you want terabytes of storage and thousands of servers, you just go to Amazon and order them. Their goal is that IP should be like that. If companies are designing cellphones in Shenzhen in 21 days, then IP can't take 10 times as long to license.

The Coreplex IP model has three steps:

1. Study: It's all on the website. Free. No NDA. No registration.
2. Evaluate: Sign an online license agreement, download the FPGA bitstream, download the RTL if you want, development environment.
3. Buy: Configure online, transparent pricing, 7-page license agreement.

Lots of people took photos of the three-step process. "You guys taking photos are missing the point. All this information is on the website." So if you want to find out more, you know where to go.

Oolong

Cecil Accetti of SJTU (our hosts) described a RISC-V project that he had done at Centro de Tecnologias Estrategicas do Nordeste in Brazil. They were doing embedded SoC design for third-party companies but still needed a processor to glue it all together. So they decided to design their own CPU core. The first motivation was economic, that it had to fit into a really small FPGA so that the client could sell it, and the second motivation was that they would own it (so NIOS, ARM, etc. were out, they were leaning toward openRisc). A third reason is that Cecil really wanted to try and do it.

In 2014, he saw an article in EE Times on RISC-V, and it looked attractive, so they decided to do an implementation starting from just the PDF of the ISA. Using just the PDF meant that he had:

• Complete freedom
• Incremental development, most important instructions first
• Fit the target device

On the other hand, they still needed a bus and peripherals. But they designed the system, complete with GPIO/UART, SPI, I2C, DACs, and ADCs. They used a wishbone bus and a simple driver. It ran at up to 1.36 DMIPS/MHz.

As if that wasn't enough, since they were doing signal processing for wireless modems, they added a complex number extension, representing complex numbers as 16 imaginary bits and 16 real bits, along with all the instructions for complex arithmetic. There were two gains, smaller code size and they ended up with a 20% faster modem, which meant that it could run on the FPGA.

In the Q&A, he was asked how many people were on the team. "Just me and a software guy. It took about 18 months." Impressive.

RISC-V Memory Consistency Model

It is possible that you have heard that there were some issues in the RISC-V memory consistency model. They even put out a press release. A memory consistency model defines the values that can legally be returned by memory loads. The strong approach is called serialization: all the threads are interleaved into a single "thread" and each load returns the result of the most recent store. That would make things really simple for the software people but is impossible to implement without sacrificing too much efficiency. For a start, cores cannot reorder instructions.

Dan Lustig from NVIDIA, chair of the memory consistency model task group reassured everyone that they caught the spec bugs well before they will affect any implementation in practice, and in some ways is an example of why it is so great to have an open-source ISA with lots of people checking each other's work. Changes to memory models like this are apparently not that rare. ARM just changed theirs, for example.

If you are a "normal" programmer writing in a high-level language, then none of this stuff affects you. If you are designing hardware, the model determines how far you go in making everything fast by letting different parts of the system get run ahead.

Summary of the Workshop

Most of my thoughts were in the first post on what seems to be the future of RISC-V outside of academia, where it looks like it is getting to be the only game in town. The only other obvious choices, ARM and x86, are too complex and too legally encumbered for academic use.

SiFive trying to sell IP using Amazon's model for web services will be interesting to watch, mostly for reasons nothing to do with RISC-V. IP (and EDA tools) are not something where you can find all the most in-depth details on the website, and you certainly won't find the price list. Enterprise software has always been sold like this, but maybe one day it won't be. If you wanted a few hundred servers, it used to be a major undertaking, not just filling in a form on AWS's website.

The next RISC-V workshop will be held at Western Digital's SanDisk facility in Milpitas on November 28-30 (week after Thanksgiving as always). As always, for all things RISC-V, go to the foundation's website.