4.1.33.27. set_max_delay (::quartus::sdc)

Intel® Quartus® Prime Pro Edition User Guide: Scripting

Download PDF

ID 683432

Date 6/26/2023

Version

Public

A newer version of this document is available. Customers should click here to go to the newest version.

Visible to Intel only — GUID: reference_TCL_tcl_pkg_sdc_ver_1_5_cmd_set_max_delay

Ixiasoft

View Details

4.1.33.27. set_max_delay (::quartus::sdc)

The following table displays information for the set_max_delay Tcl command:

Tcl Package and Version	Belongs to ::quartus::sdc
Syntax	`set_max_delay [-h \| -help] [-long_help]` `[-fall_from` <names> `]` `[-fall_to` <names> `]` `[-from` <names> `]` `[-no_synchronizer]` `[-rise_from` <names> `]` `[-rise_to` <names> `]` `[-through` <names> `]` `[-to` <names> `]` <value>
Arguments	`-h \| -help`		Short help
	`-long_help`		Long help with examples and possible return values
	`-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)
	`-no_synchronizer`		Prevent this max 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>		Time Value
Description	Specifies a maximum delay exception for a given path. The maximum delay is similar to changing the setup relationship (latching clock edge - launching clock edge), except that it can be applied to input or output ports without input or output delays assigned to them. Maximum delays are always relative to any clock network delays (if the source or destination is a register) or any input or output delays (if the source or destination is a port). Therefore, input delays and clock latencies are added to the data arrival times. Clock latencies also added to data required times and output delays are subtracted from data required times. The -from and -to values are collections of clocks, registers, ports, pins, or cells in the design. If the -from or -to values are not specified, the collection is converted automatically into [get_keepers *]. It is worth noting that if the counterpart to the unspecified collection is a clock collection, it is more efficient to explicitly specify this collection as a clock collection but only if the clock collection also generates the desired assignment. 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. Applying exceptions between a pair of clocks is more efficient than for specific node to node or node to clock paths. 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 "from1" 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.
Example Usage	# Apply a 10ns max delay between two unrelated clocks set_max_delay -from [get_clocks clkA] -to [get_clocks clkB] 10.000 # Apply a 2ns max delay for an input port (TSU) set_max_delay -from [get_ports in[]] -to [get_registers ] 2.000 # Apply a 2ns max delay for an output port (TCO) set_max_delay -from [get_registers ] -to [get_ports out[]] 2.000 # Apply a 2ns max delay for an input port to an output port (TPD) set_max_delay -from [get_ports in[]] -to [get_ports out[]] 2.000 # Apply a 2ns max delay for an input port only to nodes driven by # the rising edge of clock CLK set_max_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

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Intel® Quartus® Prime Pro Edition User Guide: Scripting

4.1.33.27. set_max_delay (::quartus::sdc)