Not much change in constraints ... Leads to Thousands of violations

Mar 19th, 2020   |   Pradeep , CR

How often have you come across the scenario where your block or full chip timing is clean or close to clean and then you get constraint drop from constraints owner saying, “not much change in the constraints”? To your surprise after using the new constraints you see thousands of timing violations.

Constraints specially at full chip level heavily use the wildcard [*]. As we mentioned in earlier blog it should be used very wisely. Many a times constraints developer uses variables to store the object collection and those variables are passed to the SDC commands. Please find below example usage.

Design is almost timing clean with Constraints_V1.tcl and after couple of days you get a new constraints file Constraints_V2.tcl. Your journey starts from not much change to thousands of violations.

# Constraints_V1.tcl

set_false_path -through $STATIC_PINS 

set_multicycle_path $CYCLE -setup -through $PWR_PINS

This collection comes from different file:

set STATIC_PINS [get_pins -hier * -filter “full_name=~*static_inst*”

Similarly, variable $CYCLE:

set CYCLE 4

# Constraints_V2.tcl

set_false_path -through $STATIC_PINS 

set_multicycle_path $CYCLE -setup -through $PWR_PINS

This collection comes from different file:

set STATIC_PINS [get_pins -hier * -filter “full_name=~*static_inst1*”

Similarly, variable $CYCLE:

set CYCLE 2

# Twist in the story

At the full chip level, the size of the $STATIC_PINS may be ~50K pins.

Full chip STA owner will see timing getting close to clean using these exceptions.  After couple of days he gets a new constraint drop from constraints owner with comment “Minor change in the constraints”. Full chip STA owner will see this comment and before he applies the constraints, he will do some diff of the two files.

In this case file diff of Constraints_V1.tcl and Constraints_V2.tcl does not show any difference because in both files same variable used. But if you look carefully variable $STATIC_PINS set in another file the pattern of instance name is different.  Similarly, for $CYCLE variable also. If you look at cycle got tightened from 4 to 2.

Nested TCL files are very common. This adds more complexity to manual debug.

STA owner will apply new constraints and he will be surprised to see thousands of paths getting violated. He will try to do following to debug the difference.

1.     Load both V1 and V2 STA session and report the violated path to see why it is not reported in V1

2.     He will try to match the object list of $STATIC_PINS in both session

3.     Compare the file and check $STATIC_PINS variable source  

4.     Similarly, he will trace $CYCLE and try to find difference

Let’s say difference comes from disable timing or clock sense and you are debugging this on a full chip. It’s makes things even worse.

Designer was able to root cause the difference but at what cost? 

1.     Lots of his bandwidth was consumed on this debug [several days of effort if you are working on fullchip design with thousands of objects involved w.r.t constraints]

2.     If the changes are more than one mode, more resource will be involved

3.     If the change is fatal [ECO can’t accommodate], it will put schedule at risk [Such things need to be caught quickly and communicate to constraints owner]

# Solution from Ausdia

Thanks to Timevision graph-based constraints compare feature wherein tool compares all the constraints between two SDC or constraints version. Upfront it will provide the root case and details. It will also provide the finer details of the SDC or TCL file which is causing this change.

Following rules will help designer to get the details on exception removed on specific object or MCP cycle tightened. This will enable designer to discuss with constraints owner quickly and understand reason for this change.  We have 100+ dedicated rules to catch all the constraints related changes.

CHG-FP-002   Fatal   A FP exception was removed (timing tightened)                                                           

CHG-MCP-004  Fatal   An MCP exception was tightened (multiplier got smaller)   

Someone rightly said: “Change is Constant” ... Continued saying “Embrace the Change”. 

Just a small change in this quote “Embrace the change easily with help of Timevision and Avoid schedule risk” 😊

For more details on Timevision platform please visit www.ausdia.com