set_clock_uncertainty (::quartus::sdc)
The following table displays information for the set_clock_uncertainty Tcl command:
Tcl Package and Version |
Belongs to ::quartus::sdc 1.5 |
|||
Syntax |
set_clock_uncertainty [-h | -help] [-long_help]
[-add]
[-enable_same_physical_edge]
[-fall_from
<fall_from_clock>
]
[-fall_to
<fall_to_clock>
]
[-from
<from_clock>
]
[-hold]
[-rise_from
<rise_from_clock>
]
[-rise_to
<rise_to_clock>
]
[-setup]
[-to
<to_clock>
]
<uncertainty> |
|||
Arguments | -h | -help | Short help | ||
-long_help | Long help with examples and possible return values | |||
-add | Specifies that this assignment is an addition to the clock uncertainty derived by derive_clock_uncertainty call | |||
-enable_same_physical_edge | Enable setting uncertainty value for same physical clock edge | |||
-fall_from <fall_from_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
-fall_to <fall_to_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
-from <from_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
-hold | Only apply the uncertainty value to hold and removal checks | |||
-rise_from <rise_from_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
-rise_to <rise_to_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
-setup | Only apply the uncertainty value to setup and recovery checks | |||
-to <to_clock> | Valid destinations (string patterns are matched using Tcl string matching) | |||
<uncertainty> | Uncertainty | |||
Description |
Specifies clock uncertainty or skew for clocks or clock-to-clock transfers. You can specify uncertainty separately for setup and hold, and you can specify separate rising and falling clock transitions. If you omit specifying -setup or -hold the uncertainty value will be applied to both analysis types. Similarly, if you omit specifying rising or falling clock transitions the uncertainty value will be applied to both transitions. The setup uncertainty is subtracted from the data required time for each applicable path, and the hold uncertainty is added to the data required time for each applicable path. When you use the -add option, the clock uncertainty assignment is treated as an addition to the value calculted by the derive_clock_uncertainty command for a particular clock transfer, overriding previous uncertainty assigments made with or without the -add option. Note that when you do not use the -add option but still call derive_clock_uncertainty, clock uncertainty assignments you create take priority. When you do not use the derive_clock_uncertainty command, using the set_clock_uncertainty command with -add option has the same effect as without the -add option. Note: The Timing Analyzer does not apply clock uncertainty to transfers involving the same physical launch and latch edge (that is, the latch and launch edges are the same edge of a clock source and occur at the same time) by default. Such transfers typically occur in hold analysis, but may also occur in setup analysis with a multicycle value of 0. You can use -enable_same_physical_edge option to override this behavior. The values for the -from, -to, and 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 the help for use_timing_analyzer_style_escaping for details. |
|||
Example Usage |
set_clock_uncertainty -setup -rise_from clk1 -fall_to clk2 200ps |
|||
Return Value | Code Name | Code | String Return | |
TCL_OK | 0 | INFO: Operation successful |