Quartus® Prime Pro Edition User Guide: Timing Analyzer

ID 683243
Date 11/26/2024
Public
Document Table of Contents

2.4.4.6. Creating Efficient Timing Exceptions

When you create efficient timing constraints, the Timing Analyzer takes less time to process the constraints, resulting in shorter compile times. Refer to the following tips to creating efficient timing constraints.

Avoid -from * or -to * in path-based constraints. If you do not specify -from or -to, the Timing Analyzer assumes all fan-ins or all fan-outs.

Consider an example where you want to cut all paths to the input of a sync_reg synchronizer. The most efficient way is to specify the following:

set_false_path -to [get_registers sync_reg]

Because the -from option is not specified, the Timing Analyzer applies the false path to all paths that fan-in to the register. If you specify the following, the Timing Analyzer gets all registers in the design and checks whether a path exists between each register and sync_reg, incurring unnecessary processing time

set_false_path -from [get_registers *] -to [get_registers sync_reg]

Combine multiple constraint targets as a list argument to a collection filter. All collection commands, such as get_registers, support a list of names or wildcards. Instead of creating a separate constraint for each name or wildcard, create fewer constraints by grouping multiple names or wildcards in a list.

Consider an example of a bus synchronizer with a data[*] data bus and a data_valid data valid signal. If you want to constrain the data delay from both of those elements, you could write two separate data delay constraints:

set_data_delay -from [get_registers data[*]] 5
set_data_delay -from [get_registers data_valid] 5

However, it is more efficient to combine both signals as a single list argument:

set_data_delay -from [get_registers { data[*] data_valid }] 5

For small quantities of wildcards or affected names in a design, using separate or combined constraints does not significantly affect the speed at which the constraints are processed. However, if separate filters match hundreds or thousands of names, this requires additional time to combine names.

When you consider whether to specify combined constraint targets, the correctness of the constraints should always be your first priority. When you specify multiple names or wildcards, the constraint applies to all paths between permutations of the names. For example, if the following paths exist in your design (registers reg_a and reg_b drive both reg_c and reg_d).

reg_a -> reg_c
reg_a -> reg_d
reg_b -> reg_c
reg_b -> reg_d

Then the following sets of constraints have different functionality:

Example 1

set_multicycle_path -from [get_registers reg_a] -to [get_registers reg_c]
set_multicycle_path -from [get_registers reg_b] -to [get_registers reg_d]

The two constraints in Example 1 affect only two paths:

  • reg_a -> reg_c
  • reg_b -> reg_d

Example 2

set_multicycle_path -from [get_registers { reg_a reg_b }] -to [get_registers { reg_c reg_d }]

The one constraint in Example 2 affects four paths:

  • reg_a -> reg_c
  • reg_a -> reg_d
  • reg_b -> reg_c
  • reg_b -> reg_d