(https://www.micro-ip.com/index.

php)

IC Design (https://www.micro-ip.com/drchip.php?mode=2&cid=2)

Synthesis (https://www.micro-ip.com/drchip.php?mode=2&cid=3)

STA (https://www.micro-ip.com/drchip.php?mode=2&cid=16)
Synopsys(PT) (https://www.micro-ip.com/drchip.php?mode=2&cid=17)

set_clock_groups

NAME
set_clock_groups
Specifies clock groups that are mutually exclusive or asyn-
chronous with each other in a design so that the paths between
these clocks are not considered during the timing analysis.

SYNTAX
Boolean set_clock_groups
[-physically_exclusive | -logically_exclusive | -asynchronous]
[-allow_paths]
[-name name]
[-group clock_list]*

list clock_list

ARGUMENTS
Note: Options marked with asterisks (*) in the SYNTAX can be used more
than once in the same command.
-physically_exclusive
Specifies that the clock groups are physically exclusive with
each other. Physically exclusive clocks cannot co-exist in the
design physically. An example of this is multiple clocks that
are defined on the same source pin. The -physically_exclusive,
-logically_exclusive and -asynchronous options are mutually
exclusive; you must choose only one.

-logically_exclusive
Logically exclusive clocks do not have any functional paths
between them, but may have coupling interactions with each
other. An example of logically-exclusive clocks is multiple
clocks, which are selected by a MUX but can still interact
through coupling upstream of the MUX cell. The -physi-
cally_exclusive, -logically_exclusive and -asynchronous options
are mutually exclusive; you must choose only one.

-asynchronous
Specifies that the clock groups are asynchronous to each other.
Two clocks are asynchronous with respect to each other if they
have no phase relationship at all. Signal integrity analysis
uses an infinite arrival window on the aggressor unless all the
arrival windows on the victim net and the aggressor net are
defined by synchronous clocks. The -physically_exclusive, -log-
ically_exclusive and -asynchronous options are mutually exclu-
sive; you must choose only one.

-allow_paths
Enable the timing analysis between specified asynchronous clock
groups. The default behavior is to suppress timing paths
between asynchronous clocks. The -allow_paths option must be
used with -asynchronous option.

-name name
Specifies a name for the clock grouping to be created. Each
command should specify a unique name, which identifies the
exclusive or asynchronous relationship among specified clock
groups, and this name is used later on to easily remove the
clock grouping defined here. By default, the command creates a
unique name.
 -group clock_list
Specifies a list of clocks. You can use the -group option more
than once in a single command execution. Each -group iteration
specifies a group of clocks, which are exclusive or asynchronous
with the clocks in all other groups. If only one group is spec-
ified, it means that the clocks in that group are exclusive or
asynchronous with all other clocks in the design. Thus, a
default other group is created for this single group. Whenever
a new clock is created, it is automatically included in the
default exclusive or asynchronous group. Substitute the list
you want for clock_list.

DESCRIPTION
Specifies clock groups that are mutually exclusive or asynchronous with
each other in a design so that the paths between these clocks are not
considered during the timing analysis. This is similar to using the
set_false_path command. In addition, these relationships also imply
the type of crosstalk analysis which should be performed between the
clocks. A clock cannot be present in multiple groups during one
set_clock_groups command execution, but can be included in multiple
groups by executing multiple set_clock_groups commands. Clock rela-
tionships are only implied across the specified clock groups; no rela-
tionship is implied across clocks within a group.

For all three relationships, timing paths between the clocks are sup-
pressed. The relationships differ in how crosstalk is handled. If
clocks are asynchronous, the clocks are assumed to have an infinite
window relationship with each other. If clocks are physically exclu-
sive, only one clock can act as an aggressor or victim during crosstalk
analysis; interactions between the clocks will not be explored. If
clocks are logically exclusive, the crosstalk computation will be com-
puted normally (synchronously if the clocks are synchronous) even
though the timing paths between the clocks are not reported.

Multiple relationship types can exist between two clocks. When this
happens, the relationships obey the following precedence:

* physically exclusive (highest)

* asynchronous
* logically exclusive (lowest)
These precedence rules reflect the real physical behavior of the
resulting circuit. For example, if two clocks are asynchronous but
they are never simultaneously present, then no crosstalk should be com-
puted.

Note that the traditional set_false_path exception between clocks will

not result in infinite window crosstalk computation between two clocks.
If multiple clocks are asynchronous with each other, the asynchronous
relationship should be specified with set_clock_groups. Failure to
specify this relationship for asynchronous clocks could result in an
optimistic analysis!

A special -allow_paths modifier can be used with the -asynchronous

option. When used, the clocks are assumed to have an infinite window
relationship for crosstalk purposes, but timing paths between the
clocks will be treated normally. When using this option, paths between
the clock domains can be manually disabled using the set_false_path
command.

When a clock pair is defined such that it has false paths (using
either physically or logically exclusive or asynchronous) but subse-
quently modified to have -asynchronous -allow_paths, then this is an
error and the first definition holds. In the reverse situation, also
the redefinition to false paths from -allow-paths between the clock
pairs would also be an error. Please refer message UITE-457 and
UITE-458.

This command should be used to specify the relationships among clocks

before using the set_active_clocks command. You should not also set a
false path if you have already specified two clocks as exclusive or
asynchronous. An error message is issued if you attempt to set a false
path between two clocks which are already exclusive or asynchronous.
If a false path was previously set between two clocks when an exclusive
or asynchronous relationship is applied, the false path is overwritten
by the set_clock_groups command. Other exceptions are unaffected.

A clock relationship on a master clock will not automatically propagate

to any generated clocks. If the relationship should also apply to gen-
erated clocks, they should be explicitly included in the
set_clock_groups command.
 To undo the set_clock_groups command, use the remove_clock_groups com-
mand. To report the clock groups defined in a design, use the
report_clock command with the -groups option.

EXAMPLES
The following example defines two asynchronous clock domains.

pt_shell> set_clock_groups -asynchronous -name g1 -group CLK33 -group CLK50

The following example defines a clock named TESTCLK to be asynchronous

with all other clocks in the design:

pt_shell> set_clock_groups -asynchronous -group TESTCLK

The following example shows how to simultaneously analyze multiple

clocks per register without manually specifying false paths. Assume
two pairs of mutually-exclusive clocks that are multiplexed:

CLK1 and CLK2

CLK3 and CLK4.

If each pair of clocks is selected by a different signal, you must exe-

cute two set_clock_groups commands to specify two independent exclusiv-
ity relationships, one for each MUX selection signal:

pt_shell> set_clock_groups -physically_exclusive -group CLK1 -group CLK2

pt_shell> set_clock_groups -physically_exclusive -group CLK3 -group CLK4

If each pair of clocks is selected by a single MUX selection signal,

you would execute only one set_clock_groups command to simultaneously
analyze all four clocks.

pt_shell> set_clock_groups -physically_exclusive -group {CLK1 CLK3} -group {CLK2

CLK4}

In this case, we are not implying any type of relationship between

CLK1-CLK3 or CLK2-CLK4. For example, f CLK1 and CLK3 were also asyn-
chronous with each other, we would need to specify an additional rela-
tionship between them.
SEE ALSO
remove_clock_groups (2), report_clock (2), set_active_clocks (2),
set_false_path (2), create_clock (2), create_generated_clock (2).

擷發科技股份有限公司 Copyright © 2014 Microip Inc. All rights reserved.