(no commit message)

[libreriscv.git] / openpower / sv / rfc / ls005.mdwn

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
index a66b4234e42f5872f0245e9f0f98a90c558893bb..f19cf7fc5c9f9799e98135198ee9ed1e52883a35 100644 (file)
--- a/openpower/sv/rfc/ls005.mdwn
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -7,7 +7,6 @@
 **URLs**:
 
 * <https://libre-soc.org/openpower/sv/rfc/ls005/>
-* <https://bugs.libre-soc.org/show_bug.cgi?id=671>
 * <https://bugs.libre-soc.org/show_bug.cgi?id=663>
 * <https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=openpower/isa;hb=HEAD>
 * <https://git.openpower.foundation/isa/PowerISA/issues/104>
@@ -18,9 +17,7 @@
 
 **Date**: 22 Dec 2022
 
-**Target**: v3.2B
-
-**Source**: v3.0B
+**Target** v3.2B
 
 **Books and Section affected**:
 
@@ -31,12 +28,10 @@
 **Summary**
 
 ```
-    Exactly as is already done in RISC-V, convert the entire
-    use of 64-bit hard-coding to "XLEN".  Exactly as is in RISC-V,
-    options then include PowerISA-32, PowerISA-64 and PowerISA-128.
-    Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is
-    also floated, for Embedded, AI, Edge, Processing-in-Memory,
-    Distributed Computing and other purposes.
+    Exactly as is already done in RISC-V, convert the entire use of 64-bit hard-coding to "XLEN".
+    Exactly as is in RISC-V, options then include PowerISA-32, PowerISA-64 and PowerISA-128.
+    Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is also floated, for Embedded,
+    AI, Edge, Processing-in-Memory, Distributed Computing and other purposes.
 ```
 
 **Submitter**: Luke Leighton (Libre-SOC)
@@ -76,7 +71,6 @@ In this way, the limitations of what would otherwise restrict the usefulness
 of a severely-targetted application-specific processor may be overcome in
 order to make it still possible to (at reduced performance) still run
 general-purpose applications.
-
 AI application-specific processing or other Processing-In-Memory or other
 specialist design therefore may for example focus a balance
 of raw computing power heavily onto 8-bit or 16-bit computation, but still
@@ -85,6 +79,11 @@ this with the more "normal" approach of creating heavily-focussed
 specialist "AI" Engines incapable of Turing-completeness and the benefits
 are clear.
 
+Note: SVP64 **requires** this change as a 100% critical dependency.
+SIMD back-end ALUs process Vectors of "Elements" at 8, 16 and 32-bit (and
+64-bit), read from, processed, and returned to, the standard **Scalar**
+Register Files, with byte-level write-enable lines.
+
 **Changes**
 
 For all pseudocode right across the board in all Scalar operations, replace
@@ -96,8 +95,19 @@ Definitions of the Register File(s) for GPR and FPR are then changed to be
 "XLEN" wide.  However, for Embedded purposes (XLEN=32/16/8), an SPR controls
 whether (and how many) sequentially-grouped registers are taken together to
 create 16-bit, 32-bit and 64-bit addresses (depending on application need).
+GPR is obvious, FPR is quirky.  SVP64 redefines FP ops (those not ending in "s")
+to be "full width" and all ops ending in "s" to be "half of
+the full width".
+
+* XLEN=64 keeps FPR "full width" exactly as presently defined, and
+  "half width" exactly as presently defined.
+* XLEN=32 overrides FPR "full width" operations to
+  full BFP32, and "half width" to be "BFP16 stored in an BFP32"
+* XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves
+  "half width" RESERVED (there is no IEEE version of [FP8](https://web.archive.org/web/20221223085833/https://wccftech.com/nvidia-intel-arm-bet-their-ai-future-on-fp8-whitepaper-for-8-bit-fp-published/)).
+* XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves
+  "half width" RESERVED. 
 
 ----------------
 
 \newpage{}
-