RISC-V Profiles
Defining sets of extensions for coherent ecosystems
We have recently published a post on RVA23U64, the new 64-bit user-model profile from the application class profile family.
This post, although generally well received, lacked some context and some details on RISC-V profiles. We will bridging this gap and covering some of those details in this new post: a deep dive into RISC-V profiles which are key for RVIA as stated in its March 2023 newsletter (https://riscv.org/blog/2023/03/risc-v-newsletter-march-2-2023/).
“Profiles are Our Highest Priority” (RVIA RISC-V Newsletter – March 2, 2023)
Let’s review some details about the profiles.
RISC-V resources on profiles
The main source of information for this post was RISC-V profile specification on github:
repository root https://github.com/riscv/riscv-profiles
profile specifications: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc (currently RVI20, RVA20, RVA22)
RVA23 profiles: https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc
There also exists a RISC-V profile spreadsheet listing details on content of existing profiles: google spreadsheet link.
For the lastest profile (RVA23, covered here) you can also check the extension status page: https://wiki.riscv.org/display/HOME/Specification+Status.
Profiles in a Nutshell
Profile specifications, as RISC-V extensions, are managed by RISC-V International Association (RVIA) organized around a set of committees, interest groups and task groups ...
In terms of specification, a profile is a set of:
a base ISA (RV32I / RV64I)
a group of mandatory extensions
a group of optional extensions
A profile belongs to a profile family . There exist currently two families: I for generic unprivileged instructions and A for application class processors. A profile is also labelled with a release year; each year, no more than one profile can be released for each family. A profile is also defined for a specific privilege mode: U for user-mode or S for supervisor mode.
Note: For each feature/extension, when necessary, a specific version is also listed (e.g. privilege architecture version 1.11 for RVA20S64).
Mandatory versus optional extensions
If the intent of a profile is to define a shared set of RISC-V extensions, what is the purpose of adding some combinatorial complexity by allowing a set of optional features ?
The goal seems to be to favour compatibility without being too restrictive: a limited group of optional extensions allows the software ecosystem to support some configurability while limiting its extent. It also allows the ecosystem to test some new features without mandating them in every single implementations, before later mandating them in a future version of the profile. It was the case for the vector V extension: optional in RVA22U64, it will become mandatory in RVA23U64.
Note: It is mandatory for ISA features in a ratified profile to also be ratified. This requirement clearly ensures that profiles only contains validated and accepted features and not on-going specification.
Profile families
Base unprivileged profile
Currently, there exists only a single version of RVI the base unpriviledge profile family: RVI20U. It has been declined into a 32-bit and a 64-bit variants. This profile is made of the base ISA, no mandatory extensions and the initial set of extensions (M, A, F, D, C, Zifenci, Zicntr, Zihpm). For more details on RVI20, you can consult the specification: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rvi20-profiles. This profile specifies “generic unprivileged execution environments”, which can be seen a a minimum base and key options to run a RISC-V program.
Application profile
The Application processor class profile is much thicker than RVI and for good reasons. This profile family aims at specifying which RISC-V support should be supported by advanced application processors targeting rich operating systems and their application stacks. This profile family has received the most effort with already two ratified iterations (RVA20 and RVA22) and one new iteration on-going (RVA23). RVA profiles only exist in 64-bit version and have a long list of mandatory extensions (all that is required for their OS/application stack targets) and always a small sets of options.
In 2023, 64-bit architectures have been pervasive for application class processors for quite some times already and it seems appropriate RISC-V would not go against that trend by also offering a more limited 32-bit RVA version.
Profile versions: Major and Minor
RVIA expects that profile versions will be used for at least 10 years, which means a lot of different profile versions may coexist. Furthermore, it is not required for implementers to chose the latest version of a profile family when developing a new product.
RVIA limits the frequency of publishing a new version of a profile family at once a year. But even this limited frequency can seem pretty high as it is expected that implementers will take between 12 and 48 months to design and productize complete implementations of a profile specification.
Having regular updates to a profile family has the advantage of making sure new features can be deployed rapidly, but in the world of microprocessor hardware this may also be a disadvantage: not letting time to the ecosystem to support new features and for customers to adapt (why adopt a given profile version if one with more feature is right around the corner ?).
To circumvent these possible shortcomings, RVIA distinguishes two types of profile version in the same profile family: major profiles and minor profiles. RVIA labels as major version a subset of the versions which are thought to be key milestone in the profile family roadmap, any other version will be a minor version.
Major and minor version is a recent concept for RISC-V profile. It was introduced officially in July 2022 (https://lists.riscv.org/g/tech-profiles/message/48). RVA20U64 (a.k.a. RV64GC) was retroactively dubbed “first major release”, RVA23 is expected to be the next one.
RVIA asks the software ecosystem to adopt major profiles (and not minor profiles). Those profiles can be seen as a way for implementer to provide advanced “official” features while ensuring a longer cycle for the full ecosystem.
Conclusion
One of the on-going challenge for RISC-V is to validate an implementation compatibility with a given profile. RVIA has existing and under-development test frameworks and sets of test to validate a RISC-V implementation. Gathered behind the label of Architecture Compatibility Test or ACT (rationale) they offer an official method to validate an implementation and ensure compatibility. They already support some of the extensions defined in the official profiles. The ACT and the various test frameworks will be covered in a future post.
Profiles simplify the RISC-V ecosystem by making sure hardware implementers and software developers roadmaps can intersect with an interface built around a rich set of extensions with a bounded amount of flexibility and designed to support well-defined categories of systems and applications. The number of RISC-V extensions will continue to grow and we will see new profile versions from the existing families in the coming years, and maybe new profile families !
Resources
RVI20, RVA20 and RVA22 specification https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc
RVA23 specification draft https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc