Xprop User Guide Oct 2012 (2)

5/26/2018 Xprop User Guide Oct 2012 (2)

1/28

Guide to the VCS

X-Propagation SimulatorE-2011.12

June 2012

Comments?

E-mail your comments about this manual to:

[email protected].


2/28

2

Copyright Notice and Proprietary InformationCopyright 2012 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietaryinformation that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement andmay 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 DocumentationThe 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 mustassign 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 StatementAll 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 todetermine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITHREGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY 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 registeredtrademarks 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, HSIMplus, 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 WorksheetBuffer 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/28

3

Introduction

1Introduction 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 catchX-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 simulationmodel that allows X-related bugs to be exposed by normal RTL

simulation.


4/28

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 standardgate-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

vmergemode 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/28

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 Xpropsimulations.

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/28

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/28

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, ingeneral, 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/28

8

Usage

2Usage 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 -xpropVCS option. Forexample:

% vcs -xprop design.v

VCS compiles the specified files enabling X-propagation in the entire

design. By default, VCS will use the tmergemerge mode. However,

you can specify a different merge mode at either compile time or run-

time.


9/28

9

Usage

Compile-time Specification of X-propagation MergeMode

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=xmergeoption is specified, the entire design isinstrumented and xmerge merge mode is used at runtime. Consider

the following:

% vcs -xprop=tmerge -sverilog

When the -xprop=tmergeoption is specified, the entire design isinstrumented and tmergemerge 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/28

10

Usage

Note: If you use a configuration file, then by default VCS performs no

instrumentation unless you specify hierarchies/modules with an

xpropOnattribute.

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 wereinferred.

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/28

11

Usage

You can disable X-propagation on a process by using the xprop_off

attributeas shown below.

always (* xprop_off *) @( posedge clk ) begin

if (we) begin

q


12/28

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. Thisfunction 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");


$set_x_prop("vmerge");


The previous example returns the following:

top.dut1: is Xprop active = 1






This assumes that the instance top.dut1has X-propagationenabled.


13/28

13

Usage

X-propagation Configuration File

You use the X-propagation configuration file mainly to specify thescope 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 xpropOnattribute.

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= followed by the name of the X-propagationconfiguration 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/28

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 theirdesired 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/28

15

Usage

Note:

A module_itemrule specifies that the indicated Xprop mode is

to be applied to all modules in the list.

Aninstance_item rule specifies that the indicated Xprop modeis to be applied to all instances in the list and recursively to all

their sub-instances.

A tree_itemrule specifies that the indicated Xprop mode is tobe 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.cpuis to be considered for

X-propagation. Finally, the third line specifies that all instances ofmodules sramand cacheare 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/28

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=xmergecommand lineoption).

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

-xpropswitch. 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.

: ""()


17/28

17

Usage

Where:

Name of the source file containing the statement.

Line number that corresponds to the start of thestatement.

Either YES or NO, depending on whether thegiven statement is instrumented for X-propagation or not,

respectively.

A description indicating the reason for not instrumenting.This is only issued when the previous field is "NO".

The line number of the statement containing theactual 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 alwaysblock

The following is a snippet from an xprop.logfile.

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/28

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 YEStest.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 Sinstrumentable assignments: 7

instrumented assignments: 5instrumentation 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/28

19

Usage

Time Zero Initialization

If you want to initialize a latch or flip-flop at time zero, then you mayfind 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 -boundscheckoption is specified, the following fourtypes 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 thespecified assertion type.

$xprop_assert_off(assertion_type)Disables thespecified assertion type; stops checking the specified assertion

type until a subsequent$xprop_assert_onis issued with thegiven assertion type.


20/28

20

Usage

$xprop_assert_fatal( assertion_type )Designates theseverity of the given assertion type to be a fatal error. When this

assertion triggers, the simulation terminates.

$xprop_assert_warn( assertion_type )Designates theseverity 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/28

21

Programming Guidelines

3Programming 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 simplemultiplexor. 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/28

22


The first column shows the value of the condition to theifstatement when unknown. The second and third column shows their

respective values for aand 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. Theif statement isexecuted once with s=0, and once with s=1, and the value of riscomputed. 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 mergevalue will be X. As a result, when aand bare the same, T-merge willgive that value. If the value of aand bare different, then T-merge willgive an X.

The last column shows the value of rwhen the merge option usedis 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/28

23


X-Propagation on case Statements

Shown below is the code for a simple casestatement. This coderepresents a simple multiplexor. Following the code is the truth table

when the value of the caseexpression 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 casestatement which considered to be unknown. The second and third

columns show their respective values for aand b. The value of r isshown in columns four, five, and six for different merge options.

V-merge, shown in the fourth column always gives the value of rthat was present before the case statement was executed. This is

standard Verilog behavior for a casestatement.

The fifth column shows T-merge. When the condition is unknown,the values of 0, 1 are substituted fors. The case statement isexecuted once with s=0, and once with s=1, and the value of riscomputed. 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/28

24


then the merge value will be that value. If the values for rin each ofthe branches are different, then the merge value will be X. As a

result, when aand bare the same, T-merge will give that value. If the

value of aand bare different, then T-merge will give an X.

In the last column, the value ofris shown when the merge optionyou 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/28

25


The following code represents a simple D-flip flop, where there reset

is inactive.

always@(posedge clk, negedge rst)

if (! rst)

q


26/28

26


X-Propagation on Latches

In Verilog, latches are implemented with an if statement that doesnot have an else branch, as shown below.

always@(*)

if(g)

q


27/28

27

Limitations

4Limitations 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

$xzcheckis not supported


28/28

28

Limitations

Documents

Xprop User Guide Oct 2012 (2)