2025-11-05 TSC Meeting
Date
Nov 5, 2025
Disclosures
Participants
Agenda
Past Meeting Minutes Approval
TSC
Fast Track approval review (link)
TSC Overflow Meeting - Nov 12th 2025
CSC
To raise awareness of the CSC’s extraction of normative rules from the ISA manuals
Explain how the normative rules will be used in certification
Discuss charter requirements for the group
Updated RISC-V Policies (Ken Dockser)
Presentations
Title | Presenter | File | |
|---|---|---|---|
| 1 | Golden Reference Model Survey | Derek Hower |
|
Votes
Notes & Action Items
Meeting recording and transcript: link
Meeting Summary
New TSC Member: Introduction of David Baker
The RISC-V Technical Steering Committee (TSC) meeting began with introductions and attendance updates. David Weaver announced his upcoming retirement and introduced David Baker as the new TSC representative from Akeana, effective November 15th. David Baker shared his extensive background in processor compilers and machine learning acceleration.
New Fast Track Proposal: Creation of O* Optimization Guidance Options (to guide HW and SW developers)
Krste presented optimization guidance proposals for ISA strings, focusing on two main options: OILSM and OVLT. OILSM aims to improve performance for misaligned scalar and vector load/store operations by allowing software to assume hardware will handle them efficiently, while OVLT ensures vector instructions execute based on the dynamic value of the VL register rather than the maximum vector length. The proposals are intended for use in Profiles and aim to improve performance across a wide range of implementations without providing detailed guidance for individual implementations.
The group discussed the proposal for mandating misaligned load/store performance features in RISC-V profiles, with Krste explaining that while current functional support exists, there's no performance guidance, leading to software workarounds. The discussion clarified that while hardware implementations aren't explicitly mandated to support these features, the profiles aim to guide software development and raise performance expectations for high-quality implementations, with the goal of making these features mandatory in future RVA profiles. The debate centered around whether this should be specified in profiles versus architecture strings, with Guy expressing concern about redundant specifications, while Krste emphasized the need for collective vendor agreement to improve RISC-V performance standards.
The group also discussed two potential RISC-V extensions related to vector length (VL) and LMUL functionality. Krste explained that software should not dynamically branch on VL to set LMUL, as this would create performance disadvantages for implementations that don't optimize for dynamic VL. The team agreed this would be formalized as a profile requirement after ratification, with Marcel noting it represents a two-step capability definition. Derek raised the question of whether a survey had been done regarding profile inclusion, which Krste confirmed had not yet been done. The discussion concluded with Tom noting this was an FYI item.
psABI Charter Update
The discussion focused on the PSA ABI Task Group, which Kito explained is not new but needs to be formally reestablished under the new governance system. The group aims to deliver the PSA ABI 2.0 release within a one-year term, incorporating new features like vector ABIs and vendor relocation. David Weaver pointed out a correction needed in the proposal regarding the term "Procedure Standard ABI." Jeff confirmed that an OPA vote would be the next step, and the group agreed to proceed with this action.
Unified Discovery (UD) Update
Greg provide an update on the disbandment of the Unified Discovery Task Group. The vote to disband the group has started and is ongoing. He explained that after several years of attempts to develop unified discovery solutions, the group is considering disbanding due to lack of progress. Greg also mentioned that new, more targeted discovery mechanisms might be explored in the future, particularly at the firmware level. Andrew inquired about the role of external debug in unified discovery, to which Greg responded that the initial motivation was indeed debug needs, but the scope had expanded over time. The conversation ended with a brief mention of a proposal for the configuration parameters test group, presented by Derek.
New Proposal of Work: Configuration Parameters TG
The task group will define parameters in the specification by creating a naming scheme and documenting all parameters, their values, and dependencies. They will start with basic parameters in RBI20 and work their way up to VA23, with the goal of incrementally integrating the defined parameters into the ISA manual. Derek explained that the CSC will use these parameters to develop certification tests, but not all parameters may be tested due to limitations in testing capabilities. Greg clarified that fully compliant implementations may not be able to receive certification if they require new tests.
The group discussed certification processes and agreed that certification cannot be denied due to incomplete testing, emphasizing the need for creative testing solutions. They debated the structure of work groups, with Krste proposing a task group focused on expanding naming schemes while keeping the process lightweight. The group agreed that if the TG was a SIG, the SIG could oversee extensions and fast tracks without creating a new task group for each, with Guy suggesting subcommittees as a lightweight alternative. Derek expressed concern about the process for every extension, but Krste noted that subsequent fast tracks should go more quickly once the initial process is understood.
The group discussed ratifying naming schemes for parameters in a backward-compatible way, similar to how profiles define options. They agreed this would involve pull requests to the ISA manual to add names and labels for existing parameters. Krista suggested creating a task group focused on the naming scheme to address issues like casual optionality and the need for a schema that captures various uses, including option naming. The group also discussed the potential for using existing work on Unified Discovery (UD) and encoding mechanisms, while noting that UD was not ISA string compatible.
The group discussed whether this work should be a separate task group or part of an existing SIG, ultimately deciding to create a new SIG to avoid potential delays and ensure dedicated focus.
The TSC approved moving forward with the parameter naming proposal to member review, with Derek tasked to update the proposal based on feedback before presenting it again for final approval.
New Golden Reference Model Survey
Derek covered a proposed survey on golden reference models, to understand member needs and usage patterns. The group discussed the attributes and importance of a golden reference model (GRM) for RISC-V. Ken emphasized the need for a formal specification that goes through a rigorous review process, while Krste highlighted that current formal models cannot capture all required behaviors and interactions. The team debated the survey questions about GRM attributes, with Krste and others expressing concerns about the leading nature of the questions and the assumption of a single GRM. They agreed to continue the discussion in an overflow meeting, with Derek tasked to start a thread on the TSC mailing list to facilitate further discussion.
Details
New TSC Member: Introduction of David Baker
David B will be assuming the role of Akeana TSC representative in the next meeting
He brings many years of experience, especially in the area of AI/ML
New Fast Track Proposal: Creation of O* Optimization Guidance Options (to guide HW and SW developers)
This proposal is not completely for software, it applies to hardware.
Discussion:
Question: is there an architecture precedence in other architecture?
Answer: other architectures do have a smaller set of implementations and vendors provide guidance on code generation.Question: has there been any software discussion?
Answer: Toolchain SIG has discussed. No objections discussed. Question raised around how these get proposed and managed going forward.Question: will these occur in profiles and be mandated?
Answer: yes, these are envisioned to be included in Profiles where applicable. Expect the proposed extensions to be RVA23. Sets expectations about performance of features.Software will see good advantages quickly.
The word “mandatory” may not be correct.
Software distros are asking for this capability. Discussion around inclusion for Profiles inclusion – motivation, performance expectations, software coding behavior, etc.
Inclusion in Profiles will occur after ratification, but discussion has started.
psABI Charter Update
Original release was November 2022
No action items were raised.
Next Steps: An OpaVote will be created for the TSC in the coming days to approve the charter.
Unified Discovery (UD) Update
Vote started a couple days ago to disband the group.
Work to create a new solution is beginning which most likely will be more basic.
When proposal has solidified it will come back to TSC for consideration.
SOC Infra HC has asked External Debug group to take a look at this.
New Proposal of Work: Configuration Parameters TG
CSC identified this issue and started some of this work, but it stalled.
While not creating new specs, will likely be updating existing specifications (ISA Manual) and may need to work in “chunks”.
Discussion:
Question: how will the CSC consume these rules? Will they certify for ALL parameters?
Answer: CSC will be reviewing the parameters and will prioritize these in their delivery.There is a certification risk that a compliant architecture may not be certifiable.
ISA needs work on naming which is similar to the parameter names. Perhaps this should be pulled out into a separate group.
Question: Should this be a SIG?
Answer: Worried that starting TGs per extension would be too cumbersome. Expect this may be mostly Fast Track updates per extension. If the SIG can identify the Fast Tracks to address the work, then this could create the same result.Question: What is the proper way to annotate the specification? Is it ratification?
Answer: this is similar to Zmmul which was a subset of existing capability. Also similar to how Profiles names existing options. So, ratification is appropriate and consistent with current practices.To contain the growth this work, recommendation was made that the parameters are created in the case where it impacts Certification.
There is a constraint here on names that they be backwards compatible.
UDB has already identified >200 parameters. Other architectures have upwards or 1000.
Unified Discovery has some similar characteristics but was limited to encoding scheme. Not sure there’s much wasted here. This TG will not be developing a schema (machine readable version), but rather to identify and name behaviors in existing specifications.
Question: can we put in existing SIG (UDB or Doc SIG) or do we need a new one?
Answer: UDB is quite busy. A new SIG might produce new leadership to help drive this.
Next Steps: