generated from riscv-admin/template-group-admin
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
99e7be4
commit e825626
Showing
1 changed file
with
64 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
--- | ||
title: "Composable Custom Extensions TG Meeting" | ||
author: Darius Rad `<darius@bluespec.com>`$\newline$Jan Gray `<jan@fpga.org>` | ||
date: 26 September 2024 | ||
output: beamer_presentation | ||
theme: "Warsaw" | ||
--- | ||
|
||
## Disclosures | ||
|
||
<https://wiki.riscv.org/display/HOME/Meeting+Disclosures> | ||
|
||
## Agenda | ||
|
||
- Final charter review status | ||
- Requirements discussion status | ||
- Draft ratification plan | ||
- Ad-hoc meeting recap (opcodes) | ||
|
||
## Final charter review status | ||
|
||
### | ||
|
||
Reuse of multiple custom extensions is rare, in part because custom | ||
extensions may conflict in use of custom instructions and CSRs, and | ||
because there is no common programming model or API for custom | ||
extensions. This can lead to disjoint solution silos and ecosystem | ||
fragmentation. To help address this gap, the TG will advance interop | ||
standards that make it easier to reuse certain kinds of custom | ||
extensions, enabling a plug-and-play ecosystem of such extensions. | ||
|
||
The TG will define a framework of ISA and non-ISA specifications that | ||
together facilitate the decentralized, cooperative reuse of the custom | ||
instruction and custom CSR space, enabling practical reuse, within a | ||
system, of multiple, independently authored composable custom extensions | ||
(CXs), CX libraries, and CX unit (CXU) logic modules, while also remaining | ||
backwards compatible with legacy custom extensions. | ||
|
||
### | ||
|
||
- Please raise any issues soon | ||
|
||
## Requirements discussion status | ||
|
||
- Discussion on list | ||
- Major topics of discussion | ||
- Extension state (one/many, hart state or not) | ||
- Opcodes (all custom opcodes or subset, one/multiple ranges) | ||
- Hotpluggable extensions | ||
- Logic interface capabilities | ||
|
||
## Draft ratification plan | ||
|
||
- Requirements → work breakdown structure → freeze date | ||
- Work breakdown structure in repository, discussion to begin soon | ||
|
||
## Ad-hoc meeting recap (opcodes) | ||
|
||
- No consensus reached, no decisions made | ||
- There was some question about opcode usage in existing legacy custom extensions | ||
- Which major custom opcodes are in use | ||
- How may opcodes are used by each custom extension | ||
- Might be worth a survey to collect data, if can be done in a timely fashion | ||
- Requirements regarding handling legacy custom extensions may need to be refined |