Guide to the VCS

X-Propagation Simulator
E-2011.12
June 2012
Comments?
E-mail your comments about this manual to:
vcs_support@synopsys.com.
2
Copyright Notice and Proprietary Information
Copyright 2012 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.
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 readers 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.
Registered Trademarks ()
Synopsys, AEON, AMPS, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, CHIPit, CoMET,
Confirma, CODE V, Design Compiler, DesignWare, EMBED-IT!, Formality, Galaxy Custom Designer, Global Synthesis,
HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda, LightTools, MAST, METeor, ModelTools, NanoSim,
NOVeA, OpenVera, ORA, PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL, SNUG,
SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, the Synplicity logo, Synplify, Synplify Pro,
Synthesis Constraints Optimization Environment, TetraMAX, UMRBus, VCS, Vera, and YIELDirector are registered
trademarks of Synopsys, Inc.
Trademarks ()
AFGen, Apollo, ARC, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos,
CosmosLE, CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design
Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Eclypse, Encore,
EPIC, Galaxy, HANEX, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC
Prototyping System, HSIM
plus
, i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT,
JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk,
Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris,
Power Compiler, Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC,
System Compiler, System Designer, Taurus, TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet
Buffer are trademarks of Synopsys, Inc.
Service Marks (
sm
)
MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
Saber is a registered trademark of SabreMark Limited Partnership and is used under license.
All other product or company names may be trademarks of their respective owners.
3
Introduction
1
Introduction 1
The simulation semantics of conditional constructs that the standard
Verilog RTL prescribes for indeterminate 'X' control expressions are
insufficient to accurately model un-initialized registers and power-on
reset. Standard RTL simulation tends to ignore the uncertainty of
X-valued control signals As a result, simulation often fails to catch
X-related bugs. A better simulation behavior is to execute all
alternatives controlled by an X value, and then merge the results.
To expose X-related bugs, engineers have typically relied on
techniques such as gate-level simulation, or pseudo-exhaustive
2-state simulations. However, as designs grow in size, these
techniques become increasingly expensive and time consuming.
The VCS X-propagation simulator provides an effective simulation
model that allows X-related bugs to be exposed by normal RTL
simulation.
4
Introduction
The VCS X-propagation simulator provides two built-in merge
modes that you can choose at either compile-time or run-time:
xmerge mode. This mode is more pessimistic than a standard
gate-level simulation.
tmerge mode. This mode is closer to actual hardware behavior.
tmerge is the more commonly used mode.
In addition to the two merge modes, you can select at run-time the
vmerge mode to specify standard Verilog RTL semantics, which
effectively disables the new X-propagation semantics.
Guidelines to Consider When Starting with X-
propagation
If you enable X-propagation on an entire design, it is likely that some
part of your design will have a change in behavior resulting in
regression failures. It may take multiple iteration cycles to debug and
fix all of the design issues.
In this case, apply a divide-and-conquer approach:
Enable X-propagation on certain blocks at a time.
Find and fix any design or testbench issues.
Move on to the next block.
In this methodology, there is no guarantee that all blocks will run
without problems, or that the entire chip will be X-prop clean.
However, it is typically easier to debug the environment if only small
block is enabled for X-propagation simulation.
5
Introduction
One of the most common sources of simulation differences while
starting Xprop is incorrect initialization sequences. This is typically
caused by a reset/clock which transitions from 0/1 to X or vice-versa.
This works in normal legacy simulation, but not under Xprop
simulations.
If you have a flip-flop that is sensitive to the rising edge of a clock,
then in a normal simulation, a X->1 will cause the flop to clock in
the value of the input. However, under X-propagation, this will not
work, and the flop may go to an unknown value. You must ensure
that a clean clock line is run into the device to correctly clock in
values to the internal registers.
You can specify various mode behaviors using a configuration file.
You must take care in constructing the X-propagation configuration
file. The target device for using X-propagation technology is typically
synthesizable Verilog RTL code. In the configuration file, you can
specify the top level of your DUT, and enable X-prop on this instance
tree. If there are any non-synthesizable models under the DUT
instance, then you should ensure that these modules are excluded
from X-propagation simulation within your configuration file.
Debugging RTL-code is a fairly routine process today. There are
multiple debug tools available that do a reasonable job of this. It is
well known that debugging a simulation mismatch is an easier task
at the RTL level than at the gate-level, due to the fact that the
engineer is much closer to the actual functional intent of the circuit.
A typical debug process is as follows:
6
Introduction
Find a regression failure
Re-run with dumping enabled
Go to point of test failure (assertion, monitor,)
Backtrace mismatching signal to origin
Identify root cause of the problem.
There are other flows that engineers use to debug various types of
regression failures. One is to compare the dump file of the working
regression and the failing regression, searching for differences near
the point of failure.
Another common flow is to determine when did the regression
recently pass. Next, you would investigate all the checked in code to
determine which check-in caused the failure.
You should enable X-prop on code that is meant to be synthesized
into a gate-level representation. Any type of non-synthesizable or
testbench code should be excluded from a X-prop simulation. Once
X-prop is enabled, normal RTL debugging techniques can be used
to debug your test failures. However, there are caveats to this
statement. In general, when debugging a design, you should be
familiar with X-propagation semantics.
You should generally not compare wave files with and without
X-prop. This can lead to extraneous, and wasted debug cycles. For
example, it may take 10ms to reset a device in legacy mode. In X-
prop mode, because reset is unclean, it takes 100ms to reset the
device. If you compare the dump files between the two, then you will
notice that the two simulations are not cycle accurate with respect to
each other. The two simulations will not have similar traces.
7
Introduction
Note that most debug tools automatically trace back signal changes
across many logic levels to some origin that caused the signal
change. These debug tools are closely tied to Verilog behavior.
X-prop causes a change in how VCS updates signals. As a result, in
general, these debug tools may not function well. Some manual
intervention may be required if you use these types of debug tools.
The recommended debug methodology is to ensure that you have
enough assertions or testbench monitors in place. As a result, any
deviation from correct functionality would cause one of these
checkers to give a runtime error message. Once VCS issues the
messages, you should then backtrace to the origin of the faulty
signal.
8
Usage
2
Usage 2
The basic use model is to compile the design specifying the
X-propagation mode, and then simulate the resulting executable. To
enable X-propagation, specify the -xprop VCS option. For
example:
% vcs -xprop design.v
VCS compiles the specified files enabling X-propagation in the entire
design. By default, VCS will use the tmerge merge mode. However,
you can specify a different merge mode at either compile time or run-
time.
9
Usage
Compile-time Specification of X-propagation Merge
Mode
The merge mode you want to use may be explicitly specified in the
compiler command line. When the merge mode is specified in this
manner, the merge mode is fixed at compile time, and cannot be
changed at run time. For example:
% vcs -xprop=xmerge -sverilog
When the -xprop=xmerge option is specified, the entire design is
instrumented and xmerge merge mode is used at runtime. Consider
the following:
% vcs -xprop=tmerge -sverilog
When the -xprop=tmerge option is specified, the entire design is
instrumented and tmerge merge mode is used at runtime.
You may also use a configuration file, as in:
% vcs -xprop=xp_config_file -sverilog
The configuration file can indicate the portions of the design that are
to be instrumented by X-propagation. The file can also include a
merge mode specification. That is done by including one of the
following lines in the configuration file (xp_config_file):
merge = xmerge ;
or:
merge = tmerge ;
The VCS compiler instruments only the specified parts of the design
with the new X-propagation semantics.
10
Usage
Note: If you use a configuration file, then by default VCS performs no
instrumentation unless you specify hierarchies/modules with an
xpropOn attribute.
Enabling Automatic Flip-Flop Recognition
You can enable the automatic hardware inference of flip-flops with
the following compile-time switch:
-xprop=unifiedInference
This is required if you want a X-propagation simulation to correctly
simulate flip-flops that have a reset that toggles when X->0, where
0 is the active reset value.
When you specify this option, then VCS creates a
"unifiedInference.log" file to show what kind of flip-flops were
inferred.
Process-Based Exclusion
Sometimes it is necessary to disable X-propagation on part of a
module. The configuration file allows exclusion, but the granularity of
this exclusion is at the module level. If you need finer granularity,
then you can use the process-based exclusion method to disable
X-propagation on a specific process.
11
Usage
You can disable X-propagation on a process by using the xprop_off
attribute as shown below.
always (* xprop_off *) @( posedge clk ) begin
if (we) begin
q <= in;
end
end
Run-time Specification of X-propagation Merge Mode
To change the merge mode at runtime, you must not specify a merge
mode at compile time (as shown in the previous section). By default,
the design will be compiled to use tmerge mode.
You then select the run-time merge mode by invoking the
$set_x_prop system task as in:
$set_x_prop( "tmerge" );
$set_x_prop( "xmerge" );
$set_x_prop( "vmerge" );
You can use the previous example to select standard Verilog
behavior, which disables the new X-propagation semantics.
You may call the $set_x_prop system function as many times
as needed during a simulation run.
If you do not use $set_x_prop, then the simulation runs in tmerge
merge-mode.
12
Usage
Run-time Function to Query If X-propagation is Enabled
To query whether X-prop is enabled for a particular module instance,
you can use the $is_xprop_active system function. This
function returns '1' if the current instance has X-propagation
enabled. It also returns information on the merge type. For example:
$set_x_prop("tmerge");
$display( "%m: is Xprop active = %d",$is_xprop_active() );
$set_x_prop("xmerge");
$display( "%m: is Xprop active = %d",$is_xprop_active() );
$set_x_prop("vmerge");
$display( "%m: is Xprop active = %d",$is_xprop_active() );
The previous example returns the following:
top.dut1: is Xprop active = 1
top.dut1: is Xprop active = 1
top.dut1: is Xprop active = 0
top.dut2: is Xprop active = 0
top.dut2: is Xprop active = 0
top.dut2: is Xprop active = 0
This assumes that the instance top.dut1 has X-propagation
enabled.
13
Usage
X-propagation Configuration File
You use the X-propagation configuration file mainly to specify the
scope of X-propagation instrumentation. You may also use it to
specify a different merge mode. Synopsys recommends that you use
a configuration file.
The X-propagation configuration file allows you to change behavior
by specifying the design hierarchies or modules that are to be
excluded from (or included for) X-propagation instrumentation. You
specify which hierarchies/modules should be enabled for
X-propagation using the xpropOn attribute.
Important: If you use a configuration file, then the default is for
instrumentation to be off for the entire design.
The X-propagation configuration mechanism is specified using the
-xprop=<option> followed by the name of the X-propagation
configuration file. For example:
% vcs -xprop=xp_config cache.v alu.v
This command does the following:
Compiles the design using the files cache.v and alu.v.
Enables X-propagation.
Specifies VCS to use xp_config as the configuration file.
14
Usage
The X-propagation configuration file consists of a set of lines. Each
line can designate one the following:
A set of modules or a hierarchical sub-trees along with their
desired X-propagation behavior.
A compile-time merge mode specification.
X-Propagation Configuration File Syntax
Following is the BNF for the configuration file.
xprop_config_text ::= { xprop_config_item ; }
xprop_config_item ::=
merge = merge_function
| module_item
| instance_item
| tree_item
merge_function ::= tmerge | xmerge
module_item ::= module { module_identifier_list } {
xprop_mode }
tree_item ::= tree { module_identifier_list } { xprop_mode }
instance_item ::= instance { instance_path_list } {
xprop_mode }
xprop_mode ::= xpropOn | xpropOff
module_identifier_list ::= module_identifier { ,
module_identifier }
instance_path_list ::= instance_path { , instance_path }
instance_path ::= { instance_identifier . }
instance_identifier
15
Usage
Note:
A module_item rule specifies that the indicated Xprop mode is
to be applied to all modules in the list.
An instance_item rule specifies that the indicated Xprop mode
is to be applied to all instances in the list and recursively to all
their sub-instances.
A tree_item rule specifies that the indicated Xprop mode is to
be applied to all modules in the list and recursively to all their sub-
instances.
For example:
tree { bridge } { xpropOff } ;
instance { top.bridge.cpu } { xpropOn } ;
module { sram, cache } { xpropOff } ;
The first line specifies that the entire sub-tree under module bridge
is to be excluded from X-propagation. The second line designates
that the sub-tree under top.bridge.cpu is to be considered for
X-propagation. Finally, the third line specifies that all instances of
modules sram and cache are to be excluded from X-propagation.
The configuration file is processed in the order in which the entries
are listed; subsequent entries override any previously listed entries.
No instrumentation diagnostics will be generated for modules or sub-
trees that are excluded from X-propagation via the configuration file
mechanism.
16
Usage
If the merge mode is specified in the configuration file, then VCS
selects (and fixes) the merge mode at compile time. For example,
the following configuration line will compile the design with merge
mode xmerge (same as the -xprop=xmerge command line
option).
merge = xmerge ;
If the merge mode is specified multiple times, the last one overrides
all others.
Note: Behavior is currently undefined for multiple uses of the
-xprop switch. In the following command, the application of the
switch is undefined:
% vcs -xprop=xp_config_file1 -xprop=xmerge \
-xprop=xp_config_file2 -xprop=tmerge <>
You must ensure only one instance of the switch is used.
Compile Time Diagnostic Report
When you compile a design with X-propagation, VCS creates a
report showing all the statements considered for instrumentation,
and whether or not the statements were instrumented.
For statements that prevent instrumentation, the report includes the
reason for their rejection. The diagnostics are stored in an ASCII file
named xprop.log which has with the following format.
<filename>:<line_number> <instrumented> "<reason>"
(<primary_line>)
17
Usage
Where:
<filename>Name of the source file containing the statement.
<line_number>Line number that corresponds to the start of the
statement.
<instrumented>Either YES or NO, depending on whether the
given statement is instrumented for X-propagation or not,
respectively.
<reason>A description indicating the reason for not instrumenting.
This is only issued when the previous field is "NO".
<primary_line>The line number of the statement containing the
actual construct for not instrumenting. This is only issued when
the instrumented field is "NO".
VCS will generate one such diagnostic entry for each of the following
constructs considered:
if statement
case statement
Body of an edge triggered always block
The following is a snippet from an xprop.log file.
decode.v:3 YES
decode.v:7 NO "prevented by sub-statement" (12)
decode.v:16 NO "delay statement" (17)
decode.v:18 YES
decode.v:20 NO "a dynamic object" (22)
At the end of the report, the report includes a metric representing the
ratio between assignment statements considered for instrumentation
and assignment statements instrumented. The ratio of these two
18
Usage
numbers (instrumented /instrumentable) is a useful measure that
represents the ratio of X-prop instrumentation. That is, it is an
indication of what fraction of the design was instrumented for
X-propagation.
Following are the contents of another xprop.log.
test.v:31 YES
test.v:45 NO "a dynamic type expression" (48)
test.v:52 YES
==================================================
X P R O P S T A T I S T I C S
instrumentable assignments: 7
instrumented assignments: 5
instrumentation success rate: 71%
Note: VCS generates no instrumentation diagnostics or modules or
sub-trees that are excluded from X-propagation via the configuration
file mechanism.
$uniq_prior_checkoff/on Use Model Change
If you use the compile-time switch -xlrm uniq_prior_final,
then in order to disable runtime RT Warning messages, you should
use the assertion enable/disable system tasks, instead of the
uniq_prior_checkoff/on checks.
19
Usage
Time Zero Initialization
If you want to initialize a latch or flip-flop at time zero, then you may
find that the devices remain at "x", instead of being initialized to some
value. This is because at time=0, the always_latch and the
always_comb processes are executed. The clock will be at an "x",
causing the corruption.
Using -boundscheck to Catch Invalid Indices
When the VCS -boundscheck option is specified, the following four
types of assertions are enabled:
Write with indeterminate index (index containing X values)
Read with indeterminate index (index containing X values)
Write with out-of-bounds index
Read with out-of-bounds index
All these assertions may be controlled via the run-time
X-propagation assertion control system tasks. VCS provides four
system tasks to control the behavior and severity of X-propagation
assertions.
$xprop_assert_on(assertion_type)Enables the
specified assertion type.
$xprop_assert_off(assertion_type)Disables the
specified assertion type; stops checking the specified assertion
type until a subsequent $xprop_assert_on is issued with the
given assertion type.
20
Usage
$xprop_assert_fatal( assertion_type )Designates the
severity of the given assertion type to be a fatal error. When this
assertion triggers, the simulation terminates.
$xprop_assert_warn( assertion_type )Designates the
severity of the given assertion type to be a warning. When this
assertion is fired, the simulation continues execution.
These four system tasks affect all assertions of the given assertion
type globally: that is, all assertions of the given type throughout the
entire design.
21
Programming Guidelines
3
Programming Guidelines 3
The following sections provide you programming guidelines and
examples for using X-propagation.
X-Propagation on if Statement
X-Propagation affects the behavior of control logic. Shown below is
code for a simple if statement. This code represents a simple
multiplexor. Following the code is the truth table for the example
when the condition of the if statement is unknown.
always@*
if(s)
r = a;
else
r = b ;
22
Programming Guidelines
The first column shows the value of the condition to the if
statement when unknown. The second and third column shows their
respective values for a and b. The value of r is shown in columns
four, five, and six for different merge options.
V-merge, shown in the fourth column, always gives the same value
as signal b, as this is standard Verilog behavior for an if statement.
The fifth column shows T-merge. When the condition is unknown,
the values of 0, 1 are substituted for s. The if statement is
executed once with s=0, and once with s=1, and the value of r is
computed. If the values for r in each of the branches are the same,
then the merge value will be that value.
If the values for r in each of the branches are different, the merge
value will be X. As a result, when a and b are the same, T-merge will
give that value. If the value of a and b are different, then T-merge will
give an X.
The last column shows the value of r when the merge option used
is X-merge. The output is always an X, because whenever there is a
merge, then the resultant with be an X.
S A b V-merge T-merge X-merge
X 0 0 0 0 X
X 0 1 1 X X
X 1 0 0 X X
X 1 1 1 1 X
23
Programming Guidelines
X-Propagation on case Statements
Shown below is the code for a simple case statement. This code
represents a simple multiplexor. Following the code is the truth table
when the value of the case expression is unknown.
case (s)
1'b0: r = a;
1'b1: r = b;
endcase
Following is the truth table:
The first column shows the value of the condition to the case
statement which considered to be unknown. The second and third
columns show their respective values for a and b. The value of r is
shown in columns four, five, and six for different merge options.
V-merge, shown in the fourth column always gives the value of r
that was present before the case statement was executed. This is
standard Verilog behavior for a case statement.
The fifth column shows T-merge. When the condition is unknown,
the values of 0, 1 are substituted for s. The case statement is
executed once with s=0, and once with s=1, and the value of r is
computed. If the values for r in each of the branches are the same,
s A b V-merge T-merge X-merge
X 0 0 r(t-1) 0 X
X 0 1 r(t-1) X X
X 1 0 r(t-1) X X
X 1 1 r(t-1) 1 X
24
Programming Guidelines
then the merge value will be that value. If the values for r in each of
the branches are different, then the merge value will be X. As a
result, when a and b are the same, T-merge will give that value. If the
value of a and b are different, then T-merge will give an X.
In the last column, the value of r is shown when the merge option
you use is X-merge. The output is always an X, because whenever
there is a merge, the resultant with be an X.
X-Propagation on Edge Sensitive Process
Edge sensitivity expressions must be handled carefully under X-prop
semantics (for example, asynchronous flip-flops). In legacy Verilog,
a posedge expression will occur for the following transitions:
0 ->1
0 ->X
0 ->Z
X ->1
Z -> 1
Verilog will optimistically consider all of these transitions as if a rising
edge of the signal occurred, which is not necessarily true.
For example, let's consider the 0-to-X transition. X can represent
either a 0 or a 1, which means a rising transition may have
happened, or may not have happened. Both cases need to be
considered.
25
Programming Guidelines
The following code represents a simple D-flip flop, where there reset
is inactive.
always@(posedge clk, negedge rst)
if (! rst)
q <= 1'b0;
else
q <= d ;
Below is the truth table for all merge types. If there is a clean edge
(0 1), then the next value for the flop output will be the d input. If there
is an unclean edge, then the current value of the flop is merged with
the d input.
Following is the truth table for the D-flip flop.
Clk V-merge T-merge X-merge
0 -> 1 d d d
0 -> X d merge(d,q(t-1)) X
0 -> Z d merge(d,q(t-1)) X
X -> 1 d merge(d,q(t-1)) X
Z -> 1 d merge(d,q(t-1)) X
26
Programming Guidelines
X-Propagation on Latches
In Verilog, latches are implemented with an if statement that does
not have an else branch, as shown below.
always@(*)
if(g)
q <= d ;
Because of the missing branch, whenever the clock into the latch is
an X, this causes a merge of the current value of the latch with the
data input.
Following is the truth table for this situation.
The assertion types used by these system functions are shown in the
following table:
G d V-merge T-merge X-merge
X 0 q(t-1) merge(0,q(t-1)) X
X 1 q(t-1) merge(1,q(t-1)) X
assertion_type Description Default behavior
xindex-wr Write with indeterminate
index
Warning
xindex-rd Read with indeterminate
index
Warning
index-wr Write with out-of-bounds
index
Warning
index-rd Read with out-of-bounds
index
Warning
27
Limitations
4
Limitations 4
Xprop is not supported with the following VCS technologies:
Multi-core VCS
Limited Configuration File Support for Mixed-Language designs
$power
Code coverage (gives optimistic results)
Active drivers do not recognize Xprop as a potential driver
$xzcheck is not supported
28
Limitations