Important

This page is a draft, currently reviewed by the CVA6 team.

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

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.

Addressing new issues

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

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 instuction 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.

DCLS implementations

Two DCLS (dual-core lockstep) projects were conducted, unknownly of each other. The teams are now cooperating to converge.

• 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.

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.

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 environments. 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.

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.

New CV64A6 core verification and certification & SAIL as a reference

Thales is contemplating the verification of a new CV64A6 configuration, incluing MMU and FPU. Key discussion points include the replacing of Spike by Sail as a reference mode for verification and CI. Certification is also considered in addition to TRL-5 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.

Higher performances

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...

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.