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

[nikhill-agnisys]

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

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