diff --git a/RVA-profile-overview.adoc b/RVA-profile-overview.adoc index 6aa0aee..e499b8d 100644 --- a/RVA-profile-overview.adoc +++ b/RVA-profile-overview.adoc @@ -65,125 +65,4 @@ of profiles. :sectnums: -== RVA Profiles Rationale - -RISC-V was designed to provide a highly modular and extensible -instruction set and includes a large and growing set of standard -extensions, where each standard extension is a bundle of -instruction-set features. This is no different than other industry -ISAs that continue to add new ISA features. Unlike other ISAs, -however, RISC-V has a broad set of contributors and implementers, and -also allows users to add their own custom extensions. For some deep -embedded markets, highly customized processor configurations are -desirable for efficiency, and all software is compiled, ported, and/or -developed in-house by the same organization for that specific -processor configuration. However, for other markets that expect a -substantial fraction of software to be delivered to end-customers in -binary form, compatibility across multiple implementations from -different RISC-V vendors is required. - -The RVIA ISA extension ratification process ensures that all processor -vendors have agreed to the specification of a standard extension if -present. However, by themselves, the ISA extension specifications do -not guarantee that a certain set of standard extensions will be -present in all implementations. - -*The primary goal of the RVA profiles is to align processor vendors -targeting binary software markets, so software can rely on the -existence of a certain set of ISA features in a particular generation -of RISC-V implementations.* - -Alignment is not only for compatibility, but also to ensure RISC-V is -competitive in these markets. The binary app markets are also -generally those with the most competitive performance requirements -(e.g., mobile, client, server). RVIA cannot mandate the ISA features -that a RISC-V binary software ecosystem should use, as each ecosystem -will typically select the lowest-common denominator they empirically -observe in the deployed devices in their target markets. But RVIA can -align hardware vendors to support a common set of features in each -generation through the RVA profiles. Without proactive alignment -through RVA profiles, RISC-V will be uncompetitive, as even if a -particular vendor implements a certain feature, if other vendors do -not, then binary distributions will not generally use that feature and -all implementations will suffer. While certain features may be -discoverable, and alternate code provided in case of presence/absence -of a feature, the added cost to support such options is only justified -for certain limited cases, and binary app markets will not support a -wide range of optional features, particularly for the nascent RISC-V -binary app ecosystems. - -To maintain alignment and increase RISC-V competitiveness over time, -the mandatory set of extensions must increase over time in successive -generations of RVA profile. (RVA profiles may eventually have to -deprecate previously mandatory instructions, but that is unlikely in -the near future.) Note that the RISC-V ISA will continue to evolve, -regardless of whether a given software ecosystem settles on a certain -generation of profile as the baseline for their ecosystem for many -years or even decades. There are many existing binary software -ecosystems, which will migrate to RISC-V and evolve at different rates, -and more new ones will doubtless be created over the hopefully long -lifetime of RISC-V. High-performance application processors require -considerable investment, and no single binary app ecosystem can -justify the development costs of these processors, especially for -RISC-V in its early stage of adoption. - -While the heart of the profile is the set of mandatory extensions, -there are several kinds of optional extension that serve important -roles in the profile. - -The first kind are _localized_ _options_, whose presence or use -necessarily differs along geo-political and/or jurisdictional -boundaries, with crypto being the obvious example. These will always -be optional. At least for crypto, discovery has been found to be -perfectly acceptable to handle this optionality on other -architectures, as the use of the extensions is well contained in -certain libraries. - -The second kind of optional extension is a _development_ _option_, -which represents a new ISA extension in an early part of its lifecycle -but which is intended to become mandatory in a later generation of the -RVA profile. Processor vendors and software toolchain providers will -have varying development schedules, and providing an optional phase in -a new extension's lifecycle provides some flexibility while -maintaining overall alignment, and is particularly appropriate when -hardware or software development for the extension is complex. -Denoting an extension as a _development_ _option_ signals to the -community that development should be prioritized for such extensions -as they will become mandatory. - -The third kind of optional extension are _expansion_ _options_, which -are those that may have a large implementation cost but are not always -needed in a particular platform, and which can be readily handled by -discovery. These are also intended to remain available as expansion -options in future versions of the profile. Several supervisor-mode -extensions fall into this category, e.g., Sv57, which has a notable -PPA impact over Sv48 and is not needed on smaller platforms. Some -unprivileged extensions that may fall into this category are possible -future matrix extensions. These have large implementation costs, and -use of matrix instructions can be readily supported with discovery and -alternate math libraries. - -The fourth kind of optional extensions are _transitory_ _options_, -where it is not clear if the extension will change to a mandatory, -localized, or expansion option, or be possibly dropped over time. -Cryptography provides some examples where earlier cyphers have been -broken and are now deprecated. RVIA used this mechanism to enable -scalar crypto until vector crypto was ready. Software security -features may also be in this category, with examples of deprecated -security features occuring in other architectures. As another -example, the recent avalanche of new numeric datatypes for AI/ML may -eventually subside with a few survivors actually being used longer -term. Denoting an option as transitory signals to the community that -this extension may be removed in a future profile, though the time -scale may span many years. - -Except for the localized options, it could be argued that other three -kinds of option could be left out of profiles. Binary distributions -of applications willing to invest in discovery can use an optional -extension, and customers compiling their own applications can take -advantage of the feature on a particular implementation, even when -that system is mostly running binary distributions that ignore the new -extension. However, there is value in providing guidance to align -hardware vendors and software developers around what extensions are -worth implementing and worth discovering, by designating only a few -important features as profile options and limiting their granularity. +include::rva-profile-overview-body.adoc[] diff --git a/rva-profile-overview-body.adoc b/rva-profile-overview-body.adoc new file mode 100644 index 0000000..0ed9d71 --- /dev/null +++ b/rva-profile-overview-body.adoc @@ -0,0 +1,122 @@ +== RVA Profiles Rationale + +RISC-V was designed to provide a highly modular and extensible +instruction set and includes a large and growing set of standard +extensions, where each standard extension is a bundle of +instruction-set features. This is no different than other industry +ISAs that continue to add new ISA features. Unlike other ISAs, +however, RISC-V has a broad set of contributors and implementers, and +also allows users to add their own custom extensions. For some deep +embedded markets, highly customized processor configurations are +desirable for efficiency, and all software is compiled, ported, and/or +developed in-house by the same organization for that specific +processor configuration. However, for other markets that expect a +substantial fraction of software to be delivered to end-customers in +binary form, compatibility across multiple implementations from +different RISC-V vendors is required. + +The RVIA ISA extension ratification process ensures that all processor +vendors have agreed to the specification of a standard extension if +present. However, by themselves, the ISA extension specifications do +not guarantee that a certain set of standard extensions will be +present in all implementations. + +*The primary goal of the RVA profiles is to align processor vendors +targeting binary software markets, so software can rely on the +existence of a certain set of ISA features in a particular generation +of RISC-V implementations.* + +Alignment is not only for compatibility, but also to ensure RISC-V is +competitive in these markets. The binary app markets are also +generally those with the most competitive performance requirements +(e.g., mobile, client, server). RVIA cannot mandate the ISA features +that a RISC-V binary software ecosystem should use, as each ecosystem +will typically select the lowest-common denominator they empirically +observe in the deployed devices in their target markets. But RVIA can +align hardware vendors to support a common set of features in each +generation through the RVA profiles. Without proactive alignment +through RVA profiles, RISC-V will be uncompetitive, as even if a +particular vendor implements a certain feature, if other vendors do +not, then binary distributions will not generally use that feature and +all implementations will suffer. While certain features may be +discoverable, and alternate code provided in case of presence/absence +of a feature, the added cost to support such options is only justified +for certain limited cases, and binary app markets will not support a +wide range of optional features, particularly for the nascent RISC-V +binary app ecosystems. + +To maintain alignment and increase RISC-V competitiveness over time, +the mandatory set of extensions must increase over time in successive +generations of RVA profile. (RVA profiles may eventually have to +deprecate previously mandatory instructions, but that is unlikely in +the near future.) Note that the RISC-V ISA will continue to evolve, +regardless of whether a given software ecosystem settles on a certain +generation of profile as the baseline for their ecosystem for many +years or even decades. There are many existing binary software +ecosystems, which will migrate to RISC-V and evolve at different rates, +and more new ones will doubtless be created over the hopefully long +lifetime of RISC-V. High-performance application processors require +considerable investment, and no single binary app ecosystem can +justify the development costs of these processors, especially for +RISC-V in its early stage of adoption. + +While the heart of the profile is the set of mandatory extensions, +there are several kinds of optional extension that serve important +roles in the profile. + +The first kind are _localized_ _options_, whose presence or use +necessarily differs along geo-political and/or jurisdictional +boundaries, with crypto being the obvious example. These will always +be optional. At least for crypto, discovery has been found to be +perfectly acceptable to handle this optionality on other +architectures, as the use of the extensions is well contained in +certain libraries. + +The second kind of optional extension is a _development_ _option_, +which represents a new ISA extension in an early part of its lifecycle +but which is intended to become mandatory in a later generation of the +RVA profile. Processor vendors and software toolchain providers will +have varying development schedules, and providing an optional phase in +a new extension's lifecycle provides some flexibility while +maintaining overall alignment, and is particularly appropriate when +hardware or software development for the extension is complex. +Denoting an extension as a _development_ _option_ signals to the +community that development should be prioritized for such extensions +as they will become mandatory. + +The third kind of optional extension are _expansion_ _options_, which +are those that may have a large implementation cost but are not always +needed in a particular platform, and which can be readily handled by +discovery. These are also intended to remain available as expansion +options in future versions of the profile. Several supervisor-mode +extensions fall into this category, e.g., Sv57, which has a notable +PPA impact over Sv48 and is not needed on smaller platforms. Some +unprivileged extensions that may fall into this category are possible +future matrix extensions. These have large implementation costs, and +use of matrix instructions can be readily supported with discovery and +alternate math libraries. + +The fourth kind of optional extensions are _transitory_ _options_, +where it is not clear if the extension will change to a mandatory, +localized, or expansion option, or be possibly dropped over time. +Cryptography provides some examples where earlier cyphers have been +broken and are now deprecated. RVIA used this mechanism to enable +scalar crypto until vector crypto was ready. Software security +features may also be in this category, with examples of deprecated +security features occuring in other architectures. As another +example, the recent avalanche of new numeric datatypes for AI/ML may +eventually subside with a few survivors actually being used longer +term. Denoting an option as transitory signals to the community that +this extension may be removed in a future profile, though the time +scale may span many years. + +Except for the localized options, it could be argued that other three +kinds of option could be left out of profiles. Binary distributions +of applications willing to invest in discovery can use an optional +extension, and customers compiling their own applications can take +advantage of the feature on a particular implementation, even when +that system is mostly running binary distributions that ignore the new +extension. However, there is value in providing guidance to align +hardware vendors and software developers around what extensions are +worth implementing and worth discovering, by designating only a few +important features as profile options and limiting their granularity. diff --git a/rva23-profile.adoc b/rva23-profile.adoc index 179012d..f27ff3a 100644 --- a/rva23-profile.adoc +++ b/rva23-profile.adoc @@ -52,13 +52,7 @@ endif::[] Do not use for implementations. Assume everything can change. ==== -== Introduction - -This document captures the current proposal for the RVA23 profile -family. - -RVA23 is not intended to be a major release of the RISC-V Application -Processor Profiles. +include::rva-profile-overview-body.adoc[] == RVA23 Profiles