openocd timeout occurs when trying to load elf file using command 'load_image'.

[nikhill-agnisys]

Hello all,

I am trying to debug SweRV RISCV RTL v1.9 during simulation using bitbang bridge and openocd in my environment. For this, I have instantiated SimJTAG module in my testbench and connected it with swerv core. Now, using bitbang a server socket is created and I am able to listen on port 9999.

In another terminal (terminal 2) , I launched openocd (vOpen On-Chip Debugger 0.11.0+dev-01861-g6edf98db7-dirty) using my 'sim_swervjtag.cfg' file, the contents of config file are shown below,

` adapter speed 100

adapter driver remote_bitbang remote_bitbang_host localhost

remote_bitbang_port 9999

set _CHIPNAME riscv

jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x01

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

riscv set_enable_virt2phys off

riscv set_mem_access abstract

riscv expose_csrs 1988

proc swerv_eh1_execute_fence {} { reg csr1988 0x3 }

$_TARGETNAME configure -event resume-start { swerv_eh1_execute_fence }

$_TARGETNAME configure -event step-start { swerv_eh1_execute_fence }

init

halt `

On another terminal (terminal 3), When I connect using telnet localhost 4444 and try to issue load_image command after reset I get timeout error as below,

On terminal 2, it outputs as shown without -d debug switch,

With debug switch -d, please find attached the log file 'openocd.log',

openocd.log

I have tried increasing the timeout interval using 'riscv set_command_timeout_sec' to 2000 but then it never comes out.

If possible, please point me to any pointer on how to resolve this. Thanks.

[olofk]

Is there any reason why you are using the bitbang bridge instead of jtag_vpi, which is the supported solution in SweRVolf?

[olofk]

Oh, sorry. I thought this was the SweRVolf repo, not the SweRV repo. Anyway, SweRVolf, the reference platform for SweRV support this out of the box if that is of any help

[nikhill-agnisys]

There is no specific reason, it is just I am not using verilator but xcelium, and I find it a little easy to link 'bitbang' and 'SimJTAG.v' DPI files with it.

[agrobman]

based on what I see in your logs - openocd could not connect/access Swerv JTAG controller - (it tries to read JTAG ID register , but gets all 0s from it. Normally it would find Manufacturer ID as of WDC ).

[aprnath]

@agrobman, jtag_id is an input. It should be tied off to the value you expect for your implementation.

The logs do indicate that the debugger is able to connect and gather some information (MISA etc).

Maybe your timeout is not long enough if the model is running slower. The logs show first abstractcs as 0x1002 - which indicates busy, and the 2nd one shows 0x1102, which indicates cmderr with busy as the error code...

[agrobman]

What is your design memory map? what do you have at address 0x0? Do you have ICCM/DCCM and what address is set for PIC? what are the base addresses you set for ICCM/DCCM and PIC?

Based on the attached openocd trace the CPU was instructed to execute memory write abstract command to address 0x0, which was timed out.

if you run simulation, you should see the CPU System Bus (SB) write transaction started (AWVALID, WVALID from the CPU - check, that you get corresponded *READY are asserted too, then what you get BVALID from SB slave) - all in case if address 0x0 is not base address of ICCM/DCCM or PIC.

BTW, in the provided TB SB is tied off - any abstract command to the core external memory will time out. If you are trying to load your code to external memory, you'll need a sort of crossbar to route SB transactions to IFU bus slave memory. (does not exist in this testbench) to be able load code by debugger to that memory.

If your design configuration does have ICCM, you may consider to compile your test to ICCM addresses. In that case CPU will load your code to the ICCM. but if your CPU reset vector does not point to ICCM you'll need set up PC to the start address of your test before running it. Or you may configure your CPU to have ICCM starting from address 0x0 ..

[nikhill-agnisys]

Hello everyone,

It was really helpful to have your inputs, thank you all for the wonderful contributions. After spending some additional time in target simulation I was able to find why my abstract commands were failing. My SB was indeed tied of, causing debug state to remain as 'SB_CMD_RESP' for rest of the simulation.

Adding crossbar to route the transactions worked for me. Thanks for the suggestion @agrobman

Also, thanks @olofk for pointing me to the reference SwerRVolf repository, I tried it out and it really supports it out of the box. I am able to fix my issue now.