Docs update

CONTRIBUTING.md

@@ -19,7 +19,7 @@ document is recommended reading.
 1. From GitHub: [fork](https://help.github.com/articles/fork-a-repo/) the [cve2](https://github.com/openhwgroup/cve2) repository
 2. Clone repository: `git clone https://github.com/[your_github_username]/cve2`
 3. Create your feature branch: `git checkout -b <my_branch>.`<br> Please uniquify your branch name.  See the [Git Cheats](https://github.com/openhwgroup/core-v-verif/blob/master/GitCheats.md)
-for a useful nominclature.
+for a useful nomenclature.
 4. Make your edits...
 5. Commit your changes: `git commit -m 'Add some feature' -s`
 6. Push feature branch: `git push origin <my_branch>`

README.md

@@ -7,7 +7,7 @@ The core will be made compatible with the OpenHW Group OBI protocol, it will use
 
 # CV32E20 RISC-V Core
 
-CV32E20 is a production-quality open source source 32-bit RISC-V CPU core written in
+CV32E20 is a production-quality open source 32-bit RISC-V CPU core written in
 SystemVerilog. The CPU core is heavily parametrizable and well-suited for
 embedded control applications. CV32E20 is being extensively verified and has
 seen multiple tape-outs. CV32E20 supports the Integer (I) or Embedded (E),
@@ -16,7 +16,7 @@ Integer Multiplication and Division (M), and Compressed (C) extensions.
 The block diagram below shows the *small* parametrization with a 2-stage
 pipeline.
 
-<p align="center"><img src="doc/03_reference/images/blockdiagram.svg" width="650"></p>
+<p align="center"><img src="doc/03_reference/images/blockdiagram.drawio.svg" width="650"></p>
 
 CV32E20 was initially developed as part of the [PULP platform](https://www.pulp-platform.org)
 under the name [&#34;Zero-riscy&#34;](https://doi.org/10.1109/PATMOS.2017.8106976), and has been
@@ -47,10 +47,12 @@ Only the person who actually performs the merge can add these labels (you need c
 
 ## Configuration
 
+<!-- TODO: This section and numbers need to be updated considering that the example code was removed -->
+
 CV32E20 offers several configuration parameters to meet the needs of various application scenarios.
 The options include different choices for the architecture of the multiplier unit, as well as a range of performance and security features.
 The table below indicates performance, area, and verification status for a few selected configurations.
-These are configurations on which lowRISC is focusing for performance evaluation and design verification (see [supported configs](cve2_configs.yaml)).
+These are configurations on which OpenHW is focusing for performance evaluation and design verification (see [supported configs](cve2_configs.yaml)).
 
 | Config                            | "micro" | "small"               |
 | --------------------------------- | ------- | --------------------- |
@@ -72,21 +74,21 @@ Notes:
   Green indicates that verification is close to complete.
   Amber indicates that some verification has been performed, but the configuration is still experimental.
   Red indicates a configuration with minimal/no verification.
-* v.1.0.0 of the RISC-V Bit-Manipulation Extension is supported as well as the remaining sub-extensions of draft v.0.93 of the bitmanip spec.
+<!-- * v.1.0.0 of the RISC-V Bit-Manipulation Extension is supported as well as the remaining sub-extensions of draft v.0.93 of the bitmanip spec.
   The latter is *not ratified* and there may be changes before ratification.
-  See [Standards Compliance](https://ibex-core.readthedocs.io/en/latest/01_overview/compliance.html) in the Ibex documentation for more information.
+  See [Standards Compliance](https://ibex-core.readthedocs.io/en/latest/01_overview/compliance.html) in the Ibex documentation for more information. -->
 
 ## Documentation (to be updated)
 
 The CVE2 documentation can be
 [read online at ReadTheDocs](https://docs.openhwgroup.org/projects/cve2-user-manual/en/latest/). It is also contained in
 the `doc` folder of this repository.
 
-## Examples
+<!-- ## Examples
 
 The CVE2 repository includes [Simple System](examples/simple_system/README.md).
 This is an intentionally simple integration of CV32E20 with a basic system that targets simulation.
-It is intended to provide an easy way to get bare metal binaries running on CV32E20 in simulation.
+It is intended to provide an easy way to get bare metal binaries running on CV32E20 in simulation. -->
 
 ## Contributing
 

doc/02_user/getting_started.rst

@@ -1,9 +1,9 @@
 .. _getting-started:
 
-Getting Started with Ibex
+Getting Started with CVE2
 =========================
 
-This page discusses initial steps and requirements to start using Ibex in your design.
+This page discusses initial steps and requirements to start using CVE2 in your design.
 
 Identification CSRs
 -------------------
@@ -12,7 +12,7 @@ The RISC-V Privileged Architecture specifies several read-only CSRs that identif
 These are ``mvendorid``, ``marchid`` and ``mimpid``.
 The fixed, read-only values for these CSRs are defined in :file:`rtl/cve2_pkg.sv`.
 Implementers should carefully consider appropriate values for these registers.
-Ibex, as an open source implementation, has an assigned architecture ID (``marchid``) of 0x23 (equivalent to 0d35).
+CVE2, as an open source implementation, has an assigned architecture ID (``marchid``) of 0x23 (equivalent to 0d35).
 (Allocations are specified in `marchid.md of the riscv-isa-manual repository <https://github.com/riscv/riscv-isa-manual/blob/master/marchid.md>`_.)
 If significant changes are made to the micro-architecture a different architecture ID should be used.
 The vendor ID and implementation ID (``mvendorid`` and ``mimpid``). The vendor ID (mvendorid) is assigned the value 0x602 and the implementation ID (mimpid) is assigned the value 0x0.

doc/02_user/index.rst

@@ -1,8 +1,10 @@
-Ibex User Guide
+.. _cve2_user_guide:
+
+CVE2 User Guide
 ===============
 
-The Ibex User Guide provides all necessary information to use Ibex.
-It is aimed at hardware developers integrating Ibex into a design, and software developers writing software running on Ibex.
+The CVE2 User Guide provides all necessary information to use CVE2.
+It is aimed at hardware developers integrating CVE2 into a design, and software developers writing software running on CVE2.
 
 .. toctree::
    :maxdepth: 1

doc/02_user/integration.rst

@@ -14,12 +14,10 @@ Instantiation Template
 .. code-block:: verilog
 
   cve2_top #(
-      .MHPMCounterNum   ( 0                                ),
+      .MHPMCounterNum   ( 10                               ),
       .MHPMCounterWidth ( 40                               ),
       .RV32E            ( 0                                ),
-      .RV32M            ( cve2_pkg::RV32MFast              ),
-      .RndCnstLfsrSeed  ( cve2_pkg::RndCnstLfsrSeedDefault ),
-      .RndCnstLfsrPerm  ( cve2_pkg::RndCnstLfsrPermDefault )
+      .RV32M            ( cve2_pkg::RV32MFast              )
   ) u_top (
       // Clock and reset
       .clk_i                  (),
@@ -38,7 +36,6 @@ Instantiation Template
       .instr_rvalid_i         (),
       .instr_addr_o           (),
       .instr_rdata_i          (),
-      .instr_rdata_intg_i     (),
       .instr_err_i            (),
 
       // Data memory interface
@@ -51,9 +48,27 @@ Instantiation Template
       .data_wdata_o           (),
       .data_wdata_intg_o      (),
       .data_rdata_i           (),
-      .data_rdata_intg_i      (),
       .data_err_i             (),
 
+      // Core-V Extension Interface (CV-X-IF)
+      // Issue Interface
+      .x_issue_valid_o        (),
+      .x_issue_ready_i        (),
+      .x_issue_req_o          (),
+      .x_issue_resp_i         (),
+
+      // Register Interface
+      .x_register_o           (),
+
+      // Commit Interface
+      .x_commit_valid_o       (),
+      .x_commit_o             (),
+
+      // Result Interface     (),
+      .x_result_valid_i       (),
+      .x_result_ready_o       (),
+      .x_result_i             (),
+
       // Interrupt inputs
       .irq_software_i         (),
       .irq_timer_i            (),
@@ -95,13 +110,13 @@ Parameters
 |                              |                     |            | "cve2_pkg::RV32MSingleCycle": 1-2 cycle multiplier, iterative divider |
 +------------------------------+---------------------+------------+-----------------------------------------------------------------------+
 
-Any parameter marked *EXPERIMENTAL* when enabled is not verified to the same standard as the rest of the Ibex core.
+Any parameter marked *EXPERIMENTAL* when enabled is not verified to the same standard as the rest of the CVE2 core.
 
-Note that Ibex uses SystemVerilog enum parameters e.g. for ``RV32M``.
+Note that CVE2 uses SystemVerilog enum parameters e.g. for ``RV32M``.
 This is well supported by most tools but some care is needed when overriding these parameters at the top level:
 
 * Synopsys VCS does not support overriding enum and string parameters at the top level via command line.
-  As a workaround, SystemVerilog defines are used in Ibex top level files simulated with VCS.
+  As a workaround, SystemVerilog defines are used in CVE2 top level files simulated with VCS.
   These defines can be set via command line.
 
 * Yosys does not support overriding enum parameters at the top level by setting enum names.

doc/02_user/system_requirements.rst

@@ -1,11 +1,11 @@
 System and Tool Requirements
 ============================
 
-The Ibex CPU core is written in SystemVerilog.
+The CVE2 CPU core is written in SystemVerilog.
 We try to achieve a balance between the used language features (as described in our `style guide <https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md>`_) and reasonably wide tool support.
 
-The following tools are known to work with the RTL code of Ibex.
-Please `file an issue <https://github.com/lowRISC/ibex/issues>`_ if you experience problems with any of the listed tools, or if you have successfully used a tool with Ibex which is not listed here.
+The following tools are known to work with the RTL code of CVE2.
+Please `file an issue <https://github.com/openhwgroup/cve2/issues>`_ if you experience problems with any of the listed tools, or if you have successfully used a tool with CVE2 which is not listed here.
 
 - Synopsys Design Compiler
 - Xilinx Vivado, version |tool_requirements.vivado| and up.
@@ -18,14 +18,14 @@ Please `file an issue <https://github.com/lowRISC/ibex/issues>`_ if you experien
 To run the UVM testbench a RTL simulator which supports SystemVerilog and UVM 1.2 is required.
 The `documentation of riscv-dv <https://github.com/google/riscv-dv#prerequisites>`_ contains a list of supported simulators.
 
-To compile code that runs on Ibex, you'll need a RISC-V toolchain.
+To compile code that runs on CVE2, you'll need a RISC-V toolchain.
 This isn't part of the core as such, but is necessary for verification.
 See the :doc:`Verification <../03_reference/verification>` section of the Reference Guide for more details about which toolchains the project currently uses for testing.
 
 Tools with known issues
 -----------------------
 
-Not all EDA tools have enough SystemVerilog support to be able to work with the Ibex code base.
+Not all EDA tools have enough SystemVerilog support to be able to work with the CVE2 code base.
 Users of such tools are encouraged to file issues with the vendor.
 As a workaround, tools like `sv2v <https://github.com/zachjs/sv2v>`_ can pre-process the source code to an older version of Verilog.
 

doc/03_reference/cosim.rst

@@ -6,9 +6,9 @@ Co-simulation System
 Overview
 --------
 
-A co-simulation system is provided that can run in either the Ibex UVM DV environment or with Simple System.
-This system runs a RISC-V ISS (currently only Spike is supported) in lockstep with an Ibex core.
-All instructions executed by Ibex and memory transactions generated are checked against the behaviour of the ISS.
+A co-simulation system is provided that can run in either the CVE2 UVM DV environment or with Simple System.
+This system runs a RISC-V ISS (currently only Spike is supported) in lockstep with an CVE2 core.
+All instructions executed by CVE2 and memory transactions generated are checked against the behaviour of the ISS.
 This system supports memory errors, interrupt and debug requests which are observed in the RTL simulation and forwarded to the ISS so the ISS and RTL remain in sync.
 The system uses a generic interface to allow support of multiple ISSes.
 Only VCS is supported as a simulator, though no VCS specific functionality is required so adding support for another simulator should be straight-forward.
@@ -25,16 +25,16 @@ It is disabled by default in the UVM DV environment currently, however it is int
 Setup and Usage
 ---------------
 
-Clone the `lowRISC fork of Spike <https://github.com/lowRISC/riscv-isa-sim>`_ and check out the ``ibex-cosim-v0.1`` tag.
-Other, later, versions called ``ibex-cosim-v*`` may also work but there's no guarantee of backwards compatibility.
+Clone the `lowRISC fork of Spike <https://github.com/lowRISC/riscv-isa-sim>`_ and check out the ``cve2-cosim-v0.1`` tag.
+Other, later, versions called ``cve2-cosim-v*`` may also work but there's no guarantee of backwards compatibility.
 Follow the Spike build instructions to build and install Spike.
 The build will install multiple header files and libraries, it is recommended a custom install location (using ``--prefix=<path>`` with ``configure``) is used to avoid cluttering system directories.
 The ``--enable-commitlog`` and ``--enable-misaligned`` options must be passed to ``configure``.
 
 Once built, the ``CVE2_COSIM_ISS_ROOT`` environment variable must be set to the Spike root install directory (as given by ``--prefix=<path>`` to ``configure``) in order to build either the UVM DV environment or Simple System with co-simulation support.
 
 To build/run the UVM DV environment with the co-simulator add the ``COSIM=1`` argument to the make command.
-To build Simple System with the co-simulator build the ``lowrisc:cve2:cve2_simple_system_cosim`` core.
+To build Simple System with the co-simulator build the ``openhwgroup:cve2:cve2_simple_system_cosim`` core.
 
 Quick Build and Run Instructions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -43,7 +43,7 @@ Build and install the co-simulator
 
 .. code-block:: bash
 
-  # Get the Ibex co-simulation spike branch
+  # Get the CVE2 co-simulation spike branch
   git clone -b cve2_cosim https://github.com/lowRISC/riscv-isa-sim.git riscv-isa-sim-cosim
 
   # Setup build directory
@@ -71,7 +71,7 @@ Build and run Simple System with the co-simulation enabled
 .. code-block:: bash
 
   # Build simulator
-  fusesoc --cores-root=. run --target=sim --setup --build lowrisc:cve2:cve2_simple_system_cosim --RV32E=0 --RV32M=cve2_pkg::RV32MFast
+  fusesoc --cores-root=. run --target=sim --setup --build openhwgroup:cve2:cve2_simple_system_cosim --RV32E=0 --RV32M=cve2_pkg::RV32MFast
 
   # Build coremark test binary, with performance counter dump disabled. The
   # co-simulator system doesn't produce matching performance counters in spike so
@@ -82,7 +82,7 @@ Build and run Simple System with the co-simulation enabled
   export LD_LIBRARY_PATH=/opt/spike-cosim/lib:$LD_LIBRARY_PATH
 
   # Run coremark binary with co-simulation checking
-  build/lowrisc_cve2_cve2_simple_system_cosim_0/sim-verilator/Vcve2_simple_system --meminit=ram,examples/sw/benchmarks/coremark/coremark.elf
+  build/openhwgroup_cve2_cve2_simple_system_cosim_0/sim-verilator/Vcve2_simple_system --meminit=ram,examples/sw/benchmarks/coremark/coremark.elf
 
 Co-simulation details
 ----------------------
@@ -121,7 +121,7 @@ Trap Handling
 Traps are separated into two categories, synchronous and asynchronous.
 Synchronous traps are caused by a particular instruction's execution (e.g. an illegal instruction).
 Asynchronous traps are caused by external interrupts.
-Note that in Ibex error responses to both loads and store produce a synchronous trap so the co-simulation system has the same behaviour.
+Note that in CVE2 error responses to both loads and store produce a synchronous trap so the co-simulation system has the same behaviour.
 
 A synchronous trap is associated with a particular instruction and prevents that instruction from completing its execution.
 That instruction doesn't retire, but is still made visible on the RVFI.
@@ -150,13 +150,13 @@ Memory Access Checking and Bus Errors
 
 The co-simulation system must be informed of all Dside accesses performed by the RTL using ``notify_dside_access``.
 See :file:`dv/cosim/cosim.h` for further details.
-As Ibex doesn't perform speculative Dside memory accesses, all notified accesses are expected to match with accesses performed by the ISS in the same order they are notified.
+As CVE2 doesn't perform speculative Dside memory accesses, all notified accesses are expected to match with accesses performed by the ISS in the same order they are notified.
 
 Accesses notified via ``notify_dside_access`` can specify they saw an error response, the co-simulation system will produce the appropriate trap when the ISS attempts to access the address that saw the error.
 
 Accesses must be notified before they occur in the ISS for the access matching and trapping on errors to work.
 
-Iside accesses from Ibex can be speculative, so there is no simple link between accesses produced by the RTL and the accesses performed by the ISS for the Iside.
+Iside accesses from CVE2 can be speculative, so there is no simple link between accesses produced by the RTL and the accesses performed by the ISS for the Iside.
 This means no direct checking of Iside accesses is done, however errors on the Iside accesses that result in an instruction fault trap need to be notified to the co-simulation system.
 ``set_iside_error`` does this, it is provided with the address that saw the bus error and it should be called immediately before the ``step`` that will process the trap.
 The co-simulation system will produce an instruction fault trap if it attempts to access the provided error address in the ``step`` call following the ``set_iside_error`` call.
@@ -172,8 +172,8 @@ When a faulting instruction is reported on the RVFI and its ``rvfi_order_id`` ma
 
 The external interface probe should be used when it is guaranteed that a bus error to address A on the external interface results in a fetch error the next time an instruction with address A is observed entering the ID/EX stage (providing no successful access to A has occurred in the mean time).
 Otherwise the internal probe should be used.
-When Ibex is used with the prefetch buffer this guarantee holds and the external probe can be used.
-When Ibex is used with the instruction cache this guarantee does not hold and the internal probe must be used.
+When CVE2 is used with the prefetch buffer this guarantee holds and the external probe can be used.
+When CVE2 is used with the instruction cache this guarantee does not hold and the internal probe must be used.
 
 Care should be taken when using the internal probe as it will miss any bug that causes instruction faults to be ignored by the prefetch buffer or ICache (or whatever else has been used in place of these by a custom implementation).
-In the case of the Ibex ICache a separate testbench ensures instruction faults are dealt with appropriately within the ICache.
+In the case of the CVE2 ICache a separate testbench ensures instruction faults are dealt with appropriately within the ICache.