This roadmap presents the CVA6 team's plans and upcoming work. It is intended to provide visibility on our directions to a broader audience.

Short term

Including urgent activities.

Merging master and master_candidate branches

This activity is two-fold:

• Porting back the assets from the CV32A60X fully verified core (TRL-5) to the master branch
• Rationalizing the internal interconnect to the YPB protocol (a superset of OBI), to ease future integration (e.g. scratchpad memories, additional bus interfaces)

Some work is still needed for debugging and to merge recent commits from the master branch and help is welcome.

SDTrig

SDTrig will be updated to work in more configurations.

Addressing new issues

We are receiving many new issues and trying to triage and solve them.

CI Infrastructure

Redesigning the Thales CI infrastructure to handle multiple configurations.

Trace unifying

The simulation environment logs committed instructions in two ways for historical reason. We'll keep the one connected to RVFI to ease maintenance.

Note: No impact on the TIP implemented in the RTL code.

Medium term

Ongoing activities with significant interaction with the CVA6 team.

Releasing

We are planning to restart producing CVA6 releases with a 3 to 6-month period.

Level 1 caches

The HPDCache is replacing the vanilla level 1 caches from PULP platform. It is also being adopted for L1 instruction cache under the HPICache name. This allows to maintain a single L1 cache that support both write-through and write-back modes of operation.

HPDCache is also being adopted by the multi-core CV-TCCC platform (aka Culsans) and the many-core CV-Mesh framework (part of OpenPiton).

For radiative environments like space, the HPDCache is getting an optional hardening:

• SECDED to correct one error and detect two errors per cache line
• Scrubbing to prevent the accumulation of errors over time in non-accessed lines
• Redundant bits over bus accesses (to L2 cache or main memory) to harden the in-flight transactions.

The hardened HPDCache is a natural candidate for integration into a DCLS (dual-core lockstep) or TMR (triple-modular redundancy) design.

The vanilla WT and WB caches are now deprecated and will be removed from the code base.

DCLS implementations

Three DCLS (dual-core lockstep) projects were conducted, unknownly of each other.

• cva6-safe features DCLS and error detection and recovery in L1 caches and with temporal diversity. It can be configured in dual-core AMP for non-critical workloads. It has been tested with Linux and Zephyr and has been integrated in a taped-out 18 nm SoC.
• cva6-dcls has similar features and will soon undergo a verification campaign.
• eLS (embedded lock-step) based on CV32A60X.

The teams are now cooperating to converge and include these safety features in the CVA6 repository, including the transition to HPDCache.

CV64A60AX

A 64-bit configuration including MMU and FPU (among others) is being verified by CEA.

CHERI

CVA6-CHERI is a derivative of CV64A6 that supports hypervision and the CHERI memory safety model, that is expected to be soon ratified by RISC-V International. To ease compatibility with existing code, CHERI will implement the so-called hybrid mode.

This activity is staffed; the RTL coding is in progress and will be followed by a TRL-5 verification.

As CHERI implies many thousands of new code lines, it is yet to be defined if CVA6-CHERI will be upstreamed to CVA6 repo (with parameters to enable/disable it) or will he hosted in a separate repo.

COSMIC, a secure enclave design project, in partnership with Capabilities Limited, Cambridge Research and lowRISC, is considered, based on CHERI. A key challenge remains to bring together lowRISC's and core-v-verif verification environments.

New CI

The OpenHW staff is deploying a new CI environment as a complement to the current environment. Unifying could come in a second step.

RVB23 profile support

As a medium term objective, RVB23 compatibility could be supported by a CV64A6 configuration. This would be an intermediate step to RVA23 support. More about RVA23 below.

FPGA support

FPGA optimizations are triggered with FpgaEn and FpgaAlteraEn parameters. In addition, we strive to support one board for each FPGA vendor in CVA6 repo. Other boards can be supported in other repos.

We plan to add support for a PolarFire FPGA-based board, in addition to already supported boards based on Altera and AMD (formerly Xilinx).

Performance improvements of the CVA6 subsystem (corev-apu) for Genesys II (AMD-based) are also planned.

Single Source of Truth (SSoT)

As CVA6 supports many configurations (e.g. 32/64 bits, with/without MMU...), this progressive work will strive to align more tools in the flow (e.g. Spike configuration).

SAIL as a reference

Replacing Spike by Sail as a reference mode for verification and CI is considered.

SW support for CVA6

Zephyr OS

Zephyr on CV32A6 has floated around for some time. We plan to get it into an OpenHW SW repo.

Baremetal SDK

In addition to available Linux support.

Longer term

RVA23 profile support

Profiles are sets of extensions specified by RISC-V International that allow binary compatibility between different RISC-V cores.

The RVB23 profile defines a 64-bit application core (i.e. capable of booting rich OSes like Linux). In a nutshell, the RVA23 profile adds hypervisor privileges and vector processing to RVB23.

RVA23 gained momentum recently with several announcements of compatible cores and processors, as well as support by various Linux distributions.

We'd like a CV64A6 configuration that is RVA23-compatible.

This means adding the support of some missing extensions, revolving around:

• Memory accesses (PMA-based behaviour, misaligned accesses...)
• Cache controls
• Some "hint" extensions
• May-be operations
• Complements to floating point computation
• Hypervision (only Ssstateen missing)
• Complements to virtual memory (MMU)
• Vector support (including the connection with ARA)

A detailed analysis of gaps, with their actual RISC-V extension names, is on-going here.

For theses gaps, contributions are welcome to documentation, RTL design, CI (continuous integration) tests and ideally full verification.

Re-building the connection between ARA and CVA6

ARA is a vector processor built by the PULP team. Some work is needed to reconnect it with CVA6, possibly through the CV-X-IF coprocessor interface.

New CV64A6 core verification

Thales is contemplating the TRL-5 verification of a new CV64A6 configuration, including MMU and FPU.

Higher performances (and architectural revisit)

Some teams are performing microarchitectural work to get even more performance than the dual-issue superscalar CVA6 (nicknamed CVA6S+): more ways, out-of-order in more pipeline stages, other branch predictors...

These evolutions come along with architectural revisits in several stages, including around the scoreboard.

Safety extensions

The addition of extensions relevant to safety, e.g. Sscofpmf and Smcntrpmf, is considered.

Multi-core

The PULP team continues work on CV-TCCC/Culsans multi-core CVA6 (Cheshire 2-4-8 cores) and multi-real-time predictability for mixed-criticality systems.