From a539e84f7ede90480eeb7bd871923a4c45ada829 Mon Sep 17 00:00:00 2001 From: Jan Gray Date: Wed, 8 May 2024 01:36:17 -0700 Subject: [PATCH] streamline --- charter.adoc | 79 +++++++++++----------------------------------------- 1 file changed, 17 insertions(+), 62 deletions(-) diff --git a/charter.adoc b/charter.adoc index 39dd35b..061bf03 100644 --- a/charter.adoc +++ b/charter.adoc @@ -17,8 +17,7 @@ modules, remaining backwards compatible with legacy custom extensions. * *CX multiplexing* enables multiple CXs to coexist within a system, conflict free; software selects the hart’s CX and CX state context, - prior to issuing that CX’s custom instructions and accessing its - custom CSRs. + prior to issuing CX custom instructions and CX CSR accesses. * *CX access control* enables more privileged code to grant/deny less privileged code access to specific CXs and state contexts. @@ -27,18 +26,14 @@ modules, remaining backwards compatible with legacy custom extensions. CX state contexts and an OS to save, reload, and manage any CX state context. -* *CX API* provides CX libraries with a uniform CX programming model, - including CX naming, discovery, versioning, state management, and - error handling. +* *CX API* provides a uniform CX programming model, including CX naming, + discovery, versioning, state management, and error handling. * *CX ABI* ensures correct nested library composition via disciplined - management of CX multiplexing state and CX state context. + management of CX multiplexing. -* *CXU logic interface* is an optional interop interface standard enabling - reuse of modular CXU hardware via automated composition of a DAG of - CPUs and CXUs into one system. With CXU-LI, each CXU implements one - or more CXs, and, in response to a CX instruction, muxing delegates - it to the selected CX/CXU. +* *CXU logic interface*, optional, enables modular CXU hardware and + automated composition of a DAG of CPUs and CXUs into one system. The TG specifications should aim to balance these design tenets: @@ -48,37 +43,29 @@ when used alongside other CXs. 2. *Decentralization:* Anyone may define or use a CX without coordination with others, and without resort to a central authority. -3. *Stable binaries:* CX library *binaries* compose without rewriting, -recompilation or relinking. +3. *Stable binaries:* CX library *binaries* compose without recompilation +or relinking. 4. *Composable hardware:* Adding a CXU to a system does not require modification of other CPUs or CXUs. 5. *Frugality:* Prefer simpler induced hardware and shorter code paths. -6. *Security:* The specifications include a security assessment to -ensure composable extensions do not introduce extension or system -vulnerabilities, and do not facilitate new side channel attacks. +6. *Security:* The specifications include a security assessment, and do +not facilitate new side channel attacks. 7. *Longevity:* The specifications incorporate mechanisms to improve -forwards compatibility with future composable extensions specifications. +forwards compatibility with future CX specifications. ## Acceptance criteria -Each deliverable must be implemented and proven in nontrivial interop +Each deliverable will be implemented and proven in nontrivial interop plug-fest scenarios involving multiple processors x extensions x extension libraries x OSs. -REVIEW: SAIL, Spike, QEMU? - ## Exclusions -Not every arbitrary custom extension can be a composable extension, so -the CX TG will specify which custom extensions are composable extensions. -Custom extensions that access only extension state and integer registers -are composable extensions, whereas other custom extensions that access -e.g., floating point registers, vector registers, shared memory, arbitrary -CSRs, etc., _may or may not be_ (yet to be determined). +Not every arbitrary custom extension can be a composable extension. The CX TG is focused on the minimum set of standards *enabling* practical composition of extensions and software. Further standards @@ -90,42 +77,11 @@ and tools, are _out of scope_. The CX TG governing committee is Privileged IC. -The CX framework will enable many ongoing and future unpriv extension -TGs to provide their extension as a composable extension. CX multiplexing -reduces the opcode and CSR impact of such extensions to zero, extending -the life of the 32b encodings. In addition, CX discovery and versioning -provides such extensions a uniform forwards compatible versioning story. -A modular CXU implementation would enable that extension in any -CXU-LI-compliant CPU cores. - -The CX TG will interact with: Unified Discovery TG, Platform Runtime -Services TG, SoftCPU SIG, Toolchains & Runtimes SIG. - -REVIEW: what about RISE, RVM-CSI SIG? - -### Possible Overlaps - -The CX TG will ensure its specification(s) harmonize and resolve overlaps -with the following TGs and specifications notwithstanding the objective -of routine, practical reuse of composable custom extensions. - -* CX muxing ISA and CX state context management ISA may overlap Smstateen/Ssstateen - -* CX muxing ISA's support for custom CSRs may overlap Smcrind/Sscrind +The CX framework will enable certain ongoing and future unpriv extension +TGs to provide their extension as a composable extension and a CXU module. -* CX API's CX discovery services may overlap - - * tech-config (Unified Discovery) to convey system config to machine mode - - * tech-prs (Platform Runtime Services) to convey system config to - supervisor mode (devicetree, UEFI), SBI if necessary - -* CX ABI may overlap - - * tech-psabi (ABI) - - * sig-toolchains for compiler ABI support, function attributes and/or - intrinsics +The CX TG may interact with: Unified Discovery TG, Platform Runtime +Services TG, SoftCPU SIG, Toolchains & Runtimes SIG, psABI. ## History @@ -138,4 +94,3 @@ extensions and libraries. In 2019-2022, members met to define a *minimum viable set* of interop interfaces, now the [Draft Proposed RISC-V Composable Custom Extensions Specification](https://raw.githubusercontent.com/grayresearch/CX/main/spec/spec.pdf), proposed as a basis (reference) spec for CX TG. -