VCS simulation infinite loop with JTAG VPI

I would like to use JTAG VPI to simulate freedom-e300 with vcs. First I wanted to do that in vsim with the default config.
In rocketchip directory in src/main/scala/rocketchip/Configs.scala I have replaced SimDTM in BasePlatformConfig by changing IncludeJtagDTM => false to true. the generated verilog contains JTAG VPI but running simv goes into an infinite loop. What could be the problem ? and is there an already written script to simulate freedom-e300 with JTAG VPI ?

You need to add +jtag_vpi_enable to your simv command line. The simulation should pause with a message like “Listening on Port 1234” if it is ready to receive connections over the VPI.

Adding +jtag_vpi_enable did the trick. Thanks
At “Listening on port …” I should run openOCD from riscv-tools/riscv-tests/debug ?

You can try using the gdbserver.py method of running all the tests in riscv-tests/debug. These may take quite a while to run against your simulation. I don’t think the necessary simulation targets are really set up there.

Alternatively, you can just launch openocd with a cfg file , then connect to OpenOCD as usual with GDB/telnet and start debugging you sim!

Depending on the speed of your simulation you may need to tweak some timeouts in the tests and/or in GDB/OpenOCD.

Here is a CFG file you can use to connect to a simulation (JTAG_VPI_PORT should be the port the simulation is listening to).

source [find interface/jtag_vpi.cfg]
jtag_vpi_set_port $::env(JTAG_VPI_PORT)

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME

riscv set_reset_timeout_sec 120
riscv set_command_timeout_sec 120

init
halt
echo "Ready for Remote Connections"

Thanks Megan.

on “Listening on port …” I start openOCD with jtag_vpi interface. Then I get “Waiting for client connection…ok”. After some time of normal operation openocd exits but the other terminal is still on “Waiting for client connection…ok”. Since it took much longer than SimDTM and .out file seemed abnormal, I had to interrupt the simulation.
I checked AXI4RAM from the unfinished vpd output and it seems the instructions were loaded correctly.

This is openocd log for dhrystone benchmark test.
Also I had to omit “riscv set_reset_timeout_sec 120” and "riscv set_command_timeout_sec 120 " because they were causing error when running openocd.

Open On-Chip Debugger 0.10.0+dev (2017-11-02-14:49)
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
Info : Set server port to 37287
Info : Connection to 127.0.0.1 : 37287 succeed
Info : This adapter doesn’t support configurable speed
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
Info : Examined RISCV core; XLEN=32, misa=0x40001105
Info : Listening on port 3333 for gdb connections
Info : [0] Found 1 triggers
halted at 0x1000 due to debug interrupt
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting ‘gdb’ connection on tcp/3333
0x00001000 in ?? ()
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
halted at 0x1000 due to debug interrupt
halted at 0x1000 due to debug interrupt
invalid subcommand "protect 0 64 last off"
in procedure 'flash’
invalid subcommand "protect 0 64 last off"
in procedure 'flash’
Loading section .text.init, size 0x1fc lma 0x80000000
Loading section .tohost, size 0x48 lma 0x80001000
Loading section .text, size 0x1844 lma 0x80001048
Loading section .text.startup, size 0x73c lma 0x8000288c
Loading section .rodata.str1.4, size 0x5e8 lma 0x80002fc8
Loading section .rodata, size 0x258 lma 0x800035b0
Loading section .eh_frame, size 0x3c lma 0x80003808
Start address 0x80001048, load size 10816
Transfer rate: 35 bytes/sec, 1545 bytes/write.
halted at 0x8000104c due to step
halted at 0x8000104c due to step
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1361). Workaround: increase “set remotetimeout” in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1361). Workaround: increase “set remotetimeout” in GDB
shutdown command invoked
shutdown command invoked
A debugging session is active.

Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Remote communication error. Target disconnected.: Connection reset by peer.

And this is some lines of the .out file that I thought abnormal.

C 0: 19 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 20 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 21 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 22 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 23 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 24 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 25 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 26 [0] pc=[9208a424] W[r 0=00000000][0] R[r15=3d6d81fa] R[r 8=d87b77b1] inst=[0487f509] DASM(0487f509)
C 0: 27 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 28 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 29 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 30 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 31 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 32 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 33 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 34 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 35 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 36 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 37 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 38 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 39 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 40 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 41 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 42 [0] pc=[00001000] W[r 0=00001002][0] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)
C 0: 43 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)

stays on DASM(0000006f) for a while then

799976 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799977 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799978 [0] pc=[00000000] W[r 0=00000000][0] R[r 2=fc4d6afb] R[r 0=fc4d6afb] inst=[0001041f] DASM(0001041f)
C 0: 799979 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000000] inst=[0001041f] DASM(0001041f)
C 0: 799980 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000002] inst=[0001041f] DASM(0001041f)
C 0: 799981 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799982 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799983 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799984 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799985 [0] pc=[00000000] W[r 0=00000000][0] R[r 2=fc4d6afb] R[r 0=fc4d6afb] inst=[0001041f] DASM(0001041f)
C 0: 799986 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000000] inst=[0001041f] DASM(0001041f)
C 0: 799987 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000002] inst=[0001041f] DASM(0001041f)
C 0: 799988 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799989 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799990 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799991 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799992 [0] pc=[00000000] W[r 0=00000000][0] R[r 2=fc4d6afb] R[r 0=fc4d6afb] inst=[0001041f] DASM(0001041f)
C 0: 799993 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000000] inst=[0001041f] DASM(0001041f)
C 0: 799994 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000002] inst=[0001041f] DASM(0001041f)
C 0: 799995 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799996 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799997 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799998 [0] pc=[00000002] W[r 0=00000002][0] R[r 2=fc4d6afb] R[r 0=00000004] inst=[0001041f] DASM(0001041f)
C 0: 799999 [0] pc=[00000000] W[r 0=00000000][0] R[r 2=fc4d6afb] R[r 0=fc4d6afb] inst=[0001041f] DASM(0001041f)

sometimes I could find what seems to be normal operation

60272 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=400080cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 60273 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60274 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60275 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60276 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60277 [1] pc=[00000864] W[r 8=400080cb][1] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60278 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60279 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60280 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=400080cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 60281 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60282 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60283 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60284 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60285 [1] pc=[00000864] W[r 8=400080cb][1] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60286 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60287 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60288 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=400080cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 60289 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60290 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60291 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60292 [0] pc=[0000086c] W[r 0=00000001][0] R[r 8=400080cb] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 60293 [1] pc=[00000864] W[r 8=400080cb][1] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60294 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60295 [0] pc=[00000864] W[r 0=400080cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 60296 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=400080cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 60297 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)

I’m a bit confused by what exactly you are asking, as things seem to be generally working. You successfully connected with OpenOCD and GDB and were able to load your program. As GDB suggests in its messages, you probably should do something set remotetimeout 120 (or so) before doing target extended-remote localhost to the target to avoid the keep_alive errors.

Yes loading the code to ram works but the code doesn’t seem to run correctly. .out file seems to show that the operation goes into loops and i don’t get the expected dhrystone results as opposed to the simdtm case. And also the sim terminal is stuck on “waiting for client connection … ok” and the results are not printed in the console

Are you saying that the problem is actually the keep_alive() warning ? Cause I have changed the “set remotetimeout” to various values including 120 and the warning didn’t disappear.

Can you please explain exactly what you did, and what you expect to happen? How did you invoke OpenOCD and GDB? In GDB, did you “load” and then “continue”?

What results do you expect to be printed to the console? Unless you are running your simv with +verbose, you won’t really see anything in the simv output other than “waiting for client connection …ok”

To clarify, your .out file results look perfectly reasonable. You shouldn’t really pay attention to any lines that aren’t committed, (just look at the ones with [1] before the pc= part).

From your snippets:

C 0: 43 [1] pc=[00001000] W[r 0=00001002][1] R[r 0=912a7d23] R[r 0=d87b77b3] inst=[0000006f] DASM(0000006f)

That is showing the first instruction committed at 0x1000, which is the reset vector for the design

60272 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=400080cb] R[r 0=00000000] inst=[02047413] DASM(02047413)

These that are executing at pc = 0x800 (anything less than 0x1000) are the debug module in operation, as you’re communicating with OpenOCD and GDB.

Once you do load and then continue in GDB, you should see instructions committing at the _start location in your program , probably 0x800000000.

If that’s not what happens, then it’s quite possible that your program isn’t linked properly and you get an exception when the core tries to start executing it.

Thanks Megan for the feedback. I have verified my command files according to the hints you recommended but unfortunately I still can’t figure out what the problem is. So I will describe what I did.

  1. I run dhrystone benchmark using SimDTM and I got the following output printed on the console:

Microseconds for one run through Dhrystone: 771
Dhrystones per Second: 1296
mcycle = 386247
minstret = 301227
$finish called from file “/home/kimokono/rocket-chip/vsrc/TestDriver.v”, line 123.
$finish at simulation time 219639550

So when I change SimDTM to JTAG_VPI I expect similar printed output

  1. Then I change SimDTM to JTAG_VPI by assigning IncludeJtagDTM to true instead of false in the class BasePlatformConfig in src/main/scala/rocketchip/Configs.scala

  2. Then I run the DefaultRV32Config using this shell script on one terminal

mkdir -p /home/kimokono/rocket-chip/vsim/generated-src/

cd /home/kimokono/rocket-chip

java -Xmx2G -Xss8M -XX:MaxPermSize=256M -jar /home/kimokono/rocket-chip/sbt-launch.jar “run-main rocketchip.Generator /home/kimokono/rocket-chip/vsim/generated-src rocketchip TestHarness rocketchip DefaultRV32Config”

java -Xmx2G -Xss8M -XX:MaxPermSize=256M -cp /home/kimokono/rocket-chip/firrtl/utils/bin/firrtl.jar firrtl.Driver -i /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.fir -o /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.v -X verilog --infer-rw TestHarness --repl-seq-mem -c:TestHarness:-o:/home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.conf

cd /home/kimokono/rocket-chip/vsim/generated-src

rm -f /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.behav_srams.v

/home/kimokono/rocket-chip/vsim/vlsi_mem_gen /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.conf >> /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.behav_srams.v.tmp

mv /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.behav_srams.v.tmp /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.behav_srams.v

rm -rf csrc

cd /home/kimokono/rocket-chip/vsim

rm -rf output

vcs -full64 -notice -line +lint=all,noVCDE,noONGS,noUI -error=PCWM-L -timescale=1ns/10ps -quiet +rad +v2k +vcs+lic+wait +vc+list -CC “-I/tools/synopsys/vcs/I-2014.03-2/include” -CC “-I/home/kimokono/rocket-chip/riscv-tools/toolchain//include” -CC “-std=c++11” -CC “-Wl,-rpath,/home/kimokono/rocket-chip/riscv-tools/toolchain/lib” /home/kimokono/rocket-chip/riscv-tools/riscv-fesvr/libfesvr.so -sverilog +incdir+/home/kimokono/rocket-chip/vsim/generated-src +define+CLOCK_PERIOD=1.0 /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.v /home/kimokono/rocket-chip/vsim/generated-src/rocketchip.DefaultRV32Config.behav_srams.v /home/kimokono/rocket-chip/vsrc/TestDriver.v /home/kimokono/rocket-chip/vsrc/jtag_vpi.v /home/kimokono/rocket-chip/vsrc/SimDTM.v /home/kimokono/rocket-chip/vsrc/DebugTransportModuleJtag.v /home/kimokono/rocket-chip/vsrc/AsyncResetReg.v /home/kimokono/rocket-chip/csrc/SimDTM.cc /home/kimokono/rocket-chip/csrc/jtag_vpi.c +define+PRINTF_COND=TestDriver.printf_cond +define+STOP_COND=TestDriver.reset +define+RANDOMIZE_MEM_INIT +define+RANDOMIZE_REG_INIT +define+RANDOMIZE_GARBAGE_ASSIGN +define+RANDOMIZE_INVALID_ASSIGN +libext+.v +vpi -P /home/kimokono/rocket-chip/vsrc/jtag_vpi.tab -CC “-DVCS_VPI” -o ./simv-rocketchip-DefaultRV32Config-debug +define+DEBUG -debug_pp

mkdir -p ./output
ln -fs /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/dhrystone.riscv output/dhrystone.riscv
./simv-rocketchip-DefaultRV32Config-debug +jtag_vpi_enable -q +ntb_random_seed_automatic +verbose +vcdplusfile=output/dhrystone.riscv.vpd +max-cycles=100000000 output/dhrystone.riscv 2> output/dhrystone.riscv.out && [ $PIPESTATUS -eq 0 ]

dhrystone.riscv is obtained by the following script:

riscv32-unknown-elf-gcc -mcmodel=medany -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -DPREALLOCATE=1 -DHOST_DEBUG=0
-c -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/…/env -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/median -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/qsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/rsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/towers -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/multiply -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mm -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/spmv -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-matmul /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common/syscalls.c -o syscalls.o

riscv32-unknown-elf-gcc -mcmodel=medany -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -DPREALLOCATE=1 -DHOST_DEBUG=0 -D__ASSEMBLY__=1
-c -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/…/env -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/median -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/qsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/rsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/towers -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/multiply -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mm -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/spmv -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-matmul /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common/crt.S -o crt.o

riscv32-unknown-elf-gcc -mcmodel=medany -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -DPREALLOCATE=1 -DHOST_DEBUG=0
-c -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/…/env -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/median -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/qsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/rsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/towers -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/multiply -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mm -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/spmv -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-matmul /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone/dhrystone_main.c -o dhrystone_main.o

riscv32-unknown-elf-gcc -mcmodel=medany -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -DPREALLOCATE=1 -DHOST_DEBUG=0
-c -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/…/env -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/median -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/qsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/rsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/towers -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/multiply -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mm -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/spmv -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-matmul /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone/dhrystone.c -o dhrystone.o

riscv32-unknown-elf-gcc -T /home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common/test.ld -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/…/env -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/common -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/median -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/qsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/rsort -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/towers -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/multiply -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mm -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/dhrystone -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/spmv -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-vvadd -I/home/kimokono/rocket-chip/riscv-tools/riscv-tests/build/…/benchmarks/mt-matmul dhrystone_main.o dhrystone.o syscalls.o crt.o
-o dhrystone.riscv -static -nostdlib -nostartfiles -lgcc

riscv32-unknown-elf-objdump --disassemble-all --disassemble-zeroes --section=.text --section=.text.startup --section=.data dhrystone.riscv > dhrystone.riscv.dump

  1. Once I get the port, on another terminal I run this following command

./work/build/openocd/prefix/bin/openocd -f /home/kimokono/freedom-e-sdk/openocd.cfg & /home/kimokono/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb /home/kimokono/rocket-chip/vsim/output/dhrystone.riscv --batch -ex “set remotetimeout 5000000” -ex “target extended-remote localhost:3333” -ex “monitor reset halt” -ex “monitor flash protect 0 64 last off” -ex “load” -ex “monitor resume” -ex “monitor shutdown” -ex “quit”

where openocd.cfg is the following.

source [find interface/jtag_vpi.cfg]
jtag_vpi_set_port 47417

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME

init
halt

The result is what I described in the previous comments. The simulation doesn’t end and I don’t get the dhrystone expected output that is supposed to be printed on the console.

I tried using Xlen = 64 instead of Xlen =32 thinking there might be a compatibility problem in the crt.S and link script test.ld but I get the same results.

As far as the start location, you mentioned, is concerned I get some committed instructions on what seems to be 0x800000000 address. The following is a snippet from .out file related to that.

C 0: 64263 [1] pc=[00000408] W[r 0=0000040c][1] R[r 0=00000000] R[r28=e11cfac3] inst=[3fc0006f] DASM(3fc0006f)
C 0: 64264 [0] pc=[00000804] W[r 0=00000808][0] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)
C 0: 64265 [0] pc=[00000806] W[r 0=0000080a][0] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)
C 0: 64266 [0] pc=[00000806] W[r 0=0000080a][0] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)
C 0: 64267 [0] pc=[00000806] W[r 5=80000000][1] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)
C 0: 64268 [0] pc=[00000806] W[r 0=0000080a][0] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)
C 0: 64269 [0] pc=[00000806] W[r 0=0000080a][0] R[r 2=00000000] R[r 0=e11cfac3] inst=[0001041f] DASM(0001041f)

.
.
.
.

C 0: 66244 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=80000000] inst=[0001041f] DASM(0001041f)
C 0: 66245 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=80000000] inst=[0001041f] DASM(0001041f)
C 0: 66246 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=80000000] inst=[0001041f] DASM(0001041f)
C 0: 66247 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=80000000] inst=[0001041f] DASM(0001041f)
C 0: 66248 [1] pc=[00000400] W[r 8=00000410][1] R[r 0=00000000] R[r16=80000003] inst=[41002403] DASM(41002403)
C 0: 66249 [0] pc=[00000400] W[r 0=00000410][0] R[r 0=00000000] R[r16=80000003] inst=[41002403] DASM(41002403)
C 0: 66250 [0] pc=[00000404] W[r 0=80000000][0] R[r 5=80000000] R[r 8=00000000] inst=[0082a023] DASM(0082a023)
C 0: 66251 [0] pc=[00000408] W[r 0=80000004][0] R[r 5=80000000] R[r 4=80000003] inst=[00428293] DASM(00428293)
C 0: 66252 [0] pc=[00000408] W[r 0=80000004][0] R[r 5=80000000] R[r 4=80000003] inst=[00428293] DASM(00428293)

.
.
.

C 0: 710000 [0] pc=[00000870] W[r 0=00000000][0] R[r 8=00000000] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 710001 [0] pc=[00000870] W[r 0=00000000][0] R[r 8=4000b12f] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 710002 [0] pc=[00000870] W[r 0=00000000][0] R[r 8=4000b12f] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 710003 [0] pc=[00000870] W[r 0=00000000][0] R[r 8=4000b12f] R[r 0=00000003] inst=[fe040ce3] DASM(fe040ce3)
C 0: 710004 [1] pc=[00000870] W[r 0=00000874][1] R[r31=4000b12f] R[r 1=00000003] inst=[fe1ff06f] DASM(fe1ff06f)
C 0: 710005 [0] pc=[00000870] W[r 0=00000874][0] R[r31=4000b12f] R[r 1=00000003] inst=[fe1ff06f] DASM(fe1ff06f)
C 0: 710006 [0] pc=[00000870] W[r 0=00000874][0] R[r31=4000b12f] R[r 1=00000003] inst=[fe1ff06f] DASM(fe1ff06f)
C 0: 710007 [0] pc=[00000870] W[r 0=00000874][0] R[r31=4000b12f] R[r 1=00000003] inst=[fe1ff06f] DASM(fe1ff06f)
C 0: 710008 [0] pc=[00000850] W[r 0=00000850][0] R[r 2=4000b12f] R[r 0=00000003] inst=[0001041f] DASM(0001041f)
C 0: 710009 [0] pc=[00000852] W[r 0=00000852][0] R[r 2=4000b12f] R[r 0=00000003] inst=[0001041f] DASM(0001041f)
C 0: 710010 [0] pc=[00000852] W[r 0=00000852][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)
C 0: 710011 [0] pc=[00000852] W[r 0=00000852][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)
C 0: 710012 [0] pc=[00000852] W[r 0=00000852][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)
C 0: 710013 [1] pc=[00000850] W[r 0=00000418][0] R[r 0=00000000] R[r 9=e11cfac2] inst=[40902c23] DASM(40902c23)
C 0: 710014 [1] pc=[00000854] W[r 0=00000858][1] R[r 0=00000000] R[r 0=00000000] inst=[40000067] DASM(40000067)
C 0: 710015 [0] pc=[00000854] W[r 0=00000858][0] R[r 0=00000000] R[r 0=e11cfac2] inst=[40000067] DASM(40000067)
C 0: 710016 [0] pc=[00000854] W[r 0=00000858][0] R[r 0=00000000] R[r 0=e11cfac2] inst=[40000067] DASM(40000067)
C 0: 710017 [0] pc=[00000854] W[r 0=00000858][0] R[r 0=00000000] R[r 0=e11cfac2] inst=[40000067] DASM(40000067)
C 0: 710018 [0] pc=[00000400] W[r 0=00000008][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)
C 0: 710019 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)
C 0: 710020 [0] pc=[00000402] W[r 0=00000008][0] R[r 2=00000000] R[r 0=e11cfac2] inst=[0001041f] DASM(0001041f)

then it’s an infinite occurrence of inst=[0001041f] DASM(0001041f).

Thanks for your very clear explanation! Now I see what the problem is.

When you run the simulation with +jtag_vpi_enable, the JTAG VPI “controls” the time of the simulation. Time cannot advance unless it allows it, and it only allows it when there is something to send on the JTAG. So once you connect with OpenOCD, you need to keep sending JTAG traffic with OpenOCD to keep the simulation running.

Fortunately, OpenOCD keeps polling your simulation to see if any harts have halted (this doesn’t affect the runtime of Dhrystone as it doesn’t impact the running Core). So all you need to do is not quit OpenOCD after loading your program. So modify your GDB/OpenOCD command to remove the -ex "monitor shutdown" -ex "quit" parts. That will keep OpenOCD & GDB running and you can even debug your program if you wish.

Once the simulation exits, OpenOCD will probably quit on its own.

Thanks for your reply.

I have tried this openocd command

./work/build/openocd/prefix/bin/openocd -f /home/kcharfi/freedom-e-sdk/openocd.cfg & /home/kcharfi/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb /home/kcharfi/rocket-chip/vsim/output/dhrystone.riscv --batch -ex “set remotetimeout 240” -ex “target extended-remote localhost:3333” -ex “monitor reset halt” -ex “load” -ex “monitor resume”

which also gives an infinite occurrence of inst=[0001041f] DASM(0001041f)

and also I tried this command but it ended with Info : dropped ‘gdb’ connection

./work/build/openocd/prefix/bin/openocd -f /home/kcharfi/freedom-e-sdk/openocd.cfg & /home/kcharfi/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb /home/kcharfi/rocket-chip/vsim/output/dhrystone.riscv --batch -ex “set remotetimeout 240” -ex “target extended-remote localhost:3333” -ex “monitor reset halt” -ex “load” -ex

This gave slightly different .out file but also it has a repetitive pattern as follows which keeps on going in a loop

C 0: 1253633 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)
C 0: 1253634 [1] pc=[00000864] W[r 8=4000b0cb][1] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253635 [0] pc=[00000864] W[r 0=4000b0cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253636 [0] pc=[00000864] W[r 0=4000b0cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253637 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=4000b0cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 1253638 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)
C 0: 1253639 [1] pc=[00000864] W[r 8=4000b0cb][1] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253640 [0] pc=[00000864] W[r 0=4000b0cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253641 [0] pc=[00000864] W[r 0=4000b0cb][0] R[r 0=00000000] R[r16=00000003] inst=[7b002473] DASM(7b002473)
C 0: 1253642 [1] pc=[00000868] W[r 8=00000000][1] R[r 8=4000b0cb] R[r 0=00000000] inst=[02047413] DASM(02047413)
C 0: 1253643 [1] pc=[0000086c] W[r 0=00000001][0] R[r 8=00000000] R[r 0=00000000] inst=[fe040ce3] DASM(fe040ce3)

However I tried to compare .out file of both SimDTM and JTAG_VPI and I realized that in .out file of SimDTM at some point in the simulation has pc values orred with 0x80000000, as in the following snippet, which is the start address. But it never happens with the simulation using JTAG_VPI. Since you mentioned this issue in a previous comment I thought of sharing. I think seeing pc values orred with 0x80000000 is due to the linker which I didn’t change when moving from SimDTM to JTAG_VPI. So I am not sure whether this difference, I observed, has something to do with openocd or something else.

C 0: 1219437 [0] pc=[00000838] W[r 0=00000000][0] R[r 0=00000000] R[r18=00000003] inst=[7b200073] DASM(7b200073)
C 0: 1219438 [0] pc=[00000838] W[r 0=00000000][0] R[r 0=00000000] R[r18=00000003] inst=[7b200073] DASM(7b200073)
C 0: 1219439 [0] pc=[00000838] W[r 0=00000000][0] R[r 0=00000000] R[r18=00000003] inst=[7b200073] DASM(7b200073)
C 0: 1219440 [0] pc=[00000838] W[r 0=00000000][0] R[r 0=00000000] R[r18=00000003] inst=[7b200073] DASM(7b200073)
C 0: 1219441 [0] pc=[00000838] W[r 0=00000000][0] R[r 0=00000000] R[r18=00000003] inst=[7b200073] DASM(7b200073)
C 0: 1219442 [1] pc=[80000080] W[r30=00000000][1] R[r 0=00000000] R[r 0=00000000] inst=[00000f13] DASM(00000f13)
C 0: 1219443 [1] pc=[80000084] W[r31=00000000][1] R[r 0=00000000] R[r 0=00000000] inst=[00000f93] DASM(00000f93)
C 0: 1219444 [1] pc=[80000088] W[r 5=0001e000][1] R[r 3=400000e3] R[r 0=00000000] inst=[0001e2b7] DASM(0001e2b7)
C 0: 1219445 [1] pc=[8000008c] W[r 0=00001800][1] R[r 5=0001e000] R[r 0=00000000] inst=[3002a073] DASM(3002a073)
C 0: 1219446 [0] pc=[8000008c] W[r 0=00001800][0] R[r 5=00000000] R[r 0=00000003] inst=[3002a073] DASM(3002a073)
C 0: 1219447 [0] pc=[8000008c] W[r 0=00001800][0] R[r 5=00000000] R[r 0=00000003] inst=[3002a073] DASM(3002a073)
C 0: 1219448 [0] pc=[8000008c] W[r 0=00001800][0] R[r 5=00000000] R[r 0=00000003] inst=[3002a073] DASM(3002a073)
C 0: 1219449 [0] pc=[8000008c] W[r 0=00001800][0] R[r 5=00000000] R[r 0=00000003] inst=[3002a073] DASM(3002a073)

And still I can’t see the expected printed output even after long simulation time.

Let’s try without the batch mode GDB. You’ll need 3 windows:

  1. start the simulation as you did before

Wait for the “listening on port…” message

  1. openocd -f openocd.cfg

Wait until it says “ready for remote connections”. Note that this can take several minutes. If you want, add “-d” so you can see what openOCD is up to. If you do that, it will start polling at some point and you may not see the “ready” message.

  1. riscv-unknown-elf-gdb dhrystone.riscv

Just leave 1 and 2 running, and do the following GDB commands:

(GDB) set remotetimeout 1000
(GDB) target extended-remote localhost:3333

Again this may take minutes to complete!
(GDB) load

This will load your program, and again will take a LONG time. You should see each section getting loaded.

(GDB) continue

This will run your program.

If you want at this point you can hit ctrl-C, or before continue, you can do things like:

(GDB) display/i $pc
(GDB) stepi

To step through your program, or use other GDB commands.

Note that all of this is VERY slow. We don’t usually run full programs in this way because it is so slow to simulate. So patience will be necessary!

Thanks Megan that was helpful to debug.
I have tried what you suggested and I figured the cause of the infinite loop. However I am not sure why it occurs. Apparently the program enters a loop when it reaches ret instruction on 80001058.

This is a snippet from dhrystone dump file

80001048 Proc_2:
80001048: 00003717 auipc a4,0x3
8000104c: 81974703 lbu a4,-2023(a4) # 80003861 <Ch_1_Glob>
80001050: 04100793 li a5,65
80001054: 00f70463 beq a4,a5,8000105c <Proc_2+0x14>
80001058: 00008067 ret
8000105c: 00052783 lw a5,0(a0)
80001060: 00003717 auipc a4,0x3
80001064: 80872703 lw a4,-2040(a4) # 80003868 <Int_Glob>
80001068: 00978793 addi a5,a5,9
8000106c: 40e787b3 sub a5,a5,a4
80001070: 00f52023 sw a5,0(a0)
80001074: 00008067 ret

80001078 Proc_3:
80001078: 00002617 auipc a2,0x2
8000107c: 7f862603 lw a2,2040(a2) # 80003870 <Ptr_Glob>
80001080: 00060a63 beqz a2,80001094 <Proc_3+0x1c>

These are GDB commands and their response

(gdb) display/i $pc
1: x/i $pc
=> 0x80001048 <Proc_2>: auipc a4,0x3
(gdb) nexti
0x8000104c in Proc_2 ()
1: x/i $pc
=> 0x8000104c <Proc_2+4>: lbu a4,-2023(a4)
(gdb)
0x80001050 in Proc_2 ()
1: x/i $pc
=> 0x80001050 <Proc_2+8>: li a5,65
(gdb)
0x80001054 in Proc_2 ()
1: x/i $pc
=> 0x80001054 <Proc_2+12>: beq a4,a5,0x8000105c <Proc_2+20>
(gdb)
0x80001058 in Proc_2 ()
1: x/i $pc
=> 0x80001058 <Proc_2+16>: ret
(gdb)
0x41798b82 in ?? ()
1: x/i $pc
=> 0x41798b82: unimp

And this is a snippet from openocd window. in addition to using 0.10 openocd version, increasing remote timeout doesn’t seem to help removing the keep_alive warning.

halted at 0x1000 due to debug interrupt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting ‘gdb’ connection on tcp/3333
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3245). Workaround: increase “set remotetimeout” in GDB
halted at 0x8000104c due to step
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1559). Workaround: increase “set remotetimeout” in GDB
halted at 0x80001050 due to step
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1910). Workaround: increase “set remotetimeout” in GDB
halted at 0x80001054 due to step
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1556). Workaround: increase “set remotetimeout” in GDB
halted at 0x80001058 due to step
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1553). Workaround: increase “set remotetimeout” in GDB
halted at 0x4f72108 due to step
Core got an exception (0xffffffff) while reading from 0x4f7213c
(It may have failed between 0x4f72100 and 0x4f7213b as well, but we didn’t check then.)

I tried to debug the vcd output using a logic analyzer. When I checked the pc register value in the write back stage of SimDTM I realized that the pc 80001058 which is the ret instruction, that causes the problem, is skipped and there is no occurrence of it in the wb_reg_pc.

However for JTAG VPI there is an occurrence of 80001058 and wb_reg_valid is high when it shows up.
I have attached the screenshots.

I agree with the fact that the simulation is very slow. However it seems that there is a problem that causes discontinuity in the instructions sequence leading the core to enter a loop that it doesn’t recover from.

This is a snippet from the .out file that shows how the infinite loop starts after pc = 80001058

C 0: 867132 [1] pc=[80001058] W[r 0=8000105c][1] R[r 1=df2d0abe] R[r 0=00000000] inst=[00008067] DASM(00008067)
C 0: 867133 [0] pc=[80001058] W[r 0=8000105c][0] R[r 1=df2d0abe] R[r 0=00000000] inst=[00008067] DASM(00008067)
C 0: 867134 [0] pc=[80001058] W[r 0=8000105c][0] R[r 1=df2d0abe] R[r 0=00000000] inst=[00008067] DASM(00008067)
C 0: 867135 [0] pc=[80001058] W[r 0=8000105c][0] R[r 1=df2d0abe] R[r 0=00000000] inst=[00008067] DASM(00008067)
C 0: 867136 [0] pc=[df2d0abe] W[r 0=df2d0abe][0] R[r 2=df2d0abf] R[r 0=00000003] inst=[0001041f] DASM(0001041f)
C 0: 867137 [0] pc=[df2d0abe] W[r 0=df2d0abe][0] R[r 2=df2d0abf] R[r 0=00000003] inst=[0001041f] DASM(0001041f)
C 0: 867138 [0] pc=[df2d0abe] W[r 0=df2d0abe][0] R[r 2=df2d0abf] R[r 0=00000003] inst=[0001041f] DASM(0001041f)

Before executing the ret you should take a look at the relevant registers that the instruction will use and see if it makes sense. It looks like whatever is in $x1 may be junk.

Hello Megan. I have actually moved to work on the freedom-e300-arty verilog instead of the default one . I have implemented a small controller to replace the flash with an “on chip” SRAM. With some modification of the fespi driver I have successfully performed the read/write from/to SRAM (acting as flash). I could see the UART starting to operate (Dhrystone benchmark) shortly after the read from flash starts. then the UART goes high during the computation (time it takes to get dhrystone results). Then I understood what you meant by it takes very long and it needs patience and the fact that you actually don’t test a risc-v based processor with a benchmark in simulation stage. During 24h I just got 150ms worth of simulation time. I had to interrupt the simulation. But I think if read/write from/to spi flash and uart were verified, that should be satisfactory. Anyway thank you very much for the support.