Extensive Application Notes On Clocks in Primetime

Synopsys Extensive Application Notes
Clocks in PrimeTime - October 1999
Extensive Application Notes
on
Clocks in PrimeTime
October 1999
0
TABLE OF CONTENTS
Topic Page
Introduction ............................................................................2
PrimeTime Commands & Variables Related to Clocks: ...........3
List of All Clock Commands with Examples: ........................3
List of Environment Variables Related to Clocks ................10
Clock Commands in Action ...................................................13
set_clock_latency on a Pin vs. Clock ..................................15
set_clock_uncertainty on Pin vs. Clock ...............................17
Generated Clocks .................................................................18
PLLs (Phase Locked Loop) ...............................................18
Generated Propagated Clocks ............................................25
Multiple Clock Domains ........................................................26
Common Base Period Expansion.........................................26
Tips for Multi-Frequency Analysis: ......................................27
Asynchronous Clock Domains ............................................28
Inter-Clock skew ...............................................................29
Pre/Post Layout Clock Issues ................................................29
Ideal Clocks (Pre-layout) ...................................................29
Propagated Clocks (Clock Trees) ......................................30
SDF back annotated Clock tree .........................................31
Collapsed Tree: ( Ex:Toshiba, TI) .......................................31
Full Tree: (Ex: LSI, Lucent) ................................................31
Overriding Clock Net Delays .............................................31
How to Create a Clock on a Net .......................................32
Clock Issues Related to Min/Max timing ...............................33
Clock Reconvergence Adjustment .....................................33
Tester Skew ......................................................................34
Off-Chip skew modeling ....................................................34
Differences between DC and PT clocking .............................38
How to achieve correlation ................................................38
1
Introduction
This document is an extensive Application Notes that covers many advanced

aspects of clocks in the context of the Synopsys static timing analysis tool
PrimeTime. The information contained in this document was collected from a
variety of sources including:
• PrimeTime User Maunal

• SOLV-IT articles on Clocks in PrimeTime
• Training Manuals
• Field Presentations
This document is not intended as a substitute or replacement for any of the above
sources, but rather as a supplement.
2
PrimeTime Commands & Variables Related to Clocks:
List of All Clock Commands with Examples:

The following section contains a list of pt_shell commands related to clocks.
Each command is listed with a simple example and a timing diagram to illustrate
the concept. How and when to use these commands is explained the the next
section titled “Clock Commands in Action”. For more detail on each command,
please refer to the man page. The commands are listed in rough order of usage
and importance; first the create or set commands then the remove commands.
• create_clock: Creates a basic clock object.

Example: The following example creates a clock on port "PHI1"
with a period of 10.0, a rise at 5.0, and a fall at 9.5.
pt_shell> create_clock "PHI1" -period 10 -waveform { 5.0 9.5 }
0 5 10 15 20
Figure 1 create_clock command
• create_generated_clock: Creates a generated clock object based on a

previously created clock. The previous clock can be another generated clock
itself. Any latency and/or propagation delay defined on the original clock will
be passed on to the generated clock accordingly. Please refer to the section
on generated propagated clocks in the Generated Clocks chapter for further
information.
Note: Generated clocks are not actually created until an update_timing has
been performed either explicitly (update_timing command) or implicitly
(report_timing for example does an update_timing first).
Example: The following example creates a generated clock whose edges

are edges 1, 3, and 5 of the master clock source.
pt_shell> create_generated_clock -edges {1 3 5} -source CLK \

[get_pins DIV_2]
3
1 2 3 4 5 6 7
CLK
DIV_2
Figure 2 Create_generated_clock command

• derive_clocks: This command finds the clock source ports and pins that
need to have clocks defined on them, so that every register clock pin has a
clock. Then on each source set, the command creates a clock in the same
way the create_clock command does. All the created clocks will have the
same waveform. Thus, after performing this command, you can time your
design without worring about having unconstrained elements.
Example:
pt_shell> derive_clocks -period 20
• set_clock_uncertainty: Captures actual or predicted clock skew. The

uncertainty can be specified separately for setup, hold, rising or falling.
Example: The following example specifies that all paths leading to
registers or ports clocked by CLK have setup uncertainty of 0.65 and
hold uncertainty of 0.45 for both the rising & falling edges.
pt_shell> set_clock_uncertainty -setup 0.65 [get_clocks CLK]

pt_shell> set_clock_uncertainty -hold 0.45 [get_clocks CLK]
CLK
CLK with
uncertainty
Hold Uncertainty Setup Uncertainty
Figure 3 Specifying clock uncertainty
4
• set_propagated_clock: Specifies propagated clock delay (usually due to

clock tree cell and net delays).
Example: This example specifies to use propagated clock latency (i.e.
delay through all gates and nets in the clock network) for all clocks
in the design .
pt_shell> set_propagated_clock [all_clocks]
Propagation delay
Clock
Clock with
propagated
delay.
Figure 4 Setting propagated delay on a clock
• set_clock_latency: Captures actual or predicted clock latency.

Example: This example specifies a rise latency of 1.2 and fall latency
of 0.9 for clock "CLK1".
pt_shell> set_clock_latency 1.2 -rise [get_clocks CLK1]

pt_shell> set_clock_latency 0.9 -fall [get_clocks CLK1]
CLK1
CLK1 with
Latency
Fall Latency (0.9)
Rise Latency (1.2)

Figure 5 Specifying clock latency
5
• set_clock_transition: Captures predicted clock transition. This command

is used to override the calculated clock transition.
Example:This example specifies a rise transition time of 0.38 and fall
transition time of 0.25 for register clock pins clocked by "CLK1".
pt_shell> set_clock_transition 0.38 -rise [get_clocks CLK1]

pt_shell> set_clock_transition 0.25 -fall [get_clocks CLK1]
CLK1 with PT
calculated
transition
CLK1 with
user-asserted
transition
0.38 0.25
Figure 6 Specifying clock transition
• get_clocks: Creates a collection of selected clocks from the current design.
You can assign these clocks to a variable or pass them into another
command.
Example: The following example sets a rise clock transition of 0.38 on
all registers clocked by "CLK1".
pt_shell> set_clock_transition 0.38 -rise [get_clocks CLK1]

Note: get_clocks does not return generated clocks unless an update_timing
(explicit or implicit) has been preformed subsequent to the
create_generated_clock command(s).
• all_clocks: Creates a collection of all clocks in the current design. You can
assign these clocks to a variable or pass them into another command.
Example: The following example applies the set_propagated_clock command
to all clocks in the design.
pt_shell> set_propagated_clock [all_clocks]

Note: all_clocks does not return generated clocks unless an update_timing
(explicit or implicit) has been preformed subsequent to the
create_generated_clock command(s).
6
• get_generated_clocks: Creates a collection of generated clocks from the

current design.You can assign these clocks to a variable or pass them into
another command.
Example: The following command applies the set_clock_latency command on
all generated clocks in the design matching "GEN*".
pt_shell> set_clock_latency 2.0 [get_generated_clocks "GEN*"]
• set_clock_gating_check: Captures clock-gating checks that can be

specified on a list of objects in the current design. The objects can be clocks,
ports, pins, or cells. If a cell is specified, all input pins of that cell are affected.
If no objects are specified, the clock-gating check is applied to the current
design. If the environment varialble “timing_disable_clock_gating_checks”
is set to False (default) PrimeTime automatically determines clock-gating
and performs setup and hold checks on the gating input pin with respect to
the clock input. By default PrimeTime uses a “0” setup and “0” hold
requirement for a clock gating check. If you wish to override this default value,
you use this set_clock_gating_check -setup / -hold command.
Example:The following example sets a setup requirement of 0.2
and a hold requirement of 0.4 on all gates in clock
network involved with clock CK1 path.
pt_shell> set_clock_gating_check -setup 0.2 -hold 0.4 [get_clocks CK1]
• remove_clock: Removes a clock object. Any endpoints that received the

clock now become unconstrained.
Example: The following example removes clock CLK1.
pt_shell> remove_clock CLK1
• remove_clock_gating_check: Removes clock gating checks for design

objects where a gating check was set by set_clock_gating_check. If the
environment varialble “timing_disable_clock_gating_checks” is set to False
(default) PrimeTime will still automatically determine clock-gating and
performs setup and hold checks on the gating input pin with respect to the
clock input. To completely disable clock gating checks on the entire design,
set the environment varialble “timing_disable_clock_gating_checks” to
True.
Example: The following example removes the setup requirement (for rising
and falling delays) on all gates in the clock network involved with
clock CK1 path.
pt_shell> remove_clock_gating_check -setup [get_clocks CK1]
7
• remove_clock_latency: Removes a clock delay specification previously set

using the set_clock_latency command. Clock latency due to cell and net
delay propagation through the clock tree will still be calculated if
set_propagated_clock is in effect.
Example:The following example removes clock latency information from
clock "CLK1".
pt_shell> remove_clock_latency [get_clocks CLK1]
Latency
CLK1 with
Latency
Latency
removed
Figure 7 Removing clock latency

• remove_clock_transition: Removes predicted clock transition.
Appropriate clock transition will be calculated by PrimeTime based on loading
Example: The following example removes clock transition information from
all clocks in the current design.
pt_shell> remove_clock_transition [all_clocks]
CLK1 with
user-asserted
transition
CLK1 with PT
calculated
transition
Figure 8 Removing clock transition
8
• remove_clock_uncertainty: Removes specified clock skew

Example:The following example removes uncertainty information
from clock CLK.
pt_shell> remove_clock_uncertainty [get_clocks CLK]
UNCERTAINTY
CLK with
uncertainty
uncertainty
removed
Figure 9 Removing clock uncertainty

• remove_generated_clock: Removes a generated_clock object. Any
endpoints that received the generated clock now become unconstrained.
Example: The following example removes the generated clock GEN1 from
the design.
pt_shell> remove_generated_clock GEN1
• remove_propagated_clock: Removes a propagated clock specification

Example: The example removes propagated clock specifications from all
clocks in the design.
pt_shell> remove_propagated_clock [all_clocks]
Propagation delay
Clock with
propagated
delay.
Propagation
delay removed
Figure 10 Removing clock propagation delay
9
• report_clock: Reports clock info

Example: pt_shell> report_clock
****************************************
Report : clock
Design : counter
Version: 1997.01-development
Date : Fri Jul 26 09:41:39 1996
****************************************
Attributes:
p - propagated_clock
G - Generated clock
Clock Period Waveform Attrs Sources

------------------------------------------------------
CLK 20.00 {0 10} {CLK}
List of Environment Variables Related to Clocks

The following section contains a list and a brief description of the environment
variables in pt_shell that are related to clocks. For more detailed information on
these environment variables, please refer to their man pages. The variables are
listed in alphabetical order:
• timing_clock_reconvergence_pessimism
Values: “same_transition” or “normal” Default: “normal”
During “on-chip-variation” analysis PrimeTime may encounter a cell or a net with

a min/max delay that happens to be present in both the clock path as well as the
data path with different delay values. Since the same object cannot have both a
min & max delay at the same time, PrimeTime adjusts this pessimism by
performing a “clock reconvergence pessimism removal” (crpr). For further detail
about this feature in PrimeTime, please refer to the “Clock Reconvergence
Adjustment section”.
10
When the variable “timing_clock_reconvergence_pessimism” is set to

same_transition, the clock reconvergence pessimim removal (crpr) value is
computed only when the clock transition to the source and destination latches
have a common path and that on each pin of the common path, the transition is
in the same direction. In other words, if the source and destination latches are
triggered by different edge types, the clock reconvergence pessimism has a zero
value. When set to normal (default), the clock reconvergence pessimim removal
is computed even if the clock transitions to the source and destination latches
are in different direction on the common clock path.
• timing_disable_clock_gating_checks
Values: “true” or “false” Default: “false”
When true, disables clock-gating setup and hold checks. When false (the default),
PrimeTime automatically determines clock-gating and performs setup and hold
checks on the gating input pin with respect to the clock input. By default
PrimeTime uses a “0” setup and “0” hold requirement for a clock gating check.
If you wish to override this default value, you can use the set_clock_gating_check
-setup / -hold command.
• timing_ideal_clock_zero_default_transition
Values: “true” or “false” Default: “true”
Specifies a transition value to use at clock pins of a flip-flop. When true (the
default), PrimeTime uses a zero transition value for all clocks. When false,
PrimeTime uses a propagated transition value for all clocks.
Note that if propagated clocks are used (set_propagated_clock), then PrimeTime

will use the calculated transition time regardless of the setting on this variable.
Also, the set_clock_transition command will override both the zero transition
value assigned to a clock pin by this variable as well as any calcualted transition
time if propagated clocks are used.
11
• timing_input_port_clock_shift_one_cycle
Values: “true” or “false” Default: “false”
Affects the behavior of PrimeTime when timing a path from an input port with no
clocked input external delay. When true, paths starting at such input ports are
given one extra cycle (set_multicycle_path 2) to meet timing constraints at
clocked destination registers or output ports. This behavior parallels Design
Compiler. When false, no extra multicycle shift is applied.
• timing_input_port_default_clock
This environment variable affects the behavior of PrimeTime when timing a path
from an input port with no clocked input external delay. When true, all such input
ports are given one imaginary clock so that the inputs are constrained. The period
of the imaginary clock will be set by PrimeTime to be the common base period
of all clocks created in the design. This also causes the clocks along the paths
driven by these input ports to become related. When false, no such imaginary
clock is assumed.
Note: It is highly recommended that the user set the proper input delays with
respect to the appropriate clocks rather than relying on PrimeTime to do this
automatically. This will insure that the input delay is defined with respect to
the correct clock period rather than the common base period of all clocks in
the design.
• timing_clock_gating_propagate_enable
This is an old environment variable that should always be set to true. It is kept
in PrimeTime for backwards compatibility reasons.
When true (the default), PrimeTime allows the delay from the data line of the
gating check to propagate. When false, PrimeTime blocks the delay from the
data line of the gating check from propagating; only the delay from the clock line
is propagated.
12
Clock Commands in Action
set_clock_uncertainty -hold / -setup

create_clock
D Q
BUF1
CLK
BUF2
FF1
set_clock_latency -source
-late
set_propagated_clock
-early
used if the clock buffers are present (post layout)
(also called insertion delay) set_clock_transition
OR
Late Skew
Overrides the calculated
set_clock_latency
Early Skew transition time. Useful
+ in pre-layout designs.
CLK
1 2 3
set_clock_uncertainty
used if the clock buffers are not present to
estimate the delay through the buffers (pre-layout)
The diagram above illustrates the different clock commands and how they interact
in PrimeTime.
• The “create_clock” command defines the basic clock. The rest of the clock
commands modify this clock definition by adding uncertainty, phase shift etc..
• The “set_clock_uncertainty” command defines the +/- uncertainty (-hold or
-setup). If the -hold/-setup modifiers are not specified, the uncertainty will
be symmetric. This command is used to model both the jitter (i.e. clock
crystal jitter) as well as estimated clock skew in pre-layout desings. In post
layout designs where the clock tree exists, the “set_propagated_clock”
command should be used instead of the estimated clock skew uncertainty.
13
For example, if a CLK_1 has 0.2 ns of crystal jitter and an estimated 0.4 ns of
estimated clock tree skew then:
Pre-Layout: Use a total uncertainty value of 0.2 + 0.4 = 0.6 ns
pt_shell> set_clock_uncertainty 0.6 CLK1
Post Laout: Use propagated clocks and an uncertainty value of 0.2 for jitter.
pt_shell> set_clock_uncertainty 0.2 CLK1

pt_shell> set_propagated_clock CLK1
• The “set_clock_latency -source” command is used to model the latency that

occurs prior to the clock definition point (also called insertion delay). The -
early / -late modifiers can be used to specify a +/- delay. This command is
used to specify tester skew on clocks for example.
• The “set_clock_latency” and “set_propagated_clock” are used mutually
exclusively. “set_propagated_clock” is used when a clock tree exists (post-
layout). This command makes PrimeTime calculate the actual clock path
delay due to the delay arcs in the buffers and nets in the clock tree. When
a clock tree does not exist (pre-layout) then an estimated skew can be
specified using the “set_clock_latency” command.
When using the “set_clock_latency” in pre-layout designs the -min / -max
command line options can be used if the analysis type is either Best Case /
Worst Case or on-chip-variation (for more information on analysis types see the
man page for the “set_operating_condition” command):
Best Case / Worst Case: if set_clock_latency -min/max is used, the specified

min value will be used when tracing min constraints (hold) while the max value
will be used when tracing max constraints (setup).
On-chip-variation: In this mode, if a min/max latency is specified, PrimeTime will

add the max latency value to the data path and the min latency value to the clock
path when tracing max type constraints (setup). PrimeTime will add the min
latency value to the data path and the max latency value to the clock path when
tracing min type constraints (hold).
14
• The “set_clock_transition” command can be used to override the calculated

transition time on the clock pin of a timed element. This command is very
useful in pre-layout designs when a single net is feeding thousand of
registers. The transition time calculated by PrimeTime is such a situation is
usually too pessimistically large. PrimeTime will overwrite this calculated
value with the value specified by a “set_clock_transition” command.
The final clock path delay at the clock pin of a timed element is computed by
combining the delay / uncertainty values specified by using the above commands.
set_clock_latency on a Pin vs. Clock

Using the “set_clock_latency” command on a part/pin or the clock itself produces
different results in an important case: If a set_input_delay refrences a clock that
has latency defined, this latency value will be added to both the clock & data
paths of the register receiving the set_input_delay’ed signal, thus resulting in no
net change in the slack calculation. Whereas if the latency were to be defined
on the pin, it will only show up in the clock path of the register receiving the
set_input_delay’ed signal and will effect the resultant slack. This behavior is the
same if “set_clock_latency -source” is used.
For clocks that are not used as references for set_input_delay constraints, it does
not make a difference whether latency is defined on the clock or a Part/Pin.
For clocks used as references for set_input_delay commands however, it is

recommended that you use set_clock_latency on a part/pin. This latency
typically estimates the delay through the clock tree in pre-layout designs and
should not be added to the clock path. “set_clock_latency -source” is used to
model off chip skew between clocks inputs and other ports and should also be
set on part/pins. This latency should not show up in the data path.
For example, in the circuit below, say we define a clock latency of 0.40 on the
clock “CLK” by executing the following commands:
create_clock -period 3.5. -waveform { 0. 20. } -name CLK\

"BUF1/A"
set_input_delay 3.0 -max -clock CLK IN1
set_clock_latency -max 0.40 [get_clock CLK]
15
IN1 D Q
A Z
CLK CP
BUF1
FF1
Figure 11 clock latency on a clock vs. a pin

report_timing -to FF1/D will show the clock network delay but will not have a net
effect on the final margin. The report looks like this:
**********************************
Startpoint: J_01 (input port clocked by CLK)
Endpoint: I4 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max
Point Incr Path

----------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock network delay (ideal) 0.40 0.40
input external delay 3.00 3.40 r
IN (in) 0.00 3.40 r
FF1/D (FD1) 0.00 3.40 r
data arrival time 3.40

FF1/CP (FD1) 0.00 3.90 r
library setup time -0.80 3.10
data required time 3.10
----------------------------------------------------------
data arrival time -3.40
-----------------------------------------------------------
slack (VIOLATED) -0.30
************************************
As can be seen from the report above, the 0.40 latency showed up in both the
clock path as well as data path causing a violation.
16
However if we were to define the latency on a pin instead:
create_clock -period 40. -waveform { 0. 20. } -name CLK\

"BUF1/A"
set_input_delay 3.0 -max -clock CLK IN1
set_clock_latency -max 0.40 [get_pin BUF1/A]
The timing report will look like this:
**********************************
Startpoint: J_01 (input port clocked by CLK)
Endpoint: I4 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max
Point Incr Path

----------------------------------------------------------
input external delay 3.00 3.00 r
IN (in) 0.00 3.00 r
FF1/D (FD1) 0.00 3.00 r

FF1/CP (FD1) 0.00 3.90 r
----------------------------------------------------------
-----------------------------------------------------------
slack (MET) 0.10
************************************
In this case, the latency only showed up the clock path resulting in a different
slack value.
set_clock_uncertainty on Pin vs. Clock

Unlike the behavior of the set_clock_latency command set_uncertainty does not
distinguish between pins and clocks. So whether the uncertainty is defined on
the clock itself or any pin in the clock path it will be treated identically by
PrimeTime.
17
Generated Clocks
PLLs (Phase Locked Loop)

A PLL is often used in circuits with clock tree insertion. During clock tree insertion,
the buffers insert a significant delay, which cause the signal to lag behind the
primary clock. To assure a synchronous clock throughout the ASIC, this phase
difference must be eliminated. A PLL is used to remove the insertion delay. It
does this by comparing the phase difference between the internal clock and
reference clock and adding delay to the internal clock, so the internal clock will
run in phase with the primary clock.
The circuit diagram below shows a simplified example of a PLL. In this ASIC,
the phase of a skewed feedback signal (CLKF) is dynamically adjusted so it
matches the phase of an input reference signal (RCLK). In other words, the PLL
shifts the feedback signal (CLKF) in the time domain so it rises at the same time
as the reference (RCLK). The resulting signal (CLKI) is said to be “locked” in
phase with the reference signal. The latecny due to the Clock tree is therefore
removed and is not seen by FF1 & FF2.
FF0 FF1 FF2 FF3

I
input Path Internal Output
D Q D Q D Q D Q
Path Path
CLKF
i_clk
CLKI o_clk
Internal Clock
Reference RCLK Clock
Clock Tree
PLL
ASIC
Figure 12 Phase Locked Loop Cirucuit Example
18
PrimeTime, being an STA tool does not have the capability to properly analyze
PLLs automatically. In other words, if you were to create a clock at the reference
clock input to the ASIC above, the tool would not be able to calculate timing on
FF1 & FF2. The intenals of the PLL require dynamic simulation to be preperly
understood by a tool. PrimeTime treats a PLL as a black box.
Therefore, the clock waveform must be defined by the user at the output pin
(CLKI) of the PLL. The create_generated_clock command is used to assert CLKI.
Aside from creating a generated clock at the output of the PLL, there are three
other effects that need to be taken into account and modeled to properly analyze
PLLs in PrimeTime:
Jitter
PLLs intoduce additional error on the internal clock. Jitter is the amount by which
the internal, post PLL clock period can vary on consecutive cycles. This
uncertainty is a PLL spec that can be obtained from the ASIC vendor.
Offset
Offset is another specification of the PLL. It is the amount by which the internal,
post PLL clock (seen by FF1 & FF2) can lead or lag the PLL reference clock.
Clock Tree Synthesis (CTS) Skew

This is the maximum amount by which the intenal clock can vary between different
points throught the ASIC. This value is automatically calculated by PrimeTime
when a clock tree exists. In pre-layout analysis, this skew is estimated or can
be obtained from the ASIC vendor.
Insertion Delay
This is the delay between the ASIC reference clock and the mid point of the post
CTS clock tree. In pre-layout where clock tree does not exist, this delay is
estimated. Insertion Delay normally causes the internal clock to lag the external
clock. But the PLL does the job of removing the insertion delay by adjusting the
phase difference to match the phase of CLKI (feedback clock) to the phase of
RCLK (reference clock)
19
In post layout designs, this value can be obtained by doing a “report_timing -

path_type full_clock” on any register that is clocked by the internal clock. The
sum of all the physical delays (net delays + cell delays) that are present in the
clock path represent the insertion delay.
Setting up the clocks

PrimeTime does not take into account the fact that the PLL removes insertion
delay. So, it assumes that the internal clock is lagging the reference clock by an
amount equal to insertion delay. To compensate for this, the input data signals
to the internal registers (FF1 & FF2) also need to be delayed by the same amount
to avoid false violations. To do this, the clock on FF0 (i_clk) needs to be delayed
by an amount equal to the insertion delay. Similarly the outputs of FF1 & FF2
will be delayed and to compensate for this, the out_clk virtual clock is also delayed
by the sameamount. This can be done by using the set_clock_latency command.
PLL jitter, on the other hand, is applied as an uncertainty on the clock, while offset
is considered as latency once the PLL is in locked mode.
The clock in_clk is unaffected by jitter and offset. Therefore, while checking the
input path, only the internal clock (CLKI) has offset applied as latency and jitter
as uncertainty.
The internal clock (CLKI), on the other hand, is affected by both jitter and offset.
Therefore, jitter is applied as uncertainty on the internal clock and offset is applied
as latency, while checking internal paths.
Output paths are affected by jitter and offset, only on the source side (Clock of
FF2). But since Primetime does not apply uncertainty to the clock of the source
register (only to the destination register’s clock) it is necessary to apply it at the
destination clock, out_clk, while checking output paths. Therefore, latency offset
as well as uncertainty jitter is applied to the external clock feeding FF3 (o_clk).
Clock tree skew plays a role in prelayout analysis only. It is applied as uncertainty
on the internal clock (CLKI). It also has to be applied on the output clock (o_clk)
since PrimeTime does account for the uncertainty .
20
Defining the Internal Clock (CLKI)

PLL offset does not appear in the internal clock definition because it is common
to all internal paths. Therefore, the uncertainty on the internal clock is determined
by CTS skew and PLL jitter. PLL jitter, however, only affects setup timing checks
and not hold timing checks. This is because, for hold time, the data is checked
at the launching edge, and so launch edge and capture edge are the same. Since
jitter affects each edge equally, the hold time is unaffected. For setup check,
however, the capture edge is different than the launch edge, since data is checked
at the next cycle, for single cycle path. Therefore, the amount of jitter could be
different, and it affects the setup timing.
Therefore, in internal clock definition, the uncertainty is calculated as CTS skew

+ PLL jitter for setup and only CTS skew for hold. For postlayout analysis,
propagated clocks are used (set_propagated_clock command) so the CTS skew
is automatically calculated by PrimeTime. Therefore, there is no need to define
hold uncertainty, and the setup uncertainty is equal to the PLL jitter.
Defining Input Delays

The set_input_delay command is used, in Primetime, to set the arrival times of
the inputs. The -min switch indicates the setting for hold time check and -max is
used for setup time check. All inputs are referenced to the clock i_clk.
While doing hold time checks on input paths, it is necessary to apply the jitter
and offset effects on the internal clock, but this will then also affect hold time
checks on internal paths, unfairly. Therefore, instead of delaying the internal clock
by the jitter and offset value, the equivalent effect is achieved by keeping the
capture edge of internal clock constant and shifting the inputs earlier by an
amount equal to the jitter and offset. While doing setup check, the jitter value has
already been applied to internal clock and so only offset value needs to be added
to the maximum input delay to get the latest input arrival time.
Defining Output Delays

Outputs are also referenced to the clock o_clk. Since all uncertainty is already
handled in the o_clk definition, the output arrival time definition is simple and only
contains the output hold and setup time requirements.
21
Below is an example TCL script to setup the PLL in Figure 12 in PrimeTime
#Define Parameters here

# Replace CTS_SKEW PLL_JITTER, etc.. with their actual values
set spec1 [expr (CTS_SKEW + PLL_JITTER) ]
set spec2 [expr (CTS_SKEW)]
set input_min_dly 0.0 # Minimum Input Delay
set input_max_dly 2.0 # Maximum Input Delay
set dly1 [expr ($input_min_dly -PLL_JITTER - PLL_OFFSET)]
set dly2 [expr ($input_max_delay + PLL_OFFSET)]
set output_hold 2.0
set output_setup 7.0
#Defining the Internal Clock (CLKI)

create_clock -period 20.0 -name RCLK PLL/RCLK
create_generated_clock -name CLKI -source RCLK \
-multiply_by 1 PLL/CLKI
set_clock_uncertainty -setup $spec1 CLKI
set_clock_uncertainty -hold $spec2 CLKI
set_clock_latency PLL_OFFSET CLKI
# propagate clocks for post layout only
set_propagated_clock internalCLK
#Defining the on Clock input paths

create_clock -period 10.0 -name i_clk
set_clock_latency INSERTION_DELAY i_clk
#Defining the Clock on output paths

create_clock -period 10.0 -name o_clk
set_clock_uncertainty -setup $spec1 o_clk
set_clock_uncertainty -hold $spec2 o_clk
set_clock_latency INSERTION_DELAY o_clk
#Input Delays
set_input_delay -clock i_clk -min $dly1 IPORT_A
set_input_delay -clock i_clk -max $dly2 IPORT_A
#Output Delays
set_output_delay -clock o_clk -min $output_hold OUT_A
set_output_delay -clock o_clk -max $output_setup OUT_A
22
Gated Clocks
Gated clocks cause “glitches” or “clipped clocks” respectively if:
• The gating signal does not become active before the controling clock
edge
• The gating signal becomes inactive before the non-contorling clock
edge
The figure below illustrates these two problems:
CLK
GATE
GATED_CLK
Glitch Clipped clock
Figure 13 Glitches and Clipped Clocks

To insure that there are no timing problems due to the gating signal arriving too
early or too late with respect to the clock signal, PrimeTime will perform clock
gating checks on all gated clocks, using 0.0 as the default for setup and hold.
The setup check will look for Glitches while the hold check look for clipped clocks.
You can use the command:
set_clock_gating_check -setup and -hold

to change the setup and hold values from 0.0 (default value) for the gating check.
To disable clock gating checks completely, you can set the environment variable:
timing_disable_clock_gating_checks to "true"
23
Derived Clocks
PrimeTime allows you to define derived clocks by dividing or multiplying existing
clocks. To specify a clock derived from an existing clock use the following
command:
create_generated_clock -name clk_name \

-source source_clk \
<object>
where <object> is the source (pin or output port) of the generated clock.
Arguments of the create_generated_clock command are:
-divide_by divide_factor
-multiply_by multiply_factor
-edges {edge_list}
edge list corresponds to the edges of the original clock.
Example:
create_generated_clock -edges {1 2 5} \
-source CLK [get_pins DIV_2]
1 2 3 4 5 6 7
CLK
DIV_2
Other generated clock examples:
create_generated_clock -divide_by 2 \
-source sys_clk [get_pins FF1/Q]
create_generated_clock -multiply_by 3 \
-source sys_clock [get_pins div3/Q]
24
Generated Propagated Clocks

The PrimeTime documentation specifies that generated clock objects are
expanded to real clocks at the time of analysis (update_timing or report_timing).
So if no timing analysis is performed before a ’set_propagated_clock [all_clocks]’
command, your generated clocks do not yet exist and are not returned by the
’all_clocks’ command. So if the following script is used:
create_clock -period 10 CLK

create_generated_clock -divide_by 2 -source CLK ff1/Q \
-name GEN_CLK
set_propagated_clock [all_clocks] report_timing
A timing report will show that the generated clocks are NOT propagated.
There are two ways to get around this issue. The best way is to add the generated
clocks to the propagated clock list:
set_propagated_clock [list [all_clocks]

[get_generated_clock *]]
An alternative is to cause a timing update before issuing the
set_propagated_clock command:
create_generated_clock -divide_by 2 -source CLK ff1/Q

-name GEN_CLK
update_timing
set_propagated_clock [all_clocks]
25
Multiple Clock Domains
Common Base Period Expansion

If paths between clocks have different frequencies, there must be a reasonable
base period over which all waveforms repeat. The base period is the least
common multiple of all clock periods. The base period requirement is qualitative;
no hard limit exists. For example, if you have clock periods of 10, 15, and 20, the
common base period is 60. The periods do not have to be divisible by each other
(15 is not evenly divisible by 10), but there must be a period that is a small multiple
of both. If the base period is more than 10 times larger than the smallest period,
long runtimes and greater memory requirements can result. Figure 10 below
shows multiple clocks with a single base periods.
Figure 14 Base Period of Multiple Clocks
If you have a register feeding another register and one period is 10 and another
is 10.1, the path is essentially asynchronous. The tool tries to determine the setup
requirement for this path by expanding both clocks to the base period and
determining the tightest single cycle relationship for setup. The common base
period for this case is 1010.0. Internally, the tool only approximates the base
period for the extreme cases, because the paths are not really synchronous. In
this case, it is best to explicity define these clock domains as asynchronous. See
the “Asynchronous Clock Domains” section for more info.
26
Tips for Multi-Frequency Analysis:

1) Make sure the clock frequencies are somewhat closely related. If not -- and
there is circuitry between clock domains -- timing analysis could take a very long
time because every setup and hold combination between the two unrelated
clocks will be checked. This can result in thousands of checks. It is
recommended that you pick the nearest common base period of 10 or less. Adjust
in the pessimistic direction if possible, or fine- tune with inter-clock uncertainty.
Bad Example: Clock1 => 95 ns period Clock2 => 100 ns period
Nearest common base period = 95 * 100 = 9500 (This is where the edges
line up.) (0, 100) (95, 100) (180, 200) ... (9405, 9500) (That’s 100 relationship
pairs.)
This means that PrimeTime must determine the most restrictive edge
relationship for setup and hold checks.
It is better to speed up from a 95 ns period to 90 ns, and add 5 ns of minus

uncertainty to the 100 ns clock wrt 90 ns clock. This way the logic will be still
constrained to 5 ns, but clock1 will be related to clock2. (90,100 - 5)
It is recommended that you avoid fractional clock periods like 100 ns vs. 100.0001
ns.
For related information, see SOLV-IT! article SYNTH-518661.html, "Addressing

Large Common Base Periods in PrimeTime".
2) Generated internal clocks are preferred for PrimeTime, because you will have
to change only the period/waveform of the source clock to change the waveform
for the internal clocks. Also, this makes it easier for PrimeTime to associate the
clocks in the design, along with automatically deriving the delay from the source
clock to the generated clock.
The less desirable alternative is to create each of the individual clocks. In this
case, should the waveform/period change, you would have to change the
waveform/period of every internal clock. You would also have to manually specify
the skew between clocks. Another problem with this approach is that it will
increase your runtime because PrimeTime is not being told how the clocks are
associated.
27
3) If the design is post-layout, be sure that all of the clocks are propagated clocks.
Use the following:
set_propagated_clocks [all_clocks]
set_propagated_clocks [get_generated_clocks *]
4) **** VERY IMPORTANT ****
Be sure you have specified all input/output delays with respect to a clock.
If there are any inputs that are not constrained with respect to a clock,
PrimeTime must compute the common base period for all clocks, EVEN if
they are asynchronous.
Asynchronous Clock Domains

When you have a set of clock domains which are asynchronous and do not wish
to perform timing analysis between these domains, you can can use the
set_false_path on clock objects. For example, if CPUClk and DotClk are
asynchronous to each other:
set_false_path -from [get_clocks CPUClk] -to [get_clocks DotClk]
set_false_path -from [get_clocks DotClk] -to [get_clocks CPUClk]
These commands tell PrimeTime not to analyze any data launched by CPUClk
and received by DotClk and vice-versa.
When there is larger number of asynchronous clock domains, this task becomes
tedious. SOLV-IT article “Static_Timing-137.html” contains a versatile TCL scripts
that simplifies asynchronous clock definition. Please refer to this article for further
details.
28
Inter-Clock skew
You need to define skew values between clock domains when dealing with pre-
layout designs. In post-route designs, the propagated delays through the buffers
in the clock tree will take care of this skew, so this step is not needed. Setup,
hold, rise, and fall can be independently set for all skews. Use the
set_clock_uncertainty command to define this skew. In the example below, we
define a skew of 0.15 from clock Phi1 to clock Phi2 (note that a separated
set_clock_uncertainty command is needed to define skew from clock Phi2 to
clock Phi1).
D Q D Q
Phi1 CLK Phi2 CLK
pt_shell> set_clock_uncertainty -from Phi1 -to Phi2 0.15
Pre/Post Layout Clock Issues
Ideal Clocks (Pre-layout)

In pre-layout STA analysis, a clock tree does not exits. Therefore, latency and
uncertainty must be estimated and set on the ideal clocks. Also, since a single
net can be feeding thousand of registers (not clock tree), the transition time
calculated by PrimeTime can be too pessimistic. Therefore, the
“set_clock_transition” command is used to override the PrimeTime calculated
value. The following is an example of a set of commands to define such a clock:
29
pt_shell> create_clock “CLOCK” -period 30 [get_port CLK1]

pt_shell> set_clock_uncertainty 0.5 CLOCK
pt_shell> set_clock_latency -min 3.5 CLOCK
pt_shell> set_clock_latency -max 5.5 CLOCK
pt_shell> set_clock_transition 0.30 CLOCK
The waveform of such a clock will look like this:
Ideal
CLOCK
CLOCK with
Latency
+
Uncertainty
Uncertainty
Latency Transition
Figure 15 Clock with latency, uncertainty and trasition
Propagated Clocks (Clock Trees)

Once a design comes back from layout, a physical clock tree exists so there is
no need to estimate the clock tree uncertainty or latency any more. Also, since
the a single net does not feed every register, there is no need to
“set_clock_transition”. In this case use the set_propagated_clock command to
have PrimeTime calculate the actual clock path delay due to the delay arcs in
the buffers and nets:
pt_shell> set_propagated_clock clock_object_list
30
Propagation delay
Clock
Clock with
propagated
delay.
Figure 16 Propagated Clock
SDF back annotated Clock tree

There are two ASIC vendor approaches to clock tree SDF back annotation:
Collapsed Tree: ( Ex:Toshiba, TI)

The clock trees are collapsed and the SDF that is returned to the customer does
not include the clock trees. The insertion delays of the clock trees are annotated
as IOPATH delays PORT constructs of the macros. The skews to each clock load
are annotated as INTERCONNECT delays. Single delay arc from the clock
definition point to the clock pin of the Register.
Full Tree: (Ex: LSI, Lucent)

Clock tree netlist is combined with the design netlist and the delays are fully back-
annotated using SDF.
In either of the above situations, the “set_propagated_clock” command should

be used in PrimeTime so that the physical latency can be calculated properly in
the clock path.
Overriding Clock Net Delays

There may be situations when you would want to find clock nets in your design
and override annotated or calculated delays in PrimeTime (For example when
trouble shooting setup violations).
31
The following script first identifies the fanout pins for all of the clocks - source
and generated - in the design, then finds the nets attached to these pins. It then
creates a collection of the fanin and fanout points of the nets. Finally, the
set_annotated_delay command is used to set a value (in this case 0) on all of
the nets connected between the startpoints and endpoints.
set ck_fanout [all_fanout -clock_tree -flat]

set clock_nets [get_nets -of_objects $ck_fanout]
set end_net [all_fanout -from $clock_nets]
set start_net [all_fanin -to $clock_nets]
foreach_in_collection start_net_pin $start_net {
foreach_in_collection end_net_pin $end_net {
set_annotated_delay 0 -net -from $start_net_pin -
to $end_net_pin
}
}
How to Create a Clock on a Net

The create_clock command only accepts pins or ports on which to create clocks.
The reason for this is because creating a clock can be ambiguous; a net might
have many drivers and many loads, so it will not be clear which is considered to
be the true source of the clock. It is best to determine the driving port or cell pin
and create the clock at that point.
A SOLV-IT article titled: “Static_Timing-98.html” addresses this problem. It

contains an example TCL script that will find the driving pin(s) and/or port(s) of
a net and issue the create_clock command on the pin(s) and port(s).
If the net has multiple drivers, one clock will be created by the script. However,
each of the driver pins and ports will be specified, creating a multi-source clock.
Please refer to the SOLV-IT article for further detail.
32
Clock Issues Related to Min/Max timing
Clock Reconvergence Adjustment

As mentioned in the previous paragraph during on-chip variation analysis mode,
PrimeTime uses the maximum cell and net delay values when tracing a max path
and the minimum cell and net delay values when computing the min path. Since
a given cell cannot have both a min delay AND a max delay at one given instant
in time, cells that are common to both the data and clock paths can receive a
“clock reconvergence adjustment”. In order to have PrimeTime perform a “Clock
Reconvergence Pessimism Removal” (crpr) during report_timing, use the
--remove_clock_reconvergence_pessimism command line option:
pt_shell > report_timing -remove_clock_reconvergence_pessimism 0.0

Please refer to the man page for the “report_timing” command for more
information on clock reconvergence.
The following figure illustrates the clock reconvergence correction concept:
1.04 Data path

Purple = PVT1 CP-Q “1.80”
Teal = “PVT2” 3.21 D Q
D Q
“3.77”
0.48 U4 U5
“0.60” CP
0.64 U2 CP
th
k pa
“0.80” setup
0.52
l oc
U1 “0.65” C “0.2”
U3
CLK
U1 is common in clock and data paths
Clock reconvergence adjustment = 0.80 - 0.64 = 0.16
33
Below is a report_timing for the above circuit:
Point Incr Path

---------------------------------------------------------------------
clock network delay (propagated) 1.40 1.40
LD1/ck (FD2) 0.00 1.40 r
LD1/q (FD2) 1.80 3.20 f
U1/z (AN2) 1.27 4.47 f

clock network delay (propagated) 1.16 7.16
clock reconvergence pessimism 0.16 7.32
clock uncertainty 0.00 7.32
LD2/ck (FD2) 7.32 r
---------------------------------------------------------------------
---------------------------------------------------------------------
slack (VIOLATED) -0.50
Tester Skew
Off-Chip skew modeling

The ASIC fabrication process includes a testing phase. Automated Test
Equipments (ATEs) are used to test and bin ASICs during production. ATEs
introduces their own error into this process. The input signals have an additional
amount of skew associated with the test fixture. This may cause a part to be
rejected, even if there are no timing errors in the logic simulation. If the tester
skew is defined, it allows the ASIC foundry to validate the device knowing that
the tester skew has been accounted for in the timing verification. When
performing static timing analysis, the user can model this skew.
34
The challenge in defining the tester skew is making sure that skew reconvergence
is done properly. In the tester skew schematic below, the setup/hold check for
registers “n1_reg” and DOUT_reg need to account for tester skew since their
clock and data paths are either directly on indirectly dependent on different
primary inputs. “n2_reg” on the other hand, does not need a skew check because
its data path is indirectly dependent on the same primary input as its clock path.
DIN D Q D Q D Q
FD1 FD1 FD2
n1_reg n2_reg n3_reg

D Q DOUT
CLK1 CLK Q CLK Q CLK Q
FD1
DOUT_reg
RESET
CLK Q
CLK2
No Skew Check !!!

Setup/Hold Recovery Setup/Hold
with Skew with Skew with Skew
Figure 17 Tester skew schematic
It is very important to note that min/max skew analysis can only be performed in
PrimeTime when in “on_chip_variation” mode. Use the following command to
set the analysis in this mode:
pt_shell> set_operating_condition -analysis_type \

on_chip_variation
To define tester skew on a clock input, use the set_clock_latency command. For
example, say you need to model +/- 1.0 skew on the clock:
35
Late Skew
Early Skew
CLK
1 2 3
The use the following commands:
set_clock_latency -source -early 1 CLK

set_clock_latency -source -late 1 CLK
To model skew on a data input signal, use the set_input delay command. For
example, say you need to model a -1.0/+2.0 skew on an input pin:
Late Skew
Early Skew
DATA
4 5 7
Then use the following commands:
set_input_delay -min 1 -add_delay -clock CLK

set_input_delay -max 2 -add_delay -clock CLK
When reporting the setup/hold slack to n1_reg, PrimeTime will now add the +/-
1.0 skew to the clock path and the additional -1.0/+2.0 skew to the data path.
36
When reporting the setup/hold slack to n2_reg, however, you need to use the
“-remove_clock_reconvergence_pessimism” switch with the report_timing
command to have PrimeTime perform the clock reconvergence pessimism
correction discussed in the previous section. This will ensure that the additional
tester skew gets removed from the slack calculation. Below is an example of
report_timing using the “-remove_clock_reconvergence_pessimism” switch:
Point Incr Path

---------------------------------------------------------------
clock CLK1 (rise edge) 0.00 0.00
clock source latency 2.00 2.00
CLK1 (in) 0.00 2.00 r
n1_reg/CP (FD2) 0.00 2.00 r
n1_reg/Q (FD2) 1.42 3.42 f
n2_reg/D (FD2) 0.00 3.42 f
clock CLK1 (rise edge) 5.00 5.00

clock source latency 1.00 6.00
CLK1 (in) 0.00 6.00 r
n2_reg/CP (FD2) 0.00 6.00 r
clock reconvergence pessimism 1.00 7.00
---------------------------------------------------------------
---------------------------------------------------------------
slack (MET) 2.73
Figure 18 Example trace with clock reconvergence pessimism correction
37
Differences between DC and PT clocking
How to achieve correlation

The Synopsys synthesis tool, Design Compiler, contains a static timing analyzer
called DesignTime. This tool is used to verify timing during synthesis and
optimization cycles. Since PrimeTime is stand-alone, it does not require all the
data constructs required for logic synthesis, it’s performance is significantly better
than DesignTime and it’s memory requirements are much lower. Also, Design
Time does not have the capacity nor the flexibility to perform full chip static timing
verification.
For the most part, the results of particular traces in DesignTime parallel that of
PrimeTime. There are situations, however, where the results might vary since
the two tools have been designed to perform two different tasks. If you need to
achieve timing correlation between Design Time and PrimeTime for a particular
trace, you need to set following environment variables in PT to simulate DT
behavior.
• set timing_disable_internal_inout_net_arcs to “false”

• set timing_disable_clock_gating_checks to “true”
• set timing_input_port_clock_shift_one_cycle to “true”
• set disable_case_analysis to “true”
• set timing_allow_short_path_borrowing to “true”
• set timing_disable_uncertainty_correction to “true”
• set timing_propagate_single_condition_min_slew to “true”
Furthermore, you need to set following variables in DT to simulate PT behavior
• set timing_self_loops_no_skew to “true”

Also, you need to check whether any clock is created at the output of a
combinational cell like a buffer, mux or a 3-input nand gate. If there are such
clocks created, then you need to move this clock to the input of the gate.
Please refer to the PrimeTime application note “How to Achieve Timing

Correlation Between PrimeTime and DesignTime” for further detail about the
above settings.
38

Extensive Application Notes On Clocks in Primetime

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extensive Application Notes On Clocks in Primetime

Uploaded by

Copyright:

Available Formats

Synopsys Extensive Application Notes

Clocks in PrimeTime - October 1999

Extensive Application Notes

This document is an extensive Application Notes that covers many advanced

• PrimeTime User Maunal

PrimeTime Commands & Variables Related to Clocks:

List of All Clock Commands with Examples:

• create_clock: Creates a basic clock object.

pt_shell> create_clock "PHI1" -period 10 -waveform { 5.0 9.5 }

• create_generated_clock: Creates a generated clock object based on a

Example: The following example creates a generated clock whose edges

pt_shell> create_generated_clock -edges {1 3 5} -source CLK \

Figure 2 Create_generated_clock command

pt_shell> derive_clocks -period 20

• set_clock_uncertainty: Captures actual or predicted clock skew. The

pt_shell> set_clock_uncertainty -setup 0.65 [get_clocks CLK]

Hold Uncertainty Setup Uncertainty

Figure 3 Specifying clock uncertainty

• set_propagated_clock: Specifies propagated clock delay (usually due to

pt_shell> set_propagated_clock [all_clocks]

Figure 4 Setting propagated delay on a clock

• set_clock_latency: Captures actual or predicted clock latency.

pt_shell> set_clock_latency 1.2 -rise [get_clocks CLK1]

Fall Latency (0.9)

Rise Latency (1.2)

• set_clock_transition: Captures predicted clock transition. This command

pt_shell> set_clock_transition 0.38 -rise [get_clocks CLK1]

pt_shell> set_clock_transition 0.38 -rise [get_clocks CLK1]

pt_shell> set_propagated_clock [all_clocks]

• get_generated_clocks: Creates a collection of generated clocks from the

pt_shell> set_clock_latency 2.0 [get_generated_clocks "GEN*"]

• set_clock_gating_check: Captures clock-gating checks that can be

pt_shell> set_clock_gating_check -setup 0.2 -hold 0.4 [get_clocks CK1]

• remove_clock: Removes a clock object. Any endpoints that received the

pt_shell> remove_clock CLK1

• remove_clock_gating_check: Removes clock gating checks for design

pt_shell> remove_clock_gating_check -setup [get_clocks CK1]

• remove_clock_latency: Removes a clock delay specification previously set

pt_shell> remove_clock_latency [get_clocks CLK1]

Figure 7 Removing clock latency

pt_shell> remove_clock_transition [all_clocks]

• remove_clock_uncertainty: Removes specified clock skew

pt_shell> remove_clock_uncertainty [get_clocks CLK]

Figure 9 Removing clock uncertainty

pt_shell> remove_generated_clock GEN1

• remove_propagated_clock: Removes a propagated clock specification

pt_shell> remove_propagated_clock [all_clocks]

Figure 10 Removing clock propagation delay

• report_clock: Reports clock info

Clock Period Waveform Attrs Sources

List of Environment Variables Related to Clocks

During “on-chip-variation” analysis PrimeTime may encounter a cell or a net with

When the variable “timing_clock_reconvergence_pessimism” is set to

Note that if propagated clocks are used (set_propagated_clock), then PrimeTime

Clock Commands in Action

set_clock_uncertainty -hold / -setup

Pre-Layout: Use a total uncertainty value of 0.2 + 0.4 = 0.6 ns

pt_shell> set_clock_uncertainty 0.6 CLK1

pt_shell> set_clock_uncertainty 0.2 CLK1

• The “set_clock_latency -source” command is used to model the latency that

Best Case / Worst Case: if set_clock_latency -min/max is used, the specified

On-chip-variation: In this mode, if a min/max latency is specified, PrimeTime will

• The “set_clock_transition” command can be used to override the calculated

4) VERY IMPORTANT