From: Luke Kenneth Casson Leighton Date: Wed, 24 May 2023 11:20:13 +0000 (+0100) Subject: rename ls005 to ls005.xlen X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ef384980a9709b126e1435ce510fed0a264e645c;p=libreriscv.git rename ls005 to ls005.xlen --- diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn deleted file mode 100644 index deac1ceac..000000000 --- a/openpower/sv/rfc/ls005.mdwn +++ /dev/null @@ -1,311 +0,0 @@ -# OPF ISA WG External RFC ls005 v1: XLEN - -* RFC Author: Luke Kenneth Casson Leighton. -* RFC Contributors/Ideas: Jacob Lifshay, Toshaan Bharvani -* Funded by NLnet under the NGI Zero Entrust EU Horizon Europe Grant 101069594 - -**URLs**: - -* -* -* -* - -**Severity**: Major - -**Status**: New - -**Date**: 22 Dec 2022 v2 TODO - -**Target** v3.2B - -**Books and Section affected**: - -``` - Everything (in a consistent, regular and systematic fashion) -``` - -**Summary** - -``` - Exactly as is already done in RISC-V, convert the entire use of 64-bit hard-coding to "XLEN". - Exactly as is in RISC-V, options then include PowerISA-32, PowerISA-64 and PowerISA-128. - Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is also floated, for Embedded, - AI, Edge, Processing-in-Memory, Distributed Computing and other purposes. -``` - -**Submitter**: Luke Leighton (Libre-SOC) - -**Requester**: Libre-SOC - -**Impact on processor**: - -``` - Entirely new processors, entirely new markets. -``` - -**Impact on software**: - -``` - Massive but regular, consistent, and systematic. -``` - -**Keywords**: - -``` - XLEN -``` - -**Motivation** - -The Power ISA is far too massive, making it wholly unsuited for Embedded -markets and adversely impacting its reach and potential. The RISC paradigm -it is based on has gone too far into PackedSIMD (128-bit). Fixing this is -relatively and conceptually straightforward: allow 32-bit and even 16-bit -and 8-bit implementations, and use the opportunity to allow future Scalar -128-bit implementations in the exact same strategic way that RISC-V has RV128. - -Register files are redefined to XLEN width but are permitted to "group" -registers together to create 16-bit, 32-bit and 64-bit addresses. -In this way, the limitations of what would otherwise restrict the usefulness -of a severely-targetted application-specific processor may be overcome in -order to make it still possible to (at reduced performance) still run -general-purpose applications. -AI application-specific processing or other Processing-In-Memory or other -specialist design therefore may for example focus a balance -of raw computing power heavily onto 8-bit or 16-bit computation, but still -gain the benefit of the Power ISA and everything it brings. Contrast -this with the more "normal" approach of creating heavily-focussed -specialist "AI" Engines incapable of Turing-completeness and the benefits -are clear. - -Note 1: SVP64 **requires** this change as a 100% critical dependency. -SIMD back-end ALUs process Vectors of "Elements" at 8, 16 and 32-bit (and -64-bit), read from, processed, and returned to, the standard **Scalar** -Register Files, with byte-level write-enable lines. The proposal is -therefore made as an opportunity for others interested in Scalar ISA -8/16/32-bit (and future 128-bit variants of Scalar Power ISA) to take -**and complete** that work in an incremental fashion, without having -to be faced with a massive bulk and body of work as a prerequisite. - -Examples include that whilst an SVP64 Prefixed '''lbz''' instruction -('''sv.lbz''') is well-defined and has strict well-defined behaviour, -a pure **Scalar-only** (non-SVP64) over-ridden '''lbz''' instruction -has not been so well-defined, and would require a Stakeholder interested -in 8/16/32-bit (and future 128-bit) to think through the implications -and incrementally submit further OPF ISA RFCs. With RISC-V **already -having done this type of work** it is not technically difficult: it -just requires another Stakeholder to do it. - -Note 2: one alternative to this proposal, as far as SVP64 is concerned, -is to literally duplicate the entirety of Chapters 3 and 4 Book III, -and to create - and then maintain - multiple identical copies of the -instructions including identical copies of the pseudocode except for -substitution of occurrences of "64" with a "32" variant, "16" variant, -"8" variant (and future "128" variant), and so on. This would add -over 700 additional pages to the Power ISA Specification and it should -be clear that it would become a maintenance nightmare. - -Another alternative is to poison and irredemably damage the Power ISA -(as a powerful and lean RISC ISA) by adding several hundred (close to 1,000) -additional specific 8-bit, 16-bit and 32-bit (and in future 128-bit) Scalar -instructions. Given that the 32-bit Opcode Allocation Space is already -under pressure such a move would be extremely unwise for that reason alone. - -**Changes** - -For all pseudocode right across the board in all Scalar operations, replace -hard-coded "64" with "XLEN". **This work is already underway as sponsored -by NLnet in the Libre-SOC Power ISA Pseudocode**. The default is obviously -recommended to be "XLEN=64" in order to create zero disruption. - -Definitions of the Register File(s) for GPR and FPR are then changed to be -"XLEN" wide. However, for Embedded purposes (XLEN=32/16/8), an SPR controls -whether (and how many) sequentially-grouped registers are taken together to -create 16-bit, 32-bit and 64-bit addresses (depending on application need). -GPR is obvious, FPR is quirky. SVP64 redefines FP ops (those not ending in "s") -to be "full width" and all ops ending in "s" to be "half of -the full width". - -* XLEN=64 keeps FPR "full width" exactly as presently defined, and - "half width" exactly as presently defined. -* XLEN=32 overrides FPR "full width" operations to - full BFP32, and "half width" to be "BFP16 stored in an BFP32" -* XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves - "half width" RESERVED (there is no IEEE version of [FP8](https://web.archive.org/web/20221223085833/https://wccftech.com/nvidia-intel-arm-bet-their-ai-future-on-fp8-whitepaper-for-8-bit-fp-published/)). -* XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves - "half width" RESERVED. - ----------------- - -# Examples - -## pseudocode examples demonstrating modification. - -before for popcntb: - -``` -do i = 0 to 7 - n <- 0 - do j = 0 to 7 - if (RS)[(i*8)+j] = 1 then - n <- n+1 - RA[(i*8):(i*8)+7] <- n -``` - -after: - -``` -do i = 0 to ((XLEN/8)-1) - n <- 0 - do j = 0 to 7 - if (RS)[(i*8)+j] = 1 then - n <- n+1 - RA[(i*8):(i*8)+7] <- n -``` - -Here as the instruction's intent is to count bytes, and RA contains on -a per-byte basis a SIMD-style count of each byte's 1s, it becomes possible -to simply count less bytes. - -Should it be more useful to redefine popcntb in terms of always returning -eight results? For example `sv.popcntb/w=16` to return 8 2-bit counts of -the number of bits in each 2-bit group in RS? - -## no modification needed, but function changes - -For the `addi` instruction there is no apparent change: - -``` -RT <- (RA|0) + EXTS(SI) -``` - -However behind the scenes, RA is XLEN bits wide, therefore EXTS performs an -increase in bitlength not to exactly 64 but to XLEN. Obviousy for XLEN=16 -there is no sign-extension, and for XLEN=8 truncation of `SI` will occur. -Illustrates that there are subtle quirks involved, requiring some thought. - -The reason for keeping as many bits of the Immediate as possible should be clear. - -## Compare Ranged Byte (cmprb BF,L,RA,RB) - -``` - src1 <- EXTZ((RA)[XLEN-8:XLEN-1]) - src21hi <- EXTZ((RB)[XLEN-32:XLEN-23]) - src21lo <- EXTZ((RB)[XLEN-24:XLEN-17]) - src22hi <- EXTZ((RB)[XLEN-16:XLEN-9]) - src22lo <- EXTZ((RB)[XLEN-8:XLEN-1]) - if L=0 then - in_range <- (src22lo <= src1) & (src1 <= src22hi) - else - in_range <- (((src21lo <= src1) & (src1 <= src21hi)) | - ((src22lo <= src1) & (src1 <= src22hi))) - CR[4*BF+32] <- 0b0 - CR[4*BF+33] <- in_range - CR[4*BF+34] <- 0b0 - CR[4*BF+35] <- 0b0 -``` - -Compare Ranged Byte takes either one or two ranges from RB as individual bytes, -thus requiring a minimum 16-bit (32-bit when L=1) operand RB. -src1 on the other hand is only -8-bit long: the first byte of RA. - -Therefore a little more thought is required. Should this simply be UNDEFINED -behaviour when XLEN=8/16 and L=1? When XLEN=16, L=0 the instruction is still -valid. Would it be costly at the Decoder? - -## Trap Word Immediate - -Like FP Single operations there also exist operations at "half of regfile width" -in the Integer realm. They are discernable with the designation "Word" in their -title, such as "Trap WORD Immediate". - -``` - a <- EXTS((RA)[XLEN/2:XLEN-1]) - if (a < EXTS(SI)) & TO[0] then TRAP - if (a > EXTS(SI)) & TO[1] then TRAP - if (a = EXTS(SI)) & TO[2] then TRAP - if (a u EXTS(SI)) & TO[4] then TRAP -``` - -Here, EXTS receives **half** of the bits of its input register operand, RA. -Note this is **not** "32 bit because a Word is 32-bit". The definition -"Trap Word Immediate" has to be replaced with "Trap Half-register-width Immediate" -but this is very clumsy. - -When XLEN=8 "half register width" is clearly 4 bit, thus the LSB nibble is tested, -but still sign-extended for comparison -against the 16-bit signed immediate. - -## Extend Sign byte/half/word - -This instruction can be redefined again in terms of: - -* "Word" meaning "Half of register width" -* "Half-word" meaning "Quarter of register width" -* "Byte" meaning "One-eighth of register width" - -And a table results as follows: - -``` - XLEN=8: - extsb: 1-bit -> 8-bit sign extension - extsh: 2-bit -> 8-bit sign extension - extsw: 4-bit -> 8-bit sign extension - XLEN=16: - extsb: 2-bit -> 16-bit sign extension - extsh: 4-bit -> 16-bit sign extension - extsw: 8-bit -> 16-bit sign extension - XLEN=32: - extsb: 4-bit -> 32-bit sign extension - extsh: 8-bit -> 32-bit sign extension - extsw: 16-bit -> 32-bit sign extension - XLEN=64: - extsb: 8-bit -> 64-bit sign extension - extsh: 16-bit -> 64-bit sign extension - extsw: 32-bit -> 64-bit sign extension -``` - -If the instructions were kept as presently defined then there -is a loss of functionality and opportunity: - -``` - XLEN=8: # completely wasted opportunity - extsb: 8-bit -> 8-bit does nothing - extsh: 16-bit -> 8-bit truncates - extsw: 32-bit -> 8-bit truncates - XLEN=16: # wasted 2/3 of encoding - extsb: 8-bit -> 16-bit sign extension - extsh: 16-bit -> 16-bit does nothing - extsw: 32-bit -> 16-bit truncates - XLEN=32: # wasted 1/3 of encoding - extsb: 8-bit -> 32-bit sign extension - extsh: 16-bit -> 32-bit sign extension - extsw: 32-bit -> 32-bit does nothing - XLEN=64: # unchanged (default) behaviour - extsb: 8-bit -> 64-bit sign extension - extsh: 16-bit -> 64-bit sign extension - extsw: 32-bit -> 64-bit sign extension -``` - -The RTL for `extsb` becomes: - -``` - in <- (RA)[XLEN-8:XLEN-1] # extract first byte - if XLEN = 8 then RT <- in[7] * 8 # 1->8 - if XLEN = 16 then RT <- in[6] * 15 || in[7] # 2->16 - if XLEN = 32 then RT <- in[4] * 29 || in[5:7] # 4->32 - if XLEN = 64 then RT <- in[0] * 57 || in[1:7] # 8->64 -``` - -And `extsh` and `extsw` follow similar logic. Interestingly there is -no loss of functionality compared to keeping `extsb` always as "byte -sign-extending" and ironically the loss of opportunity *is* to keep -`extsb` the same (extend *byte* regardless of XLEN). - -[[!tag opf_rfc]] - -\newpage{} - diff --git a/openpower/sv/rfc/ls005.xlen.mdwn b/openpower/sv/rfc/ls005.xlen.mdwn new file mode 100644 index 000000000..73e1c4072 --- /dev/null +++ b/openpower/sv/rfc/ls005.xlen.mdwn @@ -0,0 +1,311 @@ +# OPF ISA WG External RFC ls005.xlen v1: XLEN + +* RFC Author: Luke Kenneth Casson Leighton. +* RFC Contributors/Ideas: Jacob Lifshay, Toshaan Bharvani +* Funded by NLnet under the NGI Zero Entrust EU Horizon Europe Grant 101069594 + +**URLs**: + +* +* +* +* + +**Severity**: Major + +**Status**: New + +**Date**: 22 Dec 2022 v2 TODO + +**Target** v3.2B + +**Books and Section affected**: + +``` + Everything (in a consistent, regular and systematic fashion) +``` + +**Summary** + +``` + Exactly as is already done in RISC-V, convert the entire use of 64-bit hard-coding to "XLEN". + Exactly as is in RISC-V, options then include PowerISA-32, PowerISA-64 and PowerISA-128. + Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is also floated, for Embedded, + AI, Edge, Processing-in-Memory, Distributed Computing and other purposes. +``` + +**Submitter**: Luke Leighton (Libre-SOC) + +**Requester**: Libre-SOC + +**Impact on processor**: + +``` + Entirely new processors, entirely new markets. +``` + +**Impact on software**: + +``` + Massive but regular, consistent, and systematic. +``` + +**Keywords**: + +``` + XLEN +``` + +**Motivation** + +The Power ISA is far too massive, making it wholly unsuited for Embedded +markets and adversely impacting its reach and potential. The RISC paradigm +it is based on has gone too far into PackedSIMD (128-bit). Fixing this is +relatively and conceptually straightforward: allow 32-bit and even 16-bit +and 8-bit implementations, and use the opportunity to allow future Scalar +128-bit implementations in the exact same strategic way that RISC-V has RV128. + +Register files are redefined to XLEN width but are permitted to "group" +registers together to create 16-bit, 32-bit and 64-bit addresses. +In this way, the limitations of what would otherwise restrict the usefulness +of a severely-targetted application-specific processor may be overcome in +order to make it still possible to (at reduced performance) still run +general-purpose applications. +AI application-specific processing or other Processing-In-Memory or other +specialist design therefore may for example focus a balance +of raw computing power heavily onto 8-bit or 16-bit computation, but still +gain the benefit of the Power ISA and everything it brings. Contrast +this with the more "normal" approach of creating heavily-focussed +specialist "AI" Engines incapable of Turing-completeness and the benefits +are clear. + +Note 1: SVP64 **requires** this change as a 100% critical dependency. +SIMD back-end ALUs process Vectors of "Elements" at 8, 16 and 32-bit (and +64-bit), read from, processed, and returned to, the standard **Scalar** +Register Files, with byte-level write-enable lines. The proposal is +therefore made as an opportunity for others interested in Scalar ISA +8/16/32-bit (and future 128-bit variants of Scalar Power ISA) to take +**and complete** that work in an incremental fashion, without having +to be faced with a massive bulk and body of work as a prerequisite. + +Examples include that whilst an SVP64 Prefixed '''lbz''' instruction +('''sv.lbz''') is well-defined and has strict well-defined behaviour, +a pure **Scalar-only** (non-SVP64) over-ridden '''lbz''' instruction +has not been so well-defined, and would require a Stakeholder interested +in 8/16/32-bit (and future 128-bit) to think through the implications +and incrementally submit further OPF ISA RFCs. With RISC-V **already +having done this type of work** it is not technically difficult: it +just requires another Stakeholder to do it. + +Note 2: one alternative to this proposal, as far as SVP64 is concerned, +is to literally duplicate the entirety of Chapters 3 and 4 Book III, +and to create - and then maintain - multiple identical copies of the +instructions including identical copies of the pseudocode except for +substitution of occurrences of "64" with a "32" variant, "16" variant, +"8" variant (and future "128" variant), and so on. This would add +over 700 additional pages to the Power ISA Specification and it should +be clear that it would become a maintenance nightmare. + +Another alternative is to poison and irredemably damage the Power ISA +(as a powerful and lean RISC ISA) by adding several hundred (close to 1,000) +additional specific 8-bit, 16-bit and 32-bit (and in future 128-bit) Scalar +instructions. Given that the 32-bit Opcode Allocation Space is already +under pressure such a move would be extremely unwise for that reason alone. + +**Changes** + +For all pseudocode right across the board in all Scalar operations, replace +hard-coded "64" with "XLEN". **This work is already underway as sponsored +by NLnet in the Libre-SOC Power ISA Pseudocode**. The default is obviously +recommended to be "XLEN=64" in order to create zero disruption. + +Definitions of the Register File(s) for GPR and FPR are then changed to be +"XLEN" wide. However, for Embedded purposes (XLEN=32/16/8), an SPR controls +whether (and how many) sequentially-grouped registers are taken together to +create 16-bit, 32-bit and 64-bit addresses (depending on application need). +GPR is obvious, FPR is quirky. SVP64 redefines FP ops (those not ending in "s") +to be "full width" and all ops ending in "s" to be "half of +the full width". + +* XLEN=64 keeps FPR "full width" exactly as presently defined, and + "half width" exactly as presently defined. +* XLEN=32 overrides FPR "full width" operations to + full BFP32, and "half width" to be "BFP16 stored in an BFP32" +* XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves + "half width" RESERVED (there is no IEEE version of [FP8](https://web.archive.org/web/20221223085833/https://wccftech.com/nvidia-intel-arm-bet-their-ai-future-on-fp8-whitepaper-for-8-bit-fp-published/)). +* XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves + "half width" RESERVED. + +---------------- + +# Examples + +## pseudocode examples demonstrating modification. + +before for popcntb: + +``` +do i = 0 to 7 + n <- 0 + do j = 0 to 7 + if (RS)[(i*8)+j] = 1 then + n <- n+1 + RA[(i*8):(i*8)+7] <- n +``` + +after: + +``` +do i = 0 to ((XLEN/8)-1) + n <- 0 + do j = 0 to 7 + if (RS)[(i*8)+j] = 1 then + n <- n+1 + RA[(i*8):(i*8)+7] <- n +``` + +Here as the instruction's intent is to count bytes, and RA contains on +a per-byte basis a SIMD-style count of each byte's 1s, it becomes possible +to simply count less bytes. + +Should it be more useful to redefine popcntb in terms of always returning +eight results? For example `sv.popcntb/w=16` to return 8 2-bit counts of +the number of bits in each 2-bit group in RS? + +## no modification needed, but function changes + +For the `addi` instruction there is no apparent change: + +``` +RT <- (RA|0) + EXTS(SI) +``` + +However behind the scenes, RA is XLEN bits wide, therefore EXTS performs an +increase in bitlength not to exactly 64 but to XLEN. Obviousy for XLEN=16 +there is no sign-extension, and for XLEN=8 truncation of `SI` will occur. +Illustrates that there are subtle quirks involved, requiring some thought. + +The reason for keeping as many bits of the Immediate as possible should be clear. + +## Compare Ranged Byte (cmprb BF,L,RA,RB) + +``` + src1 <- EXTZ((RA)[XLEN-8:XLEN-1]) + src21hi <- EXTZ((RB)[XLEN-32:XLEN-23]) + src21lo <- EXTZ((RB)[XLEN-24:XLEN-17]) + src22hi <- EXTZ((RB)[XLEN-16:XLEN-9]) + src22lo <- EXTZ((RB)[XLEN-8:XLEN-1]) + if L=0 then + in_range <- (src22lo <= src1) & (src1 <= src22hi) + else + in_range <- (((src21lo <= src1) & (src1 <= src21hi)) | + ((src22lo <= src1) & (src1 <= src22hi))) + CR[4*BF+32] <- 0b0 + CR[4*BF+33] <- in_range + CR[4*BF+34] <- 0b0 + CR[4*BF+35] <- 0b0 +``` + +Compare Ranged Byte takes either one or two ranges from RB as individual bytes, +thus requiring a minimum 16-bit (32-bit when L=1) operand RB. +src1 on the other hand is only +8-bit long: the first byte of RA. + +Therefore a little more thought is required. Should this simply be UNDEFINED +behaviour when XLEN=8/16 and L=1? When XLEN=16, L=0 the instruction is still +valid. Would it be costly at the Decoder? + +## Trap Word Immediate + +Like FP Single operations there also exist operations at "half of regfile width" +in the Integer realm. They are discernable with the designation "Word" in their +title, such as "Trap WORD Immediate". + +``` + a <- EXTS((RA)[XLEN/2:XLEN-1]) + if (a < EXTS(SI)) & TO[0] then TRAP + if (a > EXTS(SI)) & TO[1] then TRAP + if (a = EXTS(SI)) & TO[2] then TRAP + if (a u EXTS(SI)) & TO[4] then TRAP +``` + +Here, EXTS receives **half** of the bits of its input register operand, RA. +Note this is **not** "32 bit because a Word is 32-bit". The definition +"Trap Word Immediate" has to be replaced with "Trap Half-register-width Immediate" +but this is very clumsy. + +When XLEN=8 "half register width" is clearly 4 bit, thus the LSB nibble is tested, +but still sign-extended for comparison +against the 16-bit signed immediate. + +## Extend Sign byte/half/word + +This instruction can be redefined again in terms of: + +* "Word" meaning "Half of register width" +* "Half-word" meaning "Quarter of register width" +* "Byte" meaning "One-eighth of register width" + +And a table results as follows: + +``` + XLEN=8: + extsb: 1-bit -> 8-bit sign extension + extsh: 2-bit -> 8-bit sign extension + extsw: 4-bit -> 8-bit sign extension + XLEN=16: + extsb: 2-bit -> 16-bit sign extension + extsh: 4-bit -> 16-bit sign extension + extsw: 8-bit -> 16-bit sign extension + XLEN=32: + extsb: 4-bit -> 32-bit sign extension + extsh: 8-bit -> 32-bit sign extension + extsw: 16-bit -> 32-bit sign extension + XLEN=64: + extsb: 8-bit -> 64-bit sign extension + extsh: 16-bit -> 64-bit sign extension + extsw: 32-bit -> 64-bit sign extension +``` + +If the instructions were kept as presently defined then there +is a loss of functionality and opportunity: + +``` + XLEN=8: # completely wasted opportunity + extsb: 8-bit -> 8-bit does nothing + extsh: 16-bit -> 8-bit truncates + extsw: 32-bit -> 8-bit truncates + XLEN=16: # wasted 2/3 of encoding + extsb: 8-bit -> 16-bit sign extension + extsh: 16-bit -> 16-bit does nothing + extsw: 32-bit -> 16-bit truncates + XLEN=32: # wasted 1/3 of encoding + extsb: 8-bit -> 32-bit sign extension + extsh: 16-bit -> 32-bit sign extension + extsw: 32-bit -> 32-bit does nothing + XLEN=64: # unchanged (default) behaviour + extsb: 8-bit -> 64-bit sign extension + extsh: 16-bit -> 64-bit sign extension + extsw: 32-bit -> 64-bit sign extension +``` + +The RTL for `extsb` becomes: + +``` + in <- (RA)[XLEN-8:XLEN-1] # extract first byte + if XLEN = 8 then RT <- in[7] * 8 # 1->8 + if XLEN = 16 then RT <- in[6] * 15 || in[7] # 2->16 + if XLEN = 32 then RT <- in[4] * 29 || in[5:7] # 4->32 + if XLEN = 64 then RT <- in[0] * 57 || in[1:7] # 8->64 +``` + +And `extsh` and `extsw` follow similar logic. Interestingly there is +no loss of functionality compared to keeping `extsb` always as "byte +sign-extending" and ironically the loss of opportunity *is* to keep +`extsb` the same (extend *byte* regardless of XLEN). + +[[!tag opf_rfc]] + +\newpage{} + diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index 558ba7663..e0b72a634 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -84,7 +84,7 @@ decades. Related RFCs are [[ls008]] for the two Management instructions `setvl` and `svstep`, and [[ls009]] for the REMAP Subsystem. Also [[ls001]] is a Dependency as it introduces Primary Opcode 9 64-bit encoding. An -additional RFC [[ls005]] introduced XLEN on which SVP64 is also critically +additional RFC [[ls005.xlen]] introduced XLEN on which SVP64 is also critically dependent, for Element-width Overrides. **Changes**