In designing a system for many products today, power consumption, performance and die area constrain a lot of the complex artificial (AI) and machine learning (ML) SoC requirements.
Extending the open-source RISC-V instruction set architecture (ISA) is often overlooked as an effective means to address these constraints. A recent webinar panel led by Quantum Leap Solutions, a design services company for the semiconductor industry, attempted to help take the mystery out of extending the RISC-V ISA for SoC designs. The webinar entitled “RISC-V Flexibility – The Power of Custom Extensions,” fielded questions from over 100 attendees.
The panelists attempted to deliver insight into the role of the modified ISA in designing for emerging applications and how designers view extensions to the novel RISC-V instruction set architecture.
Moderated by Mike Ingster, founder and president of Quantum Leap Solutions, the panelists were:
John Min, director of FAE at Andes Technology
Larry Lapides, vice president of sales at Imperas Software
Taek Nam, senior application engineer at Mentor
Mike Ingster: Why is RISC-V a better option for AI and ML learning applications than other CPU architectures?
John Min: The time in which RISC-V was invented coincided with AI becoming mainstream. RISC-V vector instruction set was designed with AI and VR types of applications in mind.
Larry Lapides: I would add that in an AI application with a multiplex array of heterogeneous processors—an architecture we’ve seen implemented on more than one occasion—the designer can combine scalar and vector processors within the array. Second, the RISC-V architecture allows the designer to remove unnecessary functionality while preserving vector instructions. This provides better price, performance, and area—PPA.
Ingster: Can RISC-V cores with vector extensions also be extended with custom instructions?
Min: Yes. One example is a RISC-V vector core with a reference implementation that employs customer extensions to add extra buffers. This prevents the vector unit stalling from lack of data.
Lapides: Imperas and Andes have joint customers that have implemented custom functions to help in this area.
Ingster: In a multiprocessor array, do all the CPUs need to be the same configuration? Or can they have different custom instructions?
Lapides: Yes, heterogeneous processors in an SoC design are common. Furthermore, it’s not only the custom instructions that can vary from one processor to another. The base instructions of each processor can vary as well. For example, one processor could have vector instructions and another processor scalar instructions. These can be interleaved and combined.
Min: In a multiplexed array, both CPUs and simulators can be heterogeneous to enable multicore simulation.
Ingster: Do you see a server class RISC-V processor on the market?
Min: It is coming. CPU design over time becomes faster in different ways. One is by boosting frequency. Another is by extending the CPU pipeline. Another is by designing the processor to execute instructions out of order. And there will be widening of the execution width to provide a more super scalar organization or—what is becoming common today—designs employing thousands of multicores. It’s only a matter of time before we see these elements incorporated into next generation RISC-V processors for AI enterprise applications.
Lapides: If we look at past history of RISC-V, we see that initially, there were proof of concept SoCs that were 32 and 64 bit, but about two years ago we started seeing SoCs focused on security and IoT: 32-bit SoCs competitive with microcontrollers. Now we’re starting to see the first application-class processors. They’re not server class but we’re seeing initial silicon on 64-bit RISC-V processors running real RTOS looking at high end applications. We’re starting to see some out-of-order pipelines being built. I would expect the first server class RISC-V processors in the next two to three years.
Ingster: Can custom extensions provide device security and lifecycle management?
Min: Yes, depending on implementation. For example, by enabling an instruction extension to perform checking. The program checks for the custom extension. If it’s not present, the software is prevented from executing. Another option is to implement a custom port to memory. Thus, the RISC-V CPU would have a private bus to memory rather than using the main bus.
Taek Nam: Designers can use Tessent embedded analytics IP for security and lifecycle management in SoCs with custom extensions.
Ingster: Why is the RISC-V approach to custom instructions different from others such as ARC and Tensilica?
Min: CPUs employ custom extensions to accelerate a specific task. What makes RISC-V different is that it offers a formal mechanism to incorporate the custom extension into the standard.
Ingster: How can a developer share custom instructions with customers or partners?
Min: There are three options. First, keep it private. Second, propose the addition to RISC-V International for inclusion in the standard. For example, Andes donated a set of DSP instructions to RISC-V International. These are now the P-extensions of the RISC-V standard. Third, if you share the usage of the instruction with others, you will be sharing the intrinsics and header file. If you plan to share the implementation of the custom instruction, you may need to do a three-way NDA.
Lapides: The custom extension developer can pass on the model to their customers or partners as an open source or binary model, an ISS or instruction accurate processor model, that can be used for early pre-silicon software development.
Ingster: Will custom extensions lead to compatibility issues within the RISC-V Community?
Min: This will depend on how the custom instructions are used. If a custom instruction is kept proprietary, by definition it will not cause fragmentation since the developer is the only one using it. If the custom instruction becomes so successful it’s being used by many others, perhaps it’s time to incorporate it into the basic RISC-V set. The decision is up to the creator to make it public or keep it proprietary. Either way, no fragmentation will occur.
Ingster: Is the vector processor supported by a compiler in its current version?
Min: The RISC-V vector extensions, version 0.8, are stable enough that compilers support them. Both GCC and LLVM support the existing 0.8 version of the spec. Final versions of the compilers will be available when the RISC-V Vector Extension specification has been finalized.
Ingster: How are custom extensions supported in the software tool chain?
Lapides: Designers add the custom extensions to their RISC-V model, thus providing an instruction set simulator that can be used for software development. On the tool chain side, support for new custom extensions can be added into GCC and LLVM. Both are open source tool chains and can be modified at the customer’s discretion. Designers can also assemble a macro implementation to support a custom instruction.
Ingster: How is the compiler made aware of a newly created custom instruction?
Lapides: The software team has to implement the instruction in the compiler.
Min: An alternative without the hard work of making the addition, especially if the intent is to keep the instruction proprietary is to treat the custom instruction like a library – for example, DSP libraries. Then when the custom instruction is needed in program execution, call the library with a header file. Thus, for minimal work, the design team achieves much of the gain expected from creating a custom function.
Ingster: What OSs are supported on RISC-V and is there support for Android?
Lapides: I’ve not seen Android supported but there are some wearable devices designed with RISC-V. The Linux free RTOS, the Zephyr RTOS are the primary ones supported. There are other real time operating systems supported. The software web page of the RISC-V International has a complete list.
Min: Android OS has not been verified on RISC-V processors. I believe that it’s more a porting exercise rather than a question of can it run. RISC-V cores currently run Linux.
Ingster: How are custom extensions verified?
Lapides: Custom extensions are added into the RTL of the design, but they must also be added into the processor model. Custom instructions as well as custom registers can be verified using this capability. Typically, adding extensions to the processor model running on an instruction set simulator allows software development.
Taek: We recently had a customer implement custom instructions in their SoC. Using our embedded analytics IP, their goal was to verify their software performance improvement from adding the custom extensions. This was accomplished by using trace to track the data and instruction execution. This is an effective means of validating performance improvement.
Ingster: How much area is required to add the embedded analytics IP?
Taek: There is no standard answer, but 1 percent is a typical quote for area devoted to embedded analytics IP. This estimate includes analytic models, communicator, and message fabric connecting these elements. Because the blocks have multiple options, different configurations are possible. Each customer’s design is evaluated, and the embedded analytics IP is configured for implementing in their design. In this way the total area is estimated. We determine a solution that can minimize the area impact to provide the best value to a given design.