(no commit message)

diff --git a/openpower/sv/SimpleV_rationale.mdwn b/openpower/sv/SimpleV_rationale.mdwn
index 97954ed1f4263c9b5864d2cbfd387bfc0a2aa4a4..1422cbbbd8c464ef91f75feb9408c611c4ed15c0 100644 (file)
--- a/openpower/sv/SimpleV_rationale.mdwn
+++ b/openpower/sv/SimpleV_rationale.mdwn
@@ -804,38 +804,6 @@ Intel, ARM, MIPS, Power ISA and RISC-V have all already said "yes" on that,
 for several decades, and advanced programmers are comfortable with the
 practice.
 
-**Roadmap summary of Advanced SVP64**
-
-The future direction for SVP64, then, is:
-
-* To overcome its current limitation of REMAP Schedules being
-  restricted to Register Files, leveraging the Snitch-style
-  register interception "tagging" technique.
-* To adopt ZOLC and merge REMAP Schedules into ZOLC
-* To bring OpenCAPI Memory Access into ZOLC as a first-level
-  concept that mirrors Snitch's Coherent Memory interception
-* To add the Graph-Node Walking Capability of Extra-V
-  to ZOLC / SVREMAP
-* To make it possible, in a combination of hardware and software,
-  to easily identify ZOLC / SVREMAP Blocks
-  that may be transparently pushed down closer to Memory, for
-  localised distributed parallel execution, by OpenCAPI-aware PEs,
-  exploiting both the Deterministic nature of ZOLC / SVREMAP
-  combined with the Cache-Coherent nature of OpenCAPI,
-  to the maximum extent possible.
-* To make the exploitation of this powerful solution as simple
-  and straightforward as possible for Software Engineers to use,
-  in standard common-usage compilers, gcc and llvm.
-* To propose extensions to Public Standards that allow all of
-  the above to become part of everyday ubiquitous mass-volume
-  computing.
-
-Even the first of these - merging Snitch-style register tagging
-into SVP64 - would
-expand SVP64's capability for Matrices, currently limited to
-around 5x7 to 6x6 Matrices and constrained by the size of
-the register files (128 64-bit entries), to arbitrary (massive) sizes.
-
 **Use-case: Matrix and Convolutions**
 
 Imagine a large Matrix scenario, with several values close to zero that
@@ -870,6 +838,38 @@ main CPU.  In this way a large Sparse Matrix Multiply or Convolution
 may be achieved without having to pass unnecessary data through
 L1/L2/L3 Caches only to find, at the CPU, that it is zero.
 
+**Roadmap summary of Advanced SVP64**
+
+The future direction for SVP64, then, is:
+
+* To overcome its current limitation of REMAP Schedules being
+  restricted to Register Files, leveraging the Snitch-style
+  register interception "tagging" technique.
+* To adopt ZOLC and merge REMAP Schedules into ZOLC
+* To bring OpenCAPI Memory Access into ZOLC as a first-level
+  concept that mirrors Snitch's Coherent Memory interception
+* To add the Graph-Node Walking Capability of Extra-V
+  to ZOLC / SVREMAP
+* To make it possible, in a combination of hardware and software,
+  to easily identify ZOLC / SVREMAP Blocks
+  that may be transparently pushed down closer to Memory, for
+  localised distributed parallel execution, by OpenCAPI-aware PEs,
+  exploiting both the Deterministic nature of ZOLC / SVREMAP
+  combined with the Cache-Coherent nature of OpenCAPI,
+  to the maximum extent possible.
+* To make the exploitation of this powerful solution as simple
+  and straightforward as possible for Software Engineers to use,
+  in standard common-usage compilers, gcc and llvm.
+* To propose extensions to Public Standards that allow all of
+  the above to become part of everyday ubiquitous mass-volume
+  computing.
+
+Even the first of these - merging Snitch-style register tagging
+into SVP64 - would
+expand SVP64's capability for Matrices, currently limited to
+around 5x7 to 6x6 Matrices and constrained by the size of
+the register files (128 64-bit entries), to arbitrary (massive) sizes.
+
 **Summary**
 
 Bottom line is that there is a clear roadmap towards solving a long