05-08-2019 05:08 PM - edited 05-08-2019 05:21 PM
Made a single change to my KCU040 design and added the Debug Bridge v3.0 to my BD, which already has System ILA's, and other ILA's and VIO's outside of the BD, and now the debug hub is not found. The debug bridge is configured for AXI-BSCAN and the AXI port is driven by an AXI interconnect which has it's slave axi port connected to the master axi port of AXI Bridge for PCIe Gen3 Subsystem core.
Opened the routed dcp and confirmed that the dbg_hub is present and it's clk port is connected to the clk freerun_in from my gth core block.
Looked at the C_USER_SCAN_CHAIN property of the previous revision of the design that works and the current version with the debug bridge and they are both set to 1.
Tried manually setting the the BSAN_SWITCH_USER_MASK to 0010, 0011, 0100 by
set_property BSCAN_SWITCH_USER_MASK xxxx, then refreshed the design and same result
BD is created with Vivado 2018.3 in Linux. Hardware Manager is ran from a Win10 laptop with Vivado 2018.3 as well.
05-10-2019 10:36 AM
At which point do you notice that the dbg_hub was not found? Do you get an error when when programming the device? If so, could you please post a screenshot?
How are you configuring the device and how are you trying to access the ILA and VIO? Is it via the PCIe link? Have you tried via JTAG as well?
I'm asking these questions so we can better understand the flow and pin point the issue.
05-10-2019 10:42 AM
The device programs ok. We notice that there is no dbg_hub when Hardware Manager provides the warning when it loads. We are connecting to the hw server via JTAG using the xilinx programming pod.
05-13-2019 03:27 PM
I thinnk is that, since you added the Debug Bridge and connected it via AXI to the PCIe, the design is expecting that you are going to access the debug cores (ILA, VIO, etc) through that link and not via JTAG.
You may be able to solve this issue by adding another go into the first Debug Bridge configuragion wizard and enable the JTAG Fallback feature.
Then you will need to a second Debug Bridge in the mode BSCAN to DebugHub, and connect it to the first one as below:
This will enable the first Debug Bridge to also receive JTAG connection and direct it to the Debug Hub, which manages the connections to the debug cores.
One question, since you are still connecting via JTAG, what was the purpose of adding the Debug Bridge to the design?
05-13-2019 04:18 PM
The purpose of adding the Debug Bridge was to implement XVC. The thought though was to debug the transactions going to the Debug Bridge to ensure they were getting there. I will try your recommendation, as it definitely makes sense given the scenario.
05-14-2019 03:44 PM
Not so much luck here. I'm failing DRC now with errors such as these. I though it was specific to a particular ILA but then I purposely didn't generate it and still got a DRC error on another ILA. These ILA's are outside of the BD in my design.
ERROR: [DRC AVAL-244] Independent_clock_check: The RAMB18E2 cell u_xxxxx/u_xxxxx/u_xxxxxx_ila/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop.ram.r/prim_noinit.ram/DEVICE_8SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram has CLOCK_DOMAINS=INDEPENDENT. However the two clock pins, CLKARDCLK and CLKBWRCLK, are driven by the same driver. The expected property value for CLOCK_DOMAINS for this clocking connectivity is COMMON. Improperly setting this attribute can impact simulation, optimization, and timing for the RAM resulting in incorrect simulation behavior, potential loss of performance, and increase in power.