EmbeddedRiscvJtag synthesis issue

[gregdavill]

Summary

After adding EmbeddedRiscvJtag to a VexRiscv design as described in the README, I was not able to connect to it. I'm using yosys/nextpnr to target an ECP5, I have an FTDI 2232H connected to the ECP5 (channel A) and I/O pins (channel B).

I've started with the default LietX cpu and swapped in the EmbeddedRiscvJtag plugin.

Details

conf.cfg

adapter driver ftdi
ftdi vid_pid 0x0403 0x6010
ftdi channel 1
ftdi layout_init 0x0038 0x003b

transport select jtag
adapter speed 3000

set _CHIPNAME riscv
set _TARGETNAME $_CHIPNAME.cpu

jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x10002FFF
target create $_TARGETNAME.0 riscv -chain-position $_TARGETNAME

init
halt

Output from openocd

openocd -f ./openocd/conf.cfg 
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : clock speed 3000 kHz
Info : TAP riscv.cpu does not have valid IDCODE (idcode=0xfffffffe)
Error: riscv.cpu: IR capture error; saw 0x1e not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Warn : target riscv.cpu.0 examination failed
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet

Workaround

From the start I was getting correct results in sim. So focused debugging on the FPGA flow, and it appears that during synthesis something funky was happening leaving me with tdo kept in bypass mode. the yosys logs did not indicate logic removal of the debug core, etc.

I noticed that tap_fsm_state is not reset, and I suppose in theroy is doesn't have to be, since the JTAG tap can reset it's logic with TMS=1 + TCKs

If I alter the rtl and add an initial value to tap_fsm_state things work..

...
  reg        [1:0]    logic_jtagLogic_dmiStat_value_aheadValue;
  wire       [3:0]    tap_fsm_stateNext;
  reg        [3:0]    tap_fsm_state = 0;  <-------
  wire       [3:0]    _zz_tap_fsm_stateNext;
  wire       [3:0]    _zz_tap_fsm_stateNext_1;
...

$ openocd -f ./openocd/conf.cfg 
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : clock speed 3000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x10002fff (mfg: 0x7ff (<invalid>), part: 0x0002, ver: 0x1)
Info : datacount=1 progbufsize=2
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x0
Info : starting gdb server for riscv.cpu.0 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

My workaround doesn't really feel like a solution. I'm not sure if this is actually a vexriscv bug? Or a bug in yosys.