Systems & Design
SPONSOR BLOG

Adding Value To Open-Source RISC-V Cores With Verification

A collaboration to verify a PULP RI5CY core using industrial grade techniques provides a set of guidelines for the community.

popularity

By Steve Richmond (Silicon Labs), Mike Thompson (OpenHW Group), and Lee Moore (Imperas Software)

Modern SoC verification has matured to the point that some are suggesting the use of the word ‘prototype’ when referring to the first silicon samples is now unnecessary. This is due in part to the commercial EDA industry, which has provided the innovation and tools used throughout the design process, and the verification work that has become a specialty in its own right with dedicated conferences and standards. The open-source ISA of RISC-V has generated a lot of interest around custom processor design options and the associated design freedoms beyond the roadmap of the mainstream processor IP providers. Thus, RISC‑V has enabled any SoC developer to consider designing a bespoke processor, which in turn has stimulated the interest in adapting the established SoC design verification (DV) flows based on UVM and SystemVerilog to also address the complexities of processor verification. On top of this, the open-source ISA of RISC-V has renewed the interest in open-source hardware IP. With this background, the OpenHW Group was formed to enable the community to collaboratively develop open-source hardware IP with industrial strength verification, to provide the trust and confidence that is normally associated with commercial IP quality.

But this article is not just a typical case study summary (yes, spoiler alert, the project was completed successfully). Here, we highlight that as an open-source project all aspects of the project are available for the community to use, including:

  • All documentation including the Verification Strategy and DV plans.
  • Testbench, testcase and functional coverage source code.
  • Scriptware for testcase control, regression and CI management.
  • Checklists for milestone completion.
  • Code and Functional coverage results.

All of the above are open-source artifacts that can be used “out of the box” or perhaps act as a guideline for others to follow. This provides a spotlight and insights into the dark corners of processor verification that have long been shrouded in mystery and the close kept secret know-how of a few specialist teams.

The OpenHW Group [1] set out with a clear objective: use member contributed resources (people, compute, tools) and expertise to develop open-source RISC-V processor IP with industrial strength verification. Using the PULP RI5CY core as a starting point was a natural choice as a general purpose embedded core, as it had already gained some popularity. So, with a base core donation the OpenHW CORE-V-VERIF project was the natural starting point, and thus verification was the main focus from the start.

The first steps: A plan to test is a plan to succeed

As the OpenHW group is a collection of members from different organizations, they are structured around the typical task group arrangements for key activities. The early Verification task group meetings helped to clarify the state of the available tests, test benches, other open-source example projects, and obtain general guidance based on the experience of the contributing members. To make the claim that this project was an industrial grade IP had implications on the verification framework. It is not sufficient to just verify the core and produce a report. It is expected that future adopters of the core IP will also need access to the test bench and verification environment to complete their due diligence during an IP selection process for a new SoC design, and/or as a reference during the development as the core IP is modified or extended.

These ideas and intentions were captured in a verification strategy plan, and since the test plan will act as a guide towards project completion, the strategy defines the overall objectives. As an open-source community project these plans and documents are available on OpenHW’s CORE-V-DOCS GitHub repository [2].

To avoid “lock in” to any single EDA vendor, the test bench and test plan were developed around a common set of standards such as UVM and SystemVerilog, together with all the scripts and set-up to allow adopters to set-up the full test environment independently and with any of the commercial SystemVerilog suppliers.

OpenHW CORE-V CV32E40P: Feature highlights

The CV32E40P processor IP core is a small and power efficient, 32-bit, in-order RISC-V core with a 4-stage pipeline. The core targets applications with performance and low power requirements with support for flexible configuration options to address a range of market segments including Industrial, IoT, consumer, and general microcontroller applications.

OpenHW Verification Environment: CORE-V-VERIF

  • Provides a robust, comprehensive simulation environment for the CV32E40P core [1]
    • RISC-V Specification references – RV32IMCZifencei processor [3]
  • Readily adaptable to other CORE-V cores such as the CV32E40X, CV32E40S and CVA6.
  • Freely available on GitHub at openhwgroup/core-v-verif [4]
  • Industrial-grade verification
  • UVM environment
  • Runs on any fully SystemVerilog-compliant simulator
  • Complete code coverage
  • Well-defined comprehensive functional coverage
  • Open and complete verification plans [2]


Fig. 1: The OpenHW CORE-V-VERIF test bench as used for CV32E40P.

A guided tour of the CORE-V-VERIF CV32E40P test bench

The CORE-V-VERIF test bench shown in figure 1 was constructed around the CV32E40P RTL using SystemVerilog infrastructure and consists of 6 main components:

  • Corev-dv, an extension of the Google open source ISG (Instruction Steam Generator) – riscv-dv [5]
  • Design Under Test (DUT) – CV32E40P RTL
  • Imperas RISC-V Reference Model [6]
  • The Step-and-Compare state machine that keeps the DUT and RM in sync and compares their state as each instruction is retired.
  • UVM Agents to assert debug requests and interrupts, asynchronously from the test-program.
  • Complete functional coverage models to demonstrate coverage of all items in the DV plans.

The core-v-verif instruction stream generator (ISG) is known as corev-dv. It is implemented as an extension of riscv-dv, the Google ISG. Riscv-dv is an open-source project that supports many RISC-V ISA configuration options to provide a source of valid, but random instruction sequences. These test a processor with unusual and challenging instruction sequences and corner case scenarios. It’s worth noting that the corev-dv extends the riscv-dv SystemVerilog/UVM classes to create enhanced debug and interrupt capabilities. The underlying implementation of riscv-dv is not altered in any way which allows core-v-verif to keep up with new riscv-dv capabilities as they are implemented, plus add OpenHW-specific features as needed.

The generated test-programs are compiled and run on both the device under test and the reference model. This is achieved by encapsulating the reference model in a SystemVerilog DPI so that the testbench supports co-simulation for the RTL of the core, the test bench components, and the reference model. As simulations progress, functional coverage of the executed instructions and their opcodes is collected. Any discrepancies between the RTL and RM are flagged as UVM errors in real time. Post processing of tracer outputs is not required to determine if a test has passed or failed. In addition to the ISG test sequences, other test suites, directed tests and the RISC-V International RISC-V architectural validation test suites [7] can also be applied.

The quick guide to Step-and-Compare

In the outline above, the comparison between the DUT and the reference model is the essential engine that drives the whole verification process. While an instruction stream alone may present some unique corner case situations, a major additional challenge for a processor is the interactions caused with asynchronous interrupts and debug events. The Step-and-Compare approach (also sometimes called lock-step) maintains the synchronization between the DUT and reference model at the instruction boundary. This allows for controlled and repeatable analysis of asynchronous events and also provides a direct debug view of any discrepancies. In verification, just finding a bug is not sufficient, it’s vital to quickly and accurately trace back to the root cause of the failure and document the corrective action. The step-and-compare method allows a smooth and efficient transition to debug and analysis when an issue is uncovered.

The key role of the reference model in Step-and-Compare for Processor DV

The Imperas reference model itself is central to ensuring the verification quality of state comparison results. The Imperas model provides a full envelope capability across all RISC-V specifications covering subset extensions both ratified and draft (under active development). This also includes support for differing release levels, for example user specifications of 2.2, 2.3 or Privileged specifications of 1.10, 1.11. In terms of subset extensions not yet ratified, the core model contains many under development for example Vectors 0.7 through to 1.0 and Bit Manipulation 0.90 through to current draft, plus DSP and Crypto (Scalar) and Debug 0.13,2, 0.14.0 etc.

As the various RISC-V specifications mature it is anticipated that a future design may be based on a mix of versions across base and extension options, which can be easily selected within the Imperas reference model configuration. The model itself exists as a binary object, which in this example is linked to the SystemVerilog executable via the DPI. In order to control and observe the behavior of the model, it contains both a control and state interface, in order to synchronize execution, and extract the full and comprehensive architectural state for RTL comparison.

Next steps – extending and/or modifying the CV32E40P

Since an open-source core by definition provides opportunities for adopters to modify or extend the design, this is supported in the verification environment and reference model.

In addition to the standard set of supported configuration settings and instruction subsets, the Imperas reference model can be extended to support a custom extension set of instructions, in addition to custom Control/State registers. More importantly, this is implemented as an extension and not a modification to the existing envelope model, ensuring that previously verified functionality is not inadvertently modified, only extended from its base selected capabilities. A good example of this is the inclusion and support of the Debug specification, which is highly configurable in terms of its potential implementation.

The customized behavior of the debug specification can be described in a side extension which is bound to the base model for this custom configuration.

Conclusion

Through dedicated work and expert assistance, the members and contributors of the OpenHW Verification task group recently announced:

  • CV32E40P RISC-V CPU is fully verified and available as open-source RTL
  • The CORE-V-VERIF UVM SystemVerilog test bench is available as open source
  • Functional and Code Coverage is 100%
  • All tests pass
  • DV plans, coverage reports and project completion checklists are all available as open-source artifacts.

The open source CV32E40P has been selected as the starting point for many new SoC design projects and is actively maintained in the regression test framework supported by the cloud based SystemVerilog environment provided by Metrics Technologies.

Further information is available at the links below, or contact us at www.imperas.com.

References
[1] OpenHW Group https://www.openhwgroup.org

[2] OpenHW Group Documentation repository https://github.com/openhwgroup/core-v-docs

[3] RISC-V Specifications https://riscv.org/technical/specifications/

[4] OpenHW Group Verification repository https://github.com/openhwgroup/core-v-verif

[5] Google ISG https://github.com/google/riscv-dv

[6] Imperas Software https://www.imperas.com/riscv

[7] RISC-V Compliance tests https://github.com/riscv/riscv-arch-test

[8] PULP Platform https://www.pulp-platform.org

The authors would like to thank their fellow OpenHW Verification Task Group contributors for all the hard work, help and advice during the development and use of the CORE-V-VERIF project: Mike Thompson (OpenHW Group), Steve Richmond (Silicon Labs), David McConnell and Greg Tumbush (EM Microelectronic-US), Lee Moore (Imperas Software), and Aimee Sutton (Metrics Technologies) plus all the supporters across the OpenHW membership and ecosystem.  We would also like to acknowledge the contribution of the RI5CY core to the OpenHW Group by the PULP Platform team [8].

Steve Richmond is the Design Verification Manager for the Central R&D Division of Silicon Labs, verifying advanced compute engines (AI/ML), processors, and accelerators.  He is also the co-chair of the Verification Task Group at the OpenHW Group where he oversees verification methodology development and execution of verification for OpenHW cores, including the recent CV32E40P.  Richmond has over 20 years of design verification experience in networking, processors and mixed-signal designs.

 Mike Thompson is the OpenHW Group Director of Engineering, Verification Task Group. He is a senior IC Functional Verification engineering manager with more than 20 years’ experience. Thompson has led all aspects of the discipline with broad experience in simulation, emulation and prototyping plus management level experience of formal verification projects. He has both hands-on and management level experience with multiple SV/UVM projects and has developed teams driving SV/UVM for constrained-random, coverage driven verification efforts.

Lee Moore is the lead engineer at Imperas for RISC-V processor models and simulation tools. Prior to Imperas, Moore worked as a senior consulting engineer for EDA vendors such as Co-Design Automation and Ambit, and for ASIC vendor NEC Electronics. Moore is also a private pilot, and recently developed PilotAware, a low-cost air traffic awareness device, helping aircraft to see and be seen.



Leave a Reply


(Note: This name will be displayed publicly)