From: Luke Kenneth Casson Leighton Date: Thu, 8 Sep 2022 14:38:22 +0000 (+0100) Subject: rename RFC to ls001 X-Git-Tag: opf_rfc_ls005_v1~623 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ab1fc736ae02f25920278512558f8ae47a056657;p=libreriscv.git rename RFC to ls001 --- diff --git a/openpower/sv/rfc/001.mdwn b/openpower/sv/rfc/001.mdwn deleted file mode 100644 index 7e841b516..000000000 --- a/openpower/sv/rfc/001.mdwn +++ /dev/null @@ -1,72 +0,0 @@ -[[!tag opf_rfc]] - -# OpenPOWER Foundation External RFC LS001 - -Links - -* -* -* -* -* -* -* -* -* -* - -# Introduction to Simple-V - -This proposal is to extend the Power ISA with an Abstract RISC-Paradigm -Vectorisation Concept that may be applied to **all and any** suitable -Scalar instructions, present and future, in the Scalar Power ISA. -**It is not a Vector ISA and does not add Vector opcodes of any kind**. -A variant of Simple-V was originally invented in 1994 by Peter Hsu -(Architect of the MIPS R8000) but was dropped as MIPS did not have an -Out-of-Order Microarchitecture. - -Simple-V is designed for Embedded Scenarios right the way through -Audio/Visual DSPs to 3D GPUs and Supercomputing. As it does **not** -add actual Vector Instructions, relying solely and exclusively on the -**Scalar** ISA, it is **Scalar** instructions that need to be added -to the **Scalar** Power ISA before Simple-V may orthogonally Vectorise -them. - -Therefore because the goal of RED Semiconductor Ltd, an OpenPOWER Stakeholder, -is to bring to market mass-volume general-purpose compute processors that -are competitive in the 3D GPU Audio Visual DSP EDGE IoT markets, Simple-V -has to be accompanied by corresponding **Scalar** instructions that bring -the **Scalar** Power ISA up-to-date. These include IEEE754 Transcendentals -AV cryptographic Biginteger and bitmanipulation operations that ARM Intel -AMD and many other ISAs have been adding over the past 12 years. - -*Thus it becomes necesary to consider the Architectural Resource Allocation of not just -Simple-V but the 80-100 Scalar instructions all at the same time*. - -It is also critical to note that Simple-V **does not modify the Scalar Power ISA -in any way**. There is one sole semi-exception to that (Vectorised Branch Conditional) -in order to provide the usual capability present in every Commercial 3D GPU ISA. - -# Compliancy Levels - -Simple-V has been subdivided into levels akin to the Power ISA Compliancy Levels. -For now Let us call them "SV Compliancy Levels" to distinguish the two. The reason for -the SV Compliancy Levels is the same as for the Power ISA Compliancy Levels (SFFS, SFS): -to not overburden implementors with features that they do not need. -*There is no dependence between the two types of Compliancy Levels* - -The resources below therefore are not all required for all SV Compliancy Levels but -they are all required - -# Simple-V Resources - -* No new Interrupt types are required. -* Register numbers are extended to 128 (including CR Fields). - A future version may extend to 256 or beyond [^extend] -* 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO) -* Another 24-bit (a second 2-bit XO) is needed for a planned future encoding, currently - named "SVP64-Single" [^likeext001] -* A third 24-bits (third 2-bit XO) is strongly recommended to be **reserved** - -[^extend]: Prefix opcode space **must** be reserved in advance to to so, in order to avoid the catastrophic binary-incompatibility mistake made by RISC-V RVV and ARM SVE/2 -[^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact it still embeds v3.0 Scalar operations. diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn new file mode 100644 index 000000000..7e841b516 --- /dev/null +++ b/openpower/sv/rfc/ls001.mdwn @@ -0,0 +1,72 @@ +[[!tag opf_rfc]] + +# OpenPOWER Foundation External RFC LS001 + +Links + +* +* +* +* +* +* +* +* +* +* + +# Introduction to Simple-V + +This proposal is to extend the Power ISA with an Abstract RISC-Paradigm +Vectorisation Concept that may be applied to **all and any** suitable +Scalar instructions, present and future, in the Scalar Power ISA. +**It is not a Vector ISA and does not add Vector opcodes of any kind**. +A variant of Simple-V was originally invented in 1994 by Peter Hsu +(Architect of the MIPS R8000) but was dropped as MIPS did not have an +Out-of-Order Microarchitecture. + +Simple-V is designed for Embedded Scenarios right the way through +Audio/Visual DSPs to 3D GPUs and Supercomputing. As it does **not** +add actual Vector Instructions, relying solely and exclusively on the +**Scalar** ISA, it is **Scalar** instructions that need to be added +to the **Scalar** Power ISA before Simple-V may orthogonally Vectorise +them. + +Therefore because the goal of RED Semiconductor Ltd, an OpenPOWER Stakeholder, +is to bring to market mass-volume general-purpose compute processors that +are competitive in the 3D GPU Audio Visual DSP EDGE IoT markets, Simple-V +has to be accompanied by corresponding **Scalar** instructions that bring +the **Scalar** Power ISA up-to-date. These include IEEE754 Transcendentals +AV cryptographic Biginteger and bitmanipulation operations that ARM Intel +AMD and many other ISAs have been adding over the past 12 years. + +*Thus it becomes necesary to consider the Architectural Resource Allocation of not just +Simple-V but the 80-100 Scalar instructions all at the same time*. + +It is also critical to note that Simple-V **does not modify the Scalar Power ISA +in any way**. There is one sole semi-exception to that (Vectorised Branch Conditional) +in order to provide the usual capability present in every Commercial 3D GPU ISA. + +# Compliancy Levels + +Simple-V has been subdivided into levels akin to the Power ISA Compliancy Levels. +For now Let us call them "SV Compliancy Levels" to distinguish the two. The reason for +the SV Compliancy Levels is the same as for the Power ISA Compliancy Levels (SFFS, SFS): +to not overburden implementors with features that they do not need. +*There is no dependence between the two types of Compliancy Levels* + +The resources below therefore are not all required for all SV Compliancy Levels but +they are all required + +# Simple-V Resources + +* No new Interrupt types are required. +* Register numbers are extended to 128 (including CR Fields). + A future version may extend to 256 or beyond [^extend] +* 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO) +* Another 24-bit (a second 2-bit XO) is needed for a planned future encoding, currently + named "SVP64-Single" [^likeext001] +* A third 24-bits (third 2-bit XO) is strongly recommended to be **reserved** + +[^extend]: Prefix opcode space **must** be reserved in advance to to so, in order to avoid the catastrophic binary-incompatibility mistake made by RISC-V RVV and ARM SVE/2 +[^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact it still embeds v3.0 Scalar operations.