RISCV-Compliance check - Some Fails

[cr8601]

Hi, I successfully run the RISC-V Compliance check (https://github.com/riscv/riscv-compliance) on the provided SweRV RTL and I was able to pass most of the tests except the following:

1. ree_rv32i.I-MISALIGN_JMP-01
2. ree_rv32i.I-MISALIGN_LDST-01
3. ree_rv32mi.breakpoint
4. ree_rv32Zifencei.I-FENCE.I-01
5. ree_rv32ui.fence_i

Unfortunately I couldn't find any information about RISC-V-Compliance check regarding SweRV.

• Regarding 1./2. I read that this is not needed by RISC-V spec. And also it is implementation dependent. Whenever the RTL already contains mechanism to handle misalignments, this test probably fails... What about SweRV implementation?

• Regarding 3 I didn't yet analyze in detail, but I don't expect this to be really relevant

• Regarding 4./5. As stated in the PRM (1.1 Features):

  RV32IMCZifencei_Zicsr-compliant RISC-V core with branch predictor I would expect this test to pass...

Has anyone ever run RISC-V compliance on SweRV and can comment on the above issues?

Thanks and best regards cr

[aprnath]

Misalign tests will fail because SweRV supports unaligned accesses to normal memory. IO (non-idempotent) ld/st will take misalignment exceptions, but you will need to mark the region as such using the MRAC CSR. SweRV also supports compressed (16 bit) instructions, and there is no way to turn off 16 bit support - so you cannot get alignment exceptions on branch/jump instructions either.

Regarding the fence instructions - it depends on your test setup and if it supports a unified instruction.data memory. The (currently*) provide simple TB does not support self-modifying code since the stores are not reflected in the instruction memory. To really test the fence.i instruction, you need your system to have share memory between the fetch and data buses.

• We will be updating the provided TB soon.

[aprnath]

Regarding the breakpoint test, note that SweRV disables breakpoints when mstatus.mie is cleared.

[cr8601]

Hi aprnath, thank you very much for this information. This helps a lot in further debugging and understanding!

[cr8601]

Hi aprnath,

• I was able to successfully run the "fence" instruction test by using shared memory for IFU&LSU. Thank for your hint.

• I did some analysis for the breakpoint test. By adding the following code to the beginning of the test I could successfully run it:

  # from https://github.com/riscv/riscv-asm-manual/blob/master/riscv-asm.md
  # set mstatus.MIE=1 (enable M mode interrupt)
  li      t0, 8
  csrrs   zero, mstatus, t0

After digging some more in the latest ISA spec, 3.1.6 Machine Status Registers, I am wondering whether mstatus.MIE should be '1' by default, but I didn't find anything about the default values for mstatus... Can you comment on that?

Best regards cr

[cr8601]

Hi aprnath, I think it's cleared in chapter 3.3:

Upon reset, a hart’s privilege mode is set to M. The mstatus fields MIE and MPRV are reset to 0.

Correct? Then I am wondering about the compliance check and why it works for others... I probably need to open an issue at their repo. Do you agree, or do you you have any other idea?

Best regards cr

[tmw-wdc]

Hi,

I think the answer to your question above is covered in Section 5.1, ‘Native M-Mode Triggers’ of the RISC-V External Debug Support specification, Version 0.13.2. There are two implementation options to deal with breakpoints in M-mode only cores. SweRV disables breakpoints when MSTATUS.MIE is cleared. Presumably, the breakpoint test might pass on cores which implement the other option.

Thanks, Thomas

[cr8601]

Hi, thanks for your support and quick feedback. I'll request to add the register settings within the compliance test. Thanks cr

[tmw-wdc]

Thank you for reporting these test cases! They will be documented in the next PRM release.

Thanks, Thomas