Add support for the Zvk* ISA extensions

[cmuellner]

This patch introduces support for the RISC-V Zvk* ISA extensions:

• Zvkb
• Zvkg
• Zvkned
• Zvknh[a,b]
• Zvksh
• Zvksed

The Zvk* extensions are not frozen yet, but
The implementation follows the version 20230303 of the specification,
which can be found here:
https://github.com/riscv/riscv-crypto/releases/tag/v20230303

There is an updated version available which introduces significant changes (e.g. new instructions),
but public patchset for Binutils, GCC, QEMU, Spike and SAIL only support the spec version, that this
PR supports.

There is zero support for vector instructions in this repository or any related repo (e.g. riscv-ctg).
Therefore, this PR introduces new helper macros in the first commit (inspired by the existing ones).

All tests have been hand-written.

Description

Provide a detailed description of the changes performed by the PR.

Related Issues

Please list all the issues related to this PR. Use NA if no issues exist

Ratified/Unratified Extensions

• Ratified
• Unratified

List Extensions

List the extensions that your PR affects. In case of unratified extensions, please provide a link to the spec draft that was referred to make this PR.

Reference Model Used

• SAIL
• Spike
• Other - < SPECIFY HERE >

Mandatory Checklist:

• All tests are compliant with the test-format spec present in this repo ?
• Ran the new tests on RISCOF with SAIL/Spike as reference model successfully ?
• Ran the new tests on RISCOF in coverage mode
• Link to Google-Drive folder containing the new coverage reports (See this for more info): < SPECIFY HERE >
• Link to PR in RISCV-ISAC from which the reports were generated : < SPECIFY HERE >
• Changelog entry created with a minor patch

Optional Checklist:

• RISCV-V CTG PR link if tests were generated using it : < SPECIFY HERE >
• Were the tests hand-written/modified ?
• Have you run these on any hard DUT model ? Please specify name and provide link if possible in the description
• If you have modified arch_test.h Please provide a detailed description of the changes in the Description section above.

[pawks]

The tests do look good. However, this PR does not indicate any coverage information. Tests cannot be merged without corresponding coverage reports/support.

[pawks]

Additionally, I see that the tests in rv32 are also replicated for rv64. If the same assembly file is relevant for both rv32 and rv64 then it should be present only once under the rv32 directory.

When a test is applicable for multiple extensions, it is placed under the repository corresponding to the extension which occurs first canonically.

[cmuellner]

I'm not sure how you envision coverage reports without vector support in the riscv-ctg repo.
I would claim that generic vector support cannot be part of this PR.

Anyway, I've created a PR with initial ctg files for Zvk: riscv-software-src/riscv-ctg#61

[cmuellner]

PR has been updated: the duplicated rv64 tests have been removed.

[charmitro]

Test reports for the following can be found here:

• Zvkned
• Zvksed
• Zvksh
• Zvkg

[allenjbaum]

The arch-test framework uses tests that are not self -checking; they compare a reference model resultvwith a DUT's result (DeviceUnderTest). The official reference model is Sail, but if support is not available there, you can use Spike (or Imperas's RVOVPSIM, QEMU probably, etc.

…

On Wed, Jun 14, 2023 at 3:25 PM Andrew de los Reyes < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In riscv-test-suite/rv32i_m/Zvk/src/vandn.vv-01.S <#333 (comment)> : > + +RVTEST_V_ENABLE() +RVTEST_VALBASEUPD(DATA_BASE, dataset_tc1) +RVTEST_SIGBASE(SIG_BASE, signature_tc1) + +// VANDN.VV has the following inputs and outputs: +// - input VS1: Op1 (to be inverted) +// - input VS2: Op2 +// - input VM: Mask encoding (<nothing> or v0.t) +// - output VD: Result + +#define VINST vandn.vv + +inst_1x8: +// This test will define v0, which will later be used as mask register +TEST_CASE_VVV(1, 8, VINST, v0, v0, 0*8, v1, 1*8) Apologies for what is likely a dumb question here. Is the expected result of the instruction (vandn.vv in this case) anywhere in the code, or is the expectation that SAIL and SPIKE will both exhibit identical behavior, so there is no assert/check needed to check against a golden expected value? Thanks! — Reply to this email directly, view it on GitHub <#333 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRHPDMQBQDVNSA5ODLXLI25BANCNFSM6AAAAAAWYIUBUI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[UmerShahidengr]

Its pre-req PR at CTG (PR#61) has been reviewed, and it is good to go. Tests are also good, happy to merge this one.