[dv] tb_cs_registers golden-model error in ePMP extension

[ZhongYic00]

Observed Behavior

DV test lowrisc:ibex:tb_cs_registers fails given +ntb_random_seed=111

Error, transaction:
Register transaction:
Operation:  CSR Read
Address:    PMPCfg0
Read data:  6981400
Expected rdata: 6981484
- ../src/lowrisc_ibex_tb_cs_registers_0/tb/tb_cs_registers.sv:111: Verilog $finish
Received $finish() from Verilog, shutting down simulation.
[Reg driver] drove: 4970 register transactions

//-------------//
// TEST FAILED //
//-------------//

Expected Behavior

CS_Registers test should pass, RTL's dealing with mseccfg and pmpcfg is right.
At that point, mseccfg.MML is set, write a new entry with exec privilege to pmpcfg results in no change.

The provided golden-model in base_register.cc is wrong when handling CSRWrite to pmpcfg.
It should first check mseccfg.MML then write, rather than dealing with // No reserved L/R/W/X values when MML Set.

It should check whether the new entry is a "new rule with executable privilege".
This may be due to SMEPMP extension's evolving.

uint32_t PmpCfgRegister::RegisterWrite(uint32_t newval) {
  uint32_t lock_mask = GetLockMask();
  uint32_t read_value = register_value_;

  register_value_ &= lock_mask;
  register_value_ |= (newval & ~lock_mask);
  register_value_ = HandleReservedVals(register_value_);

  return read_value;
}

Steps to reproduce the issue

fusesoc --cores-root=. run --target=sim --tool=verilator lowrisc:ibex:tb_cs_registers --run_options='+
ibex_tracer_enable=1 +ntb_random_seed=0'

My Environment

EDA tool and version:

Verilator 4.210 2021-07-07 rev v4.210

Operating system:

Ubuntu Linux 22.04

Version of the Ibex source code:

8f4c75c

[brdr-life]

Also hit this from a separate testbench. Seed 0, fails at transaction 1119.

The gap is in the model. ibex_cs_registers.sv suppresses the write:

assign pmp_cfg_wr_suppress[i] = pmp_mseccfg_q.mml  &
                                ~pmp_mseccfg_q.rlb &
                                is_mml_m_exec_cfg(pmp_cfg_wdata[i]);

is_mml_m_exec_cfg is true when the new byte has lock set and {read, write, exec} is 001, 010, 011 or 101.

PmpCfgRegister::RegisterWrite, RegisterSet and RegisterClear have no equivalent. All three mask by GetLockMask() (lock & !RLB), then call HandleReservedVals:

uint32_t PmpCfgRegister::RegisterWrite(uint32_t newval) {
  uint32_t lock_mask = GetLockMask();
  uint32_t read_value = register_value_;

  register_value_ &= lock_mask;
  register_value_ |= (newval & ~lock_mask);
  register_value_ = HandleReservedVals(register_value_);

  return read_value;
}

The model does know about MML there, since HandleReservedVals returns early with No reserved L/R/W/X values when MML Set. So it has the relaxation but not the restriction.

In my failing case mseccfg was 0x3 (MML=1, MMWP=1, RLB=0) and the byte the model applied was 0x9a (L=1, R=0, W=1, X=0, so {r,w,x} is 010):

Operation:  CSR Set
Address:    PMPCfg0
Write data: a392b5f3
Read data:  9f978f
Expected rdata: 9a9f978f

Fix: in all three write paths, skip the per-byte update when mseccfg.MML && !mseccfg.RLB and the candidate byte has lock set with {r,w,x} in that set.

[SamuelRiedel]

Thanks for reporting this. I had a look and implemented a fix for this and some other issues I stumbled upon in the golden model in #2465. Can you please have a look and check whether this resolves your issue?