You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • 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.

    Research Study on Circuit Pads-risc-v-min.jpeg

    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.