debugging is not working !!!

[kidonglee]

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]

• in terminal A
  fusesoc run --target=sim --run swervolf --jtag_vpi_enable
• in terminal B
  openocd -f $SWERVOLF_ROOT/data/swervolf_sim.cfg
• in terminal C
  telnet localhost 4444

[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]

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]

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]

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]

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]

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,

• load_image makes error messages, as below,

---

Error: Failed to read priv register.
Error: Failed to read priv register.
Error: Failed to read priv register.

• And, 'reg pc 0' also output error messages, as follow,

---

Error: Written PC (0x0) does not match read back value (0x7fff9f8f7290)

• 'resume' command sill does not work.

Please check again if I misunderstood your advice.

Thanks.

[olofk]

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]

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]

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

[olofk]

This looks very strange. I will need to investigate

[kidonglee]

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.

You can see that only lower 32-bit of 64-bit is written to memory.

Thank you,

[kidonglee]

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]

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.