dmi_bscane_tap synthesis problem in Vivado 2023.2

[andreondra]

Hello, I've integrated the riscv-dbg project to my FPGA-based SoC project and I've encountered a weird behavior in synthesis of the dmi_bscane_tap.sv module. I use Vivado 2023.2 and target Nexys Video (Artix 7, part number xc7a200tsbg484-1).

When the BSCANE2 TAP is used, the synthesis optimizes out all of the dmi_jtag_tap module except the TCK signal. All others are either not connected or tied to the ground. Fact that a lot of logic is missing is obvious from the synthesis scheme and from logs, there are messages e.g. about removing sequential logic in the dmi_cdc module:

WARNING: [Synth 8-3332] Sequential element (i_dmi_cdc/i_cdc_req/i_cdc_reset_ctrlr/i_cdc_reset_ctrlr_half_a/i_state_transition_cdc_src/FSM_sequential_state_q_reg[1]) is unused and will be removed from module dmi_jtag.

I use the latest (master) version of the riscv-dbg, common-cells and tech-cells. Normally I would suspect a bug in my part of the design, but when I use JTAG TAP (dmi_jtag_tap.sv), no logic is optimized out, no warning messages about unused signals are in logs and the debugging works as expected both in simulation and on the FPGA.

Documentation of the BSCANE2 primitive is pretty sparse. I tried to search for similar problem but I didn't find anything relevant -- e.g. in Ibex Demo System the BSCANE2 works as expected (but an older version of the riscv-dbg is used). Does anybody encountered a similar problem? Or maybe there is something I miss? Maybe special constraints need to be defined when the BSCANE TAP is used?

[andreondra]

Well, just I was about to give it up, I found a solution. At first I tried to play with KEEP, DONT_TOUCH etc. attributes on various modules and so on. When I used the DONT_TOUCH attribute I found out that while the interface of the dmi_jtag_tap was kept this time, rest of the logic was thrown away either way => there was another signal on which the logic was dependent on, and that was trst_ni. When using BSCANE variant, this signal is not driven by anything and the cdc_2phase_clearable module inside dmi_cdc.sv is not synthesized properly/being optimized out in that case. So, I tied the trst_ni signal to 1'b1 (no reset) and it solved the problem: no more logic thrown away and debugging working correctly on my Nexys Video board.

Is that intentional? Maybe it is obvious to set this signal to 1'b1 but I didn't find any mention of it anywhere.