This change request against RISC-V vector crypto specification is related to https://github.com/riscv-software-src/riscv-isa-sim/issues/1548: it aims at making the alignment mandate of vector register index clear for any vector crypto instruction manipulating element groups (vector or scalar element groups).
In the spike issue, @GuoShibo-cn noticed that the spike behavior for vector register index alignment was not consistent with the standard constraints for Vector instructions (namely the operand/destination vector register index must be EMUL aligned, else the behavior is reserved).
(a) fix for issue https://github.com/riscv-software-src/riscv-isa-sim/issues/1548: adding missing LMUL alignment checks for vector crypto instructions. All extensions from the following extensions are affected (that should be all instructions manipulating element groups): Zvkned, Zvknh[a/b], Zvksed, Zvksh, Zvkg.
(b) implementing precise LMUL alignment checks for the scalar-element-group operand of .vs instruction
(a) the EMUL alignment of vector operand/destination (=EMUL for the vector element group operands and the destination) is specified in the main RVV spec; when a vector register group is not EMUL aligned, the behavior is listed as "reserved" and spike has implemented this check to trigger illegal instruction exception when the condition was not met (e.g.
In the case of the .vs instructions defined in this specification, vs2 holds a 128-bit scalar element group. For implementations with VLEN ≥ 128, vs2 refers to a single register.
and elsewhere
Scalar element groups will occupy at most a single register in application processors. However, in implementations where VLEN<128, they will occupy 2 (VLEN=64) or 4 (VLEN=32) registers.
and also
The .vs instructions require scalar element groups of EGW=128. On implementations with VLEN < 128, these scalar element groups will necessarily be formed across registers. This is different from most scalars in vector instructions that typically consume part of a single register.
This change request against RISC-V vector crypto specification is related to https://github.com/riscv-software-src/riscv-isa-sim/issues/1548: it aims at making the alignment mandate of vector register index clear for any vector crypto instruction manipulating element groups (vector or scalar element groups).
In the spike issue, @GuoShibo-cn noticed that the spike behavior for vector register index alignment was not consistent with the standard constraints for Vector instructions (namely the operand/destination vector register index must be
EMUL
aligned, else the behavior is reserved).Current spike does not trap and execute vector crypto instruction from https://gist.github.com/nibrunie/80a00047dce935011614530d86a829e6 without complaining.
There is a PR open on spike to fix this https://github.com/riscv-software-src/riscv-isa-sim/pull/1815
LMUL
alignment checks for vector crypto instructions. All extensions from the following extensions are affected (that should be all instructions manipulating element groups): Zvkned, Zvknh[a/b], Zvksed, Zvksh, Zvkg.LMUL
alignment checks for the scalar-element-group operand of.vs
instructionThis PR (https://github.com/riscv/riscv-isa-manual/pull/1653) addresses the same two points (a) and (b):
(a) the
EMUL
alignment of vector operand/destination (=EMUL
for the vector element group operands and the destination) is specified in the main RVV spec; when a vector register group is notEMUL
aligned, the behavior is listed as "reserved" and spike has implemented this check to trigger illegal instruction exception when the condition was not met (e.g.(b) The vector crypto specification lists multiple times the intent to allow the vector register group for the scalar-element-group to have
EMUL = EGW / VLEN
(and to be aligned with thisEMUL
and not with the global LMUL associated with other vector operands/destination of the instruction). Looking at the current version of the spec (https://github.com/riscv/riscv-isa-manual/blob/1745bbf5549e519dea428fa05178b9fe0a0449f3/src/vector-crypto.adoc#element-groups) one can find:and elsewhere
and also