View Source

Submissions of extensions to the Unpriv and Priv ICs for official Architecture Review and for Opcode/CSR Assignment Review (and official allocation) should be emailed to tech-opcode-and-consistency-review. A row for your submission must also be added to the bottom of the Arch Review Status table below, and please fill in all fields except for the Status/ETA field.

Arch Review Status Table

Extension Name	Included Extensions (e.g. Zkr, Zbk[bcx], ...)	Submitting TG	Contact(s) name and email (Chair, Vice-chair, Architect, Editor, etc.)	Status	Status Date	projected completion date	Comments/blockers/next steps
Priv-related fast-track extensions	Smdisc, Sstc, Sscofpmf, Smstateen	Fast track	Greg Favor (gfavor@ventanamicro.com) John Hauser (jh.riscv@jhauser.us)	Submitted	Various	Next up	Full review
Debug 1.0	Debug	Debug	Tim Newsome (tim@sifive.com) Paul Donahue (pdonahue@ventanamicro.com)	Submitted	29 June 2021		Full review of just ISA chapters (i.e. 1, 2, 4, 5)
Pointer Masking	Zjpm	J	Martin Maas (mmaas@google.com) Adam Zabrocki (azabrocki@nvidia.com)	Submitted	23 July 2021		Full review
Packed SIMD	Zpsfoperand, Zprvsfextra, Zpn, Zbp[??]	P	Chuanhua Chang (chchang@andestech.com)	Submitted	24 June 2021		Full review

In addition to the extension spec, please submit information about the PoCs and about utility/efficiency (although we don't need all the gory detail - a paragraph or so for each can be fine). For items considered to not be consequential, a sentence or so explaining why should suffice.

Consistency with the RISC-V architecture and philosophy
Documentation clarity and completeness

Including proper distinction between normative and non-normative text

Motivation and rationale for the features, instructions, and CSRs
Utility and efficiency (relative to existing architectural features and mechanisms)

Is there enough value or benefit to justify the cost of implementation?
Is the cost in terms of area, timing, and complexity reasonable?

Proof of Concept (PoC)

Software PoC to ensure feature completeness and appropriateness for intended use cases
Hardware PoC to demonstrate reasonable implementability

Inappropriate references to protected IP (i.e. covered by patents, copyright, etc.)

If, for now, you primarily want to nail down opcode/CSR assignment and have a solid draft spec (but not a final spec ready for official Arch Review), then mention this in your email submission so we know to focus on just the opcode/CSR assignments (but in the context of the spec).

Similarly, while a spec is being developed, if there is need for a first-order spec review of certain key architectural assumptions being made (e.g. to make sure that these will ultimately be considered acceptable and appropriate), then explain this in the submission and highlight the key assumptions that we should focus on evaluating for now.

Lastly, note that Arch Review doesn't concern itself with Definition-of-done (DoD) checklist items like Spike/QEMU/Sail support, ACTs, and software support. Waivers are a matter for Tech Chairs to approve, and review of the other DoD requirements occurs through the various IC/HC sign-offs and the overall review/approval by tech-chairs.

The email addresses for the primary reviewers are:

Krste Asanovic <krste@berkeley.edu>
Andrew Waterman <andrew@sifive.com>
John Hauser <jh.riscv@jhauser.us>
Greg Favor <gfavor@ventanamicro.com>