About

• Version: 3.4

• Creation date: 2020-08-09

• One-line description: Rules for profiles

• Author(s): Mark I Himelstein

Nomenclature

Organization acronyms can be found in the organization slide doc here.

“RVI” means the RISC-V International

“Architecture” means the RISC-V architectural specifications include the privileged, unprivileged ISAs and their extensions.

“Profiles” refers to a base ISA and one or more extensions that are specified as a group (see profiles & platforms TS) so that applications can be compiled once and run on different implementations and get the same results. Similarly for Operating Systems and Non-U-mode code. Architecture Profiles have required, optional, and unsupported extensions and will list all ratified extensions in one of those 3 groups. Architecture Profiles have types and at this time there are 2 types : application (“A”), microcontroller (“M”) . TSC reserves the right to add other letters to be defined later. We intend there to be a very small number of types.

“Profile String” refers to the string that specifies the Architecture Profile, version year, and optional width. RV[TYPE][2-DIGIT-YEAR][Optional_WIDTH]. See the definition of Architecture Profile for the field values.

“Application” (A) Architecture Profile refers to the extension targeted for a rich Application environment with a multi-user, multi-process operating system.

“Microcontroller” (M) Architecture Profile refers to a simple microcontroller without support of virtual memory, which are likely to either run bare metal applications or a simple RTOS.

“Required” extensions in a collection must be implemented to be compliant with the Architectural Profile.

“Optional” extensions in an Architecture Profile may optionally be implemented in a collection but if they are present (known by discovery) and enabled, then software for this Architecture Profile is expected to handle the extension for purposes of context switching. Portable code cannot rely on optional extensions being present. Two optional extensions may be incompatible with each other and must be well documented.

“Unsupported” extensions in a collection may be incompatible with the required and optional extensions or may require the implementers to develop and maintain all mode’s software in order to use the extension. Unsupported extensions may be, for example, extensions that are meant for typical use in another collection type like using fast interrupts which are targeted at the microcontroller type in the application collection type.

“Incompatible” extensions are not possible given the required and optional extensions. For example Zfinx will likely be optional in RVM but incompatible with RVA because the floating point instructions use the separate floating point registers.

Background

We need to define Profiles and how they work. (Note that profiles were called collections for a short period of time and the name was changed to match well known industry standards). Using the year we are beginning is meant so that the profile does not sound antiquated the moment it is released and since it is on the cusp of the year it could have gone either way.

Details

1. Profiles are defined and approved by the TSC.

2. TSC should publish the updated roadmap by April 1 of each year, using the previous year’s  December Summit as a way to get community input and feedback. The roadmap shall be for at least 3 years into the future so we can plan adequate runway for long lead time extensions.

3. TSC will run a quarterly detailed review with the chairs of the TGs and TSs developing extensions.

4. While groups (TGs or TSs) can launch discussions and groundwork about any topic or instructions, they should only formally develop specifications that are in the roadmap and in their charter. Exceptions should go to TSC before the group creation process begins. Groups can ask TSC to amend their charter to include extensions beyond their current charter.

5. Architecture Profile strings are of the form RV[TYPE][2-DIGIT-YEAR][Optional _WIDTH]. Examples include: RVA20, RVM22, RVA22_64, RVS24_32. If no width is specified, all ratified widths as of that year are included.

6. A profile must contain a complete list of all ratified extensions as of November 15 and be grouped into these buckets: required, optional, unsupported, and incompatible.

7. Architecture Profile definitions must be completed by November 15 of each year and become official on December 31 of that year (and the next year is in the name). Only ratified extensions by November 15 may be included. The last two digits of the year are used in the Collection string. Each extension must make sure the ecosystem integration occurs and is upstreamed before ratification. 

8. The profile for 2020 (e.g. RVA20) contains the extensions ratified in 2019, the profile for 2022 (e.g. RVA22) contains the extensions ratified in 2021.

9. Architecture Profiles may skip years.  Years 2032, 2064, 2128 will be skipped to avoid confusion with base ISA address widths.

10. If you have released a product before the profile is approved or the definition of done items are incomplete for extensions within a profile (like the formal model and the architectural tests), then implementers may test with the basic I extension tests (which are complete) and say they are RVI20 compatible. This is a release valve for a period of time when the profile and accompanying items are not complete. Members may upgrade to other profile compatibility when the profile and its items are complete and they pass the tests.

11. An implementer can be compatible with the RVI20 profile (grandfather mechanism) and still have non-conforming extensions if those extensions don’t conflict in  any way with required or optional standard extensions.

Exceptions

Profile naming and versioning exceptions must be approved by the TSC.

Version History