17:36 <MichaelMonaghan> Hello everyone, hope you are doing well! First time on the IRC here and I am looking for advice on how to approach writing code to support Xilinx's bscan2jtag IP core. Is this the right place?

17:37 <antto> possibly yes, stick around till the more significant people notice

17:38 <MichaelMonaghan> Great! I'll go ahead and post my question

17:39 <antto> sure

17:43 <MichaelMonaghan> In brief, bscan2jtag exposes a JTAG interface within an FPGA through a protocol established via a single special purpose data register on the FPGA's TAP.

17:43 <MichaelMonaghan> Would it make sense to write an adapter driver or are there other better ways to approach this? I am not yet familiar with the openocd code base.

18:11 <borneoa_> MichaelMonaghan: I remember there is already some bscan related code in OpenOCD. In the riscv code, probably. But it's deeply embedded in that code. If you have other use cases in mind, it could be good to abstract bscan for general use.

18:21 <Hawk777> There are some boundary scan commands not related to RISC-V <https://openocd.org/doc/html/Boundary-Scan-Commands.html>. But I don’t know how useful those are for this purpose; AFAIK they’re more for doing normal boundary scan stuff (i.e. exercising I/O pins), not for creating subsidiary JTAG interfaces.

18:26 <MichaelMonaghan> borneoa_ You're right. I also noticed that SiFive contributed code with similar functionality here <https://github.com/riscv/riscv-openocd/pull/370>, but like you said, it is deeply embedded and *only* allows RISC-V debug transport modules to be used via SiFives "BSCAN tunnel" (which is incompatible with bscan2jtag).

20:20 <karlp> jsut for my own curiosity, what do you use this to? it gets you a jtag interface to something that already has a jtag interface, why can't you just expose that? is this just a workaround to not require any pins dedicated, at the expense of only working while things are halted?

21:30 <MichaelMonaghan> karlp This is just a workaround to exposing additional JTAG pins and using a separate adapter for the debug target within the FPGA. By design, to ensure the FPGA's TAP is always accessible, there is no way to insert a TAP within the FPGA onto the same chain the FPGA's TAP is on.

21:34 <MichaelMonaghan> I should probably mention that "bscan" is the name of the interface within the FPGA that exposes one of four of the FPGA TAP's special purpose data registers reserved for the user, hence the name bscan2jtag.

21:35 <karlp> not being able to just add a tap to the existing chain suckz :|

21:35 <karlp> what's the point of chaining jtag if you... cna't

21:35 <karlp> but I get that they try and "protect" you frrom it :)

21:41 <MichaelMonaghan> It certainly does. I predict bscan2jtag will be used a lot in the future of Xilinx FPGAs if they move to RISC-V processors. For example, a principle engineer at Xilinx is using it in his RISC-V project <https://github.com/eugene-tarassov/vivado-risc-v>. Saying it would be nice to be able to use OpenOCD and GDB instead of the Xilinx debugger would

21:41 <MichaelMonaghan> be an understatement.