Fix mtvec WARL readback and trap dispatch coherence

[124107157-KV]

• 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.

Why this PR is needed

mtvec currently allows software to write and read back address bits that are outside the implemented physical-address width.

For the cv64a6_imafdc_sv39 configuration, machine-mode instruction fetch ultimately uses the implemented physical-address width (PLEN). However, the CSR_MTVEC write path stores the trap-vector value at the architectural XLEN width, apart from the existing mode and alignment legalization.

This means software can write an mtvec value containing unsupported high address bits and read those bits back unchanged, while a subsequent machine-mode trap can ultimately fetch from the corresponding low physical-address alias.

The CSR-visible mtvec value can therefore differ from the trap-vector address that the implementation can actually consume.

Since mtvec is WARL, unsupported address bits can instead be legalized when the CSR is written. This keeps mtvec readback coherent with the effective machine-mode trap target.

Changes

• Legalize mtvec to the implemented physical-address width after the existing mode and alignment handling.
• Preserve the existing direct/vectored-mode behavior.
• Preserve the existing additional vectored-mode alignment requirement.
• Add a directed mtvec-warl-rv64 regression test.
• Register the new regression in verif/tests/testlist_issues.yaml.
• Exercise an mtvec value containing a valid low trap-handler address together with an unsupported high address bit.
• Treat WARL legalization on CSR readback as a valid result.
• Detect the previous condition where CSR readback retains the unsupported high address bit but trap dispatch reaches its low physical-address alias.

The RTL change legalizes the final mtvec value using:

mtvec_d = CVA6Cfg.XLEN'(CVA6Cfg.PLEN'(mtvec_d));

This is applied after the existing direct/vectored-mode and alignment handling.

Validation

Tested with the cv64a6_imafdc_sv39 configuration using veri-testharness.

Baseline RTL

The new mtvec-warl-rv64 directed regression was run with the RTL fix temporarily removed.

• The test compiled successfully.
• The original mtvec write path retained the unsupported high address bit.
• The regression reproduced the issue on the unmodified RTL.
• The inner make veri-testharness invocation failed with return code 2, as expected for the regression failure.

Fixed RTL

The same regression was then run with the mtvec WARL legalization applied.

• The test compiled successfully.
• Unsupported high address bits are removed from the CSR-visible mtvec value.
• CSR readback is therefore consistent with the machine-mode trap address supported by the implementation.
• veri-testharness completed successfully with ...done.
• The directed regression completed successfully.

Additional checks:

• git diff --check is clean.
• The RTL change is limited to the CSR_MTVEC write path.
• The existing direct/vectored-mode handling is preserved.

Scope / limitations

This change is intentionally scoped to the mtvec readback-versus-trap-target coherence problem reported in this issue.

It does not change:

• stvec
• vstvec
• the general MMU address translation behavior
• general physical-address truncation elsewhere in the core
• other CSR WARL behavior

This keeps the change focused on the reported machine-mode mtvec inconsistency.

Fixes #3458