From: lkcl Date: Wed, 29 Mar 2023 15:17:04 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls001_v3~1 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d170fa951be3174a4e565cee3647190e08a031dd;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index 71ffd21ac..b8e6222c5 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -39,7 +39,7 @@ an independent "Defined word" that augments the behaviour of the following instr but does **not** change the actual Decoding of that following instruction. **All prefixed instructions retain their non-prefixed encoding and definition**. -*Architectural Resource Allocation note: it is **prohibited** to accept RFCs which +*Architectural Resource Allocation note: it is prohibited to accept RFCs which fundamentally violate this hard requirement. Under no circumstances must the Suffix space have an alternate instruction encoding allocated within SVP64 that is entirely different from the non-prefixed Defined Word. Hardware Implementors @@ -108,7 +108,7 @@ is inherently LSB0: } ``` -Example add operation implementation when elwidths are 64-bit: +Example Vector-looped add operation implementation when elwidths are 64-bit: ``` # add RT, RA,RB using the "uint64_t" union member, "l" @@ -127,7 +127,8 @@ However if elwidth overrides are set to 16 for both source and destination: Hardware Architectural note: to avoid a Read-Modify-Write at the register file it is strongly recommended to implement byte-level write-enable lines exactly as has been implemented in DRAM ICs for many decades. Additionally the predicate mask bit is advised -to be associated with the element operation and ultimately passed to the register file. +to be associated with the element operation and alongside the result ultimately +passed to the register file. When element-width is set to 64-bit the relevant predicate mask bit may be repeated eight times and pull all eight write-port byte-level lines HIGH. Clearly when element-width is set to 8-bit the relevant predicate mask bit corresponds directly with one single @@ -146,9 +147,11 @@ A number of features need to be compacted into a very small space of only 24 bit * SV Modes including saturation (for Audio, Video and DSP), mapreduce, fail-first and predicate-result mode. -Different classes of operations require +Different classes of operations require different formats. The earlier sections cover +the c9mmon formats and the four separate modes follow: CR operations (crops), +Arithmetic/Logical (termed "normal"), Load/Store and Branch-Conditional. -# Definition of Reserved in this spec. +## Definition of Reserved in this spec. For the new fields added in SVP64, instructions that have any of their fields set to a reserved value must cause an illegal instruction trap, @@ -162,13 +165,13 @@ Unless otherwise stated, reserved values are always all zeros. This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard Power ISA definition is intended the red keyword `RESERVED` is used. -# Definition of "UnVectoriseable" +## Definition of "UnVectoriseable" Any operation that inherently makes no sense if repeated is termed "UnVectoriseable" or "UnVectorised". Examples include `sc` or `sync` which have no registers. `mtmsr` is also classed as UnVectoriseable because there is only one `MSR`. -# Scalar Identity Behaviour +## Scalar Identity Behaviour SVP64 is designed so that when the prefix is all zeros, and VL=1, no effect or @@ -178,10 +181,11 @@ v3.0/v3 1 instructions covered by the prefix are "unaltered". This is termed `sc Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix) whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity transformation"). -# Register Naming and size +## Register Naming and size -SV Registers are simply the INT, FP and CR register files extended -linearly to larger sizes; SV Vectorisation iterates sequentially through these registers. +As previously mentioned SV Registers are simply the INT, FP and CR register files extended +linearly to larger sizes; SV Vectorisation iterates sequentially through these registers +(LSB0 sequential ordering from 0 to VL-1). Where the integer regfile in standard scalar Power ISA v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127. @@ -216,28 +220,10 @@ at the LSB. The mapping from the OpenPower v3.1 prefix bits to the Remapped Encoding is defined in the Prefix Fields section. -## Prefix Opcode Map (64-bit instruction encoding) - -In the original table in the v3.1B Power ISA Spec on p1350, Table 12, prefix bits 6:11 are shown, with their allocations to different v3.1B pregix "modes". - -The table below hows both PowerISA v3.1 instructions as well as new SVP instructions fit; -empty spaces are yet-to-be-allocated Illegal Instructions. - -| 6:11 | ---000 | ---001 | ---010 | ---011 | ---100 | ---101 | ---110 | ---111 | -|------|--------|--------|--------|--------|--------|--------|--------|--------| -|000---| 8LS | 8LS | 8LS | 8LS | 8LS | 8LS | 8LS | 8LS | -|001---| | | | | | | | | -|010---| 8RR | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| -|011---| | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| -|100---| MLS | MLS | MLS | MLS | MLS | MLS | MLS | MLS | -|101---| | | | | | | | | -|110---| MRR | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| -|111---| | MMIRR | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| - -Note that by taking up a block of 16, where in every case bits 7 and 9 are set, this allows svp64 to utilise four bits of the v3.1B Prefix space and "allocate" them to svp64's Remapped Encoding field, instead. - ## Prefix Fields +TODO incorporate EXT09 + To "activate" svp64 (in a way that does not conflict with v3.1B 64 bit Prefix mode), fields within the v3.1B Prefix Opcode Map are set (see Prefix Opcode Map, above), leaving 24 bits "free" for use by SV. This is achieved by setting bits 7 and 9 to 1: