RISC-V International

Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


To Reach Definition-of-Done Plan status: extension lifecycle and milestone definitions

  • Copy  Non-ISA Platform Ratification Template 
  • keep specification status spreadsheet up-to-date ( projected dates, DoD component effort sizing, DoD tasks your group needs resource help with,...)
  • Keep dashboard  Non-ISA Extensions On Deck for Freeze Milestone up-to-date
  • Develop final charter and plan with the group and send to Chairs (tech-chairs@lists.riscv.org) for approval within 4 weeks
  • Fill in DoD Plan tab in checklist and send to chairs for approval of any deliverables that don't match the defaults along with any requested waivers
  • Freeze-time preliminary POC definition approved by IC
  • Fill in task group and specification status spreadsheet information including extension or extension group names, projected dates, DoD component effort sizing, DoD tasks your group needs resource help with,...
  • Develop Rationale document and send to chairs for approval
  • Notify TSC and Chairs when you complete this milestone and include any waivers and an updated DoD spreadsheet.
  • Plan: RISCV has prioritized RVA22.  expect CLIC to possibly be ratified at similar times with RVM23 with other embedded extensions like Zfinx, new compressed, rv32e, p-extension.  So CLIC still on roadmap but probably next gen RISC-V grouping.  Continue working on issues and refining spec.
  • Hypervisor support? One simple option is CLIC doesn’t work with H?  Both CLIC and AIA are evolving.  CLIC problematic places: table read hardware vectoring.  Otherwise no real complication.  If systems have both AIA and CLIC, how would it work. Maybe don’t need to worry about it?
    • See issue #92 discussion.  Lastest discussion: The AIA spec is being developed to be the standard support for interrupts for standard hypervisors. Possible hypervisor directions for fast interrupts for embedded include: 1) a minimal CLIC extension that adds HS mode as another privilege layer in the stack, so the hypervisor could optionally receive interrupts and optionally enable/hide interrupts from lower privilege modes. This would allow the 2-stage translation and other features of the hypervisor to be used in a CLIC-based system, but would not support sending interrupts directly to descheduled guest OS contexts (have to route via hypervisor interrupt). 2) support multiple descheduled CLIC contexts to which interrupts could be sent directly while they were sleeping, which would be a much bigger project. 3) add an extension to AIA (instead of working on CLIC) to somehow reduce interrupt latency using the standard hypervisor stack.
  • Impact of N-extension on CLIC?  Update CLIC spec to not rely on N-extension but add commentary on if N-extension is ratified how it would work with CLIC.



  • Latest Draft Fast Interrupt Specification (v0.9-draft-2021052520221108)
  • clarified 32-bit writes to clicint registers are legal but effects are not defined.
  • clarified that MPRV and SUM are obeyed on vector table accesses
  • What's next:
    • 36 outstanding issues to be addressed.  (previously 35).24 outstanding issues.
      • 12 active spec issues.
        • big items: hypervisor, cliccfg reformat proposal
      • 6 issues to track Definition of Done tasks
      • 6 issues kept open for future enhancements (post rev1.0) 

Encoding/OpCode consistency review


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


  • No new instructions are added.  Needs to be aware CSR names?  Need to choose arch string like ziclicGiven that the key CSRs are in M-mode, it should probably be named something like "Smclic"


  • No new instructions are added.  Needs to be aware of CSR names? 


  • TBD - Waiver until SAIL privilege model is completed?  e.g. add CLIC support to OS like Zephyr.
  • which github?   https://github.com/rems-projectriscv/sail-riscv or https://github.com/riscv/riscv-sailAllen is working on this with the SAIL team from Cambridge.  ultimately it will be in the RISC-V repo as soon as we have maintainers is now the official location


  • TBD



Project NameBase ArchitectureLevel of implementationNotes
area-optimized coreRV32/64

RTL simulation, FPGA Implementation, Synthesis

closed / commercial source   https://www.seagate.com/innovation/risc-v/
high-performance coreRV32RTL simulation, FPGA Implementation, Synthesisclosed / commercial source   https://www.seagate.com/innovation/risc-v/
microcontroller-class coreRV32IMAFCRTL, fully synthesizableApache License, Version 2.0 https://github.com/T-head-Semi/opene906/blob/main/doc/opene906_datasheet.pdf
E2/S2 seriesRV32/64RTL, fully synthesizablehttps://www.sifive.com/core-designer
N22RV32RTL, fully synthesizablehttp://www.andestech.com/en/products-solutions/andescore-processors/riscv-n22/
BM-310/BI-651RV32/64RTL, fully synthesizablehttps://cloudbear.ru/bm_310.html      https://cloudbear.ru/bi_651.html
n200/n900/nx900/ux900RV32/64RTL, fully synthesizable  (ECLIC)https://www.nucleisys.com/product.php?site=n200      https://www.nucleisys.com/product.php?site=n900