(no commit message)

diff --git a/openpower/sv/remap.mdwn b/openpower/sv/remap.mdwn
index 22bf57ba0b15d664dd84d62e3c4a28fa6e2672d5..ab1c05b72bb8f8f75375bbc5dc5eba7be206a0ac 100644 (file)
--- a/openpower/sv/remap.mdwn
+++ b/openpower/sv/remap.mdwn
@@ -158,7 +158,7 @@ a 5x4 result:
   - RC to use SVSHAPE3
   - RT to use SVSHAPE0
   - RS Remapping to not be activated
-* sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
+* sv.fmadds has vectors RT=0, RA=32, RB=64, RC=0
 * With REMAP being active each register's element index is
   *independently* transformed using the specified SHAPEs.
 
@@ -170,6 +170,14 @@ need to perform additional Transpose or register copy instructions.
 The example above may be executed as a unit test and demo,
 [here](https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;h=c15479db9a36055166b6b023c7495f9ca3637333;hb=a17a252e474d5d5bf34026c25a19682e3f2015c3#l94)
 
+*Hardware Architectural note: with the Scheduling applying as a Phase between
+Decode and Issue in a Deterministic fashion the Register Hazards may be
+easily computed and a standard Out-of-Order Micro-Architecture exploited to good
+effect.  Even an In-Order system may observe that for large Outer Product
+Schedules there will be no stalls, but if the Matrices are particularly
+small size an In-Order system would have to stall, just as it would if
+the operations were loop-unrolled without Simple-V*.
+
 ## REMAP types
 
 This section summarises the motivation for each REMAP Schedule