...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Disclosures
| Expand | ||
|---|---|---|
| ||
Participants
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Voters | Quorum Required - 16
Non-Voters
|
Agenda
...
| Expand | ||
|---|---|---|
| ||
As the SoftCPU SIG Chair, I am in frequent contact with the technical leads for "soft" processor designs (ie, LUT-based rather than ASIC) used at all of the major FPGA companies. This puts me in a unique position to collect and share the needs of these RISC-V members with the TSC. (Note that all major US-based FPGA companies are RISC-V members: Altera, AMD, Efinix, Lattice, Microchip, and Bluespec supplies Achronix with processors... I'm unsure about the status of Quicklogic, or some of the newer non-US-based FPGA companies). As a result, I have been reaching out to individuals, SIGs, and TGs about technical design objectives for RISC-V, listed below, which have been expressed from both AMD and Altera. Most of these objectives/issues have been discussed at the SoftCPU SIG already, although some of them are newer and have not been as thoroughly discussed as others. The hope is that these issues can be addressed in 2025. I will also be reaching out to ensure that other FPGA companies are also on board (not all of them have the time capacity to attend SoftCPU SIG meetings), but I expect this will not be a problem. I have a few reasons for sharing this list with the whole TSC:
Here is the list of objectives/issues: a) CLIC needs to be ratified. What's the holdup? How can we kickstart it again? AMD is already designing their own and Altera is ironically unhappy with it not being "locked down". (I say ironically, because it's the FPGA people that are worried about finalizing a standard -- and they're the ones that are most flexible! I can only imagine how everyone else feels.) With the recent discussion in the Profiles SIG and CSC around clarifying exactly what is being certified, it seems that an interrupt controller needs to be added to a profile to create something like a "processor subsystem" that gets certified. b) Additional support for fast interrupts via a shadow register file. c) Reg+Reg addressing modes (rather than Reg+Imm). d) 64b addressing mode for RV32, eg via concatenation of 2 registers. Please note that saying "RV64 solves this" is not the answer they are looking for, because a full 64b CPU datapath is too large for typical FPGA use. With a single DRAM capable of filling the entire 4GB address space, more bits are needed for other things. e) Bitfield insertion/extraction instructions. f) New cache management instructions to invalidate, flush and clean by cache index rather than by address. g) Soft-processor specific profiles, which we are calling RVS. This would be a "family", like RVA, which has several variants inside. It would fit somewhere between RVB and RVM. I know many of these things take a new TG, and some might be suitable for Fast Track. Most of the items above also have other supporters beyond soft CPUs, so the SoftCPU SIG is trying to identify the right route and partner for each of them. I look forward to all suggestions and discussion. Thank you, Guy |
Presentations
Title | Presenter | File | |||||
|---|---|---|---|---|---|---|---|
| 1 | Tech Committee Meetings | Andrea Gallo |
| ||||
| 2 | Machine Readable Format | Andrea Gallo |
| ||||
| 3 | 2025 Technical Objective (SoftCPU SIG) | Guy LemieuxPresentation |
| ||||
| 4 | UnifiedDB SIG Proposal | Derek Hower, QualcommPresentation |
|
Votes
| Expand | ||
|---|---|---|
| ||
Quorum Status: 17 Voters
Voting Results:
Outcome: Motion Approved Additional Notes: Approval time was 0:24 into meeting |
| Expand | ||
|---|---|---|
| ||
Quorum Status: 17 Voters
Voting Results:
Outcome: Motion Approved Additional Notes: Time of vote 0:25 into meeting |
Notes & Action Items
- From Guy Lemieux clarify his question on quorum requirements (
).Jira Legacy server System Jira serverId 4d3dce95-b4be-35da-b49f-ec8432d8f473 key RVP-28
Meeting Summary:
November and January meeting minutes approved.
Working Meeting Proposal for TSC, Tech Chairs, Tech Committee Chair Coordination
...
Under guidance from John Hengeveld, the schedule of meetings falls under the governance of the Chairs and thus no additional approval is needed.
...
The RISC-V Staff will work with leadership to make adjustments.
...
Machine Readable Format
- Review of the slides with discussion
- Key topics/points:
- Redundancy in op code syntax in many places
- Manual process of tagging requirements in spec is a massive effort to enable certification
- Syntax and semantics need to understood as being different
- It will be difficult to have Machine Readable information for everything
- Andrea will proceed with 1, 2, & 4 disconnects. Will also ensure that 3 includes SME folks.
- Discussion required to understand what role Unified DB can do to assist/improve the picture.
- Andrea Gallo will share a PDF version of his presentation.
...
Andrea Gallo spearheaded the discussion using the slides on the machine-readable format, emphasizing the need for a single source of truth for the ISA to ensure traceability, consistency, and eliminate manual duplication. The envisioned format should encompass the base ISA, ratified extensions, CSRs, and configurable options, serving as the foundation for generating specifications, test plans, test suites, verification models, and exports to DV tools.
Gaps identified:
The absence of automatic connection between the RISC-V opcodes repo (in JSON) and the GitHub documentation (in AsciiDoc).
Manual duplication of information between the RISC-V opcodes repo and the specification.
The manual process of tagging the specification for test plan generation.
The disconnect between Sail files (the reference model) and the RISC-V opcodes repo.
Additional considerations:
Clarification on Test Plan Generation: Derek Hower clarified that the test plan generation from tagged specifications isn't fully automatic; it involves a manual step to identify coverage points and link them to the tags.
Syntax vs. Semantics: Krste Asanovic emphasized the distinction between syntax and semantics, highlighting that a machine-readable format might not capture all semantics due to the complexities introduced by various options.
Ideal Flow and Human Factors: While Andrea Gallo envisioned the machine-readable format as the ultimate source of truth after ratification, Jeff Scheel underscored the human factor, stating that development often begins with the written word.
Co-Development of Representations: Philipp Tomsich mentioned instances where the machine-readable representation (e.g., in Sail) and the written word were developed concurrently.
Challenges in Capturing Semantics: Krste Asanovic cautioned that capturing all semantics in a machine-readable format, especially with numerous options, is currently beyond the state of the art.
The Role of Sail: Philipp Tomsich reminded that Sail was chosen as the language for the Golden model, which, ideally, should be the leading document, although the reality is currently different.
UnifiedDB SIG Proposal
Summary:
Derek Hower presented on the Unified DB project. He clarified that the presentation's purpose was to justify the creation of a SIG, not to explore all the potential uses and problems it could solve.
The community showed support for the project and acknowledged the need for a machine-readable format. There was discussion about the name, with members suggesting that "Unified DB" doesn't fully encompass its scope and purpose.
Questions were raised about the SIG's scope and whether it should be a Task Group (TG) instead.
Concerns were also raised about potential overlap with the Documentation SIG.
Krste Asanovic questioned the need for a separate SIG, suggesting that the work could be done within the Documentation SIG and TGs.
The discussion also touched upon the process for creating new groups under the new policies and the need for a central place to decide on documentation and specification formats.
The meeting concluded without a clear consensus on the proposed plan of work and the appropriate next steps.
- Andrea Gallo will identify and work with a group of RISC-V Members in order to refactor/reword the current proposal.
Discussion around requests to the SoftCPU SIG
The slide has been updated to reflect current status. Please review and provide feedback.
This topic will be early on the agenda in the March meeting
Adjournment
Motion to Adjourn Made By: Kenneth Dockser
Seconded By: Philipp Tomsich
Time Adjourned: 9 2:00 PTinto meeting
...
