What is a profile and why it matters to RISC-V success
RISC-V initial base ISAs (RV32I / RV64I) have been extended with numerous extensions (C, F, D, V to name but a few). Those new extensions introduced new instructions and non-instruction specifications to address numerous challenges. RISC-V creators wanted an ISA which could be easily extended and parameterized to fit specific needs, it was designed as multiple modules from which implementers could pick and choose what suited their targets and constraints best. The number of extensions is constrained by the size of the opcode space but since RISC-V creators and the community have made great effort to keep opcodes as orthogonal as possible, there is a large space of possible extensions. Some extensions, which are not intended to be used together, may even make use of the same opcodes (e.g. Zcmp and Zcd).
Eventually we get a large number of extensions (still growing), not necessarily intended to be compatible with one another and addressing different needs. One issue which can arise from this is fragmentation: each implementer selecting a different sets of extensions, this can make developing compatible and efficient software over a wide range of implementations an ordeal.
To prevent too much fragmentation and ensure software developers stay sane, RISC-V profiles were introduced. A profile is simply a set of mandatory extensions and a limited list of optional extensions. It is intended to answer a specific need (e.g. ISA and non-ISA specifications for application class processors) and help the development of a strong ecosystem.
Multiple versions of profiles have already been released: a first set in 2020 with RVI20 and RVA20, and a second set in 2022 with RVA22.
Note: RV profiles are labelled with a year, a mode (U: user-mode, S: supervisor-mode) and a base ISA XLEN. So far, in the application profile family, only 64-bit profiles have been released or are announced.
At the end of 2023 RISC-V International Association (RVIA) will introduce a new set of profiles labelled RVA23. Those profiles might be very important for RISC-V growth: as they define what an application class processor should support in multiple execution modes. Application processors are general purpose processors supporting rich OSes and application stacks. RISC-V application profile family exclude lower end chips, even if they run a rich OS: the family is dedicated for higher-end processors with high performance requirements and installed competition. They are a key milestone for RISC-V to reach (beyond the microcontroller and control processor spaces) to demonstrate it values in building a modern computing ecosystem able to rival x86 and ARM.
Note: RVIA will release new profiles regularly (not more than once a year)but intends to distinguish between major releases and minor release. RVA23 is intended to be a major release.
Thanks for reading Fprox’s Substack! If you like this post, consider subscribing for free to receive new posts and support my work.
RVA23U64 profiles novelties
There are two new profiles as part of RVA23: RVA23U (RVA23U64) for user-mode and RVA23S (RVA23S64) for supervisor-mode. In this post we focus on the user-mode profile: RVA23U64. Let’s review the novelties (new extensions) mandated by RVA23U64 and the new options listed.
extensions in RVA23U64 profile
New mandatory extension: Vector
RISC-V vector extension, V, which was optional in RVA22, becomes mandatory. The vector extension was ratified in 2021 and is a key step for RISC-V performance in application class processors. It is the main way for a RISC-V processor to exploit data level parallelism (since no SIMD extension has been ratified yet).
Zvfhmin: RVA23U64 will now mandate a minimum support for vector half precision operations (only widening and narrowing conversions from/to half precision elements)
Zihintntl: this extension defines a small number of non-temporal locality hints for the memory hierarchy
Zcb: one of the Zc* compressed instruction extensions will become mandatory with RVA23. It was presented in this post:
Zfa: additional floating-point operations, load FP immediate, comparisons compatible with IEEE-754 2019 standard definition and comparisons with no exceptions, FP round-to-integer operations and a modular convert-to-integer dedicated to accelerating Javascript Number support (Zfa specification is accessible in chapter 25 of the latest RISC-V unprivileged ISA specification build).
Zawrs: wait on reservation set (efficient reservation set wait with or without timeout)
Zjpm: pointer masking extension (allowing storage of tag information in pointers’ MSB by mandating the MMU to ignore them)
New optional extensions: Vector Cryptography
RVA23 will be the first profile defined after the (future) ratification of the vector cryptography extensions and two subsets should be defined as optional in the new profile: Zvkn (NIST Algorithm suite) and Zvks (Shang-Mi Algorithm suite). Both extensions contains Zvkb (vector bitmanip extension), besides their respective cipher and hash functions.
The vector cryptography extensions were surveyed here:
New optional extensions: floating-point, half and BF16
Extended support for half-precision is allowed as a supported option in RVA23 with Zfh (scalar half-precision operations) and Zvfh (vector half-precision operations) being available on top of the mandatory support for scalar and vector half-precision conversions.
Note: Zfh was already an option in RVA22.
Another new floating-point format appears with RVA23: BF16 (Brain Float 16). This format is a truncated version of the single precision binary32 / fp32 format since it has the same exponent and sign fields length and a 8-bit significand (including implicit digit) versus the 24-bit of standard single precision. It is mostly used in machine learning. The profile will accept as options:
scalar conversions and moves with the extension Zfbfmin
vector conversions and moves with Zvfbfmin
vector widening multiply and multiply-add with Zvfbfwma
Note: On the scalar side, since it is 16-bit wide, the BF16 format will reused the half precision load flh and store fsh instructions.
Conclusion
2023 RISC-V Application profiles are increasing the performance requirements over RVA22: making the vector extension mandatory will ensure that implementations offer a high level of data parallel performance while ensuring the software ecosystem is available to support it. The apparition of 2 vector cryptography extensions as optional (with the possibility for them to become mandatory in RVA24) goes in the same direction: making sure standard implementations provide a minimum level of performance for standard workloads (e.g. TLS stack) through ISA requirements. Although ISA requirement is not a direct requirement for performance, it will make sure the software ecosystem supports the newly listed extensions and make it worth it for RISC-V vendors to support them efficiently while sharing the burden of software ecosystem support.
Thank you to Mark H. and Rafael S. for reaching out and correct a few inaccuracies in the first version of this post:
In RVA, A is the profile family (not profile type): description and figure have been updated
I am also going to prepare a more general post on RISC-V profiles (not focused on any profile in particular as this post) to clarify the concept (thanks to information provided by Mark H.).
