Open MBleaux opened 1 month ago
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.
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.
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.
Bug Title
Error writing to memory using test bench files located in cv32e40s/tb/core
Type
Indicate whether the type of problem you found:
Steps to Reproduce
Additional context
I'm facing an issue when I try to simulate the RTL cv32e40s files + RAM memory files using the wrapper _tbtop.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.rvfiagent.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 instruction1140: 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