CV32E40P updates:
customizing an open-source RISC-V core at industrial-grade;
experiences and challenges
Pascal Gouédo¹, Yoann Pruvost1
    , Xavier Aubert¹, Olivier Montfort¹
Pasquale Davide Schiavone², Mike Thompson²

1Dolphin Design, 2    OpenHW Group

Abstract

This paper will focus on the design and verification strategy of an open-source RISC-V CPU for edge- computing platforms at industrial-grade.

                          Introduction                                     Therefore, in order to have CV32E40P fully compliant
   In 2021 Dolphin Design       made a     test chip  using    a    with the RISC-V specifications, all Xpulp instructions have
customized RI5CY CPU from ETH Zurich in one MCU sub-               been   re-encoded to fit  in   Custom-0 to         Custom-3.
system and in a Multicore platform with 16 cores.                   Additionally, the Pulp_Zfinx was fixed to meet the official
            However, the Technology-Readyness-Level (TRL) of the   Zfinx extension specification.
core was not high enough to meet standard required by               Verification
production requirements.
           When the core moved to the OpenHW Group organization,    Coming to the    verification side, the        Core-V-Verif
it achieved     a TRL-5 (enough to meet         industrial-grade         verification environment from OpenHW group was reused.
according to the official scale from NASA and the European            Core-V-Verif is an open-source SystemVerilog verification
Commission) by applying industrial verification strategies as           environment which follows the popular UVM. Core-V-Verif
step&compare     against a   reference      model,     Universal       was originally developed for v1.0.0 release of CV32E40P,
Verification Methodology (UVM), etc., on the RV32IMC                and at the time of writing, it has been extended to support
instructions subset supported by the core.                               four additional cores from the CORE-V family of RISC-V
         This paper will present the second verification project   cores.
applied to the CV32E40P core to verify the missing RV32F,                 A key feature of Core-V-Verif is its integration of a
Zfinx and custom RV32Xpulp ISA extensions to achieve a               reference model that executes the same test-program as the
TRL-5 on all the ISA supported by the core. We will talk               device-under-test (DUT). The first generation of Core-V-
about  the     challenges of verifying    custom     extensions,     Verif used an instruction set simulator (ISS) from Imperas
collaborating in  an open-source       ecosystem   with    other       Software as the reference model. Keeping the DUT and ISS
stakeholders, the Dolphin experience, and final outcome.                 synchronized was a challenge because these models have
                                                                      different concepts of time: the DUT is an RTL model which
       CV32E40Pv2                                               by definition is cycle-timed, and the ISS is instruction-timed.
           OpenHW Group is a not-for-profit, global organization          In the general case, instructions executing on an RTL
with the objective to deliver open-source cores at industrial-          model will require a variable number of clock cycles to
grade level.                                                          execute, while the same instruction stream on an ISS will
            Rather than verifying RI5CY core from the ground up,   always take a  constant number   of “instruction     cycles”
Dolphin Design (France) decided to become an OpenHW                (typically one). A technique called step&compare was used
Group member to drive and to execute the verification of the          to keep the two models synchronized by “stepping” the ISS
custom Xpulp ISA extension developed at ETH Zurich and             only after the DUT retired an instruction. At this point the
the official F and Zfinx RISC-V extensions.                                  state of the two models was compared. Any mismatch
   Specification and Design                                        between the PC, CSRs or GPRs was flagged as an error.
   Originally,        the RI5CY’s custom Xpulp instructions were     The above strategy was successful, but inefficient because
partly disseminated in RISC-V standard extensions as well               the step&compare logic in the testbench must compensate
as using   Custom extensions. And         Pulp_Zfinx  was    not  for the cycle-time effects of events that are asynchronous to
aligned with the ratified Zfinx extension.                         the instruction stream such as interrupts, debug resets plus


RISC-V Summit Europe, Barcelona, 5-9th June 2023                    1

           bus errors and random delays on instruction fetch and     Formal Verification

load/store memory buses. To accelerate the verification of more than 300 Xpulp For verification of v2.0.0 of the CV32E40P core, the ISS instructions, Formal Verification methodology and tools was replaced by a true reference model (RM) called have been analyzed and evaluated. ImperasDV. In this context, the distinction between an ISS At the end of this evaluation, Siemens EDA Onespin tools and an RM is two-fold: have been selected for ● An RM is aware of, and explicitly compensates for, ● their processor verification capabilities, the cycle-timed behavior of an RTL DUT; ● their RISC-V ISA app due to its ability to verify ● An RM is capable of predicting multiple legal state standard extension as well as easy methodology changes and comparing them to the actual state to extend it by adding custom instructions change of the DUT. ● described using pseudo-code language, for their RTL code coverage generation capability The reference model eliminated the need for complex using RTL mutation. This Formal code coverage step&compare logic by running in zero time and predicting database can be exported in standard format that multiple legal DUT states, based on instruction execution can be merged with RTL simulation code and external asynchronous events. In addition, the Imperas coverage. reference model has been extended to support the Xpulp instructions v2 specification. The Xpulp instructions pseudo-code description using Sail language have been added to the RISC-V ISA app to Another innovation for v2.0.0 was the adoption of a successfully formally verify all the CV32E40P instructions, standardized tracer interface to the DUT and RM, based on including the previously verified standard IMC together with the open-source RISC-V Verification Interface (RVVI). The the new F, Zfinx and Xpulp extensions. use of well documented, standardized interfaces greatly This has been applied on 5 different core configurations simplifies the integration of the DUT with the RM. (controlled via SystemVerilog parameters). In addition, to keep the already-verified RV32IMC Stimulus generation for a processor core comes in multiple instructions sane for v1.0.0 users, a CI flow running a forms: logical-equivalence-checking script between v1.0.0 and ● Automatic generation of pseudo-random test- v2.0.0 (parametrized like v1.0.0) has been running for each programs was facilitated by RISCV-DV, an open- contribution to the core. source, SV/UVM RISC-V instruction stream Software toolchain generator developed by Google. An OpenHW extension to RISCV-DV, called COREV-DV was One more important development is about supporting the used to generate random streams of any Xpulp instructions at industrial-grade in the GNU GCC SW ● instructions, v2 Xpulp ones included. toolchain. This has been done by Embecosm, which started Supplementing the random test-programs is a from the GCC official upstream repository based on GCC 12 library of manually generated C and Assembly on which they added the Xpulp instruction support at programs, including an obligatory “hello-world” as different levels (assembly, builtin and compiler). There was well as some benchmarking tests like Coremark a lot of investigation on -march option management and ● and Embench IOT test suite. builtin definition because no custom instruction has been Randomization of bus cycle delays on the pushed in GCC upstream repositories as of today. So a Instruction fetch and Load/Store memory interfaces builtin specification for CORE-V cores using RISC-V rules are generated by a UVM Agent for the Open Bus has been reviewed and released in OpenHW Group. After ● Interface (OBI) standard. that release, an important part of the work on the toolchain UVM Agents randomize interrupts and debug was to create and to verify more than 250 builtins. Another requests that are completely asynchronous to hot topic was the automatic generation of Hardware Loops program execution. These agents can be by the compiler. disabled/enabled at run-time so that any test- program can be used to test the effects of Conclusion interrupts/debug-request. The successful delivery of v2.0.0 release of CV32E40P is about to be possible thanks to open-source and OpenHW Group, where close collaboration of different people coming from different companies working in areas as different as software toolchain, reference model, hardware design and verification and EDA provider was a key enabler for the project.

2 RISC-V Summit Europe, Barcelona, 5-9th June 2023