cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
1,438 Views
Registered: ‎05-18-2018

Ultrascale+ debug cores not detected

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 created my design and am driving my ILA and dbg_hub cores with (apparently) 50 MHz free-running clocks, though I'm not sure how to confirm signal integrity.

 

ila_attached.png

  • My dbg_hub C_USER_SCAN_CHAIN is 1:scan chain 1.png
  • My JTAG PARAM.FREQUENCY is 5000000 (5 MHz):jtag_settings.png

     

     

     

I have tried following other "Solved" threads on this forum, but nothing seems to work so far. Any advice?

 

0 Kudos
15 Replies
Highlighted
Teacher
Teacher
1,434 Views
Registered: ‎07-09-2009

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

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Adventurer
Adventurer
1,416 Views
Registered: ‎05-18-2018

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?

0 Kudos
Highlighted
Teacher
Teacher
1,384 Views
Registered: ‎07-09-2009

sorry
may be some one else can pick up
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Teacher
Teacher
1,366 Views
Registered: ‎06-16-2013

Hi @joelschad 

 

Do you use suitable clock source for debug core ?

It seems root cause.

If you use clock source from ex. PLL, debug core can't work well.

Make sure clock source.

 

Best regards,

0 Kudos
Highlighted
Adventurer
Adventurer
1,344 Views
Registered: ‎05-18-2018

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.

Tags (1)
0 Kudos
Highlighted
Moderator
Moderator
1,335 Views
Registered: ‎02-09-2017

Hi @joelschad,

 

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.

Thanks,

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
1,332 Views
Registered: ‎05-18-2018

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.

Tags (3)
0 Kudos
Highlighted
Teacher
Teacher
1,313 Views
Registered: ‎06-16-2013

Hi @joelschad 

 

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.

 

Best regards,

0 Kudos
Highlighted
Visitor
Visitor
739 Views
Registered: ‎03-13-2020

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

0 Kudos
Highlighted
Adventurer
Adventurer
731 Views
Registered: ‎05-18-2018

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.

Highlighted
Moderator
Moderator
716 Views
Registered: ‎02-09-2017

Hi @scot0132,

 

@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.

Unfortunately, it's not possible to directly probe the input/output of such blocks with an ILA.
 
Please verify your implementation. If you are trying to connect the ISERDES to the ILA, you are probably seeing an error such as:
 
[Route 35-54] Net: mynet/Net is not completely routed.
In such cases, it's recommended to connect the ILA inside the PL logic, before the ODDRE/OSERDES, or after the ISERDES.  You can also use a physical external scope for probing such pins.
 
Thank you,
Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
708 Views
Registered: ‎03-13-2020

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.

0 Kudos
Highlighted
Teacher
Teacher
695 Views
Registered: ‎07-09-2009

quick question, as this falls over as the design gets bigger,
have you constrained and does the design pass timing constraints ?
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Visitor
Visitor
675 Views
Registered: ‎03-13-2020

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. 

0 Kudos
Highlighted
Visitor
Visitor
559 Views
Registered: ‎03-13-2020

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. 

0 Kudos