set_data_delay (::quartus::sdc_ext)

Belongs to ::quartus::sdc_ext 1.0

Specifies a maximum datapath delay exception for a given path.

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 -add_launch_clock option. To
include latch clock arrival times, use the -add_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 (such as 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.

To both cut a path for (clock-aware) timing and constrain its datapath delay, the path
must be constrained with both set_false_path and set_data_delay.

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.

# 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