introducing Composable Extensions, and invitation to participate
48 views
Skip to first unread message
Jan Gray
Apr 25, 2024, 5:11:13 PMApr 25
to isa...@groups.riscv.org, Darius Rad, tech-composab...@lists.riscv.org
Greetings.
The Soft CPU SIG was formed in 2019 to advance RISC-V for FPGA SoCs, and on behalf of RISC-V, has developed strategies, gap analyses, prioritizations, and plans. See the SIG charter [1], mailing list [2], archives [3], and Github repository [4].
This post is a consolidated summary of work done by the team to date on Composable Extensions ("CX"), investigating and proposing standards for routine reuse of certain (accelerator-ish) kinds of RISC-V custom extensions' software and hardware. We review CX history, objectives, key ideas, its pending task group status, and how to participate in the work going forward.
HISTORY AND OBJECTIVES
FPGA SoCs have a unique capability to rapidly implement domain-specific accelerators. Accelerators may be coupled to software via custom instructions of a RISC-V custom extension. In its gap analysis, the SIG identified a need for new standards to enable truly reusable custom extensions, their software libraries, and hardware units (collectively "extensions IP"), so that designers can create IP that just works, coexisting alongside others, in any conforming system. This enables a marketplace, so such IP reaches the broadest possible market, and so CPU and SoC designers may draw upon a rich IP catalog.
Although RISC-V reserves custom instruction opcodes and custom CSR addresses for anyone to define their own custom extensions [5], reuse of multiple custom extensions, together, is problematic, because separately authored extensions may conflict in use of custom instructions or CSRs, and because there is no common programming model or hardware logic interface. When everyone invents their own way, collectively we tend to get disjoint solution silos.
The custom opcode collision problem was known before the SIG formed. In this 2018 isa-dev thread [6], Guy Lemieux and correspondents discuss a possible mitigation via CSR-based custom extension mode switching. By 2019, the SIG was working on custom extensions reuse and composition (then called "CFUs") [7]: "[CFUs] aims to enable robust composition of independently authored CPU and CFU cores and software [for] a rich ecosystem of interoperable, app-optimized CFU cores and libraries". Renamed "Composable Extensions", the work continued on-and-off through the pandemic, culminating in the SIG's Draft Proposed RISC-V Composable Custom Extensions Specification [8] and other collateral [9][10][11].
Spinouts: In 2020, Charles Papon added the CFU logic interface to VexRiscv [12], the RISC-V core for Google's CFU Playground [13] toolkit for custom extensions for TinyML. A custom-instruction-extensible VexRiscv is also the hard quad-core RISC-V in Efinix Titanium FPGAs [14]. Lattice's RX RISC-V soft processor [15] implements some of the draft spec's proposed ISA extensions and logic interface.
KEY IDEAS
First, definitions: Composable extensions are a new, optional, backwards compatible, managed *subcategory* of custom extensions. Each composable extension (CX) is a named, immutable ISA contract specifying new instructions, state, and behavior. A CX Unit (CXU) is a modular hardware core that implements one or more CXs. CX software first *selects* the hart's current CX prior to issuing CX instructions.
Some key ideas:
1. Relocation-based CX composition: By shipping CX software with certain pending linker relocations, conflicting custom instructions might be automatically relocated to disjoint conflict-free custom instructions (per target system). The interconnect that composes CXUs accounts for this. (This approach was set aside for CX multiplexing.)
2. CX multiplexing: A proposed "CX muxing" ISA extension provides a CX selector CSR. CX aware software writes this to select the hart's current custom extension and state context, prior to issuing CX instructions. For backwards compatibility, the CSR can also select the CPU's built-in custom instructions. A CX status CSR accumulates any errors arising from CX multiplexing.
3. CX privileged access control: A proposed "CX access control" ISA extension provides an OS-managed per-hart selector table (inaccessible to user code), a privileged CSR to specify a hart's selector table base, and a user CSR to directly select (index) some entry in the table.
4. CX state contexts: CX custom instructions may be stateful, e.g., a matrix extension might have a private matrix register file. CX state contexts are isolated, for invariance under composition. A CX state context may have its own custom CSRs. A CX may have multiple state contexts; a stateless CX has none. There is usually one CX state context per CX per hart, but that's not mandatory. CX muxing selects the hart's current CX state context.
5. CX-agnostic CX state context management: A proposed "CX state context" ISA extension mandates CX CSRs to help manage a CX state context, initialize a CX state context, and save/restore a CX state context to/from a blob, word-by-word, so that a CX-aware OS can support any stateful CX, unchanged.
6. Decentralized IDs: Anyone may define a new CX without resort to a central authority. As with Microsoft COM [16], the creator of a new CX *self-mints* a canonical 128b CX_GUID (globally unique ID, RFC-4112) as the key for all software and hardware references to the CX. All other IDs are scoped to the CX, or to the local system.
7. Uniform programming model: For CX library programming, there should be one sound, good enough way of doing most things: uniform naming, discovering, versioning, conflict-free encodings, extension state, state sharing, access control, and error handling, all expressed in a standard CX API and ABI.
8. A common logic interface: A proposed optional standard CXU logic interface (CXU-LI), and metadata, enable automatic composition of complexes of CPUs and a DAG of CXUs, without changing CPU or CXU designs. CXU-LI supports simple or complex CPUs and CXUs, with combinational, fixed latency, or variable latency signaling.
9. Uniform CX versioning. Proposed CX ISA and non-ISA forward compatibility mechanisms anticipate CX reuse and interoperation across decades. A proposed uniform versioning model ensures that old and new CX code just works with old and new CX hardware versions, side-by-side. A single CXU might implement new and old versions of a composable extension.
10. CX emulation: A proposed "custom instruction exception enable" bit in the CX selector CSR supports CX emulation and transparent multiplexing of logical CX state contexts upon one physical context.
DELIVERABLES AND PROOF OF CONCEPT
The CX Task Group proposes to specify ISA extension(s) 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 existing custom extensions. These proposed standards will be proven in a series of Composition Plug-Fests demonstrating interoperation of various RISC-V CPUs × CXs × CXUs × CX libraries × apps x OSs × platforms. [17]
PENDING TASK GROUP STATUS
CX is in the process of moving from the SIG into a proposed Composable Extensions Task Group (CX TG) to undertake RVIA's standards lifecycle. Per the Group Lifecycle Guide [18], the nascent group is at the Group Pending Milestone. The governing committee is PRIV IC. The CX TG acting chair is Darius Rad (Bluespec), and acting vice-chair is Jan Gray (Individual).
Check out the CX Task Group Proposal video: [10] (15 mins).
JOIN US!
RVIA members (only) are invited to support and participate in this work. We will require your expertise in architecture, hardware, software, tools, verification, security, and other areas.
For news, meetings logistics, draft charter review, and ongoing discussions, please join the new tech-composable-extensions mailing list [19]. Please follow up to this list. To join RVIA: [20].
Thank you,
Darius Rad, Bluespec, CX TG acting chair
Jan Gray, Individual, CX TG acting vice-chair
[Links]
[1] Soft CPU SIG Charter: https://github.com/riscv-admin/sig-soft-cpu/blob/main/CHARTER.md
[2] Soft CPU SIG List: https://lists.riscv.org/g/sig-soft-cpu/
[3] Soft CPU SIG List Archive: https://lists.riscv.org/g/sig-soft-cpu-archive/
[4] Soft CPU SIG Github Repo: https://github.com/riscv-admin/sig-soft-cpu
[5] The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA, chapter 26: Extending RISC-V
[6] isa-dev thread: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/InzQ1wr_3Ak/m/KCJZzfKuAwAJ
[7] 2019 (draft 0.1) Composable Custom Function Unit Spec: https://cfu.readthedocs.io
[8] Draft Proposed RISC-V Composable Custom Extensions Specification: https://raw.githubusercontent.com/grayresearch/CX/main/spec/spec.pdf
[9] CX Github Repo: https://github.com/grayresearch/cx
[10] CX Task Group Proposal: https://www.youtube.com/watch?v=OgdtLnT-64g
[11] CX Design and Rationale talk: https://www.youtube.com/watch?v=7daY_E2itpo
[12] VexRiscv: https://github.com/SpinalHDL/VexRiscv
[13] CFU Playground: https://github.com/google/CFU-Playground
[14] Efinix Titanium FPGAs: https://www.efinixinc.com/shop/ti375.php
[15] Lattice RX RISC-V soft processor: https://www.latticesemi.com/products/designsoftwareandip/intellectualproperty/ipcore/ipcores04/risc-v-rx-cpu
[16] Microsoft COM: https://learn.microsoft.com/en-us/windows/win32/com/com-technical-overview
[17] Draft Charter of the Composable Extensions Task Group: https://github.com/riscv-admin/sig-soft-cpu/blob/main/TG/CX/CHARTER.md
[18] RISC-V Lifecycle Guide. https://docs.google.com/document/d/1Au3veNdNJQKPq-oiQRKTzdgmM72FDaqZOKeH7sOnG04
[19] Composable Extensions TG mailing list: https://lists.riscv.org/g/tech-composable-extensions
[20] RISC-V Membership: https://riscv.org/membership/
The Soft CPU SIG was formed in 2019 to advance RISC-V for FPGA SoCs, and on behalf of RISC-V, has developed strategies, gap analyses, prioritizations, and plans. See the SIG charter [1], mailing list [2], archives [3], and Github repository [4].
This post is a consolidated summary of work done by the team to date on Composable Extensions ("CX"), investigating and proposing standards for routine reuse of certain (accelerator-ish) kinds of RISC-V custom extensions' software and hardware. We review CX history, objectives, key ideas, its pending task group status, and how to participate in the work going forward.
HISTORY AND OBJECTIVES
FPGA SoCs have a unique capability to rapidly implement domain-specific accelerators. Accelerators may be coupled to software via custom instructions of a RISC-V custom extension. In its gap analysis, the SIG identified a need for new standards to enable truly reusable custom extensions, their software libraries, and hardware units (collectively "extensions IP"), so that designers can create IP that just works, coexisting alongside others, in any conforming system. This enables a marketplace, so such IP reaches the broadest possible market, and so CPU and SoC designers may draw upon a rich IP catalog.
Although RISC-V reserves custom instruction opcodes and custom CSR addresses for anyone to define their own custom extensions [5], reuse of multiple custom extensions, together, is problematic, because separately authored extensions may conflict in use of custom instructions or CSRs, and because there is no common programming model or hardware logic interface. When everyone invents their own way, collectively we tend to get disjoint solution silos.
The custom opcode collision problem was known before the SIG formed. In this 2018 isa-dev thread [6], Guy Lemieux and correspondents discuss a possible mitigation via CSR-based custom extension mode switching. By 2019, the SIG was working on custom extensions reuse and composition (then called "CFUs") [7]: "[CFUs] aims to enable robust composition of independently authored CPU and CFU cores and software [for] a rich ecosystem of interoperable, app-optimized CFU cores and libraries". Renamed "Composable Extensions", the work continued on-and-off through the pandemic, culminating in the SIG's Draft Proposed RISC-V Composable Custom Extensions Specification [8] and other collateral [9][10][11].
Spinouts: In 2020, Charles Papon added the CFU logic interface to VexRiscv [12], the RISC-V core for Google's CFU Playground [13] toolkit for custom extensions for TinyML. A custom-instruction-extensible VexRiscv is also the hard quad-core RISC-V in Efinix Titanium FPGAs [14]. Lattice's RX RISC-V soft processor [15] implements some of the draft spec's proposed ISA extensions and logic interface.
KEY IDEAS
First, definitions: Composable extensions are a new, optional, backwards compatible, managed *subcategory* of custom extensions. Each composable extension (CX) is a named, immutable ISA contract specifying new instructions, state, and behavior. A CX Unit (CXU) is a modular hardware core that implements one or more CXs. CX software first *selects* the hart's current CX prior to issuing CX instructions.
Some key ideas:
1. Relocation-based CX composition: By shipping CX software with certain pending linker relocations, conflicting custom instructions might be automatically relocated to disjoint conflict-free custom instructions (per target system). The interconnect that composes CXUs accounts for this. (This approach was set aside for CX multiplexing.)
2. CX multiplexing: A proposed "CX muxing" ISA extension provides a CX selector CSR. CX aware software writes this to select the hart's current custom extension and state context, prior to issuing CX instructions. For backwards compatibility, the CSR can also select the CPU's built-in custom instructions. A CX status CSR accumulates any errors arising from CX multiplexing.
3. CX privileged access control: A proposed "CX access control" ISA extension provides an OS-managed per-hart selector table (inaccessible to user code), a privileged CSR to specify a hart's selector table base, and a user CSR to directly select (index) some entry in the table.
4. CX state contexts: CX custom instructions may be stateful, e.g., a matrix extension might have a private matrix register file. CX state contexts are isolated, for invariance under composition. A CX state context may have its own custom CSRs. A CX may have multiple state contexts; a stateless CX has none. There is usually one CX state context per CX per hart, but that's not mandatory. CX muxing selects the hart's current CX state context.
5. CX-agnostic CX state context management: A proposed "CX state context" ISA extension mandates CX CSRs to help manage a CX state context, initialize a CX state context, and save/restore a CX state context to/from a blob, word-by-word, so that a CX-aware OS can support any stateful CX, unchanged.
6. Decentralized IDs: Anyone may define a new CX without resort to a central authority. As with Microsoft COM [16], the creator of a new CX *self-mints* a canonical 128b CX_GUID (globally unique ID, RFC-4112) as the key for all software and hardware references to the CX. All other IDs are scoped to the CX, or to the local system.
7. Uniform programming model: For CX library programming, there should be one sound, good enough way of doing most things: uniform naming, discovering, versioning, conflict-free encodings, extension state, state sharing, access control, and error handling, all expressed in a standard CX API and ABI.
8. A common logic interface: A proposed optional standard CXU logic interface (CXU-LI), and metadata, enable automatic composition of complexes of CPUs and a DAG of CXUs, without changing CPU or CXU designs. CXU-LI supports simple or complex CPUs and CXUs, with combinational, fixed latency, or variable latency signaling.
9. Uniform CX versioning. Proposed CX ISA and non-ISA forward compatibility mechanisms anticipate CX reuse and interoperation across decades. A proposed uniform versioning model ensures that old and new CX code just works with old and new CX hardware versions, side-by-side. A single CXU might implement new and old versions of a composable extension.
10. CX emulation: A proposed "custom instruction exception enable" bit in the CX selector CSR supports CX emulation and transparent multiplexing of logical CX state contexts upon one physical context.
DELIVERABLES AND PROOF OF CONCEPT
The CX Task Group proposes to specify ISA extension(s) 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 existing custom extensions. These proposed standards will be proven in a series of Composition Plug-Fests demonstrating interoperation of various RISC-V CPUs × CXs × CXUs × CX libraries × apps x OSs × platforms. [17]
PENDING TASK GROUP STATUS
CX is in the process of moving from the SIG into a proposed Composable Extensions Task Group (CX TG) to undertake RVIA's standards lifecycle. Per the Group Lifecycle Guide [18], the nascent group is at the Group Pending Milestone. The governing committee is PRIV IC. The CX TG acting chair is Darius Rad (Bluespec), and acting vice-chair is Jan Gray (Individual).
Check out the CX Task Group Proposal video: [10] (15 mins).
JOIN US!
RVIA members (only) are invited to support and participate in this work. We will require your expertise in architecture, hardware, software, tools, verification, security, and other areas.
For news, meetings logistics, draft charter review, and ongoing discussions, please join the new tech-composable-extensions mailing list [19]. Please follow up to this list. To join RVIA: [20].
Thank you,
Darius Rad, Bluespec, CX TG acting chair
Jan Gray, Individual, CX TG acting vice-chair
[Links]
[1] Soft CPU SIG Charter: https://github.com/riscv-admin/sig-soft-cpu/blob/main/CHARTER.md
[2] Soft CPU SIG List: https://lists.riscv.org/g/sig-soft-cpu/
[3] Soft CPU SIG List Archive: https://lists.riscv.org/g/sig-soft-cpu-archive/
[4] Soft CPU SIG Github Repo: https://github.com/riscv-admin/sig-soft-cpu
[5] The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA, chapter 26: Extending RISC-V
[6] isa-dev thread: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/InzQ1wr_3Ak/m/KCJZzfKuAwAJ
[7] 2019 (draft 0.1) Composable Custom Function Unit Spec: https://cfu.readthedocs.io
[8] Draft Proposed RISC-V Composable Custom Extensions Specification: https://raw.githubusercontent.com/grayresearch/CX/main/spec/spec.pdf
[9] CX Github Repo: https://github.com/grayresearch/cx
[10] CX Task Group Proposal: https://www.youtube.com/watch?v=OgdtLnT-64g
[11] CX Design and Rationale talk: https://www.youtube.com/watch?v=7daY_E2itpo
[12] VexRiscv: https://github.com/SpinalHDL/VexRiscv
[13] CFU Playground: https://github.com/google/CFU-Playground
[14] Efinix Titanium FPGAs: https://www.efinixinc.com/shop/ti375.php
[15] Lattice RX RISC-V soft processor: https://www.latticesemi.com/products/designsoftwareandip/intellectualproperty/ipcore/ipcores04/risc-v-rx-cpu
[16] Microsoft COM: https://learn.microsoft.com/en-us/windows/win32/com/com-technical-overview
[17] Draft Charter of the Composable Extensions Task Group: https://github.com/riscv-admin/sig-soft-cpu/blob/main/TG/CX/CHARTER.md
[18] RISC-V Lifecycle Guide. https://docs.google.com/document/d/1Au3veNdNJQKPq-oiQRKTzdgmM72FDaqZOKeH7sOnG04
[19] Composable Extensions TG mailing list: https://lists.riscv.org/g/tech-composable-extensions
[20] RISC-V Membership: https://riscv.org/membership/
Reply all
Reply to author
Forward
0 new messages