VC SpyGlass Connectivity

VC SpyGlass®
Connectivity Checker Guide

Version U-2023.03, March 2023
Copyright Notice and Proprietary Information
 2023 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to
Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys,
Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure
to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to determine the
applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Software Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse and is
not responsible for such websites and their practices, including privacy practices, availability, and content.
www.synopsys.com
Synopsys Statement on Inclusivity and
Diversity
Synopsys is committed to creating an inclusive environment where every employee,
customer, and partner feels welcomed. We are reviewing and removing exclusionary
language from our products and supporting customer-facing collateral. Our effort also
includes internal initiatives to remove biased language from our engineering and
working environment, including terms that are embedded in our software and IPs. At
the same time, we are working to ensure that our web content and software
applications are usable to people of varying abilities. You may still find examples of non-
inclusive language in our software or documentation as our IPs implement industry-
standard specifications that are currently under review to remove exclusionary
language.
Contents .............
Preface..........................................................................................7
About This Book ...................................................................................... 7
Typographical Conventions ..................................................................... 8
Getting Started .............................................................................9

Licensing Requirements ..........................................................................9
Running Connectivity Checks...................................................................9
Connection Tags..........................................................................11
CONN_CHK_REQUIRE_VALUE : Ensure that the expected node value is
achieved......................................................................... 12
CONN_CHK_REQUIRE_PATH : Ensure that the paths between user-
specified nodes exist ........................................................ 15
CONN_CHK_ILLEGAL_VALUE : Reports nets with illegal node values... 19
CONN_CHK_ILLEGAL_PATH : Path between user-specified nodes should
not exist ......................................................................... 22
Constraints .................................................................................27
define_tag............................................................................................. 28
illegal_value.......................................................................................... 29
illegal_path ........................................................................................... 31
require_path ......................................................................................... 34
require_value........................................................................................ 38
v
Feedback Synopsys, Inc.
vi
Synopsys, Inc. Feedback
Preface
About This Book

The VC SpyGlass® Connectivity Checker Guide provides information about
the connection tags and constraints used to check the designs for Design-
For-Testability.
7
Preface
Typographical Conventions
Typographical Conventions
This document uses the following typographical conventions:
To indicate Convention Used

Program code OUT <= IN;
Object names OUT
Variables representing <sig-name>
objects names
Message Active low signal name '<sig-name>' must end
with _X.
Message location OUT <= IN;
Reworked example OUT_X <= IN;
with message removed
Important Information NOTE: This Tag...
The following table describes the syntax used in this document:

Syntax Description
[ ] (Square brackets) An optional entry
{ } (Curly braces) An entry that can be specified once or multiple
times
| (Vertical bar) A list of choices out of which you can choose
one
... (Horizontal Other options that you can specify
ellipsis)
8
Getting Started
Licensing Requirements
VC SpyGlass requires the VC-SG-ELITE licenses. Ensure that these
licenses are available before you run VC SpyGlass.
Running Connectivity Checks

Use the following TCL commands to perform the Connectivity checks in VC
SpyGlass:
#Performing Connectivity checks
#App var to enable Connectivity checks
set_app_var enable_connectivity true
set_app_var hierarchy_delimiter .
#Enabling tags
configure_tag -tag { CONN_CHK_REQUIRE_VALUE
CONN_CHK_REQUIRE_PATH CONN_CHK_ILLEGAL_VALUE
CONN_CHK_ILLEGAL_PATH } -enable -app Connectivity
set_app_var hierarchy_delimiter "."
9
Getting Started
analyze -format verilog test.v

elaborate top
require_value -name {"CGC::TM"} -value 1
require_path -from {"block::out*"} -to {"DFF::clk"}
require_path -from in_top3 -to M4.clk -through M1.inst2.CG -
path_type sensitized
illegal_path -from top.M1.I_MUX_a9.D0 -to "out1"
illegal_value -name {"CGC::TM"} -value 0_or_1
require_value -name M1.inst*.a2 -value 1
require_value -name in_top5 -value 1
#Running checks
check_connectivity
#Viewing Reports
report_violations -app {Connectivity} -verbose -file
report.txt
view_activity
10
Connection Tags
This section explains the following Connection tags available in VC

SpyGlass Lint:
 CONN_CHK_REQUIRE_VALUE
 CONN_CHK_REQUIRE_PATH
 CONN_CHK_ILLEGAL_VALUE
 CONN_CHK_ILLEGAL_PATH
11
Connection Tags
CONN_CHK_REQUIRE_VALUE
Ensure that the expected node value is achieved
When to Use
Use this tag to identify the nodes that do not achieve the expected
simulation value.
Description
The CONN_CHK_REQUIRE_VALUE tag generates the VC SpyGlass highlight
data for those nodes specified with require_value constraints that do not
achieve the specified simulation value when the specified tag condition is
simulated.
Expected values at arbitrary nodes and the applied values that should
cause or force the expected values are checked. This is useful for ensuring
that unit-level test requirements are satisfied at the SoC level.
Consider the following require_value constraint:
require_value
-tag <tagName> -name <nodeNames> -value <value>
The CONN_CHK_REQUIRE_VALUE tag generates the highlight data for
those nodes specified with the -name argument that do not achieve the
simulation value <value> when the conditions of <tagName> are
simulated.
Prerequisites
Specify the require_value constraint.
Default Weight
10
Language
Verilog, VHDL
Method
For each define_tag, simulate power, ground and all conditions defined for this
define_tag.
For each require_value with the current define_tag, check that the defined pin has the
defined value. Otherwise, report a message.
12
Connection Tags
Parameter(s)
None
Constraint(s)
 define_tag: Use this constraint to define a named condition for
application of certain stimulus at the top port or an internal node.
 require_value: Use this constraint to define a check that requires a logic
value to be established on a certain node when the circuit has been
simulated using the condition specified by the -tag argument.
Operating Mode
Define_tag
Messages and Suggested Fix

The following violation messages are displayed for the Conn_01 tag:
Message 1
[ERROR] Node <name> has value <value1>. (Required: <value2>)
under tag <tag-name>
Arguments
 Name of the node <name>
 Actual value <value1>
 Expected value <value2>
 Tag name <tag-name>
Potential Issues
A violation is reported due to incomplete or incorrect simulation condition
or incorrect design connectivity.
Consequences of Not Fixing
Not fixing the violation may result in unexpected code behavior.
How to Debug and Fix
View the Incremental Schematic for the violation message. The
Incremental Schematic highlights the node where the required simulation
mismatches the actual simulation.
13
Connection Tags
Message 2
[INFO] Node '<node-name>' has required value(<value>) under tag
'<tagName>'
Arguments
 Name of the node, <node-name>
 Simulation value, <value>
 Tag name, <tagName>
Potential Issues
This is an informational tag. Therefore, it does not have any related
potential issues.
This is an informational tag. Therefore, it does not have any implicit
impact.
View the Incremental Schematic of the violation message. The Incremental
Schematic displays the node where the required simulation matches the
actual simulation.
Severity
Error
14
Connection Tags
CONN_CHK_REQUIRE_PATH
Ensure that the paths between user-specified nodes exist
When to Use
Use this tag to identify the disjointed pair of user-specified nodes.
Description
The CONN_CHK_REQUIRE_PATH tag reports connection violations between
specified pair of nodes.
The CONN_CHK_REQUIRE_PATH tag checks either conditional or
unconditional paths between user-specified nodes.
While processing the require_path constraints, CONN_CHK_REQUIRE_PATH
tag checking depends on -path_type and simulation condition.
Specified field of require_path constraint Simulation condition

-tag <tag_name> tag_name
If none of the above specified Power ground
 If you specify the value of the -path_type argument as

sensitized, the CONN_CHK_REQUIRE_PATH tag performs the strict
functional checking. This ensures that the path is properly sensitized by
the specified simulation condition.
NOTE: Multiple-drivers create blockages only when the path_type is sensitized.
 If you specify the value of the -path_type argument as
sensitizable, the CONN_CHK_REQUIRE_PATH tag performs the
functional checking. This ensures that the path is properly sensitizable
and is not blocked by the simulation condition.
 If you specify the value of the -path_type argument as
buffered, the CONN_CHK_REQUIRE_PATH tag looks for strict
topological checking and checks for buffers and inverters only.
 If you do not specify the value of the -path_type argument, the
default value of the argument, that is, sensitizable is used.
SoC integration often requires that connections between various units
exist. This tag allows arbitrary from-to pin to be checked.
15
Connection Tags
The CONN_CHK_REQUIRE_PATH tag flags a violation if during traversal to

find a path between two nodes, a contentious net is found. This path is no
longer considered a correct path.
Prerequisites
Specify the require_path constraint.
Default Weight
10
Language
Verilog, VHDL
Parameter(s)
Constraint(s)
 require_path (mandatory): Use this constraint to define a connectivity
check for a path from a pin specified with the -from argument to a pin
specified with the -to argument.
 define_tag (optional): Use this constraint to define a named condition for
Operating Mode
Power Ground, Define_tag

Message 1
[ERROR] '<path_type>' path(s) not found from '<from_node_name>'
to '<to_node_count>' nodes under <simulation condition> within
'<sequential_depth>' sequential depth
Potential Issues
The violation message appears if no valid path exists between the user-
specified nodes.
Not fixing the violation may result in unsearchable expected path. This may
16
Connection Tags
impact the functionality of the design.

Message 2
[ERROR] '<path_type>' path(s) not found to '<to_node_name>'
from '<from_node_count>' nodes under <simulation condition>
within '<sequential_depth>' sequential depth
Potential Issues
specified nodes.
NOTE: This violation message is reported instead of Message 1, in case of '-from_one_of'
field specified in 'require_path' constraint.
Message 3
[ERROR] '<path_type>' path(s) not found from '<from_node_name>'
to '<to_node_count>' nodes within '<sequential_depth>'
sequential depth
Potential Issues
specified nodes.
NOTE: This violation message is reported instead of Message 1, when '-path_type' is
'buffered' in 'require_path' constraint.
17
Connection Tags
Severity
Error
18
Connection Tags
CONN_CHK_ILLEGAL_VALUE
Reports nets with illegal node values
When to Use
Use this tag to identify the nodes that have a user-specified value under
the specified simulation condition.
Description
The CONN_CHK_ILLEGAL_VALUE tag generates the SpyGlass Explorer
highlight data for those nodes specified with illegal_value constraints that
contain the illegal simulation value when the specified tag condition is
simulated.
Expected values at arbitrary nodes and the applied values that should
cause or force the expected values are checked. This is useful for ensuring
that unit-level test requirements are satisfied at the SoC level.
Consider the following illegal_value constraint:
illegal_value
-tag <tagName> -name <nodeNames> -value <value>
Prerequisites
Specify the illegal_value constraint.
Default Weight
10
Language
Verilog, VHDL
Parameter(s)
Constraint(s)
 define_tag: Use this constraint to define a named condition for
 illegal_value: Use this constraint to check for the presence of an illegal
value on a certain node when the circuit has been simulated using the
condition specified by the -tag argument.
19
Connection Tags
Operating Mode
Define_tag

The following violation messages are reported by the
CONN_CHK_ILLEGAL_VALUE tag:
Message 1
[ERROR] Node <name> has illegal value <value1>. under tag <tag-
name>
Arguments
 Name of the node <name>
 Illegal value <value1>
 Tag name <tag-name>
Potential Issues
A violation is reported due to incomplete or incorrect simulation condition
or incorrect design connectivity.
Not fixing the violation may result in unexpected code behavior.
View the Incremental Schematic for the violation message. The
Incremental Schematic highlights the node with the illegal value at the
simulation.
Message 2
[INFO] Node '<node_name>' has valid value '<current_value>
(illegal: <disallowed_value>)' under <mode>
Arguments
 Name of the design node which does not have the illegal value (check
PASSED), <node_name>
 Current value, <current_value>
 Disallowed value, <disallowed_value>
 Name of the 'mode' (simulation condition), <mode>
20
Connection Tags
Potential Issues
This is an informational message. Therefore, there are no potential issues
related to this message.
This is an informational message. Therefore, there are no consequences of
not fixing this message.
This is an informational message. Therefore, no debug or fix is required.
Example Code and/or Schematic

Example 1
Consider the following sample SGDC file describing the illegal_value
constraint description:
illegal_value -name top.op1 -value 1 -tag abc
Default Severity Label

Error
21
Connection Tags
CONN_CHK_ILLEGAL_PATH
Path between user-specified nodes should not exist
When to Use
Use this tag to ensure that the path between two nodes does not exist.
Description
The CONN_CHK_ILLEGAL_PATH tag reports a violation, if a path exists
between from and to nodes of the illegal_path constraint.
The type of path to be searched is determined by the -path_type
argument of the illegal_path constraint. This argument can take one
of the following values: buffered, sensitized, or sensitizable. By default,
sensitizable path is searched.
The tag also reports violation if an undesired path is found through non-X
nets.
Default Weight
10
Language
Verilog, VHDL
Parameter(s)
None
Constraint(s)
 illegal_path (mandatory): Use this constraint to define nodes between
which path should not exist.
 define_tag (optional): Use this constraint to define a named condition for
Operating Mode
Define_tag, Power Ground
22
Connection Tags

Message 1
[ERROR] '<path_type>' path found from '<from_node>' to
undesired node '<to_node>' in '<mode_name>'
Arguments
 Type of path found, <path_type>
 From node name, <from_node>
 To node name, <to_node>
 Simulation condition, <mode_name>
Potential Issues
The violation message is reported because a valid path exists from
<from_node> to <to_node>, which are specified using the illegal_path
constraint.
Not fixing this violation may impact the functionality of design.
View the incremental schematic of the violation message. It displays the
path specified in the violation message.
To fix the violation, verify the highlighted path. If the path is correct,
modify the corresponding illegal_path constraint. However, if the path is not
correct, specify any missing define_tag constraint or check the design.
Additional Information
The CONN_CHK_ILLEGAL_PATH tag also report following additional
information based on the inputs specified:
 If sequential depth is specified, the message reports the current
sequential depth of the reported path.
 If the one_of property of the illegal_path path constraint is used, the
message reports the message count for the respective constraint.
Message 2
[ERROR] <path_type>' path found to '<to_node>' from undesired
node '<from_node>' in '<mode_name>'
Arguments
23
Connection Tags
 Type of path found, <path_type>

 From node name, <from_node>
 To node name, <to_node>
 Simulation condition, <mode_name>
Potential Issues
The violation message is reported because a valid path exists to
<to_node> from <from_node>, which are specified using the
illegal_path constraint.
Message 3
[ERROR] <From | To>' node <node name> is connected to leaf
cell(s)
Arguments
 From / To node name, <node name>
Potential Issues
The violation message is reported because a from node was driving a leaf
cell or a to node was driven by a leaf cell. The violation message is
reported only for to or from nodes which were specified without any from
or to nodes, respectively, in the illegal_path constraint.
24
Connection Tags

Message 4
[INFO] '<passed_checks>' out of '<total_checks>' check(s)
passed
Potential Issues
Not Applicable.
Not Applicable.
Not Applicable.
Message 5
[INFO] Skipping check between nodes ‘<from_node>’ and
‘<to_node>’ (Reason: <reason-string>)
Arguments
 From node, <from_node>
 To node, <to_node>
 Reason for skipping the check, <reason>
Potential issues
This is an informational tag. Therefore there are no potential issues related
to this violation.
Consequences of not fixing
This is an informational tag. Therefore, there is no implicit impact of this
violation.
How to debug and fix
This is an informational tag. Therefore, no fix is required. However, you
may review the constraint specification.
Message 6
[INFO] '<passed_checks>' out of '<total_checks>' check(s)
passed (‘<skipped-checks>’ checks(s) skipped)
25
Connection Tags
Arguments
 Passed check count, <passed_checks>
 Total check count, <total_checks>
 Skipped check count, <skipped_checks>
Potential issues
This is an informational tag. Therefore there are no potential issues related
to this violation. Check between from and to points can be skipped.
Consequences of not fixing
This is an informational tag. Therefore, there is no implicit impact of this
violation.
How to debug and fix
This is an informational tag. Therefore, no fix is required. However, you
may review the constraint specification.
Example Code and/or Schematic

Example 2
Consider the following violation message reported by the
CONN_CHK_ILLEGAL_PATH tag:
'Sensitizable' path found to 'top.u_config_register.ff2_reg.D
(config_register:FLIP_FLOP_DATA)' from undesired node
'top.u_mem3.op (MEMORY_OUT) (in 2 sequential depth) (1 of 2)'
in 'Power-Ground mode'
The above violation message reports the following additional information:
 Current sequential depth, when you have specified the
-sequential_depth <n> argument for the input constraint.
 Message count (x of y) for the respective constraint, if source (FROM) or
destination (TO) use the ONE_OF property of the illegal_path constraint.
Severity
Error
26
Constraints
This section explains the following constraints:

 define_tag
 illegal_value
 illegal_path
 require_path
 require_value
27
Constraints
define_tag
define_tag
The define_tag constraint is used to define a named condition for
application of certain stimulus at the top port or an internal node. The
connectivity checks are made by applying one or more of the user-defined
conditions such that circuit can be simulated into the desired mode.
To use the define_tag constraint, provide an initial state of a design
To provide an initial state for a design, each register needs to be initialized
using the define_tag constraint. The following example initializes a
register foo of design unit top to the value 0:
define_tag –tag initState –name top.foo –value 0
The following example initializes a vector register foo[7:0] of design unit
top to the value 0:
define_tag –tag initState –name top.foo[7:0]
–value “0”
28
Constraints
illegal_value
illegal_value
Purpose
The illegal_value constraint checks for the presence of illegal value on a
certain node when the circuit has been simulated using the condition
specified by the -tag argument.
When illegal_value is used twice for the same node, VC SpyGlass
interprets as neither 0 nor 1.
Syntax
The syntax for the illegal_value constraint is as follows:
illegal_value
[-name <nodename>]
[-value <value> ]
[ –tag <condname> ]
Arguments
-name <nodename>
(Optional) The name can be a top-module port, or any internal net name,
or terminal name. More than one pin name can be specified, and it is
effectively read as a concise description of as many individual value
checks.
-value <value>
The value is a logic value string of 0, 1, X, Z, 1_or_0, and 0_or_1. A single-
bit value means check at end of complete simulation. The X value is
treated as do-not-compare. A multi-bit value means check on cycle-by-
cycle simulation basis.
-tag <condname>
(Optional) A condition previously defined by using the define_tag constraint.
It describes a simulation condition.
Note that only one condition name can be defined in a illegal_value
specification. However, simulation for a given condition name simulates all
29
Constraints
illegal_value
pin-value specifications simultaneously. The built-in power-ground

connections are also simulated in this process.
Examples
Consider the following examples:
Example1
illegal_value -name abc -value 1
Supported Tags
CONN_CHK_ILLEGAL_VALUE
30
Constraints
illegal_path
illegal_path
Purpose
The illegal_path constraint is used to define nodes between which path
should not exist.
Syntax
The syntax of the illegal_path constraint is as follows:
illegal_path
[-from <frompinlist> ]
[-from_one_of <fromoneof_pinlist> ]
[-to <topinlist> ]
[-to_one_of <tooneof_pinlist> ]
[-invert ]
[-noinvert ]
[-path_type <buffered | sensitized | sensitizable | direct
| topological>]
[-sequential_depth <value>]
Guidelines for Using Arguments

The following combination of arguments are not allowed for the illegal_path
constraint:
 The –from_one_of argument can not be used with the –to_one_of
argument
Arguments
-from <from_node_list>
(Optional) This is a list of top-module port names, internal net names, or
terminal names from which path should not exist to nodes specified
through <to node list>.
31
Constraints
illegal_path
-to <to_node_list>
(Optional) This is a list of top-module port names, internal net names, or
terminal names to which path should not exist from nodes specified
through <from node list>.
-sequential_depth <value>
Specifies the number of sequential elements between end points specified
on an illegal path. This means that the illegal_path check will go through
the specified number of sequential elements. You can specify an integer
value as an input to this argument.
It is recommended to use this argument when the path type is set to
sensitizable. For other path_types, that is, direct, buffered, and sensitized,
a sequential element is a stop-point. This is so because path through
sequential cell is neither buffered nor sensitized path.
-to_one_of <tooneof_pinlist>
(Optional) Specifies that no error message is reported, if there is at least
one success case among the specified nodes.
-tag <tag name>

(Optional) These arguments are used to specify simulation condition under
which path is searched between from nodes and to nodes. If none of them
are specified then path is searched after simulating all power-ground
connections. Please note that only one of these arguments can be used to
specify simulation condition in the illegal_path constraint.
<tag name> is a condition name that has been previously defined by using
the define_tag constraint.
-path_type <direct| buffered | sensitized | topological | sensitiz-

able>
The -path_type argument accepts only predefined list of values: direct,
buffered, sensitized, topological, and sensitizable. The default value of this
qualifier is sensitizable. This argument determines the type of path that is
searched between from and to nodes.
Supported Tags
CONN_CHK_ILLEGAL_PATH
32
Constraints
illegal_path
Examples
Consider the following schematic:
Now, consider the following constraint description:

illegal_path –from d1 –to bidi1 –path_type topological –
sequential_depth 1
For the above example, a topological path is traced through the flip-flop if
the sequential depth greater than 0 is specified, even if the tristate buffer
is disabled.
33
Constraints
require_path
require_path
Purpose
The require_path constraint checks for the existence of the path between
the specified nodes. However, the destination node may have paths
existing to other nodes.
NOTE: Buffers and inverters are single-input, single-output devices. Therefore, there is no
interference from external logic while tracing a net connectivity.
Syntax
The syntax for require_path constraint is as follows:
require_path
[-from <frompinlist> ]
[-from_one_of <fromoneof_pinlist> ]
[-to <topinlist> ]
[-to_one_of <tooneof_pinlist> ]
[-invert ]
[-noinvert ]
[-path_type <buffered | sensitized | sensitizable | direct
| topological>]
[-sequential_depth <value>]
[-tag ]
[-stop]
[-same_sequential_depth <value>]
Arguments
-tag <condname>
(Optional) Specifies a condition name that is previously defined by using
the define_tag constraint.
This condition describes the simulation of circuit into a desired state. Please
note only one condition name can be defined in a require_path
pin-value specification simultaneously, whether defined directly by pin-
value specification, or merge of other define_tag specifications. The built-
34
Constraints
require_path
in power-ground connections are also simulated in this process

automatically.
If the -tag argument is specified, an un-blocked path must exist when the
defined condition is simulated. If the -tag argument is not specified, the
require_path constraint defines a connectivity check that requires a net
connection to exist from pin(s) specified with the -from argument to pin(s)
specified with the -to argument. A net connection means a net connection
across hierarchical boundaries between the specified start point and end-
point(s) and may only contain buffers or inverters.
-from <frompinlist>, -to <topinlist>

These are the start-point and end-point nodes, respectively, in a circuit (as
controlled by effective current_design specification) for which a path is
searched after the circuit has been simulated by LE into the desired state
(with the -tag argument specified) or a net connection is to be checked
(without the -tag argument specified).
Either of these can be a list of top-module port names, internal net names,
or terminal names. It is effectively read as a concise description of
connectivity check from the each node in the <frompinlist> list to
each node in the <topinlist> list.
-from_one_of <fromoneof_pinlist>
-to_one_of <tooneof_pinlist>
-invert | -noinvert
(Optional) These additional qualifiers mean that check is performed to
check a positive polarity or negative polarity path between the two nodes.
If neither of these is specified, polarity is not relevant for such paths.
-path_type
The -path_type argument accepts only the following predefined list of
values: buffered, sensitized, sensitizable, direct, and
35
Constraints
require_path
topological. The default value of this qualifier is sensitizable.
-sequential_depth <value>
Specifies the number of sequential elements between end points specified
on a success path. This means that the require_path check will go through
the specified number of sequential elements. You can specify an integer
value as an input to this argument.
-stop <stop_point_list>
(Optional) Specifies the stop-point list. The name can be a top-module
port, internal net name, terminal name or instance (cell) name.
-same_sequential_depth
(Optional) Specify this argument to perform same sequential depth checks
across all paths, that is, balanced path check. By default, sequential depth
check limit is 10, which can be modified by additionally specifying the “–
sequential_depth” argument.
This argument checks for only the connected nodes (depth should be
same) when one_of fields is used. If all the nodes are unconnected, it does
not perform the same_sequential_depth check and an error is flagged.
Also, for every constraint using the same_sequential_depth field, the
expected depth remains the same (irrespective of the starting-point and
traversal direction).
NOTE: The ‘from’ and ‘to’ sets must be flop-terminals, otherwise “require_path” check will
fail.
Examples
Consider the following schematic:
36
Constraints
require_path
Now, consider the following constraint description:

require_path –from d1 –to bidi1 –path_type topological –
sequential_depth 1
For the above example, a topological path is traced through the flip-flop if
the sequential depth greater than 0 is specified, even if the tristate buffer
is disabled.
Supported Tags
CONN_CHK_REQUIRE_PATH
37
Constraints
require_value
require_value
Purpose
The require_value constraint defines a check that requires a logic value
to be established on a certain node when the circuit has been simulated
using the condition specified by the -tag argument.
The require_value constraint has two optional fields: -allowInversion
and matchNBits.
When require_value is used twice for the same node, VC SpyGlass checks
twice on the net per the specified value.
Syntax
The syntax for require_value constraint is as follows:
require_value
[-name <nodename>]
[-value <value> ]
[ –tag <condname>
Arguments
-name <nodename>
(Optional) The name can be a top-module port, or any internal net name,
or terminal name. More than one pin name can be specified, and it is
effectively read as a concise description of as many individual value
checks.
NOTE: Specify either -name or -type argument.
-value <value>
The value is a logic value string of 0, 1, X, Z, 1_or_0, and 0_or_1. A single-
bit value means check at end of complete simulation. The X value is
treated as do-not-compare. A multi-bit value means check on cycle-by-
cycle simulation basis. For specification of a vector value, SGDC multi-bit
specification format (same as used for the test_mode constraint) should be
used.
38
Constraints
require_value
You can specify repeat sequences for the require_value constraint.

For fields that require repeat sequence, you can specify the values as
<I*S>. Here, S is any string that does not contain the <, >, and *
characters. However, S can contain another <I*S> expression. I is an
integer that is always interpreted as a decimal value. The expression
<I*S> means that the sequence S will be repeated I number of times.
-tag <condname>
(Optional) A condition previously defined by using the define_tag constraint.
It describes a simulation condition.
Note that only one condition name can be defined in a require_value
pin-value specifications simultaneously. The built-in power-ground
connections are also simulated in this process.
Supported Tags
CONN_CHK_REQUIRE_VALUE
39
Constraints
require_value
40

VC SpyGlass Connectivity

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

VC SpyGlass Connectivity

Uploaded by

Copyright:

Available Formats

VC SpyGlass®

Connectivity Checker Guide

Getting Started .............................................................................9

About This Book

To indicate Convention Used

The following table describes the syntax used in this document:

Running Connectivity Checks

analyze -format verilog test.v

This section explains the following Connection tags available in VC

Messages and Suggested Fix

Specified field of require_path constraint Simulation condition

 If you specify the value of the -path_type argument as

The CONN_CHK_REQUIRE_PATH tag flags a violation if during traversal to

Messages and Suggested Fix

impact the functionality of the design.

Messages and Suggested Fix

Example Code and/or Schematic

Default Severity Label

Messages and Suggested Fix

 Type of path found, <path_type>

modify the corresponding illegal_path constraint. However, if the path is not

Example Code and/or Schematic

This section explains the following constraints:

pin-value specifications simultaneously. The built-in power-ground

Guidelines for Using Arguments

-tag <tag name>

-path_type <direct| buffered | sensitized | topological | sensitiz-

Now, consider the following constraint description:

in power-ground connections are also simulated in this process

-from <frompinlist>, -to <topinlist>

topological. The default value of this qualifier is sensitizable.

Now, consider the following constraint description:

You can specify repeat sequences for the require_value constraint.

You might also like