riscv-crypto
riscv-crypto copied to clipboard
riscv
Vector extension ELEN requirements
I'm trying to understand what requirements the K extension will impose on the Vector extension. Some instructions here clearly require SEW=128, and future instructions might require even wider element widths. What does this mean in terms of other instructions in the V extension? Do all non-floating-point instructions need to be implemented at this wider width? If not, do any? If so, which ones?
It would seem to me unattractive that implementation of the the K extension forces all Vector extension integer instructions to be implemented at that wider width, if those instructions are not required for cryptographic algorithms. I posed this issue over in the Vector Extension also (see https://github.com/riscv/riscv-v-spec/issues/566) and suggested there a possible way to implement this extension even on machines that normally only implement a smaller ELEN.
I'm not an expert either on cryptographic applications or the hardware implementation of vector instructions, so I think some discussion between experts in the two groups might be needed here to clarify things.
Thanks.
My understanding was that although the crypto extension needs very large element widths, we absolutely would not require base V instructions to accommodate those element widths. I don't think there is anything in the V spec which requires or implies this either, but it is something we could be better at spelling out in the (crypto) spec.
@grnewell can probably weigh in on this too?
Ben is correct. Crypto does not affect the base vector spec. Furthermore, if crypto is implemented, and thus wider ELEN/ESEW values are supported for it, does not mean that any of the original base vector instructions are changed in any way. E.g., just because crypto uses effective SEW of 128 or 256 bits does not mean that the base FP or integer vector instructions change.
As I recall, the minimum ELEN for the base vector spec is XLEN, but larger ELENs are optional in the base. This is regardless of whether crypto is implemented or not.
Ok, so in conclusion what you are saying is that wider SEW is required to be supported only for the instructions defined here, and not for anything in the base, including loads and stores - is that correct?
If so, I would suggest that perhaps some discussion with Krste or Andrew is needed so that appropriate words can be inserted both in this specification and the vector specification to express this. The vector specification is always quite precise about the causes of Illegal Instructions, but this kind of constraint is not mentioned. For example, section 11.1. of that specification (Vector Arithmetic Instruction encoding) currently says this about floating point operands:
For floating-point operations, the scalar can be taken from a scalar f register. If FLEN > SEW, the value in the f registers is checked for a valid NaN-boxed value, in which case the least-significant SEW bits of the f register are used, else the canonical NaN value is used. If execution is attempted of a vector instruction where any floating-point vector operand’s EEW is not a supported floating-point type width (which includes when FLEN < SEW), an illegal instruction exception is raised.
However, there is no such size constraint specified for any other operand types. From what you have said this needs to change.
My understanding is that none of the other vector operand types (besides floating point) are "polymorphic." I.e., all the opcodes (except FP) specify by the opcode whether they are dealing with bytes, half-words, etc. for both inputs and outputs. The Vector FP instructions, instead, use SEW to determine the exact data type.
So, the programmer needs to set the CSR so that SEW is 128 when doing vector AES operations (for example), and then set it back to 32 or 64 to perform single- or double-precision vector floating point instructions (respectively). Failure to do so will result in an illegal instruction exception (assuming quad-precision vector FP is not supported).
Note that our proposed vector SHA2 instructions are also polymorphic: SEW=256 results in SHA-256 operations and SEW=512 results in SHA-512 operations (using the same opcodes).
Of course, we want the Vector and Crypto task groups to generate compatible specifications; and I certainly don't want to miss any opportunity to make things more clear. There are several people that are members of both groups so hopefully we avoid most of the pitfalls.
All non-floating-point vector instructions are polymorphic (with the exception of whole-register operations) so I think some clarification of expectations in both specifications will be required. I'll append a note to the corresponding issue I raised over there.
Since we have adopted vector element groups, we do not need to create wider elements than those already defined. Therefore, this issue is now moot.
