Update charter with Preliminary Draft Charter

charter.adoc

@@ -1,39 +1,104 @@
-= Composable Extensions Task Group Charter
+# Composable Extensions (CX) Task Group Charter
 
-== Introduction
+Reuse of multiple custom extensions is rare, in part because extensions
+may conflict in use of custom instructions and CSRs, and because there
+is no common programming model or API for discovering, using, and
+managing such extensions. This leads to disjoint solution silos and
+ecosystem fragmentation. This TG will fix this.
 
-The Composable Extensions Task Group aims to [INSERT CLEAR, CONCISE OVERALL MISSION STATEMENT IN 2-3 SENTENCES].
+The TG will specify ISA extension(s) (CX ISA) plus interop interface
+standards (CX API, CX ABI, and CX Unit logic interface (CXU-LI)) that
+enable practical reuse, within a system, of multiple, independently
+authored composable custom extensions (CXs), CX libraries, and CX unit
+modules, remaining backwards compatible with legacy custom extensions.
 
-== Definitions (Optional)
+* *CX ISA* extension(s) provide CX multiplexing (muxing), CX access control,
+  and CX state context management.
 
-[TERM 1] refers to [DEFINITION 1]. It is critical because [EXPLAIN SIGNIFICANCE]. [INCLUDE ADDITIONAL TERMS/DEFINITIONS IF REQUIRED].
+  * *CX muxing* 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.
+  
+  * *CX access control* enables priv code to grant/deny unpriv code access
+    to specific CX state contexts.
+  
+  * *CX state context management* enables an OS to save, reload, and manage
+    any CX state context.
 
-== Background
+* *CX API* provides CX libraries with a uniform CX programming model,
+  including CX naming, discovery, versioning, state management, and
+  error handling.
 
-[PROVIDE CONTEXT ABOUT THE GROUP'S RELEVANCE AND ANY PERTINENT TECHNOLOGY].
+* *CX ABI* ensures correct nested library composition via disciplined
+  save/restore of the CX mux selection.
 
-== Objectives
+* *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.
 
-The {New Group Name} {New Group Type} is committed to delivering [SPECIFY DELIVERABLE] with the following attributes:
+The TG specifications should aim to balance these design tenets:
 
-* [ATTRIBUTE 1]
-* [ATTRIBUTE 2]
-* [ADD MORE AS REQUIRED]
+1. *Composability:* The behavior of a CX or CX library does not change
+when used alongside other CXs.
 
-== Exclusions (Optional)
+2. *Decentralization:* Anyone may define or use a CX without coordination
+with others, and without resort to a central authority.
 
-While not currently in scope, the following items may be considered for future iterations:
+3. *Stable binaries:* CX library *binaries* compose without rewriting,
+recompilation or relinking.
 
-* [FEATURE 1]
-* [FEATURE 2]
-* [ADD MORE AS REQUIRED]
+4. *Composable hardware:* Adding a CXU to a system does not require
+modification of other CPUs or CXUs.
 
-== Collaborations
+5. *Frugality:* Prefer simpler induced hardware and shorter code paths.
 
-To fulfill its objectives, the {New Group Name} {New Group Type} will engage with:
+6. *Security:* The specifications include a vulnerability assessment
+and do not facilitate new side channel attacks.
 
-* [GROUP NAME 1] [GROUP TYPE 1]
-* [GROUP NAME 2] [GROUP TYPE 2]
-* [ADDITIONAL GROUPS AS NEEDED]
+7. *Longevity:* The specifications define how each interface may be
+versioned over decades, and incorporate mechanisms to improve forwards
+compatibility.
 
-NOTE: Ensure to replace all placeholders ({ }) with the actual names or information and remove any optional sections that are not applicable to your charter. Also, remove this note :)
+## Acceptance criteria
+
+Each deliverable must be implemented and proven in nontrivial interop
+plugfest scenarios involving multiple processors x extensions x extension
+libraries x OSs.
+
+## Exclusions
+
+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
+for infrastructure and tooling e.g. for CX packages, debug, profile,
+formal specification of CX interface contracts, CX library metadata,
+and tools, are _out of scope_.
+
+## Collaborations
+
+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.
+
+### Overlaps (incomplete!)
+
+* CX API's CX discovery services may overlap uniform discovery TG
+
+## History
+
+In 2019, the RISC-V Foundation FPGA soft processor SIG members, working
+to advance RISC-V as the preeminent ecosystem for FPGA SoCs, committed to
+"Propose extensions ... to enable interoperable RISC-V FPGA platforms and
+applications". Members set out to define standards by which FPGAs'
+extensible RISC-V cores might enable a marketplace of reusable custom
+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 starting point for CX TG.