xprop user guide

Guide to the VCS X-Propagation SimulatorE-2011.12June 2012

Comments?E-mail your comments about this manual to:[email protected].

2

Copyright Notice and Proprietary InformationCopyright 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 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 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 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 to determine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, 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, 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 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.

3Introduction

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

5Introduction

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.

7Introduction

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

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

9Usage

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

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


$set_x_prop("vmerge");


The previous example returns the following:

top.dut1: is Xprop active = 1






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= 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_itemmerge_function ::= tmerge | xmergemodule_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 | xpropOffmodule_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.

: "" ()

17

Usage

Where:

Name of the source file containing the statement.

Line number that corresponds to the start of the statement.

Either YES or NO, depending on whether the given 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 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 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: 7instrumented 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

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

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


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


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


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


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

always@(posedge clk, negedge rst)

if (! rst)

q

26


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

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

$xzcheck is not supported

28

Limitations

VCS Document Navigator

xprop user guide

Documents

registered trademarks

property of synopsys

design compiler

synthesis technology

hdl compiler

trademarks afgen

dc ultra

dc professional