(no commit message)

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index 6e57c3b1ce6e2b5c70716b850d6bb9eea035f052..4272e05f4a0efd477d34fb2f634807d2869d0dc3 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -6,6 +6,11 @@
 
 <https://bugs.libre-soc.org/show_bug.cgi?id=213>
 
+SV is designed as a Vector ISA for Hybrid 3D CPU GPU VPU workloads.
+As such it brings features normally only found in Cray Supercomputers
+and GPUs, but keeps strictly to a *Simple* principle of leveraging
+a *Scalar* ISA, exclisively using "Prefixing". **Not one single actual
+explicit Vector opcode exists in SV, at all**.
 Fundamental design principles:
 
 * Simplicity of introduction and implementation on the existing OpenPOWER ISA
@@ -20,7 +25,11 @@ dependency hazards, allowing high performance superscalar microarchitectures to
 Advantages of these design principles:
 
 * It is therefore easy to create a first (and sometimes only) implementation as literally a for-loop in hardware, simulators, and compilers.
-* More complex HDL can be done by repeating existing scalar ALUs and pipelines as blocks.
+* Hardware Architects may understand and implement SV as being an
+  extra pipeline stage, inserted between decode and issue, that is
+  a simple for-loop issuing element-level sub-instructions.
+* More complex HDL can be done by repeating existing scalar ALUs and 
+  pipelines as blocks and leveraging existing Multi-Issue Infrastructure
 * As (mostly) a high-level "context" that does not (significantly) deviate from scalar OpenPOWER ISA and, in its purest form being "a for loop around scalar instructions", it is minimally-disruptive and consequently stands a reasonable chance of broad community adoption and acceptance
 * Completely wipes not just SIMD opcode proliferation off the
   map (SIMD is O(N^6) opcode proliferation)