SN About This Release PDF

About This Specman
Elite Release
Specman Elite 4.3.4
Legal Notice
Copyright © 1998-2004 Verisity Design, Inc. All rights reserved.
Trademarks
Verisity, the Verisity logo, eAnalyzer, eCelerator, eRM, Invisible Specman, LicenseE, Pure
IP, Specman, Specman Elite, SpeXsim, SpeXtreme, SureCov, SureLint, SureSolve, sVM,
Verification Advisor, Verification Alliance, Verification Vault, Verification Viewport,
Visualization Toolkit, vManager, vPlan, Xbench, Xchange, Xcite, Xoc, Xpert, Xsim, and
Xtreme are either trademarks or registered trademarks of Verisity Design, Inc. in the
United States and/or other jurisdictions. All other trademarks are the exclusive property of
their respective owners.
Confidentiality Notice
Verisity confidential, do not distribute. The contents of this document constitute valuable
proprietary and confidential property of Verisity Design, Inc. No part of this information
product may be reproduced, transmitted, or translated in any form or by any means,
electronic, mechanical, manual, optical, or otherwise without prior written permission
from Verisity Design, Inc.
Information in this product is subject to change without notice and does not represent a
commitment on the part of Verisity. The information contained herein is the proprietary
and confidential information of Verisity or its licensors, and is supplied subject to, and may
be used only by Verisity’s customers in accordance with, a written agreement between
Verisity and its customers. Except as may be explicitly set forth in such agreement,
Verisity does not make, and expressly disclaims, any representations or warranties as to the
completeness, accuracy, or usefulness of the information contained in this document.
Verisity does not warrant that use of such information will not infringe any third party
rights, nor does Verisity assume any liability for damages or costs of any kind that may
result from use of such information.
Restricted Rights Legend

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in
subparagraphs (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013.
Destination Control Statement

All technical data contained in this product 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.
Contents
1 New Features in Version 4.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

1.1 Documentation Reorganization to Support SpeXsim . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.1.1 New Help Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.1.2 New Document: Specman Elite Integrator’s Guide . . . . . . . . . . . . . . . . . . . . 1-3
1.1.3 Updates to the Specman Reference Manuals to Support SpeXsim . . . . . . . . . 1-3
1.2 Updated Path to the Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.3 New configuration simulation Category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.4 FCS for Method Ports and SystemC Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
1.4.1 New Method Port Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
1.5 ASCII Format for Support Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
1.6 sn_which.sh Now Documented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
1.7 4.3.4 Deprecation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
1.7.1 New 4.3.4 Deprecated Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
1.7.2 Severity Changes for Existing Deprecation Categories . . . . . . . . . . . . . . . . . . 1-6
1.7.3 specsim Command Replaced by specrun Command . . . . . . . . . . . . . . . . . . . . 1-7
1.8 Updates to Supported Simulators and Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . . 1-7

2.1 New Memory Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.2 Deprecation of Soft Binding for Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.3 Forcing VHDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.4 License Required for NC-SystemC Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.5 Updates for Supported Simulators and Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
About This Specman Elite Release iii

Contents

3.1 Bit Slice Access and Force/Release for Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Generation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.2.1 New Configuration Flag for Controlling Direction of Constraints on List Items .
3-2
3.2.2 New Search Available for Finding Specific Generation Steps . . . . . . . . . . . . 3-3
3.2.3 Updated Syntax for Generation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.2.4 Shortened Generation Error IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
3.3 New Configuration Option for Reporting Coverage Buckets . . . . . . . . . . . . . . . . . . . . 3-4
3.4 New show patches -long Provides Details for All Patches . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.5 Change in Default Severity for eRM Package Warnings . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.6 Change in Behavior for config print line_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.7 Enhanced Online Search Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.8 Updates to Supported Platforms and Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

4.1 Updates for 4.3.1 Beta Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1.1 New Support for “in” Method Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.1.2 New Visual Toolbox Methods for Adding Secondary Toolbars . . . . . . . . . . . 4-2
4.2 Support for Instantiating the “specman” Module in a Verilog DUT . . . . . . . . . . . . . . . 4-2
4.3 Struct Syntax Updates Resulting from Keyword Deprecation . . . . . . . . . . . . . . . . . . . . 4-3
4.4 Documentation Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
4.4.1 Waveform Viewer Documentation Enhancement . . . . . . . . . . . . . . . . . . . . . . 4-4
4.4.2 Clarification of per-instance Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
4.4.3 Hierarchy for PDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
4.4.4 Java Navigation for Verisity Help on Windows XP . . . . . . . . . . . . . . . . . . . . 4-5
5 New Features in Version 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

5.1 New GUI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.2 New Data Browser Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.3 New Language Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.4 Production Release of Beta Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
5.4.1 Static Analysis on Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.5 New Platforms and Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.5.1 Support for LDV 5.0 and 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.5.2 Support for the SimVision Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
iv About This Specman Elite Release

Contents
6 Overview of the 4.3 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

6.1 Preparing for 4.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.2 Installing eRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.2.1 Loading the Core eRM Package on Top of Specman Elite . . . . . . . . . . . . . . . 6-2
6.2.2 Compiling the Core eRM Package on Top of Specman Elite as User Code . . 6-3
6.3 Upgrading to 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
7 The Deprecation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

7.1 Understanding the Deprecation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.2 Deprecation for Syntactic Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.3 Deprecation for Semantic Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
7.4 Deprecation Recommendation for eVC Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
8 Deprecation and Backward Compatibility for this Release . . . . . .8-1

8.1 Deprecation and Backward Compatibility in the Current Release . . . . . . . . . . . . . . . . . 8-2
8.1.1 Access Violation for Bit Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.1.2 Use of keep {…} Constraint Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
8.1.3 Access Violation for List Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
8.1.4 Use of Specman Elite Reserved Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
8.1.5 Setting the Verilog Timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
8.1.6 Constraining the hdl_path() of sys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
8.1.7 Extending a TCM using a Different Sampling Event . . . . . . . . . . . . . . . . . . 8-20
8.1.8 Use of the back33 additional_eval Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21
8.1.9 Use of the back33 no_reorder Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-23
8.1.10 Reserved Type Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
8.1.11 Access Violation for List Slice of Unbounded Integer . . . . . . . . . . . . . . . . . 8-25
8.1.12 Restrictions on the Creation of Unit Instances . . . . . . . . . . . . . . . . . . . . . . . . 8-26
8.1.13 Deprecated Wave Configuration Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.1.14 References to When Subtypes of Structs with Like Children . . . . . . . . . . . . 8-30
8.2 Upgrading from Version 3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
8.2.1 Using the Compatibility Warning Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34
8.2.2 Setting Compatibility Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
8.2.2.1 Setting Backward Compatibility from Specview . . . . . . . . . . . . . . 8-36
8.2.2.2 Setting Backward Compatibility from the Specman Elite Installation
Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
8.2.2.3 Back33 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
About This Specman Elite Release v

Contents
8.3 Version 3.3 Backward Compatibility Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39

8.3.1 Language Bugs or Undocumented Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
8.3.1.1 old_struct_member_under_when . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
8.3.1.2 old_method_extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43
8.3.1.3 tick_notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
8.3.1.4 list_assign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
8.3.1.5 disable_illegal_ignore_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
8.3.2 Performance Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-54
8.3.2.1 Restriction on Complex Temporal Expressions . . . . . . . . . . . . . . . 8-54
8.3.2.2 Restrictions on Temporal Expressions with consume() . . . . . . . . . 8-55
8.3.2.3 disable_otf_gc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
8.3.3 Usability Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-57
8.3.3.1 cover_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-58
8.3.3.2 disable_cover_events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-59
8.3.3.3 tree_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60
8.3.3.4 no_gen_in_write_stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-61
8.3.3.5 use_trace_gen_33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
8.4 Upgrading from Version 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63
8.5 Documentation for Fully Deprecated or Outdated Features . . . . . . . . . . . . . . . . . . . . . 8-64
9 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

9.1 Language Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.1.1 Macros Defining Macros Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.1.2 Extending TCMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
9.1.3 Save and Restore Crash on Deeply Nested Structs . . . . . . . . . . . . . . . . . . . . . 9-3
9.1.4 Parse Limit on Bit Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
9.1.5 Return from is first Not Recognized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
9.1.6 Gnu C Compiler (GCC) and Long Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
9.1.7 collect -reload Does Not Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
9.1.8 deep_compare_physical() Incorrectly Flags Subtypes as Non-identical . . . . . 9-5
9.2 Coverage Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
9.2.1 Coverage for Long Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
9.2.2 Coverage for like Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.3 Generation Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.3.1 Parameters Passed by Reference to TCMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.3.2 as_a() in Constraints Is Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
9.3.3 Complex Constraints on List Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
vi About This Specman Elite Release

Contents
9.3.4 Multiple List-in-List Constraints on the Same List . . . . . . . . . . . . . . . . . . . . 9-10

9.3.5 or Constraint Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.6 Generation of Long Integers Can Consume More Memory Than Expected . 9-13
9.4 Temporal Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.4.1 Temporal Evaluator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.4.2 Premature Evaluation of Expressions under not . . . . . . . . . . . . . . . . . . . . . . 9-14
9.4.3 change, fall, rise, true Behave Differently . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.4.4 Multiple Callbacks in Same Time Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.4.5 on Methods Before Event Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.4.6 Temporals in Variable Structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
9.4.7 VHDL Variables in @sim Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
9.4.8 Compound Temporal Expressions with @sim . . . . . . . . . . . . . . . . . . . . . . . . 9-17
9.5 TCM Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
9.5.1 try Action Does Not Work in TCMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
9.5.2 Debugger Might Not Stop when Exiting a Called TCM . . . . . . . . . . . . . . . . 9-19
9.5.3 Fork Branches and State Machine Transitions . . . . . . . . . . . . . . . . . . . . . . . . 9-19
9.5.4 stop_run() Does Not Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
9.6 eRM Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
9.6.1 Running Old Specman Elite Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
9.6.2 Specman Elite Backward Compatibility Flags . . . . . . . . . . . . . . . . . . . . . . . . 9-21
9.6.3 Encrypted Code and the e Source Code Debugger . . . . . . . . . . . . . . . . . . . . 9-22
9.6.4 Mixing load and test Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
9.6.5 Using in_sequence() and in_unit() in Complex Constraints . . . . . . . . . . . . . 9-23
9.6.6 Using Nested Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
9.7 Simulator Interface Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
9.7.1 Force/Release Limitation on ModelSim 5.7 . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
9.7.2 Integration of Specman Elite and Cadence LDV 5.X Fails on HP-UX . . . . . 9-25
9.7.3 No Support for NC SystemC as Top Module in Mixed Environment . . . . . . 9-25
9.7.4 Verilog-XL Limitation: Failure After Forcing a Verilog Register from e . . . 9-26
9.7.5 NC Verilog Limitation: Wrong Sampling of Verilog Registers . . . . . . . . . . 9-26
9.7.6 Force/Release Actions in e with NC VHDL 5.x Behave Inconsistently . . . . 9-27
9.7.7 NC VHDL LImitation: No Update of Windows at Prompt . . . . . . . . . . . . . . 9-27
9.7.8 NC VHDL LImitation: VHDL Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
9.7.9 ModelSim and Specman Elite Exit Code for License Failures . . . . . . . . . . . 9-28
9.7.10 SpeedSim Limitation: Verilog Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
9.7.11 SpeedSim Limitation: Verilog Tasks and Functions . . . . . . . . . . . . . . . . . . . 9-29
About This Specman Elite Release vii

Contents
9.7.12
SpeedSim Limitation: Forced Driving of Verilog Signals . . . . . . . . . . . . . . . 9-29
9.7.13
SpeedSim Limitation: Ungraceful Exit from Simulator . . . . . . . . . . . . . . . . 9-30
9.7.14
SpeedSim Limitation: Specview Windows Not Updated . . . . . . . . . . . . . . . 9-30
9.7.15
Null Simulator Limitation: Sampling HDL-Style Variables . . . . . . . . . . . . . 9-30
9.7.16
Null Simulator Limitation: Unit Relative Paths and Full HDL Paths . . . . . . 9-31
9.7.17
Null Simulator Limitation: X/Z Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31
9.7.18
Null Simulator Limitation: Read/Write Race Conditions . . . . . . . . . . . . . . . 9-31
9.7.19
Time Literals Do Not Propagate into the Verilog Stub File . . . . . . . . . . . . . 9-32
9.7.20
Cannot Set Callback on Expanded Verilog Net . . . . . . . . . . . . . . . . . . . . . . . 9-33
9.7.21
Lists of Unit Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
9.7.22
Escaped Verilog Identifier Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
9.7.23
Wrong Sampling in Mixed Verilog/VHDL Environment . . . . . . . . . . . . . . . 9-35
9.7.24
trace on special event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
9.7.25
Verisity Adapters Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
9.7.25.1 Port Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
9.7.25.2 ‘test” in Pre-commands Fails for NCSIM Mixed Verilog/VHDL . . 9-39
9.7.26 ESI Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
9.7.26.1 Development of Proprietary Adapters . . . . . . . . . . . . . . . . . . . . . . . 9-39
9.8 Debugger Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40
9.8.1 finish Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
9.8.2 Abort Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
9.8.3 Calling Methods of the Current Struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
9.8.4 Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
9.8.5 Debugging TCMs That Return a Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
9.8.6 on event Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
9.9 Data Browser Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
9.9.1 list_from Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-44
9.9.2 raw_print Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-44
9.9.3 Refreshing the Window During Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 9-44
9.9.4 Problem Displaying Methods in the Data Browser . . . . . . . . . . . . . . . . . . . . 9-45
9.9.5 do_print() Ignored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-45
9.10 GUI Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
9.10.1 Common Desktop Environment (CDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
9.10.2 Solaris Patches Required for Running Java . . . . . . . . . . . . . . . . . . . . . . . . . . 9-46
9.10.3 Specview and Exceed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-47
9.11 Help Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-51
viii About This Specman Elite Release

Contents
9.11.1 Help or Apropos Fails for Certain Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52

9.11.2 Viewing Help in a Rational ClearCase Environment . . . . . . . . . . . . . . . . . . . 9-52
9.11.3 Broken Hyperlinks in About This Specman Elite Release . . . . . . . . . . . . . . . 9-53
9.12 Waveform Viewer Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53
9.12.1 Detection of Loops in TCMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-53
9.12.2 Cannot Trace like Inherited Instance Content . . . . . . . . . . . . . . . . . . . . . . . . 9-54
9.12.3 MTI ModelSim: Indication for Event Occurrence . . . . . . . . . . . . . . . . . . . . . 9-54
9.12.4 MTI ModelSim: String Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-54
9.12.5 MTI ModelSim: GUI Locks and No Automatic Refresh . . . . . . . . . . . . . . . . 9-55
9.12.6 Synopsys VirSim: Event Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-55
9.12.7 DAI Signalscan: Refreshing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-56
9.13 CVL Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-56
9.13.1 CVL Method and CVL Call Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-56
9.13.2 CVL Method and CVL Call Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
9.14 OS Platform Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
9.14.1 AIX Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
9.14.2 Visual Toolkit Applications on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-58
9.14.3 Specman Elite CPU Profiler on Linux in Multi-Thread Environment . . . . . 9-58
9.14.4 Static Linking with NC Verilog on Red Hat 7.2 . . . . . . . . . . . . . . . . . . . . . . 9-59
9.15 Miscellaneous Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59
9.15.1 collect Command Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59
9.15.2 Specview Hanging during Simulator Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60
9.15.3 Size of File Names and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60
9.15.4 Config Memory Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-61
9.15.5 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-61
10 Supported Platforms and Third-Party Tools . . . . . . . . . . . . . . . . .10-1

10.1 Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
10.2 Supported Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
10.3 Supported Waveform Viewers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
10.4 Other Supported Third Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
About This Specman Elite Release ix

Contents
x About This Specman Elite Release

1 New Features in Version 4.3.4
Specman Elite version 4.3.4 is being released in conjunction with Verisity’s new simulator offering,
SpeXsim.
This chapter describes the 4.3.4 release. It contains the following sections:
• “Documentation Reorganization to Support SpeXsim” on page 1-2

• “Updated Path to the Online Help” on page 1-4
• “New configuration simulation Category” on page 1-4
• “FCS for Method Ports and SystemC Integration” on page 1-4
• “ASCII Format for Support Requests” on page 1-5
• “sn_which.sh Now Documented” on page 1-5
• “4.3.4 Deprecation Updates” on page 1-6
• “Updates to Supported Simulators and Third-Party Tools” on page 1-7
Additional Information
• For additional information about the 4.3.4 release, please see:
$SPECMAN_HOME/docs/release_notes.txt
• For information about the defects fixed in the 4.3.4 release, please see:
$SPECMAN_HOME/docs/fixed_defects.txt
About This Specman Elite Release 1-1

New Features in Version 4.3.4
Documentation Reorganization to Support SpeXsim
1.1 Documentation Reorganization to Support

SpeXsim
The Specman documentation has been reorganized and expanded to serve the needs of both SpeXsim
users and the users of other, third-party simulators.
The following sections describe the new documentation reorganization:
• “New Help Organization” on page 1-2

• “New Document: Specman Elite Integrator’s Guide” on page 1-3
• “Updates to the Specman Reference Manuals to Support SpeXsim” on page 1-3
1.1.1 New Help Organization

As of 4.3.4, the Specman documentation has been divided into two main groupings:
• Specman Core Technologies: documentation that is relevant for the users of all simulators, including
SpeXsim
• Specman Elite / Third Party Simulators: documentation that is specific to the use of the Specman
Elite tool, including with third-party simulators
The table of contents for the Specman online Help is now as follows:
Specman Core Technologies
Usage and Concepts Guide for e Testbenches

e Language Reference
Specman Command Reference
Generation Guide
Specman Beta Features
Specman Elite / Third Party Simulators
Specman Elite Integrator’s Guide (see “New Document: Specman Elite Integrator’s Guide” on page
1-3
SSpecman Elite Installation Guide (provided only with the Specman Elite product)
About This Specman Elite Release (provided only with the Specman Elite product)
e Reuse Methodology (eRM) Developer Manual
Verification Advisor
1-2 About This Specman Elite Release

New Document: Specman Elite Integrator’s Guide
Tip If you use the online Search as your primary method for accessing the documentation, you
probably will not notice much difference in the documentation. Search engine functions have not
changed with this release.
1.1.2 New Document: Specman Elite Integrator’s Guide

The chapters “Compiling and Linking” and “Running Specman Elite”, which appeared in the Usage and
Concepts Guide in previous releases, have been reorganized into a new manual for use with the Specman
Elite product, Specman Elite Integrator’s Guide. This new manual contains a separate chapter for each
of the external simulators supported by Specman Elite.
In addition, the Specman Elite Integrator’s Guide contains information about accessing HDL objects
from within Specman Elite, using the SystemC integration with Specman Elite, using waveform viewers
with Specman Elite, and other topics specific to the Specman Elite tool.
See Also
• “Specman Elite Integrator’s Guide”
1.1.3 Updates to the Specman Reference Manuals to

Support SpeXsim
The Specman Command Reference and the e Language Reference have been updated to include
examples, references, and new material that is relevant to the introduction of SpeXsim with 4.3.4.
In particular, the documentation for the following commands has been expanded to serve the needs of
both SpeXsim users and the users of other, third-party simulators.
• sn_compile.sh
• write stubs
• Waveform-related commands
See Also
• sn_compile.sh on page 2-12 in the Specman Command Reference
• write stubs on page 13-7 in the Specman Command Reference
• Chapter 14 “Waveform Related Commands” in the Specman Command Reference

Updated Path to the Online Help
1.2 Updated Path to the Online Help

The name of the directory that contains the HTML online help has changed from “SpecmanDocs” to
“online_help”.
Thus, the general path to the Help launcher file is as follows:

…docs/online_help/VerisityHelp.htm
Note that the name of the launcher file, “VerisityHelp.htm”, has not changed.
Tip If you rely on bookmarks to access the online Help, be sure to bookmark the correct path for 4.3.4.
Remember that you can also launch the online HTML help with the following commands:
• When using SpeXsim: sxbuild -docs

• When using Specman Elite: sn_help.sh
1.3 New configuration simulation Category

The new configuration category simulation is introduced with version 4.3.4. The configure simulation
command sets simulation related configuration options. The options available for use with configure
simulation are:
• compatible_vhdl_at_x_nc—(NC VHDL and NC SIM only) ensures an evaluation of @x that

is compatible with other VHDL simulators.
• compatible_vhdl_int_to_std_mti—(ModelSim only) ensures assignment of non-zero
integers to a one-bit std_logic VHDL objects that is compatible with other VHDL simulators.
• enable_vhdl_time_mti—(ModelSim only) ensures that vhdl time statements are taken into
effect (not ignored) when Specman is linked with ModelSim.
See Also
• “configure simulationc” on page 6-54 in the Specman Command Reference
• “show configure simulation” on page 6-57 in the Specman Command Reference
1.4 FCS for Method Ports and SystemC Integration

As of 4.3.4, method ports and the Specman Elite integration with SystemC are no longer beta features,
but rather are full production features.

New Method Port Attribute
The documentation for method ports has been folded into the chapter on ports in e Language
Reference.The documentation for SystemC integration now appears as a chapter in Specman Elite
Integrator’s Guide.
See Also
• Chapter 6 “e Ports” in the e Language Reference
• Chapter 12 “SystemC Specman Elite Integration” in the Specman Elite Integrator’s Guide
1.4.1 New Method Port Attribute

The new method_port attribute static_sensitivity() lets you use an external out method port to call a
time-consuming SystemC function from e code.
See Also
• “Using Static Sensitivity Events” on page 12-30 in Specman Elite Integrator’s Guide
1.5 ASCII Format for Support Requests

Starting with the 4.3.4 release, you can generate a support request in ASCII format, rather than using the
GUI Support button. This ability is provided via two new configuration options, open_support_page
and support_info_file, and a new command, write support info.
See Also
• write support info on page 22-28 in Specman Command Reference
• configure misc on page 6-33 in Specman Command Reference
1.6 sn_which.sh Now Documented

Documentation for the sn_which.sh shell script has been added to Specman Command Reference.
sn_which.sh returns the absolute pathname of the specified file or directory.
See Also
• sn_which.sh on page 2-30 in Specman Command Reference

4.3.4 Deprecation Updates
1.7 4.3.4 Deprecation Updates

This section contains the following:
• “New 4.3.4 Deprecated Features” on page 1-6

• “Severity Changes for Existing Deprecation Categories” on page 1-6
• “specsim Command Replaced by specrun Command” on page 1-7
1.7.1 New 4.3.4 Deprecated Features

Table 8-1 on page 8-2 in About This Specman Elite Release documents the deprecated features
associated with the following new notification IDs:
• DEPR_AT_X_NCVHDL
• DEPR_BACK33_METHOD_EXTENSION
• DEPR_BACK33_WHEN_STRUCT_MEMBER
• DEPR_FORBIDDEN_ACTION_IN_SEQ_BLOCK
• WARN_VHDL_TIME_MODELSIM_IGNORED
See Also
• “Deprecation and Backward Compatibility in the Current Release” on page 8-2 in About This Specman
Elite Release
1.7.2 Severity Changes for Existing Deprecation Categories

The default severity level for the following deprecation notification IDs has changed from IGNORE to
WARNING:
• DEPR_CONFIG_CATEGORY_MEMORY
• DEPR_CONFIG_COLLECT_ALL
• DEPR_KEEP_SOFT_BIND
• DEPR_SN_VERILOG_TIME_SCALE_INCOMPAT
• DEPR_WAVE_REGISTER_STRUCTS
• DEPR_WHEN_AFTER_LIKE

specsim Command Replaced by specrun Command
See Also
Elite Release
1.7.3 specsim Command Replaced by specrun Command

The specsim command has been replaced with the specrun command as of the 4.3.4 release. The reason
for this change is to avoid confusion with the spexsim command.
The specsim command continues to be fully supported in 4.3.4, and thus you can continue to use it.
When you do so, however, Specman Elite will display a message asking you to use specrun instead.
See Also
• “specrun” on page 2-4 in the Specman Command Reference
Elite Release
1.8 Updates to Supported Simulators and

Third-Party Tools
The 4.3.4 release provides support for:
• SpeXsim 4.3.4
• VCS 7.1
• NC Simulator on IUS5.3
• Cadence SimVision on IUS5.3

Updates to Supported Simulators and Third-Party Tools

This chapter describes the 4.3.3 release. It contains the following sections:
• “New Memory Configuration Options” on page 2-1

• “Deprecation of Soft Binding for Ports” on page 2-2
• “Forcing VHDL Objects” on page 2-2
• “License Required for NC-SystemC Adapter” on page 2-2
• “Updates for Supported Simulators and Platforms” on page 2-3
$SPECMAN_HOME/docs/release_notes.txt.
$SPECMAN_HOME/docs/fixed_defects.txt.
2.1 New Memory Configuration Options

Release 4.3.3 provides several new config memory options to use to help debug memory-related
problems. The new options are:
• check_consistency—Triggers a heap consistency check. (This replaces the config debug

-check_consistency_all option.)
• show_mem_raw—Executes the show memory -raw command before each garbage collection.
(This replaces the config debug -show_mem option.)
• print_process_size—Displays process size metrics.

Deprecation of Soft Binding for Ports
• debug_thread_leak—Searches for threads owned by structs that are connected only to the scheduler
and causes their memory to be collected during garbage collection.
To support backward compatibility, the config debug options are translated into the appropriate config
memory commands.
See Also
• configure memory on page 6-26 in Specman Command Reference
• “Troubleshooting Specman Memory Management” on page 8-4 in Usage and Concepts Guide for e
Testbenches
2.2 Deprecation of Soft Binding for Ports

Currently, if you enter port constraints using keep soft bind(), the constraints are automatically and
silently converted to hard constraints.
As of 4.3.3, the keep soft bind() syntax is being deprecated, with a default severity level of IGNORE.
When fully deprecated, the use of keep soft bind() will not be allowed.
2.3 Forcing VHDL Objects

Specman Elite VHDL adapters do not discard regular assignments after a force action.If there are
multiple assignments to a VHDL object from e via tick access notation, every new (not necessarily
forced) assignment overrides the previous one. Some proprietary VHDL adapters, however, ignore
assignments executed after force by default.
The new global method set_assign_after_force_compatible() lets you change the default behavior of
such proprietary VHDL adaptors to be compatible with the default Specman Elite behavior.
See Also
• force on page 17-53 in e Language Reference
2.4 License Required for NC-SystemC Adapter

Starting with the 4.3.3 release, use of the NC-SystemC adapter requires an ncsysc_specman license
feature.
Note If you need help getting your Verisity license file or have questions regarding the Verisity license,
please email licenses@verisity.com.

Updates for Supported Simulators and Platforms
2.5 Updates for Supported Simulators and

Platforms
• Support for MTI version 5.8—The 4.3.3 release supports MTI (ModelSim) version 5.8.
• Red Hat 7.2 and Cadence NC Verilog—Specman Elite cannot be statically linked with NC Verilog
on RedHat 7.2. For more information, see “Static Linking with NC Verilog on Red Hat 7.2” on page 9-59.

Updates for Supported Simulators and Platforms

This chapter describes the new features in the 4.3.2 release. It contains the following sections:
• “Bit Slice Access and Force/Release for Ports” on page 3-1

• “Generation Updates” on page 3-2
• “New Configuration Option for Reporting Coverage Buckets” on page 3-4
• “New show patches -long Provides Details for All Patches” on page 3-5
• “Change in Default Severity for eRM Package Warnings” on page 3-5
• “Change in Behavior for config print line_size” on page 3-6
• “Enhanced Online Search Available” on page 3-6
• “Updates to Supported Platforms and Simulators” on page 3-7
3.1 Bit Slice Access and Force/Release for Ports

Specman Elite 4.3.1 and 4.3.2 provide support for writing a value to a bit slice of a simple port. In
previous versions, only reading a bit slice of a port was supported. In addition, you can force and release
simple ports or bit slices of simple ports. The new constructs include:

Generation Updates
• port$[:]—Read or write a value to a bit or a bit slice of a simple port

• force port$—Force a value to a simple port
• release port—Remove a force port$ action from a port
• force port$[:]—Force a value to a bit or a bit slice of a simple port
• put_mvl_to_bit_slice()—Write mvl data to a bit slice of a port
• force_mvl_to_bit_slice()—Force mvl data to a bit slice of a port
See Also
For more information, see the following sections in the e Language Reference:
• port$[ : ] on page 6-43

• force port$ on page 6-47
• release port on page 6-49
• force port$[ : ] on page 6-50
• put_mvl_to_bit_slice() on page 6-100
• force_mvl_to_bit_slice() on page 6-101
3.2 Generation Updates

This section contains the following:
• “New Configuration Flag for Controlling Direction of Constraints on List Items” on page 3-2
• “New Search Available for Finding Specific Generation Steps” on page 3-3
• “Updated Syntax for Generation Commands” on page 3-4
• “Shortened Generation Error IDs” on page 3-4
3.2.1 New Configuration Flag for Controlling Direction of

Constraints on List Items
Previous to Specman Elite version 4.2, constraints on list items were treated as unidirectional
constraints. As of Specman Elite 4.2, such constraints were treated as bidirectional.

New Search Available for Finding Specific Generation Steps
If you are upgrading from a pre-4.2 version of Specman Elite version to 4.2 or later and your code
requires the pre-4.2 behavior—or if you are using an eVC that requires the pre-4.2 behavior—you now
can set a new generation configuration option to ensure that constraints on lists are unidirectional, rather
than bidirectional.
The new option is -list_constraint_is_bidir, and its default value is TRUE, which means that all
constraints on list items are treated as bidirectional. You set it to FALSE to ensure the pre-4.2 behavior.
Note that -list_constraint_is_bidir must be TRUE to enable binding of lists of ports.
The -list_constraint_is_bidir option is effective only during parsing. If your design contains a mixture
of code that requires the old behavior and the new behavior, you can change the value of this flag as
appropriate before loading each module in your design. (You can also edit your existing code to avoid
the problem, as described in “Backwards Compatibility for List Item Constraints” on page 11-13 in the e
Language Reference.)
See Also
• “configure gen” on page 6-17 in the Specman Command Reference
• “Constraining List Size” on page 11-11 in the e Language Reference
3.2.2 New Search Available for Finding Specific Generation

Steps
Version 4.3.2 provides a new search utility that appears on both the Run-Time Generation Debugger and
the Static Analysis Generation Debugger. The new utility lets you search on a specific string that is used
in the code for one of the currently visible (expanded) generation steps. When you enter the search
string, the Debugger finds the line of code for the first step that includes the search string and highlights
it in the Source File pane.
This new feature enables you to find interesting steps in the step tree more quickly when you know
specific strings of code used in the interesting steps.
See Also
• “Using the Run-Time Generation Debugger” on page 5-16 in the Usage and Concepts Guide for e
Testbenches
• “Using the Static Analysis Generation Debugger” on page 5-35 in the Usage and Concepts Guide for
e Testbenches

Updated Syntax for Generation Commands
3.2.3 Updated Syntax for Generation Commands

The collect generation command syntax has been expanded. The new syntax is:
col[lect] gen[eration] [-all | -help | -off]
Where -all and -help are new options as of version 4.3.2:
• The new -all option collects all generation information and is equivalent to the existing -collect_all
option for the configure gen command.
• The new -help option displays information about the collect gen options.
See Also
• collect gen on page 7-1 in the Specman Command Reference
• configure gen on page 6-17 in the Specman Command Reference
3.2.4 Shortened Generation Error IDs

Previous to 4.3.2, several generation error IDs were unsearchable in the online help.
As of 4.3.2, these IDs have been shortened so that they are searchable in the online help:
• ERR_GEN_PARSE_NON_SIMPLE_PATH_IN_FOREACH is now
ERR_GEN_PARSE_NON_SIMPLE_PATH_FOREACH.
• ERR_GEN_PARSE_NON_SIMPLE_PERMUTATION_PATH is now
ERR_GEN_PARSE_NON_SIMPLE_PERM_PATH.
See Also
• Appendix B “Generation Errors” in the Usage and Concepts Guide for e Testbenches
3.3 New Configuration Option for Reporting

Coverage Buckets
Version 4.3.2 provides the new option -space for the show cover command. This new option reports the
number of legal buckets defined for each coverage item reported versus the number of buckets defined
for the item if the illegal and ignore options did not apply (the valid number of buckets versus the actual
physical number of buckets for the item).

New show patches -long Provides Details for All Patches
See Also
• show cover on page 10-6 in the Specman Command Reference.
• “Using show cover -space To Show the Effect of the illegal/ignore Options” on page 7-13 in the Usage
and Concepts Guide for e Testbenches
3.4 New show patches -long Provides Details for All

Patches
Previously to 4.3.2, you had to enter a patch number to get detailed patch information. As of 4.3.2, you
can enter the command show patches -long to get detailed information about all patches. The detailed
information includes the following for each patch:
• The patch number

• The release for which the patch is intended to work
• The defects that the patch fixes
• The patch issue date
• The individual in Verisity who is responsible for creating this patch.
• (If specified by the patch author) modules or files that must not be loaded when using the patch.
• (If specified by the patch author) modules or files required to load the patch.
• Whether or not this patch needs to be loaded or compiled on top of Specman Elite.
• Description of the patch
See Also
• For more information, see show patches on page 22-22 in the Specman Command Reference
3.5 Change in Default Severity for eRM Package

Warnings
The default severity of warnings for packages that specify an open version range for either package
compatibility or Specman Elite compatibility was changed from WARNING to IGNORE. As such, no
message will be issued unless the default setting is changed.

Change in Behavior for config print line_size
See Also
• For more information, see“Declaring Dependencies on Specman Version and Other Packages” on
page 2-15 in the e Reuse Methodology (eRM) Developer Manual.
3.6 Change in Behavior for config print line_size

When you are using Specview, if the configuration print option line_size is set to a value that is larger
than the legal maximum (150 characters), Specview automatically resets the value to the legal
maximum.
As of 4.3.2, this behavior also applies to ASCII command mode: when you are working in ASCII
command mode, if the configure print line_size option is set to a value that is larger than the legal
maximum, Specman Elite automatically resets the value to the legal maximum. Note that the legal
maximum line width for ASCII command mode is 2048 characters, rather than 150 characters.
Previous to 4.3.2, Specman Elite did not correct your error automatically for you in ASCII command
mode.
See Also
• For more information, see “The Print Options” on page 6-38 in the Specman Command Reference.
3.7 Enhanced Online Search Available

Version 4.3.2 provides enhanced Search for the Specman Elite online Help. The enhanced Search now
lets you:
• Search for two-character words.

Previously, your search words had to contain three characters or more
• Search for words that contain special characters.
Previously, searches for words such as “&&” or “@sim” would fail.
• Search for any e keyword.
Previously, searching for some keywords required you to append “-syntax” to the search word.
As of 4.3.2, search words with “-syntax” appended to the end of the word no longer work. This pre-4.3.2
feature was intended to help users find keywords more quickly. However, most users never learned to
use this feature; it therefore might not be familiar to you. Regardless, it is no longer supported as of
4.3.2.
The rules for the enhanced search are completely described in the Search and Browsing Tips.

Updates to Supported Platforms and Simulators
3.8 Updates to Supported Platforms and Simulators

Version 4.3.2 supports Red Hat Linux 9.0 and Enterprise 3 on Intel Pentium platforms only.

Updates to Supported Platforms and Simulators

This chapter describes the new features in the 4.3.1 release. It contains the following sections:
• “Updates for 4.3.1 Beta Features” on page 4-1

• “Support for Instantiating the “specman” Module in a Verilog DUT” on page 4-2
• “Struct Syntax Updates Resulting from Keyword Deprecation” on page 4-3
• “Documentation Updates” on page 4-3
4.1 Updates for 4.3.1 Beta Features

This section contains:
• “New Support for “in” Method Ports” on page 4-2

• “New Visual Toolbox Methods for Adding Secondary Toolbars” on page 4-2

New Support for “in” Method Ports
4.1.1 New Support for “in” Method Ports

In the 4.3 release, Specman Elite supported, at beta quality, both internal (e-to-e) and external
(e-to-foreign-agent) method ports. However, support for in method ports was restricted to internal
method ports only.
With this release, in method ports are supported for external method ports as well. This new support lets
you call an e method directly from a foreign agent such as SystemC.
A method port must be parameterized by a type of a special kind—a method type. In this release, the
syntax for declaring method types has changed from
type send_packet_method_t: m(p : packet)@sys.any; -- old syntax
to
method_type send_packet_method_t(p : packet)@sys.any; -- new syntax
4.1.2 New Visual Toolbox Methods for Adding Secondary

Toolbars
Each VT Window has a “main” toolbar that shows predefined and user actions (such as navigation
buttons). In addition to the main toolbar, you can add secondary toolbars to the VT window. The
secondary toolbars will appear below the main toolbar. You can add actions and separators to the
secondary toolbar.
See Also
• add_secondary_toolbar() on page 2-154 in Specman Beta Features
• add_menu_item_to_secondary_toolbar() on page 2-155 in Specman Beta Features
• add_separator_to_secondary_toolbar() on page 2-156 in Specman Beta Features
4.2 Support for Instantiating the “specman” Module

in a Verilog DUT
You can now instantiate the Verilog module “specman”, which is defined in the Verilog stub file
specman.v, anywhere in the hierarchy of the Verilog DUT. This new feature means that you do not need
to specify the “specman” stub module as a separate topmost Verilog module in your simulation
environment.
See Also
• “Verilog Stubs Files” on page 8-4 in the Usage and Concepts Guide for e Testbenches.

Struct Syntax Updates Resulting from Keyword Deprecation
4.3 Struct Syntax Updates Resulting from Keyword

Deprecation
The following syntax is being changed as the result of deprecation to avoid overlap with e keywords:
• The dut_error_struct.message field is being replaced by the new dut_error_struct.get_message()

predefined method
• The locker.release() predefined method is being replaced by the new locker.free() predefined method.
• The session.dut_error predefined event is being replaced by the new session.dut_err predefined
event.
• The cvl predefined struct is being replaced by cvl_manager.
Note Verisity will continue to support the deprecated syntax for the forseeable future, and thus you do
not need to change your e code as a result of this deprecation. However, the Specman Elite manuals will
show the new syntax in reference sections and in examples.
See Also
Elite Release
• dut_error_struct on page 10-6 in the e Language Reference
• lock() and free() on page 22-65 in the e Language Reference
• “Events for Aiding Debugging” on page 12-13 in the e Language Reference
• “The cvl_manager Struct (a Global Struct Field)” on page 12-4 in the Usage and Concepts Guide for
e Testbenches
4.4 Documentation Updates

This section describes:
• “Waveform Viewer Documentation Enhancement” on page 4-4

• “Clarification of per-instance Coverage” on page 4-4
• “Hierarchy for PDF Files” on page 4-4
• “Java Navigation for Verisity Help on Windows XP” on page 4-5

Waveform Viewer Documentation Enhancement
4.4.1 Waveform Viewer Documentation Enhancement

The “Using a Waveform Viewer” chapter in the Specman Elite Usage and Concepts Guide has been
simplified and shortened. Most of the details about compiling and linking waveform viewers/simulators
and Specman Elite have been replaced by pointers to the tool-specific examples in the
$SPECMAN_HOME/examples/Waveform/ directories.
See Also
• Chapter 10 “Using a Waveform Viewer” in the Specman Elite Integrator’s Guide
4.4.2 Clarification of per-instance Coverage

The documentation for per-instance coverage has been updated to clarify the use of radix in per-instance
group names.
See Also
• “Using Per-Instance Coverage” on page 7-29 in the Usage and Concepts Guide for e Testbenches.
4.4.3 Hierarchy for PDF Files

In previous releases, the PDF files contained in the release file sn_reln.n.pdf.tar.gz were installed in the
following directory structure under $SPECMAN_HOME:
docs/about/about_this_release.pdf
docs/beta/beta_features.pdf
docs/cref/c_reference.pdf
docs/eref/e_reference.pdf
…
As of 4.3.1, the PDF files now appear in the new docs/pdf_docs directory. The PDF hierarchy is flattened
so that all PDF files appear directly in the docs/pdf_docs directory:
docs/pdf_docs/about_this_release.pdf
docs/pdf_docs/beta_features.pdf
docs/pdf_docs/c_reference.pdf
docs/pdf_docs/e_reference.pdf
…
All hyperlinks between the PDF files (from one manual to another manual) work in this new hierarchy.

Java Navigation for Verisity Help on Windows XP
4.4.4 Java Navigation for Verisity Help on Windows XP

If you’re using Verisity Help on Windows XP, you should now use the Java implementation rather than
JavaScript. The Java navigation provides better features and is faster than JavaScript.
For more information about Java navigation on a Windows computer, see the section “Java/JavaScript
Navigation” in the Search and Browsing Tips. This document can be located in the left-hand pane of the
Verisity Help.

Java Navigation for Verisity Help on Windows XP

5 New Features in Version 4.3
This chapter describes the new features in the 4.3 release:
• “New GUI Features” on page 5-1

• “New Data Browser Features” on page 5-2
• “New Language Features” on page 5-2
• “Production Release of Beta Features” on page 5-2
• “New Platforms and Third-Party Tools” on page 5-3
• For additional information about the 4.3 release, please see:
• For information about the defects fixed in the 4.3 release, please see:
5.1 New GUI Features

Clicking the eRM button in Specview launches the eRM utility, which lets you:
• Browse eRM packages, load them, run their demos, and so on

• Browse the Unit and Env structure of the verification environment
• View eRM sequence stripe charts
• Control messages and message loggers

New Features in Version 4.3
New Data Browser Features
• Generate eDoc reports

For more information on the eRM utility, see Chapter 8, “The eRM Utility” in the e Reuse Methodology
(eRM) Developer Manual.
5.2 New Data Browser Features

The Data Browser now includes a Visualize button and a Show Visualization command in the Tools
menu. Either of those features opens a Visualization Toolkit (VT) window that displays a user-defined
graphical representation of the current Specman Elite data. To enable the visualization button and
command, you must extend the new, predefined visualize() method of any struct by writing VT code in
that method.
For structs that contain extended visualize() methods, a new Data Browser configuration parameter,
auto_visualize, can be set so that selecting a struct instance in the Data Browser automatically opens the
VT window for the struct.
See the following for additional information on the new Visualization Toolkit features:
• The auto_visualize parameter in configure databrowser on page 6-11 in the Specman Command
Reference
• “The visualize() Method of any_struct” on page 22-32 in the e Language Reference
• Chapter 2 “Using the Visualization Toolkit” in Specman Beta Features
• “Opening Visualization Toolkit Windows” on page 3-19 in the Usage and Concepts Guide for e
Testbenches
5.3 New Language Features

Two new e language constructs are included in Specman Elite 4.3:
• The visualize() method of any struct, used to enable Visualization Toolkit features. See “The
visualize() Method of any_struct” on page 22-32 in the e Language Reference.
• The writef() method writes data to a file in a user-defined format. See writef() on page 22-50 in the
e Language Reference.
5.4 Production Release of Beta Features

Static analysis optimizations is released as a production feature in 4.3:

Static Analysis on Demand
5.4.1 Static Analysis on Demand

New optimizations of generation static analysis decrease the memory consumption and the run time of
static analysis. To activate those optimizations, use configure gen or set_config() to set the
-static_analysis_opt configuration option, using either
config gen -static_analysis_opt = TRUE
or
set_config(gen, static_analysis_opt, TRUE);
Notes
• Random stability is not preserved from the 4.2.1 release (or any earlier releases) when the
optimizations are activated.
• If it is used, the -static_analysis_opt configuration option must be set no later than the setup() test
phase (see “Generation and Test Phases” on page 1-2 in the Generation Guide).
• The configuration option is FALSE by default, and cannot be set to FALSE. The only possible user
setting is TRUE.
• The ability to set this option will be deprecated in a future release when it will be automatically
activated within Specman Elite.
5.5 New Platforms and Third-Party Tools

The 4.3 release provides support for the following new platforms and third-party tools:
• “Support for LDV 5.0 and 5.1” on page 5-3

• “Support for the SimVision Waveform Viewer” on page 5-4
5.5.1 Support for LDV 5.0 and 5.1

The 4.3 release provides support for the following additional simulator platforms:
• Cadence Design Systems LDV 5.0

• Cadence Design Systems LDV 5.1
Note Please see $SPECMAN_HOME/docs/release_notes.txt for information about limitations on the
use of LDV 5.0 and 5.1.

Support for the SimVision Waveform Viewer
5.5.2 Support for the SimVision Waveform Viewer

Specman Elite now supports the Cadence Design Systems SimVision waveform viewer in addition to
the waveform viewers previously supported. For complete information about using the SimVision
waveform viewer with Specman Elite, see
• Chapter 10 “Using a Waveform Viewer” in the Specman Elite Integrator’s Guide

6 Overview of the 4.3 Release
Specman Elite® version 4.3 includes the following:
• Easy launch of the eRM utility from Specview, plus additional eRM enhancements
• Data Browser enhancements
• New methods visualize(), which enables Visualization Toolkit features, and writef(), which lets you
write data to a file in a user-defined format
• New generation constraint block e keep all of {…}, which lets you define a block of constraints in a
simple, readable format
• The production release of the following 4.2.x beta feature:
• Static analysis optimizations
• The beta release of the following features:
• NC SystemC integration
• Method ports
• Additional new features for the Visualization Toolkit
• Support for the following:
• Cadence Design Systems LDV5.0 and LDV5.1
• Cadence Design Systems SimVision waveform viewer
For more information about the new features in this release, see Chapter 5 “New Features in Version 4.3”.
For information about installing 4.3 and upgrading to 4.3, see the following sections:
• “Preparing for 4.3 Installation” on page 6-2

• “Installing eRM” on page 6-2

Overview of the 4.3 Release
Preparing for 4.3 Installation
• “Upgrading to 4.3” on page 6-3
6.1 Preparing for 4.3 Installation

The Specman Elite Installation Guide gives you complete instructions for installing 4.3 at your site,
whether you are installing Specman Elite for the first time or you are upgrading a previous installation.
See Chapter 2 “Installation Process” in the Specman Elite Installation Guide for an overview of the
process.
You can download the PDF version of the Specman Elite Installation Guide from the Verisity FTP site
or you can look at it online.
To get instructions on how to download the Specman Elite Installation Guide, the release executables,
and the documentation and Verification Advisor tar files from the Verisity FTP site, send email to
support@verisity.com.
Note A 4.3 license file is required to run this release.
6.2 Installing eRM

The 4.3 release includes eRM as part of the installation hierarchy, in $SPECMAN_HOME/erm_lib. You
can make eRM available for all runs by installing it with the Specman Elite installation script. To do so,
run a full installation. During the installation, you are prompted to install eRM, as described in “Install
eRM Packages” on page 3-3 in the Specman Elite Installation Guide.
Alternatively, you can make eRM available for selected runs (rather than for all runs) by either:
• “Loading the Core eRM Package on Top of Specman Elite” on page 6-2
• “Compiling the Core eRM Package on Top of Specman Elite as User Code” on page 6-3
See Also
• “Install eRM Packages” on page 3-3 in the Specman Elite Installation Guide
6.2.1 Loading the Core eRM Package on Top of Specman

Elite
If you do not install eRM with the installation script, you can make it available for individual runs by
loading evc_util, the core eRM package, onto Specman Elite.
To load evc_util onto Specman Elite, enter the following command at the vrst-tool> prompt:
load evc_util/e/evc_util_top

Compiling the Core eRM Package on Top of Specman Elite as User Code
Note You can also load evc_util implicitly if it is imported by another package that you load. All
packages in erm_lib import evc_util.
6.2.2 Compiling the Core eRM Package on Top of Specman

Elite as User Code
If you want to make eRM available for selected runs, rather than all runs, you can compile evc_util, the
core eRM package, onto Specman Elite to create a separate Specman Elite executable, rather than
installing eRM with the installation script.
To compile evc_util onto Specman Elite, enter the following command at the shell prompt:
% sn_compile.sh -t /tmp evc_util/e/evc_util_top.e
This produces an executable (named evc_util_top, in the above example), with evc_util compiled on top
of Specman Elite.
For information on the command-line options for sn_compile.sh, see sn_compile.sh on page 2-12 in the
Specman Elite Integrator’s Guide.
6.3 Upgrading to 4.3

Specman Elite 4.3 is distributed with FLEXlm version 7.2. If you are upgrading a 3.3.2 or earlier
Specman Elite installation to 4.3, you must update your FLEXlm license server and tools during the
installation process. See “Install the License” on page 3-5 in the Specman Elite Installation Guide for
more details.

Upgrading to 4.3

7 The Deprecation Process
A deprecated feature is a feature that may no longer be allowed or supported in a future release of
Specman Elite. Specman Elite issues a message when your code uses a deprecated feature. Verisity
increases the severity level of these messages over a number of releases. This approach gives Verisity the
time necessary to make appropriate decisions about changes in technology and gives you the time
necessary to update your code if changes are required.
This chapter contains the following sections:
• “Understanding the Deprecation Process” on page 7-1

• “Deprecation for Syntactic Changes” on page 7-3
• “Deprecation for Semantic Changes” on page 7-4
• “Deprecation Recommendation for eVC Developers” on page 7-5
7.1 Understanding the Deprecation Process

Deprecation can result from:
• Syntactic changes (previously legal e code will no longer be accepted)

• Semantic changes (previous legal e code will behave differently)
Specman Elite warns you about deprecated features in your e code by displaying notification messages
when you load your code. The messages identify the filenames and line numbers for the e code
containing the deprecated features.

The Deprecation Process
Understanding the Deprecation Process
The notification messages are associated with one or more notification IDs. Each notification ID
identifies a specific deprecated feature and a default severity level. The notification ID appears in all
notification messages about the deprecated feature. The severity level for the notification ID progresses
over several releases from IGNORE to WARNING and ERROR. The meaning of the severity level for
each type of deprecation is described in:
• “Deprecation for Syntactic Changes” on page 7-3

• “Deprecation for Semantic Changes” on page 7-4
In the early stages of deprecation, you can manipulate whether or not notification messages are
displayed with the set notify command. You use the set notify command to set:
• The severity level for given notification IDs

• The maximum number of times that a given message can be printed
You can also display information about all currently deprecated features with the show notify command.
You use the show notify command to list:
• The notification IDs and related severity levels associated with a given release
• The number of times that the associated notification occurs in the currently loaded e code
See Also
• show notify on page 22-20 in the Specman Command Reference
• set notify on page 22-10 in the Specman Command Reference

Deprecation for Syntactic Changes
7.2 Deprecation for Syntactic Changes

Table 7-1 describes the steps in the deprecation process and the related severity levels for changes that
result in syntactic deprecation (previously legal e code will no longer be accepted).
Table 7-1 Syntactic Deprecation Process
Step in the Severity

Process Level Description
Notification IGNORE By default, the related notification messages are not displayed. You
can display the notification messages by setting the severity level for
the related notification IDs to WARNING with the set notify
command. (See set notify on page 22-10 in the Specman Command
Reference.)
If new syntax replaces the deprecated syntax, the new syntax is

documented in the Specman Elite documentation. The
documentation, however, also describes the deprecated syntax so that
users who want to continue using it can find documentation on it.
Warning WARNING By default, the related notification messages are always displayed.
You can disable the notification messages by setting the severity
level for the related notification IDs to IGNORE with the set notify
command. (See set notify on page 22-10 in the Specman Command
Reference.)
Disabling the notification messages lets you continue to use the

deprecated feature in your e code.
Error ERROR You can continue to disable the notification messages with the set
notify command. Descriptions of the deprecated feature, however,
no longer appear in the Specman Elite documentation.
Full ERROR No notification messages are issued. Instead, you receive a standard
Deprecation Specman Elite error message asking that you correct your code. You
cannot disable the error messages, and you must change your code.

Deprecation for Semantic Changes
7.3 Deprecation for Semantic Changes

Table 7-2 describes the steps in the deprecation process and the related severity levels for changes that
result in semantic deprecation (previous legal e code will behave differently).
Table 7-2 Semantic Deprecation Process

Process Level Behavior Description
Early IGNORE Default: old behavior By default, the related notification messages
notification are not displayed. You can display the
Cannot change to new notification messages by setting the severity
behavior level for the related notification IDs to
WARNING with the set notify command.
(See set notify on page 22-10 in the
Specman Command Reference.)
The old behavior is the default behavior, and

you cannot change to the new behavior.
This is an optional step in the process.
Notification IGNORE Default: old behavior By default, the related notification messages
are not displayed. You can display the
Can change to new notification messages by setting the severity
WARNING with the set notify command.
(See set notify on page 22-10 in the
Specman Command Reference.)
The old behavior is the default behavior, but

you are provided with the ability to choose
the new behavior.
Warning WARNING Default: old behavior By default, the related notification messages
are always displayed. You can disable the
Can change to new notification messages by setting the severity
IGNORE. (See set notify on page 22-10 in
the Specman Command Reference.)
The old behavior is the default behavior, but

you are provided with the ability to choose
the new behavior.

Deprecation Recommendation for eVC Developers
Table 7-2 Semantic Deprecation Process (continued)

Process Level Behavior Description
New IGNORE Default: new behavior By default, the related notification messages
Behavior are not displayed. You can display the
Can change to old notification messages by setting the severity
behavior level for the related notification ID to
WARNING. (See set notify on page 22-10
in the Specman Command Reference.)
The new behavior is now the default

behavior, but you are still provided with the
ability to revert to the old behavior.
Full None Default: new behavior No notification messages are issued. The
Deprecation new behavior is the default behavior, and
Cannot change to old you are no longer able to change to the old
behavior behavior.
7.4 Deprecation Recommendation for eVC

Developers
Newly deprecated features are generally deprecated at a severity level of IGNORE. This means that code
containing the deprecated feature will not trigger error messages unless you change the severity level to
WARNING.
If you are an eVC developer, Verisity recommends that you run new releases with deprecation severity
levels set to WARNING so that you become aware of all features that have started deprecation.
set notify on page 22-10 in the Specman Command Reference describes how to change the severity
level.
Note The notification messages and IDs for currently deprecated features are described in Chapter 8
“Deprecation and Backward Compatibility for this Release”.

Deprecation Recommendation for eVC Developers

8 Deprecation and Backward
Compatibility for this Release
Specman Elite introduced feature deprecation in version 4.0.3. The deprecation process is described in
Chapter 7 “The Deprecation Process”.
Specman Elite also maintains a set of backward compatibility flags for versions 3.3 and 3.2. The
backward compatibility flags let you revert some aspects of the tool’s current behavior to version 3.2 or
3.3 behavior, to help support conversions from version 3.3 or 3.2 to the current version of Specman Elite.
This chapter describes both deprecation for the current version and version 3.X backward compatibility.
Not all backward compatibility issues are addressed through deprecation or backward compatibility
flags. For example, software fixes can cause changed behavior that requires your understanding, even if
they do not result in a deprecated feature. This chapter also describes these additional backward
compatibility issues.
This chapter contains the following sections:
• “Deprecation and Backward Compatibility in the Current Release” on page 8-2

• “Upgrading from Version 3.3” on page 8-31
• “Version 3.3 Backward Compatibility Issues” on page 8-39
• “Upgrading from Version 3.2” on page 8-63
• “Documentation for Fully Deprecated or Outdated Features” on page 8-64
Note In this chapter, the major release number also refers to the subsequent point releases. For
example, “3.3” includes 3.3 through 3.3.4.

Deprecation and Backward Compatibility for this Release
Deprecation and Backward Compatibility in the Current Release
8.1 Deprecation and Backward Compatibility in the

Current Release
Table 8-1 describes the features in the current release that are either formally under deprecation or that
affect backward compatibility. For each feature, the table lists the Notification ID and its default severity.
For a description of the deprecation process and the meaning of the severity levels, see Chapter 7 “The
Deprecation Process”.
Note For the complete history of each deprecated feature, see the deprecation_history.pdf file in the
Verification Vault (www.verificationvault.com) at Knowledge Base ›› Product
Documentation ›› Deprecated and Outdated Features.
Table 8-1 Deprecation and Backward Compatibility in the Current Release
Default
Notification ID/Description Severity
DEPR_AHB_BURST_DELAY_KEYWORD IGNORE
DEPR_AHB_BURST_START_KEYWORD
DEPR_AHB_TRANSFER_DELAY_KEYWORD
DEPR_AHB_TRANSFER_START_KEYWORD
DEPR_AHB_TRANSACTION_START_KEYWORD
These notification IDs identify the use of “delay” fields and the “start()” method in
AHB eVC predefined structs and units. These fields and method are under
deprecation to avoid overlap with e keywords. For more information, read the
AHBeVC release notes vr_ahb_release_notes.txt.
DEPR_AT_X_NCVHDL IGNORE
Identifies code which, when reading VHDL objects using @x, interprets U, W and -
(don’t care) std_logic values incorrectly as zero. Applies for NC VHDL and NC SIM
only. The valuation of zero is incompatible with other VHDL simulators, for which
the evaluation is one. You can ensure compatible valuation by setting the
compatible_vhdl_at_x_nc simulation config option to TRUE.
For more information, see configure simulationc on page 6-54 in Specman

Command Reference.
DEPR_BACK33_METHOD_EXTENSION WARNING
Identifies the use of the back33 old_method_extension configuration option, which

is under deprecation. This option reverts the Specman Elite method extension rules
to pre-4.0 behavior. For more information about old_method_extension, see
old_method_extension on page 8-43.

Table 8-1 Deprecation and Backward Compatibility in the Current Release (continued)
Default
DEPR_BACK33_WHEN_STRUCT_MEMBER WARNING
Identifies the use of the back33 old_struct_member_under_when configuration

option, which is under deprecation. This option reverts Specman Elite type checking
for struct members in when subtypes to the more relaxed, pre-4.0 rules. For more
information about old_struct_member_under_when, see
old_struct_member_under_when on page 8-39.
DEPR_BIT_EXTRACT_BOUNDS WARNING
Identifies user code that accesses illegal range of bits. For more information, see
“Access Violation for Bit Slice” on page 8-10.
DEPR_CONFIG_CATEGORY_MEMORY WARNING
Identifies the use of undocumented config debug options that are under deprecation.
These undocumented options are listed below, along with the config memory
options that you should use instead:
Deprecated option: config debug check_consistency_all

Replaced by: config memory check_consistency
Deprecated option: config debug show_mem
Replaced by: config memory show_mem_raw
Deprecated option: config debug print_process_size
Replaced by: config memory print_process_size
For more information about the config memory options, see configure memory on
page 6-26 in Specman Command Reference.
DEPR_CONFIG_COLLECT_ALL WARNING
Identifies the use of the -collect_all config gen option, which is under deprecation.
This option controls the generation information collected when the collect gen
command is enabled. Instead of config gen -collect_all, use the collect gen -all. For
more information, see collect gen on page 7-1 in Specman Command Reference.

Default
DEPR_CONFIG_SHORT_IS_SIGNED WARNING
Identifies the use of the miscellaneous configuration option short_is_signed, which

controls the behavior of short signed integers. By default, the value is TRUE, which
means that short signed integers are treated as signed. If set to FALSE, short signed
integers are treated as unsigned. For example:
vrst-tool> set_config(misc, short_is_signed, FALSE)
vrst-tool> var i: int(bits:4)
vrst-tool> i = -4
vrst-tool> print i
i = 12
As of version 4.2, setting this option to FALSE causes an OS11 error during a test
run. Instead of using this option, change the type of all short signed integers that
require an unsigned behavior with a corresponding unsigned type. For example:
vrst-tool> var i: uint(bits:4) // change to an unsigned type
vrst-tool> i = -4
vrst-tool> print i
i = -4
DEPR_CVL_FIELD_KEYWORD IGNORE
Identifies the use of the predefined cvl struct (a global struct field). This struct is
under deprecation to avoid overlap with e keywords and is being replaced with the
new predefined struct cvl_manager. For more information, see “The cvl_manager
Struct (a Global Struct Field)” on page 12-4 in the Usage and Concepts Guide for e
Testbenches.
DEPR_DUT_ERR_FIELD_MESSAGE_KEYWORD IGNORE
Identifies the use of the message field in the dut_error_struct. This field is under
deprecation to avoid overlap with e keywords. Instead, use the struct member
dut_error_struct.get_message(). For more information, see dut_error_struct on
page 10-6 in the e Language Reference.

Default
DEPR_FM_REPEAT_SAMPLING IGNORE
Using sampling for the repeat part of First Match temporal expressions—for
example, as used in the temporal expression “{([..] * cycle ) @clk; @b}”—is illegal.
Currently, this sampling (the @clock in the example) is ignored, even though it is
illegal. This illegal syntax is now under deprecation and identified with this
notification ID.
For more information about First Match temporal expressions, see [ exp..exp ] on
page 13-26 in e Language Reference.
DEPR_FORBIDDEN_ACTION_IN_SEQ_BLOCK ERROR
Identifies the use of a a time-consuming action or a control flow action (such as

break, continue, or return) in the action block for message(), messagef(),
dut_error(), or dut_errorf(). The use of such actions in an action block of
message[f] or dut_error[f] is under deprecation.
DEPR_INT_TO_STD_LOGIC_MTI IGNORE
Identifies value assignments to one-bit std_logic VHDL objects in ModelSim that

are incompatible with the assignments made by other VHDL simulators. You can
ensure compatible assignments by setting the compatible_vhdl_int_to_std_mti
simulation config option to TRUE. For more information, see configure
simulationc on page 6-54 in Specman Command Reference.
DEPR_KEEP_BLOCK IGNORE
Identifies user code that contains the undocumented keep{…} constraint block. For
more information, see “Use of keep {…} Constraint Block” on page 8-12.
DEPR_KEEP_SOFT_BIND WARNING
Identifies user code that contains keep soft bind {…} constraints. Currently these
constraints are converted silently to hard constraints, but the keep soft bind {…}
syntax will be completely deprecated in a future release.
DEPR_LIST_SLICE_BOUNDS WARNING
Identifies user code that accesses illegal items of a list. For more information, see
“Access Violation for List Slice” on page 8-13.

Default
DEPR_LOCKER_RELEASE_TCM_KEYWORD IGNORE
Identifies the use of the locker.release() predefined TCM. This TCM is under
deprecation to avoid overlap with e keywords and is being replaced with the new
predefined TCM locker.free().
For more information about locker.free(), see “lock() and free()” on page 22-65 in the
e Language Reference.
DEPR_MESSAGE_LOGGER_IS_UNIT WARNING /
ERROR
Identifies message loggers that are defined as structs, not units. Note that in some
cases, the default severity level associated with this notification ID is WARNING, in
others it is ERROR. For more information, see “Message Logger Struct Deprecation”
on page 6-4 in the e Reuse Methodology (eRM) Developer Manual.
DEPR_RESERVED_KEYWORD IGNORE
Identifies a Specman Elite keyword that is being used as an identifier in your code.
For more information, see “Use of Specman Elite Reserved Keywords” on page 8-16.
DEPR_SEQUENCE_FIELD_KEYWORD IGNORE
Identifies the fields in the MAIN and RANDOM sequences that are named
“sequence”. These fields are under deprecation to avoid overlap with e keywords.
Verisity recommends using “main_sequence” for the name for the MAIN sequence
field and “sub_sequence” as the name for sequence fields under MAIN or
RANDOM. For more information, see “Sequence Deprecation” on page 5-96 and
“Field sequence Deprecation” on page 5-97 in the e Reuse Methodology (eRM)
Developer Manual.
DEPR_SEQUENCE_ITEM_KEYWORD IGNORE
Identifies the field named “item” in SIMPLE sequences. This field is under
deprecation to avoid overlap with e keywords. Verisity recommends using the name
“seq_item” instead. For more information, see “Sequence item Deprecation” on page
5-99 in the e Reuse Methodology (eRM) Developer Manual.

Default
DEPR_SEQUENCE_START_KEYWORD IGNORE
Identifies the method sequence.start(). This method is under deprecation to avoid

overlap with e keywords and is being replaced with the new method
start_sequence(). For more information, see “Sequence Deprecation” on page 5-96
and “Method sequence.start() Deprecation” on page 5-97 in the e Reuse Methodology
(eRM) Developer Manual.
DEPR_SESSION_DUT_ERR_EVENT_KEYWORD IGNORE
Identifies the use of the predefined event session.dut_error, which is emitted when
a dut_error action is performed. This event is under deprecation to avoid overlap
with e keywords. Instead, use the new predefined event session.dut_err.
For more information about this event, see “Events for Aiding Debugging” on page
12-13 in the e Language Reference.
DEPR_SN_VERILOG_TIME_SCALE_INCOMPAT WARNING
Identifies a discrepancy between the time scale specified in the stubs file
(specman.v) and the Verilog time scale currently affecting Specman Elite behavior.
In a future release, the behavior of Specman Elite will be changed such that it gets
the time scale from the stubs file. For more information, see “Setting the Verilog
Timescale” on page 8-18.
DEPR_SYS_HDL_PATH WARNING
Identifies constraints on the hdl_path() of sys. For more information, see

“Constraining the hdl_path() of sys” on page 8-19.
DEPR_TCM_CLOCK WARNING
Identifies user code that uses a different sampling event in an extension of a TCM.
For more information, see “Extending a TCM using a Different Sampling Event” on
page 8-20.
DEPR_TEMPO_BACK33_ADD_EVAL ERROR
Identifies use of the back33 -add_eval option, which is being deprecated. This
option eliminates multiple evaluations of temporal expressions in the same cycle.
For more information, see “Use of the back33 additional_eval Option” on page 8-21.

Default
DEPR_TEMPO_BACK33_NO_REORDER ERROR
Identifies use of the back33 -no_reorder option, which is being deprecated. This
option determines whether temporal expression evaluation order is influenced by the
dependency order of each temporal expression on other events. For more
information, see “Use of the back33 no_reorder Option” on page 8-23.
DEPR_TYPE_LONG WARNING
Identifies user code that uses “long” as the name for a type. For more information,
see “Reserved Type Name” on page 8-25.
DEPR_UNBOUND_INT_SLICE WARNING
Identifies user code that does not place an upper bound to a list slice of an unbounded
integer (an int (bits:*) expression). For more information, see “Access Violation for
List Slice of Unbounded Integer” on page 8-25.
DEPR_UNIT_GEN_INSTANCE WARNING
DEPR_UNIT_INSTANCE
Identifies a unit instance rule violation. For more information, see “Restrictions on
the Creation of Unit Instances” on page 8-26.
DEPR_WAVE_REGISTER_STRUCTS WARNING
Identifies the use of the deprecated wave configuration option -register_structs and
requests the user to use the memory configuration option -retain_trace_structs
instead. For more information, see “Deprecated Wave Configuration Option” on page
8-30.
DEPR_WHEN_AFTER_LIKE WARNING
Identifies references to when subtypes of structs with like children. For more
information, see “References to When Subtypes of Structs with Like Children” on
page 8-30.

Default
list_constraint_is_bidir generation config option (not

applicable)
This option, which was introduced in 4.3.2, ensures backward compatibility during
an upgrade from a pre-4.2 version to Specman Elite 4.2 or later. It controls whether
list constraints are bidirectional or unidirectional. This option is not connected with a
deprecated feature, but instead ensures backward compatibility for legacy code. For
more information, see the description of list_constraint_is_bidir in configure gen
on page 6-17 in the Specman Command Reference.
specsim command (not

applicable)
The specsim command has been replaced by the specrun command. This change is
to avoid confusion with the spexsim command, which launches SpeXsim. If you
enter the specsim command, Specman Elite issues a message asking you to use
specrun instead.
In a future release, the specsim command may not be available for use.
For more information about the specrun command, see specrun on page 2-4 in
Specman Command Reference.
WARN_VHDL_TIME_MODELSIM_IGNORED WARNING
Warns you that the vhdl time statements in your code will be ignored. This problem
occurs only when Specman Elite is linked with ModelSim.
As of 4.3.4, you can change this default behavior by setting the

-enable_vhdl_time_mti simulation config option to TRUE. When
-enable_vhdl_time_mti simulation is TRUE, vhdl time statements are taken into
effect (not ignored) when Specman Elite is linked with ModelSim.
For more information, see configure simulationc on page 6-54 in Specman

Command Reference.
See Also
Some of the deprecated features included in Table 8-1 on page 8-2 are described in more detail in the
following sections:
• “Access Violation for Bit Slice” on page 8-10

• “Use of keep {…} Constraint Block” on page 8-12

Access Violation for Bit Slice
• “Access Violation for List Slice” on page 8-13

• “Use of Specman Elite Reserved Keywords” on page 8-16
• “Setting the Verilog Timescale” on page 8-18
• “Constraining the hdl_path() of sys” on page 8-19
• “Extending a TCM using a Different Sampling Event” on page 8-20
• “Use of the back33 additional_eval Option” on page 8-21
• “Use of the back33 no_reorder Option” on page 8-23
• “Reserved Type Name” on page 8-25
• “Access Violation for List Slice of Unbounded Integer” on page 8-25
• “Restrictions on the Creation of Unit Instances” on page 8-26
• “Deprecated Wave Configuration Option” on page 8-30
• “References to When Subtypes of Structs with Like Children” on page 8-30
8.1.1 Access Violation for Bit Slice

This notification message identifies user code that accesses illegal range of bits. In earlier versions of
Specman Elite some of these violations were not detected and others were detected only during run time.
To prevent this message it is recommended to modify the code to remove the identified violation.
Associated Notification ID
DEPR_BIT_EXTRACT_BOUNDS
Sample Notification Message

If you access bits out of the natural range, you will see a message similar to the following message. (See
“Example 1” on page 8-11 for an illustration of this type of violation.)
*** Warning: DEPR_BIT_EXTRACT_BOUNDS: Cannot access bits [40:5] of an item

whose natural range is [31..0].
In future releases this violation may become an error.
at line 6 in load_warn1.e
print x[40:5];
For more information, search help for 'DEPR_BIT_EXTRACT_BOUNDS'

Access Violation for Bit Slice
If you access bits in a [low:high] format, you will see a message similar to the following message. (See
*** Warning: DEPR_BIT_EXTRACT_BOUNDS: Cannot access bits [5:10] of an item

whose natural range is [31..0] - must be in [high:low] format.
at line 6 in test9a.e
x[5:10] = 5;
For more information, search help for 'DEPR_BIT_EXTRACT_BOUNDS'
Example 1
In earlier releases, Specman Elite did not find some bit extraction violations at parse time. Thus the
following code parses and runs without error in earlier releases:
<'
run() is also {
var x: int;
print x[40:5];
};
'>
To avoid accessing non-existent bits you must only access bits within the natural range:
<'
run() is also {
var x: int;
print x[31:5];
};
'>
Example 2
In earlier releases, Specman Elite did not find some bit extraction format violations where the upper
bound is lower than the lower bound. Thus the following code loads and runs without error in earlier
releases:
<'
extend sys {
run() is also {
var x: int;
x[5:10] = 5;
};
};
'>

Use of keep {…} Constraint Block
To avoid this format violation you must have an higher bound that is equal or higher than the lower
bound:
<'
extend sys {
run() is also {
var x: int;
x[10:5] = 5;
};
};
'>
8.1.2 Use of keep {…} Constraint Block

With this release, the undocumented keep {…} constraint block is deprecated with a severity of
IGNORE. This construct is under deprecation because of its ambiguity and its conflict with the list
concatenation syntax. As of 4.3, you can replace keep {…} with keep all of {…}, which allows you to
define a block of constraints in a simple, readable format.
To see whether your code uses the deprecated keep {…} constraint block, use the set notify command to
change the severity of DEPR_KEEP_BLOCK to WARNING.
DEPR_KEEP_BLOCK

If your code uses the deprecated keep {…} constraint block and you have set the severity of
DEPR_KEEP_BLOCK to WARNING, you will see a message similar to the following message. (See
*** Warning: DEPR_KEEP_BLOCK:

In previous versions, keep blocks (keep {...}) were allowed. Now, this
construct is under deprecation. In future versions, using this construct
might be treated as an error. Instead, you can replace 'keep' with
'keep all of'.
at line 12 in @keep
keep {a.f1 == 5; a.f2 == 6};
Example 1
The following code is now deprecated:

Access Violation for List Slice
<'
struct A {
f1: int;
f2: int;
};
extend sys {
a: A;
a1: A;
keep {a.f1 == 5; a.f2 == 6};

};
'>
Instead, you can use the keep all of {…} constraint block. For example,
keep all of {a1.f1 == 5; a1.f2 == 6};
8.1.3 Access Violation for List Slice

This notification message identifies user code that accesses illegal items of a list. In earlier versions of
Specman Elite some of these violations were not detected and others were detected only during run time.
DEPR_LIST_SLICE_BOUNDS

If you access non-existent items of a list, you will see a message similar to the following message. (See
*** Warning: DEPR_LIST_SLICE_BOUNDS: Cannot access range [..40] of an item

whose natural range is [0..31].
print l[..40];
For more information, search help for 'DEPR_LIST_SLICE_BOUNDS'
If you access list items in a [high..low] format, you will see a message similar to the following message.
(See “Example 2” on page 8-15 for an illustration of this type of violation.)
*** Warning: DEPR_LIST_SLICE_BOUNDS: Cannot access range [20..10] of an

item whose natural range is [0..31] - must be in [low..high] format.

print l[20..10];
If you access list items using a negative index, you will see a message similar to the following message.
(See “Example 3” on page 8-15 for an illustration of this type of violation.)
*** Warning: DEPR_LIST_SLICE_BOUNDS: Cannot access range [-1..i] of a list
- negative index not allowed.
print l[-1..i];
Example 1
In earlier releases, Specman Elite did not find at parse time some list access violations. Thus the
following code parses without error in earlier releases but fails to run:
<'
extend sys {
run() is also {
var l: int;
print l[..40];
};
};
'>
To avoid accessing non-existent bits you must only access bits within the natural range:
<'
extend sys {
run() is also {
var l: int;
print l[..31];
};
};
'>

Example 2
In earlier releases, Specman Elite did not find at parse time some list access format violations where the
upper bound is lower than the lower bound. Thus the following code parses without error in earlier
releases but fails to run:
<'
extend sys {
run() is also {
var l: int;
print l[20..10];
};
};
'>
To avoid this format violation you must have an higher bound that is equal or higher than the lower
bound:
<'
extend sys {
run() is also {
var l: int;
print l[10..20];
};
};
'>
Example 3
In earlier releases, Specman Elite did not find at parse time some list access violations that use a
negative index. Thus the following code parses without error in earlier releases but fails to run:
<'
extend sys {
run() is also {
var l: list of int;
var i: int;
print l[-1..i];
};
};
'>
To avoid this violation you must avoid using a negative index in your code:
<'
extend sys {
run() is also {
var l: list of int;

Use of Specman Elite Reserved Keywords
var i: int;
print l[0..i];
};
};
'>
8.1.4 Use of Specman Elite Reserved Keywords

Identifiers in code that are identical to Specman Elite reserved keywords are deprecated with a severity
of IGNORE.
The primary reason for this deprecation category is that modern parsers have difficulty handling code in
which keywords are used also as identifiers. Thus, keyword deprecation is necessary to support the
development of future e based tools, whether from Verisity or from a third party.
However, unlike other deprecation categories, you will continue to be able to set the severity level for
keyword deprecation to IGNORE, regardless of the default severity level. Thus, if your code contains
identifiers that are identical to keywords, you will be able to choose what to do about it: If using other e
based tools turns out to be important to you, you can choose to edit your code. If using other e based
tools turns out not to be important to you, you will be able to keep the severity level at IGNORE and
preserve your code in its current form.
To see whether your code contains identifiers that are identical to Specman Elite reserved keywords, use
the set notify command to change the severity of DEPR_RESERVED_KEYWORD to WARNING.
How To Identify Specman Elite Keywords

The Specman Elite reserved keywords are listed in “Reserved Keywords” on page 2-10 in the e
Language Reference.
Note Keywords that are used in Specman Elite commands are not subject to deprecation.
DEPR_RESERVED_KEYWORD

If your code contains identifiers that are identical to Specman Elite reserved keywords and you have set
the severity of DEPR_RESERVED_KEYWORD to WARNING, you will see a message similar to the
following message.
*** Warning: DEPR_RESERVED_KEYWORD:
The keyword 'index' is used as an identifier.

Use of Specman Elite Reserved Keywords
This was allowed in previous versions and is currently under deprecation.

Example 1
In the following example, the reserved keyword “index” is used as an identifier, which conflicts with the
for each index syntax and also the implicit index variable:
extend sys {
index: byte; -- use of the reserved keyword "index" as an identifier
run() is also {
print me.index;
};
};
To fix the problem, change the “index” identifier to a non-keyword:

extend sys {
index1: byte; -- change the identifier to a non-Specman Elite
-- reserved keyword
run() is also {
print me.index1;
};
};
Example 2
In the following example, the reserved keyword “delay” is used as an identifier, which conflicts with the
delay() temporal expression:
extend sys {
delay: uint;
my_tcm() @clk is {
wait [delay];
};
};
To fix the problem, change the “delay” identifier to a non-keyword:

extend sys {
delay_time: uint; -- change the identifier to a non-Specman Elite
-- reserved keyword
my_tcm() @clk is {
wait [delay_time];
};

Setting the Verilog Timescale
};
8.1.5 Setting the Verilog Timescale

Notifies you that the Verilog time scale affecting current Specman Elite behavior does not fit the time
scale specified in the stubs file (specman.v). In a future release, the behavior of Specman Elite will be
changed such that it always gets the time scale from the Verilog stubs file.
DEPR_SN_VERILOG_TIME_SCALE_INCOMPAT

*** Warning: DEPR_SN_VERILOG_TIME_SCALE_INCOMPAT: The time scale
associated with Specman Elite's Verilog stubs file differs from that
associated with the first instance of the $sn task in the DUT code.
Currently the time scale of the first instance prevails. Suggestion:
Change the time scale(s) to comply, either in your Verilog code, or in
e - using the 'verilog time' declaration
Example
If you were to enter the following command (for Verilog XL):
xl_specman -s file1.v file2.v specman.v
The specman.v stubs file would inherit the Verilog time scale from file2.v, while the first instance of $sn
(which affects Specman Elite behavior) would be taken from file1.v. Thus, the time scale used at that
point might not be the same as the time scale defined in the stubs file.
To avoid this problem, follow these suggestions to ensure that the time scale used is always the one set
in the stubs file:
• When the DUT contains more than one `timescale directive, use the verilog time statement to set
the time scale in the stubs file.
• If you need to call Specman Elite (using $sn) from Verilog code explicitly, use the verilog code
statement to put the Specman Elite call in the stubs file. This ensures that the call to Specman Elite
has the time scale shown in the stubs file, rather than a time scale from other parts of the Verilog code.

Constraining the hdl_path() of sys
See Also
• verilog time on page 17-14 in the e Language Reference
8.1.6 Constraining the hdl_path() of sys

The hdl_path() of sys is always the empty string “” and you cannot constrain it. However, in earlier
releases of Specman Elite, constraints on sys.hdl_path() were ignored without notifying the user.
To prevent this message, you must remove all constraints on sys.hdl_path().
DEPR_SYS_HDL_PATH

If you define constraints on the hdl_path() of sys, you will see a message like the following. (See
“Example” on page 8-19 for an illustration of this type of violation.)
*** Warning: DEPR_SYS_HDL_PATH: It is illegal to constrain the hdl_path()

of sys. Currently this constraint is ignored.
Suggestion: Constrain the hdl_path() of some other unit(s)
instantiated under sys.
at line 3 in tt3.e
keep hdl_path() == "abc";
For more information, search help for 'DEPR_SYS_HDL_PATH'
Example
In earlier releases, Specman Elite allowed you to define constraints on the hdl_path() of sys. Thus the
following code parses and runs without error in earlier releases:
extend sys {
keep hdl_path() == "abc"; -- As documented in the e Reference Manual,
-- you cannot constrain sys.hdl_path()
};
If the hdl_path() setting of the units under sys worked well in earlier versions of Specman Elite it is safe
to remove the constraints on sys.hdl_path().
If you are trying to constrain only the HDL path of sys in order to affect all HDL access paths, you need
to define the appropriate constraints on other units in your environment.

Extending a TCM using a Different Sampling Event
See Also
• hdl_path() on page 5-19 of the e Language Reference
8.1.7 Extending a TCM using a Different Sampling Event

This notification message identifies user code that uses a different sampling event in an extension of a
TCM.
To prevent this message you must use the same sampling event in a TCM and all its extensions.
DEPR_TCM_CLOCK

If you use a different sampling event in an extension of a TCM, you will see a message like the
following. (See “Example” on page 8-20 for an illustration of this type of violation.)
*** Warning: DEPR_TCM_CLOCK: TCM 'sys.foo()' is defined using clock
'p1.clk', but extended using clock 'p2.clk'.
This is not not allowed - TCM must use exactly the same clock definition in
all extensions.
at line 10 in tt1.e
foo() @p2.clk is also {};
For more information, search help for 'DEPR_TCM_CLOCK'
Example
Extensions of a TCM need to use the same syntactical definition of the sampling of the TCM. In earlier
versions of Specman Elite this check was only partially implemented. As a result, Specman Elite did not
identify all violations.
In the following example:

<'
foo() @p1.clk is {
// ...
};
'>
<'
foo() @p2.clk is also {

Use of the back33 additional_eval Option
out("entering foo ext");

wait cycle;
// ...
};
'>
The wait in the extension is interpreted as “wait cycle@p2.clk”. However the out() is synchronized with
@p1.clk, not with @p2.clk.
To prevent this message, use the same event reference in all extensions of a TCM. For example:
<'
foo() @p1.clk is {
// ...
};
'>
<'
foo() @p1.clk is also {
// ...
};
'>
See Also
• method [@event] is also | first | only | inline only on page 7-12 of the e Language Reference
8.1.8 Use of the back33 additional_eval Option

This notification message identifies the use of the additional_eval back33 compatibility flag.
If your e code contains temporal expressions that depend on data that is modified after the observed
events are emitted, your code behavior might change when you migrate from Specman Elite 3.3 or
earlier to 4.2 or later. This is because some temporal expressions might not be evaluated as frequently.
If you want to restore the old behavior, then you can enable the additional_eval back33 compatibility
flag. This compatibility flag, however, is in deprecation starting with 4.3.1.
DEPR_TEMPO_BACK33_ADD_EVAL

If you use the additional_eval back33 compatibility flag, you will get a message similar to the
following:

Use of the back33 additional_eval Option
*** Warning: DEPR_TEMPO_BACK33_ADD_EVAL: back33 additional_eval

configuration flag is being deprecated.
In future releases this flag may become obsolete.
For more information, search help for 'DEPR_TEMPO_BACK33_ADD_EVAL'
About the additional_eval Option

Syntax:
conf[ig[ure]] back33 -additional_eval=[TRUE | FALSE]
When this flag is set to TRUE, many temporal expressions are evaluated multiple times in the same
cycle, regardless of relevant events, which is detrimental to performance.
When this flag is the default, FALSE, the temporal engine evaluates temporal expressions only upon
occurrence of relevant events.
Note You cannot change the setting of the additional_eval back33 compatibility flag after loading any
e files containing temporal definitions. This results in a runtime error.
The following code is an example of a temporal expression that depends on data that is modified after
the observed event is evaluated. In 4.0 and later, if a_gt_0 is evaluated first, before the run of tcm_2(), it
sees ‘a’ = 0 as initialized, until reevaluated at time 2, and tcm_1() outputs “I saw ‘a’ > 0 at 2”.
With the additional_eval back33 flag set to TRUE, event a_gt_0 is evaluated once more and sees the
assignment to 1 at time 1. tcm_1() outputs “I saw ‘a’ > 0 at 1”.
<'
extend sys {
!a : int;
event a_gt_0 is true(a>0)@any;
tcm_1()@any is {
sync @a_gt_0;
out( "I saw 'a' > 0 ", sys.time );
wait [5];
stop_run()
};
tcm_2()@any is {
wait cycle;
a = 1;
out( "I assigned 'a' with 1 at ", sys.time );
};
run() is also {

Use of the back33 no_reorder Option
start tcm_1();
start tcm_2();
};
};
'>
How to Migrate Old Code

No parse error is generated and normally, old code runs as expected. If it does not run as expected, this
indicates that your e code has races that you must remove.
Contact Verisity Support or your local CE for help with getting your environment working properly
without this flag set to TRUE.
8.1.9 Use of the back33 no_reorder Option

If your e code contains races and you migrate from Specman Elite 3.3 to 4.2 or later, the temporal
expression evaluation order might change the code behavior, because events might be emitted in a
different order.
If you want to restore the old behavior, then you can enable the no_reorder back33 compatibility flag.
This compatibility flag, however, is in deprecation starting with 4.3.1.
DEPR_TEMPO_BACK33_NO_REORDER

*** Warning: DEPR_TEMPO_BACK33_NO_REORDER: back33 no_reorder
configuration flag is being deprecated.
In future releases this flag may become obsolete.
For more information, search help for 'DEPR_TEMPO_BACK33_NO_REORDER'
About the no_reorder Compatibility Option

Syntax:
conf[ig[ure]] back33 -no_reorder=[TRUE | FALSE]

Use of the back33 no_reorder Option
When this flag is set to TRUE, the order of evaluating temporal expressions and executing TCMs is
determined purely on the basis of the order in which events are emitted. When this flag is FALSE (the
default), temporal expression evaluation order is influenced by the dependency order of each temporal
expression on other events.
Taking into account the dependency order optimizes performance.
Note You cannot change the setting of the no_reorder back33 compatibility flag after loading any e
files containing temporal definitions. This results in a runtime error.
The following code contains a race. If tcm1() is run first, data will have the final value which tcm2()
assigned to it, 2, and finalize() will output “data = 2”. If the order is reversed, the output will be “data =
1”.
<'
extend sys {
!data : int;
on any {
if sys.time == 5 {
stop_run();
};
};
tcm1()@any is {
data = 1;
};
tcm2()@any is {
data = 2;
};
finalize() is also {
out( "data = ", data );
};
run() is also {
start tcm2();
start tcm1();
};
};
'>

No parse error is generated and normally, old code runs as expected. If it does not run as expected, this
indicates that your e code has races that you must remove.

Reserved Type Name
Contact Verisity Support or your local CE for help with getting your environment working properly
without this flag set to TRUE.
8.1.10 Reserved Type Name

This notification message category identifies code that refers to the predefined, internal type “long”. To
prevent this message, it is recommended to use “uint”, rather than “long”.
DEPR_TYPE_LONG

If you refer to the type “long”, you will see a message like the following.
*** Warning: DEPR_TYPE_LONG: 'long' type currently is not documented
and may later be removed or changed.
Suggestion: Please use 'uint' type instead.
at line 3 in test1.e
data: long;
For more information, search help for 'DEPR_TYPE_LONG'
Example
In earlier releases, the following code parses and runs without error:
data: long; -- use of predefined type "long"
To fix the problem, assign the type “uint” instead:

data: uint;
8.1.11 Access Violation for List Slice of Unbounded Integer

This notification message identifies user code that does not place an upper bound to a list slice of an
unbounded integer (an int (bits:*) expression or a uint (bits:*) expression).
DEPR_UNBOUND_INT_SLICE

Restrictions on the Creation of Unit Instances

If you have no upper bound for a list slice of an int (bits:*), you will see a message like the following.
*** Warning: DEPR_UNBOUND_INT_SLICE: Expression is int(bits:*) thus must
have <to'exp>.
print l[2..];
For more information, search help for 'DEPR_UNBOUND_INT_SLICE'
Example
In earlier releases, Specman Elite did not find this violation at parse time. This violation could lead to a
memory overflow at run time. Thus the following code parses and runs without error in earlier releases:
<'
extend sys {
run() is also {
var l: int (bits: *);
l= 1024M*1024M;
print l[20..];
};
};
'>
To avoid creating an unbounded list you must determine the upper bound of the list slice. For example:
<'
extend sys {
run() is also {
var l: int (bits: *);
l= 1024M*1024M;
print l[20..ilog2(l)+1];
};
};
'>
8.1.12 Restrictions on the Creation of Unit Instances

As stated in “Methodology Recommendations and Limitations” on page 5-5 of the e Language Reference,
each unit instance has a unique and constant place (an e path) in the run-time data structure of an e
program. That place is determined during pre-run generation. You cannot modify the data structure by
generating unit instances on the fly or assigning new values to existing unit instances. Also you cannot
violate the uniqueness of a unit instance through constraints.

However, in earlier releases Specman Elite did not flag all forms of such violations. Specman Elite now
issues a notification message if it detects a unit instance rule violation.
Note In most unit instance violations, the relevant unit instance field need not be defined as a unit
instance but rather as a unit type, in other words, a reference to a unit that is instantiated elsewhere.
Associated Notification IDs

DEPR_UNIT_INSTANCE
DEPR_UNIT_GEN_INSTANCE
Sample Notification Messages

If your code generates or assigns new values to unit instances at run time, you will see a message like the
following. (See “Example 1” on page 8-27, and “Example 2” on page 8-28 for illustrations of these types
of violations.)
*** Warning: DEPR_UNIT_INSTANCE: This code modifies unit instance
'a' procedurally (the instance field was defined at line 7 in @tt10 ).
It is illegal to modify the unit instance tree in procedural e code
(including using the 'gen' action).
The unit instance tree should only be generated during pre-run generation.
at line 10 in tt10.e
sys.a = a1;
For more information, search help for 'DEPR_UNIT_INSTANCE'
If constraints in your code violate the uniqueness of a unit instance, you will see a message like the
following. (See “Example 3” on page 8-29 for an illustration of this type of error.)
*** Warning: DEPR_UNIT_GEN_INSTANCE: unit instance 'u2' was defined
at line 9 in @tt0
but was later constrained to equal another unit instance or NULL.
A unit instance must be unique and non-NULL.
For more information, search help for 'DEPR_UNIT_GEN_INSTANCE'
Example 1
In earlier releases, Specman Elite did not detect run-time generation of unit instances when the unit
expression was of the form unit-type-exp.unit-instance. Thus the following code parses and runs without
error in earlier releases, even though gen_new_injector() generates a unit instance at run time.
extend sys {

atm_dut: atm_dut is instance;

keep atm_dut.hdl_path() == "~/top/atm_dut";
gen_new_injector() is {
gen atm_dut.injector keeping { -- illegal gen of unit instance
.injector_id == 1;
};
};
run() is also {
gen_new_injector();
};
};
unit atm_dut {
injector :atm_injector is instance;
};
unit atm_injector {
injector_id: uint;
keep soft injector_id == 0;

};
To avoid violating the unit instance rule, you must remove all actions from your code that generate unit
instances at run time.
Note It is legal to generate fields of a unit type (not a unit instance type) at run time. See field:
unit-type on page 5-13 of the e Language Reference.
Example 2
In earlier releases, Specman Elite did not detect run-time assignments of new values to existing unit
instances when the unit expression was of the form unit-type-exp.unit-instance. Thus the following code
parses and runs without error in earlier releases, even though assign_null_injector() assigns NULL value
to an existing unit instance at run time.
extend sys {
!ref_inj: atm_injector;
assign_null_injector() is {
atm_dut.injector = ref_inj; -- illegal assign of unit instance

};
run() is also {
assign_null_injector();
};
}; // sys
unit atm_dut {
}; //atm_dut
unit atm_injector {
injector_id: uint;

}; // atm_injector
To avoid violating the unit instance rule, you must remove all actions from your code that assign new
values to existing unit instances at run time.
Note It is legal to assign new values to fields of a unit type (not a unit instance type) at run time. Thus,
in this example, changing the assignment from “atm_dut.injector = ref_inj” to “ref_inj =
atm_dut.injector” removes the unit instance rule violation. See field: unit-type on page 5-13 of the e
Language Reference.
Example 3
Each unit instance must have a unique place in the unit tree hierarchy. In other words, each unit instance
must have only one parent, either sys or a unit that you have defined. In earlier releases, Specman Elite
did not detect code that violated this rule. Thus the following example parses and runs without error,
although it constrains two unit instances to be the same, in effect allowing a single unit instance to have
two parents.
extend sys {
ref_inj: atm_injector is instance;
keep ref_inj == atm_dut.injector; --illegal constraint of unit instance

};
unit atm_dut {

Deprecated Wave Configuration Option
};
unit atm_injector {
injector_id: uint;

};
To avoid this violation, you must modify your code so that each unit instance has a single parent unit.
Note It is legal to create references to unit instances at other places in the unit hierarchy. For example,
if you change “ref_inj: atm_injector is instance;” to “ref_inj: atm_injector;”, ref_inj becomes a legal
reference to atm_dut.injector and the unit instance rule violation is removed. See field: unit-type on
page 5-13 of the e Language Reference.
8.1.13 Deprecated Wave Configuration Option

The wave configuration option -register_structs is no longer used. The associated notification message
tells you to use the memory configuration option -retain_trace_structs instead.
DEPR_WAVE_REGISTER_STRUCTS

*** Warning: DEPR_WAVE_REGISTER_STRUCTS: 'register_structs'
configuration flag currently is not documented and may later be removed.
Suggestion: Please use memory configuration flag
'retain_trace_structs' instead
See Also
• configure memory on page 6-26 of the Specman Command Reference
8.1.14 References to When Subtypes of Structs with Like

Children
Previously you could refer to a when subtype of a struct even if it had like children. For example, given
the following code:
struct dog {
size: [big, small];
};

Upgrading from Version 3.3
struct bulldog like dog {

no_tail: bool;
};
The following line loaded without a problem:

var x: big dog;
This behavior is inconsistent with the semantic rules for when and like inheritance, which do not let you
create when subtypes of structs with like children. For example, explicitly defining the when subtype
“big dog” results in a compile-time error:
extend dog {
when big dog {
barks: bool;
};
};
With this release, references to a when subtype of a struct that has like children are deprecated. To avoid
this violation, you must modify your code to remove these references. For example, to fix the variable
declaration in the example above, try:
var x: dog = new dog with {.size=big} ;
DEPR_WHEN_AFTER_LIKE

References to when subtypes of structs with like children is now deprecated. Following is an example
of the notification message:
*** Error: Cannot refer to subtype 'big dog'. Struct 'dog' already has
like-children (e.g. 'bulldog').
8.2 Upgrading from Version 3.3

If you are upgrading from version 3.3 or earlier to 4.2, there may be additional compatibility issues that
were introduced in the intervening releases.
To identify those compatibility issues:
1. Identify a set of e source files that loads into an earlier version of Specman Elite without error.
2. Load these files into the new version of Specman Elite.

If there is no parse error, skip to Step 6. If there is a parse error, continue with Step 3.
3. Turn on the compatibility warning mode and reload the e files.
The compatibility warning mode treats all errors related to language compatibility issues as
warnings, so you can see the type and source file location of all the compatibility issues related to
coding style. See “Language Bugs or Undocumented Behavior” on page 8-39 for the types of errors
that are treated as warnings in compatibility warning mode.
The compatibility warning mode does not identify potential differences in run-time behavior.
4. After reading the documentation on each type of warning, upgrade your code wherever possible.
5. After setting the backward compatibility flags for any code you did not upgrade, reload your code.
6. Run the test.
While running the test or reviewing the test results, you may identify differences in run-time
behavior compared to earlier releases or you may decide that for this particular test, you prefer a
certain aspect of the behavior of the older version of Specman Elite.
7. If necessary, set additional compatibility flags and rerun the test.
Figure 8-1 shows the flow chart for this process.

Figure 8-1 Flow Chart: Managing Compatibility Issues When Upgrading from
Version 3.3 or Earlier
Load e files
no
Parse error?
yes
Set compatibility
warning mode and
reload code
Identify problematic
code
no
Fix code? Set compatibility flag
yes
Reload code
Run test
no
Compatibility issues? Run another test
yes
Set compatibility flag
The following sections provide more detailed information on some of the steps of this process.
• “Using the Compatibility Warning Mode” on page 8-34

• “Setting Compatibility Flags” on page 8-35

Using the Compatibility Warning Mode
For a description of the 3.3 backward compatibility issues, see “Version 3.3 Backward Compatibility
Issues” on page 8-39.
8.2.1 Using the Compatibility Warning Mode

Some of the bug fixes or new features added in version 4.0 can cause code that loaded in versions 3.3 to
give parse errors in 4.0 or later. To avoid the frustrating process of fixing one problem, only to reload the
code and find another problem, you can use the Specman Elite compatibility warning mode.
When you load your code in this mode, Specman Elite reports the source reference and line for all
occurrences of the language-related compatibility issues.
For more detailed descriptions of these issues, see “Language Bugs or Undocumented Behavior” on page
8-39.
To identify compatibility issues with the compatibility warning mode use the following command:
set back[ward] warn[ing] 33
1. Turn on the compatibility warning mode with the following command:

set back warn 33
You can execute this command from the vrst-tool> prompt or you can include it on the Specman
Elite invocation line, in an .ecom file, or in the $SPECMAN_PRE_COMMANDS environment
variable. You must execute this command before loading the code you wish to analyze.
2. Load your code.
Specman Elite prints out a list of warnings for all language-related errors in your code. From this
list, you can know how many load-time problems exist and which enhancements are affecting the
load.
Notes
• If you have turned on a language-related compatibility flag, you do not see warnings related to that
issue. For example, if you set “conf back33 -old_method_extension=TRUE”, you do not see warnings
related to method extension.
• Each of the warning messages contains the name of the message, for example,
“WARN_AMBIGUOUS_METHOD”. In Specview, each message name is a hyperlink to the section
of this document that details the relevant enhancement. In text-only mode, you can use the message
name to search the online docs for more information on that warning.
• You cannot run a test in compatibility warning mode. To run tests, you must first exit Specman Elite
and then re-invoke it in normal mode.

Setting Compatibility Flags
8.2.2 Setting Compatibility Flags

Use the configuration category called back33 to set compatibility flags:
conf[ig[ure]] back33 -option=value
For example:
conf back33 -old_struct_member_under_when=TRUE
In this category, there are several Boolean flags that let you revert aspects of Specman Elite behavior to
the 3.3 behavior, as described in “Back33 Configuration Options” on page 8-36.
There are five ways to set backward compatibility flags:
• From the Specman Elite installation script (see “Setting Backward Compatibility from the Specman
Elite Installation Script” on page 8-36)
• From the UNIX command line, using the -precommands command-line argument to specview,
specman, or specrun or the SPECMAN_PRE_COMMANDS environment variable
• From the vrst-tool> prompt
• From any .ecom file
• From the backward compatibility tabs of the Specman Elite Configuration Options window in
Specview (see “Setting Backward Compatibility from Specview” on page 8-36)
In addition to setting specific back33 flags, you can use the set backward compatibility command to
set or unset ALL back33 flags as follows:
set back[ward] compat[ibility] 33 [on | off]
Note The back33 flags must be set before any e code is loaded. You cannot set the flags in a method
extension.
Examples
To set full backward compatibility mode for one session:
specman -p "set back compat 33"
To set full backward compatibility mode for multiple sessions:

setenv SPECMAN_PRE_COMMANDS "set back compat 33"
To set backward compatibility for only one feature over only one session:
specman -p "config back33 -cover_mode=TRUE"

To set backward compatibility for only one feature over multiple sessions:
setenv SPECMAN_PRE_COMMANDS "config back33 -cover_mode=TRUE"
To set backward compatibility from an .ecom file that can be used for Specman Elite 3.3 and 4.0:
#ifdef SPECMAN_VERSION_4_0_OR_LATER { specman("set back compat 33 on") }
8.2.2.1 Setting Backward Compatibility from Specview

To set a back33 flag in Specview:
1. Click the Config button to open the Specman Elite Configuration Options window.
2. On the Back33 tab of the Specman Elite Configuration Options window, select the check box(es) for
the back33 option(s) you want to enable.
8.2.2.2 Setting Backward Compatibility from the Specman Elite

Installation Script
All of the other ways of setting backward compatibility described in this document apply for a specific
run or set of runs. If you want to change the default backward compatibility settings for your installation
of Specman Elite, you must do so using the Specman Elite installation script. Changing your settings via
the installation script means that Specman Elite Elite will open with your customized backward
compatibility settings. Otherwise, you will get the default backward compatibility settings described in
Table 8-2 on page 8-36.
For more information, see the Specman Elite Installation Guide.
8.2.2.3 Back33 Configuration Options

Table 8-2 describes all of the back33 options in brief.
Table 8-2 Summary of the Back33 Configuration Options
Flag Specview Option Description (Flag Is Enabled)
Language General
old_struct_ Use old behavior of Struct members under when will not be entirely
member_under_ struct members under distinct. (See “old_struct_member_under_when” on
when when page 8-39.)
Original default setting is FALSE.

old_method_ Use old method Old method extension rules will be used. (See
extension extension rules “old_method_extension” on page 8-43.)
tick_notation Allow ticks in field Old style of notation for access to fields under when
access notation will be used. (See “tick_notation” on page 8-47.)
Original default setting is TRUE.
list_assign Allow assignment Assignment between simple and keyed lists will be
between simple list allowed. (See “list_assign” on page 8-50.)
and keyed list
Memory Management
disable_otf_gc Disable on-the-fly On-the-fly garbage collection will not occur. (See
GC “disable_otf_gc” on page 8-56.)
Coverage
cover_mode Use old coverage The default coverage mode will be always off. (See
mode behavior “cover_mode” on page 8-58.)
disable_cover_ Disable automatic Specman Elite will not collect event statistics. (See
events coverage of events “disable_cover_events” on page 8-59.)
disable_illegal_ Disable automatic Specman Elite will not check the expression assigned
ignore_check check of the scope of to an illegal or ignore cover item option for invalid
an expression items. (See “disable_illegal_ignore_check” on page
assigned to an illegal 8-52.)
or ignore cover item
option Original default setting is FALSE.
Data Browser

tree_window Show old tree When the tree command is issued, the old tree
window window is displayed instead of the Data Browser.
(See “tree_window” on page 8-60.)
Modules Window
old_modules_ Show old modules When you click the Modules button on the Specview
window window (modules window, the old modules window is displayed
window used prior to instead of the new modules window.
version 4.2)
Commands
no_gen_in_write_ Do not generate The write stubs command will not cause generation
stub during ‘write stubs’ when there are no units except sys. (See
in single-unit mode “no_gen_in_write_stub” on page 8-61.)
Generation
use_trace_gen_33 Use old generation Instead of the Generation Browser, trace gen will be
debugger used. (See “use_trace_gen_33” on page 8-62.)
Temporals
no_reorder Use 3.3 TCM The order of evaluation of temporal expressions will
scheduling scheme simulate the order used by Specman Elite 3.3. (See
“Use of the back33 no_reorder Option” on page 8-23.)
additional_eval Keep additional Redundant evaluations will be retained. (See “Use of

temporal evaluations the back33 additional_eval Option” on page 8-21.)

Version 3.3 Backward Compatibility Issues
8.3 Version 3.3 Backward Compatibility Issues

The following sections document compatibility issues in the 4.0 or later releases for users who are
currently using 3.3:
• “Language Bugs or Undocumented Behavior” on page 8-39

• “Performance Enhancements” on page 8-54
• “Usability Enhancements” on page 8-57
8.3.1 Language Bugs or Undocumented Behavior

Code that loaded without error in 3.3 or earlier releases may generate parse errors in 4.0 or later.
In general, we recommend that you upgrade your e code to remove or rewrite the code that contains
language bugs or that relies on undocumented Specman Elite behavior. However, we recognize that in
some cases, you may not have the time or resources to upgrade your e code. For that reason, we provide
backward compatibility flags in Specman Elite that revert the relevant aspects of new behavior to the old
behavior.
The following sections describe the compatibility issues related to language bugs or undocumented
behavior, listed by the back33 flag you can use to disable these enhancements:
old_struct_member_under_when 4.0 and later releases provide stricter type checking for
on page 8-39 struct members in when subtypes.
old_method_extension on page 4.0 and later releases implement simplified method
8-43 extension rules.
tick_notation on page 8-47 4.0 and later releases provide stricter type checking for field
access expressions. An undocumented use of ticks in field
access expressions is no longer allowed.
list_assign on page 8-50 4.0 and later releases do not allow either explicit or implicit
assignments between keyed lists and regular lists.
disable_illegal_ignore_check on 4.0 and later releases provide stricter scope checking for the
page 8-52 illegal/ignore coverage item option.
8.3.1.1 old_struct_member_under_when
Syntax
conf[ig[ure]] back33 -old_struct_member_under_when=[TRUE | FALSE]

Language Bugs or Undocumented Behavior
Bug Fix
As of 4.0, Specman Elite provides stricter type checking for struct members in when subtypes.
Previously, a method first defined in a when subtype could be called or extended in the base type or any
other subtype without defining it. Similarly, an on struct member could be defined using an event from
a different subtype.
Example 1
In the following code, the method foo() is defined in two different when subtypes. The call to rb_A.foo()
prints either “I am red” or “I am big”, depending on the order in which the when extensions are loaded.
<'
type color: [red];

type size: [big];
struct A{
color;
size;
when red'color A{
foo() is {out("I am red")};
f: bool;
};
when big'size A{
foo() is {out("I am big");};
f: int;
};
};
extend sys{
rb_A : red big A;
run() is also{
rb_A.foo(); -- this generates an error in 4.0
};
};
'>
In 4.0 or later, the call to foo() generates an error. To fix this error, you have to explicitly cast rb_A as a
big’size A or as a red’color A in order to call foo(). For example, the following call prints “I am big”:
rb_A.as_a(big A).foo();

Example 2
In the following code, a method is defined in one when subtype and called from a different when
subtype. In earlier releases, this parsed and ran without error. (No output was displayed.)
<'
type size: [big, small];
struct A{
size;
when big'size A{
foo() is {out("I am big")};
};
};
extend sys{
a : small A;
run() is also{
a.foo(); -- this generates an error in 4.0
};
};
'>
In 4.0 or later, the call to a.foo() generates an error. To fix this error, you have to explicitly cast ‘a’ as a
big’size A or check whether it is a big’size A. For example, the following code checks whether ‘a’ is a
big’size A:
if(a is a big'size A (ba)){
ba.foo();
};
Related Enhancement
As of the 4.0 release, Specman Elite supports the use of different method signatures in different when
subtypes.
Methods with the same name can have different parameter lists and different types of return values.
For examples of how to define different method signatures in different when subtypes, see “Extending
Methods in When Subtypes” on page 4-26 in the e Language Reference.
Implications for User

If -old_struct_member_under_when=FALSE

• A load-time or compile-time error is produced when calling or extending a method or a TCM that
was not defined for a type or a subtype but was defined in another when subtype.
• A load-time or compile-time error is produced for an on struct member with an event defined in
another when subtype.
If -old_struct_member_under_when=FALSE and the compatibility warning mode is on, a load-time

or compile-time warning is produced for each occurrence of the problem.
If -old_struct_member_under_when=TRUE, no warning or error message occurs, regardless of

whether the compatibility warning mode is on or not.
Sample Error Messages

*** Error: Cannot add a method 'foo()' for struct 'A' (It was previously
defined for a derived struct 'red'color A').
If this error did not arise in Specman Elite 3.x, you can also resolve this
error by using 'set_config(back33,old_struct_member_under_when,TRUE)'.
Note that using backward compatibility flags sacrifices some of the
enhanced functionality of the current Specman Elite version.
at line 10 in old_struct_member0.e
foo() is {};};
For more information, search help for 'ERR_ADD_METHOD'
*** Error: Method name 'foo' is not unique. The methods 'red'color
A.foo' and 'big'size A.foo' may exist simultaneously in the same subtype.
rb_A.foo();
For more information, search help for 'ERR_AMBIGUOUS_METHOD'
*** Error: 'a' does not have a method 'foo'

a.foo();
In compatibility warning mode, the following warning message is also generated.

*** Warning: The method foo was defined in red'color A and big'size A but
was not defined in the parent. In Specman Elite v. 3.x this was
considered legal and created an implicit empty method in the parent, in
current Specman Elite version these are considered to be two different
methods, and no empty method is automaticly created in the parent.
If you want the Specman Elite version 3.x behavior
set_config(back33,old_method_extension,TRUE) and
set_config(back33,old_struct_member_under_when,TRUE).
foo() is {out("I am big");};
For more information, search help for 'WARN_METHOD_EXTENSION'

To migrate old code that worked as intended:
• For methods, introduce them in the base type. For example, if you received an error when extending
a method, add “method() is empty” to the base type. If you received an error when calling a method,
either move the method declaration to the base type or move the calling to the subtype.
• For on struct members, surround the on event with “when subtype basetype { … }”.
8.3.1.2 old_method_extension
Syntax
conf[ig[ure]] back33 -old_method_extension=[TRUE | FALSE]
Bug Fix
As of the 4.0 release, Specman Elite implements simplified method extension rules. The previous de
facto behavior of method extensions had many rules, and those rules had many exceptions. The new
rules are much simpler.
For a complete description of the new rules for extending methods, see “Rules for Defining and
Extending Methods” on page 7-2 in e Language Reference.
Example
The following code defines a method in a subtype and then redefines it in the base type. This parses and
runs without error in earlier releases of Specman Elite. The definition of foo() in extension to the base
type effectively overwrites the definition of foo() in the red subtype and the call to a.foo() prints “I am
A”.

<'
type color: [red];

struct A{
color;
when red'color A{
foo() is {out("I am red");};
};
};
extend sys {
a: red A;
run() is also {
a.foo();
};
};
'>
<'
extend A {
foo() is {out("I am A");}; -- generates an error in 4.0
};
'>
The example code above generates an error in 4.0 or later. In order to run the code without modification,
you must set both -old_struct_member_under_when=TRUE and -old_method_extension=TRUE.
If the intention is for a.foo() to print both “I am A” and “I am red”, then foo() should be introduced in the
base type and extended with is also in the subtype:
<'
type color: [red];

struct A{
color;
foo() is {out("I am A");};
when red'color A{
foo() is also {out("I am red");};
};
};
extend sys {

a: red A;
run() is also {
a.foo();
};
};
'>
Related Enhancement
The new rules now enable the use of is only C routine. They also enable is only after is undefined.

If -old_method_extension=FALSE, a load-time or compile-time error occurs for multiple method
declarations using method is empty or method is undefined or multiple declarations using method is
in when inheritance, like inheritance, or extensions in the same type.
If -old_method_extension=FALSE and the compatibility warning mode is on, a load-time or

compile-time warning is produced for each occurrence of the problem.
If old_method_extension=TRUE, no warning or error message occurs, regardless of whether the

compatibility warning mode is on or not.
In most cases, in order to run the code without modification, you must set both
-old_struct_member_under_when=TRUE and -old_method_extension=TRUE.

*** Error: The method 'A.foo' was defined previously (at line 11 in
old_method_extension.e ) - must use 'is also', 'is first' or 'is only'.
error by using 'set_config(back33,old_method_extension,TRUE)'.
at line 14 in old_method_extension.e
For more information, search help for 'ERR_DEFINED_METHOD'
*** Error: The method 'A.foo' was defined previously (at line 4 in
old_method_extension1.e ) - must use 'is also', 'is first' or 'is only'.
error by using 'set_config(back33,old_method_extension,TRUE)'.


at line 13 in old_method_extension1.e
foo() is {};
For more information, search help for 'ERR_DEFINED_METHOD2'
*** Error: The method 'A.foo' was not defined previously - cannot use 'is
also', 'is first' or 'is only'.
at line 4 in old_method_extension2.e
foo() is also{};
For more information, search help for 'ERR_UNDEFINED_METHOD1'
*** Error: Cannot add a method 'foo()' for struct 'A' (It was previously
defined for a derived struct 'red'color A').
For more information, search help for 'ERR_ADD_METHOD'
With compatibility warning mode turned on, you may see these messages:
*** Warning: The method foo was defined in red'color A and A but was not
defined in the parent. In Specman Elite v. 3.x this was considered legal
and created an implicit empty method in the parent, in current Specman Elite
version these are considered to be two different methods, and no empty
method is automaticly created in the parent.
If you want the Specman Elite version 3.x behavior

set_config(back33,old_method_extension,TRUE) and
set_config(back33,old_struct_member_under_when,TRUE).
foo() is {out("I am A");}; -- generates an error in 4.0
For more information, search help for 'WARN_METHOD_EXTENSION'
*** Warning: Method name 'foo' is not unique. The methods 'red'color A.foo'
and 'A.foo' may exist simultaneously in the same subtype.


a.foo();
For more information, search help for 'WARN_AMBIGUOUS_METHOD'

To migrate the code:
1. Replace method extension using “method() is empty” with “method() is only { ... }”.
2. Replace use of duplicate “method() is { ... }” with “method() is only { ... }”.
8.3.1.3 tick_notation
Syntax
conf[ig[ure]] back33 -tick_notation=[TRUE | FALSE]
New Restriction on Undocumented Coding Style

The e language uses the tick character in many documented contexts, such as in HDL object access
(print 'top.data') or in struct subtype references (when red'color A). These documented uses of the tick
character are still supported in the 4.0 release.
Field access using tick notation is an undocumented way to gain unrestricted access to fields of every
when subtype from the base type or anywhere else. For example, in the following code, the some_int
field of the red’color A subtype is set to 5 from a method in the base type using tick notation.
<'
type color: [red, blue];

struct A{
color;
when red'color A {
some_int: int;
};
foo() is {
me.red'color'some_int = 5;
};
};
'>

Even though tick notation for field notation works, we strongly discourage this style. Currently Specman
Elite does store inactive parts of when subtypes. However, Specman Elite treats inactive parts of objects
differently from active parts. For example:
• Specman Elite does not call the extension of the init() method of an inactive part of an object.
• Specman Elite does not enforce constraints on an inactive part of an object.
• Specman Elite does not enforce the size attribute of a list that has been defined in an inactive part of
an object.
For example, in the following code, a variable “gca” is declared of type “green A”. The struct members
of the red’color subtype are inactive in “gca”, but accessible using tick notation. The two checks return
an error (because the constraints are not enforced) and the assignment to “some_int” is accepted without
error. If the checks were not in place, a user might assume that “gca” has an active field “some_int” and
that the constraints were applied.
<'
type color: [red, green];

struct A{
color;
when red'color A {
some_int: int;
sized_list[20]: list of int; // enforced-size list
keep some_int == 3;
init() is also {
out("initializing the red A part");
};
};
};
extend sys {
run() is also {
var gca: green A;
gen gca; // create a green A
// an un-enforced constraint
check that gca.red'color'some_int == 3;
// an un-enforced sized list

check that gca.red'color'sized_list.size() == 20;
// access to an 'inactive' part

gca.red'color'some_int = 3;
};
};

'>
Tick notation allows access to inactive parts of objects as if they were active. This can result in incorrect
results. Disallowing tick notation for field access prevents mistakes. It also lets Verisity make memory
efficiency improvements in future releases.

If -tick_notation=FALSE, a load-time or compile-time error occurs for the first expression using tick
notation for field access.
If -tick_notation=FALSE and the compatibility warning mode is on, a load-time or compile-time

warning occurs for each expression.
If -tick_notation=TRUE, no warning or error message occurs, regardless of whether the compatibility

warning mode is on or not.
Note The original default setting for -tick_notation is TRUE.
Sample Warning Message

*** Warning: Obsolete field access syntax.
error by using 'set_config(back33,tick_notation,TRUE)'.
at line 12 in tick_notation.e
For more information, search help for 'ERR_NAME_WITH_TICKS_WARN'
Sample Error Message

*** Error: Ticks are not allowed in names.
If this error did not arise in Specman Elite 3.x, you can also resolve
this error by using 'set_config(back33,tick_notation,TRUE)'.
at line 12 in tick_notation.e
For more information, search help for 'ERR_NAME_WITH_TICKS'

Field access using tick notation is unsafe.
To migrate the code:

• Use a safe way to perform the required access.

• One safe way is to use is a to identify the subtype of a struct instance. For example:
if pkt is a ATM packet(atm_pkt) {
print atm_pkt.atm_hdr;
};
• In some cases the issue can be avoided by modifying the struct definition to use the correct when
subtype. For example:
var pkt: ATM packet;
// ...
print pkt.atm_hdr
• If the struct is known to be of the desired subtype, you might use .as_a(). For example:
print pkt.as_a(ATM packet).atm_hdr;
Note If pkt is not an ATM packet then pkt.as_a(ATM packet) returns a null struct.
8.3.1.4 list_assign
Syntax
conf[ig[ure]] back33 -list_assign=[TRUE | FALSE]
Bug Fix
Previously, after assigning a keyed list to a list, the key mapping for the keyed list did not update if there
was a change to the list (add, pop, push, delete, etc.). As a result, queries to the keyed list (key,
key_index, and key_exists pseudo-methods) might result in incorrect responses.
Previously, assigning a list to a keyed list might also result in incorrect responses to queries to the keyed
list.
Specman Elite 4.0 and later does not allow either explicit or implicit assignment of a keyed list to a list
or vice versa. The stronger type checking in Specman Elite 4.0 disallows the assignments that previously
led to incorrect responses.
Example
The following code parses without error in earlier releases of Specman Elite. However, the “check that
lk.key_exists(456)” generates a DUT error at runtime. In 4.0 and later, the “l = lk” assignment generates
a load-time or compile-time error.
<'

extend sys {
run() is also{
var lk : list (key: it) of int;
var l : list of int;
lk.add(123); // keys updated: static list's type is keyed list

check that lk.key_exists(123);
l = lk; // error in 4.0; assign between 'simple' list and keyed list
l.add(456); // keys not updated, static list's type is simple list

check that lk.key_exists(456);
};
};
'>

If -list_assign=FALSE, a load-time or compile-time error occurs if a keyed list is assigned to a list or
vice versa. A similar load-time or compile-time error occurs when passing a keyed list as a parameter
where a list is expected or vice versa.
If -list_assign=FALSE and the compatibility warning mode is on, a load-time or compile-time warning
is produced for each assignment.
If -list_assign=TRUE, no warning or error message occurs, regardless of whether the compatibility

warning mode is on or not.

*** Error: 'lk' is of type 'list (key: it) of int', while expecting type
'list of int'.
If this error did not arise in Specman Elite 3.x, you can also resolve
this error by using 'set_config(back33,list_assign,TRUE)'.
at line 12 in list_assign.e
l = lk;
For more information, search help for 'LIST_ASSIGN_ERR'

Preferred Solution:

• Use the as_a() pseudo-method to explicitly convert a list to a list with key and vice versa. For example:
var lk : list (key: it) of int;
var l : list of int;
l = lk.as_a(list of int);
Note The use of as_a() to convert a keyed list to a list or vice versa builds a new list and could impact
memory and CPU consumption.
Alternative Solution:
• If using the as_a() pseudo-method causes such a problem, change the type of the target list to match
the type of the source list.
8.3.1.5 disable_illegal_ignore_check
Syntax
conf[ig[ure]] back33 -disable_illegal_ignore_check=[TRUE | FALSE]
Bug Fix
The 4.0 and later releases provides stricter scope checking for the illegal and ignore coverage item
options.
In earlier releases, Specman Elite assumed that the expression in the illegal/ignore option referred only
to the item that uses the option and did not detect invalid items used in the expression. Specman Elite
accepted invalid items but did not sample them. Instead, it assigned arbitrary values to them while
evaluating the expression. This resulted in false coverage results without any warning.
The stricter scope checking in Specman Elite 4.0 enforces correct illegal/ignore definitions. This, in
turn, ensures correct coverage results.
Example
In earlier releases, the following code parses and runs without errors. While evaluating the illegal
expression for b2, Specman Elite would assign the value FALSE to b1 regardless of what its real value
was when b2 was sampled.
<'
extend sys {
!b1: bool;
!b2: uint(bits:4);
event info;
cover info is {

item b1;
item b2 using
illegal=(b2!=2) and (b1==TRUE); -- generates an error in 4.0
};
};
'>
To fix this example and ensure correct coverage results, you need to remove “b1” from the illegal item
option, for example:
item b2 using illegal=(b2!=2);

If -disable_illegal_ignore_check=FALSE and you use any invalid items in the expression of the
illegal/ignore coverage item option, Specman Elite issues a load-time error.
If -disable_illegal_ignore_check=FALSE and the compatibility warning mode is on, a load-time or

compile-time warning is produced for each assignment.
If -disable_illegal_ignore_check=TRUE, no warning or error message occurs, regardless of whether

the compatibility warning mode is on or not.
Note Due to some limitations in compilation, this check is applied only in interpreted mode and not in
compiled mode. This limitation will be removed in the next major release of Specman Elite.

*** Error: No such variable 'b1'
Suggestion: Use only the item 'b2' and constants in the illegal expression.
Note: The expression is also evaluated when showing coverage results.
at line 10 in ignore_check.e
illegal=(b2!=2) and (b1==TRUE);
For more information, search help for 'BAD_COV_II_DEF'

To migrate old code:
• Change any illegal/ignore expression that causes an error as follows:

For simple items Use only the item itself in the expression.
For transition items Use only the base item and the prev item in the expression.
For cross items Use only the base items of the cross.

Performance Enhancements
For additional information about the correct use of the illegal/ignore coverage options, see the FAQ
“Correct use of cover option ‘when’ vs. ‘ignore/illegal’” in the Verification Vault
(https://www.VerificationVault.com).
8.3.2 Performance Enhancements

The 4.0 release or later of Specman Elite contains some performance enhancements that change some
aspects of Specman Elite behavior.
The following section describes the compatibility issues related to usability enhancements, listed by the
back33 flag you can use to disable these enhancements:
disable_otf_gc on page 8-56 Specman Elite can now perform on-the-fly garbage
collection that applies during load, compilation, generation,
and within a Specman Elite tick.
There are two compatibility issues related to the new temporal engine that do not have back33 flags:
• “Restriction on Complex Temporal Expressions” on page 8-54

• “Restrictions on Temporal Expressions with consume()” on page 8-55
8.3.2.1 Restriction on Complex Temporal Expressions
Related Enhancement
Due to the nature of static analysis performed by the new temporal engine, there might be some
extremely rare and complex temporal expressions that cannot be translated by the new engine.
For more information on the kinds of complex expressions that may cause a problem, see “Translation of
Temporal Expressions” on page 13-10 in the e Language Reference.

*** Error: Temporal Exp analysis Capacity Overflow
at line 15 in complex_TE1.e
expect @a => {[..i];@b} or {[..j];@c} or {[..k];@d} or {[l..];@e};
*** Error: May not use a bounded repeat in the match part of a
first_match
event b is {[..i]; [j] *@a};
*** Error: Multiple successes in repeat part

event d is {[..n]*{@a or {@b;@b}};@c};

There is no back33 flag to revert Specman Elite behavior. The complex temporal expression must be
decomposed into several smaller temporal expressions.
If you have difficulty decomposing the complex temporal expression that is causing the error, contact
Verisity support for help.
In compatibility warning mode, this error is still an error, not a warning.
8.3.2.2 Restrictions on Temporal Expressions with consume()
Related Enhancement
The new temporal engine, which provides performance enhancements, restricts the use of the
consume() temporal expression for direct synchronization of TCMs:
• The consume(@event-name) temporal expression can only be used with the time-consuming actions
sync and wait. No other temporal operator can be used with it. Thus, only the following use is allowed:
sync consume(@event-name) [@sampling-event];
wait consume(@event-name) [@sampling-event];
For example, consume(cycle@event-name) is no longer allowed.
• An event can either be used by consume(@event-name) or in other temporal expressions, but not in
both.
The following code illustrates an illegal use of consume in 4.0:

<'
extend sys {
event a;
event b is [3] @a; -- illegal; event a is also used by consume
foo()@b is {
wait consume(@a);
};
};
'>


*** Error: Event 'a' cannot be used without 'consume', since it is used
with 'consume' in some other place.
Detected at line 4 in @consume1
event b is [3] @a;

There is no back33 flag to revert Specman Elite behavior. You must modify the code so that the event is
not used both by consume() and in some other temporal expression.
In compatibility warning mode, this error is still an error, not a warning.
For information on known limitations with temporals in Specman Elite 4.0, see “Temporal Evaluator” on
page 9-13.
8.3.2.3 disable_otf_gc
Syntax
conf[ig[ure]] back33 -disable_otf_gc=[TRUE | FALSE]
Related Enhancement
Specman Elite 4.0 supports a new memory manager.
Specman Elite can now perform on-the-fly garbage collection that applies during load, compilation,
generation, and within a Specman Elite tick. As a result, in some cases, tasks that previously caused a
memory overflow can now complete. The new on-the-fly garbage collection complements the
traditional garbage collection.

The new on-the-fly garbage collection might expose flaws in C code integrated with Specman Elite. In
the unlikely event that this happens, a segmentation violation occurs after a garbage collection.
The flaw could occur if the external C code keeps a reference to a Specman Elite object that is no longer
referenced from within Specman Elite. The new on-the-fly garbage collector reclaims this memory for
future allocations, and the stored reference becomes invalid. When the C code uses that invalid stored
reference to access the Specman Elite object, a segmentation violation might occur. Here is an example
of C code that stores a reference to an e object:
#include "generated_specman.h"

Usability Enhancements
static SN_TYPE(packet) static_stored_ref;
/*
* This method is called from Specman with an e object pointer (pckt).
*/
void my_c_method_stores_ref(SN_TYPE(packet) pckt) {
/*
* stores a reference to an e object. The stored reference might be used
* after garbage collection occurs. Using it will lead to errors.
*/
static_stored_ref = pckt;
}
As the on-the-fly garbage collection can now be performed irrespective of Specman Elite tick
boundaries, previously undetected flaws might be exposed.
Error Messages
Unlike regular garbage collection, no messages are printed when on-the-fly garbage collection is
executed. The problem with stored references, for example, shows up as a segmentation fault in the C
code.

Instead of storing references to Specman Elite objects in your C code, use e code for storing references.
To migrate old code:
1. Add fields to sys (or deeper) for storing the references to Specman Elite objects.
2. In your C code, access those objects through the e fields.
8.3.3 Usability Enhancements

The 4.0 release or later of Specman Elite contains some usability enhancements that change some
aspects of Specman Elite behavior.
The following sections describe the compatibility issues related to usability enhancements, listed by the
back33 flag you can use to disable these enhancements:

cover_mode on page 8-58 Some coverage mode names have changed and the default
coverage mode behavior has also changed.
disable_cover_events on page 8-59 4.0 supports automatic coverage of events.
tree_window on page 8-60 4.0 has a new Data Browser.
no_gen_in_write_stub on page 8-61 The write stubs command now causes generation, in
order to support computed names and non-static
expressions in HDL declarations.
use_trace_gen_33 on page 8-62 In 4.0, generation data is displayed in a graphical browser.
8.3.3.1 cover_mode
Syntax
conf[ig[ure]] back33 -cover_mode=[TRUE | FALSE]
Related Enhancement
For greater clarity and convenience, some coverage mode names have changed and the default coverage
mode behavior has also changed.
New coverage mode names

• The count_only mode is now called on
• The normal mode is now called on_interactive
In Specman Elite 3.3, the coverage mode names were misleading. Users tended to opt for normal mode
when count_only was and still is the recommended mode. The new names should resolve the earlier
confusion.
New coverage mode behavior

When you define coverage groups, the mode changes automatically to on (rather than remaining off as
happened previously)
In Specman Elite 3.3, users sometimes forgot to update the coverage mode after defining coverage
group. As a result, they received no coverage information. Specman Elite 4.0 automates this simple but
essential task so that the default coverage mode always corresponds with most users’ preferences.


This feature is fully backward compatible. It does not produce any syntax error. Using the old coverage
mode names is supported, as those names are automatically translated to the new names for what is
exactly the same behavior.
If you have user-defined coverage definitions in your code and you do not specify the coverage mode
explicitly, then coverage is now collected automatically. An ecov file is created at the end of the run.

Not applicable.

To disable collection of coverage data when you have user-defined coverage groups:
• Explicitly set the coverage mode to off. For example:

<'
extend sys {
setup() is also {
set_config(cover, mode, off);
};
};
'>
8.3.3.2 disable_cover_events
Syntax
conf[ig[ure]] back33 -disable_cover_events=[TRUE | FALSE]
Related Enhancement
Specman Elite 4.0 supports automatic coverage of events.
In Specman Elite 3.3, there was no easy way to collect coverage information on the events in your
environment. This 4.0 feature lets you collect coverage information about all events defined in your
environment automatically. The collected information tells if an event ever happened, and, if so, how
many times it happened.


An additional predefined coverage group named session.events is added to the environment, and that
coverage group appears in the coverage reports.
Any event in your environment is added automatically to the session.events group as a coverage item.
You can apply any coverage command (covers.set_cover(), covers.set_weight(), and so on) to the new
session.events coverage group.
The session.events coverage group is gradeable (unlike the other predefined coverage groups,
session.start_of_test and session.end_of_test). Therefore, the overall coverage grade for tests might
change.
The effect of setting this compatibility flag to TRUE differs depending on when you set the flag:
Before loading the environment Prevents Specman Elite from collecting event data
and defining events as items
After loading the environment Causes Specman Elite to ignore the session.events
group when grading

Not applicable.

There is no migration issue. You either take the new feature or turn it off.
8.3.3.3 tree_window
Syntax
conf[ig[ure]] back33 -tree_window=[TRUE | FALSE]
Related Enhancement
Specman Elite 4.0 has a new Data Browser.
The new Data Browser provides more detailed information on values of fields, events, and methods of
expressions. It also provides a friendly way to navigate the data hierarchy. You can open the Data
Browser using the old tree command or the new show data command.


Using the tree or show data command, clicking hyperlinks in a Specview window, or using the print
action in the Source Debugger now opens the Data Browser for the required expression, regardless of its
type. For example, selecting a scalar and clicking the Print button in the Source Debugger window opens
the Data Browser.
While the Data Browser has many advantages, it also has some known limitations that did not exist
when using the old tree command. If any of the following known limitations are essential to you, you
can set the tree_window back33 compatibility flag to On.
Print Config Options: The Data Browser ignores these two print config options.
• list_index_radix
• list_from
Print Config Option Once the Data Browser has been opened, it ignores changes to
this print config option.
• raw_print option
do_print() Extensions The Data Browser ignores all do_print() user extensions.
Displayed Methods The command show data <method> causes the method to be
executed at every Specman prompt.
Note This compatibility flag is relevant only in GUI mode (Specview). While working in ASCII mode,
the tree command behaves the same whether the back33 compatibility flag is on or off.

Not applicable.

This is a new feature unrelated to parsing code. There is no migration issue. You either take the new
feature or turn it off.
8.3.3.4 no_gen_in_write_stub
Syntax
conf[ig[ure]] back33 -no_gen_in_write_stub=[TRUE | FALSE]

Related Enhancement
Specman Elite 4.0 supports computed names and non-static expressions in HDL declarations.
Previously, the write stubs command might not cause generation. To support computed names and
non-static expressions in HDL declarations, the write stubs command now causes generation by
default.

Previously, if your e modules contained no units other than sys, the write stubs command did not cause
generation.
The drawback to the new default where the write stubs command always causes generation is the time
taken by generation. If your code does not contain any computed names or non-static expressions in
HDL statements or unit members, this new default behavior has no benefit.

There is no migration issue. You either accept the new behavior or you disable it by setting the
no_gen_in_write_stub flag to TRUE. If you set the flag to TRUE, computed names and non-static
expressions in HDL declarations are not supported.
Note If you turn the flag on and an HDL declaration includes a computed expression, you get a
load-time error like the following:
*** Error: Incorrect verilog variable declaration. Wrong specifier for
verilog variable declaration... "
8.3.3.5 use_trace_gen_33
Syntax
conf[ig[ure]] back33 -use_trace_gen_33=[TRUE | FALSE]
Related Enhancement
With Specman Elite 4.0, generation data is displayed in a graphical browser for more friendly navigation
and more powerful debugging. This replaces the old trace gen mechanism. The old mechanism had an
ASCII-based report format.


The trace gen command is replaced by the collect gen command. The command show gen now opens
the Generation Debugger window rather than the old ASCII tree displayed on the screen and in the log
file.
For descriptions of the 3.3 generation analysis commands, including trace gen, show gen, and config
gen, see the 4.0.5 Specman Elite documentation, available on the Verification Vault.

*** Warning: Cannot use 'trace gen':
use 'config back33 -use_trace_gen_33 = TRUE'
For more information, search help for 'SHOW_GEN_VIS_CANT_TRACE_GEN'
*** Error: 'show gen' for Generation Debugger can have only '-ascii' as
modifier.
To use 'trace gen' use 'config back33 -use_trace_gen_33 = TRUE'
For more information, search help for 'SHOW_GEN_VIS_ILLEGAL_SHOW_GEN'

If you use trace gen in your code, it must be replaced by collect gen.
If you issue a show gen command with parameters in your code, these parameters are no longer
supported and must be removed.
Enabling the use_trace_gen_33 compatibility flag lets you continue as before. If the text output of the
old trace gen command is required as a reference or the trace gen command itself is part of your
verification environment, then you must enable the use_trace_gen_33 flag.
8.4 Upgrading from Version 3.2

Specman Elite provides flags that let you revert some behavior to the 3.2 style. You set these back32
flags in the same way as the back33 flags. For more information, see “Setting Compatibility Flags” on
page 8-35.
Note None of these compatibility issues is identified with the compatibility warning mode. None can
be set from any installation script.
The following table describes all of the back32 options in brief.

Documentation for Fully Deprecated or Outdated Features
implicit_pack Implicit pack/unpack Implicit packing and unpacking of non-scalar structs

will be allowed.
old_error_handling Use 3.2 error The 3.2 error handling scheme will be used.
handling scheme
enable_verilog_ Enable verilog trace False verilog trace will be translated into wave event
trace commands.
bit_slicing_is_uni_ Bit slicing constraint Constraining bit slicing will impose order from right
directional imposes order from to left only.
right to left
add_slashes_in_ Add slashes in set Slashes will be added around the match string for set
set_check check check.
allow_enum_as_ Allow enum as index Enums will be allowed as indexes of lists.

index
use_quotes_in_ Allow double quotes Double quotes will be allowed around file names in
import_statements in import statements import statements.
struct_eq_is_uni_ Struct equality Constraining struct equality will impose order from
directional constraint imposes right to left only.
order from right to
left
index_is_uni_ Index constraint Constraining indexes will impose order from right to
directional imposes order from left only.
right to left
in_list_is_uni_ Item-in-list constraint Constraining items in lists will impose order from
directional imposes order from right to left only.
right to left
8.5 Documentation for Fully Deprecated or Outdated

Features
Documentation for features that have been fully deprecated or that are outdated is available on the
Verification Vault (www.verificationvault.com) at the following location:
Verification Vault ›› Knowledge Base ›› Product Documentation » Deprecated and Outdated Features

The “Deprecated and Outdated Features” section on the Verification Vault contains the following:
• deprecation_history.pdf, which contains a table showing the deprecation history for deprecation
notification IDs
• PDF documentation for outdated or fully deprecated features
Table 8-3 provides you with the names of the PDF documentation files.
Note At this time, no fully deprecated features require documentation. Thus, the PDF files listed in
Table 8-3 document outdated features only.
Table 8-3 Documentation for Outdated Features
Old Documentation on the

Feature Replaced By Verification Vault
sn_compile.sh -sim qvl sn_compile.sh -shlib 4.0.5_compiling_and_linking.pdf

-sim qvh
SPECMAN_LIBQVH SPECMAN_DLIB 4.0.5_compiling_and_linking.pdf

SPECMAN_LIBQVL
libqvhsn_basic.so libspecman.so 4.0.5_compiling_and_linking.pdf

libqvlsn_basic.so
libqvhsn.so libqvlsn.so libmti_sn_boot.so 4.0.5_compiling_and_linking.pdf
qvl_sn_pic_.o — 4.0.5_compiling_and_linking.pdf
qvh_sn_pic_.o
trace gen collect gen 4.0.5_gendebug.pdf
config gen — 4.0.5_gendebug.pdf

-show_on_trace
-show_repeats
-nesting
-prefix
-reduction_colors

Table 8-3 Documentation for Outdated Features
Old Documentation on the

Feature Replaced By Verification Vault
show gen — 4.0.5_gendebug.pdf

-scalar_fields
-reordering
-reductions
-constraints
-all
-details
-last
-window

9 Known Limitations
This chapter describes the known limitations for Specman Elite and the e language.
This chapter includes the following sections:
• “Language Limitations” on page 9-2

• “Coverage Limitations” on page 9-6
• “Generation Limitations” on page 9-7
• “Temporal Limitations” on page 9-13
• “TCM Limitations” on page 9-18
• “eRM Limitations” on page 9-20
• “Simulator Interface Limitations” on page 9-23
• “Debugger Limitations” on page 9-40
• “Data Browser Limitations” on page 9-43
• “GUI Limitations” on page 9-46
• “Help Limitations” on page 9-51
• “Waveform Viewer Limitations” on page 9-53
• “CVL Limitations” on page 9-56
• “OS Platform Limitations” on page 9-57
• “Miscellaneous Limitations” on page 9-59

Known Limitations
Language Limitations
9.1 Language Limitations

• “Macros Defining Macros Not Supported” on page 9-2
• “Extending TCMS” on page 9-2
• “Save and Restore Crash on Deeply Nested Structs” on page 9-3
• “Parse Limit on Bit Extraction” on page 9-3
• “Return from is first Not Recognized” on page 9-3
• “Gnu C Compiler (GCC) and Long Methods” on page 9-4
• “collect -reload Does Not Work” on page 9-4
• “deep_compare_physical() Incorrectly Flags Subtypes as Non-identical” on page 9-5
9.1.1 Macros Defining Macros Not Supported
Defect: 2932
Description
When a macro (for example, “define five 5;”) is defined inside another macro, the inner macro is not
recognized by the compiler.
Workaround
Currently, none.
9.1.2 Extending TCMS
Defect: NA
Description
After extending a TCM in a like child, that TCM cannot be extended in the parent.
Workaround
Avoid extending TCMs in children until all TCMs in the parent are extended.

Known Limitations
Save and Restore Crash on Deeply Nested Structs
9.1.3 Save and Restore Crash on Deeply Nested Structs
Defect: NA
Description
When a deeply nested struct structure is defined, save and restore may crash. Typically, this happens
when linked lists are used instead of built-in lists.
Workaround
Prefer built-in lists to linked lists. If necessary, use the indexes as pointers.
9.1.4 Parse Limit on Bit Extraction
Defect: 839
Description
If there are multiple colons in square braces, then the parser may report an error. For example:
print t[TRUE? 1:0:2]
Workaround
Use parentheses to make operator binding explicit. In the example:
print t[(TRUE? 1:0):2]
9.1.5 Return from is first Not Recognized
Defect: 745
Description
When an is first method extension changes the result value, extensions appearing earlier in the code do
not get the new value result.

Known Limitations
Gnu C Compiler (GCC) and Long Methods
Workaround
Currently, none.
9.1.6 Gnu C Compiler (GCC) and Long Methods
Defect: 3706
Description
When compiling a very long method, GCC may crash and terminate the compilation.
Workaround
Most crashes are caused by the GCC optimizer. Remove the optimization flag from your .specman file
and recompile your environment. If that does not solve the problem, split your method into several
methods using is also.
9.1.7 collect -reload Does Not Work
Defect: 533
Description
The collect -reload command does not work. Attempting to use this command results in an error
message.
Workaround
Currently, none.

Known Limitations
deep_compare_physical() Incorrectly Flags Subtypes as Non-identical
9.1.8 deep_compare_physical() Incorrectly Flags Subtypes

as Non-identical
Defect: 8456
Description
The deep_compare_physical() predefined routine flags two structs as non-identical if the when
determinant fields for the two structs differ, even if their physical fields are identical. Using the struct
member attribute to ignore the when determinant field during a physical deep compare does not affect
the incorrect output of the deep_compare_physical() routine.
Workarounds
1. Convert the two structs to the exact same subtype before calling deep_compare_physical().
2. Filter the result of deep_compare_physical() to ignore the subtype difference.
The example below illustrates both solutions:

<'
type kind_t : [good, bad];
struct foo {
kind : kind_t;
%pf1 : uint;
%pf2 : byte;
%pf3 : bit;
keep pf1 == 25;

keep pf2 == 4;
keep pf3 == 1;
when good foo {

vf1 : uint;
}; // when good
when bad foo {
vf2 : list of byte;
}; // when bad foo
}; // struct foo
extend sys {
goodfoo : good foo;
badfoo : bad foo;

Known Limitations
Coverage Limitations
post_generate() is also {
var diff : list of string;
diff = deep_compare_physical (goodfoo, badfoo ,10);
//solution 2
check that (diff.is_empty() or (diff.size()==2 and diff.has(it ~
"...foo...")));
//solution 1
var badfoocasted : good foo = new;
var lob : list of bit = pack(NULL, badfoo);
unpack (NULL, lob, badfoocasted);
diff = deep_compare_physical (goodfoo, badfoocasted ,10);
print diff;
}; // post_generate()...
}; // extend sys
'>
9.2 Coverage Limitations

• “Coverage for Long Types” on page 9-6
• “Coverage for like Inheritance” on page 9-7
9.2.1 Coverage for Long Types
Defect: 0758
Description
Coverage does not work for scalar item types (int, uint) with a length larger than 32 bits.
Workaround
Use an enum type to define the meaningful value ranges of the covered type. Map procedurally the
values of the long scalar type field into the enum type item.

Known Limitations
Coverage for like Inheritance
9.2.2 Coverage for like Inheritance
Defect: 2601
Description
If you use like inheritance, you cannot define or extend a coverage group for an event declared in the
parent struct.
Workaround
Use when inheritance.
9.3 Generation Limitations

• “Parameters Passed by Reference to TCMs” on page 9-7
• “as_a() in Constraints Is Not Supported” on page 9-8
• “Complex Constraints on List Items” on page 9-9
• “Multiple List-in-List Constraints on the Same List” on page 9-10
• “or Constraint Limitations” on page 9-10
• “Generation of Long Integers Can Consume More Memory Than Expected” on page 9-13
9.3.1 Parameters Passed by Reference to TCMs
Defect: 2903
Description
Parameters passed by reference to a TCM are not supported in constraints.
Example:
m(i : *int) : int @clk is {
gen result keeping { it == i };
};
This code produces an error message.

Known Limitations
as_a() in Constraints Is Not Supported
Workaround
Use a new local variable in the TCM constraints together with the corresponding assignments to or from
the parameter.
9.3.2 as_a() in Constraints Is Not Supported
Defect: 3161
Description
The generator cannot resolve constraints that use as_a() within a constraint path.
For example, the following constraint cannot be resolved:

packet_t: [SMALL, LARGE];keep p.as_a(SMALL packet).i == 5; // This
constraint cannot be resolved
In some cases, the generator identifies a contradiction. In other cases, it identifies an unsatisfied
constraint and issues an error message.
Workaround
Define the constraint within the object definition itself for the right subtype. For example:
type packet_t: [SMALL, LARGE];
struct packet {
kind : packet_t;
when SMALL packet {

i: int;
keep i == 5; // The constraint can be resolved.

};
};
‘>
In the first example, substitute a procedural assignment for the keep constraint.
In the second example, use gen before to control the ordering.

Known Limitations
Complex Constraints on List Items
9.3.3 Complex Constraints on List Items
Defect: 1163, 3237
Description
Some compound constraints on list items may lead to an undue contradiction. For example:
keep l[0] == 5 or l[0] == 6
Also, the combination of soft constraints and list-item constraints may also lead to undue contradiction.
For example:
keep l[0] == 45;
keep soft l == {1;2;3;4};
Finally, the combination of for each constraints and list-item constraints may also lead to undue
contradiction. For example:
keep soft l[0] == 1;
keep for each in l {
index == 0 => it == 0;
};
Workaround
In the first example, use keep for each in combination with the imply operator (=>).
In the second example, constrain the list size to ensure the existence of the constrained item:
keep l.size() >= 4;
In the third example, use for each in combination with the imply operator instead of the list constraint:
index == 0 => soft it == 1;
};
index == 0 => it == 0;
};

Known Limitations
Multiple List-in-List Constraints on the Same List
9.3.4 Multiple List-in-List Constraints on the Same List
Defect: 3541
Description
You cannot use the list-in-list constraint to keep a list in more than one (other) list. This situation is
reported as a contradiction.
Example:
keep l in {1;2;2}; keep l in {2;2;3}; -- causes contradiction
Note that this situation can be caused indirectly using list equality constraints:
keep l1 in l2;
keep l3 in l4;
keep l1 == l3; -- contradiction since l1 is in both l2 and l4
Workaround
Compute procedurally the intersection of all containing lists and use one list-in-list constraint to keep the
targeted list in the intersection.
9.3.5 or Constraint Limitations
Defect: NA
Description
If the same field appears in all of the alternatives of an or constraint and if at least one of those
alternatives relate the field to non-literals, then the generator may not infer the implied constraints and
ranges for that field.
Example:
x == 1 or x in [20..220];
is translated correctly into

x in [1,20..220]
but

Known Limitations
or Constraint Limitations
x == i or x == j
depends on the order of generation for i, j, and x. It might lead to a contradiction. For example, if i and j
are generated before x, then:
• If the value of i is NOT in the currently known range of values for x, then x == j is enforced.
• If the value of j is NOT in the currently known range of values for x, then x == i is enforced.
• If the values of i and j are both in the currently known range of values for x, then the generator does
NOT infer the resulting range for x, that is [i,j]). x is generated from its range, which will probably
lead to a contradiction.
Note that if i is generated before x, and x is generated before j, then if i happens to be != x, then x == j
(using generated value for x) is enforced when j is generated.
Workaround
There are several ways to work around this problem. You can define a Boolean field and use that field in
implication constraints to control the generation of x.
Note You must generate the Boolean field before generating x. For example:
struct packet {
x_is_i: bool;
i: uint;
j: uint;
x: uint;
keep x_is_i => x == i;

keep !x_is_i => x == j;
};
extend sys {
plist: list of packet;
};
For generating on the fly, you can also use a Boolean variable, for example:
<'
struct packet {
i: uint;
j: uint;
x: uint;
};
extend sys {

Known Limitations
or Constraint Limitations
run() is also {
var x_is_i: bool;
var p: packet;
gen x_is_i;
case x_is_i {
TRUE: {gen p keeping {.x == .i}};
FALSE: {gen p keeping {.x == .j}};
};
};
};
'>
Another solution is to put the or alternatives under different when subtypes, for example:
<'
struct packet {
x_is_i: bool;
i: uint;
j: uint;
x: uint;
when x_is_i packet {

keep x == i;
};
when FALSE'x_is_i packet {

keep x == j;
};
};
extend sys {
plist: list of packet;
};
'>
These workarounds have the advantage of letting you control distribution between or alternatives.

Known Limitations
Generation of Long Integers Can Consume More Memory Than Expected
9.3.6 Generation of Long Integers Can Consume More

Memory Than Expected
Defect: 4350
Description
The generation of long integers can sometimes consume more memory then expected. This memory is
reclaimed only at the next garbage collection.
Workaround
When possible, use 32-bit integers rather than long integers.
9.4 Temporal Limitations

• “Temporal Evaluator” on page 9-13
• “Premature Evaluation of Expressions under not” on page 9-14
• “change, fall, rise, true Behave Differently” on page 9-14
• “Multiple Callbacks in Same Time Unit” on page 9-15
• “on Methods Before Event Declaration” on page 9-16
• “Temporals in Variable Structs” on page 9-17
• “VHDL Variables in @sim Expressions” on page 9-17
9.4.1 Temporal Evaluator
Defect: NA
Description
delay() can only be used in:
wait delay(N)
sync delay(N)
event a is {@b; delay(N)}

Known Limitations
Premature Evaluation of Expressions under not
Workaround
When possible, split the temporal expression into multiple temporal expressions.
9.4.2 Premature Evaluation of Expressions under not
Defect: 2619
Description
Expressions under not may be evaluated when the containing temporal expression is first evaluated,
even in the case of a sequence. For example, consider the sequence:
{@A; @B; not @C}
The evaluation of @C may happen as soon as @A is evaluated. While normally resulting in a correct
temporal evaluation, this may cause an error in cases where @C is not ready for evaluation (for
example, when it contains a NULL path).
Workaround
Make sure that expressions under not are accessible for evaluation from the onset of the temporal
expression.
9.4.3 change, fall, rise, true Behave Differently
Defect: 3032, 1845, 3049
Description
When the operators change, fall, rise or true are used to observe e expressions (in contrast with HDL
expressions) and when the watched expressions may change during the temporal evaluation phase (that
is, some event evaluation may change the expression value), the result might differ for optimized versus
non-optimized temporal expressions.
This behavior is consistent with Specman Elite versions 3.1.x.
Note that optimization is done for such expressions that are not sub-expressions and have no exec blocks
attached.

Known Limitations
Multiple Callbacks in Same Time Unit
Workaround
If at all possible, the situation in which values change during the temporal evaluation phase should be
avoided.
However, if desired, the optimization of a temporal expression can be avoided by adding an empty exec
block to that expression.
9.4.4 Multiple Callbacks in Same Time Unit
Defect: 2675, 2802
Description
When Specman Elite works with a simulator, it may be called back several times within the same
simulation time unit. Some reasons for this may be:
• A zero-delay task was called during the first tick, creating another tick upon return.
• One clock system transition caused the first tick; and, upon completion, another clock system
transition (in another delta-cycle of the simulator) caused the second tick.
(The term tick is used above for Specman Elite computation following a callback from a simulator.)
While multiple callbacks during the same simulation time unit are considered normal behavior, they
may cause premature success of negated events. All temporal expressions evaluated during the first tick
assume non-present events to have not happened, although some of them may actually be emitted during
later ticks.
This conceptual problem cannot be overcome automatically. The user must use the correct event to
sample such expressions so that they will be evaluated during the appropriate tick.
For example, in the following code the no_sig_up event happens in the same cycle as the sig_up event,
although it looks like a contradiction:
event clk is rise('top.clk') @sim;
event sig_up is rise('top.sig') @sim;
event no_sig_up is not (@sig_up) @clk;
Use the echo event full to see the presence of multiple ticks. For example:
--------------------------------------------------
-> 100 sys-@2.new_time
-> 100 sys-@2.tick_start <= First tick
-> 100 simulator-@4. top.clk <= Sampling event for no_sig_up
-> 100 sys-@2.any

Known Limitations
on Methods Before Event Declaration
-> 100 my_struct-@1.clk

-> 100 scheduler-@3.NEG
-> 100 my_struct-@1.no_sig_up <= sig_up event not found
-> 100 sys-@2.tick_end
-> 100 sys-@2.tick_start <= Second tick
-> 100 simulator-@4. top.sig
-> 100 sys-@2.any
-> 100 my_struct-@1.sig_up <= sig_up event occurs late
-> 100 scheduler-@3.NEG
-> 100 sys-@2.tick_end
--------------------------------------------------
The sig_up event only occurs at the second tick in the cycle while the clk sampling event occurs at the
first tick of the cycle.
Workaround
Sample each temporal expression with the event that is expected at the specific tick (for example, the
specific clock system transition). Do not use generic events (such as sys.any) when working in a
multi-clock environment.
For example, add a dummy clock to the HDL:

reg dummy_clk;
always @clk
dummy_clk <= clk;
Use the dummy clock to define the sampling event:

event clk is rise( top.dummy_clk ) @sim;
9.4.5 on Methods Before Event Declaration
Defect: 3197, 3320
Description
Definition of an on method before its event declaration results in a load time error message.
Workaround
Define the event before its on method. If necessary, a forward definition of the event can be used and
extended later (using is only).

Known Limitations
Temporals in Variable Structs
9.4.6 Temporals in Variable Structs
Defect: 3646
Description
Structs that are declared as variables within methods and that have no path from sys pointing to them
will not have quit (event and method) done in them as a result of stop_run().
Moreover, if those structs are created before the run phase, the run() method will not run in them and no
expect or event will be done in them.
Workaround
Create a call to the struct’s quit() method when the struct is no longer needed. If some structs may be
still active when stop_run() is called, maintain a list of active structs, and keep the list in a struct
accessible from sys. In that way, the quit() of each struct is called when stop_run() is called.
9.4.7 VHDL Variables in @sim Expressions
Defect: NA
Description
You cannot use a VHDL variable in an @sim temporal expression.
Workaround
Use a VHDL signal instead.
9.4.8 Compound Temporal Expressions with @sim
Defect: 6914
Description
Compound temporal expressions that contain @sim sub expressions may be evaluated incorrectly. For
example:

Known Limitations
TCM Limitations
event a is rise('sig1')@sim or rise('sig2')@sim;
Workaround
Split the compound TE into a few simpler ones. For example the compound temporal expression show
above can be split to:
event rise_seg1 is rise('sig1')@sim;
event rise_seg2 is rise('sig2')@sim;
event a is @rise_seg1 or @rise_seg2;
9.5 TCM Limitations

• “try Action Does Not Work in TCMs” on page 9-18
• “Debugger Might Not Stop when Exiting a Called TCM” on page 9-19
• “Fork Branches and State Machine Transitions” on page 9-19
• “stop_run() Does Not Stop” on page 9-19
9.5.1 try Action Does Not Work in TCMs
Defect: 302
Description
The try action is not implemented in TCMs. A corresponding error message is issued at the compilation
stage.
Workaround
Add explicit code for returning from a TCM in erroneous situations.

Known Limitations
Debugger Might Not Stop when Exiting a Called TCM
9.5.2 Debugger Might Not Stop when Exiting a Called TCM
Defect: 984
Description
In some situations, the debugger is expected to stop just before exiting a TCM (for example, when it is
at the last line of the TCM and you issue a next or step command). This does not work when the current
TCM (A) calls another TCM (B) and (B) in its last action calls a third TCM (C). In that case, the
debugger can stop at the end of C but not at the end of B. This is because of an optimization made in
Specman Elite’s TCM interpreter that causes a return from C to skip over a return to B and go directly to
A.
Workaround
Currently, none.
9.5.3 Fork Branches and State Machine Transitions
Defect: 2652
Description
If two or more branches of all of or first of are activated within the same clock cycle, the order of
activation is unpredictable. This situation also applies for state machine transitions.
Workaround
If the order of activation is important for correct behavior, you should provide additional flags and
conditions to dictate the order.
9.5.4 stop_run() Does Not Stop
Defect: 2927
Description
stop_run() does not stop when issued from on tick_start.

Known Limitations
eRM Limitations
In the following example, the message “Last specman tick - stop_run() was called” is issued, but
simulation is not stopped. Eventually, the simulation may hang.
Example:
<'
extend sys {
!count: int;
on tick_start { count += 1; if count > 3 { stop_run(); }; };
};
'>
Workaround
Invoke stop_run() from any place other than on tick_start.
9.6 eRM Limitations

• “Running Old Specman Elite Code” on page 9-20
• “Specman Elite Backward Compatibility Flags” on page 9-21
• “Encrypted Code and the e Source Code Debugger” on page 9-22
• “Mixing load and test Commands” on page 9-22
• “Using in_sequence() and in_unit() in Complex Constraints” on page 9-23
• “Using Nested Messages” on page 9-23
9.6.1 Running Old Specman Elite Code
Defect: NA
Description
There is a chance that some names in older Specman Elite code, developed prior to introducing eRM,
will clash with the new types or syntax added by the eRM library. If this happens, you must change those
names in your code.
Workaround
You can use #define and #undef to allow old code to coexist with new code.

Known Limitations
Specman Elite Backward Compatibility Flags
See Also
• #define on page 20-5 in the e Language Reference
• #undef on page 20-8 in the e Language Reference.
9.6.2 Specman Elite Backward Compatibility Flags
Defect: NA
Description
Some Specman Elite backward compatibility flags cannot be used in conjunction with eRM.
The following flags from the back33 group are incompatible with eRM and must not be set if you load
any eRM packages:
• old_struct_member_under_when and old_method_extension:

These flags affect the behavior of TCMs with multiple extensions. Setting these flags interferes
with method extensions within subtypes. eRM sequences use TCMs extensively, with many
extensions of sequence subtypes and extensions of the body() method for specific subtypes.
Setting these flags with eRM code can cause some TCM extensions to be overlooked (not visited),
typically with no error message emitted.
• no_reorder
This flag relates to old ordering of temporal behavior. Setting this flag will make rerun() fail to
work correctly, and some temporal evaluations may be overlooked.
All other back33 flags can be used as required.
All back32 flags, which emulate Specman Elite 3.2 behavior, are incompatible with eRM and must not
used.
See Also
• “Setting Compatibility Flags” on page 8-35

Known Limitations
Encrypted Code and the e Source Code Debugger
9.6.3 Encrypted Code and the e Source Code Debugger
Defect: NA
Description
While using the e source code debugger, you might step into encrypted code, like that in evc_util, which
cannot be seen. In such a case, the debugger code window shows a message like:
SOURCE FILE IS NOT AVAILABLE
( FILE IS ENCRYPTED )
Workaround
Use the debugger command Next instead of Step, unless you explicitly want to “step” into a
user-defined method. If you accidentally step into encrypted code, get out of it by clicking:
• Finish—to go to the end of current encrypted method

• Next—to step back into user code
Alternatively, you can go to the method call stack, click on a user method, set a temporary breakpoint
(break once) on a line as the target for stopping, and click Continue to have the debugger run until it
stops there.
9.6.4 Mixing load and test Commands
Defect: NA
Description
vt_util (once compiled or loaded into Specman Elite) does not let you do the following sequence of
commands:
1. Issue the test command.
2. Load additional e files.
3. Issue test again. (This test is blocked.)
Workaround
Execute restore before loading additional files.

Known Limitations
Using in_sequence() and in_unit() in Complex Constraints
9.6.5 Using in_sequence() and in_unit() in Complex

Constraints
Defect: NA
Description
Some complex constraints currently fail to handle in_sequence() and in_unit() properly and produce a
contradiction.
Workaround
It is recommended to use these constructs only in:
• Simple constraints
• Simple implications, such as:
keep in_sequence(red seq) => me.kind == red;"
• procedural code, for example, in post_generate().
9.6.6 Using Nested Messages
Defect: NA
Description
The message() and messagef() actions can be nested. In other words, you can put a message action
within the action block of another message action. In that case, each message action is handled by its
respective logger, not necessarily the same logger. The order of execution is currently uncertain.
Workaround
If order of execution is critical, avoid using nested messages.
9.7 Simulator Interface Limitations

• “Integration of Specman Elite and Cadence LDV 5.X Fails on HP-UX” on page 9-25
• “No Support for NC SystemC as Top Module in Mixed Environment” on page 9-25

Known Limitations
Simulator Interface Limitations
• “Verilog-XL Limitation: Failure After Forcing a Verilog Register from e” on page 9-26
• “NC Verilog Limitation: Wrong Sampling of Verilog Registers” on page 9-26
• “Force/Release Actions in e with NC VHDL 5.x Behave Inconsistently” on page 9-27
• “NC VHDL LImitation: No Update of Windows at Prompt” on page 9-27
• “NC VHDL LImitation: VHDL Drivers” on page 9-28
• “ModelSim and Specman Elite Exit Code for License Failures” on page 9-28
• “SpeedSim Limitation: Verilog Memories” on page 9-29
• “SpeedSim Limitation: Verilog Tasks and Functions” on page 9-29
• “SpeedSim Limitation: Forced Driving of Verilog Signals” on page 9-29
• “SpeedSim Limitation: Ungraceful Exit from Simulator” on page 9-30
• “SpeedSim Limitation: Specview Windows Not Updated” on page 9-30
• “Null Simulator Limitation: Sampling HDL-Style Variables” on page 9-30
• “Null Simulator Limitation: Unit Relative Paths and Full HDL Paths” on page 9-31
• “Null Simulator Limitation: X/Z Literals” on page 9-31
• “Null Simulator Limitation: Read/Write Race Conditions” on page 9-31
• “Time Literals Do Not Propagate into the Verilog Stub File” on page 9-32
• “Cannot Set Callback on Expanded Verilog Net” on page 9-33
• “Lists of Unit Instances” on page 9-33
• “Escaped Verilog Identifier Limitations” on page 9-33
• “Wrong Sampling in Mixed Verilog/VHDL Environment” on page 9-35
• “trace on special event” on page 9-36
• “Verisity Adapters Known Limitations” on page 9-37
• “ESI Limitations” on page 9-39

Known Limitations
Force/Release Limitation on ModelSim 5.7
9.7.1 Force/Release Limitation on ModelSim 5.7
Defect: N/A
Description
ModelSim 5.7 introduces a limitation where a VHDL IN port associated at a higher level to Verilog
register or wire cannot be forced. ModelSim issues the following error:
Error: (vsim-3456) Cannot force an input port that is mapped at a higher

level.
9.7.2 Integration of Specman Elite and Cadence LDV 5.X

Fails on HP-UX
Defect: RQST017159 and Cadence PCR 650606
Description
Sometimes an integration fails on HP-UX with one of the following error messages:
ncsim: *internal* (
sv_seghandler - SIGSEGV while handling SIGSEGV)
or
ncsim: *internal* (sv_bushandler - SIGBUS fault address not odd
This problem is fixed by Cadence in release LDV5.0s11 and later.
9.7.3 No Support for NC SystemC as Top Module in Mixed

Environment
Description
Specman Elite and NC SystemC do not support access to mixed SystemC/Verilog or SystemC/VHDL
designs if SystemC is the topmost module and an RTL component (Verilog or VHDL) is instantiated in
it.

Known Limitations
Verilog-XL Limitation: Failure After Forcing a Verilog Register from e
Any attempt to issue a call sn command from the NC interactive prompt causes the following error
message:
ncsim> INTERNAL ERROR: VPI UNKTYPE
Unknown type: (243).
9.7.4 Verilog-XL Limitation: Failure After Forcing a Verilog

Register from e
Description
Integrated Specman Elite and Verilog XL 5.X fail sometimes with the following error message:
**** Fatal error - leaving Specman:
Internal Specman error: unhandled OS signal 11 (segmentation violation).
This failure happens after forcing a Verilog register from e.
9.7.5 NC Verilog Limitation: Wrong Sampling of Verilog

Registers
Defect: NA
Description
When sampling Verilog registers at a clock edge, Specman observes new signal values, assigned on the
Verilog side by non-blocking assignments. This makes the sampling results inconsistent with all other
supported Verilog simulators. Also these values often contradict the user's expectations.
This problem does not exist with old NC Verilog versions. It appears only starting from Cadence release
LDV 2.2.

Known Limitations
Force/Release Actions in e with NC VHDL 5.x Behave Inconsistently
Workaround
Use NC Verilog LDV3.20s6 and later with the '-NBASYNC' command line option. You can use earlier
versions of NC Verilog back to LDV3.0s13, but you might encounter problems with the '-NBASYNC'
command line option in those earlier versions.
9.7.6 Force/Release Actions in e with NC VHDL 5.x Behave

Inconsistently
Description
Force/release actions in e with NCVHDL 5.X behave inconsistently, depending on how the test
command is issued.
The default behavior of the release action with the latest versions of the tools is that the last forced value
must be discarded and the VHDL signal must receive the current simulated value.
In contrast with the above, if you include the Specman Elite test command in the sequence of
pre-commands, some VHDL signals after release may retain the last forced value. This happens
regardless of the way you activate the pre-commands, either using specview -p or setting the UNIX
environment variable SPECMAN_PRE_COMMANDS.
Workaround
Move the test command to a command file, either the Specman Elite ecom file or the simulator
command file.
9.7.7 NC VHDL LImitation: No Update of Windows at Prompt
Defect: NA
Description
When simulation stops at the simulator prompt because of a breakpoint or because the simulation time
is elapsed, Specview does not update the last prompt shown in the main window and does not update its
thread debugger windows. This problem is caused by NC VHDL’s lack of callback capability.

Known Limitations
NC VHDL LImitation: VHDL Drivers
Workaround
Switch manually to the Specman prompt.
9.7.8 NC VHDL LImitation: VHDL Drivers
Defect: NA
Description
The new unit member in the Specman Elite 3.3 VHDL driver is not supported by NC VHDL.
Workaround
Add a “shadow” VHDL signal for the driven one and add an auxiliary concurrent signal assignment:
driven_sig <= driven_sig_shadow;
9.7.9 ModelSim and Specman Elite Exit Code for License

Failures
Defect: NA
Description
When linked with simulators other than ModelSim, Specman Elite exits with a code -5 exit status (code
251 in unsigned format) if a Specman Elite license failure occurs.When linked with ModelSim,
Specman Elite does not influence the exit code when a Specman Elite license failure occurs.
Workaround
None at this time

Known Limitations
SpeedSim Limitation: Verilog Memories
9.7.10 SpeedSim Limitation: Verilog Memories
Defect: NA
Description
There is no access to Verilog memories.
Workaround
Add auxiliary Verilog code to communicate between Specman and Verilog memories via single
registers.
9.7.11 SpeedSim Limitation: Verilog Tasks and Functions
Defect: NA
Description
Verilog tasks and functions are not supported. (Note that calls to tasks that advance simulation time are
not allowed by SpeedSim.)
Workaround
Add auxiliary Verilog code to initiate Verilog tasks following signals controlled by Specman.
9.7.12 SpeedSim Limitation: Forced Driving of Verilog

Signals
Defect: NA
Description
Forced driving of Verilog signals is not supported.
Workaround
Use SpeedSim commands in ecom files.

Known Limitations
SpeedSim Limitation: Ungraceful Exit from Simulator
9.7.13 SpeedSim Limitation: Ungraceful Exit from Simulator
Defect: NA
Description
There is an ungraceful exit from the simulator when Specman is exited.
Workaround
Exit from the simulator prompt.
9.7.14 SpeedSim Limitation: Specview Windows Not Updated
Defect: NA
Description
Specview windows are not updated when SpeedSim is stopped at its prompt.
Workaround
Switch manually to the Specman prompt.
9.7.15 Null Simulator Limitation: Sampling HDL-Style

Variables
Defect: 4476
Description
Sampling of the same HDL-style variable returns different values when the same object is accessed
directly or through a computed name.
Workaround
Currently, none.

Known Limitations
Null Simulator Limitation: Unit Relative Paths and Full HDL Paths
9.7.16 Null Simulator Limitation: Unit Relative Paths and Full

HDL Paths
Defect: 4099
Description
Unit relative paths are not concatenated with full HDL paths of the unit instances
Workaround
Currently, none.
9.7.17 Null Simulator Limitation: X/Z Literals
Defect: 3309
Description
X/Z literals cannot be correctly assigned.
Workaround
Currently, none.
9.7.18 Null Simulator Limitation: Read/Write Race Conditions
Defect: NA
Description
Read/write race conditions may occur for HDL-style variables, because driven values become
immediately visible for sampling.
Workaround
Currently, none.

Known Limitations
Time Literals Do Not Propagate into the Verilog Stub File
9.7.19 Time Literals Do Not Propagate into the Verilog Stub

File
Defect: NA
Description
.There are two ways to create delayed assignments for Verilog signals:
• For “tick” notation, you use verilog variable using drive =.

• For external simple ports, you use the attribute verilog_drive().
Both constructs accept a delay written as a string.
However, the actual Verilog time scale of the DUT is unknown to Specman Elite when the stubs file is
created. Hence, Specman Elite cannot convert time literals into correct numeric values in the stub file.
Example:
<’
extend sys {
delay: string;
keep delay == append("#",10 ns);
verilog variable ’my_ver.my_wire’ using wire,drive=delay;
};
>
Although the code in this example is legal syntactically, it does not create a correct stubs file. An error
message is issued during the test phase, telling you that the checksum for the above verilog variable is
incorrect.
Workaround
None.

Known Limitations
Cannot Set Callback on Expanded Verilog Net
9.7.20 Cannot Set Callback on Expanded Verilog Net
Defect: 2928
Description
Specman Elite does not support temporal expressions with @sim for expanded vector nets. The nets are
considered expanded if their slices are accessed anywhere in the DUT or in Specman Elite.
Workaround
First, evaluate whether the net in question must be sampled @sim. Unless it represents an asynchronous
signal, sampling @clk is better. If it is an asynchronous signal, add single-bit signals in Verilog, attach
them to the relevant net, and then modify the temporal expression in Specman Elite so that it uses those
additional signals instead of the original net.
9.7.21 Lists of Unit Instances
Defect: 3328
Description
Lists of unit instances with unconstrained HDL paths cause an illegal Verilog stub file (specman.v file)
to be produced.
Workaround
Add empty HDL path strings to constrain every unit instance.
9.7.22 Escaped Verilog Identifier Limitations
Defect: NA
Description
There are limitations on the special characters that can appear in escaped Verilog identifiers:

Known Limitations
Escaped Verilog Identifier Limitations
Limitations for escaped Verilog identifiers enclosed in single quotes

The following limitations apply for the use of special characters in escaped Verilog identifiers enclosed
in single quotation marks (identifying literal names):
• Escaped Verilog identifiers in single quotes cannot contain any of the following characters:
! " ' , ; ` { }
For example, the following is not supported:
’top.\!sig ’
• Escaped Verilog identifiers in single quotes cannot contain the character pairs -- and // (which indicate
the beginning of an e comment).
• Escaped Verilog identifiers in single quotes can contain parentheses () and brackets[], as long as they
are balanced and the single quotes do not enclose an (unescaped) computed part of the name.
For example, the following signal access causes a syntax error.
unit top {
path : string;
x() is {
-- ’path’ is a computed name while
-- ’sig(0:8)’ is a literal identifier
’~/(path).\sig(0:8) ’ = 1; -- not supported.
-- The sig(0:8)is okay,
-- but the (path) is not okay
};
};
Limitations for escaped Verilog identifiers enclosed in double quotes

There are fewer limitations on the use of special characters in escaped Verilog identifiers enclosed in
double quotation marks (for example, when using strings with computed names or using hdl_path()
with ports):
• In regular HDL access, escaped Verilog identifiers enclosed in double quotation marks cannot contain
the following two characters:
" `
• When the HDL object is defined as a port, only one character is not allowed in Verilog escaped
identifiers enclosed in double quotation marks:
`

Known Limitations
Wrong Sampling in Mixed Verilog/VHDL Environment
Note The characters " (if supported) and \ require an additional \ preceding each appearance of
them when they appear in escaped Verilog identifiers within double quotes.
Workaround
if you are able to reference a given escaped Verilog identifier in double quotes, rather than in single
quotes, the limitations are fewer.
For example, although the following is not supported:

unit top {
path : string;
x() is {
-- ’path’ is a computed name while
-- ’sig(0:8)’ is a literal identifier
’~/(path).\sig(0:8) ’ = 1; -- not supported.
};
};
The following rework of the above example is supported:

<'
unit top {
sig : string;
keep sig == "\sig(0:8) ";
path : string;
keep path == "top";
x() is {
’~/(path)/(sig)’ = 1;
};
};
'>
Otherwise, there is no workaround.
9.7.23 Wrong Sampling in Mixed Verilog/VHDL Environment
Defect: NA
Description
Specman samples wrong Verilog signal values when all the signal assignments are done within an
instantiated VHDL component.

Known Limitations
trace on special event
For example:
+-----------------------------+
| Verilog |
| +------------------+ |
| | | |
| | VHDL | |
| input | | |
| ------>| ... | |
| output | | |
| <------| output <= input | |
| | | |
| +------------------+ |
+-----------------------------+
In the above example, Specman samples the same (new) values for output and input, even if a sampling
event is set to a change of input @sim.
Workaround
NCSim: Add any signal assignment in Verilog code, triggered by change of the above 'input'. (For
example, such assignment may be added in a specman.v file.) Then, use NC Verilog LDV3.0s13 and
later with the '-NBASYNC' command line option.
Modelsim: Add a “shadow” register in Verilog and connect it to the sampled signal using non-blocking
assignment. Then, sample the “shadow”.
9.7.24 trace on special event
Defect: NA
Description
Entering a trace on special-event command with a signal name or a wildcard does not work. The full
signal name is not accepted. The wildcard is accepted but does not print a trace message. For example:
Specman xor_verify> trace on sim_write xor_try.inp
trace on sim_write xor_try.inp
*** Warning: 'sim_write xor_try' is not a struct
Specman xor_verify> trace on sim_write 'xor_try.inp'
trace on sim_write 'xor_try.inp'

Known Limitations
Verisity Adapters Known Limitations
*** Warning: 'sim_write 'xor_try' is not a struct
Workaround
Set a trace without a signal name or wildcard. For example:
Specman xor_verify> trace on sim_write
-> 8250 sim_write -> xor_try.inp = 0 at line 16 in @xor_verify
9.7.25 Verisity Adapters Known Limitations
9.7.25.1 Port Limitations

The adapters provided by Verisity have the following limitations related to ports:
• The unification of ports and 'HDLpathname' access is not fully implemented in Verisity adapters.
Writing to the same signal via different ports or mixing 'HDLpathname' access with port access can
cause race conditions, as well as unnecessary performance penalty and memory consumption.
• Support for point-to-point connections is between ports only, in other words, each port can be
connected to only one other port.
• Simple ports of int(bits: *) are not supported.
• Use of @sim with simple ports is supported only for those ports whose element type is scalar.
• External buffer ports are not supported.
• There is no support for passing structs or lists of struct through external simple ports.
• External out and inout event ports are not supported.
• Support for event ports is incomplete:
• The on struct member for event ports is not supported.
• Coverage on event ports is currently unsupported.
• The echo event command is not supported for event ports.
• It is impossible to specify a temporal formula (like “event_port is …”) for definition of an out
event port.
In order to use any of the above unsupported capabilities for event ports it is possible to define an
additional event and connect it to the event port as follows:
ep: in event_port is instance;

Known Limitations
Verisity Adapters Known Limitations
keep bind(ep,external);
event e is @ep$;
• Specman Elite currently does not support soft binding of ports, and no error message is issued to
indicate this. If you enter constraints in the form keep soft bind …, they are automatically (and
silently) converted to the hard constraint in the form keep bind ….
Note As of release 4.3.3, the keep soft bind syntax is being deprecated. For more information, see
Chapter 8 “Deprecation and Backward Compatibility for this Release”.
• The port attribute driver_delay() is currently ignored by Verilog adapters and does not affect the
stubs file.
Suggested workaround: use the attribute verilog_drive() instead.
• You cannot bind a port to a part select of an external signal. It must be bound to the entire signal.
The declared_range() must also match the actual range of the signal; it cannot be a part select.
However, assignments to a part select of a simple external port are allowed, for example:
outp$[31:16] = data;
• The list slicing operator [..], the list indexing operator [], and the field access operator are not supported
for ports in LHS expressions. In other words, p$[l..h], p$[i], and my_unit.p$ are not supported on
the LHS of an assignment operator.
• You cannot bind an external port to a Verilog memory or a VHDL multi-dimensional array. Use the
tick access syntax to read and write these objects.
• Unpacking to output ports or inout ports is not supported. The error messages are not consistent:
unpack(packing.high, cc, my_inoutport$);
*** Error: Expression 'my_inoutport.do_get()' is not assignable.
unpack(packing.high, cc, my_outport$);

*** Error: Trying to read from 'out' port 'my_outport'
Note Unpacking to an HDL signal using tick access is also unsupported:
unpack(packing.high, cc, 'vv');
• When an out TCM method port is killed from e code (for example, when using first of), any SystemC
function that is bound to this method port cannot be killed. Its execution continues until its normal
stop. The method port cannot be called again from e until the SystemC function completes execution.

Known Limitations
ESI Limitations
9.7.25.2 ‘test” in Pre-commands Fails for NCSIM Mixed Verilog/VHDL
Defect 8108
Description
In an NCSIM mixed Verilog/VHDL environment in which adapters are dynamically loaded, the test
command fails if it is called from the -pre_commands option or from
$SPECMAN_PRE_COMMANDS.
Workarounds
• Remove the test command from the pre_commands option or from
$SPECMAN_PRE_COMMANDS and put it, for example, in the simulator command file. The
simulator command might be, for example
call sn "test"
• Set the SPECMAN_ADAPTERS_NUMBER UNIX environment variable to 2 before running

Specman Elite, where two is the number of adapters, one for Verilog and one for VHDL. For example,
for C shell:
% setenv SPECMAN_ADAPTERS_NUMBER 2
For Bourne shell:
% SPECMAN_ADAPTERS_NUMBER=2;export SPECMAN_ADAPTERS_NUMBER
9.7.26 ESI Limitations

Following are the ESI limitations:
• “Development of Proprietary Adapters” on page 9-39

• “‘test” in Pre-commands Fails for NCSIM Mixed Verilog/VHDL” on page 9-39
9.7.26.1 Development of Proprietary Adapters

ESI currently does not allow fully independent development of proprietary adapters. Instead, Verisity
partners must link proprietary ESI binary files with the framework object file shipped by Verisity. The
framework object includes utilities such as Specman Elite initialization, I/O utilities, save/restore, and
interactive prompt.

Known Limitations
Debugger Limitations
Figure 9-1 shows the structure of a Specman Elite integration in GSI phase 1. As shown in Figure 9-1,
some of the framework utilities use the simulator’s proprietary interface (Verilog PLI, VHPI, FLI, etc.).
Other utilities use a non-standard interface that varies from simulator to simulator.
Figure 9-1 Phase 1 Integration
Specman Elite ADAPTER SIMULATOR
Framework
SIM
Port or IF
ESI object
tick
access functions
access
In phase 1, for each of the supported simulator interfaces, Verisity ships:
• A full-blown adapter, as shown in Figure 9-1, developed by Verisity

• The framework as an object file
The adapters developed by Verisity work transparently for external ports and for old HDL tick access
notation so that existing e code remains fully functional. Because the lower level of Verisity’s Verilog
ESI adapters use the same low-level methods (such as Verilog PLI, command line arguments passing,
initialization points) as the older Specman Elite interfaces, all of the already existing proprietary
simulator interfaces continue working with the adapters without any changes. Moreover, these existing
simulator interfaces implicitly support simple e ports of scalar type.
To enhance DUT object access and to improve run-time performance, VIP partners can develop
proprietary ESI object access functions and link these functions with the framework, thus creating a new
adapter.
9.8 Debugger Limitations

• “finish Command” on page 9-41
• “Abort Commands” on page 9-41
• “Calling Methods of the Current Struct” on page 9-42
• “Conditional Breakpoints” on page 9-42
• “Debugging TCMs That Return a Value” on page 9-42

Known Limitations
finish Command
• “on event Blocks” on page 9-43
9.8.1 finish Command
Defect: 3521
Description
Sometimes, the finish command fails to stop at the end of a TCM. This happens only in TCMs that are
called by other TCMs.
Workaround
Currently, none.
9.8.2 Abort Commands
Defect: 3434
Description
At the debugger prompt, if you use a command that causes Specman Elite to abort (for example, abort,
reload, or restore), it must be the only command on your command line.
For example:
reload -- OK
test -- OK
reload;test -- Fails
Workaround
Issue abort commands on separate lines.

Known Limitations
Calling Methods of the Current Struct
9.8.3 Calling Methods of the Current Struct
Defect: 1078, 2653, 3521, 3434
Description
Specman Elite does not recognize methods of the current struct that are called from the debugger prompt
if the me prefix is omitted.
For example, if me contains the method foo():

foo() -- Fails
me.foo() -- OK
Workaround
Use the me prefix explicitly when calling methods of the current struct from the debugger prompt.
9.8.4 Conditional Breakpoints
Defect: 2653
Description
Conditional breakpoints cannot be set on events.
Workaround
Currently, none.
9.8.5 Debugging TCMs That Return a Value
Defect: 2738
Description
If you set a breakpoint on a call to a TCM that has a return value, then the debugger will stop AFTER
that TCM is executed instead of before entering that TCM.
This bug affects the debugging of all TCMs that return values.

Known Limitations
on event Blocks
Workaround
If you need to break upon a call to a value-returning TCM, add a dummy action in front of the call, in the
same line as the call. You will be able to break there.
For example, instead of:

print read(addr);
Write:
var x: int; print read(addr);
9.8.6 on event Blocks
Defect: 2653
Description
The debugger cannot break on an on event block. If you try it, you may get an exception.
Workaround
Write the desired code in a separate method and call it from inside the on event block. Then you can set
a breakpoint on the separate method.
9.9 Data Browser Limitations

• “list_from Options” on page 9-44
• “raw_print Option” on page 9-44
• “Refreshing the Window During Simulation” on page 9-44
• “Problem Displaying Methods in the Data Browser” on page 9-45
• “do_print() Ignored” on page 9-45

Known Limitations
list_from Options
9.9.1 list_from Options
Defect: NA
Description
The list_from configuration option in the Print category does not affect the Data Browser.
Workaround
Display the data using the older tree command after first setting the backward configuration option
config back33 -tree_window=TRUE.
9.9.2 raw_print Option
Defect: NA
Description
Changing the value of the config option raw_print while the Data Browser is open has no effect. The
Data Browser uses the raw_print value that was in effect when the Data Browser was first opened.
Workaround
Use the Restore command to force the Data Browser to check the current value of raw_print, or set
raw_print before opening the Data Browser. Closing all Data Browser windows is not a workaround.
9.9.3 Refreshing the Window During Simulation
Defect: NA
Description
The Data Browser and Watch windows are not always refreshed automatically when Specman stops at
the simulator prompt. This is true, for example, for the ModelSim simulator.

Known Limitations
Problem Displaying Methods in the Data Browser
Workaround
Click on the vrst-tool> button to refresh the Data Browser and Watch windows if necessary.
9.9.4 Problem Displaying Methods in the Data Browser
Defect: NA
Description
The command show data method causes the method to be executed at every Specman prompt.
Workaround
To display information about a method, use the print command or set the option config back33
-tree_window=TRUE and then use the tree command.
9.9.5 do_print() Ignored
Defect: NA
Description
do_print() user extensions have no effect in the new data browser.
Workaround
To display information in the format defined by do_print(), use the print command. This command
prints the selected expression to the Specview main window, using the do_print() user extensions, if
they exist.
The print command is available:
• Under the Tools menu in the menu bar

• In the pop-up menu that appears when you right click on a selected tree or table entry
If this is not sufficient, you can set the option config back33 -tree_window=TRUE and then use the
tree command.

Known Limitations
GUI Limitations
9.10 GUI Limitations

• “Common Desktop Environment (CDE)” on page 9-46
• “Solaris Patches Required for Running Java” on page 9-46
• “Specview and Exceed” on page 9-47
9.10.1 Common Desktop Environment (CDE)
Defect: 2824
Description
Specview running on CDE pops up in a different desktop when a simulation error occurs.
Workaround
Currently, none.
9.10.2 Solaris Patches Required for Running Java
Defect: N/A
Description
Various Solaris platforms require specific Sun patches to run Specman in GUI mode (that is, to run
Specview).
Workaround
Ensure that the required patches are installed in your environment. The full list of required cluster
patches for the various Solaris versions can be found on the Web at:
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/J2SE
Please read the README page for the appropriate Solaris versions for detailed descriptions and
installation instructions.
Note The patch installation requires system administration permissions.
To get a list of all currently installed patches on your Solaris machine, type:

Known Limitations
Specview and Exceed
/bin/showrev -p | awk '{print $2}'
Please compare the list of currently installed patches with the list of required patches in the README
file to verify that the required patches were installed.
After all patched are installed, you can try running Java by opening the Data Browser. To open the Data
Browser, click on the Sys button on Specview.
Note See also “Specview and Exceed” on page 9-47 for information about debugging Java problems
when you are using Exceed.
9.10.3 Specview and Exceed
Defect: 4729
Description
You might encounter problems with Specview if you use Exceed from Hummingbird, Ltd. The
problems are probably caused by an incomplete font installation in the Exceed environment or Exceed
limitations processing Java-based GUIs. The problems can include:
• Specview does not run or hangs when you are using Exceed (font problem or Java problem).
• Specview window borders disappear, you cannot scroll or enter keystrokes, and so on when you are
using Exceed (Java problem).
Workaround
The following describe possible workarounds for your Exceed problems:
• “Check the Exceed and Specman Elite Installations” on page 9-48

• “Install Additional Fonts” on page 9-48
• “Use a Remote Font Server” on page 9-48
• “Change the Exceed Window Mode and Manager” on page 9-50
• “Upgrade To a Higher Version of Exceed” on page 9-51
• “Help Limitations” on page 9-51
Note For more information about troubleshooting Java problems, also see “Solaris Patches Required
for Running Java” on page 9-46.

Known Limitations
Specview and Exceed
Check the Exceed and Specman Elite Installations

The first step in solving Exceed problems is to check that Specman Elite and Exceed are both installed
correctly and completely.
Install Additional Fonts

Font problems with Exceed can cause Specview to hang or not to run.
To solve the font problem, try installing additional fonts, as described in this section, or using a remote
font server, as described in “Use a Remote Font Server” on page 9-48. Default installations for Exceed
often do not include all standard fonts, in particular, the fonts required for Hewlett-Packard
workstations.
Note If you have problems installing additional fonts, see the Exceed Help or contact your system
administrator.
To install additional fonts and font aliases:
1. Open the Exceed XConfig window
2. Double click on Font.
The Font Settings dialog box appears. This dialog box lets you view and edit the font database
available to Exceed and import font aliases.
3. If Exceed is using font directories, rather than a central font server, ensure that the font database
includes ALL fonts from the following directories:
hpfont
andrew
100dpi
75dpi
pc
misc
Note The 75dpi font directory may not exist. If it does, ensure that the 100dpi font directory is
listed before the 75dpi font directory.
4. Ensure that the “automatic font substitution” check box is checked.
5. In addition, load all known font aliases in the Exceed font configuration.
The alias files are provided with Exceed and are stored in files with an .ali suffix.
Use a Remote Font Server

Font problems with Exceed can cause Specview to hang or not to run.

Known Limitations
Specview and Exceed
If installing additional fonts, as described in the previous section, does not solve your Exceed problems,
try using a remote font server, as described in this section.
Note If you have problems setting up a remote font server, see the Exceed Help or contact your system
administrator.
1. Activate the font server on your server (for example, your Solaris workstation)
To active the font server, you need to know the port on which it is connected.
2. Open the Exceed XConfig window and double click on Font.
The Font Settings dialog box appears.
3. Click on Font Database.
4. Click on Add.
The Add Font Directory dialog box appears.
5. Choose “Server” in radio button selection on right side
The Add Font Server dialog box appears.
6. In the Add Font Server dialog box, specify:
- The host (IP address) from which you activated the font server
- tcp transport
- The font server port
- Status “load” or “keep”
Note See the Help for this dialog box for more information.
7. Click OK to save your changes.
8. Click the Move Up button until your newly added font server is at the top of the Font Database list.
9. Click OK and exit.
Note When you use a font server, ensure that the following fonts are installed on your server:
hpfont
andrew
100dpi
75dpi
pc
misc

Known Limitations
Specview and Exceed
Change the Exceed Window Mode and Manager

Java problems with Exceed can cause the following problems:
• Specview does not run or hangs when you are using Exceed.
• Specview window borders disappear, you cannot scroll or enter keystrokes, and so on when are using
Exceed.
To solve the Java problems, change the window mode and manager with one of the following solutions.
The window manager controls how windows look (borders and so on) and act (scroll bars and so on).
Solution 1: Multiple Window Mode with Native Window Manager
This is the recommended solution. If it does not work, try Solution 2.
With this method you force the window manager for your Exceed windows to “native”, that is, the
window manager for your PC machine.
1. Open the Exceed XConfig window.
2. Double click on Communication and ensure that the mode is Passive. Close the Communication box.
3. Double click on Screen Definition or Window Mode.
One or the other of these options appear on the XConfig window, depending on the Exceed version.
4. If you opened the Screen Definition box, choose the following, close the Screen Definition box, and
close the XConfig window:
Window Mode: Multiple
Server Visual: Auto Select
Window Manager: Native
5. If you opened the Window Mode box, choose the following and close the Window Mode box:
Window Mode: Multiple
Window Manager: Native
Back on the XConfig window, click on Video, choose the following, close the Video box, and close
the XConfig window:
Server Visual: PseudoColor
The window manager now changes to your native window manager. If this solution does not work,
try the following solution.
Solution 2: Multiple Window Mode with Remote Window Manager

Known Limitations
Help Limitations
This method requires using a remote window manager, for example, the window manager used on your
Solaris or HP server.
1. Follow the steps in Solution 1, but this time choose:

Window Manager: Default to Native
2. Using Exceed, open a terminal window on the server, and run a remote window manager explicitly.
The remote window managers are typically stored under /usr/dt/bin. For example, if your server is a
Solaris, you could run:
/usr/dt/bin/dtwm &
Note Check with your system administrator for information about the remote window managers
available to you.
Once you activate the remote window manager, it controls all your GUI windows, including
Specview.
Note The window management problem has been logged as an Exceed bug. For more information,
see:
http://www.hummingbird.com/exceedusers/Feb2000/0016.html
http://www.hummingbird.com/exceedusers/Feb2000/0043.html
Upgrade To a Higher Version of Exceed

Some Exceed problems appear to be solved in version 7.0. Consider moving to a newer version if you
are using Exceed 6.2 or earlier.
9.11 Help Limitations

• “Help or Apropos Fails for Certain Strings” on page 9-52
• “Viewing Help in a Rational ClearCase Environment” on page 9-52
• “Broken Hyperlinks in About This Specman Elite Release” on page 9-53
Note See the Search and Browsing Tips for additional information about limitations in the Help system.

Known Limitations
Help or Apropos Fails for Certain Strings
9.11.1 Help or Apropos Fails for Certain Strings
Defect: 309, 1336, 1500, 1611
Description
The help or apropos command in ASCII mode might fail if you enter strings with special characters,
such as “&” or “<?>”, or strings with unbalanced brackets, such as “select(”.
Workaround
Search for strings with none of the above limitations.
9.11.2 Viewing Help in a Rational ClearCase Environment
Description
Beginning with release 4.0.3 the Help system displays in your default Web browser. If a browser
window is open when you access the Help, it uses that window to display the Help, rather than opening
a new browser window.
If you are working in one ClearCase environment and have a browser open in another ClearCase
environment, the Help displays in the open browser in the other ClearCase environment. This can cause
problems because the Help HTML files may not be accessible in the other environment.
Workaround
Before you open the Help while working in a ClearCase environment, close any Web browser windows
that were opened in a different ClearCase environment. Alternatively, you can set the configuration gui
option -new_help_window to TRUE.
See Also
• configure gui on page 6-23 in the Specman Command Reference

Known Limitations
Broken Hyperlinks in About This Specman Elite Release
9.11.3 Broken Hyperlinks in About This Specman Elite

Release
Description
The hyperlinks in About This Specman Elite Release that link to other Specman Elite manuals work
when you view this manual from the:
• HTML online Help—that is, the Help as it is accessed from Specview

• PDF version of About This Specman Elite Release in …/docs/pdf_docs/about_this_release.pdf.
When you view the standalone PDF version of About This Specman Elite Release that you download
from the “software downloads” section of the Verification Vault, the hyperlinks between manuals will
not work.
9.12 Waveform Viewer Limitations

• “Detection of Loops in TCMs” on page 9-53
• “Cannot Trace like Inherited Instance Content” on page 9-54
• “MTI ModelSim: Indication for Event Occurrence” on page 9-54
• “MTI ModelSim: String Display” on page 9-54
• “MTI ModelSim: GUI Locks and No Automatic Refresh” on page 9-55
• “Synopsys VirSim: Event Names” on page 9-55
• “DAI Signalscan: Refreshing Data” on page 9-56
9.12.1 Detection of Loops in TCMs
Defect: 4236
Description
If the code of the TCM has a loop with a wait command, then all you see in the waveform viewer is that
“wait cycle” took n cycles. You do not see each iteration as a single item.

Known Limitations
Cannot Trace like Inherited Instance Content
Workaround
Currently, none.
9.12.2 Cannot Trace like Inherited Instance Content
Defect: 4385
Description
Tracing an instance that is inherited from like shows only the instance content and not the inherited
fields and events.
Workaround
Currently, none.
9.12.3 MTI ModelSim: Indication for Event Occurrence
Defect: NA
Description
ModelSim does not display the indication for event occurrence. Therefore the only valid value for the
config option event_data is “details”.
Workaround
None.
9.12.4 MTI ModelSim: String Display
Defect: NA
Description
ModelSim does not display strings that are longer than the physical allocation in the wave. You have to
zoom in to see the whole string.

Known Limitations
MTI ModelSim: GUI Locks and No Automatic Refresh
Workaround
Try to use shorter text strings by modifying the Specman wave configuration options:
stub_message_len and stub_strings_len.
9.12.5 MTI ModelSim: GUI Locks and No Automatic Refresh
Defect: NA
Description
While at the Specman prompt, the ModelSim GUI is locked, and there is no automatic refreshing of the
displayed data. To refresh the waveform display, you must press the Refresh button in the debugger
window or issue the refresh wave command.
Workaround
None.
9.12.6 Synopsys VirSim: Event Names
Defect: NA
Description
VirSim cannot rename event entries with a meaningful name, so it uses the name sn_event<id>.
Workaround
In order to see event occurrences, set the wave config option event_data to all_data and not
occurrence_only. The event entry will have a meaningless name but the details wave entry below it will
have the proper event name.

Known Limitations
DAI Signalscan: Refreshing Data
9.12.7 DAI Signalscan: Refreshing Data
Defect: NA
Description
When Signalscan is in a stopped state at the debugger prompt, there is no way to refresh the data
displayed in the waveform viewer.
Workaround
None.
9.13 CVL Limitations

• “CVL Method and CVL Call Declarations” on page 9-56
• “CVL Method and CVL Call Arguments” on page 9-57
9.13.1 CVL Method and CVL Call Declarations
Defect: NA
Description
CVL method and CVL call declarations cannot appear within a when block or within a derived struct.
The field declaration of type cvl_connection has the same limitation.
For example, the following code involving a CVL method causes a load-time error:
struct a {
!con: cvl_connection;
--...
};
struct b like a {
m() @sys.clk is {
--...
};
// Invalid CVL method declaration within `like'
cvl method m() @sys.clk is C routine specman_m;
};

Known Limitations
CVL Method and CVL Call Arguments
In contrast to CVL declarations, CVL method implementation can be within a derived struct. Remote
CVL calls can also be activated from within a derived struct.
Workaround
Currently, none.
9.13.2 CVL Method and CVL Call Arguments
Defect: NA
Description
CVL method and CVL call arguments from the following types are not supported:
• Sized scalars with an actual bit width greater than 32 bits

• Structs
• Lists of Boolean items
• Lists of enumerated items
Workaround
Convert the argument into a supported type before and after the remote CVL call. For example, convert
“int (bits: 128)” into “list of int”.
9.14 OS Platform Limitations

• “AIX Limitations” on page 9-57
• “Visual Toolkit Applications on AIX” on page 9-58
• “Specman Elite CPU Profiler on Linux in Multi-Thread Environment” on page 9-58
• “Static Linking with NC Verilog on Red Hat 7.2” on page 9-59
9.14.1 AIX Limitations

The AIX platform supports dynamic linking of Specman's shared libraries with simulators only. The
sn_compile.sh script applies this kind of linking implicitly.

Known Limitations
Visual Toolkit Applications on AIX
AIX does not support:
• The Mentor Graphic Seamless co-verification environment

• Visualization Toolkit
9.14.2 Visual Toolkit Applications on AIX
Defect: NA
Description
Visual Toolkit (VT) applications run on AIX 5.1 only, which is in beta support in 4.3. The only
exception to this is the Specman Elite Test Ranking GUI, which is based on VT and can be run on any
supported AIX.
Workaround
None
9.14.3 Specman Elite CPU Profiler on Linux in Multi-Thread

Environment
Defect: NA
Description
Under Red Hat Linux, when the Specman Elite CPU profiler is activated in an environment that initiates
a number of threads, the profiler does not receive all the signals, and the profiler report is not valid.
This limitation applies for all Linux pre-2.6 kernel versions.
Workaround
The workaround for this problem is to create a single-thread build whenever CPU profiling is required.

Known Limitations
Static Linking with NC Verilog on Red Hat 7.2
9.14.4 Static Linking with NC Verilog on Red Hat 7.2
Defect: NA
Description
Specman Elite cannot be statically linked with NC Verilog using IUS5.3 on Red Hat 7.2. An attempt to
do so causes the following fatal error at elaboration time:
ncelab: *internal* (dlib_init() - Unable to initialize a search handle error
Note that such static linking is a normal step during integration of Specman Elite with the Incisive
simulator provided by Cadence.
This error has been reported to Cadence and is being tracked under Cadence's Support Request “SR
32839966”.
Workaround
Use a Red Hat version higher than 7.2.
9.15 Miscellaneous Limitations

• “collect Command Limitations” on page 9-59
• “Specview Hanging during Simulator Reset” on page 9-60
• “Size of File Names and Commands” on page 9-60
• “Config Memory Mechanism” on page 9-61
• “Encryption” on page 9-61
9.15.1 collect Command Limitations
Defect: 51, 299, 2035, 2777, 3087
Description
The collect command does not:
• Accept -reload for a method that is inherited

Known Limitations
Specview Hanging during Simulator Reset
• Do collection for methods under when

• Do collection for TCMs
Workaround
Currently, none.
9.15.2 Specview Hanging during Simulator Reset
Defect: 2807, 3126
Description
Specview can hang when commands are issued while the simulator is being reset.
Workaround
Wait for the $reset command to execute in full before issuing any commands from the Specman prompt
or with the Specview buttons.
9.15.3 Size of File Names and Commands
Defect: 165, 997
Description
Specman Elite does not accept file names or commands longer than about 4,000 characters.
Workaround
Currently, none.

Known Limitations
Config Memory Mechanism
9.15.4 Config Memory Mechanism
Defect: 3588
Description
The config mechanism does not save the values inside category “mem” with a save command.
Workaround
Use write config file to save the config values. Then use read config file to restore them.
9.15.5 Encryption
Defect: 6889
Description
Encryption of files containing Japanese characters is not supported. Files containing EUC-JP characters
can be encrypted, but the encrypted files cannot then be loaded into Specman Elite.
Workaround
None.

Known Limitations
Encryption

10 Supported Platforms and
Third-Party Tools
This chapter contains the following information:
• “Supported Platforms” on page 10-1

• “Supported Simulators” on page 10-2
• “Supported Waveform Viewers” on page 10-2
• “Other Supported Third Party Tools” on page 10-3
10.1 Supported Platforms

Verisity supports the following platforms:
• Solaris 2.7, 2.8, 2.9

• HP-UX 11 on PA-RISC machines
• Red Hat Linux 7.1, 7.2, 7.3, 8.0, 9.0 and Enterprise 3 on Intel Pentium platforms only
Note If you use Red Hat 9.0 or Enterprise 3, you must also use a simulator that supports this Red
Hat platform.
• AIX 4.3.2.0, 4.3.3.0, and 5.1 (beta support, using an AIX 4.3 executable)
Note See “OS Platform Limitations” on page 9-57 in About This Specman Elite Release for platform
limitations.

Supported Platforms and Third-Party Tools
Supported Simulators
10.2 Supported Simulators

Table 10-1 Supported Simulator Versions
Simulator Version(s)
SpeXsim (Verisity Design, Inc.) 4.3.4
Verilog-XL (Cadence Design Systems, Inc.) LDV5.0, LDV5.1, and IUS5.3
NC Simulator (Cadence Design Systems, Inc.) LDV5.0, LDV5.1, and IUS5.3
VCS (Synopsys, Inc.) 6.2, 7.0, 7.1
ModelSim (Model Technology, Inc.) 5.6, 5.7, and 5.8
SpeedSim, Verilog cycle-based (Quickturn, a 3.2 and 3.2.1

Cadence Company)
Note All simulators are supported in 32-bit mode only (not 64-bit mode).
10.3 Supported Waveform Viewers

Table 10-2 Supported Waveform Viewer Versions
Waveform Viewer Version Remarks
Novas Debussy off_line, 4.3 onwards

manual
interactive 4.4.h14 onwards The cmdlib.a library supplied by

Novas enables the interactive working
mode. This library has been available
on the Novas FTP site only from
version 4.4.h14.
DAI Signalscan 6.3p2 onwards
Cadence off_line LDV4.0, LDV4.1

SimVision onwards, IUS5.3
MTI ModelSim 5.4 onwards
Synopsys VirSim 3.0.3.patch5

onwards

Other Supported Third Party Tools
Table 10-2 Supported Waveform Viewer Versions (continued)
Waveform Viewer Version Remarks
Undertow off_line, 7.0.7 onwards

manual
Table 10-3 Supported Combinations of Simulators and Waveform Viewers
VirSim Debussy Signalscan ModelSim Undertow SimVision
MTI VHDL: M, I, M, O
O
Verilog: O
XL O I, M, O M, O NA M, O
NC O I, M, O M, O NA O
Verilog
VCS O I, M, O NA M, O
NC M, O NA O
VHDL
Modes: I = Interactive M = Manual O = Offline (Batch) NA = Not Applicable
10.4 Other Supported Third Party Tools

Table 10-4 Other Supported Third Party Tool Versions
Tool Version Remarks
Denali Memory 3.0

Modeler
Seamless 4.0 onwards Specman Elite can work with earlier versions of Seamless, but
Co-Verification no integration is supported.
Environment

Other Supported Third Party Tools

Index
Symbols limitation on 9-18

additional_eval 8-21
@sim event AIX
limitations 9-32, 9-33 limitations 9-57, 9-58
[:] bit slice operator versions and simulators, supported 10-1
multiple colon limitation 9-3 all
show gen option 8-66
Numerics apropos command
4.3 new features limitations 9-52
data browser 5-2 ASCII help
simulator versions supported 5-3 limitations 9-52
SimVision wave viewer 5-4 auto_visualize Data Browser configuration
visualize() method 5-2 parameter 5-2
writef() method 5-2
B
A back32
abort command eRM incompatibility 9-21
limitations 9-41 back33
access violations eRM limitations 9-21
bit slice backward compatibility
illegal format 8-10 upgrading from 3.2.x 8-63
non-existent bits 8-10 upgrading from 3.3.x 8-31
list slice backward compatibility flags
illegal format 8-13 setting 8-35
negative index 8-13 setting defaults from installation script 8-36
non-existent bits 8-13 setting from Specview 8-36
unbounded integer 8-25 backward compatibility issues
actions due to language bugs 8-39
try due to performance enhancements 8-54
About This Specman Elite Release Index-1

Index
due to usability enhancements 8-57 write stubs 8-61

Verisity policy 7-1 config memory mechanism
backward compatibility warning mode 8-34 limitations 9-61
BAD_COV_II_DEF 8-52 configuration options
bit extraction, See bits, slicing back32 8-63
bits add_slashes_in_set_check 8-64
slicing allow_enum_as_index 8-64
limitation on multiple colons 9-3 bit_slicing_is_uni_directional 8-64
breakpoints enable_verilog_trace 8-64
conditional implicit_pack 8-64
limitation 9-42 in_list_is_uni_directional 8-64
index_is_uni_directional 8-64
C old_error_handling 8-64
struct_eq_is_uni_directional 8-64
Cadence Design Systems use_quotes_in_import_statements 8-64
supported simulators 10-2 back33 8-36
Cadence LDV 5.X limitations 9-25 additional_eval 8-21, 8-38
ClearCase environment, viewing Help in 9-52 cover_mode 8-37, 8-58
collect command disable_cover_events 8-37, 8-59
limitations 9-4, 9-59 disable_illegal_ignore_check 8-37, 8-52
commands disable_otf_gc 8-37, 8-56
abort list_assign 8-37, 8-50
limitations 9-41 no_gen_in_write_stub 8-38, 8-61
apropos no_reorder 8-23, 8-38
limitations 9-52 old_method_extension 8-37, 8-43
collect old_modules_window 8-38
limitations 9-4, 9-59 old_struct_member_under_when 8-36,
configure back33 8-35 8-39
finish tick_notation 8-37, 8-47
limitations 9-41 tree_window 8-38, 8-60
help use_trace_gen_33 8-38, 8-62
limitations 9-52 gen
names of -static_analysis_opt 5-3
limitations 9-60 miscellaneous
reload short_is_signed 8-4
limitations 9-41 constraints
restore limitations
limitations 9-41 or 9-10
set backward compatibility 33 8-35 list item
set backward warning 33 8-34 limitations 9-9, 9-10
show gen show gen option 8-66
3.3.x version 8-62 use of as_a() 9-8
show visualization 5-2 consume()
trace on gen 8-62
Index-2 About This Specman Elite Release
Index
backward compatibility issues with 8-55 DEPR_AHB_TRANSFER_START_KEYWOR

cover_mode 8-58 D 8-2
coverage DEPR_BIT_EXTRACT_BOUNDS 8-10
limitations DEPR_CONFIG_SHORT_IS_SIGNED 8-4
like inheritance 9-7 DEPR_CVL_FIELD_KEYWORD 8-4
for long integer types 9-6 DEPR_DUT_ERR_FIELD_KEYWORD 8-4
for long uint types 9-6 DEPR_KEEP_BLOCK 8-12
co-verification DEPR_LIST_SLICE_BOUNDS 8-13
limitations 9-56 DEPR_LOCKER_RELEASE_TCM_KEYWOR
CPU profiler D 8-6
limitation 9-58 DEPR_RESERVED_KEYWORD 8-16
CVL DEPR_SESSION__DUT_ERR_EVENT_KEY
limitations 9-56 WORD 8-7
DEPR_SN_VERILOG_TIME_SCALE_INCOM
D PAT 8-18
DEPR_SYS_HDL_PATH 8-19
data browser DEPR_TCM_CLOCK 8-20
limitations DEPR_TEMPO_BACK33_ADD_EVAL 8-21
automatic window refresh during DEPR_TEMPO_BACK33_NO_REORDER
simulation 9-44 8-23
displaying methods 9-45 DEPR_TYPE_LONG 8-25
do_print() 9-45 DEPR_UNBOUND_INT_SLICE 8-25
list_from_options 9-44 DEPR_UNIT_GEN_INSTANCE 8-26
raw_print 9-44 DEPR_UNIT_INSTANCE 8-26
limitations_list_from 9-44 DEPR_WAVE_REGISTER_STRUCTS 8-30
Visualize button 5-2 DEPR_WHEN_AFTER_LIKE 8-30
debugger DEPRE_AHB_BURST_START_KEYWORD
limitations 8-2
calling methods of current struct 9-42 deprecation
conditional breakpoints on events 9-42 deprecated features in the current release 8-2
corner cases 9-42 displaying information about 7-1
finish command 9-41 eVC developer recommendation 7-1
on event blocks 9-43 for semantic changes 7-4
when aborting 9-41 for syntactic changes 7-3
deep_compare_physical() predefined routine notification IDs 7-1
limitations 9-5 setting severity level for 7-1
Denali interface the deprecation process 7-1
versions, supported 10-3 Verisity policy 7-1
DEPR_AHB_BURST_DELAY_KEYWORD deprecation messages
8-2 access violations
DEPR_AHB_TRANSACTION_START_KEY bit slice 8-10
WORD 8-2 list slice 8-13, 8-25
DEPR_AHB_TRANSFER_DELAY_KEYWOR config options
D 8-2
Index
short_is_signed 8-4 8-62

incompatible Verilog time scales 8-18 ERR_SHOW_GEN_VIS_ILLEGAL_SHOW_G
-register_structs wave config option 8-30 EN 8-62
reserved keywords 8-16 ERR_UNDEFINED_METHOD1 8-43
reserved type names 8-25 ERR_UNRECOGNIZED_ENUM_TYPE 8-47
sys hdl_path() 8-19 eVC developers
TCM sampling events 8-20 deprecation recommendation 7-1
unit instance restrictions 8-26 events
use of keep{} block 8-12 session.dut_error 8-7
use of locker.release() TCM 8-6 Exceed window manager bug 9-51
use of session.dut_error event 8-7
when subtypes 8-30 F
details
show gen option 8-66 file names
disable_cover_events 8-59 limitations 9-60
disable_illegal_ignore_check 8-52 finish command
disable_otf_gc 8-56 limitations 9-41
do_print() 9-45 first method extension option
downloading limitation 9-3
Specman Elite 6-2
G
E garbage collection
encrypted code on-the-fly 8-56
eRM limitations 9-22 generation
encryption limitations
limitations 9-61 as_a() in constraints 9-8
eRM list item constraints 9-9, 9-10
compatibility 9-20 or 9-10
limitations 9-20 parameter passing by reference 9-7
back32 incompatibility 9-21 Gnu C compiler
back33 9-21 limitations
encrypted code 9-22 crashes on long methods 9-4
source code debugger 9-22
ERR_ADD_METHOD 8-39, 8-43 H
ERR_ASSIGN_LIST_COMPAT 8-50 help command
ERR_BAD_COV_II_DEF 8-52 limitations 9-52
ERR_DEFINED_METHOD 8-43 Help system
ERR_DEFINED_METHOD2 8-43 limitations 9-51
ERR_METHOD_NOT_DEFINED 8-39 HP-UX
ERR_METHOD_NOT_DEFINED1 8-39 versions, supported 10-1
ERR_NAME_WITH_TICKS 8-47 HP-UX limitations 9-25
ERR_NAME_WITH_TICKS_WARN 8-47 Hummingbird Exceed
ERR_SHOW_GEN_VIS_CANT_TRACE_GEN
Index
installing fonts 9-48 OS platform 9-57

native window manager 9-50 ports 9-37
remote window manager 9-50 profilers 9-58
solving problems with 9-47 simulator interface 9-23
using remote font server 9-48 temporal 9-13
version vt_util 9-22
6.0 9-51 waveform viewer 9-53
7.0 9-51
window mode and manager 9-50 L
last
I show gen option 8-66
in_sequence contradiction in complex constraints libqvhsn.so 8-65
9-23 libqvhsn_basic.so 8-65
in_unit contradiction in complex constraints 9-23 libqvlsn.so 8-65
installation libqvlsn_basic.so 8-65
Specman Elite version 4.3 6-2 limitations
for long integer types 9-13
J trace on special event 9-36
list_assign 8-50
Japanese characters LIST_ASSIGN_ERR 8-50
encryption limitations 9-61 lists
Java constraining
known limitations 9-46 limitations 9-9, 9-10
K M
keywords, reserved 8-16 macros
known limitations 9-1 limitations
coverage 9-6 nested definitions of 9-2
data browser 9-43 memory management
debugger 9-40 problems
eRM 9-20 long integer generation 9-13
ESI 9-39 message() action
generation 9-7 limitation on nesting 9-23
GUI 9-46 messagef() action
help system 9-51 limitation on nesting 9-23
using in_sequence in complex constraints method extension
9-23 limitations 9-2, 9-3
using in_unit in complex constraints 9-23 Model Technology
language 9-2 supported simulators 10-2
miscellaneous 9-59 ModelSim
NCsim mixed 9-39 limitations 9-54, 9-55
using nested messages 9-23 versions, supported 10-2

Index
ModelSim limitations predefined routines

VHDL 9-25 deep_compare_physical()
MTI limitations 9-5
limitations 9-54, 9-55 prefix
config gen option 8-65
N profilers
limitations 9-58
NC Simulator
versions, supported 10-2
NC SystemC limitations 9-25
Q
NC Verilog Quickturn
limitations 9-26, 9-27 supported simulators 10-2
-NBASYNC option 9-26 qvh
NC VHDL sn_compile.sh option 8-65
limitations 9-28 qvh_sn_pic_.o 8-65
NC VHDL limitations qvl
force/release 9-27 sn_compile.sh option 8-65
nesting qvl_sn_pic_.o 8-65
config gen option 8-65
no_gen_in_write_stub 8-61 R
no_reorder 8-23
notification IDs, deprecation 7-1 race conditions
Novas Debussy HDL-style variables 9-31
versions, supported 10-2 Red Hat Linux
reduction_colors
O config gen option 8-65
old_method_extension 8-43 reductions
old_struct_member_under_when 8-39 show gen option 8-66
-reload collect command option
P limitation on 9-4
reload command
parameters limitations 9-41
passing by reference reordering
not allowed in TCMs 9-7 show gen option 8-66
passing reserved words, deprecation messages for 8-16,
by reference 8-25
restrictions on 9-7 restore
patches limitations 9-3
Solaris, for running Java 9-46 restore command
paths limitations 9-41
relative unit and full HDL
limitation 9-31
platforms, supported 10-1

Index
S upgrading from 3.3.x 6-3

version 4.3.1
sampling new features 4-1
HDL-style variables version 4.3.2
limitations 9-30 new features 3-1
in mixed environment versions, upgrading 6-3
limitation 9-35 SPECMAN_LIBQVH 8-65
save SPECMAN_LIBQVL 8-65
limitations 9-3 Specview
scalar_fields limitations 9-60
show gen option 8-66 Common Desktop Environment 9-46
Seamless co-verification SpeedSim
versions, supported 10-3 limitations
Seamless interface Specview window updates 9-30
not supported on AIX 9-57 ungraceful exit 9-30
session.dut_error event 8-7 Verilog memories 9-29
session.events coverage group 8-59 Verilog signals 9-29
show_on_trace Verilog tasks and functions 9-29
config gen option 8-65 Speedsim
show_repeats versions, supported 10-2
config gen option 8-65 -static_analysis_opt generate command option
Signalscan 5-3
limitations 9-56 stop_run() predefined method
versions, supported 10-2 limitations 9-19
simulators structs
and waveform viewers, supported nested
combinations 10-3 garbage collection crash with 9-3
interface limitations 9-23 Synopsis
supported 10-2 supported simulators 10-2
SimVision sys, HDL path of 8-19
Solaris
T
source code debugger eRM limitations 9-22 TCMs
Specman extending
version 4.3.3 limitations 9-2
new features 2-1 limitations
version 4.3.4 debugger not stopping 9-19
new features 1-1 extending 9-2
Specman Elite fork branches transitions 9-19
known limitations 9-1 parameter passing by reference 9-7
licensing 6-2 state machine transitions 9-19
version 4.3 6-1 stop_run() 9-19
new features 5-1 try action 9-18
Index
passing parameters V
restrictions on 9-7
sampling events for 8-20 variables
temporal HDL-style
limitations limitations 9-30, 9-31
change behavior 9-14 VCS
fall behavior 9-14 versions, supported 10-2
not, expressions under 9-14 Verilog
on methods 9-16 limitations
rise behavior 9-14 escaped identifiers 9-33
true behavior 9-14 sampling in mixed environment 9-35
variable structs 9-17 SpeedSim 9-29
VHDL variables in @sim expressions time scale, setting 8-18
9-17 Verilog time scale 8-18
temporal evaluator Verilog-XL
compatibility 8-54, 8-55, 9-13 versions, supported 10-2
limitations 9-13 Verilog-XL limitations
temporal expressions forcing a reg 9-26
restrictions on 8-54, 8-55 version 4.0
tick_notation 8-47 compatibility issues
time scale setting backward compatibility flags
setting 8-18 8-35
tools, third party, supported 10-3 VHDL limitations
trace gen 8-65 ModelSim 9-25
trace on special event vhdl time statement
limitations 9-36 ignored by ModelSim 8-9
tree_window 8-60 VirSim
try action limitations 9-55
limitation on 9-18 versions, supported 10-2
type names, reserved 8-25 visual toolkit
AIX limitation 9-58
visualization of struct information 5-2
U Visualization Toolkit
Undertow not supported on AIX 9-57
versions, supported 10-2 vt_util
unit instance rule, violations of 8-26 limitations 9-22
units
limitations 9-33 W
relative paths
limitation 9-31 WARN_ADD_METHOD 8-39
upgrading WARN_AMBIGUOUS_METHOD 8-39, 8-43
Specman Elite versions 6-3 WARN_ASSIGN_LIST_COMPAT 8-50
use_trace_gen_33 8-62 WARN_BAD_COV_II_DEF_WARN 8-52
WARN_DEFINE_METHOD 8-43

Index
WARN_DEFINE_METHOD2 8-43
WARN_METHOD_EXTENSION 8-39, 8-43
WARN_METHOD_NOT_DEFINED 8-39
WARN_METHOD_NOT_DEFINED1 8-39
WARN_UNDEFINED_METHOD1 8-43
WARN_VHDL_TIME_MODELSIM_IGNORE
D 8-9
waveform viewers
and simulators, supported combinations 10-3
limitations
loops in TCMs 9-53
MTI 9-54, 9-55
Signalscan 9-56
tracing like inherited instance 9-54
VirSim 9-55
Novas Debussy
waveform viewers, supported 10-2
when subtypes
references to 8-30
window
show gen option 8-66
X
X/Z literals
limitations 9-31
Z
z and x values
limitations 9-31

SN About This Release PDF

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

SN About This Release PDF

Uploaded by

Copyright:

Available Formats

About This Specman

Restricted Rights Legend

Destination Control Statement

1 New Features in Version 4.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

2 New Features in Version 4.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

About This Specman Elite Release iii

3 New Features in Version 4.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

4 New Features in Version 4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

5 New Features in Version 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

iv About This Specman Elite Release

6 Overview of the 4.3 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

7 The Deprecation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

8 Deprecation and Backward Compatibility for this Release . . . . . .8-1

About This Specman Elite Release v

8.3 Version 3.3 Backward Compatibility Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39

9 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

vi About This Specman Elite Release

9.3.4 Multiple List-in-List Constraints on the Same List . . . . . . . . . . . . . . . . . . . . 9-10

About This Specman Elite Release vii

viii About This Specman Elite Release

9.11.1 Help or Apropos Fails for Certain Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-52

10 Supported Platforms and Third-Party Tools . . . . . . . . . . . . . . . . .10-1

About This Specman Elite Release ix

x About This Specman Elite Release

• “Documentation Reorganization to Support SpeXsim” on page 1-2

About This Specman Elite Release 1-1

1.1 Documentation Reorganization to Support

The following sections describe the new documentation reorganization:

• “New Help Organization” on page 1-2

1.1.1 New Help Organization

Specman Core Technologies

Usage and Concepts Guide for e Testbenches

Specman Elite / Third Party Simulators

e Reuse Methodology (eRM) Developer Manual

1-2 About This Specman Elite Release

1.1.2 New Document: Specman Elite Integrator’s Guide

1.1.3 Updates to the Specman Reference Manuals to

About This Specman Elite Release 1-3

1.2 Updated Path to the Online Help

Thus, the general path to the Help launcher file is as follows:

• When using SpeXsim: sxbuild -docs

1.3 New configuration simulation Category

• compatible_vhdl_at_x_nc—(NC VHDL and NC SIM only) ensures an evaluation of @x that

1.4 FCS for Method Ports and SystemC Integration

1-4 About This Specman Elite Release

1.4.1 New Method Port Attribute

1.5 ASCII Format for Support Requests

1.6 sn_which.sh Now Documented

About This Specman Elite Release 1-5

1.7 4.3.4 Deprecation Updates

• “New 4.3.4 Deprecated Features” on page 1-6

1.7.1 New 4.3.4 Deprecated Features

1.7.2 Severity Changes for Existing Deprecation Categories

1-6 About This Specman Elite Release

1.7.3 specsim Command Replaced by specrun Command

1.8 Updates to Supported Simulators and

About This Specman Elite Release 1-7

1-8 About This Specman Elite Release

• “New Memory Configuration Options” on page 2-1

2.1 New Memory Configuration Options

• check_consistency—Triggers a heap consistency check. (This replaces the config debug

About This Specman Elite Release 2-1

2.2 Deprecation of Soft Binding for Ports