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.
minutes of requirements meeting on single vs. multiple CX state contexts
- Loading branch information
Showing
1 changed file
with
52 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,52 @@ | ||
# Meeting Minutes 2024-08-13 | ||
|
||
- CX TG Requirements Ad-Hoc Meeting: Single or Multiple Contexts | ||
|
||
- Attendees | ||
|
||
Darius Rad (Bluespec) | ||
Jan Gray (Individual) | ||
Guy Lemieux (Individual) | ||
Victor Lu (Individual) | ||
|
||
- Discussion | ||
|
||
Jan proposed meeting rules, objectives (better mutual understanding of | ||
the proposals, but not a decision). | ||
|
||
Guy asked for clarification about the specific topic of the discussion. | ||
Darius stated that the topic is multiple potential requirements related | ||
to the general concept of one or multiple state contexts per hart, | ||
and not a simple binary question. | ||
|
||
Jan presented his position that multiple state contexts per hart is a more | ||
novel, more complex, but more flexible, more performant, affordable, and | ||
preferable approach to achieve the goals of the task group. His position | ||
was presented from the perspective of the user programming model and | ||
suggested other perspectives be clear about which level of abstraction | ||
they are referring to. He described a number of use cases in support | ||
of this position. | ||
|
||
Guy questioned whether objection to multiple state contexts is due to | ||
memory table mechanism in basis specification, for which he is designing | ||
an alternative. | ||
|
||
Guy proposed the following requirements: | ||
* Must efficiently support hardware implementation for single context per hart | ||
* Should efficiently support hardware implementation for multiple contexts per hart | ||
* Must convey a single programming model in either case | ||
* Must support >1 context per thread without context switching | ||
|
||
Darius presented his position that a single state context per hart is more | ||
consistent with existing RISC-V extensions and that existing mechanisms | ||
for context management in the operating system and in user level software | ||
may be utilized to achieve the goals of the task group. He indicated | ||
that the behavior of one state context per hart is more consistent with | ||
the expected programming model at the ISA level in all privilege modes. | ||
|
||
There was discussion regarding whether a single state per hart or multiple | ||
states per hart need to be mutually exclusive requirements. | ||
|
||
There was discussion regarding whether extension state should be | ||
considered hart state, or not, or if both behaviors could be or should | ||
be supported. |