RVB profile: application class profile with options
Description of the second RISC-V profile family for application-class processors
This article describes a specification in draft state (not yet ratified), changes are possible, including significant ones.
A new RISC-V profile for application-class processors was recently1 introduced: RVB.
Note: for some explanation of what a profile is and how profiles are named you can read one of our previous posts on the subject:
As the existing RVA profile, RVB is a base RISC-V ISA and a collection of mandatory and optional extensions which targets application class processors (AP). Profiles organize RISC-V extensions into coherent sets, targeting well-defined classes of systems. AP are somewhat large and performant CPUs which are able to run complex application stacks. In this post we survey the RVB23 profile, note some of the difference with RVA and analyze why it was introduced.
The profile contains two parts: a user mode profile RVB23U64 and a system mode profile RVB23S64. Let us start by reviewing the user-mode part of the profile where some of the interesting differences with RVA lie.
RVB vs RVA: user mode
The following diagram presents the various extensions which constitute RVB23U64. The extensions are split between mandatory and optional sets with further discrimination between the set of extensions which have the same constraints as in RVA and the ones where RVA and RVB differ.
RVB23U64 shares the same base as RVA23U64: RV64I, they are both 64-bit ISAs.
Most of the mandatory extensions are common, except V, Zfhmin, Zvfhmin and Zjpm (Pointer masking extension). This seems to indicate a common goal between RVA and RVB with a few variations. These differences means
The removal of V from the mandatory set is interesting, and in that regard RVB23U64 looks similar to RVA22U64 (last year version of the RVA profile family). It is possible to build a CPU fully compatible with the profile without any support for RISC-V vector extension which may represent a substantial opportunity for area and power saving for markets which do not necessitate the full strength of vectors.
Zfhmin and Zvfhmin being optional make both scalar and vector supports for half precision floating-point completely optional (whereas a minimal support is mandatory in RVA23U64, both on the scalar side and the vector side).
When it comes to vector crypto, some interesting choices were made for RVB: it is possible to provide support for NIST or Shang-Mi suites with Zvbc rather than Zvkg. RVA mandates the latter by only allowing vector crypto to be enabled through Zvkng (NIST + Zvkg + …) or Zvksg (Shang-Mi + Zvkg + …).
This means that there are two options when it comes to implementing GCM acceleration for ciphers in RVB: either implementing Zvkg (direct acceleration with the instruction vghsh.vv implementing the elementary operation of GHASH) or Zvbc (indirect acceleration with the instructions vclmul* which can be used to implement the GHASH primitive). The specification mandates that at least one of the two must be implemented if either the NIST suite or the Shang-Mi suite are supported (it is not possible to only implement the cipher/hash without CLM/GHASH). In RVA23 Zvkg is mandatory if either Zvkn or Zvks are supported
RVB vs RVA: system mode
The following diagram presents the various extensions which constitute RVB23S64.
RVB23S64 has the same unprivileged options as RVA23U64 and thus inherits the higher unprivileged flexibility of the RVB family versus RVA.
RVB23S64 has the same privileged options as RVA23S64, including the mandatory required extensions when the hypervisor option H is selected.
They are less difference on the system side compared to the user side. This should allow processors implementing RVB to directly benefit from the systems developed for the RVA profile.
Intent behind RVB and conclusion
RVB is less prescriptive than RVA (for an overview of RVA23U64 you can refer to the this post): more unprivileged options are available, including some extensions which are mandatory for the newest profile of the RVA family. As seen on the section on RVB23U64, 4 options for RVB are mandatory for RVA23U64 and they are two options for crypto. The multiplication of the number of options will make writing software for the profile a bit more complex (more software required to accommodate all the legal combinations) or less performant (generic software implementation will not be able to rely on the most performant extensions when they are optional) but this align well with RVB purpose: giving more flexibility to companies that are ready to develop custom software for their RISC-V implementation. One could imagine that a base RVB ecosystem will develop (sharing the same basis as RVA) and then custom software will be developed on top by each CPU provider.
Is there a risk for RVB to be more successful than RVA in the target market segment of the latter (application class processors with standard ecosystem) ?
Future will tell, but the fact that the Vector extension is only optional for RVB vs RVA and that it offers more options makes RVA a better candidate for such ecosystem where implementations are willing to pay the price associated with the extension providing more performance (e.g the vector extension) and where software development of very large ecosystems can greatly benefit from reduced option sets.
If you wish to discuss any aspects of this post feel free to leave a comment or join the conversation on the subscriber chat:
Initial publication July 15th 2023: RVB23 is still in development state. It will certainly be frozen and reviewed publicly alongside the other 2023 profiles (RVA23 and RVM23) later in the year.
References
The initial draft was posted on May 10th 2023