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.
| Section | Command | Comment |
|---|---|---|
| 1 |
set_disable_timing set_case_analysis |
Keep in this order within this section. |
| 2 |
create_clock create_generated_clock set_clock_sense |
Clocks are referred to by other constraints and need to be defined before the constraints that refer to them. Generated clocks can be derived from other generated clocks, so the recommendation is to follow a "define before use" rule. Keep in this order within this section. |
| 3 |
set_clock_latency set_propagated_clock set_clock_uncertainty set_input_jitter set_system_jitter |
These constraints can trigger additional constraint loading runtime, so they should be kept together to minimize any additional runtime. The order is not important within this section. |
| 4 |
set_input_delay set_output_delay |
Section about I/O delays. These constraints should be defined before the timing exceptions, but the impact on the constraints loading runtime is minimal. The order is not important within this section. |
| 5 |
set_clock_groups set_false_path set_min_delay set_max_delay set_multicycle_path set_bus_skew |
Section about timing exceptions. The order is not important within this section. |
| 6 |
set_max_time_borrow set_external_delay |
These constraints do not have a significant
impact on the constraint loading runtime. The order is not important within this section. |
If the timing constraints follow the above order, a single timing update should be triggered, which means a minimum runtime impact. Some commands like all_fanin/all_fanout can have a high intrinsic runtime, which is expected, and those commands should be avoided:
- all_fanin
- all_fanout
- all_clocks
- all_registers
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>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]]