ID 683230
Date 11/12/2018
Public

## 3.4.3.5. Tips for Creating a .tcl Script to Monitor Critical Paths Across Compiles

Many designs have the same critical paths show up after each compile. In other designs, critical paths bounce around between different hierarchies, changing with each compile.

This behavior happens in high speed designs where many register-to-register paths have very little slack. Different placements can then result in timing failures in the marginal paths.

1. In the project directory, create a script named TQ_critical_paths.tcl.
2. After compilation, review the critical paths and then write a generic report_timing command to capture those paths.
For example, if several paths fail in a low-level hierarchy, add a command such as:
report_timing –setup –npaths 50 –detail path_only \
–to “main_system: main_system_inst|app_cpu:cpu|*” \
–panel_name “Critical Paths||s: * -> app_cpu”
3. If there is a specific path, such as a bit of a state-machine going to other *count_sync* registers, you can add a command similar to:
report_timing –setup –npaths 50 –detail path_only \
–from “main_system: main_system_inst|egress_count_sm:egress_inst|update” \
–to “*count_sync*” –panel_name “Critical Paths||s: egress_sm|update -> count_sync”
4. Execute this script in the Timing Analyzer after every compilation, and add new report_timing commands as new critical paths appear.
This helps you monitor paths that consistently fail and paths that are only marginal, so you can prioritize effectively