Experts at the Table: The open-source ISA is gaining ground in multiple markets, but the tool suite is incomplete and the business model is uncertain.
Ed Sperling, Semiconductor Engineering
September 23, 2020
Part 2: Semiconductor Engineering sat down to discuss the business and technology landscape for RISC-V with Zdenek Prikryl, CTO of Codasip; Helena Handschuh, a Rambus Security Technologies fellow; Louie De Luna, director of marketing at Aldec; Shubhodeep Roy Choudhury, CEO of Valtrix Systems; and Bipul Talukdar, North America director of applications engineering at SmartDV. What follows are excerpt of that conversation.
SE: Who are the main competitors for RISC-V? Is it Arm or ARC or MIPS, or is it other RISC-V vendors?
Roy Choudhury: Arm is definitely one of the competitors. RISC-V is definitely getting a lot of traction in the microcontroller space, and even Arm is trying to make it easier for other companies to adopt that adopt their baseline designs. Arm and ARC are definitely competitors, especially in the IoT embedded space.
De Luna: We’re a verification tool vendor, so our competition is anybody making verification tools. Right now, the with RISC-V, the competition is open-source verification tools. But it’s still okay for use because those tools still have very far to go compared to commercial tools.
Prikryl: We co-operate within the RISC-V domain to compete against other architectures, such as Arm, ARC, and others. We discuss RISC-V specifications during the workshops or other RISC-V related events. We push the RISC-V architecture further. We try to create the best architecture that scales well, from small MCUs up to HPC and data centers, so RISC-V is the right choice if you need a CPU for any purpose. We are trying to make things better together. But then, on the customer side, we are definitely competing with each other to win deals. So you can see it as an example of co-opetition.
Talukdar: It’s too early to talk about competition yet. It’s more about interpretation of the spec, because it’s new, as well as interpretation of design intent in terms of what you’re trying to achieve. Once these things are well understood, then everybody will go kind of develop their own version. That’s when competition comes in. The main problem today is to be able to tell my customer, ‘This is proven verification IP.’
SE: Is RISC-V making inroads into markets such as automotive and mil/aero? And are things like security an issue here?
Prikryl: We have had several customer engagements in automotive market and we are working on RISC-V solutions compliant with the automotive safety standard (ISO 26262) together with our customers. The design cycles for these applications are extremely long but we will definitely see RISC-V solutions in automotive and military/aerospace markets in the future.
De Luna: I have seen some awesome presentations in the avionics. You need the full RTL source code, for example, if you want to comply with DO-254. But full DO-254 compliance is still a long way off for RISC-V. The one thing missing in the open-source cores right now is the functional requirements specification. The open-source community is very good at developing the code, but they usually develop the requirements document after. That’s a mindset that needs to change. So starting from a requirements document and defining all the functions without worrying so much about the implementation yet, the designers can create the implementation and the source code, and the verification engineers can create test cases and test code.
Handschuh: The foundation defines the instruction set architectures. The most important layer, from a security standpoint, is actually one or two levels down in the micro-architecture and implementation. And that’s where the real issues start. So at the ISO level, it’s a great first step to have to make sure this is all publicly defined and discussed, and we can add hooks for new security features and so on. But it won’t completely remove the need for having secure implementations built and also certified and verified by independent organizations. So that will all stay. And part of that is making sure that the supply chain security is maintained in some form. Those problems don’t completely go away because they’re a few levels down from the actual specifications that RISC-V International and the RISC-V Foundation have built.
Talukdar: There is definitely a road for RISC-V to get into the automotive world, and part of this has to do with the AI overlap. One of the things about RISC-V is it’s very adaptable. You can go in and work with any algorithms and twist it around and make it a very customized solution.
SE: What kinds of problems do you encounter working with RISC-V?
Roy Choudhury: The big problem we see is this is a new architecture, and there are some pieces of the puzzle that still need to be figured out. We see it from the standpoint of verification, because there are so many designs coming up. There’s no standard yet where people can say they design this like fully compliant. It’s not just ISA compliance. Design also needs to function correctly. Every design has a different micro-architecture implementation, so we really need to have a very good verification ecosystem around RISC-V just like to make sure customers can adopt and/or designs and that quality and reliable reliability is of the highest order. So we need to make sure that there’s more verification being done.
Prikryl: A couple of years back, we were questioned about the maturity of RISC-V, how big the community is, and similar topics. Meanwhile, RISC-V and the whole ecosystem has established and we don’t get these questions anymore. Nowadays, we hit issues because of missing certain ISA extensions, such as e.g. instructions for DSP processing or another missing part of the spec. But these are not significant issues for us thanks to our automatized design flow tool called Codasip Studio – adding missing instructions or microarchitecture features can be easily done in Codasip Studio. Other types of issues are that the RISC-V specifications are sometimes not precise enough and leave too much freedom for interpretation. This could lead to fragmentation, which is a bad thing. We have to be careful about it.
Talukdar: From our standpoint, RISC-V has an ISA from which you can make derivatives, and that creates a verification challenge. You derive a specific portion of the instruction set, and that’s how you build your hardware. This has to be scalable with regard to the instruction set so that developers can write at a higher level of abstraction. That’s needed to develop the hardware, and to generate derivatives. Those kind of methodologies use different languages, and experts in those languages can produce different designs. But how do you verify them? You need different verification components to verify designs, but there are a lot of different ISAs. You need instruction set simulators, and if you have a custom ISA you need custom simulators. This can be a big problem if it isn’t standardized. There isn’t much donation of open-source verification technology. Before you can use those cores and bring those cores into your development flow, you need all those components to verify what you are building. Somebody has to take leadership in building those verification components.
De Luna: Along those lines, we see big problems on the business side. The open-source business model makes it very difficult for companies to make an investment. We do see open source becoming a huge movement, and we’ve already seen that happen in the software domain. But for EDA, and particularly hardware verification tools, we’re still gauging what we’re going do with it. You need to make sure that whatever you invest is going to generate a return on that investment.
Handschuh: And from a security standpoint, security is always a system question. You have to consider how your device or how your chip, or even lower your IP fits into the rest of the system. So, of course, you have to ask yourself more questions, what are the new threat models around the new vertical you’re trying to go into. And that will change a number of things. But fortunately, you can have, you know, some basic building blocks that are always kind of the same to solve security aspects. And those ones can be built with the same type of architecture then it’s a question of performance and throughput but whether that’s going to work or not, but the basics are always the same, right? You have you need some crypto you need to cryptography algorithms implement entered and you need acceleration for that if performance is going to be or bandwidth is going to be an issue, you need to have some notion of Trusted Execution environment. So you have to need have to wait to securely boot up the system and then make sure that your applications run in a secured environment. So, how to build these things? It’s kind of always the same method. The question is for your specific vertical Do I need to accelerate things and which parts and that’s what the foundation is looking at and it’s to task groups dedicated to security, crypto and trusted execution environment.
SE: What’s still missing out of the design flow? Do all the tools work with RISC-V?
De Luna: The main thing is the lack of UVM support. UVM has become a widely adopted verification methodology for SoCs, but the open-source tools don’t have any UVM support. UVM would give you constrained random verification, functional coverage, and re-usability. It really depends on the expertise of that open-source community to provide that. I don’t think any EDA vendor will contribute a huge amount technology towards that. It’s not easy to do.
Prikryl: Let’s look at this from different angles. As a programmer, I have all I need. I can use the open-source SDK, such as GCC (GNU compiler collection) or LLVM. Simulators and debuggers are available, as well. And the same goes for the whole IDEs. Commercial software tools from multiple vendors are here, as well. From the hardware implementation and verification point of view, I usually need to go with commercial EDA tools because the open-source tools — for example those for synthesis and verification — are not there yet.
Roy Choudhury: I don’t see anything major lacking. There’s some work required in debug and the software ecosystem, but it’s coming up pretty fast.
Talukdar: We see a need for more integration testing and emulation for RISC-V designs. There are many companies that will use RISC-V because of cost, and most of them cannot afford an emulator. So the goal for them would be to do things in FPGA, but how much support we have in terms of FPGA verification for RISC-V designs?
Handschuh: The foundation is working on a broader compliance program. It’s not finished, and there’s a lot of work ahead, but people are starting to work on it. At some point, hopefully, we will get to a point where the compliance tools will be ready and where somebody can maybe pick up the task of saying, ‘Okay, let’s pass all these things through, you know, this test suite and make sure that it does comply formally, even with the specifications in a sort of proven way.’ And then perhaps it is a good question to be asking to the RISC-V foundation is whether at some point they will be able to put a stamp on things. That would help move the entire ecosystem forward, because then we all know that things are compliant, interoperable, and interface correctly.
Part 3 coming soon …
This article was originally published on Semiconductor Engineering