Instruction after pmpaddr0 csr write was not executed

[Ankelih]

Hello,

When I tried to run riscv-isa test rv32ui-p-add on Veer EH-1 core, I observed that the instruction after pmpaddr0 csr write operation is not executed and I cannot see it in the log file. However, when I run the same code with Spike ISS, I see the next instruction after csr write operation. You can find the executable, its dump, and logs from core and spike iss below. Can anyone help me figure out what going on in this situation?

rv32ui-p-add.zip

[algrobman]

As far as I know EH1 does not have PMP - CPU should take illegal exception on pmpaddr0 write ... You need to modify your test to avoid programming PMP and other facilities, unimplemented in this CPU.

[Ankelih]

@algrobman Thank you for the information, however the situation is a little bit weird. Yes, I can see that core takes illegal operation on pmpaddr0 however I can see in the log that instruction is executed. After that one, there is one li instruction in the code but it is not logged on the trace and it is not executed. In the screenshot you can see the trace log from core(left) and from spike(right).

[algrobman]

the testbench / tracer are confusing in sense of printing trace log with exceptions. Really instructions #48, #49 are not executed, but trapped .

You can't compare spike and EH1 traces - spike implements more CSRs than EH1 and EH1 has privet CSRs , spike does not have.

You better compare the RTL with whisper ISS.

you can enhance TB trace printing as :

                   $fwrite (el, "%10d : %8s %0d %h %h%13s ; %s%s\n",cycleCnt, $sformatf("#%0d",commit_count), 0,
                           trace_rv_i_address_ip[31+i*32 -:32], trace_rv_i_insn_ip[31+i*32-:32],
                           (wb_dest[i] !=0 && wb_valid[i]) ?  $sformatf("%s=%h", abi_reg[wb_dest[i]], wb_data[i]) : "             ",
                           dasm(trace_rv_i_insn_ip[31+i*32 -:32], trace_rv_i_address_ip[31+i*32-:32], wb_dest[i] & {5{wb_valid[i]}}, wb_data[i]), trace_rv_i_exception_ip ? " !EXCEPTION!" : ""
                           );

To see if an instruction was trapped. trac_rv_i_ecause_ip bus can be printed in case of exception to show mcause, and trace_rv_i_tval_ip to show mtval

[Ankelih]

@algrobman Okay, they are trapped, and not executed really, but I do not understand why the core is not executing the instruction address 0x0000010C. I also use whisper ISS, and whisper skips that "li" instruction too. Since the Veer EH-1 is a RISC-V core, it should cover the standards. As far as I know pmpaddr0 is a machine-level CSR and Veer EH-1 is supporting machine-level. So, it should support pmpaddr0 I guess. But for now, my main question is why the core not executing the "li" instruction.

Thanks for the suggestion about trace printing, I'll add it to the testbench.

[algrobman]

The test code is a bit tricky - instead of having unimplemented instruction handler , the test presets mtvec to instruction, next to one, potentially could be trapped (which are all CSR writes ) just before each of these CSR access instructions. This makes the CPU to skip pieces of code related to unimplemented CSRs programming.

The RISCV spec defines PMP as optional facility, so this core does not implement it. There is no sense in PMP for Machine mode only CPU. It more usable if U or/and S modes are implemented.

BTW, trace with exceptions printing can look like:

     16595 :      #36 0 000000d4 00000297   x5=000000d4 ; auipc   x5,0x0
     16604 :      #37 0 000000d8 01028293   x5=000000e4 ; addi    x5,x5,16
     16605 :      #38 0 000000dc 30529073               ; csrrw   x0,mtvec,x5
     16613 : Exception 0 Cause=0x02 mtval=74445073
     16613 :      #39 0 000000e0 74445073               ; csrrwi  x0,csr_744,0x08 !EXCEPTION!
     16629 :      #40 0 000000e4 00000297   x5=000000e4 ; auipc   x5,0x0

[algrobman]

but I do not understand why the core is not executing the instruction address 0x0000010C.

the test sets up mtvec to 0x114 before programming PMP CSRs - once write to pmpaddr0 traps CPU goes directly to 0x114

[Ankelih]

@algrobman Thank you very much, I understand the situation now.
I am closing the case.