Error writing to memory using test bench files located in cv32e40s/tb/core

[MBleaux]

Bug Title

Error writing to memory using test bench files located in cv32e40s/tb/core

Type

Indicate whether the type of problem you found:

• Functionally incorrect behavior

Steps to Reproduce

cd cv32e40s/sim/core
make questa-custom-gui CUSTOM_PROG=hello-world CUSTOM=../../tests/programs/custom

• Note 1: The makefile located in cv32e40s/sim/core couldn't generate the binary file. So, I copied the .hex file generated by the simulation performed in cv32e40s/sim/uvmt to the path where the corresponding .c scripts are located (core-v-verif/cv32e40s/tests/programs/custom/hello-world/hello-world.hex).
• Note 2: It is necessary to ignore the .irq_ack_o and .irq_id_o signals (https://github.com/openhwgroup/core-v-verif/blob/master/cv32e40s/tb/core/cv32e40s_tb_wrapper.sv#L118-L119) as they do not exist in the cv32e40s_core.sv file (https://github.com/openhwgroup/cv32e40s/blob/master/rtl/cv32e40s_core.sv#L110).
• Note 3: In order to use the wrapper tb_top.sv (https://github.com/openhwgroup/core-v-verif/blob/master/cv32e40s/tb/core/tb_top.sv), it's necessary to ignore the wrapper located in bhv defined in cv32e40s_manifest.flist (https://github.com/openhwgroup/cv32e40s/blob/master/cv32e40s_manifest.flist#L33-L34 and https://github.com/openhwgroup/cv32e40s/blob/master/cv32e40s_manifest.flist#L87-L90)

Additional context

I'm facing an issue when I try to simulate the RTL cv32e40s files + RAM memory files using the wrapper tb_top.sv located in cv32e40s/tb/core. While the simulation in cv32e40s/sim/uvmt works fine, in cv32e40s/sim/core it is in an infinite loop. Analyzing the waveforms and the hello-world.objdump file, the microprocessor stops working correctly when it executes an instruction to store a value in the memory.

From the hello-world.objdump file:
1140: 00b703a3 sb x11,7(x14)

From the waveforms:

Looking at the uvm_test_top.env.rvfi_agent.trn.log generated by simulation performed in cv32e40s/sim/uvmt (by executing make test TEST=hello-world USE_ISS=NO GUI=YES CV_SIMULATOR=vsim), the instruction 1140: 00b703a3 sb x11,7(x14) is the first instruction related to memory access. As the microprocessor can no longer execute the other instructions, it remains in this state forever, which generates the infinite loop.

I've attached the waveforms, the hello-world function and the generated .log file here:
files.zip

[MikeOpenHWGroup]

Thanks for your interest in the CV32E40S @MBleaux. The "core" testbench for CV32E40S is not supported at this time. We would gladly accept a pull-request to restore it. Please start with the cv32e40s/dev branch of core-v-verif.

[MBleaux]

I understand the reason for the problem. Since the microprocessor initiates the countermeasures by default the value
0x0000_0019 (https://docs.openhwgroup.org/projects/cv32e40s-user-manual/en/latest/control_status_registers.html#cpu-control-cpuctrl), which includes the interface integrity, it expects that the microprocessor receives the signals of parity (e.g. instr_gntpar), but the file mm_ram.sv does not provide these signals because it is based on the P core, which implies errors in sorting and loading in memory (https://docs.openhwgroup.org/projects/cv32e40s-user-manual/en/latest/xsecure.html#interface-integrity). So, according to the OBI manual (https://github.com/openhwgroup/obi/blob/072d9173c1f2d79471d6f2a10eae59ee387d4c6f/OBI-v1.6.0.pdf), the parity signals must be the inverse of the corresponding signals (e.g. instr_gntpar ~= instr_gnt). I also changed some parameters in cv32e40s_tb_wrapper.sv because the UVM simulation uses different values for these parameters:

.DM_REGION_START ( 32'h1A110000 ),
.DM_REGION_END ( 32'h1A111000 ),
.LFSR0_CFG ('{ coeffs : 32'h80000057, default_seed : 32'habbacafe }),
.LFSR1_CFG ('{ coeffs : 32'h80000062, default_seed : 32'hbeef1234 }),
.LFSR2_CFG ('{ coeffs : 32'h8000007a, default_seed : 32'ha5a5a5a5 }),

I also set the data_err_i and instr_err_i signals to 0 because they were always low level in the UVM simulation. I don't think it's a good practice to put them in low level (e.g.: .data_err_i ( 1'h0 ),) but I couldn't find in the manual how to model these signals.

[MikeOpenHWGroup]

I couldn't find in the manual how to model these signals.

As you already know, the specification for the OBI is here. According to the CV32E40S User Manual, you will want v1.6.0. If there is a question about the OBI that you cannot answer from the specification, please create a GitHub Issue on that repository.