laundry list of concerns following TG Minutes 2020/6/26
|
David Horner
I trust this is not just noise.
toggle quoted message
Show quoted text
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?
On 2020-06-26 11:05 p.m., Krste
Asanovic wrote:
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 |
|
|