From: Luke Kenneth Casson Leighton Date: Wed, 29 Mar 2023 16:27:23 +0000 (+0100) Subject: move regfile section X-Git-Tag: opf_rfc_ls012_v1~245 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=4db15c1f1a3261794a08cc6a30cc0fc309b2f301;p=libreriscv.git move regfile section --- diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index ba99bd601..34a382f4a 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -67,6 +67,61 @@ rules are followed, allowing for full soft-emulation including future revisions. Compliancy Subsets exist to ensure minimum levels of binary interoperability expectations within certain environments. +## SVP64 encoding features + +A number of features need to be compacted into a very small space of +only 24 bits: + +* Independent per-register Scalar/Vector tagging and range extension on + every register +* Element width overrides on both source and destination +* Predication on both source and destination +* Two different sources of predication: INT and CR Fields +* SV Modes including saturation (for Audio, Video and DSP), mapreduce, + fail-first and predicate-result mode. + +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. + +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, +to allow emulation of future instruction sets, or for subsets of SVP64 to +be implemented in hardware and the rest emulated. This includes SVP64 +SPRs: reading or writing values which are not supported in hardware +must also raise illegal instruction traps in order to allow emulation. +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" + +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 + +SVP64 is designed so that when the prefix is all zeros, and + VL=1, no effect or +influence occurs (no augmentation) such that all standard Power ISA +v3.0/v3 1 instructions covered by the prefix are "unaltered". This +is termed `scalar identity behaviour` (based on the mathematical +definition for "identity", as in, "identity matrix" or better "identity +transformation"). + +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 files, elements, and Element-width Overrides In the Upper Compliancy Levels the size of the GPR and FPR Register @@ -153,61 +208,6 @@ write-enable line. It is up to the Hardware Architect to then amortise as simultaneous non-overlapping Register File writes, to achieve High Performance designs. -## SVP64 encoding features - -A number of features need to be compacted into a very small space of -only 24 bits: - -* Independent per-register Scalar/Vector tagging and range extension on - every register -* Element width overrides on both source and destination -* Predication on both source and destination -* Two different sources of predication: INT and CR Fields -* SV Modes including saturation (for Audio, Video and DSP), mapreduce, - fail-first and predicate-result mode. - -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. - -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, -to allow emulation of future instruction sets, or for subsets of SVP64 to -be implemented in hardware and the rest emulated. This includes SVP64 -SPRs: reading or writing values which are not supported in hardware -must also raise illegal instruction traps in order to allow emulation. -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" - -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 - -SVP64 is designed so that when the prefix is all zeros, and - VL=1, no effect or -influence occurs (no augmentation) such that all standard Power ISA -v3.0/v3 1 instructions covered by the prefix are "unaltered". This -is termed `scalar identity behaviour` (based on the mathematical -definition for "identity", as in, "identity matrix" or better "identity -transformation"). - -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 As previously mentioned SV Registers are simply the INT, FP and CR