CV64A --> CVA6

Signed-off-by: Mike Thompson <[email protected]>

verif/Common/CORE-V_Verification_Strategy/source/corev_env.rst

@@ -81,7 +81,7 @@ as follows:
 
 The Instruction and Data memory interface is listed first for a reason.  This
 interface is generally the most core-specific.  For example, CV32E supports I&D
-interfaces that are AHB-like while CV64A supports AXI-like interfaces.  These
+interfaces that are AHB-like while CVA6 supports AXI-like interfaces.  These
 are significant difference and so the Testbench Layer deliberately hides this
 interface from the higher-level layers.  This is done in the "DUT Wrapper"
 module, see below.

verif/Common/CORE-V_Verification_Strategy/source/cva6_env.rst

@@ -0,0 +1,7 @@
+.. _cva6_env:
+
+CV6A Simulation Testbench and Environment
+==========================================
+
+TODO.
+

verif/Common/CORE-V_Verification_Strategy/source/formal.rst

@@ -1,11 +1,11 @@
 CORE-V Formal Verification
 ==========================
 
-Formal verification of the CV32E and CV64A cores is a joint effort of
+Formal verification of the CV32E and CVA6 cores is a joint effort of
 the OpenHW Group and OneSpin Solutions with the support of multiple
 Active Contributors (AC) from other OpenHW Group member companies. This
 section specifies the goals, work items, workflow and expected outcomes
-of CV32E and CV64A formal verification.
+of CV32E and CVA6 formal verification.
 
 Goals
 -----
@@ -79,11 +79,11 @@ At the time of this writing [17]_, the completeness of the RV32/64IMAC
 Sail models is not known, but is believed to be complete. Extensions of
 the models will be required to support Zifencei, Zicsr, Counters and the
 XPULP extensions. OpenHW may also wish to include User Mode and PMP
-support as well, especially for the CV64A. Its a given that much or all
+support as well, especially for the CVA6. Its a given that much or all
 of the work to create these extensions to the Sail models will need to
 be done by the OpenHW Group.
 
-Given that CV32E and CV64A projects are leveraging pre-existing
+Given that CV32E and CVA6 projects are leveraging pre-existing
 specifications and models, it should be possible for the
 micro-architecture and Sail models to be developed in parallel and by
 different ACs.
@@ -133,14 +133,14 @@ OpenHW Group to develop and deliver:
    Schiavone, Director of Engineering for the Cores Task Group.
 -  **Sail models** of each core’s ISA. This activity will be managed by
    the Verification Task Group. The expectation is that this
-   pre-existing Sail model can be extended for both the CV32E and CV64A
+   pre-existing Sail model can be extended for both the CV32E and CVA6
    cores, including the PULP ISA extensions.
 
 Compute and Tool Resources
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is rows #4 and #5 in , above. Tool licenses in sufficient numbers
-to allow for "reasonable" regression turn-around time on CV64A RTL.
+to allow for "reasonable" regression turn-around time on CVA6 RTL.
 These tools will be installed on VMs on the IBM Cloud and will only be
 accessible by employees/contractors of the OpenHW Group or select ACs
 actively involved in formal verification work.
@@ -149,7 +149,7 @@ Formal Testplans
 ~~~~~~~~~~~~~~~~
 
 OpenHW and OneSpin will jointly develop Formal Testplans for both the
-CV32E and CV64A. The high-level goals of the FTBs will be two-fold:
+CV32E and CVA6. The high-level goals of the FTBs will be two-fold:
 
 1. Prove that the core designs conform to the RISC-V+Pulp-extended ISA.
    Specifically, every instruction must:
@@ -194,7 +194,7 @@ is considered complete when all assumptions, assertions and covers are
 coded.
 
 OneSpin will initiate development of Formal testbenches (FTB) for CV32E
-and CV64A as soon as possible. These FTBs will be open-source, ideally
+and CVA6 as soon as possible. These FTBs will be open-source, ideally
 implemented in SystemVerilog, and may be based on OneSpin’s RISC-V
 Verification App [18]_.
 

verif/Common/CORE-V_Verification_Strategy/source/index.rst

@@ -17,7 +17,7 @@ Editor: **Michael Thompson**
    pulp_verif
    corev_env
    cv32_env
-   cv64_env
+   cva6_env
    sim_tests
    test_program_environment
    formal

verif/Common/CORE-V_Verification_Strategy/source/intro.rst

@@ -3,15 +3,15 @@ Introduction
 
 This document captures the methods, verification environment
 architectures and tools used to verify the first two members CORE-V
-family of RISC-V cores, the CV32E and CV64A.
+family of RISC-V cores, the CV32E and CVA6.
 
 The OpenHW Group will, together with its Member Companies, execute a
 complete, industrial grade pre-silicon verification of the first
-generation of CORE-V IP, the CV32E and CV64A cores, including their
+generation of CORE-V IP, the CV32E and CVA6 cores, including their
 execution environment [1]_. Experience has shown that “complete”
 verification requires the application of both dynamic (simulation, FPGA
 prototyping, emulation) and static (formal) verification techniques. All
-of these techniques will be applied to both CV32E and CV64A.
+of these techniques will be applied to both CV32E and CVA6.
 
 License
 -------
@@ -79,7 +79,7 @@ Definition of Terms
 | SDK         | Software Developers Toolkit.                                       |
 |             | A set of software tools used to compile C and/or RISC-V            |
 |             | assembler code into an executable format. In the case of           |
-|             | the CV32E and CV64A, this includes the supported RISC-V            |
+|             | the CV32E and CVA6, this includes the supported RISC-V             |
 |             | ISA compliant instructions, plus a set of XPULP extended           |
 |             | instructions.                                                      |
 +-------------+--------------------------------------------------------------------+

verif/Common/CORE-V_Verification_Strategy/source/pulp_verif.rst

@@ -3,9 +3,9 @@
 PULP-Platform Simulation Verification
 =====================================
 
-Before discussing the verification strategy of the CV32E and CV64A, we
+Before discussing the verification strategy of the CV32E and CVA6, we
 need to consider the starting point provided to OpenHW by the RI5CY
-(CV32E) and Ariane (CV64A) cores from PULP-Platform. It is also
+(CV32E) and Ariane (CVA6) cores from PULP-Platform. It is also
 informative to consider the on-going Ibex project, another open-source
 RISC-V project derived from the ‘zero-riscy’ PULP-Platform core.
 
@@ -15,8 +15,8 @@ Those wanting more background should read the :ref:`ri5cy` and
 :ref:`ariane` sub-sections of this chapter which review the
 status of RI5CY and Ariane testbenches in sufficient detail to provide
 the necessary context for the :ref:`cv32_env` and
-:ref:`cv64_env` chapters, which detail how the RI5CY and Ariane simulation
-environments will be migrated to CV32E and CV64A simulation
+:ref:`cva6_env` chapters, which detail how the RI5CY and Ariane simulation
+environments will be migrated to CV32E and CVA6 simulation
 environments.
 
 .. _exec_summary:
@@ -37,10 +37,10 @@ the verification environment developed for the Ibex core and will also
 be able to run hand-coded code-segments (programs) such as those
 developed by the RISC-V Compliance Task Group.
 
-In the case of CV64A, the existing verification environment developed
+In the case of CVA6, the existing verification environment developed
 for Ariane is not yet mature enough for OpenHW to use. The
 recommendation here is to build a UVM environment from scratch for the
-CV64A. This environment will re-use many of the components developed for
+CVA6. This environment will re-use many of the components developed for
 the CV32E verification environment, and will have the same ability to
 run the RISC-V Compliance test-suite.
 
@@ -260,7 +260,7 @@ The rationale for undertaking such a task is twofold:
    verification environment, particularly software developers. Note that
    such tests can be difficult to debug if the self check indicates an
    error, but, for a more "mature" core design, such as the CV32E
-   (RI5CY) and CV64A (Ariane) they can provide a useful way to run
+   (RI5CY) and CVA6 (Ariane) they can provide a useful way to run
    ‘quick-and-dirty’ checks of specific core features.
 
 Waiting for two to three months for RI5CY core verification to re-start
@@ -313,23 +313,23 @@ configuration.*
 
 So, the (very) good news is that the Ariane core has been subjected to
 basic verification and extensive exercising in the FPGA prototype. The
-not-so-good news is that CV64A lacks a good starting point for its
+not-so-good news is that CVA6 lacks a good starting point for its
 verification efforts.
 
-Comments and Recommendations for CV64A Verification
+Comments and Recommendations for CVA6 Verification
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Given that the focus of the Ariane verification environment is based on
 a specific FPGA implementation that the OpenHW Group is unlikely to use
 and the lack of a library of existing testcases, it is recommended that
-a new UVM-based verification environment be developed for CV64A. This
+a new UVM-based verification environment be developed for CVA6. This
 would be a core-based verification environment as is envisioned for
 CV32E and not the mini-SoC environment currently used by Ariane.
 
 At the time of this writing it is not known if the UVM environment
-envisioned for CV32E can be easily extended for CV64A, thereby allowing
+envisioned for CV32E can be easily extended for CVA6, thereby allowing
 a single environment to support both, or completely independent
-environments for CV32E and CV64A will be required.
+environments for CV32E and CVA6 will be required.
 
 IBEX
 ----
@@ -350,15 +350,15 @@ OpenHW Group is not planning to verify this core on its own. However,
 the Ibex verification environment is the most mature of the three cores
 discussed here and its structure and implementation is the closest to
 the UVM constrained-random, coverage driven environment envisioned for
-CV32E and CV64A.
+CV32E and CVA6.
 
 The documentation associated with the Ibex core is the most mature of
 the three cores discussed and this is also true for the `Ibex
 verification
 environment <https://ibex-core.readthedocs.io/en/latest/verification.html>`__,
 so it need not be repeated here.
 
-IBEX Impact on CV32E and CV64A Verification
+IBEX Impact on CV32E and CVA6 Verification
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Illustration 3 is a schematic of the Ibex UVM verification environment.  The
@@ -401,7 +401,7 @@ the compiler and ISS are coded in C/C++ so these components will be
 integrated using the SystemVerilog DPI. A new scoreboarding component to
 compare results from the ISS and RTL models will be required. It is
 expected that the *uvm_scoreboard* base class from the UVM library will
-be sufficient to meet the requirements of the CV32E and CV64A
+be sufficient to meet the requirements of the CV32E and CVA6
 environments with little or no extension.
 
 Refactoring the existing Ibex environment into a single UVM environment

verif/Common/CORE-V_Verification_Strategy/source/sim_tests.rst

@@ -8,7 +8,7 @@ environments are all UVM environments and the overall structure should
 be familiar to anyone with UVM experience. This section discusses the
 CORE-V-specific implementation details that affect test execution, and
 that are important to test writers. It attempts to be generic enough to
-apply to both the CV32E and CV64A environments.
+apply to both the CV32E and CVA6 environments.
 
 A unique feature of the CORE-V UVM environments is that a primary source
 of stimulus, and sometimes the only source of stimulus, comes in the