An animated panel discussion Design Automation Conference in June offered up a view of the state of RISC-V and open-source functional verification and a wealth of good material for a three-part blog post series.
Parts One and Two covered a range of topics from microcontroller versus more general-purpose processor versus running a full stack with an operating system and buying from a major vendor versus picking open source and adding instructions versus keeping it pristine.
In Part Three, Ron Wilson and Contributing Editor to the Ojo-Yoshida Report tidies up the discussion by asking how to determine the right questions for an IP vendor and whether the functional models are in place. Answering those questions and more were Jean-Marie Brunet, Vice President and General Manager of Hardware-Assisted Verification at Siemens; Ty Garibay, President of Condor Computing; Darren Jones, Distinguished Engineer and Solution Architect with Andes Technology; and Josh Scheid, Head of Design Verification at Ventana Microsystems.
Wilson: Is the gold standard to have asked all the right questions of the vendor. Or is the gold standard to see the RTL performing functionally correctly with the software stack?
Scheid: Designers must focus on both at different stages of the project. It needs vendor selection and what’s needed from the vendor selected. The designer will need to commit to that at some point. The amount of effort it takes to go from evaluating IP into a hardware prototyping platform where the designer can see all that working is a significant investment already.
Garibay: Designers would be happy to have a vendor selection problem with the Arm core, but they don’t. It’s a little unfair to focus on that for RISC-V. Because many of the players in the RISC-V market are relatively new, they have to establish a track record and earn user trust. Arm has been doing that for years and has done a good job. I have no problem staying to the current gold standard and what we all hope to be the challenge.
How can we compare each of the potential players in RISC-V today? It’s knowing the people, their track records, their companies and business profiles. As we move forward and IP becomes silicon, we’ll find out who the real viable players are. Go ahead, disagree.
Jones: CPU IP are complex designs, especially the higher performance ones with so many transistors dedicated to eking out that last quarter of a percent of performance. It’s difficult to verify. That’s why it still matters that at first silicon, a designer can see Linux is booting. Booting Linux is huge because Linux seems simple when turning on the computer. It comes to a prompt. But it just ran billions of instructions and probably touched 90%-plus of the system to get to that prompt.
Scheid: I agree. Designers need a greater relationship with their IP vendor and a good understanding of what has been done and what has been verified. They also need to verify even more themselves. In our space, providing solutions to assist the verification of an SoC or IP integration is good because there are greater challenges associated with it. Ultimately, they’re going to measure up to the point where they boot Linux and see what’s happening. To do this, they need to have an entire SoC where each component talks correctly to each other. That’s a huge task.
Jones: We are talking about the CPU instructions and that’s not the hardest part. When a designer is trying to verify an SoC, the hardest part is the interconnect and the buses and that’s not RISC-V versus Arm. These processors use AXI, an industry standard. That’s where the verification IP is needed. Otherwise, how does a designer find bus exercisers and monitors? It’s more about the large SoC than it is the pieces.
Wilson: Because you did your job, it can be about integration. It sounds like you agree that we’re at that stage, if licensing from an experienced, reputable vendor.
Garibay: If I look at what I expect to be the total challenge for verification of our CPU, the percentage of what is ISA-specific is maybe 10%. Yes, designers must check all the boxes, make sure all the bits are in the right place, and they flip and twiddle correctly. At that level of performance, we’re shooting for with hundreds and hundreds of instructions in flight at any one time. It doesn’t matter which ISA. Making sure that the execution is correct and that the performance is 90% of verification
I’ve done 68,000, x86, MIPS, Arm, PowerPC, a couple of proprietaries and now RISC-V. The difference is not substantial, other than the fact that the theoretical ownership of the specification lies with an external body that is a committee. That’s the main difference. Typically, the ownership has always lived with MIPS or PowerPC, Arm or x86 Duo. Yes, the difference is that the ownership is in a committee. Once the committee makes a call, the industry lives with it.
Scheid: We can contribute as well, whether it’s systemic concerns about software availability or specification extension capabilities that have multiple vendors on stage to talk about these things.
That’s the power of RISC-V. When looking at these solutions, we’re all interested in addressing concerns, making sure everyone’s communicating about what the CPU implements, what the software expects, what user software may run. Systemic risks with other solutions are put aside with the way that RISC-V is set up.
Garibay: It’s not our interests to put out a bad product. We all are cheering for each other.
Brunet: The RISC-V community and ecosystem and the market have mature chips using the RISC-V core, and everything works well. It’s a good sign.
Wilson: You mentioned earlier virtual models. The same question with best functional models. Are those in place? Are they coming?
Jones: Models of RISC-V are publicly available from Imperas. RISC-V is not immature.
Garibay: Designers can get the models. What they run on them may be a challenge.
