0% found this document useful (0 votes)
2K views6 pages

An CDC False Path

The cdc_false_path constraint allows you to specify false paths so that the Clock_sync01 and Clock_sync02 rules do not consider clock crossings along these paths. The -from, -to, and -through arguments are as follows: Argument -from Allowed Object Types A top-level port or a net connected to the output pin of a source flip-flop, latch, or blackbox Parent design unit (submodule

Uploaded by

MukeshPanda
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2K views6 pages

An CDC False Path

The cdc_false_path constraint allows you to specify false paths so that the Clock_sync01 and Clock_sync02 rules do not consider clock crossings along these paths. The -from, -to, and -through arguments are as follows: Argument -from Allowed Object Types A top-level port or a net connected to the output pin of a source flip-flop, latch, or blackbox Parent design unit (submodule

Uploaded by

MukeshPanda
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

SpyGlass® Application Notes

Using the cdc_false_path Constraint


Introduction
This application note describes the use model of the cdc_false_path
constraint in the SpyGlass® Clock-Reset solution.
The cdc_false_path constraint is used by the following rules:
Clock_sync01 Clock_sync02 Clock_sync03a
Clock_sync03b Clock_sync08 Clock_sync08a
Clock_sync09 Ac_cdc01a Ac_cdc01b
Ac_cdc01c Ac_cdc04a Ac_cdc04b
Ac_cdc08 Ac_crossing01 Ac_glitch01
Ac_glitch02 Ac_handshake01 Ac_handshake02
Propagate_Clocks

Syntax
The cdc_false_path constraint allows you to specify false paths so that
the Clock_sync01 and Clock_sync02 rules do not consider clock crossings
along these paths.
Use the cdc_false_path constraint as follows to specify the false paths:
current_design <du-name>
cdc_false_path
[ -from <obj1-name> ]
[ -to <obj2-name> ]
[ -through <obj3-name> ]

Where:
<du-name> is the module name (for Verilog designs) or the design unit name
in <entity-name> or <entity-name>.<arch-name> format (for VHDL

©Copyright 2001-2010 Atrenta, Inc. All rights reserved. 1


Using the cdc_false_path Constraint

designs).
The types of objects that can be specified with the -from, -to, and -through are
as follows:

Argument Allowed Object Types


-from • A top-level port or a net connected to the output pin of a source flip-
flop, latch, or blackbox
• Parent design unit (submodule) name containing the source flip-flop,
latch, or blackbox
• Port of a design unit (submodule) name when the port is connected
to the output pin or clock pin of a source flip-flop, latch, or blackbox
• A top-level port or a net connected to the clock pin of a source flip-
flop or latch
• User-specified clock nets (using the clock constraint)
• Auto-inferred clock sources (when the
use_inferred_clocks rule parameter is set)
-to • A top-level port or a net connected to the input pin or output pin of a
destination flip-flop, latch, or blackbox
• Parent design unit (submodule) name containing the destination flip-
flop, latch, or blackbox
• Port of a design unit (submodule) name when the port is connected
to the input pin, output pin, or clock pin of a destination flip-flop,
latch, or blackbox
• A top-level port or a net connected to the clock pin of a destination
flip-flop or latch
• User-specified clock nets (using the clock constraint)
• Auto-inferred clock sources (when the
use_inferred_clocks rule parameter is set)
-through • Any intermediate net in the crossing path
• Parent design unit (submodule) name containing any portion of the
crossing path
• Port of a design unit (submodule) name when the port is connected
to any intermediate net in the crossing path

2 July 2010 Version 4.4.0


Using the cdc_false_path Constraint

You must specify at least one of the -from, -to, and -through arguments.

Specifying Object Names


Specify net names as hierarchical names with respect to the top (top name is
optional). For example, top.U1.net1 or U1.net1.
Specify design units (submodules) as simple design unit names. For example,
myDU1.
Specify top-level port names as simple names. For example, in1.
Specify port of a design unit (submodule) as <du-name>/<port-name> or <du-
name>.<port-name>. You should not specify instance names or top-level
design unit name.

Wild Card Support


You can specify the object names using the * (match none, one, or more) and ?
(match none or one) wildcards.
When you specify the * wildcard, SpyGlass performs maximal matching. For
example, top.*.n1 matches top.n1, top.U1.n1, top.U1.U2.n1 and
so on.
You cannot specify wildcards with escaped names directly. It can be done by
replacing escape character (\) with wildcard character (*).
For example, for source flop outputs top.\rdPtr1 and top.\rdPtr2,
you cannot specify the constraint as shown below:
cdc_false_path -from "top.\rdPtr*”
Instead, you should specify it as:
cdc_false_path -from "top.*rdPtr*”
In case of array of instances in the design, escaped character gets appended as
part of the hierarchy name. Therefore, wildcard in such names should also be
specified as mentioned above.
For example, if a design, top, has an array of instances, U_INST[1:10] and
n1 is the net inside the module of these instances. In this case, SpyGlass
generates the following nets:
top.\U_INST[1].n1
top.\U_INST[2].n1

Version 4.4.0 July 2010 3


Using the cdc_false_path Constraint


Now, to declare cdc_false_path for net n1 inside any of these instances, you
cannot specify the name as top.\U_INST[*].n1. Instead, you should
specify this as shown below:
cdc_false_path -to "top.*U_INST*.n1"

Vector Name Support


You can specify vector object names also as simple object names, object names
with width specification, part-select, or bit-select.
You must use the Verilog bus-width specification format for specifying the
vector object names even for VHDL designs. For example,
in1(7 downto 0) must be specified as in1[7:0] or in1[0:7].
Similarly, a part-select should be written as say in1[6:3] or in1[3:6]. A
bit-select should be written as say in1[4].
You can also use wildcards in vector names. in1[*] matches any bit of in1.
The bit-width specification using wildcards for part-select is assumed to be
Higher bit first. Thus, the order of bits is important. in1[*:3] matches
in1[7:3]. in1[3:*] matches in1[3:0]. in1[0:*] does not match
anything!

Scope of False Paths


When you specify a clock name (hierarchical net name) with the -from or
-to argument should be a hierarchical net name. Then, the applicable paths
are paths originating from or terminating at flip-flops triggered by the specified
clock.
When a master design unit is specified with the -from or -to arguments,
then the applicable paths are paths originating from or terminating at all flip-
flops in all instances of the specified design unit. When you specify a master
design unit name with the -through argument, then the applicable paths are
all paths passing through all instances of the specified design unit.
When you specify a flip-flop output net (hierarchical net name) with the
-from or -to arguments, then the applicable paths are paths originating from
or terminating at the corresponding flip-flop.
When you specify a pin name (of a master design unit) (in <du-name>/

4 July 2010 Version 4.4.0


Using the cdc_false_path Constraint

<pin-name> format) with the -from or -to arguments, then the applicable
paths are paths originating from or terminating at all flip-flops connected to the
specified pin in all instances of the corresponding master design unit. When
you specify a pin name (of a master design unit) with the -through
argument, then the applicable paths are all paths passing through the specified
pin in all instances of the corresponding master design unit.
When you specify an internal net (hierarchical net name) with the -through
argument, then the applicable paths are paths containing the specified net.
Some examples of the cdc_false_path constraint are as follows:
cdc_false_path -from clk1 -to top.lower.q
The above specification suppresses all paths originating from flip-flops
triggered by clock clk1 and terminating at flip-flop top.lower.q.
cdc_false_path -through LOWER/out1
The above specification suppresses all paths passing through pin out1 of all
instances of master design unit LOWER.

Sanity Checking
The following sanity checking rules have been provided:

Rule Checks...
SGDC_cdc_false_path01 Existence of object specified with the -from argument (without
wildcards)
SGDC_cdc_false_path02 Existence of object specified with the -to argument (without
wildcards)
SGDC_cdc_false_path03 Existence of object specified with the -through argument
(without wildcards)
SGDC_cdc_false_path04 Existence of object specified with the -from/-to/-
through arguments (with wildcards)
FalsePathSetup Flags when a cdc_false_path constraint specification
does not waive any clock crossing

Special Cases: Merged Clocks


When more than one clock is reaching the clock pin of a flip-flop or latch,

Version 4.4.0 July 2010 5


Using the cdc_false_path Constraint

these clocks are called merged clocks.


To waive clock crossing involving a flip-flop or latch triggered by merged
clocks, you can specify the names of all clocks in the merged set with the
-from argument or the -to argument as a space-separated list as in the
following example:
cdc_false_path -from clk1 clk2 ...
If there are merged clocks involved in a clock crossing, you must specify all
clocks in the merged set for the clock crossing to be waived based on the
clocks. Thus, the clock crossing involving merged clocks clk1 and clk2 will
not be waived if one of the clocks is not specified.
You cannot specify multiple objects that are not merged clocks. Such
specification will not match any clock crossing and the FalsePathSetup rule
will flags a message. For example, the following specification is invalid:
cdc_false_path ... -to top.U1.Q clk2

Special Cases: Impact of one_cross_per_dest rule parameter


Setting the one_cross_per_dest rule parameter to yes (default value)
results in only the first found clock crossing of a destination object to be
reported.
If you set a valid cdc_false_path constraint on this first found clock
crossing, then the next found clock crossing for the same destination object is
reported. For example, there are three clock crossings between sources s1, s2,
and s3 and the destination d1 and these clock crossings are found as say,
s1->d1, s2->d1, and s3->d1. Normally, the crossing s1->d1 will be
reported. If you set a valid cdc_false_path constraint on this path, the
second found crossing s2->d1 will be reported:
cdc_false_path -from s1 -to d1
If you have only specified the -to argument (without -from argument) in a
valid cdc_false_path constraint, all clock crossing involving the
destination object are waived.

End of the Document

6 July 2010 Version 4.4.0

You might also like