Zbigniew Chamski

Looking at the code, the access is explicitly coded as `lw zero, -16(zero)`, so the compilation flow only generates the corresponding instruction.

> OK, so that's an RTL issue (access outside the mapped space should be detected). @JeanRochCoulon, what's your view on this? Any news from the CVA6 spec and/or implementation side?

Hi @SylRemTHA , to help with the analysis of the issue, can you indicate the CVA6 hash that you used in the failing case?

Hi @SylRemTHA, the CVA6 infrastructure underwent a major overhaul in the last weeks/months (including a reorg of repositiories and a rework of Questa support). Is your issue still relevant/reproducible in...

Hi @SylRemTHA, any updates?

We have three sources of discrepancies: * differences in interpretation of implementation-dependent "may"/"can" cases in the RISC-V specs * bugs in CVA6 * (unlikely but possible) bugs in Spike. We...

The behavior of bit 0 in the `PMPADDRn` CSRs depends on the address matching mode in effect (encoded in the associated `PMPCFG` register) **and** the PMP granularity set for each...

> Agree, I will add the parameter @MarioOpenHWGroup, I can see Spike params `/top/.../pmpregions` (number of PMP regions), `/top/.../pmpaddr0` (reset value of `PMPADDR0`), and `/top/.../pmpcfg0` (reset value of `PMPCFG0`), but...

This task should be assigned to @Gchauvon as I'm not involved with the FPGA (except for Spike build interactions).

This seems to be another incarnation of #1625 where CVA6 does not trap on address `0xffff_fff0`.