From: Luke Kenneth Casson Leighton Date: Wed, 29 Mar 2023 16:29:56 +0000 (+0100) Subject: move regfile section X-Git-Tag: opf_rfc_ls012_v1~243 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=4d8b34faf008f142a6315ce75d1bca14ae5f8a7e;p=libreriscv.git move regfile section --- diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index aaa6eb73a..73083fcec 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -106,45 +106,6 @@ Any operation that inherently makes no sense if repeated is termed 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 expanded on below 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. Likewise FP registers are -extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries, -CR0 thru CR127. - -The names of the registers therefore reflects a simple linear extension -of the Power ISA v3.0B / v3.1B register naming, and in hardware this -would be reflected by a linear increase in the size of the underlying -SRAM used for the regfiles. - -Note: when an EXTRA field (defined below) is zero, SV is deliberately -designed so that the register fields are identical to as if SV was not in -effect i.e. under these circumstances (EXTRA=0) the register field names -RA, RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers. -This is part of `scalar identity behaviour` described above. - ## Register files, elements, and Element-width Overrides In the Upper Compliancy Levels the size of the GPR and FPR Register @@ -231,6 +192,45 @@ 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. +## 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 indicated above 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. Likewise FP registers are +extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries, +CR0 thru CR127. + +The names of the registers therefore reflects a simple linear extension +of the Power ISA v3.0B / v3.1B register naming, and in hardware this +would be reflected by a linear increase in the size of the underlying +SRAM used for the regfiles. + +Note: when an EXTRA field (defined below) is zero, SV is deliberately +designed so that the register fields are identical to as if SV was not in +effect i.e. under these circumstances (EXTRA=0) the register field names +RA, RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers. +This is part of `scalar identity behaviour` described above. + ## Future expansion. With the way that EXTRA fields are defined and applied to register fields,