About

• Name: Architecture Review

• Version: 1.3

• Creation date: 2021-05-17

• One line description: This policy cover the opcode encoding, mnemonics, and CSR

• Author(s): Greg Favor, Krste Asanovic

• Status: Approved

Version History

Rationale

We need to produce robust extensions that are consistent with the ratified RISC-V specifications and RISC-V overall strategy. 

We also need to coordinate assignments of opcode encodings, mnemonics, CSRs, etc so we have a consistent set of conventions across extensions, handle different profile targets, and manage encoding resources.

Policy

There was a previous policy that covered some of the same areas as this policy and this policy fully supersedes any older policy covering the same topics.

The Architecture Review policy and process will be managed and performed by the Unprivileged and Privileged ISA committees (ICs). This will be structured in a way to enable parallel work by several key architecture people. Responsiveness as well as sufficient thoroughness are both goals.

There are four pieces to this process:

• Architecture review of Unpriv extensions by the Unpriv IC

• Architecture review of Priv extensions by the Priv IC

• Opcode assignment review

• CSR assignment review

Process details

• The four ISA committee chairs and their delegates, will work together to accomplish this policy.

• Architecture reviews will examine the architectural consistency, cost/benefit justifications, and specifics of an extension as being appropriate for standardization by RISC-V (e.g. are there questionable details, potentially unjustified features, or architectural choices inconsistent with the overall RISC-V architecture). This doesn't supplant the need for Task groups (TGs) to do their full diligence as part of developing a proposed architecture extension. The more thoroughly a TG does its work and documents, the what and why, the more smoothly the review process will go and it will help the overall extension development process produce quality RISC-V architecture extensions.

• The chairs will delegate who will drive CSR assignment review (as technically the most appropriate people to do this knowledgeably and holistically).

• Opcode assignment review will be handled more dynamically and jointly between the IC chairs and their delegates.

• The DoD sign-offs for the ICs will be contingent on completing this policy for each extension.

• The definition of done (DoD) checklist deliverables concerning early opcode assignments, etc. will be conducted in accordance with this policy and must be completed in time for the appropriate DoD milestone.

• The tech-arch-review email list is the one portal for submissions from TGs of arch extensions to be reviewed. This also includes submissions for preliminary reviews of specific key issues or questions. An updated version of the submission status spreadsheet will have tracking/status columns for the above four pieces. (The intent is to try and provide opcode and CSR assignment feedback, when possible, more quickly and ahead of complete arch review feedback.). The queue will be reviewed by one of the chairs of the ICs at every chairs meeting and rolled up to the BOD monthly for the high priority extensions.

AR Review During the Specification Development Lifecycle

In the process of developing the RISC-V Specification, Architecture Review (AR) serves a pivotal function. This review can occur at various stages: Planning, Development, Freeze, and Ratification-Ready.

During the Planning and Development phases, AR functions primarily as a consultative activity, offering requested guidance on possible architectural choices and suggestions for improvement. However, the Architecture Review conducted during the Freeze stage is particularly important and mandatory, as it determines whether the specification is genuinely prepared to advance or if modifications and enhancements are needed. Lastly, AR is required during the Ratification-Ready phase if the specification text has undergone any significant changes (i.e. past simple typo corrections, formatting corrections, and very simple clarifications).

Exception handling

All exception requests should be forwarded to the ISA committees. It is unlikely any will be granted.

Any escalation should occur to the CTO who may choose to resolve the issue, or escalate to the TSC or the CEO or the BOD.

Transition to start using policy

Effective immediately. This will be the acting policy while awaiting approval (possibly with modifications before approval). Any extension that was part way through the process with the previous policy should contact the ISA chairs to determine how to proceed.