Simple system VCS simulation fails with multiple errors

[sabbari]

I want to simulate the simple system example using VCS, the build passes without any issue, but when I run the simulation, I get multiple errors caused by failed assertion

My Environment

EDA tool and version:

VCS S-2021.09-SP1_Full64 Operating system:

Red Hat Enterprise Linux release 8.5 **Version of the Ibex source code:** master branch hash : 668856441a73ebd067c09fdd2432241a32b8f03d **first part of the long errors list** Chronologic VCS simulator copyright 1991-2021 Contains Synopsys proprietary information. Compiler version S-2021.09-SP1_Full64; Runtime version S-2021.09-SP1_Full64; May 2 13:47 2022 Initializing memory ibex_simple_system.u_ram.u_ram.gen_generic.u_impl_generic.unnamed$$_2.gen_meminit from file './examples/sw/simple_system/hello_test/hello_test.vmem'. "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 982: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX: started at 18s failed at 18s Offending '(!$isunknown(instr_req_o))' Error: "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 982: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX: at time 18 18: (../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv:982) [ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX] [ASSERT FAILED] IbexInstrReqX "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 983: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqPayloadXKnownEnable: started at 18s failed at 18s Offending '(!$isunknown(instr_req_o))' Error: "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 983: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqPayloadXKnownEnable: at time 18 18: (../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv:983) [ibex_simple_system.u_top.u_ibex_top.IbexInstrReqPayloadXKnownEnable] [ASSERT FAILED] IbexInstrReqPayloadXKnownEnable "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 1002: ibex_simple_system.u_top.u_ibex_top.IbexInstrGntX: started at 18s failed at 18s Offending '(!$isunknown(instr_gnt_i))' Error: "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 1002: ibex_simple_system.u_top.u_ibex_top.IbexInstrGntX: at time 18 18: (../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv:1002) [ibex_simple_system.u_top.u_ibex_top.IbexInstrGntX] [ASSERT FAILED] IbexInstrGntX "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 982: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX: started at 20s failed at 20s Offending '(!$isunknown(instr_req_o))' Error: "../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 982: ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX: at time 20 20: (../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv:982) [ibex_simple_system.u_top.u_ibex_top.IbexInstrReqX] [ASSERT FAILED] IbexInstrReqX

[vogelpi]

Thanks @sabbari for reporting this issue. Unfortunately, I could not fully reproduce it locally. I am using the same VCS version and did build the simulation with:

fusesoc --cores-root=. run --target=sim --tool=vcs --setup --build lowrisc:ibex:ibex_simple_system --RV32E=0 --RV32M=ibex_pkg::RV32MFast --SRAMInitFile=examples/sw/simple_system/hello_test/hello_test.vmem

then run with:

/build/lowrisc_ibex_ibex_simple_system_0/sim-vcs/lowrisc_ibex_ibex_simple_system_0 -gui &

In my case a different SVA is failing. E.g.,

"../src/lowrisc_ibex_ibex_top_0.1/rtl/ibex_top.sv", 1000: ibex_simple_system.u_top.u_ibex_top.IbexDataRPayloadX: started at 98s failed at 98s
    Offending '(!$isunknown({data_rdata_i, data_rdata_intg_i, data_err_i}))'

The failing assertion is:

`ASSERT_KNOWN_IF(IbexDataRPayloadX, {data_rdata_i, data_rdata_intg_i, data_err_i}, data_rvalid_i)

and I think there is either an issue with the assertion itself or less likely the memory model. To me it sounds okay for the memory model to return X on a write request. data_rvalid_i just indicates whether the response is valid. i.e, in case of a write, only data_err_i should really matter. I think we should fix the assertion. Alternatively, maybe the binary/simulation environment can be changed to initialize everything to zero. But this sounds less clean to me. @rswarbrick , @ctopal do you know how this is handled in the RISCV-DV environment?

It should also be said that the primary use case for the simple system is to have a quick and simple, Verilator-based simulation environment that we use e.g. to run CoreMark. For the real DV, we use the UVM environment under dv/uvm/core_ibex.

[rswarbrick]

Hmm. I agree with what you're saying, Pirmin. I'm a bit surprised if the core_uvm agents don't drive rdata to X on writes: they probably should! I think the assertion just needs fixing. @GregAC, I think you added it as part of 0f69d4972: any strong reason not to factor in "and it was a read"?

[abdullahyildiz]

Hi,

I get similar errors for commit 7ba6667.

[jamesrbailey]

We have run into the IbexDataRPayloadX issue as well on our own system.

The prim_generic_ram_1p module does not initialize its rdata_o flops, so they are X until the first read. Therefore if you write this memory model before reading it, it will necessarily set off this assertion. As a workaround, we initialize these flops to zero.

Agreed with comments that qualifying the assertion based on it being a read is sensible. This information does not appear to be available in the ibex_top hierarchy where the assertion exists, but I think a hierarchical reference to u_ibex_core.load_store_unit_i.data_we_q would work.

[GregAC]

My apologies for the slow response to this.

I have made a fix in https://github.com/lowRISC/ibex/pull/1725. I added some tracking logic so the assertions know which outstanding requests are read and then apply the X checks appropriately. This allows me to successfully run the hello_test binary on simple system under VCS. I've observed the first response, which is to a write, having Xs in rdata_i not triggering assertion failures.

We should really drive these inputs to X in the UVM testbench. I'll create a separate issue to trace.