Add Zvbc32e and Zvkgs specifications (into vector crypto chapter)

[Nicolas Brunie (nibrunieAtSi5)]

Following the ARC review on #1306, I am opening this pull-request to integrate the specifications following the ARC recommendations.

Eventually this PR will represent the frozen specifications for both Zvbc32e and Zvkgs.

RVIA tracking

This pull requests draft the changes associated with two fast track extensions for vector crypto.

Fast track is tracked in https://riscv.atlassian.net/browse/RVS-1915

New features:

• Zvbc32e: Extending vclmul[h].v[vh] instruction to support SEW=32-bit, 16-bit and 8-bit values. Zvbc32e is available standalone (ELEN >= 32) or in addition to Zvbc (ELEN >= 64). no new encoding
• Zvkgs: Adding .vs variants to vghsh and vgmul; should depend on Zvkg; new encodings

Related changes:

• spike-isa-sim modifications
  • add support for Zvbc32e and Zvkgs: Vector crypto additional riscv-software-src/riscv-isa-sim#1748
• encoding proposal in riscv-opcodes repo: Vector crypto additional extensions: Zvbc32e and Zvkgs riscv-opcodes#270
• adapt vector crypto code samples for Zvbce32 https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvbc-test.c
• adapt vector crypto code samples for Zvkgs https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkg-test.c
• Sail models
  • Zvkgs: Adding support for (project) fast track extension Zvkgs sail-riscv#1017
  • Zvbc32e: Adding support for Zvbc32e sail-riscv#931
• Compiler support
  • LLVM: [WIP][RISC-V] prototyping intrinsic support for Zvbc32e and Zvkgs llvm/llvm-project#128243
  • GCC: TBD
• rvv-intrinsics support: Adding intrinsics generation support for extension Zvbc32e and Zvkgs riscv-non-isa/riscv-rvv-intrinsic-doc#420

History

During the specification process for vector crypto 1.0.0 a few items had to be discarded because they appeared too late in the process. This fast track extension tries to address some of them.

The official demand that will be discussed in the Task Group and submitted to the Unpriv Committee is being drafter here: https://docs.google.com/document/d/1zpYhnZi2NxhjfcBGvPOy0oDhx6lTXchscG17Qcl6wv8/edit?usp=sharing

This pull request follows a previous PR against riscv-isa-manual, #1306, which itself was the follow-up to a pull request started on the riscv-crypto repo: riscv/riscv-crypto#362.

[Andrew Waterman (aswaterman)]

Please replace all of the <= with {le} and >= with {ge}.

[Nicolas Brunie (nibrunieAtSi5)]

done in 7cb19f0

[Nicolas Brunie (nibrunieAtSi5)]

Suggested change

	It is not suitable for implementations with small `ELEN` (32) and incurs some inefficiencies for algorithms where at least one of the multiplication operands is limited to 32 bits (or less).
	It is not suitable for implementations with small `ELEN` (32) and incurs some inefficiencies for algorithms where at least one of the multiplication operands is limited to 32-bit (or narrower).

[Jiawei (pz9115)]

Just a quick update from ISCAS: we have implemented preliminary toolchain support for Zvbc32e and Zvkgs in both GCC and Binutils.

The current development branches are available here:

• GCC: https://github.com/ruyisdk/riscv-gcc/tree/zvbc32e-zvkgs
• Binutils: https://github.com/ruyisdk/riscv-binutils/tree/zvbc32e-zvkgs

We will keep tracking this ISA manual PR and the related riscv-opcodes / rvv-intrinsic changes, and are happy to adjust the implementation if the specification or intrinsic naming changes before finalization.

Please feel free to add these branches to the related toolchain support list if that is useful.

Thanks.

[Nicolas Brunie (nibrunieAtSi5)]

Just a quick update from ISCAS: we have implemented preliminary toolchain support for Zvbc32e and Zvkgs in both GCC and Binutils.

The current development branches are available here:

• GCC: https://github.com/ruyisdk/riscv-gcc/tree/zvbc32e-zvkgs
• Binutils: https://github.com/ruyisdk/riscv-binutils/tree/zvbc32e-zvkgs

We will keep tracking this ISA manual PR and the related riscv-opcodes / rvv-intrinsic changes, and are happy to adjust the implementation if the specification or intrinsic naming changes before finalization.

Please feel free to add these branches to the related toolchain support list if that is useful.

Thanks.

Thank you Jiawei (@pz9115), this is definitely useful.
I think the test inputs are one of the last remaining thing required to freeze Zvbc32e and Zkvgs.

I need to update this PR (rebase) but no material changes are expected at the moment.

[JojoR (rjiejie)]

Hi, I have a question regarding the extension versioning used in this implementation. The upstream specification for Zvbc32e/Zvkgs is currently at v0.0.7 (a three-component version: major.minor.patch = 0.0.7).
However, in the LLVM/GCC codebase, the version appears to be encoded as 0p7, which under LLVM/GCC's standard MpN (major-p-minor) convention would represent version 0.7 rather than 0.0. I would have expected 0p0 to faithfully reflect the major.minor components of the spec version (0.0), with the trailing .7 being a patch-level revision that the two-component scheme simply cannot capture.
Could you clarify the rationale behind choosing 0p7? Is this an intentional flattening of the three-component spec version into the two-component LLVM/GCC scheme (i.e., treating 0.0.7 as effectively 0.7), or is there a different convention at play here?
Understanding this would help ensure consistency as the spec continues to evolve toward ratification.
Thank you!

[Jiawei (pz9115)]

Hi, I have a question regarding the extension versioning used in this implementation. The upstream specification for Zvbc32e/Zvkgs is currently at v0.0.7 (a three-component version: major.minor.patch = 0.0.7). However, in the LLVM/GCC codebase, the version appears to be encoded as 0p7, which under LLVM/GCC's standard MpN (major-p-minor) convention would represent version 0.7 rather than 0.0. I would have expected 0p0 to faithfully reflect the major.minor components of the spec version (0.0), with the trailing .7 being a patch-level revision that the two-component scheme simply cannot capture. Could you clarify the rationale behind choosing 0p7? Is this an intentional flattening of the three-component spec version into the two-component LLVM/GCC scheme (i.e., treating 0.0.7 as effectively 0.7), or is there a different convention at play here? Understanding this would help ensure consistency as the spec continues to evolve toward ratification. Thank you!

Thanks for pointing this out.

The version was encoded as 0p7 intentionally. My understanding is that
the current draft is moving toward the frozen stage, and the version used
for that frozen draft is expected to be 0.7.

Since the RISC-V toolchain ISA string only represents extension versions
as major.minor, using 0p7 follows the normal MpN convention and matches
the version we expect to track for the frozen draft. In other words, this
is not intended to preserve the earlier three-component draft document
version literally as 0.0.7.

I agree the transition from the previous 0.0.7 document version to the
toolchain 0p7 form can be confusing, so I am happy to add a clarification
in the commit message or comments if that would be helpful.