verilator_tb_utils: JTAG server TMS glitches
tinylabs opened this issue · 5 comments
The JTAG server glitches the TMS input to the verilated model for a half cycle regularly.
This can be easily reproduced by:
- Add tinylabs-cores library: https://github.com/tinylabs/tinylabs-cores
- Build simulation: fusesoc run --target=sim cm3_min_soc
- Run and attach openocd using cortexm3sim.cfg script
$> ./build/cm3_min_soc_0.1/sim-verilator/Vcm3_min_soc --jtag-server --vcd=sim.vcd
$> openocd -f ./build/cm3_min_soc_0.1/src/cm3_min_soc_0.1/scripts/cortexm3sim.cfg
Let me know if you need any more info.
I'll try to take a look this ASAP.
I did reproduce the problem using your setup and I found a missing break:
Could you please try it ?
Hi Franck,
Thank you for looking at this. It does indeed seem to fix most of the glitches. I do see two glitches still and have added code to print them when found:
Found glitch at 16029
Found glitch at 282848
I'm not convinced these are a problem though as they don't happen around the rising JTAG_CLK edge. I see you also wrote the openocd side. Do you know if this interface has only been tested on riscv? I've verified the Cortex-M3 design in hardware and have no problems connecting JTAG. Also, I have previously written an openocd bitbang server and tested the interface without issue. I suppose my next step would be to port that over to verilator_tb_utils...
The main issue is openocd receives an invalid ACK (7) from the ARM DAP (should be 4). Appreciate your help!
Info : This adapter doesn't support configurable speed
Info : JTAG tap: CortexM3Sim.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : CortexM3Sim.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : CortexM3Sim.cpu: external reset detected
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: CortexM3Sim.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: Invalid ACK (7) in DAP response
Error: DP initialisation failed
I used this when I was working on the mor1kx (openrisc).
An yes, it seems like riscv guys are using it.
However, I think they use the version of the jtagServer here: https://github.com/fjullien/jtag_vpi
They improved this part and the openocd driver as well.
I fixed the last (?) glitch problem here e19c2e8 (sorry for the commit message, I fixed the code directly in the github interface, and screw it up. Now, I don't know how to change it without cloning the repo).
May be I could push my changes on the other repo.
I have to admit I don't remember exactly when we moved from verilator_tb_utils jtagServer to the one in jtag_vpi :(
Sorry for this mess.
That fixed the glitches, thanks again! Unfortunately I still see DAP related errors so I'm going to fork verilator_tb_utils and add a openocd bitbang server.