COREV-DV initilization gpr value issue

[murattokez]

Hello,

I am using the cv32e40p/dev branch. In ~/core-v-verif/cv32e40p/env/corev-dv/cv32e40p_asm_program_gen.sv, how should I change the "reg_val" constant value in the init_str_reserved_gpr and init_gpr functions according to my linker script? Also, do I need to change anything in any other file to prevent writes to memory where I don't want them?

I changed the memory sections in my linker script and made the boot_address 0x80000080.

[murattokez]

I think I also need to change the SET_GPR_VALUE values in the set_reserved_sp_addr function in ~/core-v-verif/cv32e40p/enc/corev-dv/instr_lib/cv32e40p_float_instr_lib.sv. I have done a couple of try so that it doesn't conflict with my memory, but it still writes to very large and very small addresses in my memory as shown below.

[MikeOpenHWGroup]

Hi @murattokez, you are deep into the weeds of the core-v-verif environment now! 🤣 If you change the boot address of the test-program, you must also change the value of the boot_addr_i input to the core to match. You can control this on the simulator command-line with a plusarg: +boot_addr=32'h0800_0080. If you are using Synopsys VCS you can use the VCS_RUN_FLAGS to set this on the Make command-line:

$ make test TEST=hello-world SIMULATOR=vcs VCS_RUN_FLAGS=+boot_addr=32'h0800_0080 USE_ISS=NO

If you are using a different simulator, look in the appropriate mk/uvmt/<simulator>.mk file for the variable to use (it should be <SIM>_RUN_FLAGS).

You will, of course, need to edit the linker control script to match the new boot address. Unfortunately, this is a hardcoded value in the E40P environment (the E40S generates the linker-control script on-the-fly to solve this particular issue).

Lastly, have a look at the test-program configuration YAMLs, (see Bulid Configurations) in mk/README. You should be able to define a SystemVerilog runtime plusarg there.

[murattokez]

“You can control this on the simulator command-line with a plusarg: +boot_addr=32'h0800_0080” I was not aware of this information, thank you. I actually changed this value to hardcoded in the UVM environment. What I don't understand about my current issue is that now I put the address of the ram +0x80000000 up. In the codes in the image I sent, in the “FIX ME” line, there is a statement that this value should be able to change depending on the linker. There are also many SET_GPR_VALUE statements in cv32e40p_float_instr_lib.sv file. Should I change all these values? According to the memory section in the original linker, the addresses in the image I posted are too high. So I made this assumption and moved these addresses even higher than 0x80000000 to addresses like 0xa0000000, 0xb0000000..., but no matter what I do, in my trace.log file there is always access to the low places 0x000123xx or high places 0xffff123xx of my memory during floating point instructions.

[MikeOpenHWGroup]

I suspect the problem is with your linker control script. Have a look at the readelf and objdump files. They will be located in cv32e40p/sim/uvmt/<simulator>_results/default/hello-world/0/test_program/. Please note that unless you are a member of the OpenHW Group, I will not be able to spend much time debugging your modifications to the environment.

As you may have figured out already, the Makefiles place all generated outputs from a simulation into <simulator>_results/CFG/<test-program>/<run>. The readelf and objdump will be in <simulator>_results/CFG/<test-program>/<run>/test_program/. Admittedly, this is only partially documented in mk/README.

[murattokez]

Can you just tell me what the value 0x80000000 was chosen for in the picture I posted. I was especially confused by the FIXME comment line.

[MikeOpenHWGroup]

0x80000000 is the default value driven onto the core's boot_addr_i input vector.

[murattokez]

Are you sure about this. In cv32e40p_tb_wrapper.sv BOOT_ADDR='h80 and in linker the boot address is 0x80.

[MikeOpenHWGroup]

Ack. Sorry, you are right. (I am currently doing some work with Spike and its default boot address is 0x80000000 and I mixed up the numbers...)

[murattokez]

I converted the linker and the forwarded files to the original(cv32e40p/dev branch) and ran floating point tests from corev-dv. Something seems to be wrong. Are the following lines from the log file normal? The addresses in memory where the main code is located are being accessed.

[MikeOpenHWGroup]

Can you provide me with the exact set of command-lines you ran to obtain this? Please start with git clone...