Enabling industrial-grade open verification for RISC-V - Embedded.com

Enabling industrial-grade open verification for RISC-V

The open nature of the RISC-V means anyone can design a custom processor, moving the verification task from a few specialist suppliers to all SoC developers. This article looks at an open-source IP with industrial-grade verification and open methodology to support verification of an open-source CV32E40P core.

The amount of time, money and effort it takes to design a system-on-chip (SoC) means it is not surprising when engineering teams want to get it right first time. This long-held ideal doesn’t just happen on its own; it takes a lot of test, measurement and verification. Of course, this requires funding and effort, but as most people would agree, spending a little more in the early design phase can save spending much, much more later.

This is certainly the case with RISC-V processor intellectual property (IP) cores. Previously, SoC design verification (DV) was based on the basic assumption of known-good processor IP as supplied by the established mainstream providers. But now, with the open nature of the RISC-V standard, anyone can design a custom processor. This, in turn, moves the verification task from a few specialist suppliers to all SoC developers. RISC-V verification is such an essential part of the process that it is practically becoming a standalone market segment. 

RISC-V is an open standard ISA (instruction set architecture) that supports a modular and flexible framework for optimized processor implementations. RISC-V based IP cores can be delivered as commercial products or developed internally, and some are available as open-source projects. Although open-source hardware IP for chip or SoC designs is an attractive option, quality concerns remain a barrier for broad adoption and acceptance, especially for complex IP such as processor cores.

The OpenHW group has a founding objective to deliver open-source IP with industrial-grade verification based on established and trusted standards. The initial project has produced just that; an open methodology that can support the verification of the open-source CV32E40P core. To support this vision, the OpenHW full verification environment and flows are openly available to help both build confidence in the IP quality and serve as a platform as the cores are modified or extended by future adopters.

The resources are all freely available and include the testbench, documentation, scripts for testcase control, a checklist of completed milestones, as well as all the code and functional coverage results. It is hoped that these resources will be used either ‘out of the box’ or as a template for other DV teams to follow.

Perhaps even more important is that the project presents some technologies and verification methodologies that may otherwise only be known by experienced processor DV teams. By making all the resources and results of the project freely available on GitHub, adopters can continue to use the test flow as they modify or extend the open-source processor IP. In addition, other design teams can use this as a guide to improve their verification process and achieve that elusive ‘right first-time’ objective.

Fail to plan, and you plan to fail

The OpenHW Group established a verification task group to tackle the project, which then generated a verification strategy plan. The key objective was to document everything other engineers may need to perform their due diligence as they adopt, modify or extend the cores. All of the documents are now available on the OpenHW Group’s GitHub repository, CORE-V-DOCS.

The test plans were developed using UVM (universal verification methodology), making the project as transferable and easy to adopt by the SoC community as possible. This approach uses class libraries based on SystemVerilog to create a verification environment that isn’t specific to any single EDA tool vendor.

The initial focus addressed the verification of the CV32E40P core, a power-efficient 32-bit RISC‑V core that is small in size but big in popularity. It uses in-order execution with a 4-stage pipeline and now being used in several commercial SoC designs. These include internet of things (IoT) devices for the industrial and consumer sectors, as well as a general-purpose 32-bit microcontroller.

The verification environment created is called the core-v-verif (figure 1). It provides a simulation environment for the CV32E40P RTL core based on the RISC-V specification (RV32IMCZifencei). The environment will be adapted to other future CORE-V cores, including the CV32E40X, CV32E40S and CVA6, and is freely accessible on GitHub.

Imperas Open Verification to RISC-V
Figure 1: The CORE-V-VERIF test bench, developed by the OpenHW Group for the CV32E40P (Source: Imperas Software Ltd)

A key goal of the project was that the environment should be open, EDA vendor-independent, and based on standards, such as UVM, to provide industrial-grade verification that is compatible with the common SoC DV flows. This target was achieved, and the environment runs on any SystemVerilog-compliant simulator. In addition, it delivers complete code coverage and comprehensive functional coverage and is supported by open and complete verification plans.

There are six main components to the verification environment, shown in figure 1. These include the DUT (design under test), which in this case is the CV32E40P RTL. It also includes the RISC-V reference model (RM) and the COREV-DV; an extension to the Google open source ISG (instruction stream generator). Other key elements in the core-v-verif environment are the step-and-compare state machine, which synchronizes the DUT and RM. Debug requests and interrupts are asserted by the UVM Agents, which happen asynchronously under control of the test program. The final element is the functional coverage models, which corresponds to the DV plans.

The ISG in the core-v-verif environment, core-dv, is an extension of Google’s open-source ISG known as riscv-dv. Google’s ISG is a popular option and supports several RISC-V ISA configurations. While the standard riscv-dv, which provides instruction sequences to test a processor, is a useful DV tool, as an open-source project, it can also be extended by users.

The implementation created by the verification task group extends the SystemVerilog/UVM classes used to include enhanced debug and interrupt capabilities, which builds on the challenging instruction sequences and corner-case scenarios provided by riscv-dv. This is achieved without changing the core riscv-dv implementation, so core-v-verif stays aligned with any future improvements made to riscv-dv while also implementing the OpenHW Group’s specific capabilities.  

The test programs are compiled and executed on both the DUT and the RM, using the SystemVerilog DPI (direct programming interface). This methodology allows the testbench to simulate the core (in RTL form), the RM and the test bench components concurrently. During simulation, the opcodes of the instructions executed are captured, allowing a comparison between the RTL core and the RM. Any variations are shown in real time as UVM errors, which means no post-processing is required to determine whether a test has passed or failed. Other test suites, such as the RISC-V International RISC-V architectural validation test suites, can also be applied.

Step-and-compare for verification

The verification flow described above, which illustrates the comparisons made between the DUT and the RM, is fundamental to the verification methodology. The instruction stream can be used to identify some unique corner cases; another important task for processor design teams is to understand what happens under asynchronous conditions, such as interrupts.

Imperas step and compare state machine
Figure 2: Step and compare state machine (Source: Imperas Software Ltd)

The step-and-compare (also known as lock-step) approach keeps the DUT and RM synchronized at the instruction boundary (figure 2). This lock-step allows asynchronous events to be analyzed in a repeatable way, so any discrepancies can be viewed as part of the debug process. Tracing back to the root cause of a bug is imperative during verification, and the step-and-compare method allows a seamless transition between debug and analysis.

The RM provided by Imperas is another fundamental element to the quality of verification and the state comparisons carried out. The Imperas reference model is fully configurable across all RISC-V specifications and covers subset extensions, both under development and those already ratified. Those currently under development but covered by the Imperas RM include vectors (0.7 through to 1.0), and bit manipulation (0.90 through to the current draft), plus DSP, crypto (scalar) and debug are also supported, as well as the various release levels across the base user and privileged specifications.

In the future, it is anticipated that cores may be based on combinations of RISC-V specifications, across a variety of the base and standard extensions. The Imperas envelope RM can support these combinations within its configuration granularity, covering all the features and incremental versions of the RISC-V specifications.

In the core-v-verif flow the Imperas RISC‑V RM is integrated into the SystemVerilog testbench as a binary object, linked to the SystemVerilog executable through the DPI. The model includes a control and state interface which provides synchronization and extraction of architectural states for RTL comparison of the in-order pipeline of CV32E40P. However, for RISC-V core designs featuring multi-harts or out-of-order pipelines, the Imperas RM allows detailed control features to ensure complete synchronization and the ability to compare with the RTL under test.

Supporting core extensions

One of the main benefits of open-source IP and the RISC-V ISA is the ability to extend its capabilities. This is supported by the verification environment and the Imperas RM. In addition to custom control/state registers and the standard set of configurations and instruction subsets, the model supports a custom extension set of instructions.

Because this capability is implemented as an extension, there is no modification of the envelope model. This means any functionality that has already been verified is not changed, but instead extended from its base capabilities. For example, support of the debug specification is provided in this way, even though it is highly configurable in its implementation. It can be coded as a side extension, which is bound to the base model.

A reference verification solution that others can build on

The RISC-V ISA is becoming extremely popular, thanks to its open-standard nature but also because of the features and benefits offered by the open-source cores it enables. This includes the CV32E40P, which is popular with developers targeting new SoC designs across a range of industrial and commercial applications.

The OpenHW Verification task group has worked hard to fully test and verify the open source CV32E40P RISC-V core. What is more, in doing so, it has also produced the core-v-verif test bench, also freely available on GitHub and works with any tools that support UVM/SystemVerilog standards. In concluding the CV32E40P verification project, the core passed all tests, which included 100% functional and code coverage. All documentation for the project is available and it provides a valuable source of information for any design team looking to evaluate, adopt and/or modify the core. With a focus on the need for an industrial-grade verification solution for RISC-V, the OpenHW Verification task group has truly delivered a reference that others can build the future on.


Imperas Kevin McDermott

Kevin McDermott is vice president of marketing at Imperas Software. Previously, he held various senior business and management roles at Arm, MIPS and Imagination Technologies, focused on CPU IP and software development tools. Kevin received his BSc degree in microelectronics and microprocessor applications from the University of Newcastle upon Tyne, U.K.



Related Contents:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.