Page History

...

• What's next: when outstanding issues are reduced, start planning for review
• tech-chairs@lists.riscv.org - 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.)

Architecture Tests

• 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.

...