- What's next: when outstanding issues are reduced, start planning for review
- email@example.com - when spec is solid but not a final spec - primarily want to nail down opcode/CSR assignment and have a solid draft spec (but not a final spec ready for official Arch Review)
- Also, to remind people of what gets reviewed (as is appropriate for a given extension), see the following list. 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.)
- Deterministic Test plan for the fast-interrupt is available. Discussion on-going on how to add async/undeterministic testing of interrupts.
- YAML config needs to be created. See info here.
- Discussion in Arch tests group to add automation (docker?) to validate check-in so that arch-test-suite is run against sail, spike, gcc/toolchain, with versions used recorded. So sail and spike will need to work for CLIC before CLIC tests can be added to riscv-config github.