09-17-2019 07:28 AM
I am using Vivado 2019.1 and am trying to program an UltraScale+ xczu3eg-sfva625-1-i (on a Avnet UltraZed-3EG with IO Carrier Card).
I am having trouble getting the debug cores to work on an UltraZed-EG dev board. I am able to successfully synthesize and implement my design and set up my debug cores. However, when I go to program the device, I get the following:
WARNING: [Labtools 27-3361] The debug hub core was not detected. Resolution: 1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active. 2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device. To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'. For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908). WARNING: [Labtools 27-3413] Dropping logic core with cellname:'u_ila_0' at location 'uuid_23E7D65A79BC59F7BC47406C1714DFAE' from probes file, since it cannot be found on the programmed device.
I have tried following other "Solved" threads on this forum, but nothing seems to work so far. Any advice?
09-17-2019 07:35 AM
first up, try droping the JTAG frequency to say 1 Mhz,
what do you see on the scan chain ?
what do yo uhave for clock constraints on the design
have you tried the TRD http://zedboard.org/support/design/14201/126
09-17-2019 08:16 AM
I have a PL clock set to 100 MHz, and I've constrained the clock coming to dbg_hub at a 20 ns period (50 MHz).
How do I view the scan chain, and what should I be looking for?
09-17-2019 02:26 PM
09-18-2019 05:23 AM - edited 09-18-2019 05:24 AM
My clock is ultimately produced by an MMCM buried in a block which is putputting 50 MHz. But I have also tried using 50 MHz fabric/PL clock routed directly from Zynq US+ PS block.
09-18-2019 10:08 AM
Could you please detail where is this clock originated? It is produced by an MMCM but where does it comes from before it enters the MMCM? Which pins? And are those pins on the PL or PS side?
This issue is in almost all the cases related to the clock not really arriving at the ILA.
When this clock comes directly from the PS, you need to first open SDK and run a "hello world" program in there to start up the PS resources, and just then you can program the PL and have the debug cores work.
Finally, could you do a basic test and route that same clock straight to an output LED and verify it it's blinking? That will confirm to us that the clock is actually being routed within the FPGA.
09-18-2019 10:31 AM - edited 09-18-2019 10:41 AM
The MMCM is instantiated in an IP block that is not directly driven by the PS (no AXI, no nets going directly to the PS).
This block is clocked at 50 MHz by a Clocking Wizard block that itself is clocked by a fabric clock running at 100 MHz.
Within the IP where the MMCM is, there are 1/7x, 4/7x, and 1x clocks as described by XAPP1315. The block is basically a 7:1 gearbox for video signals (7:4 rtl gearbox to 4:1 OSERDESE3 final stage).
I was able to use ILA in a similar design, but when I stripped this block out to debug it on its own, I never got dbg_hub to work.
09-18-2019 09:20 PM
It's a root cause.
"debugging module" requires stable clock as clock source.
In this case, you use clock source from MMCM.
So, I suggest you to change clock source to stable clock, ex. oscillator.
07-28-2020 01:51 PM
This thread is a bit old at this point, but I am having a very similar issue with an Zynq Ultrascale platform. I have tried everything to get the ILA to work. I get it to work on occasion (some time I build the project and it works, but most of the time it does not). The failure is taht teh debug core is not detected. I have tried different clocks. Optimally, I will use the clock generated from an external 350Mhz LVDS clock that feeds an MMCM. I am using a 50Mhz clock that is generated by the MMCM as teh debug clock. I have a counter using this clock that blinks an LED. I can connect just the counter register to the ILA and it works fine. But when I connect the ISERDESE3 output to the ILA, I get problems. There is something related to the ISERDESE3 block that causes this issue. I have also tried using IBUFDS_DIV blocks instead of the MMCM with the same results. Additionally, I have tried using a 50Mhz clock directly from the PS, and still have this issue. I have other designs using almost the identical logic but running at 400Mhz input and do not have this problem. I am curious if the original poster ever found a solution
07-28-2020 02:04 PM
My memory is a bit foggy at this point, but the ultimate problem with ILA and SERDES blocks ended up being that the ISERDESE3, being a hard silicon block inside the US+ (like all the other hard silicon blocks), is physically placed near the edge of die for speed and short routing, rendering it physically inaccessible to the the ILA probes that are routed internally. There is literally no way to use ILA to probe certain hard silicon block outputs.
The only way I could end up using ILA to debug SERDES-related behavior was by placing the probes at the input or even farther upstream. This meant I had to know what the upstream/pre-gearbox input was supposed to look like, which in my application was relatively easy.
Hopefully you get it sorted.
07-28-2020 02:30 PM
@joelschad is correct!
This is the expected behavior and the issues stems from the fact that the ODDRE/OSERDES/ISERDES is placed in the IOB pad, where the ILA is physically not capable of reaching.
[Route 35-54] Net: mynet/Net is not completely routed.
07-28-2020 03:05 PM
I am not attempting to probe the inputs to the ISERDES. the serilization is 1:14, so I have the 8:56 gearbox and bitshift logice feeding off the 8bit ISERDES. I can actually usually connect to the 8bit output of the ISERDES block, but I have only been able to get that to work for a couple channels. When I add more, The debug core cannot be found. When I probe the 14bit output of the gearbox, almost always the debug core cannot be found. The issue is somewhat intermittent, but a given bitstream that works, will always work, and one that fails will always fail. It has something to do with the logic or the placement of of the logic. When I feed the deserialized logic into the PS (fifo-DMA) I can read expected data, so the logic is working. When I add additional channels, I get failures on various channels. This is what I need to debug, but cannot reliably get a debug core to function.
Thank you for your comments so far.
07-28-2020 03:40 PM
07-28-2020 04:49 PM
I have stripped down the design to just a couple data channels, the sync channel, and the clock channel. I removed all other logic from the design and it does pass timing. I have also used a low jitter clock source to directly feed the clock to verify there is a clean free running clock at all times. Originally, I had all 16 channels from the ADC running and I could probe them most of the time. but had unexplained invalid data on some of the data channels. Depending on how many channels I would add, I would get unusual data corruption on different channels. I cannot use the high speed SelectIO wizard since I am stuck with the pins used on the FMC connector and the wizard using the bitslices is very restrictive on what pins can be used. I don't know ifthis is an indicator that my pin usage is ultimately problematic. I have a similar project using teh same platform and an 8 channel ADC. almost identical logic. I do not have these problems. So even if I do get this ILA issue figured out, then there is the issue of the unusual(periodic bit flipping not shifting) deserilized data on some channels.
07-29-2020 06:16 PM
I think I have figured out a workaround, though I have not figured out the root cause short of a software issue. If I feed the signals back into the block design( I feed them into a fifo) then debug the signals from the block design using an ILA block, the ILA works. These are the exact same signals that I put a (* mark_debug = "TRUE" *) on and used the "set up debug" gui under the synthesis section.