search

chipsalliance / VeeRwolf

FuseSoC-based SoC for VeeR EH1 and EL2
284 stars 64 forks source link

debugging is not working !!! #26

Open kidonglee opened 3 years ago

kidonglee commented 3 years ago

I am following the 'debugging' sequences. In normal simulation, "SweRV+FuseSoC rocks" is displayed. But, in debug mode, there is no response from simulator after "releasing reset" message. Please check the simulation results, as below, Thanks in advance.

[test sequences]

[terminal message output] - in terminal A INFO: Running INFO: Running simulation Starting jtag_vpi server: interface 127.0.0.1 (loopback), port 5555/tcp ... jtag_vpi server created. Waiting for client connection... Client connection accepted. JTAG VPI enabled. Not loading RAM Releasing reset

- in terminal B Open On-Chip Debugger 0.10.0+dev-01402-gccb21ab5a (2020-10-20-17:21) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' Info : Set server port to 5555 Info : Set server address to 127.0.0.1 Warn : riscv set_prefer_sba is deprecated. Please use riscv set_mem_access instead. Info : Connection to 127.0.0.1 : 5555 succeed Info : This adapter doesn't support configurable speed Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (), part: 0x0000, ver: 0x0) Info : datacount=2 progbufsize=0 Warn : We won't be able to execute fence instructions on this target. Memory may not always appear consistent. (progbufsize=0, impebreak=0) Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=32, misa=0x40001104 Info : starting gdb server for riscv.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : accepting 'telnet' connection on tcp/4444

- in terminal C Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger

load_image /home/kdlee/work/riscv/chipsalliance/Cores-SweRVolf/sw/hello.elf 69 bytes written at address 0x00000000 downloaded 69 bytes in 4.572055s (0.015 KiB/s)

reg pc 0 pc (/32): 0x00000000

resume

Codasip commented 3 years ago

Please check https://github.com/chipsalliance/Cores-SweRV-Support-Package (SSP) . There is SweRVolf integrated already with SweRV EH1 1.8 and proven Open On-Chip Debugger 0.10.0+dev-01255-g2c909f8 (2020-09-29-10:12) . Your problem will high probably disappear if you run you experiments within Cores-SweRV-Support-Package environment with this SweRVolf and SweRV EH1 1.8, however you may extract from the SSP installation what you need.

kidonglee commented 3 years ago

Please check https://github.com/chipsalliance/Cores-SweRV-Support-Package (SSP) . There is SweRVolf integrated already with SweRV EH1 1.8 and proven Open On-Chip Debugger 0.10.0+dev-01255-g2c909f8 (2020-09-29-10:12) . Your problem will high probably disappear if you run you experiments within Cores-SweRV-Support-Package environment with this SweRVolf and SweRV EH1 1.8, however you may extract from the SSP installation what you need.

I tried "Cores-SweRV-Support-Package (SSP)". But I have some problem with installing ssp script. So I append new issue on "Cores-SweRV-Support-Package (SSP)" If possible, please help me once again.

Thanks.

Codasip commented 3 years ago

My answer to your ssp install problem can be found in the issue you have opened there.

Back to your question. The last 2 lines in $SWERVOLF_ROOT/data/swervolf_sim.cfg are: # Halt the target halt It means - SweRV EH1 is in halt state after init and therefore you do not get any response.

kidonglee commented 3 years ago

My answer to your ssp install problem can be found in the issue you have opened there.

Back to your question. The last 2 lines in $SWERVOLF_ROOT/data/swervolf_sim.cfg are:

Halt the target

halt It means - SweRV EH1 is in halt state after init and therefore you do not get any response.

Thanks for the prompt reply. Actually, because I am a beginner in this area, I didn't understand the meaning exactly. I'll remove those lines and try again.

Thanks again.

kidonglee commented 3 years ago

My answer to your ssp install problem can be found in the issue you have opened there.

Back to your question. The last 2 lines in $SWERVOLF_ROOT/data/swervolf_sim.cfg are:

Halt the target

halt It means - SweRV EH1 is in halt state after init and therefore you do not get any response.

Dear Codasip, I tried your solution but it seems to be getting worse. In previous, load_image works with no error. However, after removing 'halt' command in swervolf_sim.cfg,

Please check again if I misunderstood your advice.

Thanks.

olofk commented 3 years ago

Hi @kidonglee . There is another thing that you should know about. When the --jtag_vpi_enable switch is used, SweRVolf will not load any program to RAM. The reason for that is that the default program (the one that prints fusesoc+swerv rocks) will exit before you have a chance to connect the debugger. This means that you must load an elf file yourself with openocd after the debugger is connected.

olofk commented 3 years ago

Ah, I looked at your original report now and see that you already load an elf file. It looks like everything should be ok. I will need to check if I can see any issues here. One thing that caught my eyes is Warn : riscv set_prefer_sba is deprecated. Please use riscv set_mem_access instead. Your openocd version is probably newer than the one I have.

Perhaps you could run halt again after the resume command and a) read the memory through openocd to make sure that the elf file was programmed correctly. e.g.mdw 0 8 should give you the first 8 words of the memory b) Check the value of the PC. Since this is a very short program, the PC should not be higher than 0x00000040

You can also add --vcd at the end of the command line to produce a waveform file that can be useful for checking what's going on (note that the simulation will run much slower with this enabled). The waveform file can be found in build/swervolf_0.7/sim-verilator/trace.vcd

Hope this helps

kidonglee commented 3 years ago

Ah, I looked at your original report now and see that you already load an elf file. It looks like everything should be ok. I will need to check if I can see any issues here. One thing that caught my eyes is Warn : riscv set_prefer_sba is deprecated. Please use riscv set_mem_access instead. Your openocd version is probably newer than the one I have.

Perhaps you could run halt again after the resume command and a) read the memory through openocd to make sure that the elf file was programmed correctly. e.g.mdw 0 8 should give you the first 8 words of the memory b) Check the value of the PC. Since this is a very short program, the PC should not be higher than 0x00000040

You can also add --vcd at the end of the command line to produce a waveform file that can be useful for checking what's going on (note that the simulation will run much slower with this enabled). The waveform file can be found in build/swervolf_0.7/sim-verilator/trace.vcd

Hope this helps

Dear olofk, First of all, thank you for the kind advice. I checked the the points that you mentioned. There seems to be a problem with image load via openocd. According to vcd wave, dmi_wrapper write data is OK, but only 32 bits of 64 bits are written to ram. In my thought, there seems to be some problem. Even though, I don't know the reason exactly. If you don't mind, please check the results.

Here are the test results. 1. hello.vh 0085051380001537 0285859300000597 0055002300058283 0005828300158593 2. memory read mdw 0 8 0x00000000: 80001537 00000000 00000597 00000000 00058283 00000000 00158593 00000000 3. vcd wave image

olofk commented 3 years ago

This looks very strange. I will need to investigate

kidonglee commented 3 years ago

This looks very strange. I will need to investigate

Dear, olofk.

Here is an additional wave image for the details on we[7:0] signals. image You can see that only lower 32-bit of 64-bit is written to memory.

Thank you,

kidonglee commented 3 years ago

This looks very strange. I will need to investigate

Dear olofk,

I am sorry to bother you but I wonder if there is any progress with this issue. How is it going ?

Thanks

kidonglee commented 3 years ago

This looks very strange. I will need to investigate

Dear olofk,

I look into RTL code and find some clue. axi2wb module can not handle 64-bit data at once. it can handle only upper or lower 32-bit data at once. However, swerv core generate 64-bit write transaction to axi2wb block. It seems to make this problem. Please check and fix it.

Thanks.