text: Security around open source is a huge concern, he said. “With RISC-V, security becomes big, and the reason why is that people like to have an open-source piece of hardware for security so you can review it. The danger is that the bad guys can review it, too. If you don’t do enough security verification at all levels, you’ve just told the bad guys how you might be able to have some vulnerabilities there. Although some work is going on in secure embedded cores, a lot more needs to be done. We need to have a lot more formal analysis. We need to actually identify what our vulnerabilities are before hackers get to it, because with the number of cores that are out there, only a limited number of people could do this analysis. We have to focus and get that.”
  Michael Thompson, director of verification engineering at OpenHW Group, agreed. “There are problems that need to be addressed when thinking about how to deal with a processor. How do you deal with an open-source processor? How do you deal with a processor that’s readily extensible? That extensibility is built right in to the way RISC-V works. Those problems have been encountered by industry for quite a long time, and tried-and-true techniques are in place today to address those, so we have to just apply those techniques. Further, open source by its nature is collaborative, and there we need to stand on the shoulders of giants. The people in the open-source software community have worked out how large, dispersed teams can come together to get a job done. How do you get a whole bunch of different people, scattered around the world, working for different organizations, all working on the same problem? That, too, is a solved problem. That was solved by the open-source software community.”
  But not all problems have been solved. A big concern is fragmentation, which makes all of these issues more complicated. “The RISC-V Foundation carefully watches what is going on here,” said Jerry Ardizzone, vice president of worldwide sales at Codasip. “You have the base integer instructions that is carefully locked down. You’ve got the standard extension space, which is monitored closely, and there’s a very good ratification process to that. And then there’s the customizable space. So it’s up to all of us to make sure it doesn’t get too fragmented and out of control, because if it does it won’t succeed. As a supplier, as a third-party member and as a user, it’s in the best interest of all of us to make sure it doesn’t get fragmented.”
  To face this problem from the point of adoption, Emerson Hsiao, senior vice president at Andes Technology, offered an analogy. “Let’s say you’re going to buy a new car from a dealer. Does anyone ever open the hood and see what’s underneath when buying a new car? You don’t do that. Why? Because you assume the car manufacturer knows what they are doing, and if there is a problem, the car goes back to the manufacturer. But we’re talking about a different scenario here. I interpret the shift in a verification environment for open-source ISA-based IP is actually pushing the responsibility more onto the end users, which is a problem because we are expecting our users to know what to look for under the hood. Granted there will be end users who know how to verify processor IP and know where to look. But the majority of end users probably don’t know where to look or where to check, so the challenge lies in the verification for RISC-V.”
  There are roughly 100 RISC-V IP cores on the RISC-V Foundation website today. That number will grow, and Hsiao argues there should be some type of checklist for the companies building those IPs, along with a history or documentation of what has been tested and checked. That way, when an IP is used in an open source implementation, the adopter knows what kind of risk they are taking.
  “That’s the problem we’re facing right now as an IP provider,” he said. “We’re a commercial RISC-V IP provider, so we’re actually taking a very different approach. We make sure that IP is tested and verified before we ship it. But there is one problem. RISC-V has this amazing feature of custom extensions, and this is a major challenge for verification. Anyone who has done custom instructions or extensions knows the difficulty. Even identifying requirements from design to verification is a major challenge. From the IP perspective, in addition to providing a design environment for customers who design their own extensions, we also are trying to modularize to make the verification task complete.”
  Where the real frontier is now will be the integration of processors onto the SoC infrastructure in such areas cache coherency, making sure interrupts are being managed correctly, according to Dave Kelf, chief marketing officer at Breker Verification Systems. “This is going to be the kind of thing that is also going to need a lot of verification help, and it’s an area where the whole Portable Stimulus Standard is focused. It’s going to be interesting to see how RISC-V develops and platforms are based on it, but if you can imagine just the complexity of taking a new processor with an open instruction set, putting this onto a varied range of SoC platforms, and then the idea of adding instructions to it, clearly a lot of help is going to be required right through the verification process — particularly on the SoC platforms.”
  Frank Schirrmeister, senior group director for product management and system development in the System & Verification Group at Cadence, isn’t convinced the magnitude of the shift is so large. “I agree there’s a shift, there’s no question about that. There’s a shift in verification going on, especially at the SoC level, and it’s very important. The question I have is how seismic it is, because processor verification itself has been done for quite some time, both for fixed ISAs and for variable ISAs like ARC and Tensilica and so forth. The commercial vendors even have been publishing articles about how they verify these processors, and it looks very much like Portable Stimulus for IP. A lot of software-driven verification is very important.”