When loading the timing constraints in memory, the timing engine validates each new constraint and prints messages to flag potential problems. Some timing constraints partially invalidate the timing database (also referred as timing graph) and some other timing constraints require an up-to-date timing database to be properly applied. Once the timing database is out of date, subsequent timing updates are needed, for instance, to update auto-derivation clocks or to disable certain timing paths in the design. The XDC commands which query the clocks or which traverse the design to query netlist objects require an up-to-date timing database.
Interleaving constraints and commands that impact the timing database state can be runtime intensive as the timing information gets invalidated and updated multiple times.
For runtime optimization, AMD recommends that you order the timing constraints and queries carefully. The table below lists the XDC constraints and commands that have an impact on the timing graph.
| Constraints with Impact on Timing Graph | Constraints with No Impact on Timing Graph | Constraints which Require Up-to-Date Timing Graph |
|---|---|---|
| create_clock | set_bus_skew | all_fanout |
| create_generated_clock | set_clock_groups | all_fanin |
| set_case_analysis | set_clock_latency | get_clocks |
| set_clock_sense | set_false_path | get_generated_clocks |
| set_clock_uncertainty | set_input_delay | all_clocks |
| set_disable_timing | set_output_delay | Any constraint with the –clock option |
| set_external_delay | set_min_delay | |
| set_propagated_clock | set_max_delay | |
| set_max_time_borrow | ||
| set_multicycle_path | ||
| set_system_jitter |
One of the most runtime intensive combinations is set_disable_timing with all_fanout or all_fanin. Such
combinations should be avoided. For example:
set_disable_timing –from <pin> -to [all_fanout …] set_disable_timing –from [all_fanin …] -to <pin>Based on the table above, the optimal constraints order for runtime optimization is:
- XDC constraints
set_disable_timing,set_case_analysis, andset_external_delay. - Constraints that have an impact on the timing graph.
- Constraints that do not require timing graph updates.
For example, the following sequence of constraints is not optimal.
create_clock –name clk1
create_generated_clock –name genclk1 –master_clock [get_clocks -of [get_pins ...]] set_disable_timing ...
create_clock –name clk2
set_false_path -from [get_clocks -of [get_pins ff1/C]] set_case_analysis ...
create_clock –name clk3
set_max_delay -to [get_clocks -of [get_pins ff2/C]]
The following shows a more optimal and runtime efficient sequence.
set_disable_timing ...
set_case_analysis ...
create_clock –name clk1 create_clock –name clk2
create_clock –name clk3
create_generated_clock –name genclk1 –master_clock [get_clocks -of [get_pins ...]]
set_false_path -from [get_clocks -of [get_pins ff1/C]]
set_max_delay -to [get_clocks -of [get_pins ff2/C]]