Quartus® Prime Pro Edition User Guide: Timing Analyzer

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

2.4.3.4. Data Delay (set_data_delay)

The Set Data Delay (set_data_delay) constraint specifies a maximum datapath delay exception for the path you specify.

The maximum delay analysis includes tCO of the launching register, and tSU of the latching register. By default, the maximum delay analysis does not include the clock arrival times at the launching or latching register.

Note: Exclusive clock groups (set with set_clock_groups -exclusive) override set_data_delay constraints. Unlike paths between asynchronous clocks, paths between exclusive clocks are entirely inactive, and therefore are not suitable for timing requirement analysis. False paths do not override set_data_delay constraints.
Table 22.  set_data_delay Options
Arguments Description
-h | -help Short help.
-long_help Long help with examples and possible return values.
-add_latch_clock Include the latch clock path in timing analysis.
-add_launch_clock Include the launch clock path in timing analysis.
-allow_destination_borrowing Allow time borrowing at the destination.
-fall_from <names> Valid source clocks (string patterns are matched using Tcl string matching).
-fall_to <names> Valid destination clocks (string patterns are matched using Tcl string matching).
-from <names> Valid sources (string patterns are matched using Tcl string matching).
-get_value_from_clock_period <src_clock_period|dst_clock_period| min_clock_period|max_clock_period> Compute constraint as a multiple of the clock period.
-no_synchronizer Prevent this data delay from triggering a synchronizer.
-rise_from <names> Valid source clocks (string patterns are matched using Tcl string matching).
-rise_to <names> Valid destination clocks (string patterns are matched using Tcl string matching).
-through <names> Valid through nodes (string patterns are matched using Tcl string matching).
-to <names> Valid destinations (string patterns are matched using Tcl string matching).
-value_multiplier <multiplier> Value by which the clock period should be multiplied to compute requirement.
<value> Time value.

A common use for the set_data_delay constraint is to specify an upper bound on the allowable delay on a false path in a cross-domain transfer. When you specify set_false_path path, the Fitter does not have to meet a timing requirement on that path. Consequently, the Fitter is free to place the endpoints of the path very far apart, and to route the path in a convoluted way. Although a convoluted route does not often occur, a false path allows the Fitter to make that selection. When you use set_false_path to cut asynchronous transfers, you often want to keep the path delay down to reduce system latency. A set_data_delay constraint is one way to specify an upper bound for the path delay.

The set_net_delay constraint is also appropriate in many of the same situations. You can use set_net_delay to set an upper bound for a path that you specify as false. The set_data_delay and set_net_delay constraints differ in their behavior when there is combinational logic on the path:

  • A register-to-register set_data_delay constraint applies to the path regardless of whether it has combinational logic.
  • A register-to-register set_net_delay constraint does not apply if there is combinational logic on the path.

Generally, you should not use combinational logic on paths that transfer data between clock domains. Therefore, set_data_delay and set_net_delay constraints are both appropriate. However, when there is logic on paths between clock domains, use the set_data_delay constraint to constrain the paths.