From b814f554cc28b4eb949937fe393dffc1cc4fe4e2 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 21 Jun 2022 19:02:29 +0100 Subject: [PATCH] --- openpower/sv/compliancy_levels.mdwn | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) 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. + -- 2.30.2