-[[!tag standards]]
-
# Simple-V Compliancy Levels
The purpose of the Compliancy Levels is to provide a documented
instruction need not or must not raise an illegal instruction on UNDEFINED
behaviour, unimiplemented parts of SVP64 *MUST* raise an illegal
instruction trap when (and only when)
-that same Scalar instruction is Prefixed*.
+that same Scalar instruction is Prefixed*. It is absolutely critical
+to note that when not Prefixed, under no circumstances shall the Scalar
+instruction deviate from the Scalar Power ISA Specification.
Summary of Compliancy Levels, each Level includes all lower levels:
+* **Zero-Level**: Simple-V is not implemented (at all) in hardware. This
+ Level is required to be listed because all capabilities of Simple-V
+ must be Soft-emulatable.
* **Ultra-embedded**: `setvl` instruction and context-switching of SVSTATE
to/from SVSRR1. Register Files as Standard Power ISA. `scalar identity`
implemented.
and support for Hardware for-looping
in both Horizontal-First and Vertical-First Mode as well as Predication
(Single and Twin) for the GPRs r3, r10 and r30. CR-Field-based
- Predicates, if used, may still raise illegal instruction trap.
-* **DSP/AV**: 128 registers,
+ Predicates do not need to be added.
+* **Embedded DSP/AV**: 128 registers,
element-width
overrides, and Saturation and Mapreduce/Iteration Modes.
+* **High-end DSP/AV**: Same as Embedded-DSP/AV except also
+ including Indexed and Offset REMAP capability.
* **3D/Advanced/Supercomputing**: all SV Branch instructions;
crweird and vector-assist instructions (`set-before-first` etc);
Swizzle Move instructions;
Levels (SFS, SFFS, Linux, AIX). They are separate and independent. It
is perfectly fine to implement Ultra-Embedded on AIX, and perfectly fine to implement 3D/Advanced on SFS. **Compliance with SV Levels does not convey or remove the obligation of Compliance with SFS/SFFS/Linux/AIX Levels and vice-versa**.
-# Ultra-Embedded Level
+## Zero-Level
+
+This level exists to indicate the critical importance of all and any
+features attempted to be executed on hardware that has no support at
+all for Simple-V being **required** to raise Illegal Exceptions.
+**This includes existing Power ISA Implementations:** IBM POWER being
+the most notable.
+
+With parts of the Power ISA being "silent executed" (hints for example),
+it is absolutely critical to have all capabilities of Simple-V sit
+within full Illegal Instruction space of existing and future Hardware.
+
+## Ultra-Embedded Level
This level exists as an entry-level into SVP64, most suited to resource
constrained soft cores, or Hardware implementations where unit cost is a much
Scalar non-prefixed, i.e. as if the Prefix had not been present.
Additionally all SV SPRs must be zero and the 24-bit `RM` field must be zero.
-# Embedded Level
+## Embedded Level
This level is more suitable for Hardware implementations where performance and power saving begins to matter. A second instruction, `svstep`, used
by Vertical-First Mode, is required, as is hardware-level looping in
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.
instructions are Prefixed
to 64-bit.
-# DSP / Audio / Video Level
+## DSP / Audio / Video Level
This level is best suited to high-performance power-efficient but
specialist Compute workloads. 128 GPRs, FPRs and CR Fields are all
required, as is element-width overrides to allow data processing
down to the 8-bit level. SUBVL support (Sub-Vector vec2/3/4) is also
-required.
+required, as is Pack/Unpack EXTRA format (helps with Pixel and
+Audio Stream Structured data)
-All SVP64 Modes are required to be implemented in hardware: Saturation
+All SVP64 Modes must be implemented in hardware: Saturation
in particular is a necessity for Audio DSP work. Reduction as well to
assist with Audio/Video.
-It is not mandatory for this Level to have DCT/FFT REMAP Capability but
+It is not mandatory for this Level to have DCT/FFT REMAP Capability in
+hardware but
due to the high prevalence of DCT and FFT in Audio, Video and DSP
-workloads it is strongly recommended.
+workloads it is strongly recommended. Matrix (Dimensional) REMAP
+and Swizzle may also be useful to help with 24-bit (3 byte) Structured Audio Streams and are also recommended but not mandatory.
-# 3D / Advanced / Supercomputing
+## High-end DSP
+
+In this Compliancy Level the benefits of the Offset and Index REMAP
+subsystem becomes worth its hardware cost. In lower-performing DSP
+and A/V workloads it is not.
+
+## 3D / Advanced / Supercomputing
This Compliancy Level is for highest performance and energy efficiency.
All aspects of SVP64 must be entirely implemented, in full, in Hardware.
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=4 an
+Illegal Exception is raised, and the Embedded Level requires full
+VL Loop support in hardware.
+
+[[!tag standards]]
+
+-------
+
+\newpage{}
+
+
projects / libreriscv.git / blobdiff