(no commit message)

diff --git a/openpower/sv/SimpleV_rationale.mdwn b/openpower/sv/SimpleV_rationale.mdwn
index 848c2e8c446d86c8fa075d9c2c78b6a2c4a323e2..c3aa46bda852bf864e72b975f1d29a6b93bb10f0 100644 (file)
--- a/openpower/sv/SimpleV_rationale.mdwn
+++ b/openpower/sv/SimpleV_rationale.mdwn
@@ -750,4 +750,26 @@ compilers? As intrinsics: of course. Can it become part of auto-vectorisation? P
 if an infinite supply of money and engineering time is thrown at it.
 Is a half-way-house solution of compiler intrinsics good enough?
 Intel, ARM, MIPS, Power ISA and RISC-V have all already said "yes" on that,
-for several decades, and advanced programmers are comfortable with it.
+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.
+