Verification, RISC-V and Extensibility

RISC-V is obviously making progress. Independent of licensee signups and new technical offerings, the simple fact that Arm is responding – in fundamental changes to their licensing model and in allowing custom user extensions to the instruction set – is proof enough that they see a real competitive threat from RISC-V.

Which all sounds great, but there’s a problem – verification. Dave Kelf of Breker gave me some interesting perspectives on this. In verification of the CPU itself, Arm has decades of experience and rich ecosystem support in this area. This all works very well when the CPU IP can’t be changed. The development team build up giant regression suites which they can use to verify complete compliance with compilers, and backward compatibility and all those other requirements.

But when you have a core allowing for instruction extensions, the core vendor can confidently verify the core as they ship it, but how does the ultimate product user verify the core with their extensions? You can’t just assume that the extensions have zero interaction with the behavior of the unmodified core. You really need to re-verify everything, including all the stuff you didn’t mess with.

This is apparently a problem all the extensible core vendors run into. They can’t ship their massive regression suites to their customer. Instead they typically reverify customer cores with extensions, in-house, a service which apparently they are expected to perform at no cost.

As a part-solution to this problem, the RISC-V group has put a lot of effort into testing compliance between independent implementations of the CPU to encourage cross-compatibility and a healthy ecosystem. Test suites are available from Imperas, Codasip, Google and many others.

As an aside, I wonder how well behavior can be bounded around custom extensions to the instruction set? Timing certainly, with stalls to the pipeline if an instruction doesn’t complete within a cycle. That seems like a necessary but insufficient and compromise condition. How will a stall affect other operations? How will the instruction interoperate with caching and other complications? Proving that a custom extension cannot disturb the correct operation of the rest of the system, or vice-versa, sounds like a hard verification problem. Maybe that’s just me.

Back to Dave, he sounded pretty confident that between the compliance standard groups and companies building compliance solutions, they’d figure out ways to ensure strong compliance in CPU implementations. But what they aren’t working on (as far as he knows) is system compliance – the interoperation of a CPU (or CPUs) with all the surrounding infrastructure: bus fabrics, caches and coherent fabrics, interrupt management, memory management, etc, etc.

Arm have put a lot of work, through their ecosystem, into verifying this kind of infrastructure. If an SoC product team switches from Arm to RISC-and loses this support, they are really going to struggle in verifying their SoCs. Breker had already developed an app on their Trek platform support of verifying integrations around the ARMv8 platform, so it was natural to spin a comparable solution for RISC-V.

The Breker team started with the ARMv8 tests, including cache coherency and interrupt testing, and added tests they thought might be necessary for RISC-V. They found some early customers who were sufficiently interested to run evals. Then SiFive approached them, maybe referred by one of those eval clients. SiFive were also running into the problem I mentioned earlier, needing to re-regress customer modifications against the internal SiFive regression suite.

SiFive also wanted a method to test their own internal processes. They saw the Trek RISC-V app as a way to do that, an independent audit of their quality. They helped Breker add more standardized tests, including a bunch of load/store-type operations according to Dave. SiFive were sufficiently impressed with the ultimate app that they have become one of the biggest customers for this product. That’s an impressive endorsement given SiFive’s leading role in RISC-V cores.

Breker released the RISC-V app a couple of months ago and Dave tells me they’re getting a ton of interest from customers. He says for him it’s really clear a lot of design teams are having this integration problem. They build their SiFive core, integrate it into their SoC and the system falls over. Without the Arm debug ecosystem, they need an alternative. They are evidently seeing a lot of promise in the Breker Trek RISC-V app.

You can learn more about the Trek RISC-V app HERE.

Also Read

Build More and Better Tests Faster

Taking the Pain out of UVM

WEBINAR: Eliminating Hybrid Verification Barriers Through Test Suite Synthesis