cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
1,007 Views
Registered: ‎08-22-2018

Inconsistency of Hold Violation

Jump to solution

Hi,

 

I Use ZYNQ Ultra Scale+ xczu9eg-ffvb1156-2-e to generate bitstream successfully.

But I have Hold time violation which is inconsistent, once runs without timing violation and second time re running gives hold violation.

 

Can anybody give solution or explain why this inconsistency in Hold time violation. Thanks in advance.

Below is the hold violation path

holdtiming.png
0 Kudos
Reply
1 Solution

Accepted Solutions
Contributor
Contributor
1,022 Views
Registered: ‎09-14-2017

It seems that your clock is routed in normal fabric and not in clock network, that can cause quite big skew between the source and destination clocks and different results on each run (in this case ~430ps). You could try forcing the clock to global network:

 

set_property CLOCK_BUFFER_TYPE BUFG [get_nets design_1_i/jtag_axi/inst/u_jtag/tck]

 

You should see in the source and destination clocks routing where there is fo=1 net to BUFG and then fo=<big> net starting from the buffer.

 

--Kim

 

 

View solution in original post

2 Replies
Moderator
Moderator
995 Views
Registered: ‎11-04-2010

Hi, @snehaaadi ,

For the repeatability issue, please refer to the bleow discussion:

https://www.xilinx.com/support/answers/61599.html

 

1.  Confirm your environment is supported.

2.  You need to confirm where the divergence occurs.

3.  Can single thread resolve your problem?

4.  If you can reproduce the issue in 2018.2, you can consider upload your desing to me for further analysis.  

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Contributor
Contributor
1,023 Views
Registered: ‎09-14-2017

It seems that your clock is routed in normal fabric and not in clock network, that can cause quite big skew between the source and destination clocks and different results on each run (in this case ~430ps). You could try forcing the clock to global network:

 

set_property CLOCK_BUFFER_TYPE BUFG [get_nets design_1_i/jtag_axi/inst/u_jtag/tck]

 

You should see in the source and destination clocks routing where there is fo=1 net to BUFG and then fo=<big> net starting from the buffer.

 

--Kim

 

 

View solution in original post