Cosim mismatch in some tests with PMP enabled using QuestaSim

[omarbesta]

Observed Behavior

I am getting the following error when running the tests using the default configuration (OpenTitan).

# UVM_FATAL ibex/dv/uvm/core_ibex/common/ibex_cosim_agent/ibex_cosim_scoreboard.sv(168) @ 50673967:
uvm_test_top.env.cosim_agent.scoreboard [uvm_test_top.env.cosim_agent.scoreboard] Cosim mismatch Synchronous trap was expected at ISS PC: ffffffff8000360a but the DUT didn't report one at PC 80003606

• riscv_debug_instr_test
• riscv_debug_wfi_test
• riscv_interrupt_wfi_test
• riscv_debug_single_step_test
• Other tests are matching the behavior in Ibex Regression Results

Expected Behavior

It was expected for these tests to pass with the default configuration as of here Ibex Regression Results
When I set the PMPEnable to 0 in ibex configuration file it passes gracefully.

Steps to reproduce the issue

• make SIMULATOR=questa ITERATIONS=1 TEST=riscv_debug_wfi_test

The test passes when PMPEnable is set to 0 in ibex_configs.yaml

My Environment

EDA tool and version: Questasim 2023.1

Operating system: Linux-64 CentOS 7.9

Version of the Ibex source code: df88055

[rswarbrick]

Hmm, this might be a problem with Questa support. At lowRISC, we don't currently have Questa access so it's rather hard for us to help.

Can you reproduce the problem with another simulator (Xcelium / VCS / Verilator) as well? If not, I think you might have to do a bit more digging to figure out what's coming unstuck.

[omarbesta]

Unfortunately, I can't run using another simulator at the time.
I have pinpointed the issue location to this code section.

vendor/google_riscv-dv/src/riscv_asm_program_gen.sv

    if (riscv_instr_pkg::support_pmp) begin
      str = {indent, "j main"};
      instr_stream.push_back(str);
    end

If I comment it out the test passes.
Any ideas here about what does this code section do or what can be a possible cause here?

[omarbesta]

Another follow-up is that the traces between ISS and RTL are erroring out at only the last instruction where on ISS it is giving the instruction "wfi" while on the RTL side, it is not giving anything the last instruction is the one before it.

trace_core	rtl_trace
8000353c 58dd c.li x17,-9 x17=0xfffffff7	8000353c,c.li,a7:fffffff7,,58dd,,"c.li x17,-9","a7,-9"
8000353e 0199c2b3 xor x5,x19,x25 x19:0x5dba8bcc x25:0x0000000e x5=0x5dba8bc2	8000353e,xor,t0:5dba8bc2,,0199c2b3,,"xor x5,x19,x25","t0,s3,s9"
80003542 10500073 wfi	---

[rswarbrick]

The code you've pinpointed is part of riscv-dv: a random instruction generator that we use as a dependency. Looking at it briefly, this seems to tell the generated binary to branch to "main" at the start. We probably won't do anything interesting if that's commented out :-)

Your note about the traces makes sense. I suspect that this means the "there was a WFI instruction" message isn't getting to the DV code properly. @GregAC knows lots more about this area. Greg: any ideas?

[omarbesta]

All tests mentioned don't generate the "WFI" instructions in the rtl_trace.