We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RISC-V arch extensions that have been submitted for official AR (or for prelim review). Here are this week's minutes.
Minutes from AR Committee meeting on 11/22/22
Vector Crypto.
The question was asked to AR as to what would be considered a sufficient PoC to validate the completeness and correctness of the proposed arch spec.
Currently the instructions have been modeled in Spike, and various crypto tests have been run - producing correct results. This was largely considered to be sufficient to satisfy the architecture PoC requirement.
But one notable exception was called out - for the instructions that require VLEN=256 to run with LMUL=1. On VLEN=128 designs, software will need to use LMUL=2 to create effectively 256-bit-wide vector registers - which halves the number of available registers. Hence a request for the TG to verify that 16 vector registers (vector register groups to be precise) are sufficient to implement fully performant routines using these instructions.
IOMMU detailed architecture review.
The in-depth review continues and is down to the final chapter of the spec.
P extension.
Work has been paused (on putting together a proposed spec for a baseline RISC-V P extension) for a while due to priority being given to completing arch review of the IOMMU spec. Focus is expected to shift back after the RISC-V Summit and December holidays.
Zicondops.
An inquiry to be sent to Ved and Ken about the latest status of this fast track extension (which is targeted for inclusion in the RVA23 ISA profiles).
BFloat16
A fast track extension proposal is being put together to add BFloat16 support to the ISA and a question was put to the AR Committee regarding the handling of details like NaN payloads and subnormals - especially given that other architectures (e.g. Intel, Nvidia, ARM) have not made the exact same choices in these areas.
The general AR feedback is that it would be best for RISC-V to match one of the other architectures with regards to these details (versus doing something yet again different from everyone else). Further, following ARM's choices is suggested as this is most consistent with RISC-V FP architecture.
Flushing subnormals to zero was proposed, but the informal AR feedback is to require subnormal handling (as part of following the preceding bullet point).
