laundry list of concerns following TG Minutes 2020/6/26
A laundry list of concerns
Assess objectives and those met as we approach v1.0 of RVV
Polymorphism has not made it into RVV V0.9
Tagging registers with a datatype is not likely for v1.0
Is it still a vision for a future evolution of v1.0
Is it likely for INST64?
Is there anything we need to put in place now to assist its inclusion later?
A design for all ranges of processors IOT to Supercomputers.
The full V0.9 is too large for smallest implementations
The specification implies float is optional when F not implemented.
Float_in_Integer would lessen the burden on small designs.
Does Float in V become mandatory if FinI is implemented/.
RVV has a complex model:
SEW/EEW, vl/LMUL/EMUL, v0.m
register types: scalar vs vector vs mask
register groups: and alignment on 8/4/2 boundaries.
(similar but not synonymous with LMUL.
csrs: vtype (including ediv), vcsr, vxrm, vxsat, vstart and vlenb,.
Behaviour qualifiers: tail and mask undisturbed/agnostic
vsetvli instruction(s) – multipurpose persistent settings and algorithm for vl.
Scope and nature of V1.0
The current design is large.
The only optional functionality is Zvediv.
Is a smaller base possible/desirable.
Do we punt to “profiles” to determine what needs to be included?
RVI intends to be a base for extensions and experimentation.
Are we expecting V1.0 to be a similar base for diversity and experimentation.
Are there sufficient facilities in place to allow this?
RVI relies on traps for emulation/extension.
RVV explicitly tries to avoid traps.
What needs to be added to vcsr or elsewhere?
Date: 2020/6/26 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~15 Current issues on github: https://github.com/riscv/riscv-v-spec