1. Messages
  2. Vector Task Group minutes 2020/5/15

Re: Vector Task Group minutes 2020/5/15

Bill Huffman
 

I believe it is provably not possible for our vectors to have more than
two of the following properties:

1. The datapath can be sliced into multiple slices to improve wiring
such that corresponding elements of different sizes reside in the
same slice.
2. Memory accesses containing enough contiguous bytes to fill the
datapath width corresponding to one vector can spread evenly
across the slices when loading or storing a vector group of two,
four, or eight vector registers.
3. The operation corresponding to storing a register group at one
element width and loading back the same number of bytes into a
register group of the same size but with a different element width
results in exactly the same register position for all bytes.

The SLEN solution we've had for some time allows for #1 and #2. We're
discussing requiring "cast" operations in place of having property #3.

I wonder whether we should look again at giving up property #2 instead.
It would cost additional logic in wide, sliced datapaths to keep up
memory bandwidth. But the damage might be less than requiring casts and
the potential of splitting the ecosystem?

Bill

On 5/15/20 11:55 AM, Krste Asanovic wrote:
EXTERNAL MAIL



Date: 2020/5/15
Task Group: Vector Extension
Chair: Krste Asanovic
Co-Chair: Roger Espasa
Number of Attendees: ~20
Current issues on github: https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec__;!!EHscmS1ygiU1lA!W3LXrGwuFwNIJ12NX5xQnmMbzk4zgzIDO39xVFEgrQGQSggvT8Zg9M2ElNRv61w$

Issues discussed:

# MLEN=1 change

The new layout of mask registers with fixed MLEN=1 was discussed. The
group was generally in favor of the change, though there is a proposal
in flight to rearrange bits to align with bytes. This might save some
wiring but could increase bits read/written for the mask in a
microarchitecture.

#434 SLEN=VLEN as optional extension

Most of the time was spent discussing the possible software
fragmentation from having code optimized for SLEN=LEN versus
SLEN<VLEN, and how to avoid. The group was keen to prevent possible
fragmentation, so is going to consider several options:

- providing cast instructions that are mandatory, so at least
SLEN<VLEN code runs correctly on SLEN=VLEN machines.

- consider a different data layout that could allow casting up to ELEN
(<=SLEN), however these appear to result in even greater variety of
layouts or dynamic layouts

- invent a microarchitecture that can appear as SLEN=VLEN but
internally restrict datapath communication within SLEN width of
datapath, or prove this is impossible/expensive


# v0.9

The group agreed to declare the current version of the spec as 0.9,
representing a clear stable step for software and implementors.
Join {tech-vector-ext@lists.riscv.org to automatically receive all group messages.