One of the appealing things about open-source is that it invites modification to the underlying technology. In the case of the RISC-V instruction set architecture (ISA), this includes adding user-defined extensions to the processor core itself. Naturally, this level of extensibility has implications on the design flow, particularly if the core is going to be instantiated in silicon within an SoC or ASIC device.
Today, many products are largely software-defined and take advantage of OTA (over the air) updates to the firmware to fix bugs or add new features. Unfortunately, the same is not valid for hardware; in most cases, once the hardware design is manufactured, its functionality is effectively locked. Putting the design into an FPGA could potentially allow OTA updates to the hardware, including a processor core. However, it carries a higher risk factor than OTA software updates.
For this reason, significant verification is an essential part of the hardware design flow. As the popularity of the RISC-V ISA continues to grow, so too is the rise in demand for verification solutions. The RISC-V design flexibility, based on a modular structure with many standard extensions plus custom instructions, enables a new wave of design innovation by adopters. But this opportunity in design flexibility is also changing the processor verification responsibility. SoC verification was based on using known-good processor IP from a few mainstream suppliers in the past. Now every SoC team can modify and adapt a RISC-V processor; thus, they also need to address the verification tasks associated with the new processor hardware.
The critical components of IP verification
Before the open standard RISC-V ISA was available, SoC design engineers had few options for processor IP selection. Invariably, it would mean using IP supplied as a pre-verified ‘black box’. With little room for customization, the overall chip verification would only extend to the interface to the IP, not the IP itself. The SoC verification task typically takes around 50-80% of the project’s total cost and effort, but now with RISC-V, these assumptions are no longer valid. RISC-V implementations are available as commercial IP offerings and also there are a growing number of open-source processor cores to challenge the processor IP status quo. However, whatever the starting point, any modification or extension still needs verification. One popular option for an open-source core is the CORE-V family from the OpenHW Group, with a unique focus on verification to overcome one of the common concerns for adopters of open-source hardware IP – quality.
As the net result, even experienced ASIC design engineers choosing to use RISC-V may have never had to verify a processor core before. The added challenge is that the IP may continue to be developed during the SoC design cycle, if the options to extend the core are exercised as an iterative design process. This flexibility on the processor design side follows through to the SoC verification and requires a parallel approach to the processor core in line with the overall SoC schedule. RISC-V processor verification is not just about IP quality but also impacts overall schedule dependencies within the complete SoC project.
The key components needed in the verification process include an overall design verification plan, the RTL code of the IP, a testbench, a test suite, some form of Reference Model (RM), and an environment to support simulation. The SystemVerilog module provided by OVP (Open Virtual Platforms) and Imperas includes a binary of a RISC-V CPU envelope model. This can be used in a testbench like any other module, and it features a control interface that allows SystemVerilog to load programs, run the clock and stop/start execution. The OVP model provides access to the CPU’s state registers and events. This can be configured to run in parallel, synchronized with the RTL of the device under test (DUT). Comparisons can be made at the instruction boundary; however, this is only the start of the process.
OpenHW Testbench – example of Step-and-Compare DV flow (Image courtesy of DVCon)
Step-and-Compare for RISC-V verification
Any discrepancies detected could be attributed to a bug, but just where that bug resides is still open to question. For example, it could be a design bug in the RTL, but it could equally be in the test bench, the test program, or even a misinterpretation of the ISA specification. At the design verification stage, the starting assumption is that the issue is in the RTL; the challenge then is to track the bug down to its source with a process for efficient resolution.
As the Imperas OVP reference model sits inside the SystemVerilog testbench, the RTL and reference models use the same simulation environment. This single environment approach allows the same debug session to control both the DUT and the reference model using a ‘step-and-compare’ methodology. This approach helps identify divergence at the earliest stage and avoids unnecessary simulation cycles. As used in other less efficient verification methodologies, post-simulation trace compare would typically keep executing after the first discrepancy, taking more time and resources long after the issue occurred and thus reducing the value of the results beyond the discrepancy event.
Once the basic functionality is verified, the next step is to use the simulation to run ‘real’ software. At this stage, it is usual to present the DUT with real-world conditions to evaluate its reaction to ‘the unexpected’. Subjecting the simulation to asynchronous events, including interrupts triggered by external stimuli, is a critical part of the overall verification process. This includes cascading events with multiple levels using a test generator that can provide repeatable tests. Recording the coverage of these tests is also essential for later analysis and progress towards completion of the test plan.
The RISC-V’s vector extensions have been developed to support emerging use-cases, emphasizing complex arithmetic, such as AI, machine learning (ML), and cryptography. The complexity of these extensions has been estimated to be greater than all other extensions combined. Imperas has produced tests comprising seven suites, with more than 5,000 tests covering over 300 vector instructions. Using the methodologies above, engineering teams can achieve around 91% functional test coverage with these architectural validation test suites as a useful phase of the overall verification plan.
The reference model used in the SystemVerilog testbench described above, developed by Imperas, in addition to verification, can also be used to execute software early in the project development schedule well before silicon prototypes are available. This includes extending the processor model with custom instructions, optimize software development, and supports key tasks such as OS bring-up. The VAP (Verification, Analysis and Profiling) tools and simulator, available commercially from Imperas (www.imperas.com), supports the open-source models and platforms available from the OVP (Open Virtual Platform) website, www.OVPworld.org.
Conclusion
RISC-V verification with SystemVerilog testbenches provides debug and analysis in a single environment. This directly addresses the disruption caused by RISC-V to conventional SoC development cycles that have relied on known-good IP in the past. However, the flexibility RISC-V brings must be assesed with the understanding that it increases the complexity of the verification tasks.
The Imperas RISC-V reference model, encapsulated using industry-standard SystemVerilog and UVM methodologies, is providing DV teams the essential reference point they need to develop verification flows that complement the design flexibility of RISC-V. RISC-V now offers all SoC developers the opportunity to build an optimized processor for the next generation of domain-specific devices. Standards-based verification helps address the verification of the RISC-V processor core, with the tools and methodologies already established for SoC’s, which also helps minimize the barriers to adoption of RISC-V.
For a more detailed analysis on the options for SystemVerilog UVM based RISC-V verification, this paper was presented at DVCon 2021, Jump start your RISCV project with OpenHW.
About Imperas
Imperas is the leading provider of RISC-V processor models, hardware design verification solutions, and virtual prototypes for software simulation. Imperas, along with Open Virtual Platforms (OVP), promotes open source model availability for a spectrum of processors, IP vendors, CPU architectures, system IP and reference platform models of processors and systems ranging from simple single core bare metal platforms to full heterogeneous multicore systems booting SMP Linux. All models are available from Imperas at www.imperas.com and the Open Virtual Platforms (OVP) website at www.OVPworld.org.