set_data_delay (::quartus::sdc_ext)

The following table displays information for the set_data_delay Tcl command:

Tcl Package and Version

Belongs to ::quartus::sdc_ext 1.0

Syntax set_data_delay [-h | -help] [-long_help] [-add_latch_clock] [-add_launch_clock] [-allow_destination_borrowing] [-fall_from <names> ] [-fall_to <names> ] [-from <names> ] [-get_value_from_clock_period <src_clock_period|dst_clock_period|min_clock_period|max_clock_period> ] [-override] [-rise_from <names> ] [-rise_to <names> ] [-through <names> ] [-to <names> ] [-value_multiplier <multiplier> ] [ <value> ]
Arguments -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
-override Make this constraint override non-datapath-only constraints, instead of applying it in addition to them
-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
Description
Specifies a maximum datapath delay exception for a given path.
NOTE: This constraint should only be used for clock domain crossing paths.
See the end of this help section for more information.

The maximum delay analysis includes Tco of the launching register,
and Tsu of the latching register.  By default, it does not include
clock arrival times at the launching or latching register. To include
launch clock arrival times, use the -allow_launch_clock option. To
include latch clock arrival times, use the -allow_latch_clock option.
If the path starts or ends at a port, the analysis does not
include delays due to set_input_delay or set_output_delay.

Use -get_value_from_clock_period to set the delay requirement
for each path to be equal to the launching or latching clock period,
or whichever of the two has a smaller or larger period.
If -value_multiplier is used, the requirement will be multiplied by
that value.  If there are no clocks clocking the endpoints
of the path (e.g. if the path begins or ends at an unconstrained I/O),
the constraint will be ignored.

The datapath delay constraint is applied in addition to other constraints on
the given path, including the default constraint. Furthermore, the datapath delay 
constraint is analyzed independently from other SDC constraints, including 
set_false_path and set_clock_groups, and cannot be overridden by other SDC constraints. 
For example, you can use set_data_delay to specify an upper limit on logic and routing 
delay for paths cut by set_false_path.

The -from and -to values are collections of clocks, registers, ports,
pins, or cells in the design.

Applying exceptions between clocks applies the exception from all
register or ports driven by the -from clock to all registers or ports
driven by the -to clock. 

If pin names or collections are used, the -from value must be a clock
pin and the -to value must be any non-clock input pin to a register.
Assignments from clock pins or to and from cells applies to all
registers in the cell or driven by the clock pin.

The -through values are collections of pins or nets in the design.  An
exception applied through a node in the design applies only to paths
through the specified node.
the Timing Analyzer allows you to specify the -through argument multiple times to
describe paths that go through multiple points. 
For instance, users can select all paths that go through node X, and then go through node Y. 
This helps you narrow down and select the specific paths that you are interested in.

The -rise_from and -fall_from options can be used in place of the
-from destination nodes.  The rise or fall value of the option
indicates that the "from" nodes are driven by the rising or falling
edge of the clock that feeds this node taking into consideration any
logical inversions along the clock path.  The "-from" option is the
combination of both rising and falling "from" nodes.  If the "from"
collection is a clock collection, the assignment applies to those
nodes that are driven by the respective rising or falling clock edge.

The -rise_to and -fall_to options behave similarly to the "from"
options described previously.  These assignments restrict the given
assignment to only those nodes or clocks that correspond to the
specified rise or fall value taking into consideration any logical
inversions that are along the clock path.

The values of the -from, -to, -through, and other similar options are
either collections or a Tcl list of wildcards used to create
collections of appropriate types. The values used must follow standard
Tcl or Timing Analyzer-extension substitution rules. See help for the
use_timing_analyzer_style_escaping command for details.

If the source of a path with a set_data_delay constraint has any time
borrowed, the delay budget will be reduced by the time borrowed.

By default, the delay budget will not be increased by time borrowed at the
destination of a path constrained by a set_data_delay constraint, and
negative slack on a set_data_delay constraint will not cause time borrowing
to happen. To change this behavior, use the -allow_destination_borrowing
option.

set_data_delay constraints should only be applied on asynchronous clock
domain crossing paths. When applied on an synchronous or intra-clock path,
set_data_delay may cause Fitter optimizations to ignore or mishandle the
effects of clock skew on the path's slack.
Example Usage
# Apply a 10ns max data delay on paths between two unrelated clocks
set_data_delay -from [get_clocks clkA] -to [get_clocks clkB] 10.000

# Apply a 2ns max data delay from an input port to any register
set_data_delay -from [get_ports in[*]] -to [get_registers *] 2.000

# Require net delay to be at most 90% of the period of the clock driving the inst9 register
set_data_delay -get_value_from_clock_period dst_clock_period -value_multiplier 0.9 -from [get_clocks clk] -to [get_keepers inst9]

# Apply a 2ns max data delay for an input port only to nodes driven by 
# the rising edge of clock CLK
set_data_delay -from [get_ports in[*]] -rise_to [get_clocks CLK] 2.000
Return Value Code Name Code String Return
TCL_OK 0 INFO: Operation successful
TCL_ERROR 1 ERROR: Timing netlist does not exist. Use create_timing_netlist to create a timing netlist.
TCL_ERROR 1 ERROR: The -add_launch_clock option can only be used when the -override option is used as well.
TCL_ERROR 1 ERROR: The option -value_multiplier must be a non-zero floating point number
TCL_ERROR 1 ERROR: The option -value_multiplier may only be used if -get_value_from_clock_period is used