You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The file loaded in module generic_memory by $readmemh is a relative file location, and so not found if the Verilator model is not run in an expected directory. In our example, the problem was triggered trying to open mem_init/TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri0_i.u0.mem.
We tested this using the prototype embdebug Verilator model GDB server. The error message is as follows.
charlie@troughton:~/src/install/bin$ ./embdebug --soname /home/charlie/src/embdebug-target-core-v/target/target.so --rsp-port 1234
Loading ITarget interface from dynamic library: /home/charlie/src/embdebug-target-core-v/target/target.so
Timescale 1ns / 1ns
Listening for RSP on port 1234
Remote debugging from host 127.0.0.1
TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri0_i.u0
%Error: mem_init/TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri0_i.u0.mem:0: $readmem file not found
Aborting...
Aborted (core dumped)
Changing this to run from the build/openhwgroup.org_systems_core-v-mcu_0/model-lib-verilator directory, caused correct behavior as follows:
charlie@troughton:~/src/core-v-mcu/build/openhwgroup.org_systems_core-v-mcu_0/model-lib-verilator$ ../../../../install/bin/embdebug --soname /home/charlie/src/embdebug-target-core-v/target/target.so --rsp-port 1234
Loading ITarget interface from dynamic library: /home/charlie/src/embdebug-target-core-v/target/target.so
Timescale 1ns / 1ns
Listening for RSP on port 1234
Remote debugging from host 127.0.0.1
TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri0_i.u0
TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri1_i.u0
TOP.core_v_mcu.i_soc_domain.l2_ram_i.CUTS[0].bank_i.u0
TOP.core_v_mcu.i_soc_domain.l2_ram_i.CUTS[1].bank_i.u0
TOP.core_v_mcu.i_soc_domain.l2_ram_i.CUTS[2].bank_i.u0
TOP.core_v_mcu.i_soc_domain.l2_ram_i.CUTS[3].bank_i.u0
...
The solution is either to ensure the $readmemh uses the absolute filename, or that there is a way to specify the base for any relative file references.
The text was updated successfully, but these errors were encountered:
Is there an existing core-v-mcu bug for this?
Bug Description
The file loaded in module
generic_memory
by$readmemh
is a relative file location, and so not found if the Verilator model is not run in an expected directory. In our example, the problem was triggered trying to openmem_init/TOP.core_v_mcu.i_soc_domain.l2_ram_i.bank_sram_pri0_i.u0.mem
.We tested this using the prototype embdebug Verilator model GDB server. The error message is as follows.
Changing this to run from the
build/openhwgroup.org_systems_core-v-mcu_0/model-lib-verilator
directory, caused correct behavior as follows:The solution is either to ensure the
$readmemh
uses the absolute filename, or that there is a way to specify the base for any relative file references.The text was updated successfully, but these errors were encountered: