Application Note

Constraining Designs

Version 1.0
May 1999
NEC Electronics Europe GmbH
 NEC Electronics (Europe) GmbH

Contents
Contents ..............................................................................................................................2
1 Introduction..................................................................................................................3
2 Specifying Clock Information ...................................................................................3
2.1 Creating a Clock........................................................................................................4
3 Calculating the Clock Tree Delay.............................................................................5
4 Constraining Internal Clocks....................................................................................6
4.1 Example of an Clock Divider .....................................................................................7
4.2 Clock tree propagation ..............................................................................................8
4.3 How to use generated clocks in DesignCompiler environment ..................................9
4.4 Constraining a PLL..................................................................................................10
5 Timing Checks of gated Clocks .............................................................................11
5.1 How to fix clock gating violations .............................................................................12
6 Minimum Pulse Width Checks................................................................................12
7 Input and Output Delay............................................................................................13
7.1 Setting Port Input Delay ..........................................................................................13
7.2 Setting Input Delay on Clocks .................................................................................14
7.3 Setting Port Output Delay........................................................................................14
8 Timing Exceptions ....................................................................................................15
8.1 Setting False Paths .................................................................................................15
8.2 Setting Multicycle Paths ..........................................................................................15
8.3 Analyzing Asynchronous Preset and Clear Timing Arcs ..........................................17
8.4 Bidirectional Feedback Paths ..................................................................................17
8.5 Set_case_analysis ..................................................................................................17
8.6 Switch off clock_gating checks ................................................................................17

Application Note
Constraining designs, Doc.-Nr. 1.0
2
NEC Electronics (Europe) GmbH

1 Introduction
To get an effectively timing optimized design it’s necessary to define the design goals in
measurable circuit characteristics. These design goals are called ‘timing constraints’. They
are necessary for the initial synthesis as well as for the Static Timing Analysis.

This document refers to the constraints for the Static Timing Analysis using the Synopsys
tool Primetime. Especially around the clock definitions these constraints are slightly different
compared to constraints for synthesis.

When Primetime flags violations it is mandatory to generate the same violations also in the
DesignCompiler environment in order to fix them. Therefor we highlight eventually
differences between DesignCompiler and PrimeTime .

All descriptions and examples in this document can only give some first hints to create the
timing constraints as exact and as complete as possible. This Application Note can’t
substitute a dedicated tool training for PrimeTime and DesignCompiler . For further details
the reading of Synopsys online documentation

2 Specifying Clock Information

It’s necessary to specify all clocks used or referenced in the design.

The clock information includes:

• Period and waveform

• Latency (insertion delay)
• Uncertainty (skew)
• Divided and internally generated clocks
• Clock gating checks
• Fixed transition time for incomplete clock networks

The analysis of the synchronous portion of a design is supported by PrimeTime and

DesignTime . Paths between registers or ports will be analyzed. For each path, a fixed phase
relationship must exist between the startpoint and endpoint clocks.

The clocks can be:

• Single phase
• Multiple phase
• Multiple frequency

Application Note
Constraining designs, Doc.-Nr. 1.0
3
NEC Electronics (Europe) GmbH

If paths between clocks have different frequencies, there must be a reasonable base period
over which all waveforms repeat. The least common multiple of all clock periods is the base
period. 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. Long runtimes and greater memory
requirements can result if the base period is more than 10 times larger than the smallest
period. The Picture below shows multiple clocks with a single base period.

Note: Each register clock pin should be in the transitive fanout of one clock source.

If you have a sending register whose period is 10 and a receiving register whose period is
10.1, the path is asynchronous. The tool tries to determine the setup requirement for this path
by expa00nding both clocks to the base period and determining the tightest single cycle
relationship for setup. The common base period for this case is 1010.

2.1 Creating a Clock

The create_clock command creates a clock at the specified source.

The Syntax in PrimeTime and DesignTime is:

create_clock -period period_value [-name clock_name] [-waveform edge_list] [ port_pin_list]

Input ports of the design or internal pins, such as the output of a clock divider cell, can be
clock source. PrimeTime and DesignTime trace the clock network automatically so the clock
reaches all registers in the transitive fanout of its sources. It’s necessary to create clocks close
to the true sources. Do not create a clock at every flip-flop clock pin separately.

With the create_clock command generated clocks have perfect waveforms and the delay
effects of the clock network will be ignored. After the clock creation, you must describe the
clock network for an accurate timing analysis (described in chapter 3 “Calculating the Clock
Tree Delay”).

Application Note
Constraining designs, Doc.-Nr. 1.0
4
NEC Electronics (Europe) GmbH

Example for PrimeTime and DesignTime :

To create a clock with a period of 10, a rising edge of 2, and a falling edge of 4 on ports C1
and C2, enter:

create_clock -period 10 -waveform {2 4} {C1 C2}

The resulting clock is named C1 to correspond with the first source listed. C1 produces the
waveform shown below

It’s also possible to define virtual clocks for signals that interface to external (off-chip) clocked
devices with the create_clock command. A virtual clock has no actual source in the current
design but you can use it for setting input or output delays.

Example for PrimeTime and DesignTime:

To create a virtual clock named vclk, enter:

create_clock -period 8 -name vclk -waveform {2 5}

The vclk clock has the following waveform.

3 Calculating the Clock Tree Delay

Within the Synopsys environment a clock tree can be described either as ideal or propagated.
An ideal clock is described by specifying a clock latency and a clock uncertainty. In this
application note we will focus on propagated clocks. To propagate clock network delays and
automatically determine latency at each register clock pin, enter

pt_shell> set_propagated_clock [all_clocks]

or
dc_shell> set_propagated_clock all_clocks()

This approach is the most accurate for post layout analysis. The same approach can be used
by doing a forward annotation, but keep in mind, that the forward annotation is doing only a
rough estimation of the clock tree latency and can not take clock skew into account. Although

Application Note
Constraining designs, Doc.-Nr. 1.0
5
NEC Electronics (Europe) GmbH

the clock skew between two FF is calculated during the timing analysis it might still be useful
to specify a clock uncertainty for the following reasons:

• to add some margin for setup and hold checks

• to take clock jitter into account (in general only required for setup checks, not for
hold checks)

Note, that a different clock uncertainty can be specified for setup and hold checks. The clock
uncertainty can also be specified between clock domains.

Modifying the clock tree latency can have quite a big impact on the timing violations. If you
like to analyze your design assuming a different clock latency, it is possible to add an delay to
the clock-source pin, use:

pt_shell> set_input_delay <add_delay> <clock-source-pin>

4 Constraining Internal Clocks

Quite a big number of circuits have internal clocks. An internal clock is a clock where the clock
source pin is not an external pin. In most cases this internal clock is derived from an external
clock and keeps a certain phase relation to the external clock. One key issue for an STA is to
analyse this relation correctly.

One common class of internal clocks are clock generator like dividers or multiplier. This class
can be described as a generated clock which allowes an automatic calculation of the phase
relation to the master clock. Other classes of internal clocks like the output of a PLL can not be
described using generated clocks. An approach for these clock classes is described in the
chapter “Constraining a PLL”

Generated clocks are only supported in PrimeTime . The subsequent chapter “How to use
generated clocks in DesignCompiler environment” will show a work-around which allows
timing fixes by DesignCompiler .

The Figure below shows a simple clock divider, assuming an ideal environment.

Application Note
Constraining designs, Doc.-Nr. 1.0
6
NEC Electronics (Europe) GmbH

Specifying a generated clock instead of independent internal clock has two advantages:

• The clock period is derived from the master clock

• The propagation delay will be calculated in relation to the master clock. This
simplifies timing checks between clock domains.

One restriction is, that the master clock can not be a virtual clock, since the source pin of the
clock needs to be know.

Note that generated clocks are kept separately from other clock definitions. Generated clock
objects are expanded to real clocks when you time your design (update_timing).

4.1 Example of an Clock Divider

If the period of the divided clock is a power of 2, the simplest way is to use the –divide_by
option. Assuming a clock divider as shown in the figure above, enter:

pt_shell> create_generated_clock -name CLK1 -source CLK -divide_by 2 INFF1/Q

If the relation between the master and generated clock can not be described by a simple
binary division, then use the edge option. The edge option, specify the edges in terms of the
edge number from the master clock that form the edges of the generated clock. The figure
below shows an example of an clock divider by 3 and the command which can be used to
specify the clock.

pt_shell> create_generated_clock -edges { 1 5 7 } \

-source SYSCLK [get_pins DIVIDE]

Divide-by-3 Clock Generator:

Application Note
Constraining designs, Doc.-Nr. 1.0
7
NEC Electronics (Europe) GmbH

You can shift the edges of a generated clock. This shift is not considered as clock latency. The
number of shifts must equal the number of edges. To create a divide-by-3 generated clock
and shift the edges by two time units as shown in the Figure below, enter:

pt_shell> create_generated_clock -edges { 1 3 7 } -edge_shift { 2 2 2 } \

-source SYSCLK [get_pins DIVIDE]

4.2 Clock tree propagation

For post-layout analysis usually the clock tree propagation delay is calculated automatically.
This is done usually by issuing the command:

pt_shell> set_propagated_clock [all_clocks]

Be aware that generated clocks are expanded to real clocks at the time of analysis
(update_timing or report_timing). This means, that unless the timing analyses have been
started the generated clocks do not yet exist and are not returned by the ‘all_clocks’
command. For this reason it is required to enable clock tree propagation for the generated
clocks explicitly by using the command:

pt_shell> set_propagated_clock [get_generated_clock *]

If you do not feel certain, whether the clock tree propagation delay has been calculated
correctly you can use the command:

pt_shell> report_timing –path_type full_clock

to get a detailed listing of the clock tree propagation delay calculation.

Application Note
Constraining designs, Doc.-Nr. 1.0
8
NEC Electronics (Europe) GmbH

4.3 How to use generated clocks in DesignCompiler environment

Unfortunately generated clocks are not supported in DesignCompiler environment.

DesignCompiler stops the clock propagation at a FF. As a work-around it is required to
specify a generated clock as a separate clock. The period and waveform has to be specified
by hand. One important issue is to calculate the clock tree propagation delay correctly. This
has to be done in two steps. The first step is to measure the delay up the root pin of the
generated clock. The next step is to define the generated clock as an independent clock and
to add an input delay to the new defined clock.

Define additional
Clock Devider
clock here

Clock Domain A

Mesure delay

Clock Domain B
CLK

Given a circuit as shown in the figure above the following commands have to be issued:

dc_shell> create_clock CLK_EXT –name CLK_EXT –period 10

dc_shell> set_clock_skew –propagated CLK_EXT

dc_shell> report_timing –delay max_rise –from CLK –to devider_FF/H02

dc_shell> report_timing –delay max_rise -from devider_FF/N01

dc_shell> create_clock devider_FF/N01 –name CLK_INT –period 20

dc_shell> set_input_delay –rise <delay_value > -clock CLK_INT ff-name/N01

dc_shell> set_propagated_clock CLK_INT

Be careful when measuring delays. Always make sure, that the delay is related to the correct
edge. If both edges of the divided clocks are used, a different input delay has to be specified.

Application Note
Constraining designs, Doc.-Nr. 1.0
9
NEC Electronics (Europe) GmbH

4.4 Constraining a PLL

The timing behavior can not be described within the synopsys library format. Therefore it is
modeled as a black-box. As a consequence the clock propagation stops at the input of the
PLL and an internal clock needs to be redefined at the output of the PLL. To get the clock
propagation correct it is required to set an input delay to the root pin of the internal clock. The
value should be equal to the difference of the delay A – B. All input and output delays of
external pins should be defined related to the external defined clock.

Define clock CLK_INT here

Set input delay to A-B
mesure delay A

CLK PLL

mesure delay B

Define clock CLK_EXT here

In terms of synopsys you have to issue the following commands:

dc_shell> create_clock CLK –name CLK_EXT –period 10

dc_shell> create_clock pll_inst/N01 –name CLK_INT –period 10
dc_shell> set_propagated_clock {CLK_EXT CLK_INT}
dc_shell> set_input_delay <value> pll_inst/N01

This methodology will work in both environment PrimeTime and DesignCompiler .

Application Note
Constraining designs, Doc.-Nr. 1.0
10
NEC Electronics (Europe) GmbH

5 Timing Checks of gated Clocks

The clock tree contains quite often not only inverters an buffers, but also gates with 2 input
pins. This is called clock gating and requires special timing checks between both pins of the
gate.

PrimeTime can automatically check setup and hold violations on gating inputs. This ensures
that the clock signal is not interrupted or clipped by the gate. The clock gating setup check
ensures that the controlling data signals are stable before the clock becomes active. This
check is performed on combinational gates through which clock signals are propagated. The
arrival time of the leading edge of the clock signal is checked against both edges of any data
signal feeding the data pins to prevent a glitch at the leading edge of the clock pulse or a
clipped clock pulse.

Clock gating setup violations are shown in the Figure below:

The clock gating hold check ensures that the controlling data signals are stable while the clock
is active. The arrival time of the trailing edge of the clock pin is checked against both edges of
any data signal feeding the data pins using the hold equation. A clock gating hold violation
causes either a glitch at the trailing edge of the clock pulse or a clipped clock pulse.

Clock gating hold violations are shown in the Figure below:

Application Note
Constraining designs, Doc.-Nr. 1.0
11
NEC Electronics (Europe) GmbH

• Keep in mind, that this check is only done on combinational gates. It is a restriction, that
only one pin of the gate might be affected by the clock. The other pin must be independent
from any clock.

By default no margin is added for setup and hold times of gated clocks. Margin can be added
by using the set_clock_gating_check command.

The syntax is:

set_clock_gating_check [-setup setup_value] [-hold hold_value] [-rise] [-fall]

[ object_list]

As object_list a specific gate or a clock can be specified. If a clock is specified, then these
commands refer to all gates in the clock network.

The report_constraint command performs clock gating setup and hold checks. Use it to
identify any clock gating violations.

To remove clock gating checks set using the set_clock_gating_check command, use
remove_clock_gating_check.

There is also a global switch which disables all checks on gated clocks. If the variable

Set timing_disable_clock_gating_checks false

Is set to false, then no timing check on gated clocks will be performed.

5.1 How to fix clock gating violations

By default DesignCompiler does not check for clock gating violations. In order to fix these
violations use the set_clock_gating_check command and specify all gates, which require a
clock gating check.

6 Minimum Pulse Width Checks

Minimum pulse width checks are important to ensure proper operation of sequential circuits.
The pulse width of the original clock can be reduced due to different delays for rising and
falling edge. Sequential cells have a minimum pulse width limit incorporated in the library. It is
possible to enable additional checks by using the command set_min_pulse_width.

Minimum pulse width checks can only be performed by PrimeTime . DesignCompiler can
neither check for such kind of violations nor fix those. If you encounter such violations, they
have to be fixed by manual modification of the circuit.

Application Note
Constraining designs, Doc.-Nr. 1.0
12
NEC Electronics (Europe) GmbH

7 Input and Output Delay

Input ports are assumed to have zero input delay and output delay by default. To characterize
the operating environment of the current design you can use input and output delays. For inout
(bidirectional) ports, you can specify the path delays for input and output mode. An input or
output delay can be set on input or output ports relative to a clock edge.

7.1 Setting Port Input Delay

To specify the timing of external paths leading to an input (or inout) port you can use the
set_input_delay command. An input delay is the specification of an arrival time at an input
port relative to a clock edge.

The path length from the clock pin of the source flip-flop to the output pin of the driving cell,
minus the load-dependent portion of the driving cell’s delay should be equal to the input delay.
For example, sees in Figure below the external path from the clock port of cell L1 to port IN1.

Example 1
If the delay from the clock port of cell L1 to the input IN1 (minus the load-dependent delay of
the driving cell) is 4.5, the set_input_delay command should be as follows:

set_input_delay 4.5 -clock PHI1 {IN1}

Example 2
If paths from multiple clocks or edges reach the same port, specify each path using the -
add_delay option. If you omit the -add_delay option, existing data is removed and overwritten.
For example:

set_input_delay 2.3 -clock PHI2 -add_delay {IN1}

Application Note
Constraining designs, Doc.-Nr. 1.0
13
NEC Electronics (Europe) GmbH

This allows PrimeTime and DesignTime to determine the correct single-cycle timing
constraint for paths from this port. Use the -clock_fall option to denote a negative level-
sensitive latch; otherwise the -level_sensitive option implies a positive level-sensitive latch.

To describe a path delay from a level-sensitive latch, use the -level_sensitive option. If the
latch is positive-enabled, set the input delay relative to the rising clock edge; if it is negative-
enabled, set the input delay relative to the falling clock edge. If time is being borrowed at that
latch, add that time borrowed to the path delay from the latch when determining input delay.

To see input delays on ports, use report_port -input_delay.

7.2 Setting Input Delay on Clocks

If the clock is propagated PrimeTime and DesignTime consider the input delay on clock
source ports or pins as source latency. The input delay can be relative to no clock, or to the
clock of that source. To determine total latency the source latency value is added to the clock
network delay.

The following command, which sets delay on all the inputs including the clock input, is a
common mistake:

set_input_delay 2 -clock CLK [all_inputs]

Instead, use the following command:

set_input_delay 2 -clock CLK \

[remove_from_collection [all_inputs] [get_port CLK] ]

In PrimeTime use the set_clock_latency command with the -source option to define the
actual source latency, if any exists.

In DesignTime use the set_clock_skew command.

7.3 Setting Port Output Delay

With the set_output_delay command you are able to specify output delays. An output delay
describes an external timing path from an output or inout port to an external register. To
describe this path correctly the maximum output delay value should be equal to the length of
the longest path to the register data pin, plus the setup time of the register. Also the minimum
output delay value should be equal to the length of the shortest path to the register data pin,
minus the hold time.

Example:

To set an output delay of 4.3 relative to the rising edge of clock PHI1 on port OUT1 (see
above, Figure 2-12):

set_output_delay 4.3 -clock PHI1 {OUT1}

Application Note
Constraining designs, Doc.-Nr. 1.0
14
NEC Electronics (Europe) GmbH

Use report_port -output_delay to show output delays associated with ports.

Please find more detailed information in the Synopsys User Manual for PrimeTime and
DesignTime .

8 Timing Exceptions

8.1 Setting False Paths

The set_false_path command defines logic paths that exist but cannot be sensitized. It is a
point-to-point timing exception command. PrimeTime excludes these paths from timing
analysis.
PrimeTime is able to detect paths that are not sensitizable automatically and can optionally
exclude those paths from timing reports. However, it is highly recommended to proof all
‘false_paths’carefully. An unintended path with the attribute ‘false_path’ will not listed in the
collection of timing violations. Consequently these paths will not be addressed during timing
optimization in DesignCompiler .
When you set a false path between unrelated clock domains, specify the clock names. This
method ends in a significant smaller database and this results in a faster runtime of the tool.
Do not specify the data and clock pin names.

8.2 Setting Multicycle Paths

Multicycle paths are paths which intentionally require more than one clock cycle to propagate.
This information can‘t be inferred by the timing analyzer, so it must be specified by the
designer so the analyzer can mark the path and correctly calculate the timing. A start point,
end point and/or through point is specified, along with the number of allowed clock cycles.
Before defining multicyclepathes it is quite important to understand how synopsys selects the
edge to calculate a setup or hold condition. Three cases can be distinguished:
Sending FF and receiving FF belong to the same clockgroup. In this case synopsys will take
next edge for setup check and the same edge for hold check.

setup

CLK

hold

Sending FF and receiving FF belong to different clockgroups which have the same period
In this case synopsys takes either B or C for setup check and A or B for hold check. Which
edge will be selected depends on the way the clock is defined. There are two ways to define a
shifted clock.

Application Note
Constraining designs, Doc.-Nr. 1.0
15
NEC Electronics (Europe) GmbH

A. Use the waveform option when creating the clock. In this case synopses will calculate
the setup condition between D and B and the hold condition between A and D.

B. Define CLK1 and CLK2 using the same waveform. Set an input delay on the clock-
root pin of CLK1. This delay will be added when calculating the clock-tree propagation
delay. In this case synopses will use the edge C for setup check and B for hold check.

The reason for this different behavior is, that synopses uses the waveform of the clock-root pin
to determine the edge which should be used for setup and hold check.

A B C
CLK1

CLK2
D

Sending FF and receiving FF belong to different clockgroups, which have different periods. In
this case synopsys identifies the edges which have the shortest distance. The picture below
shows an example for clock divider:

CLK1
setup hold

CLK2

If the behavior described above does not fit to the circuit it is possible to select a different edge
for setup and hold check. This is done by the following command:
set_multicycle_path path_multiplier [-from from_list] [-to to_list]
[-through through_list]
path_multiplier
Specifies the number of cycles that the data path must have relative to the clock before data is
required at the endpoint.
-from from_list | -to to_list
A list of clocks, ports, pins or cells to find path startpoints | endpoints.
-through through_list
A list of ports, pins or cells in the current design. Hierarchical cells are not allowed. For more
detailed informations please use the „Synopsys Online Documentation“.

Application Note
Constraining designs, Doc.-Nr. 1.0
16
NEC Electronics (Europe) GmbH

8.3 Analyzing Asynchronous Preset and Clear Timing Arcs

The timing analysis in PrimeTime and in DesignTime always refers to ‘timing paths’. The
startpoint of these paths can be primary inputs or sequential cells. The endpoints of such
paths are primary outputs or sequential cells. Per default a sequential cell is always a timing
endpoint, even if the path arrives at an asynchronous preset or reset pin. This behavior is ok,
when you a global set/reset circuitry for all sequential cells. If the asynchronous signals of
sequential cells are driven by a distributed logic, it is recommended, also to check the timing
paths through the asynchronous signals of sequential cells. You can analyze timing paths
through preset and clear arcs by setting the environment variable
timing_enable_preset_clear_arcs to true.

By default, PrimeTime always disables all preset and clear timing arcs.

8.4 Bidirectional Feedback Paths

PrimeTime automatically disables bidirectional feedback paths. No path segmentation is

required. Design Compiler provides these paths by default. To enable bidirectional feedback
paths in more than one cell in PrimeTime , set the
timing_disable_internal_inout_net_arcs variable to false.
To enable bidirectional feedback paths in only one cell in PrimeTime , set the
timing_disable_internal_inout_cell_paths variable to false.

8.5 Set_case_analysis

Case analysis is a way to specify a given mode of the design without altering the netlist
structure. You can specify for the current timing analysis session, that some signals are at a
constant value (1 or 0) or that only one type of transition (rising or falling) is considered. When
case analysis to a constant value is specified, the constant value is propagated through the
network as long at the constant value is a controlling value for the traversed logic. For
example, if you specify that one of the inputs of a NAND gate is a constant value 0, it is
propagated to the NAND output which is now considered at a logic constant 1. This
propagated constant value itself is propagated to all cells driven by this signal. In the event of
case analysis on transition, the given pin or port is only considered for timing analysis with the
specified transition. The other transition is disabled.
The command ‘set_case_analysis’ is very useful to analyze timings in certain functional
modes. Actually this command is available in Primetime only. For the same analysis in
DesignCompiler it is necessary to use various ‘set_false_path’commands.

8.6 Switch off clock_gating checks

It is possible to switch off the clock gating checks at all. The right variable to do that is

timing_disable_clock_gating_checks = "false"

This variable is used to switch off all clock gating checks in the design globally.

Application Note
Constraining designs, Doc.-Nr. 1.0
17