From: lkcl <lkcl@web>
Date: Tue, 21 Jun 2022 18:02:29 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~1622
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=b814f554cc28b4eb949937fe393dffc1cc4fe4e2;p=libreriscv.git

---

diff --git a/openpower/sv/compliancy_levels.mdwn b/openpower/sv/compliancy_levels.mdwn
index 98ce2ea47..8c7dc0a26 100644
--- a/openpower/sv/compliancy_levels.mdwn
+++ b/openpower/sv/compliancy_levels.mdwn
@@ -116,7 +116,7 @@ to the required total 128.
 Another important aspect is that when Rc=1 is set, CR Field Vector co-results
 are produced. Should these exceed CR7 (CR8-CR127) and the number of CR Fields
 has not been increased to 128 then an Illegal Instruction Trap must be
-raised.  In practical terms, to avoid this occurrence in software,
+raised.  In practical terms, to avoid this occurrence in Embedded software,
 MAXVL should not
 exceed 8 for Arithmetic or Logical operations with Rc=1.
 
@@ -166,3 +166,25 @@ additional Register Hazard Dependencies on fine-grained (8/16/32-bit)
 operations.  Just as with SRAMs multiple write-enable lines may be
 raised to update higher-width elements.
 
+# Examples
+
+Assuming that hardware implements scalar operations only,
+and implements predication but not elwidth overrides:
+
+    setvli r0, 4            # sets VL equal to 4
+    sv.addi r5, r0, 1       # raises an 0x700 trap
+    setvli r0, 1            # sets VL equal to 1
+    sv.addi r5, r0, 1       # gets executed by hardware
+    sv.addi/ew=8 r5, r0, 1  # raises an 0x700 trap
+    sv.ori/sm=EQ r5, r0, 1  # executed by hardware
+
+The first `sv.addi` raises an illegal instruction trap because
+VL has been set to 4, and this is not supported.  Likewise
+elwidth overrides if requested always raise illegal instruction
+traps.
+
+Such an implementation would qualify for the "Ultra-Embedded" SV Level.
+It would not qualify for the "Embedded" level because when VL=1 an
+Illegal Exception is raised, and the Embedded Level requires full
+VL Loop support in hardware.
+