Code of Conduct

• I have searched the existing bug issues.
• 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.

Bug Description

Bug Description

When the C extension is disabled (CVA6ConfigCExtEn = 0), the implementation supports only IALIGN=32. Per the RISC-V Privileged Specification, sepc[1:0] must always be zero in such configurations. However, the current implementation only forces bit[0] to zero on CSR writes and does not handle bit[1]
This affects sepc, mepc, vsepc

RISC-V Privileged Specification:

The low bit of mepc (mepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits (mepc[1:0]) are always zero.
The low bit of sepc (sepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits (sepc[1:0]) are always zero.

Buggy Code

1. CSR write path ([core/csr_regfile.sv](line 1358):

riscv::CSR_SEPC:
if (CVA6Cfg.RVS) sepc_d = {csr_wdata[CVA6Cfg.XLEN-1:1], 1'b0};

Only bit[0] is forced to zero. bit[1] from csr_wdata is preserved regardless of CVA6Cfg.RVC.

2. Trap write path ([core/csr_regfile.sv](line 2069):

sepc_d = {{CVA6Cfg.XLEN - CVA6Cfg.VLEN{pc_i[CVA6Cfg.VLEN-1]}}, pc_i};

pc_i is stored directly without masking any low bits (neither bit[0] nor bit[1]).

3. CSR read path ([core/csr_regfile.sv](line 511):

riscv::CSR_SEPC:
if (CVA6Cfg.RVS) csr_rdata = sepc_q;

sepc_q is returned without any alignment mask. If bit[1] was stored as 1, it is read back as 1.