cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Anonymous
Not applicable
7,603 Views

ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution

Hello community,

 

with some designs, I notice the following pattern while in PAR of ISE 13.2 (Spartan 6 45T, Speed Grade -2 Target):

Phase  1  : 25811 unrouted;      REAL time: 11 secs 
Phase  2  : 21854 unrouted;      REAL time: 14 secs 
Phase  3  : 8435 unrouted;      REAL time: 27 secs 
Phase  4  : 8437 unrouted; (Setup:0, Hold:40098, Component Switching Limit:0)     REAL time: 29 secs 
Updating file: TEST.ncd with current fully routed design.
Phase  5  : 0 unrouted; (Setup:0, Hold:39773, Component Switching Limit:0)     REAL time: 38 secs 
Phase  6  : 0 unrouted; (Setup:0, Hold:39773, Component Switching Limit:0)     REAL time: 38 secs 
Phase  7  : 0 unrouted; (Setup:0, Hold:39773, Component Switching Limit:0)     REAL time: 38 secs 
Phase  8  : 0 unrouted; (Setup:0, Hold:39773, Component Switching Limit:0)     REAL time: 38 secs 
Phase  9  : 0 unrouted; (Setup:0, Hold:0, Component Switching Limit:0)     REAL time: 47 secs 
Phase 10  : 0 unrouted; (Setup:0, Hold:0, Component Switching Limit:0)     REAL time: 49 secs 
Total REAL time to Router completion: 49 secs 
Total CPU time to Router completion (all processors): 1 mins 2 secs 

 As one can see, there are quite severe hold violations in intermediate PAR phases, but in the end, they completely disappear.

 

Some more info on the design, it's using several clock domains (125 MHz x2, 100 MHz) which are isolated using dual-clock FIFOs and dual-rank synchronizers applying the HBLKNM constraint to enforce co-placement of the FFs, also applying relaxing timing constraints on the clock domain crossings. Also, GTPs are used with east-to-west clock forwarding and using GTPCLKOUT(0) in the design via BUFIO2/BUFG (PERIOD constraint applied). Apart from this, none of the I/Os use any (source/system synchronous) clocking, they just have catch-all OFFSET IN, OFFSET OUT constraints applied.

 

Out of curiosity (and bit out of worrying), I have some questions on this phenomenon:

 - What do these intermediate HOLD violations mean? Do they point out bad routing which is fixed in a later phase?

 - Is it possible to find the design elements causing this? The timing reports are clean since the issues are resolved in the final phases.

 - Is this harmful at all, i.e. is it possible that this intermediate situation will at some point become a real timing violation as routing complexity increases?

 

Regards,

Florian

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
9,740 Views
Registered: ‎07-01-2008

Re: ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution

If you really want to analyze the Hold errors that are being fixed, you can disable the Hold Router with this environment variable and then run trce:

setenv No_Hold_Time_Routing 1

View solution in original post

4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
7,583 Views
Registered: ‎07-01-2008

Re: ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution

The router initially focuses on routing the design completely and reducing the setup score to zero. Then the Hold Router is run to add delay to the data path to fix the hold errors. To do this it needs to be able to find a route with a delay inside the window between setup and hold errors. In ISE it will not introduce a setup violation to fix a hold error. That has changed for Vivado where if the hold router can't find a solution it will pick the setup/hold error with least negative slack. Anyway, for a healthy design such as yours, the hold errors represent data paths that were routed too efficiently and need to be slowed down by the hold router. For an unhealthy design the hold errors will also represent large clock delays and the router would be likely to print warning messages about the unusually large hold errors. There would also probably be warnings at clock placement time about non-optimal clock configurations.

Highlighted
Anonymous
Not applicable
7,560 Views

Re: ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution

Thanks bwade for the clarification.

 

So... nothing to worry about, that's great.

Still, how can I find out what pathes are causing this behaviour?

 

Regards,

Florian

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,741 Views
Registered: ‎07-01-2008

Re: ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution

If you really want to analyze the Hold errors that are being fixed, you can disable the Hold Router with this environment variable and then run trce:

setenv No_Hold_Time_Routing 1

View solution in original post

Highlighted
Anonymous
Not applicable
7,512 Views

Re: ISE PAR: Intermediate hold violations, are they harmful?

Jump to solution
set env(No_Hold_Time_Routing) 1

 After doing this via Tcl console, the violations persisted (20k score, although it was 40k in earlier phases).

 

In analyzing the violations, it showed that almost all of the inter-clock synchronization FFs (the capture stage) as well as some of the GTP dedicated pins had negative HOLD slack due to clock skew/routing/"negative" data delay.

 

Very interesting, thanks again for the hint.

0 Kudos