Imperas and RISC-V

I met Imperas at TechCon this year because I wanted to become a bit more knowledgeable about virtual modeling. That led me to become more interested in RISC-V and a talk given by Krste Asanovic of UCB and SiFive. My takeaway surprised me. I had thought this was an open-source David versus proprietary Goliaths (Intel and ARM) battle in the world of processors/controllers (or more exactly the instruction set architectures – ISAs – underlying those systems). With of course everyone rooting for the plucky newcomer.

I’m sure that remains an aspiration, but I took from Krste’s talk that RISC-V can still be very successful even if the Goliaths hold onto their primary roles. He talked about SoCs with 15-16 ISAs, from the core CPU (usually ARM) to graphics, image processing, radio and audio DSPs, power management, security management, etc, etc. Standard MCU solutions are likely to be sub-optimal for some of these functions, and custom solutions must seem compelling for IP vendors and in-house developers who need an embedded controller. Standardizing the ISA for some of these functions seems like a natural win given potential for healthy competition and hopefully a robust software ecosystem growing around the standard.

I’m not so sure about the DSP examples as a target; radio performance depends on some pretty carefully-crafted architecture support in the more demanding wireless standards. Doesn’t seem like a good fit for a general-purpose ISA, but maybe that’s just my lack of understanding. RISC-V allows you to tune the ISA, which might overcome objections of this kind. In fact this appears to be one of the real attractions in the standard.

But that raises a question – how much can you change before you become non-compliant? Change enough and what you are using is just a convenient starting point on your way to yet another proprietary ISA. So as you’re refining your architecture against your (hopefully) extensive software regression suites, you will want to assess performance and power, among other metrics, when making decision on ISA optimization. But you also want to know that you are staying inside the boundaries of RISC-V compliance. How do you do any of that when you don’t yet have even a hardware simulation model?

The answer is that you use an instruction set simulator (ISS) reflecting the RISC-V ISA, adapted with whatever changes you want to make. Unlike hardware simulators, these things can run at near real-time speed, so it is possible to run those extensive regression suites and compare and contrast performance, power etc between different ISA tweaks. Since the ISA is free, why would you want to pay for this simulator? You don’t have to. In the spirit of the standard, Imperas provides a free ISS for RISC-V; notably this is used by the RISC-V Foundation’s compliance working group in their compliance testing, a feather in Imperas’ cap.

Naturally Imperas offers a number of (presumably charged) options. After all they have to make money somewhere. This model isn’t noticeably different from RedHat or many “freemium” business models. So more power to them.

I talked with Kevin McDermott (VP Marketing at Imperas) while at TechCon to get a bit more insight into his view on the role of virtual prototyping in system design. He acknowledges they didn’t invent this concept but believes they offer a differentiated solution over similar products First, they focus exclusively on virtual prototyping and are not trying to extend down into implementation. Where connection to implementation is important, they partner with companies like Cadence to do hybrid prototyping. Imperas models the CPU/cluster part of an SoC running a software stack and the rest of the SoC runs on Palladium. This allows for software performance, communicating with hardware accuracy where needed.

Second they have an open approach to models. Generic models for many processors, platforms and peripherals are already available under OVP and you are free to adapt these to match what you intend to use/build. The Imperas ISS generated for your system based on these models can then be used for driver development, OS and hypervisor integration and application-level software development, allowing all of this to start before you’ve written your first line of RTL.

Another interesting capability Imperas support is safety analysis with fault injection. In this forum, we’re used to ISO 26262 safety analysis in the hardware domain. ISO 26262 safety analysis is just as important in software and requires, unsurprisingly, fault injection in the software. The Imperas solution has been adopted for safety coverage analysis in aspects of Audi design, which tells me this has to be competitive.