From: Luke Kenneth Casson Leighton Date: Thu, 22 Dec 2022 12:55:25 +0000 (+0000) Subject: add LS005 RFC X-Git-Tag: opf_rfc_ls005_v1~14 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=912fd242b5908f058dba75386ff16cb7dda0881d;p=libreriscv.git add LS005 RFC --- diff --git a/openpower/sv/rfc/Makefile b/openpower/sv/rfc/Makefile index 7f39f8fb4..804c854ee 100644 --- a/openpower/sv/rfc/Makefile +++ b/openpower/sv/rfc/Makefile @@ -1,4 +1,4 @@ -all: ls001.pdf ls002.pdf ls003.pdf +all: ls001.pdf ls002.pdf ls003.pdf ls004.pdf ls005.pdf %.pdf: %.mdwn pandoc \ diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn new file mode 100644 index 000000000..7f842984a --- /dev/null +++ b/openpower/sv/rfc/ls005.mdwn @@ -0,0 +1,102 @@ +# 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 + +**Target**: v3.2B + +**Source**: v3.0B + +**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. + +**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). + +---------------- + +\newpage{} +