Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎01-03-2019

Inferred dbg_hub TCK vs ILA clock hold / setup time violation


Hoping Xilinx community can help me with the following issue.

Tool version -> Vivado 2018.2 (GUI)

OS version -> Ubuntu 18.04

FPGA -> Ultrascale+ Architecture


Trying to debug couple of signals internal to RM in Partial Reconfiguration design.

Took quite sometime to be able to instantiate ILA modules inside PR region.

I had to

1) Instantiate ILA module inside PR

2) Instantiate Debug Bridge inside PR (pretty confusing what is written inside UG909 regarding this). I got to know about this due to Vivado tool being stopped during Optimization phase with an error and suggesting to instantiate Debug Bridge.

3) Connect Debug Bridge signals to the PR boundary:

  debug_bridge_0 u_debug_bridge(
    .clk                (PR_local_clk),
    .S_BSCAN_bscanid_en (S_BSCAN_bscanid_en),
    .S_BSCAN_capture    (S_BSCAN_capture),
    .S_BSCAN_drck       (S_BSCAN_drck),
    .S_BSCAN_reset      (S_BSCAN_reset),
    .S_BSCAN_runtest    (S_BSCAN_runtest),
    .S_BSCAN_sel        (S_BSCAN_sel),
    .S_BSCAN_shift      (S_BSCAN_shift),
    .S_BSCAN_tck        (S_BSCAN_tck),
    .S_BSCAN_tdi        (S_BSCAN_tdi),
    .S_BSCAN_tdo        (S_BSCAN_tdo),
    .S_BSCAN_tms        (S_BSCAN_tms),
    .S_BSCAN_update     (S_BSCAN_update)

After the above mentioned stages my very first configuration went successfully through Implementation phase and I was able to see and debug ILA connected PR internal signals.


Now the issue comes to light when I try to Implement second configuration, which is the child of the first implementation.

The tool for whatever reason claims huge Hold / Setup time violations between TCK clock (dbg_hub) and PR_local_Clk, which drives ILA and Debug Bridge.


It is pretty obvious that TCK is the JTAG slow clock used by Logic Analyser System to sequentially move captured data from ILA modules. However, as dbg_hub gets inferred only at Optimization phase I kind of out of way to create "set_clock_groups -asynchronous  -group" constraint on TCK vs PR_local_Clk to make sure this stupid Hold time violations don't show up.


To be honest this is the first time I see such violation.

Would never face such problem, when ILA modules are instantiated in static region. I assume tool is able to apply all those timing constraints automatically.


The only option I see is to source a TCL script post Optimization to apply timing constraint, as currently my timing constraints are applied after Synthesis but before Optimization phase.


Hoping there is a better way to solve the problem.



0 Kudos
0 Replies