Allow ELEN>VLEN in Vector extension

[DmitryUtyansky]

Change/amend wording and formulas in Vector extension to allow ELEN>VLEN configurations, along the lines agreed upon in Vector SIG. To allow e.g. ELEN=64, VLEN=32 extensions.

[github-actions]

Normative Rule Changes Detected

This PR modifies normatively tagged text. Please review the changes below to ensure they are intentional.

View Detected Changes

Normative Tag Change Report

Unprivileged Specification

================================================================================
Tag Changes Report
================================================================================

Reference file: ref/riscv-unprivileged-norm-tags.json
Current file: build/riscv-unprivileged-norm-tags.json
Modified 13 tags:
  * "norm:vector_ls_seg_wholereg_eew":
      Reference: "The load instructions have an EEW encoded in the mew and width fields following the pattern of regul..."
      Current:   "The load instructions have the element width encoded in the mew and width fields following the patte..."
  * "norm:vector_ls_unit_stride_mask":
      Reference: "Additional unit-stride mask load and store instructions are provided to transfer mask values to/from..."
      Current:   "Additional unit-stride mask load and store instructions are provided to transfer mask values to/from..."
  * "norm:vfmv-f-s_vfmv-s-f_ignoreLMUL":
      Reference: "The instructions ignore LMUL and vector register groups."
      Current:   "#The instructions ignore LMUL; EMUL is computed as ceil(EEW/VLEN)."
  * "norm:vlen":
      Reference: "The number of bits in a single vector register, VLEN {ge} ELEN, which must be a power of 2, and must..."
      Current:   "The number of bits in a single vector register, VLEN {ge} 8, which must be a power of 2, and must be..."
  * "norm:vmv-nr-r_op":
      Reference: "The vmv<nr>r.v instructions copy whole vector registers (i.e., all
VLEN bits) and can copy who..."
      Current:   "The vmv<nr>r.v instructions copy whole vector registers (i.e., all
VLEN bits) and can copy who..."
  * "norm:vmv-s-x_op":
      Reference: "The vmv.s.x instruction copies the scalar integer register to element 0 of
the destination vector re..."
      Current:   "The vmv.s.x instruction copies the scalar integer register to element 0 of
the destination vector re..."
  * "norm:vmv-x-s_vmv-s-x_ignoreLMUL":
      Reference: "The instructions ignore LMUL and vector register groups."
      Current:   "The instructions ignore LMUL, EMUL is computed as ceil(EEW/VLEN)."
  * "norm:vreduction_scalar_def":
      Reference: "Vector reduction operations take a vector register group of elements
and a scalar held in element 0 ..."
      Current:   "Vector reduction operations take a vector register group of elements
and a scalar held in element 0 ..."
  * "norm:vreduction_scalar_disregard_LMUL":
      Reference: "The scalar input and output operands
are held in element 0 of a single vector register, not a vector..."
      Current:   "The scalar input and output operands
are held in element 0 of a group with EMUL = ceil(EEW/VLEN), re..."
  * "norm:vreg_scalar_emul":
      Reference: "Widened scalar values, e.g., input and output to a widening reduction operation, are held in the fir..."
      Current:   "Widened scalar values, e.g., input and output to a widening reduction operation, are held in the fir..."
  * "norm:vtype_lmul_fval":
      Reference: "Implementations must provide fractional LMUL settings that allow the narrowest supported type to occ..."
      Current:   "Implementations must provide fractional LMUL settings that allow the narrowest supported type to occ..."
  * "norm:vtype_lmul_fval_rsv":
      Reference: "The use of vtype encodings with LMUL < SEWMIN/ELEN is reserved, but implementations can set vill ..."
      Current:   "The use of vtype encodings with LMUL < SEWMIN/min(ELEN, VLEN) is reserved, but implementations ca..."
  * "norm:vtype_sew_val":
      Reference: "For a given supported fractional LMUL setting, implementations must support SEW settings between SEW..."
      Current:   "For a given supported fractional LMUL setting, implementations must support SEW settings between SEW..."

================================================================================
Summary: 13 total changes
  Added:    0
  Deleted:  0
  Modified: 13
================================================================================

Privileged Specification

================================================================================
Tag Changes Report
================================================================================

Reference file: ref/riscv-privileged-norm-tags.json
Current file: build/riscv-privileged-norm-tags.json
No changes detected.

---

What happens next:

• This comment is informational only and does not block merging
• When this PR is merged, a GitHub issue will be automatically created with the NormRules label for CSC tracking
• If these changes are unintentional, please update the PR before merging

How to update reference files (if needed):

make update-ref
git add ref/*.json
git commit -m "Update normative tag reference files"

Note: New tags (additions) are automatically added to the reference files when PRs are merged to main. Only modifications and deletions require manual review.

This comment was automatically generated by the normative tag check workflow.

[omasanori]

This change seems actual revision to hardware-software contracts. Will it bump the version of V extension to 1.01, 1.1, 2.0 or whatever?

[aswaterman]

My recollection from having discussed this with @kasanovic is that it will come in the form of new extensions, not revisions of the existing ones.

[DmitryUtyansky]

@aswaterman , indeed new extensions will be required to specify the configurations; existing "V" and zve* remain intact). But the baseline specification must allow that (as of now it directly prohibits). We talked about that with @kasanovic and in Vector SIG. But of course there is a question how to best put that to the spec. I am not sure that my version is the best possible, certainly this requires a thorough review, and I'd appreciate any feedback/suggestions.

[aswaterman]

@DmitryUtyansky I will provide more feedback sometime down the road, but at first blush this appears to be on the right track (modulo the extensionology matter).

[DmitryUtyansky]

@omasanori , I am not sure what's the best approach with the versioning. The extensions defined in the document (V, zvl*, zve*) are not changed (at least that's the idea, unless I messed up somewhere). Existing contracts shall stay intact. But the text is changed anyway.

Alternatively, one could think of more clustered/localized changes, giving the updated formulas only for ELEN>VLEN cases and leaving the existing paragraphs intact. But overall document is then changed all the same.

[aswaterman]

Seems like we're on the right track.

Since we are globally relaxing the ELEN <= VLEN requirement, we should explicitly change the definitions of the Zve32x etc. extensions to require ELEN <= VLEN. That keeps the existing extensions functionally unchanged.

[kasanovic]

Table 60 in Section 30.18.2 already explicitly lists the ELEN <= VLEN requirement for each extension.

[aswaterman]

Ah right, thanks.

[DmitryUtyansky]

@aswaterman , I moved the explanations into one big note in the beginning, and did other small edits. Now I believe the doc is good for review, please take a look.

[aswaterman]

Thanks, I think this is getting close. Ping me after this round of feedback is addressed.

[aswaterman]

@DmitryUtyansky Thank you for hanging in there with my review; I think this is good to go after you address my last minor comment. But I'd like to give @kasanovic the chance to weigh in.

[kasanovic]

EEW is used as a hint to microarchitecture and doesn't affect architectural behavior of these instructions - I don't think it should change in case some funny trick is used by micorarchitecture knowing that EEW > VLEN?

[aswaterman]

I think this is a clean definition that doesn't actually preclude funny tricks. I suggested it because it's important we don't preclude vtype-unaware register spill/fill code from e.g. moving v1 to v2 when SEW > VLEN. Without this definition, the reference to v1 would make the instruction reserved.

A uarch is free to ignore this dictum in its trickery and represent the destination with whatever EEW it wants, e.g. it could compute its internal-representation EEW as a function of VLEN, EEW_encoded, and the register specifiers involved.

[DmitryUtyansky]

I deleted there the paragraph left by oversight after the earlier edit introducing "EEW=min(VLEN, EEW_encoded)." ("In implementations supporting ELEN > VLEN, element size can exceed the number of bits available in a vector register or a vector register group. In that case, the whole vector register load instructions
still operate on the specified number of vector register(s), using the
least-significant bits of the element.")

It's either one or the other, EEW as min(...), as @aswaterman suggested or "use LSBs of an unchanged bigger EEW" as it was originally.

The benefit of having EEW defined through min(...) is that the subsequent formulas evl=NFIELDS*VLEN/EEW works without giving fractional evl.

Thinking more about this, the formula with min(VLEN, EEW_encoded) for e.g. VLEN=32 EEW=64 breaks e.g. vl2re64.v: a perfectly valid "load pair of vregs with EEW=64" is now switched to EEW=32 (potentially misguiding all those "microarch hints").
I have changed the formula to "EEW=min(VLEN*NFIELDS, EEW_encoded)", limiting EEW to whatever fits into the requested group. Same logic applies to whole register move: I have changed the formula there as well, to EEW = min(VLEN*EMUL, SEW), factoring in EMUL.

@aswaterman , @kasanovic , please tell me what you think of the current wording.

[aswaterman]

Good catch. I think this scheme hangs together. I'll chat with @kasanovic about this topic later this week and try to reach a conclusion.

[kasanovic]

I think this is mostly OK but there are a few tweaks in wording , extension->implementation, and also the whole register move to update.

[DmitryUtyansky]

@aswaterman , @kasanovic , so what's your opinion, does this require any further refinement, what's the next step(s)?

[aswaterman]

Sorry, I'll try to re-review this before the end of the month. I think it is basically OK, but I want the chance to think it through carefully again.

[aswaterman]

I think this is ready to go after my minor comments are addressed. Please ping me once you've done so.

Also, after merging, please delete the riscv/riscv-isa-manual-dmitry repo. (In the normal github workflow, forks should be in your personal github area rather than the original one.)

[DmitryUtyansky]

I think this is ready to go after my minor comments are addressed. Please ping me once you've done so.

Thanks for getting back to this and spotting! I did the corrections.