+++ /dev/null
-[[!tag opf_rfc]]
-
-# OpenPOWER Foundation External RFC LS001
-
-Links
-
-* <https://libre-soc.org/openpower/sv/>
-* <https://libre-soc.org/openpower/sv/compliancy_levels/>
-* <https://libre-soc.org/openpower/transcendentals/>
-* <https://libre-soc.org/openpower/sv/bitmanip>
-* <https://libre-soc.org/openpower/sv/int_fp_mv>
-* <https://libre-soc.org/openpower/sv/fclass/>
-* <https://libre-soc.org/openpower/sv/av_opcodes/>
-* <https://libre-soc.org/openpower/sv/fcvt/>
-* <https://libre-soc.org/openpower/sv/cr_int_predication/>
-* <https://libre-soc.org/openpower/sv/biginteger/>
-
-# 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.
--- /dev/null
+[[!tag opf_rfc]]
+
+# OpenPOWER Foundation External RFC LS001
+
+Links
+
+* <https://libre-soc.org/openpower/sv/>
+* <https://libre-soc.org/openpower/sv/compliancy_levels/>
+* <https://libre-soc.org/openpower/transcendentals/>
+* <https://libre-soc.org/openpower/sv/bitmanip>
+* <https://libre-soc.org/openpower/sv/int_fp_mv>
+* <https://libre-soc.org/openpower/sv/fclass/>
+* <https://libre-soc.org/openpower/sv/av_opcodes/>
+* <https://libre-soc.org/openpower/sv/fcvt/>
+* <https://libre-soc.org/openpower/sv/cr_int_predication/>
+* <https://libre-soc.org/openpower/sv/biginteger/>
+
+# 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.
projects / libreriscv.git / commitdiff