Skip to content

Fix decoder: RV32-only and RV64-only Zkn encodings must decode as illegal on the other XLEN - #3599

Open
youzi27 wants to merge 2 commits into
openhwfoundation:masterfrom
youzi27:fix-3588-zkn-xlen
Open

youzi27 wants to merge 2 commits into
openhwfoundation:masterfrom
youzi27:fix-3588-zkn-xlen

Conversation

@youzi27

@youzi27 youzi27 commented Sep 28, 2026

Copy link
Copy Markdown
  • I have searched for similar pull requests
  • I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources.

Fixes #3588.

core/decoder.sv matches several Zkn encodings on CVA6Cfg.ZKN alone, with no XLEN term. On the XLEN where these instructions do not exist, they decode as real operations and retire instead of raising illegal-instruction:

The vendored Spike raises illegal-instruction (mcause=2) for all of them.

This PR follows #3527, which fixed zip/unzip the same way:

  • The first commit adds CVA6Cfg.IS_XLEN32 to the RV32-only matches.
  • The second commit adds CVA6Cfg.IS_XLEN64 to the RV64-only matches.

Only core/decoder.sv changes.

Tests

Two directed tests are added in verif/tests/custom/issues/ and registered in testlist_issues.yaml. Each checks that eleven encodings trap with mcause=2 and that the valid forms on that XLEN still retire.

test target before after
decoder-zkn-rv32-only-rv64 cv64a6_imafdc_sv39 FAIL (tohost = 1: aes32esi retires) SUCCESS
decoder-zkn-rv64-only-rv32 cv32a6_imac_sv32 FAIL (tohost = 1: aes64es retires) SUCCESS

Both tests also pass on the vendored Spike, with 11 illegal-instruction traps each. The testharnesses were built with Verilator 5.008 and run with --iss=veri-testharness.

As a regression check, the same programs were run on the baseline and patched cv64a6_imafdc_sv39 testharnesses, and each trace was compared against Spike. The verdicts are identical for 331 floating-point programs and 96 interrupt programs; a batch of trigger programs is still running. The full CI regression has not been run.

The second commit goes beyond the issue as filed. I am happy to move it to a separate PR if you prefer.

Fixes openhwfoundation#3588. aes32esi/esmi/dsi/dsmi, sha512sig0h/0l/1h/1l and
sha512sum0r/1r are defined for RV32 only, and on RV64 the
instr[31:20] = 12'b011010011000 encoding is not rev8 (the RV64 rev8 is
12'b011010111000). core/decoder.sv matched all of them on CVA6Cfg.ZKN
alone, so on RV64 they decoded to real operations and retired instead of
raising illegal-instruction (the vendored Spike raises mcause=2). Add the
CVA6Cfg.IS_XLEN32 term, as openhwfoundation#3527 did for zip/unzip.

The new test decoder-zkn-rv32-only-rv64 checks that each of the eleven
encodings traps with mcause=2 on RV64 and that the RV64 forms (aes64es,
aes64esm, sha512sum0, sha512sig0, rev8) still retire.
The converse of the previous change. aes64es/esm/ds/dsm/ks2, aes64ks1i,
aes64im, sha512sig0/1 and sha512sum0/1 are defined for RV64 only, but
core/decoder.sv matched them on CVA6Cfg.ZKN alone, and cv32a6_imac_sv32
enables ZKN: on that configuration aes64es retires instead of raising
illegal-instruction. Add the CVA6Cfg.IS_XLEN64 term.

The new test decoder-zkn-rv64-only-rv32 checks that each of the eleven
encodings traps with mcause=2 on RV32 and that the RV32 forms (aes32esi,
sha512sum0r, sha256sum0, rev8) still retire.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] <RV32-only Zkn instructions (aes32*, sha512*h/l/r) and the RV32 rev8 encoding still retire on RV64 after #3527>

1 participant