Improving RISC-V Processor Quality with Verification Standards and Advanced Methodologies

At the RISC-V Summit in December, there were presentations halfway between a keynote and a technical session. known as RISC-V Spotlights. These were presented to the entire group of attendees but were not blessed with the keynote title. Maybe this is like the way that when a physician in Britain becomes a surgeon, they drop the title "Dr." and go back to "Mr.". A spotlight is even better than a keynote. One spotlight was by Simon Davidmann of Imperas titled Improving RISC-V Processor Quality with Verification Standards and Advanced Verification Methodologies.

Simon and I go back a long way, ever since he was the VP of Sales for Ambit in Europe in the era when I was VP of Engineering. One of our lead customers was Ericsson in Stockholm, and I remember jointly visiting the group there at least once. Ericsson was what I thought of as a dream customer, at least partially because everyone knows who they are. They were also a dream customer in another way: their design was too big for any other synthesis tool to handle, but our BuildGates product could just synthesize the entire design. When that happens to a customer, they pretty much would just say, "please take our money," and Ericsson did. But I digress.

Simon started with a lot of numbers, such as:

• 100,000,000,000 is the number of stars in the Milky Way
• 20,000,000,000,000 is the total net worth of the world in $ (M2)
• And 1,000,000,000,000,000 is the number of verification cycles that Arm applies to one core

Even though RISC-V processors are relatively new, companies selling them have to contend with the fact that users expect the core quality to be the same as Arm. But the RISC-V companies don't operate at the same scale as Arm, so each core developer will not have the resources needed to be able to perform the same level of verification as Arm.

Simon considers this to be the RISC-V disconnect (he even has a logo! See the start of this post).

So the big question is:

How can we scale in-depth proprietary processor verification experience, tools, and methodology across the RISC-V community?

Simon considers this to be a sort of missing link. Of course, RISC-V needs and ISA and a focused team for its development. Yes, RISC-V needs software and its ecosystems and partnerships. But if the devices don't work as needed, then there is nothing. If the cores/processors are not as expected, the systems fail.

So, alongside ISA and SW, the community has a third big challenge, namely verification. And this doesn't even bring you differentiation (although a working processor is certainly differentiated from one that does not).

Brute force won't get you there since we are talking about thousands of SystemVerilog Simulators running for a year, or a single hardware emulator running for 30 years.

Imperas

I don't want this to come across too much as a commercial for Imjperas, but they have been working for over four years assisting customers with their DV needs, and in 2018, many RISC-V developers started using Imperas as a reference for their hardware verification. If it passes Imperas, it is good.

During those four years, they have learned that there are many methodologies for the 'verification' of new processors. That table only covers dynamic verification, formal techniques are great (and Cadence's Jasper platform is the greatest), but that is outside the scope of Simon's presentation.

Another challenge is that verifying a core depends somewhat on the specific core, somewhat on industry standards (don't reinvent the wheel), and some are standard for all RISC-V implementations (just dependent on the ISA). Part of the "trick" is to develop all this without having to handcraft everything for each core, for each team, and for each company. So we need an environment that is configurable, without (too many() source edits, and that has been developed to be re-used.

RVVI

RVVI is the RISC-V Verification Interface. It is an open standard (RVVI on GitHub). It allows the re-use of test bench VIP components. It allows the re-use of configured reference models. And it allows the use of external components, such as for functional coverage. It just requires what I am used to calling a "gasket", a specific core tracer to interface the core being tested to RVVI. See the image above.

Another interesting open project is the OpenHW Functional Coverage Requirements Project, RISCVISACOV (RISCVISACOV on Github). This is, to me, quite ambitious. Starting from a machine-readable definition of the RISC-V ISA, it uses a reconfigurable generator to create SystemVerilog source.

Summary

Simon wrapped up with a summary of his message:

• RISC-V processors need to be high quality
• High quality means lots of verification resources
• High quality means advanced verification methodologies
• Efficiency needs standards and re-use

The conclusion of conclusions:

RISC-V ecosystem needs to invest in a verification ecosystem to complement the ISA and SW ecosystems

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.