Status at a glance:
- Develop final charter and plan with the group and send to Chairs (firstname.lastname@example.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 with RVM22 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?
- 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.
Encoding/OpCode consistency review
- Need to propose new CLIC CSR Registers and addresses
- 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.
GCC and Binutils
- No new instructions are added. Needs to be aware CSR names? Need to choose arch string like ziclic
- No new instructions are added. Needs to be aware of CSR names?
Though all listed under "simulators", these are actually a collection of formal model / virtual machine / architectural simulators / DV simulators etc.
ABI Extensions (no new ABI required)
- Regular C function that save/restores all caller-save registers
- Inline handler gcc interrupt attribute to always callee-save every register (save as you go)
- EABI Task Group - improve interrupt latency by reducing the number of caller-save registers