Hi All,

My apologies for the long email up front. I hope people find this useful as well as a starting point for a broader discussion in how all these pieces fit together within RISC-V. There are implications to the decisions we make on this front. I’m cross posting to multiple lists for visibility. However, please direct all responses to the Profiles mailing list: https://lists.riscv.org/g/tech-profiles

I had volunteered to take a stab at describing the interaction between Profiles, Platforms, and OS-A SEE. As alluded to in the last list item, this particular write up will focus on OS-A (application level devices) and the A Profiles. In the current proposed specification, there can and will be Profiles defined for different target markets/applications. I hope I captured the intent of what has been said in meetings I have been in as well as what is written previously. Please provide any feedback where I am wrong in my understanding of the direction on these particular topics.

For Profiles, Platforms, and OS-A SEE, there is a dependency chain in that a Profile serves as the base dependency and OS-A SEE would depend on a Profile. A Platform, in turn, would depend on an OS-A SEE. The OS-A SEE is about providing specs for binary operating systems for booting, and a Platform is targeting particular manifestations of RISC-V implementation for a particular target market (e.g. server). Each will, or can, have different versions of their requirements over time. One can think of a tuple of those specification versions culminating in distinct requirements for both hardware and software implementations.

Profiles are expected to be a roadmap of the future support expected in both software and hardware. In the current Profile proposed specification, there are RVA20S64 and RVA22S64 variants. There’s also a proposal for a RVA23S64 Profile based on what is known today about in-flight extensions that are working through the system in 2022. Within the current proposed specification there are classifications of options/extensions: mandatory, supported optional, unsupported optional, and incompatible. Please read the proposed specification for details of the meanings. In short, the mandatory classification provides baseline expectations, and the incompatible classification sets an expectation that those options/extensions are *not* present.

The intention for a Profile is to “only describe ISA features, not a complete execution environment.” It should be noted, though maybe obvious to some, that a Profile is providing expectations for both the instruction stream that can be emitted from a compiler as well as other architectural state that does not have an impact on the compiler’s instruction emission (runtime handling within the OS, e.g.). The Profile is expecting that software can assume all those mandatory requirements exist, either in instruction support or runtime. 

The current cadence is a yearly Profile release that incorporates the latest ratified extensions. While extensions/options may start in a supported optional categorization, the trend is that there is a progression to a mandatory classification for the ratified extensions. (Note: RVA23S64 proposal does have a case where an extension moves in the opposite direction).

With the aforementioned yearly Profile release cadence setting the roadmap in direction, one needs to figure out how to intercept a particular release from both a software and hardware implementation standpoint. An OS-A SEE version would need to pick a Profile version. With that in mind there is now a default target for the compiler to choose instructions (mandatory instructions). For the kernel itself adhering to a particular Profile, it’s not clear if the kernel would refuse to boot if a particular mandatory option/extension was not available on a particular implementation. The hardware implementers can take up to 2-3 years to deliver a product. As such, there is inherently a lag in interception on the hardware front with a Profile. A RVA22 Profile may not see compatible hardware until 2024, e.g.. But for binary compatibility of Operating Systems, one needs to figure out how to align against a Profile version (by way of an OS-A SEE). An implication I observe from the progression of extensions/options going to mandatory is that there is a multiplier effect on the number of build targets. That can be solved by fixing on a particular Profile version in time (read: older), and dealing with runtime choices for newer extensions/options. That’s simplistic, but I’m not sure that’s necessarily the best path. We may need to decide what extensions we truly want to be mandatory as a fixed baseline. A biennial cadence was proposed for a OS-A SEE release, but as I noted there are implications from the transitive dependencies of the Profile progression. I do want to point out that the previous explanation was focusing on binary compatibility. If a user/operator can rebuild their software, they certainly can target newer Profiles with the knowledge their particular piece of hardware supports it.

In short, we have multiple moving trains that we need to align the various specifications with the right version to ensure it fosters the best possible outcome for the RISC-V ecosystem. There are implications for hardware implementers bringing a product to market as well as software vendors who are bringing products to market too.

Thanks for taking the time to read and digest. I hope it produces a fruitful discussion that allows us to come up with the best plan that achieves the goals of hardware implementers, software implementers, and users.

-Aaron