2009 06

VCS® / VCS® MX Beta
Feature Descriptions
Version C-2009.06 Beta
December 2008
Comments?
E-mail your comments about this manual to:
vcs_support@synopsys.com.
Copyright Notice and Proprietary Information
Copyright © 2008 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and
proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a
license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of
the software and documentation may be reproduced, transmitted, or translated, in any form or by any means,
electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as
expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
_________________________________ and its employees. This is copy number______.”
Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Cadabra, CATS, CRITIC, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality,
HSIM, HSPICE, iN-Phase, in-Sync, Leda, MAST, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical
Compiler, PrimeTime, SiVL, SNUG, SolvNet, System Compiler, TetraMAX, VCS, Vera, and YIELDirector are registered
trademarks of Synopsys, Inc.
Trademarks (™)
AFGen, Apollo, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, Columbia, Columbia-CE, Cosmos,
CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, DC Expert, DC Professional, DC Ultra, Design Analyzer,
Design Vision, DesignerHDL, Direct Silicon Access, Discovery, Encore, Galaxy, HANEX, HDL Compiler, Hercules,
Hierarchical Optimization Technology, HSIMplus, HSPICE-Link, iN-Tandem, i-Virtual Stepper, Jupiter, Jupiter-DP,
JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Magellan, Mars, Mars-Xtalk, Milkyway,
ModelSource, Module Compiler, Planet, Planet-PL, Polaris, Power Compiler, Raphael, Raphael-NES, Saturn,
Scirocco, Scirocco-i, Star-RCXT, Star-SimXT, Taurus, TSUPREM-4, VCS Express, VCSi, VHDL Compiler, VirSim, and
VMC are trademarks of Synopsys, Inc.
Service Marks (SM)
MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
Saber is a registered trademark of SabreMark Limited Partnership and is used under license.
All other product or company names may be trademarks of their respective owners.
ii
Contents
1. VCS SystemVerilog Features

SystemVerilog Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Parameterized Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
String Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Array Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SystemVerilog Linked Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 18
New SystemVerilog Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Task and Function Calls Using Virtual Interface Variables. . . 19
The $typename Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Fine-Grained Process Control Using the process Class . . . . 22
Assignment Patterns Using %p . . . . . . . . . . . . . . . . . . . . . . . 30
Signal Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Nested Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
’__FILE__ and ’__LINE__ Compiler Directives . . . . . . . . . . . 34
Extension to SystemVerilog $readmemb/$readmemh . . . . . . . . 35
Loading Memories with $readmemb and $readmemh. . . . . . 35
1
2. Assertions
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Overlapping Operators in Multiclock Environment . . . . . . . . . . . 42
Deferred Immediate Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Property Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Weak and Strong Sequence Operators . . . . . . . . . . . . . . . . . 44
Implication and Equivalence Operators . . . . . . . . . . . . . . . . . 45
until Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
nexttime Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
always Operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
eventually Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
followed-by Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Mixed Strength Property Reporting . . . . . . . . . . . . . . . . . . . . 49
Modeling Abort Conditions: accept_on, reject_on . . . . . . . . . 50
Inferred Value Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Recursive Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Local Variable Initialization and Input . . . . . . . . . . . . . . . . . . . . . 52
Global Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Past and Future Sampled Value Functions . . . . . . . . . . . . . . 54
let Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Debug Support for New Constructs . . . . . . . . . . . . . . . . . . . . 57
Note on Cross Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2
3. Coverage Enhancements
SystemVerilog Language Enhancements . . . . . . . . . . . . . . . . . . 60
Wildcard Support in binsof Expressions . . . . . . . . . . . . . . . . 60
Wildcard Array Bins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
State Bin Names as States in Transition Sequences . . . . . . . 66
OpenVera Language Enhancement . . . . . . . . . . . . . . . . . . . . . . 69
Wildcard Support in binsof Expressions . . . . . . . . . . . . . . . . 69
Coverage Exclusion Enhancement . . . . . . . . . . . . . . . . . . . . . . . 73
Understanding Half-Toggle Exclusion . . . . . . . . . . . . . . . . . . 73
Unified Coverage Reporting Enhancements . . . . . . . . . . . . . . . . 75
Reporting Only Uncovered Objects . . . . . . . . . . . . . . . . . . . . 75
Understanding Covergroup Page Splitting. . . . . . . . . . . . . . . 86
DVE Coverage Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Branch Coverage and Implied Branches . . . . . . . . . . . . . . . . 88
DVE Coverage Source / Database File Relocation . . . . . . . . 88
Container Exclusion State Markers . . . . . . . . . . . . . . . . . . . . 90
4. Coverage Convergence Technology

Compile-Time Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Coverage Convergence Option . . . . . . . . . . . . . . . . . . . . . . . 94
Coverage Model Autogeneration Options . . . . . . . . . . . . . . . 94
Coverage Convergence Runtime Options . . . . . . . . . . . . . . . . . 95
URG Options for Bias File Generation . . . . . . . . . . . . . . . . . . . . 97
Coding Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3
Constraints and Coverage Model on the Same Variables . . 98
No Procedural Overwriting of Values Generated by the Solver 98
Coverage Should Be Sampled Between Consecutive Calls to
randomize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Use Open Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Avoid Explicit or Implicit Partitioning in Constraints . . . . . . . 100
Avoid In-line Constraints and the Use of “constraint_mode” and
“rand_mode” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Automatic Generation a Coverage Model from Constraints . . . . 100
Coverage Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Contribution to Coverage Scoring . . . . . . . . . . . . . . . . . . . . . 108
Coverage Model Inference for In-line Constraints . . . . . . . . . 108
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Understanding Bias Files and Coverage Convergence. . . . . . . . 110
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
What Is a “Test”? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using Coverage Convergence Bias File to Pick Target Coverage
Holes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Automatic Generation of Coverage Convergence Bias Files . . . 113
Repeatability of Test Results for Parallel Regression Runs . . . . 114
Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Running a Single Test with Randomized Configurations . . . . 115
Running a Single Test with Randomized Transactions . . . . . 115
Using a Bias File for a Parallel Regression . . . . . . . . . . . . . . 116
Autogenerating a Coverage Model . . . . . . . . . . . . . . . . . . . . 117
4
Methodology and Flow Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Scenario: All Tests Have the Same Constraints and Coverage Space
(Recommended). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Scenario: Tests Are Grouped Into Categories With Each Category
Having Specific Test Constraints . . . . . . . . . . . . . . . . . . . 119
Scenario: Coverage Database Being Loaded in the Beginning of a
Test Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5. DVE Features
Back Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Setting the Back Trace Properties . . . . . . . . . . . . . . . . . . . . . 124
Using the Back Trace Schematic Toolbar . . . . . . . . . . . . . . . 125
Editing the Bus Bit Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Creating and Updating Counters. . . . . . . . . . . . . . . . . . . . . . . . . 126
Deleting Signal Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Creating Multiple Groups when Adding Multiple Scopes into Wave View
130
Visualizing X at all Zoom Levels . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Viewing Interfaces as Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6. Viewing values in Symbolic format
7. Constraints Features
SystemVerilog Constraint Features . . . . . . . . . . . . . . . . . . . . . . . 142
5
Array and XMR Support in std::randomize() . . . . . . . . . . . . . 142
XMR Support in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 145
Constraint Debugging and Profiling. . . . . . . . . . . . . . . . . . . . . . . 148
Using Constraint Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Using the Hierarchical Constraint Debugger Report . . . . . . . 151
Debugging Constraint Solver Diagnostics . . . . . . . . . . . . . . . . . . 154
Solver Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Methodology for Using Unidirectional Constraints . . . . . . . . . 156
Constraint Solver Search Space and Solution Space . . . . . . 158
Search Space Reduction And Random Assignment . . . . . . . 159
Using the Constraint Solver Diagnostics . . . . . . . . . . . . . . . . 160
Classes of Constraint Diagnostics . . . . . . . . . . . . . . . . . . . . . 163
8. Parallel VCS
Parallel VCS Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Use Model for Design Profiling and Simulation . . . . . . . . . . . 173
Use Model for Assertion Simulation. . . . . . . . . . . . . . . . . . . . 174
Use Model for Toggle and Functional Coverage . . . . . . . . . . 174
Use Model for VPD Dumping. . . . . . . . . . . . . . . . . . . . . . . . . 175
Running Parallel Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Design Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Assertion Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
VPD File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6
Profiling a Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Profiling a Serial Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Specifying Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Profiling a Parallel Simulation . . . . . . . . . . . . . . . . . . . . . . . . 183
Running PVCS Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Current Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
9. VMM Additions and Enhancements

VMM RAL C Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Execution Timeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Writing Firmware Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VMM Standard Library Class Additions . . . . . . . . . . . . . . . . . . . . 218
vmm_opts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
vmm_opts::get_bit() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
vmm_opts::get_int() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
vmm_opts::get_string() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
vmm_opts::get_help() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
vmm_scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
vmm_scenario::stream_id . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
vmm_scenario::scenario_id . . . . . . . . . . . . . . . . . . . . . . . . . . 226
vmm_scenario::scenario_kind . . . . . . . . . . . . . . . . . . . . . . . . 227
vmm_scenario::length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
vmm_scenario::repeated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7
vmm_scenario::repeat_thresh . . . . . . . . . . . . . . . . . . . . . . . . 230
vmm_scenario::repetition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
vmm_scenario::define_scenario() . . . . . . . . . . . . . . . . . . . . . 232
vmm_scenario::redefine_scenario(). . . . . . . . . . . . . . . . . . . . 233
vmm_scenario::scenario_name(). . . . . . . . . . . . . . . . . . . . . . 234
vmm_scenario::psdisplay() . . . . . . . . . . . . . . . . . . . . . . . . . . 235
vmm_scenario::set_parent_scenario(). . . . . . . . . . . . . . . . . . 236
vmm_scenario::get_parent_scenario() . . . . . . . . . . . . . . . . . 237
vmm_object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
vmm_object::type_e. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
vmm_object::new . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
vmm_object::set_parent() . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
vmm_object::get_parent() . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
vmm_object::get_type() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
vmm_object::get_hier_inst_name() . . . . . . . . . . . . . . . . . . . . 245
vmm_object::display() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
vmm_object::psdisplay() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
vmm_ms_scenario_gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
vmm_ms_scenario_gen::stop_after_n_scenarios . . . . . . . . . 249
vmm_ms_scenario_gen::stop_after_n_insts . . . . . . . . . . . . . 250
vmm_ms_scenario_gen::scenario_count . . . . . . . . . . . . . . . 251
vmm_ms_scenario_gen::inst_count . . . . . . . . . . . . . . . . . . . 252
vmm_ms_scenario_gen::get_n_scenarios() . . . . . . . . . . . . . 253
vmm_ms_scenario_gen::get_n_insts() . . . . . . . . . . . . . . . . . 254
vmm_ms_scenario_gen::GENERATED. . . . . . . . . . . . . . . . . 255
vmm_ms_scenario_gen::DONE . . . . . . . . . . . . . . . . . . . . . . 256
8
vmm_ms_scenario_gen::register_ms_scenario() . . . . . . . . . 257
vmm_ms_scenario_gen::ms_scenario_exists(). . . . . . . . . . . 258
vmm_ms_scenario_gen::get_ms_scenario() . . . . . . . . . . . . . 259
vmm_ms_scenario_gen::get_ms_scenario_name() . . . . . . . 260
vmm_ms_scenario_gen::get_ms_scenario_index() . . . . . . . 261
vmm_ms_scenario_gen::get_names_by_ms_scenario() . . . 262
vmm_ms_scenario_gen::get_all_ms_scenario_names(). . . . 263
vmm_ms_scenario_gen::replace_ms_scenario() . . . . . . . . . 264
vmm_ms_scenario_gen::unregister_ms_scenario() . . . . . . . 265
vmm_ms_scenario_gen::unregister_ms_scenario_by_name() 266
vmm_ms_scenario_gen::select_scenario . . . . . . . . . . . . . . . 267
vmm_ms_scenario_gen::scenario_set[$] . . . . . . . . . . . . . . . 268
vmm_ms_scenario_gen::register_channel() . . . . . . . . . . . . . 269
vmm_ms_scenario_gen::channel_exists(). . . . . . . . . . . . . . . 270
vmm_ms_scenario_gen::get_channel(). . . . . . . . . . . . . . . . . 271
vmm_ms_scenario_gen::get_channel_name() . . . . . . . . . . . 272
vmm_ms_scenario_gen::get_names_by_channel() . . . . . . . 273
vmm_ms_scenario_gen::get_all_channel_names() . . . . . . . 274
vmm_ms_scenario_gen::replace_channel() . . . . . . . . . . . . . 275
vmm_ms_scenario_gen::unregister_channel() . . . . . . . . . . . 276
vmm_ms_scenario_gen::unregister_channel_by_name() . . . 277
vmm_ms_scenario_gen::register_ms_scenario_gen() . . . . . 278
vmm_ms_scenario_gen::ms_scenario_gen_exists(). . . . . . . 279
vmm_ms_scenario_gen::get_ms_scenario_gen() . . . . . . . . . 280
vmm_ms_scenario_gen::get_ms_scenario_gen_name() . . . 281
vmm_ms_scenario_gen::get_names_by_ms_scenario_gen() 282
9
vmm_ms_scenario_gen::get_all_ms_scenario_gen_names() 283
vmm_ms_scenario_gen::replace_ms_scenario_gen() . . . . . 284
vmm_ms_scenario_gen::unregister_ms_scenario_gen() . . . 285
vmm_ms_scenario_gen::unregister_ms_scenario_gen_by_name()
286
vmm_xactor_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
vmm_xactor_iter::new() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
vmm_xactor_iter::first() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
vmm_xactor_iter::xactor() . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
vmm_xactor_iter::next() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
‘foreach_vmm_xactor() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
vmm_log::catch() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
vmm_test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
vmm_test::log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
vmm_test::new() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
vmm_test::get_name() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
vmm_test::get_doc() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
vmm_test::run() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
vmm_test_begin() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
vmm_test_end() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
vmm_ms_scenario::get_channel(). . . . . . . . . . . . . . . . . . . . . 304
vmm_channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
vmm_channel::record() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
vmm_channel::playback() . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
vmm_ral_block_or_sys Base Class Additions. . . . . . . . . . . . . . . 311
10
vmm_ral_block_or_sys::set_offset() . . . . . . . . . . . . . . . . . . . 312
vmm_ral_block_or_sys::get_reg_by_offset() . . . . . . . . . . . . . 313
10. VMM Planner MS Doc Annotation

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
License Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Compatibility with the VMM Planner Spreadsheet Annotation Flow
319
hvp annotate Command Arguments . . . . . . . . . . . . . . . . . . . . . . 319
Capturing a Verification Plan in Doc XML Format . . . . . . . . . . . . 322
Built-In Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Table Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Other Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Debugging the Doc Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
[Style|Table] Keyword Indicator . . . . . . . . . . . . . . . . . . . . . . . 332
Unique Error Code in Error Messages. . . . . . . . . . . . . . . . . . 334
How to Get Scores Back-Annotated in the Doc. . . . . . . . . . . . . . 334
Plan/Feature Score Summary . . . . . . . . . . . . . . . . . . . . . . . . 335
Measure Score Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Navigating Down to a Subplan . . . . . . . . . . . . . . . . . . . . . . . 337
11
11. URG Enhancements
New URG Features and Changes. . . . . . . . . . . . . . . . . . . . . . . . 339
Improved HTML Page Format . . . . . . . . . . . . . . . . . . . . . . . . 340
Incompleteness Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Omitting Filtered Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Dumping User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Predictable Page Naming Convention . . . . . . . . . . . . . . . . . . 343
Add New Hyperlinks from group bin and group instance. . . . 343
New –show hvpprob Command for Problem Reports . . . . . . 344
Test Metric Coloring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
License Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
12. Run Command

run Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
12
1
VCS SystemVerilog Features 1
This chapter contains the following topics:
• “SystemVerilog Enhancements”
• “New SystemVerilog Features”
• “Extension to SystemVerilog $readmemb/$readmemh”
SystemVerilog Enhancements
Enhancements have been made to the following features. These

features are described in the SystemVerilog Language Reference
Manual:
• Strings in structs
• Queues in unpacked structs
VCS SystemVerilog Features

13
• Associative arrays of unpacked structs
• Multidimensional queues
• Arrays of queues
• Multidimensional associative arrays
• Multidimensional queues
• Integer indexed arrays
• Selecting an array word connected to a task ref port
• Casting of derived class with base class
Additional SystemVerilog enhancements are described in the
following sections:
• “Parameterized Mailboxes”
• “String Casting”
• “Array Literals”
• “SystemVerilog Linked Lists”
Parameterized Mailboxes
The default mailbox has no type. A mailbox can send and receive
any type of data. This can result in runtime errors due to type
mismatches between a message and the type of the variable to
which the message gets assigned. When a mailbox is used to
transfer a particular message type, it is useful to detect type
mismatches at compile time. For a parameterized mailbox, the

14
compiler checks that calls to the mailbox methods use the same
argument types as the mailbox type so that type mismatches are
caught by the compiler.
Parameterized mailboxes use the same parameter syntax as

parameterized classes, modules, and interfaces.
Syntax
mailbox #(type = dynamic_type)
where dynamic_type is a type that enables runtime type checking

(the default).
Example
You declare a parameterized mailbox of a particular type by
specifying the type as in the following example.
typedef mailbox #(string) s_mbox;

s_mbox sm = new;
string s;
sm.put( "hello" );
...
sm.get( s ); // s <- "hello"
Parameterized mailboxes provide the same methods as dynamic

mailboxes, which are:
• num()
• new()
• get()
• peek()
• put()

15
• try_get()
• try_peek()
• try_put()
The compiler checks that calls to the put(), try_put(), peek(),
try_peek(), get(), and try_get() methods use the same
argument type as the parameterized mailbox type.
String Casting
String literals can be cast to a packed or unpacked array, following

the same rules as those for assigning a literal string to a packed or
unpacked array.
Example
program rb;
initial
begin
logic [39:0] StringLogic = "hello";
string realstring;
realstring = string'(StringLogic);
$display("%s -- %s\n", StringLogic, realstring);
end
endprogram
Array Literals
Any unpacked array can be written one entry at a time, or all the
array contents can be replaced using an array literal. See
“Limitations on Variable-Sized Arrays” for restrictions on this feature.
The syntax for associative arrays is:

16
'{index:value}
The syntax for other unpacked dimensions is:
'{val1, val2, val3} or '{default: value}
In arrays that have multiple unpacked dimensions, array literals can

be nested.
Example 1-1 Variable-sized arrays
// Nested array literals

int mix7[][*][3]='{'{0:'{11,22,33}, 11:'{111,222,333}},
'{5:'{5,8,3}, 1:'{'1,1,1}}, '{3:'{1,2,3}, 4:'{3,2,1},
7:'{9,9,9}}};
// An associative array of strings indexed by 2-state

// integers
string words [int];
// An associative array of 4-state integers indexed by

// strings
integer tab [string] = '{"Peter":20, "Paul":22, "Mary":23 };
For an associative array, if a nonexistent element is read, the default

initial value shown in Table 1-1 is returned.
Table 1-1 Default values for associative array elements
Type of array Default value

4-state integral type ‘X
2-state integral type ‘0
string “”
enumeration base type default
initial value

17
Limitations on Variable-Sized Arrays
The following features are not supported:
• '{default: value} for associative arrays

• Identifiers imported from packages, in associative arrays
• Only the following types of associative array indexes are
supported:
- integer literal
- string literal
- identifier
• Cross-module references into multidimensional associative
arrays
• structure element type
An associative array declared with a non-constant RHS initializer
may be initialized before expressions referred to in the RHS are
initialized.
Assignments such as "aa = '{0:aa[1], 1:aa[0]}" are

executed as if they were separate assignments. This can have
unexpected results.
SystemVerilog Linked Lists
VCS provides a library implementation for SystemVerilog linked lists

as specified in the SystemVerilog Language Reference Manual.
The VCS Users Guide provides details of how to use this feature.

18
New SystemVerilog Features
The following SystemVerilog features have been implemented in

2009.06:
• “Task and Function Calls Using Virtual Interface Variables”

• “The $typename Function”
• “Fine-Grained Process Control Using the process Class”
• “Assignment Patterns Using %p”
• “Signal Aliasing”
• “Nested Classes”
• “’__FILE__ and ’__LINE__ Compiler Directives”
Task and Function Calls Using Virtual Interface

Variables
Tasks and functions in a virtual interface can be called using a

variable of that virtual interface type. In the following example, the
Read_data() function in the Bus interface is called using the vB
virtual interface variable in the test program :
interface Bus;
function void Read_data(logic [31:0] data);
$display("Data Received = %0d", data);
endfunction
endinterface
module Cpu_process;
logic [31:0] rdata = 256;
Bus b();

19
endmodule
program test;
virtual Bus vB = Cpu_process.b;
initial begin
vB.Read_data(Cpu_process.rdata);
end
endprogram
The $typename Function
The $typename system function returns a string that represents the

resolved type of its argument.
Syntax
$typename (expression | data_type)
The return string is constructed using the following steps:
1. A typedef that creates an equivalent type is resolved back to

built-in or user-defined types.
2. The default signing is removed, even if present explicitly in the
source.
3. System-generated names are created for anonymous structs,
unions, and enums.
4. A ‘$’ is used as the placeholder for the name of an anonymous
unpacked array.
5. Actual encoded values are appended with enumeration named
constants.
6. User-defined type names are prefixed with their defining package
or scope name space.

20
7. Array ranges are represented as unsized decimal numbers.
8. White space in the source is removed and a single space is added
to separate identifiers and keywords from each other.
This process is similar to the way that type matching is computed,
except that simple bit vectors types with predefined widths are
distinguished from those with user-defined widths. Thus $typename
can be used in string comparisons for stricter type comparison of
arrays than with type references.
When called with an expression as its argument, $typename

returns a string that represents the self-determined type result of the
expression. The expression’s return type is determined during
elaboration, but never evaluated. When used as an elaboration time
constant, the expression shall not contain any hierarchical
references or references to elements of dynamic objects.

21
Example 1-2 Values returned by $typename for different types of variables
Source code Value returned by $typename

typedef bit node; "bit"
node signed [2:0] X; "bit signed[2:0]"
int signed Y; "int"
package A; "enum{A=32'd0,B=32'd1,C='32d99
enum {A,B,C=99} X; }A::e$1"
typedef bit [9:1'b1] word; "A::bit[9:1]"
endpackage : A
import A::*; "struct{bit A;bit B;}top.AB_t$[0:9]"
module top;
typedef struct {node A,B;} AB_t;
AB_t AB[10];
endmodule
Fine-Grained Process Control Using the process Class
A process is a built-in class that allows one process to access and

control another process once it has started running. Processes can
be passed to tasks or functions, and can become members of other
classes.
The prototype for the process class is as follows:
class process;
enum state { FINISHED, RUNNING, WAITING, SUSPENDED,
KILLED };
static function process self();
function state status();
task kill();
task await();
task suspend();
task resume();
endclass

22
A process handle can be created only by a call to the process class
self() static method.
A process cannot be extended. An error is issued if this is attempted.
You cannot use new to create an object of the process class. An error
is issued if this is attempted.
The following terms are used below:
• fork...join represents any of the fork-join/join_any/

join_none statements.
• thread_n is a thread of a fork, where n denotes the number of
the thread of the fork.
• tf_n represents a task or function call.
process Class Members

self()
The self() function returns a process class handle

corresponding to the process thread in which the function call is
executed. If the handle does not exist already a new handle is
allocated and returned, otherwise the existing handle is returned.
The handle can be used for controlling the process and accessing
its status using process class methods. Process status is marked
RUNNING.
Example
process p;
...
fork
thread_1

23
tf_1
tf_2
p = process::self
thread_2
join
...
process handle "p" belong to "thread_1".
enum state { FINISHED, RUNNING, WAITING, SUSPENDED,

KILLED };
state/status()
The status() function returns the current state of the process.

The possible states are:
FINISHED – The process finished execution normally.
RUNNING – The process is running (not blocked).
WAITING – The process is blocked by a delay/@/wait, or due

to a condition such as a blocking mailbox or semaphore call.
SUSPENDED – The process has been stopped by a suspend()

call. The process is not executing at all.
KILLED – The process was killed by a kill() call or

disable.
The process status is updated upon a change in the process

execution and follows the process execution state. Every time a
process blocks, the process state is updated to WAITING. Upon
unblocking of the process, the process state is updated to
RUNNING.

24
Example
process p;
process::state estate;
...
fork
thread_1
tf_1
tf_2
p = process::self
#10;
...
thread_2
join_none
#1;
estate = p.status(); // WAITING
...
kill()
The kill() task terminates the process and all its child
processes, just like disable. A process can be killed if it is not
already finished. Process status is marked as KILLED.
Example
process p;
...
fork
thread_1
tf_1
tf_2
p = process::self
#10;
$display("I was killed");
thread_2
join_none
#1;

25
p.kill();
...
await()
The await() task blocks the current thread. It unblocks once the
awaited process has finished execution normally. If the awaited
process is killed, await() will never unblock. Calling await()
on the current process is a runtime error. (A process cannot wait
for its own completion.) If the process has already finished
execution, then await() does not block.
Example
process p;
...
fork
thread_1
tf_1
tf_2
p = process::self
#10;
...
thread_2
join_none
...
#1
p.await();
$display("I’m waiting for thread_1 to finish");
...
suspend()/ resume()

26
The suspend() task suspends the execution of the process. It
can be called on the current process (a process can suspend
itself). A killed or finished process cannot be suspended. The
process status is marked as SUSPENDED.
The resume() task restarts a previously suspended process. If

the process is killed or terminated while it is suspended, then it
cannot resume. If the process has pending delay or waiting
events, then it cannot continue execution upon resumption. It must
wait for maturity of the blocking condition. Call resume() on a
process that suspended itself causes the process to continue
executing at the statement following the call to suspend(). The
process status is marked as RUNNING.
Unlike kill(), the suspend() and resume() tasks act only

on the process on which they are called and do not affect
execution of its child processes in any way.
Effects of suspend() on Waiting Processes
The following sections describe the effects of the suspend() task

on process that are waiting due to different reasons.
- Waiting on delay
If a process gets suspended while waiting for a delay to
mature, then, upon resumption, the process waits for the
remaining delay time.
Example
process p;
...
fork

27
thread_1
tf_1
tf_2
process = process::self
#10;
$display("I’ll resume at time 110");
thread_2
join_none
#3;
p.suspend();
#100;
p.resume();
The process p above must wait for a delay of 10 time units to

mature. If the process is suspended after 3 time units, then,
upon resumption, it must wait for 7 more time units before it can
continue execution. This is independent of the amount of time
the process spent in suspension.
- Waiting on @(SV_event)
If a process gets suspended while waiting for a SystemVerilog
event, and that event triggers while the process is suspended,
then the process will unblock from waiting but it will not continue
executing until its resume() task is called.
- Waiting on blocking mailbox or semaphore methods

If a process is suspended while waiting for a mailbox or
semaphore method to complete, and that method unblocks
while the process is suspended, then the process will unblock
from waiting but it will not continue executing until its resume()
task is called.
- Waiting on @(static_variable) or
wait(static_expression)

28
A static variable or expression is one that does not contain any
dynamic types such as class handles, dynamic arrays,
associative arrays, and so on.
A process waiting on a static variable or expression will not

unblock while it is suspended, no matter how many times the
static variable or expression changes.
- Waiting on @(dynamic_variable) or
wait(dynamic_expression)
A dynamic variable or expression is one that contains a dynamic
type such as a class handle, dynamic array, or associative array,
or a class reference using any of those.
A process waiting on a dynamic variable or expression will not

unblock while it is suspended, no matter how many times the
dynamic variable or expression changes. The value used as
the previous value for computing the change of the dynamic
expression is the value of the expression at the time of the
suspension. If the expression changes after the process thread
is suspended, then the previous value does not change. Unlike
the static variable case, in which the previous value gets
updated every time the variable’s value changes, checking for
a change of the static variable is done, upon resumption, using
the last value as the previous value. Therefore,
@(static_variable) cannot unblock upon resumption, but
@(dynamic_variable) can unblock upon resumption if the
value during suspension is different from the value at
resumption.
srandom()

29
The srandom() method can be called on a process handle,
which allows seeding of underlying process threads. This works
the same as calling srandom() directly in the process scope,
while providing the flexibility of seeding a process from outside
its scope, using the process handle.
Limitations
• The process::self.srandom() syntax is not supported
• Debug is not supported
• DPI calls are not supported
Assignment Patterns Using %p
The %p format specifier can be used to print aggregate expressions

such as packed structures and arrays. It prints the value as an
assignment pattern with named elements. For unions, only the first
declared elements are printed. In the case of a tagged union, it prints
“tag:value” along with the currently valid element.
The value of each element that is a singular type is printed as

follows:
• A packed structure data type prints its value as an assignment

pattern with named elements. Each element is printed under one
of these rules.
• An enumerated data type prints its value as an enumeration name
if the value is valid for that type. Otherwise the value prints
according to the base type of the enumeration.
• A string data type or string literal prints its value as a string.

30
• A chandle, class handle, event, or virtual interface prints a pointer,
except that a null handle value prints the word null.
• All other singular data types print their values unformatted.
The %p format specifier can also be used to print singular
expressions, in which case the expression is formatted as an
element of an aggregate expression described above.
Example
module top;
typedef enum {ON, OFF} switch_e;
typedef enum {switch10, switch20} switch_s;
typedef struct packed {switch_e sw; switch_s s;} pair_t;
pair_t va[int] = '{10 : '{ON,switch10}, 20 : '{OFF,

switch20}};
initial begin
$display("va[int] = %p;",va);
$display("va[int] = %0p;",va);
$display("va[10].s = %p;", va[10].s);
end
endmodule : top
The example above prints this:
va[int] = '{10:'{sw:ON, s:switch10}, 20:'{sw:OFF,

s:switch20}} ;
va[int] = '{10:'{sw:ON, s:switch10}, 20:'{sw:OFF,
s:switch20}} ;
va[10].s = switch10;

31
Signal Aliasing
An alias statement declares multiple names for the same physical

net or slice of bits in a net.
Syntax
alias net-expr|bit-expr = alias-expr [ = alias-expr ...];
Example
alias net_a = net_b = net_c = net_d;
The statement above results in three aliases:
alias net_a = net_d;

alias net_b = net_d;
alias net_c = net_d;
The members of an alias list are signals whose bits are on the same
physical nets. Each member must be the same size and the nets
must be of compatible types. For example, it is an error to use an
alias statement to connect a wand net to a wor net.
Variables are not allowed in alias statements.
The same nets can appear in multiple alias statements, so that a

net can belong to several aliases.
See the SystemVerilog Language Reference Manual for additional

information about net aliasing.
Note:
Standard SystemVerilog restrictions on hierarchical references in
alias statements and on aliasing a net or signal to itself do not
apply in the VCS implementation.

32
Nested Classes
The class scope resolution operator applies to all static elements of

a class: static class properties, static methods, typedefs,
enumerations, structures, unions, and nested class declarations.
Class scope resolved expressions can be read (in expressions),
written (in assignments or subroutine calls), or triggered (in event
expressions). They can also be used as the name of a type or a
method call.
Like modules, classes are scopes and can nest. Nesting allows
hiding of local names and local allocation of resources. This is often
desirable when a new type is needed as part of the implementation
of a class. Declaring types within a class helps prevent name
collisions and the cluttering of the outer scope with symbols that are
used only by that class. Type declarations nested inside a class
scope are public and can be accessed outside the class.
Parameterized outer classes are not supported for this feature.
Example 1-3 Nested classes in a linked list and in a binary tree

class StringList;
class Node; // Nested class for a node in a linked list
string name;
Node link;
endclass
endclass
class StringTree;
class Node; // Nested class for a node in a binary tree.
string name;
Node left, right;
endclass
endclass
// StringList::Node is different from StringTree::Node

33
’__FILE__ and ’__LINE__ Compiler Directives
The ’__FILE__ and ’__LINE__ compiler directives have been

implemented in this release, as described below. These directives
are described in "Compiler Directives" in the SystemVerilog
Language Reference Manual.
’__FILE__ expands to the string literal name of the current input

file. This is the path by which a tool opened the file, not the short
name specified in ’include or as a tool’s input file name argument.
’__LINE__ expands to the decimal current input line number.
’__FILE__ and ’__LINE__ are useful in generating error messages

to report problems. The message can state the line in the source at
which the problem was detected.
Example 1-4 ’__FILE__ and ’__LINE__ usage

$display("Internal error: null handle at %s, line %d.",
`__FILE__, `__LINE__);
An ’include directive changes the expansions of ’__FILE__ and

`’__LINE__ to correspond to the included file. At the end of that file,
when processing resumes on the input file that contained the
’include directive, the expansions of ’__FILE__ and ’__LINE__
revert to the values they had before the ’include and `__LINE__
is then incremented by one as processing moves to the line after the
ìnclude.
A ’line directive changes ’__LINE__ and might also change

’__FILE__ .

34
Extension to SystemVerilog $readmemb/$readmemh
The following SystemVerilog $readmemb/$readmemh tasks have

been extended as described in the following section:
• “Loading Memories with $readmemb and $readmemh”
Loading Memories with $readmemb and $readmemh
The $readmemb and $readmemh tasks described in "System Tasks

and Functions" in the SystemVerilog Language Reference Manual,
have been extended. Their functionality is described in this section.
$readmemb and $readmemh are system tasks that allow you to load
memory from a file on the disk, for use in simulating memories at
runtime. $readmemb reads in binary and $readmemh reads in
hexadecimal numbers.
Syntax
$readmemb ("file_name", memory_name [, start_addr
[, finish_addr]]);
$readmemh ("file_name", memory_name [, start_addr

[, finish_addr]]);
Reading Packed Data

$readmemb and $readmemh are extended to queues, unpacked
arrays of packed data, associative arrays of packed data, and
dynamic arrays of packed data. In such cases, the system tasks treat
each packed element as the vector equivalent and perform the
normal operation.

35
When working with associative arrays, indexes must be of integral
types. When an associative array’s index is of an enumerated type,
address entries in the pattern file are in numeric format and
correspond to the numeric values associated with the elements of
the enumerated type.
Note:
The real data type is not supported with these system tasks.
Reading 2-state Types

$readmemb and $readmemh are extended to packed data of 2-state
types, such as int or enumerated types. For 2-state integer types,
reading proceeds the same as for conventional Verilog variable
types (e.g., integer), with the exception that X or Z data are
converted to 0. For enumerated types, the file data represents the
numeric values associated with each element of the enumerated
type. If a numeric value is out of range for a given type, then an error
shall be issued and no further reading shall take place.
$readmemb and $readmemh for Dynamic Data Types
Dynamic Arrays
A dynamic array is any dimension of an unpacked array whose size
can be set or changed at runtime. The space for dynamic array
doesn’t exist until the array is explicitly created at runtime
The syntax to declare a dynamic array is:
data_type array_name[];
where data_type is the data type of the array elements. Dynamic

arrays support the equivalent types as fixed-size arrays.

36
Initializing and Loading Dynamic Arrays
• When loading a memory that has not been initialized yet, the
array must be initialized with the size of the given file (for example,
a = new[10]).
• When loading a dynamic array that has been initialized, if the file
requires a smaller or larger array than the existing array, then the
array is resized to the size of the file.
• If there is a start address specified in the $readmemb or
$readmemh call for an uninitialized dynamic array, then the
required finish address is calculated and a new array is allocated
and filled.
• Elements of the array that are not filled from the memory file are
filled with default values for the data type of the array.
• The start address can be a higher-numbered address than the
finish address. The contents of the memory file can be loaded into
the array in either ascending or descending order.
• You can also use the @ operator to make the memory file load into
the array in the reverse direction.
• For an uninitialized array and a memory file that has holes in it,
(for example, it starts from address 10), the first 10 elements of
the array are filled with the default value for the data type for the
array.
• Strings, chandles and class objects are not supported as memory
elements of memories by $readmemb or $readmemh.
Smart Queues
A queue is a variable-size, ordered collection of homogeneous
elements. A queue supports constant-time access to all its elements
as well as constant-time insertion and removal at the beginning or

37
the end of the queue. Each element in a queue is identified by an
ordinal number that represents its position within the queue, with 0
representing the first, and $ representing the last. A queue is
analogous to a one-dimensional unpacked array that grows and
shrinks automatically. Thus, like arrays, queues can be manipulated
using the indexing, concatenation, slicing operator syntax, and
equality operators.
Queues are declared using the same syntax as unpacked arrays, but
specifying $ as the array size. The maximum size of a queue can be
limited by specifying its optional right bound (last index).
Initializing and Loading Smart Queues

• If an uninitialized queue with start and finish addresses specified
is being loaded, and if the start address is 0, a new queue is
created and filled. If the start address is greater than 0, a new
queue is created with the size specified by the finish address. If
no finish address is specified, the memory file is loaded until the
end of the file is reached. Queue positions for which no values
are present in the memory file are filled with the default values for
the data type of the queue.
• For an uninitialized queue with start address 0 and no finish
address specified, a new queue with a size equal to the size of
the memory file is created.
• For an uninitialized queue with start address 0 and a specified
finish address, a queue of size finish address + 1. is created
• If the memory file is larger than the queue can hold, an error is
issued, but the queue is filled up to the specified finish address.
• For an existing queue, if there are more entries in the file than the
finish address of the queue, a new queue is created with the
required size.

38
• For an existing queue with start index greater than the finish index,
only those elements within the size of the existing queue are filled.
If the finish address is greater than the current size of the queue,
an error is issued.
• You can also use the @ operator to make the memory file load into
the array in the reverse direction. For an existing new queue, if
the @ operator is trying to fill a position larger than the current size
of the queue, an error is issued.
• For an uninitialized queue whose address file starts with an
address higher than 0, the queue elements that are not present
in the memory file are filled with default values for the data type.
• For an uninitialized array and a memory file that has holes in it,
(for example, it starts from address 10), the first 10 elements of
the array are filled with the default value for the data type for the
array.
• Strings, chandles and class objects are not supported as memory
elements of memories by $readmemb or $readmemh.
Associative Arrays
Dynamic arrays are useful for dealing with contiguous collections of
variables whose number changes dynamically.
When the size of the collection is unknown or the data space is

sparse, an associative array is a better option. An associative array
does not have any storage allocated until it is used, and the index
expression is not restricted to integral expressions, but can be of any
type.
An associative array implements a lookup table of the elements of its

declared type. The data type to be used as an index serves as the
lookup key, and imposes an ordering.

39
The syntax to declare an associative array is:
data_type array_id [index_type];
where:
data_type is the data type of the array elements. It can be any

type allowed for fixed-size arrays.
array_id is the name of the array being declared.
index_type is the data type to be used as an index, or *. If * is

specified, then the array is indexed by any integral expression of
arbitrary size. An index type restricts the indexing expressions to
a particular type. It shall be illegal for index_type to declare a
type.
Initializing and Loading Associative Arrays

Strings and class objects are not allowed as associative array
indexes. Otherwise, initializing and loading of associative arrays
is the same as for dynamic arrays.

40
2
Assertions 1
This chapter describes the implementation of beta features for
SystemVerilog Assertions. Many of these features are part of SV
LRM 2009 (draft) and detailed descriptions for them is available in
the LRM.
This chapter contains the following sections:
“Use Model” on page 2-40
“Overlapping Operators in Multiclock Environment” on page 2-40
“Deferred Immediate Assertions” on page 2-41
“Property Operators” on page 2-42
“Inferred Value Functions” on page 2-49
“Recursive Properties” on page 2-50
Assertions
39
“Local Variable Initialization and Input”
“Global Clocking” on page 2-52
“let Operator” on page 2-55
“Limitations” on page 2-55
Use Model
You must use the –assert svaext compile time option for all the
new SVA features .
Note:
The –assert svaext option must be used at analysis phase
(vlogan) for the UUM flow.
Overlapping Operators in Multiclock Environment
SV 1800-2005 LRM allowed only non-overlapping implication (|=>)

operator to be used in multiclock properties. This is at times difficult
and restricts the usage. LRM 2009 relaxes this and allows
overlapping operators as well.
You can use the operators ##0, |->, if … else, and #-# in
multiclock environments.
@clk1 a ##0 @clk2 b
@clk1 s |-> @clk2 p
@clk1 if (b) @clk2 p1 else @clk3 p2
Assertions
40
Either clk 1 and clk2 (resp. clk3) may occur in the same time step, or
it may occur in a future time step after clk1
This feature is implemented in conformance with the IEEE P1800-

2009 Standard for SystemVerilog — Unified Hardware Design,
Specification, and Verification Language.
Deferred Immediate Assertions
Immediate assertions used in combinational always blocks may fire

on 0-width glitches. They may produce unnecessary noise in
simulation reports.
In the example below, when a changes, always will execute 2x and

the assertion will fire on a transient value.
assign not_a = !a;

always_comb begin : b1
glitch_prone_check: assert (not_a != a);
end
Deferred assertions help in such cases. It triggers the simulation

report on the final, settled value of a given time step thereby
producing single report line.
The syntax for Deferred assertion is:
assert #0 (expression) action_block
always_comb begin : b1
def_final_check: assert #0 (not_a != a);
end
Assertions
41
Immediate assertions can an also be used in non-procedural context
(implicit always_comb).
Immediate cover is also supported in deferred version.
module def_assert_ex;
logic a,b;
conc_def_assert: assert #0 (a == b);

endmodule : def_assert_ex
This is equivalent to:
module def_assert_ex;
logic a,b;
always_comb begin
equiv_def_assert: assert #0 (a == b);
end
endmodule : def_assert_ex
Property Operators
This section describes implemented property operators

implemented in conformance with the IEEE P1800-2009 Standard
for SystemVerilog — Unified Hardware Design, Specification, and
Verification Language.
Weak and Strong Sequence Operators
The weak and strong sequence property operators are defined as

follows:
weak (sequence_expr)
Assertions
42
A success occurs if there is a match or incomplete evaluation
when the simulation finishes.
strong (sequence_expr)
Success requires a match during simulation; otherwise a
mismatch results.
By default, sequence_expr property is
• Weak in assert and assume

• Strong in cover property
Implication and Equivalence Operators
Implication and equivalence operators are implemented for

expression and property levels:
• At the expression level

• expression1 -> expression2 is shorthand for
(!expression1 || expression2)
• expression1 <-> expression2 is shorthand for
(!expression1 || expression2) &&
(!expression2 || expression1)
• At the property level
• property1 implies property2 is shorthand for
(not property1) or property2
• property1 iff property2 is shorthand for
((not property1) or property2) and
(not property2) or property1)
Assertions
43
until Operator
SystemVerilog 2009 adds the until operator. VCS supports 4

forms of until operator:
weak until (Non-overlapping)
strong until (Non-overlapping)
weak until_with (Overlapping)
strong until_with (Overlapping)
Weak versions
• property_expr1 until property_expr2 is the weak

non-overlapping form.
• property_expr1 until_with property_expr2 is the
weak overlapping form. This form requires that
property_expr2 eventually evaluates true for until to
succeed.
Strong versions:
• property_expr1 s_until property_expr2 is the strong

non-overlapping form.
• property_expr1 s_until_with property_expr2 is the
strong overlapping form. This form requires that
property_expr2 eventually evaluates true for until to
succeed.
Assertions
44
nexttime Operator
There are four variants of the nexttime property operator:
• nexttime property_expr is weak and evaluates the

expression at the next clock tick.
• nexttime [N] property_expr is weak and evaluates the
expression at the N-th tick, if it exists.
• s_nexttime property_expr is strong nexttime and evaluates
the expression at the next tick. A clock tick must occur.
• s_nexttime [N] property_expr is strong nexttime and
evaluates the expression at the N-th tick. N clock ticks must occur.
always Operator
The always operator has two variants:
• always property_expr is weak and is true as long as there

is a tick.
• always [cycle_delay_const_range_expression]
property_expr is weak and is true during the range. It may
not have enough ticks for the range.
• s_always [constant_range] property_expr strong is
true during the range. It must have enough ticks for the range.
Note that assert property(p) has an implicit always.
Assertions
45
Example
This property sets an assumption that once reset is HIGH for 5
continuous clocks, it remains low forever. The followed-by operator
#=# is discussed in LRM and also below in this document.
initial rst_stays_low : assume property

(reset[*5] #=# always !reset) ;
eventually Operator
The eventually operator evaluates an expression within a range of

ticks. It has three variants:
• eventually [constant_range] property_expr is weak.

It evaluates the expression within the range of ticks in the future.
It may not have enough ticks for the range.
• s_eventually property_expr is strong. It evaluates the
expression, which must be true in the future. It must have enough
ticks for it to be true.
• s_eventually
[cycle_delay_const_range_expression] is strong. It
must be true in the range of ticks and must have ticks for the range.
followed-by Operator
The followed-by operator (#-#, #=#) is useful when a sequence

needs to be followed by a property within a specified interval. It is a
dual operator of |-> , |=>, respectively. For example,
• seq #-# prop is the same as not (seq |-> not prop)
Assertions
46
• seq #=# prop is the same as not (seq |=> not prop)
seq must have at least one match followed by a success of prop.
When prop is a sequence strong(seq1) then
• seq #-# strong(seq1) is the same as strong(seq ##0

seq1)
• seq #=# strong(seq1) is the same as strong(seq ##1
seq1)
Mixed Strength Property Reporting
The concept of weak and strong operators is closely related to an

important notion of safety properties. Safety properties have the
characteristic that all their failures happen at a finite time. For
example., the property always a is safety since it is violated only if
after finitely many clock ticks there is a clock tick at which a is false,
even if there are infinitely many clock ticks in the computation. To the
contrary, a failure of the property s_eventually a on a
computation with infinitely many clock ticks cannot be identified at a
finite time: if it is violated, the value of a must be false at each of the
infinitely many clock ticks.
Since typical simulations complete in finite number of clock ticks,

VCS has implemented a flexible means for users to interpret the
result of a strong and weak operators.
In VCS, strong and weak properties are not distinguished as to the

reporting at the end of simulation. In all cases, if a property
evaluation attempt did not complete evaluation, it will be reported as
Assertions
47
"unfinished evaluation attempt", rather than success or failure.
Depending on the property, the user may then decide the effective
outcome.
Modeling Abort Conditions: accept_on, reject_on
Abort properties model abort conditions by controlling asynchronous

aborts based on sampled values of expressions.
• accept_on makes the property true when the expression

becomes true.
accept_on (expression) property_expr
• reject_on makes the property false when the expression

becomes true.
reject_on(expression) property_expr
accept_on and reject_on can be nested within properties.
If abort occurs simultaneous with property result, abort dominates.
Synchronous versions are sync_accept_on and

sync_reject_on, In which case:
• If simultaneous aborts occur the one at the higher level in syntax

order dominates.
• If abort occurs simultaneous with property result, abort dominates.
Synchronous versions are sync_accept_on and
sync_reject_on.
Assertions
48
Example
assert property (@(clk)
go ##1 get[*2] |->
reject_on(stop) put[->2]);
Inferred Value Functions
Use elaboration-time system functions to query the inferred clocking

event expression, disable expression, and enable condition. The
inferred clocking event expression is the current resolved event
expression that can be used in a clocking event definition. It is
obtained by applying clock flow rules to the point where
$inferred_clock is called.
$inferred_clock
Returns the expression of the inferred clocking event. There must
be a current resolved event expression when $inferred_clock is
encountered or an error is issued.
$inferred_disable
Returns the inferred disable expression.
$inferred_enable
Returns the inferred enable condition. $inferred_enable is a
VCS extension to the Inferred functions and not a standard LRM
feature.
$inferred_clock and $inferred_disable are instantiated in

conformance with the IEEE P1800-2009 Standard for SystemVerilog
— Unified Hardware Design, Specification, and Verification
Language.
Assertions
49
Recursive Properties
Recursive properties are implemented in this release. Recursive

properties substitute in assertions and unfold until all unique property
instances are reached (as in a tree structure with feedback
references for recursion). Operators are instantiated following the
tree in postorder and loops are closed by passing handles.
Example
property prop_always(p);
p and (1'b1 |=> prop_always(p));
endproperty
is a recursive property that says that the formal argument property p

must hold at every cycle. This example is useful if the ongoing
requirement that property p hold applies after a complicated
triggering condition encoded in sequences:
property p1(s,p);
s |=> prop_always(p);
endproperty
Support for recursive properties is an update in conformance with

IEEE Std 1800™-2005 Standard for SystemVerilog — Unified
Hardware Design, Specification, and Verification Language.
Local Variable Initialization and Input
The use of local variables allows arguments of sequences and

properties to serve as local variable declarations. In this release,
local variable initializers:
Assertions
50
• Allow initialization of local variables in the declaration.
• Assign initial values in the order of the local variable declarations.
• Can initialize by actual argument and preceding local variables in
an expression.
property p();
int a = 1;
int b = a+2;
…
endproperty
A local variable argument:
• Passes “by value” of actual argument for input direction, by

reference for output direction.
• On input and inout, implicitly creates a local variable
declaration and initialization by the actual argument.
• On inout and output in sequences assigns the local value to the
external local variable actual arg.
• Can be used in recursive properties and LTL
property p(local input int x);
int a = x;
int b = a+2;
@clk (dut_y == x, a+=1) … ;
endproperty
Local variable input and initialization are implimented in
conformance with the IEEE P1800-2009 Standard for SystemVerilog
— Unified Hardware Design, Specification, and Verification
Language.
Assertions
51
Support for use of local variables with property operators is an
update in conformance with IEEE Std 1800™-2005 Standard for
SystemVerilog — Unified Hardware Design, Specification, and
Verification Language.
Global Clocking
Global clocking is to represent a system clock.
The syntax for the global clocking specification statement is as

follows:
global clocking [clocking_identifier ] clocking_event ;

endclocking [ : clocking_identifier ]
There can be only one global clocking block per system.

SystemVerilog provides a system function to refer to the global
clocking. This helps in writing generic assertions.This system
function $global_clock returns the event expression specified in
the global clocking statement. The function has no arguments.
This feature is implemented in conformance with the IEEE P1800

Standard for SystemVerilog — Unified Hardware Design,
Specification, and Verification Language.
Past and Future Sampled Value Functions
Use the global clocking system functions to access past and future
shifted sampled value at the global clock tick that immediately
precedes or follows the timestep at which the function is called. They
may be used only if global clocking is defined. The following
functions are provided:
Assertions
52
Sampling Past Value Functions
Global clocking past sampled value functions report the past shifted
times. The functions are:
Global clocking past sampled value functions are:
$past_gclk(expression)
$rose_gclk(expression)
$fell_gclk(expression)
$stable_gclk(expression)
$changed_gclk(expression)
Where:
$past_gclk (expression)
Returns sampled value of expression at the previous global
clocking tick.
$rose_gclk(expression)
Returns true if the sampled value of expression changed to 1
from its sampled value at the previous global clocking tick.
Otherwise, it returns false.
$rose_gclk should read something like this: $rose_gclk is true

whenever the sampled value of b changed to 1 from its sampled
value at the previous global clocking tick.
$fell_gclk(expression)
Returns true if the sampled value of expression changed to 0
from its sampled value at the previous global clocking tick.
Otherwise, it returns false.
$stable_gclk(expression)
Returns true if the sampled value of expression did not change
at the previous global clocking tick. Otherwise, it returns false.
Assertions
53
$changed_gclk(expression)
Returns true if the sampled value of expression changed at the
previous global clocking tick. Otherwise, it returns false.
Sampling Future Value Functions

In VCS, the future value access is implemented by shifting the whole
assertion by one gclk tick into the past.
The future value functions are:
$future_gclk(expression)
$rising_gclk(expression)
$falling_gclk(expression)
$steady_gclk(expression)
$changing_gclk(expression)
Where:
$future_gclk (expression)
Returns sampled value of expression at the next global clocking
tick.
$rising_gclk(expression)
Returns true if the sampled value of expression changes to 1
from its sampled value at the next global clocking tick. Otherwise,
it returns false.
$falling_gclk(expression)
Returns true if the sampled value of expression changes to 0
from its sampled value at the next global clocking tick. Otherwise,
it returns false.
$steady_gclk(expression)
Returns true if the sampled value of expression does not
change at the next global clocking tick. Otherwise, it returns false.
Assertions
54
$changing_gclk(expression)
Returns true if the sampled value of expression changes at the
next global clocking tick. Otherwise, it returns false.
let Operator
Use of the let operator is facilitated when you use -assert

svaext.There is no need fto enter the -assert let option.
Limitations
This section describes known limitations.
Debug Support for New Constructs
Use -assert dve at compile/elab to enable debug for assertions.

While basic debug support is available with this release, assertion
tracing in DVE not supported completely. DVE provides information
such as: start_time, end_time for every attempt and statistics
for every assertion/cover. DVE also groups all signals involved in an
assertion on tracing an attempt. However the extra "hints" that are
provided for SVA 2005 constructs are not available for new
constructs as of now.
UCLI support for new assertions is not fully qualified.
Assertions
55
Note on Cross Features
Some of the features in new assertions have known limitations with

cross feature support, such as Debug, Coverage. Please check with
Synopsys support if there are unexpected results with cross feature
behavior for these new constructs.
Some known issues:
• –cm property_path is not available for most of the new

constructs
• New sequence operators when used as sampling event for
covergroups may not function well.
Assertions
56
4
Coverage Enhancements 1
This chapter provides details on the following coverage
enhancements:
• “SystemVerilog Language Enhancements” on page 64

- “Wildcard Support in binsof Expressions” on page 64
- “Wildcard Array Bins” on page 69
- “State Bin Names as States in Transition Sequences” on page
70
• “OpenVera Language Enhancement” on page 73
- “Wildcard Support in binsof Expressions” on page 73
• “Coverage Exclusion Enhancement” on page 77
- “Understanding Half-Toggle Exclusion” on page 77
63
• “Unified Coverage Reporting Enhancements” on page 79
- “Reporting Only Uncovered Objects” on page 79
- “Understanding Covergroup Page Splitting” on page 90
• “DVE Coverage Enhancements” on page 92
- “Branch Coverage and Implied Branches” on page 92
- “DVE Coverage Source / Database File Relocation” on page 92
- “Container Exclusion State Markers” on page 94
SystemVerilog Language Enhancements
Wildcard Support in binsof Expressions
You can use wildcards (x, z, ?) to specify ranges in the binsof

expression. These wildcards are an extension of SystemVerilog
syntax and are not part of the IEEE Standard for SystemVerilog—
Unified Hardware Design, Specification, and Verification Language
(IEEE Std 1800™-2005). (This document is referred to herein as the
SystemVerilog Language Reference Manual.)
SystemVerilog Syntax Extensions

The following non-standard extensions have been made to
SystemVerilog syntax:
cover_cross ::=
[ cover_point_identifier : ] cross list_of_coverpoints [ iff (
expression ) ] select_bins_or_empty
list_of_coverpoints ::= cross_item , cross_item { , cross_item
}
64
cross_item ::=
cover_point_identifier
| variable_identifier
select_bins_or_empty ::=
{ { bins_selection_or_option ; } }
| ;
bins_selection_or_option ::=
{ attribute_instance } coverage_option
| { attribute_instance } bins_selection
bins_selection ::= [ wildcard ] bins_keyword bin_identifier =
select_expression [ iff ( expression ) ]
select_expression ::=
select_condition
| ! select_condition
| select_expression && select_expression
| select_expression || select_expression
| ( select_expression )
select_condition ::= binsof ( bins_expression ) [ intersect {
open_range_list } ]
bins_expression ::=
variable_identifier
| cover_point_identifier [ . bins_identifier ]
open_range_list ::= open_value_range { , open_value_range }
open_value_range ::= value_range
Understanding Wildcard Usage

An optional keyword wildcard is included in the cross bin
definition.
The wildcard bins definition causes all x, z, and ? to be treated

as wildcards for 0 or 1 (similar to the ==? operator). You can use one
or all of x, z, and ? as wildcards, but using one wildcard consistently
helps prevent confusion.
Consider the following example:
wildcard bins g12_16 = binsof( x ) intersect { 4’b11?? };
65
Only bins of x whose associated values intersect values between 12
and 16 are included:
1100 1101 1110 1111
A wildcard bin definition only considers 2-state values; sampled

values containing x and/or z are excluded.
Thus, the range of values covered by a wildcard bin is established by

replacing every wildcard digit by 0 to compute the low bound and 1
to compute the high bound.
The following is an example of user-defined cross coverage and

select expressions.
bit [3:0] v_a, v_b;

covergroup cg @(posedge clk);
a: coverpoint v_a
{
bins a1 = { [0:3] };
bins a2 = { [4:7] };
bins a3 = { [8:11] };
bins a4 = { [12:15] };
}
b: coverpoint v_b
{
bins b1 = {0};
bins b2 = { [1:8] };
bins b3 = { [9:13] };
bins b4 = { [14:15] };
}
c : cross a, b
{
wildcard bins c1 = binsof(a) intersect {4’b11??};
// The above shows 4 cross products
wildcard bins c2 = ! binsof(b) intersect {4’b1?0?};
// The above shows 8 cross products
}
endgroup
66
The example above defines a coverage group named cg that
samples its coverage points on the positive edge of signal clk (not
shown). The coverage group includes two coverage points, one for
each of the two 4-bit variables, a and b.
Coverage point a (associated with variable v_a) defines four equal-

sized bins for each possible value of variable v_a.
Coverage point b (associated with variable v_b) defines four bins for
each possible value of variable v_b.
Cross definition c specifies the cross coverage of the two coverage

points v_a and v_b. If the cross coverage of coverage points a and
b were defined without any additional cross bins (select
expressions), then cross coverage of a and b would include 16
cross products corresponding to all combinations of bins a1 through
a4 with bins b1 through b4, that is, cross products
• a1,b1
• a1,b2
• a1,b3
• a1,b4
• ...
• a4,b1
• a4,b2
• a4,b3
• a4,b4
67
The first user-defined cross bin, c1, specifies that c1 should include
only cross products of coverage point a that intersect the value range
of 1100 to 1111. This select expression excludes bins a1, a2, and
a3. Thus, c1 will cover only four cross products of
• a4,b1
• a4,b2
• a4,b3
• a4,b4
This is similar to the behavior of following code:
bins c1 = binsof(a) intersect {[12:15]};
The second user-defined cross bin, c2, specifies that bin c2 should
include only cross products of coverage point b that do not intersect
the value range of 1000 to 1001 and 1100 to 1101. This select
expression excludes bins b2 and b3. Thus, c2 covers only four
cross products of
• a1,b1
• a1,b4
• a2,b1
• a2,b4
• a3,b1
• a3,b4
• a4,b1
• a4,b4
68
Wildcard Array Bins
Wildcard array bins are useful if you want to express array bin ranges
as wildcard patterns.
You can use any of the following symbols as a wildcard: “?”, “x”, or
“z”.
Consider the following examples:
wildcard bins b1[] = {4’b01??};

wildcard bins b2[] = {4’b100?, 4’b11?1};
wildcard bins b3[] = (4’bx1xx => 4’bxx1x);
In each of the examples above, a separate bin is created for each

value the wildcard pattern can represent.
For example, in the first example, four bins are created for each of
the following values:
• 4’b0100
• 4’b0101
• 4’b0110
• 4’b0111
You can also constrain bins in the following fashion:
wildcard bins b3[3] = (4’bx1xx => 4’bxx1x);
This syntax creates three bins by dividing the number of total

possible transitions into three bins and putting the remaining
transition in the last bin.
69
The syntax example above has a total of 64 transitions. The first and
second bins contain 64/3 = 21 transitions, and the third bin contains
21 + 1 = 22 transitions.
State Bin Names as States in Transition Sequences
The syntax for specifying transition bins has been extended to allow
state bin names to be used as individual states of a transition
sequence.
Note:
These extensions are allowed for both SystemVerilog and
OpenVera testbenches. However, the SV extensions are not
compliant with the standard SystemVerilog Language Reference
Manual.
With this new syntax, the hit count for the transition bin is
incremented only if the hit counts of the state bins in the sequences
were incremented in the prior occurences of the sampling event.
Revised SystemVerilog Syntax for Transition Bin

Specifications
This section outlines the extension to SystemVerilog syntax that
implement this feature.
The syntax for specifying bins for transitions appears in the

SystemVerilog Language Reference Manual, section 18.4.1,
illustration “Syntax 18-3’:
trans_list ::= (trans_set) {, (trans_set)}

trans_set ::= trans_range_list {=> trans_range_list}
| state_bin_name {=> state_bin_name}
state_bin_name ::= identifier
70
state_bin_name
Represents a state bin.
The following example illustrates the use of thes state bin name
syntax:
int cp ;
covergroup gc @ (posedge clk);
coverpoint cp {
bins s0 = {[0:7]} iff (x > 0);
bins s1 = {[16:20]} iff (y < 3);
bins newt1 = (s0=>s1);
}
endgroup
Revised OpenVera Syntax for Transition Bin

Specifications
This section outlines the changes in OpenVera syntax that
implement this feature.
trans trans_bin_name(state_bin_name
[repeated_transition_values] -> state_bin_name
[repeated_transition_values] -> …) [conditional];
trans_bin_name
Represents the name of the transition bin.
state_bin_name
Represents the name of a state bin defined in the same sample
construct. This name must be a user-defined state bin name. It
cannot be the name of bad_state bin, m_state bin,
m_bad_state bin or “all” state bin.
71
repeated_transition_values (optional)
Specifies the number of times a particular value is to be repeated
in a transition sequence. Use the following constructs:
[*constant] | [*min_constant:max_constant]
The constant construct must represent an unsigned integer

constant. The state preceding the constant must be repeated
a fixed number of times.
The min_constant:max_constant construct must

represent unsigned integer constants. The state preceding the
constants must be repeated at least min_constant times and
not more than max_constant times.
The following example illustrates the use of the state bin name
syntax:
coverage_group COV1
{
sample x {
state s1(1);
state s2(2);
trans t0sbn(s1->s2);
}
sample_event = wait_var(x) async;
}
There is no dependency on the order of specification of state bins

and transition bins where the state bin names are used. State bin
names can be specified after their names are used in a transition bin
specification.
72
OpenVera Language Enhancement
Wildcard Support in binsof Expressions
You can use wildcards (x and z) to specify ranges in the binsof

expression. These wildcards are an extension of OpenVera syntax
and are not part of the OpenVera Language Reference Manual:
Native Testbench.
Extensions to OpenVera Syntax
The following extensions have been made to the OpenVera® syntax:
cross cross_name (coverage_point, coverage _point,

[,coverage_point_name])
{
[cross_bin_definitions]
[attribute_definitions]
}
An optional keyword wildcard is included in the cross bin

definition.
The cross_bin_definition defines a cross coverage bin that

combines several cross products into a single named bin or
equivalence class, using the following syntax:
[wildcard] state state_name

((select_expression)[logical_operator
(select_expression)]) [ if (expression) ];
The following definitions apply to the preceding syntax:
wildcard
73
Treats the x or z values as wildcards in the state declarations.
state
Can be state, ignored, or bad_state.
state_name
Represents a user-specified name for the cross bin.
select_expression
Represents a subset of bins_expression. See the OpenVera
Language Reference Manual: Native Testbench for details on
bins_expression.
logical_operator
Represents && or ||.
Understanding Wildcard Usage

By default, a bit with a value of x must match a sampled value of x
for a cross bin counter to be incremented. The wildcard keyword
treats the x value as a wildcard in the state declarations:
Note:
Here wildcard essentially means either 1 or 0 at the specified
location.
The following code provides an example wildcard usage.
coverage_group cg {
sample_event = @(posedge CLOCK);
sample v_a {
state a1 (0:3);
state a2 (4:7);
74
state a3 (8:11);
state a4 (12:15);
}
sample v_b {
state b1 (0);
state b2 (1:8);
state b3 (9:13);
state b4 (14:15);
}
cross c (v_a, v_b) {
wildcard state c1 (binsof(v_a) intersect {4'b11zx});
wildcard state c2 (!binsof(v_b) intersect {4'b1x0x});
}
}
The example above defines a coverage group named cg that

samples its coverage points on the positive edge of signal clk (not
shown). The coverage group includes two samples, one for each of
the two 4-bit variables v_a and v_b.
Sample v_a defines four equal-sized bins for each possible value of
variable v_a.
Sample v_b defines four bins for each possible value of variable
v_b.
Cross definition c specifies the cross coverage of the two samples

v and v_b. If the cross coverage of samples v_a and v_b were
defined without any additional cross bins (select expressions), then
cross coverage of v_a and v_b would include 16 cross products
corresponding to all combinations of bins a1 through a4 with bins b1
through b4, that is, cross products
• a1,b1
• a1,b2
75
• a1,b3
• a1,b4
• ...
• a4, b1
• a4,b2
• a4,b3
• a4,b4
The first user-defined cross bin, c1, specifies that c1 should include
only cross products of sample v_a that intersect the value range of
1100 to 1111. This select expression excludes bins a1, a2, and a3.
Thus, c1 will cover only four cross products of
• a4,b1
• a4,b2
• a4,b3
• a4,b4
This is similar to the behavior of the following code:
state c1 (binsof(a) intersect {[12:15]});
The second user-defined cross bin, c2, specifies that bin c2 should
include only cross products of samples v_b that do not intersect the
value range of 1000 to 1001 and 1100 to 1101. This select
expression excludes bins b2 and b3. Thus, c2 covers only four
cross products of
• a1,b1
76
• a1,b4
• a2,b1
• a2,b4
• a3,b1
• a3,b4
• a4,b1
• a4,b4
Coverage Exclusion Enhancement
Understanding Half-Toggle Exclusion
Toggle coverage monitors each net and register for any value
transition from 0 to 1 and 1 to 0. Such monitoring provides an
indication of the amount of activity on each element.
Without half-toggle exclusion, when you exclude an element from

toggle coverage, VCS and VCS MX exclude both transitions, even if
one of the transitions is covered. This can have an impact on the
overall toggle coverage score. Consider the following example:
reg [1:0] p;
p = 2’b10;
#1 p = 2’b01;
In this simulation, p[0] has a 0-to-1 transition and p[1] has a 1-to-
0 transition. Full-toggle exclusion for a signal p[1] gives a coverage
toggle report of 50%, which can be broken down as follows:
77
p[0] 0->1 Covered
p[0] 1->0 Not covered
p[1] 0->1 Excluded (not counted)
Half-toggle exclusion gives you better control of the granularity of the

transitions to be ignored. In this example, you can exclude the p[1]
0->1 transition and still cover the p[1] 1->0 transition. The overall
coverage score becomes 66.67% (2/3), as shown below:
p[0] 0->1 Covered

p[0] 1->0 Not covered
p[1] 1->0 Covered
This is the BNF syntax for the half-toggle exclusion functionality:
toggle_spec : mod_or_inst : mod_or_inst_name {toggle_data}

mod_or_inst : MODULE | INSTANCE
toggle_data : Toggle {direction} {signal_spec}
direction: 0to1 | 1to0 | NULL
signal_spec : name [index]
index: ID r_id
r_id: COLON ID | NULL
This is an example of exclusion for toggle coverage:
INSTANCE: top
Toggle y[0]
Toggle 1to0 x [0]
Toggle res[3]
Toggle res[4]
Toggle res[5]
In the above example, full-toggle exclusion is active for y[0],

res[3], res[4], and res[5]. Half-toggle exclusion is active for
x[0].
78
Unified Coverage Reporting Enhancements
Reporting Only Uncovered Objects
This section describes how URG allows you to create reports only for
uncovered objects (instead of creating reports for all coverable
objects).
Command-Line Access
URG supports a command-line option that causes only uncovered
objects to be shown in the report:
% urg –show brief
You can use this option in combination with text mode to generate a
brief text report:
% urg –show text –format brief
Report Changes
This section describes how each report section changes when you
use the -show brief option.
Dashboard
The dashboard report does not change. The total coverage
summary for the design is still shown, as well as the summary for
each top-level instance.
79
Module List
Only modules with an overall coverage score less than 100% are
shown. Modules with no coverable objects in them (for any reported
metric) are not listed.
For example, assume the module list report looks like this:
In brief mode the module list report would only show the following
modules:
Hierarchy
The hierarchy report omits any instances that have no coverable
objects in their subtree or whose entire subtree has a score of 100%
(for all reported metrics). URG does not produce a comment or other
indication that such an instance has been omitted.
80
In other words, the only parts of the hierarchy that will be deleted
from the report are those entire subtrees that have coverage scores
of 100%, or that have no coverable objects in them at all.
Assume the full report looks like this:
In brief mode, the report would show only the following modules:
Note that HNUCKIDVOXUSFT_0 is omitted because it has no

coverable objects, and the subtree rooted at HNPSIDEDJI_0 is
omitted because it has 100% coverage.
81
Groups
The groups report omits any groups that have a 100% score.
Tests
The tests report does not change.
HVP
The HVP format omits any features whose subtrees are either 100%
covered or which have no coverable measures in them. Like the
hierarchy, only entire subtrees are omitted (if any).
Assertions Report
URG lists in any of the tables only assertions that are not covered or
that failed. Only covers and assertions that are not covered are
listed.
The total number of assertions is still reported the same way in

asserts.html.
Module and Instance Header Sections

In brief mode, URG generates module, instance, and group
reports only for those regions that have coverage scores less than
100%.
Module Header
URG lists the same header for modules, including all self-
instances—even those self-instances that have 100% coverage.
However, the self-instances with 100% coverage do not link to any
82
report because their reports are not generated. URG shows all self-
instances because you can see how URG computed the scores for
the module.
If a module is hidden from the module list page, but its instances are
reported, the module header still appears at the top of the module
page because the module header contains useful information for the
whole page.
Instance Header
URG shows the same instance header, including a list of all
subtrees.
Detailed Coverage Reports

URG shows detailed coverage reports only for regions that do not
have 100% coverage. Within each region, URG shows the detailed
report for a given metric only if that metric does not have 100%
coverage in that region.
For example, if a module has 100% line coverage and 50% condition
coverage, URG generates a detailed report for condition coverage
but no detailed report for line coverage. Note also that the condition
coverage report only shows uncovered objects.
83
URG shows the entire summary table for a metric it reports. For
example, the following summary table for toggle coverage would not
omit the “1 -> 0” rows even though they are all at 100%:
However, if the module had 100% toggle coverage in all rows, URG
would not provide either this table or any toggle coverage details.
Line Coverage
For line coverage reports (which provide annotated source code that
shows coverable objects and which objects are not covered), URG
shows only the lines that contain uncovered statements (“uncovered
lines”), along with two lines of context before and after each
uncovered line.
Showing some context is important because the coverage database

does not know the extent of a statement—a statement could cross
over several lines, in which case the statement would be truncated.
URG provides two lines of context above and below a statement:
84
if (some condition)
if (some other condition)
a <= (b ? c :
( d ? e :
( f ? g :
( h ? i :
( j ? k : l )))));
If the statement is uncovered, URG shows only this information:
if (some condition)
a <= (b ? c :
( d ? e :
( f ? g :
If several uncovered lines are grouped together, they are all grouped
together in the report. For example:
if (some condition)
begin
begin
a <= b;
if (yet another condition)
begin
x <= y;
end
end
end
The report for the above example would show the following text,
rather than reporting the information in two separate sections:

begin
a <= b;
if (yet another condition)
begin
85
x <= y;
end
end
Condition Coverage
If a condition and all of its subconditions are completely covered (all
vectors), then URG omits the report for it and its subconditions.
If a condition is not fully covered, then URG shows the condition’s

complete report (all vectors). If a condition is fully covered but one of
its subconditions is not, URG still shows the complete report for that
condition (and the not-fully-covered subcondition).
86
For example, consider the following report:
87
The brief report would appear as follows:
Note that URG shows the first condition because its subcondition
(the second) is not fully covered. The condition at line 505 is omitted
in the brief report because the condition was fully covered, with no
(uncovered) subconditions.
The brief report shows both the condition on line 510 and its
subcondition—even though the condition itself is fully covered—
because one vector of the subcondition is not covered.
88
Toggle Coverage
In the detailed table, URG lists only signals that are not fully covered.
For example, consider the following full report:
The brief report shows only these items:
89
FSM Coverage
URG omits from the report any FSMs that are fully covered (all states
and transitions). However, these FSMs are shown in the FSM
summary table—with only the FSM name and its score.
If an FSM is fully covered except for its sequences, URG omits the
FSM it will be omitted (even if the sequence score is less than 100).
If an FSM is not fully covered, URG lists all of the FSM’s states, and
only its uncovered transitions and sequences.
Assertion Coverage
URG list only assertions that have failed or are not covered. Only
uncovered “covers” are listed.
Group Report
Inside a group report, URG lists only bins that are not covered.
Understanding Covergroup Page Splitting
The HTML version of the detailed covergroup report can become

quite large, which can cause difficulties when you load and view this
report.
Important:
The page-splitting functionality applies only to HTML reports,
not text reports.
Note the following page-splitting guidelines for covergroup reports:
90
• Instance splitting: URG splitting behavior for covergroup
instances resembles code coverage splitting for module
instances. When URG generates a report for any group instance,
URG checks the size of the current page and creates a new page
if the report exceeds the value you defined with -split N.
URG never splits a group report.
• Bin table splitting: If the bin table is so large that the previous
splitting strategy is not enough to make the page fit in the page
size limit, URG splits the bin table across several pages. In this
situation, the covergroup page displays a note alerting you to the
multiple-page splitting that URG has performed. The covergroup
page also contains links to the various pages.
Each page that is split contains a summary table of coverage
information.
The following examples show how a report for a hypothetical

covergroup a is split:
Page for covergroup a, before splitting:

Group a
Group instance a1
Group instance a2
Group instance a3
Group instance a4
Pages for covergroup a, after splitting:
Page for covergroup a:
Group a
Group instance a1
91
Subpage 1:
Group instance a2
Group instance a3
Subpage 2:
Group instance a4
DVE Coverage Enhancements
Branch Coverage and Implied Branches
The DVE Coverage GUI shows implied branches in the source

window (when you use dve -cov) only when you view branch
coverage or are analyzing the branch metric. The implied branches
of case and if statements are indicated by MISSING_ELSE and
MISSING_DEFAULT tags. You can exclude any branches tagged in
this fashion.
DVE Coverage Source / Database File Relocation
DVE normally determines the location of a coverage database,

source directory, or source file by using information built into the
coverage database at compilation and runtime. (In this discussion,
the word "file" includes any of the preceding three items.)
However, if you change the location of a coverage file, and then

attempt to load that file with DVE, DVE displays a dialog asking you
to provide the new location of the file.
92
After you provide DVE with the new location of the file, DVE
subsequently uses both the built-in location and the new location
information you have provided.
Moreover, DVE compares the two locations to make a more

intelligent attempt at locating the file.
For example, assume that the location of a file foo.v (as specified
in the coverage database) is as follows:
/A/B/C/foo.v
But assume that you moved the file to this location, which you
provided to DVE:
/X/Y/C/foo.v
Thereafter, DVE compares these two locations and, working from

right to left, determines that the following location is the new root
directory for design files is as follows:
/X/Y
Assume now that DVE performs a search for the following file, based
on database information:
/A/B/E/bar.v
Instead of looking in /A/B, DVE searches in /X/Y, the correct

location of this file:
/X/Y/E/bar.v
If DVE cannot find the file using the default location, then DVE
displays a dialog asking for the correct location of the file.
93
DVE can only remember one root location directory at a time. DVE
replaces any earlier root location directory with whichever new
location you specify.
Container Exclusion State Markers
The following DVE exclusion markers indicate the exclusion state of

items within a container, without the need to open the container to
inspect the exclusion state of the individual items in the container.
A container is a structural element that contains other data, for

example, a module or entity.
Note:
In this discussion of “Attempted” state markers, be aware that
DVE displays the “Attempted” state marker only in strict mode,
that is, when you use the -excl_strict switch. When DVE
marks a container as “Attempted” in strict mode, this means that
the item was already covered and cannot be excluded.
• Partially Excluded—When some, but not all, of the items in a

container are excluded, the container is marked with the “Partially
Excluded” state marker:
The following illustration shows how the Partially Excluded marker

appears in the DVE GUI in relation to the container:
Partially Excluded
state marker
94
• Partially Excluded and Attempted—When some of the items in a
container are excluded, and some have been marked as
attempted, the container is marked with the “Partially Excluded”
and “Attempted” state markers:
The following illustration shows how the Partially Excluded and

Attempted state markers appear in the DVE GUI in relation to the
container and its contents:
Partially Excluded
marker
Attempted state marker
• Attempted—When DVE has attempted to exclude some or all

covered items in a container, the container is marked with the
“Attempted” state marker:
95
The following illustration shows how the Attempted state marker
appears in the DVE GUI in relation to the container:
Attempted state marker
The Source window also displays container exclusion information:
Partially Excluded and

Attempted state markers
96
5
Coverage Convergence Technology 1
This document describes the coverage convergence technology.
You need a special license for both compile-time and runtime usage.
This chapter describes all coverage-convergence-specific options.
This chapter also includes coding guidelines that allow you to get the
most out of the coverage convergence technology. Some common
user flows are also provided.
Compile-Time Options
This section describes the options you use to enable the coverage
convergence technology when using the VCS compiler. Note that
using these options does not guarantee that coverage convergence
will occur. For coverage convergence to occur, the constraints and
coverage model need to meet certain requirements.
Coverage Convergence Technology

89
You also need to specify the options described in this chapter (as
appropriate) when you execute simulation (that is, when you run
simv).
Coverage Convergence Option
-ntb_opts cct
Ensures that the required coverage-convergence-related
processing is done for all relevant coverage points.
Example for OpenVera testbench:
vcs -ntb -ntb_opts cct foo.vr
Example for SystemVerilog testbench:
vcs -sverilog -ntb_opts cct foo.sv
Coverage Model Autogeneration Options
-ntb_opts cct_cov_gen
Generates a coverage model for a stimulus object—that is, for a
class that contains random variables and/or constraints.
See “Automatic Generation a Coverage Model from Constraints”

on page 96 for details on how a coverage model is inferred from
constraints.
When you specify this option, coverage convergence writes

automatically inferred cover groups (if any) to the directory
${SIMV_DIR}/cct_cov_gen. You can specify a different
directory with the -ntb_opts cct_cov_gen_dir option.

90
Note that if the cct_cov_gen directory already exists, any files
in that directory will be clobbered when you rerun coverage
convergence with the -ntb_opts cct_cov_gen option.
The names of the files created (and the names of the coverage
groups themselves) depend on the names of the classes and
constraints blocks in the source file.
Example for OpenVera testbench:
vcs -ntb -ntb_opts cct_cov_gen foo.vr
Example for SystemVerilog testbench:
vcs -sverilog -ntb_opts cct_cov_gen foo.sv
-ntb_opts cct_cov_gen_dir <directory_name>

Overrides the default directory (./cct_cov_gen) into which
coverage convergence writes automatically inferred covergroups.
Example:
vcs -ntb -ntb_opts cct_cov_gen -ntb_opts cct_cov_gen_dir

./my_dir foo.vr
Coverage Convergence Runtime Options
To enable the coverage convergence functionality, specify the

following command-line options when executing the simv generated
by VCS.
-cct_enable
Enables coverage convergence at runtime.

91
The -cct_enable option is required for running coverage
convergence. The following arguments are optional.
-cct_enable=on_start
Tells coverage convergence to target coverage holes from the
very first call to randomize. By default, the targeting of holes does
not start until coverage convergence determines that merely
running pure random stimulus (based on constraints) is no longer
resulting in increasing coverage.
You can use this option when few randomize calls occurring in
the test so each randomize call can be coverage-aware. This
option is also enabled automatically when you use bias file
options.
-cct_bias_file=<file_name>
Specifies the bias file to be used for the test run. The bias file
specifies the coverage holes that the test should target in the
current run. Different runs of the test can use different bias files
as input. Although it is possible to create a bias file manually, we
recommend that you generate the bias file using the URG utility.
See “URG Options for Bias File Generation ” on page 93 for more
details.
For the bias file to have any effect, you must enable other options
(such as -cct_enable). When you specify the
-cct_bias_file option, the -cct_enable=on_start option
is automatically enabled.

92
URG Options for Bias File Generation
This section describes the URG options related to coverage

convergence. These options generate bias files. You use the bias
files to bias coverage convergence to target specific coverage holes.
The URG options described in this section are in addition to other
required URG options, such as -dir and -format.
-group cct_gen_bias <non-zero integer>

Instructs URG to partition all the coverage holes in the input
database into the specified number of bias files.
Coverage convergence writes the bias files to the

./biasConfigs directory. The bias files are text files that
represent coverage holes. Avoid editing the bias files by hand.
However, if you choose to edit the bias files, do not deviate from
the bias file format. You can use each bias file generated with the
cct_gen_bias option as an input to a test run.
See “Understanding Bias Files and Coverage Convergence” on

page 106 for more details.
-group cct_gen_bias_dir ./<my_dir>

Overrides the default directory setting that determines where the
bias files are written. By default, the bias files are written into the
./biasConfigs directory. Coverage convergence creates the
directory if the directory does not exist.

93
Coding Guidelines
The following sections provide coding guidelines for using coverage

convergence.
Constraints and Coverage Model on the Same Variables
Coverage convergence works when the coverage model is on the

stimulus variables. In other words, the cover points (and cover point
expressions) should be the rand variables that represent the
stimulus. Constraints and the coverage model should be in the same
class. Further, the randomize and coverage sampling should happen
on the same instance of the generator class.
No Procedural Overwriting of Values Generated by the

Solver
Coverage convergence works by generating constraints for all the

coverage holes and by enabling these “coverage constraints” during
consecutive calls to randomize. If there is procedural code (in
post_randomize for example) which overwrites the values
generated by the solver, then it is possible that coverage bins might
not be hit, even though the solver is generating the right values for
the random variables.

94
Coverage Should Be Sampled Between Consecutive
Calls to randomize
The sampling event for the coverage model should be triggered

between consecutive calls to randomize, to ensure that all
generated values are sampled. An alternative is to use the
@randomize sample event. Using this sample event ensures that
the cover points are sampled as soon as randomization is
completed.
Use Open Constraints
In an ideal scenario, you should specify only the legal (or

environment) constraints when running coverage convergence. Do
not use test constraints. Test constraints further constrain the legal
environment to focus the solver on a specific part of the legal space.
With coverage convergence enabled, the solver is automatically
focussed on the portion of the legal space that is covered by the
coverage model.
If you want to focus the solver in coverage convergence mode, then

load a preexisting coverage database before starting the stimulus
generation. Coverage convergence will not target anything that is
covered in the loaded database.

95
Avoid Explicit or Implicit Partitioning in Constraints
Coverage convergence might not work efficiently when there are

explicit or implicit partitions in the constraint problems. Explicit
partitioning is enabled by using “solve before” constructs. Implicit
partitioning is enabled when there are function calls in constraints or
when object allocation is enabled.
If partitioning does happen and coverage convergence is enabled,

then partitioning might lead to some loss of efficiency for coverage
convergence: some coverage bins might be targeted but not
covered.
Avoid In-line Constraints and the Use of

“constraint_mode” and “rand_mode”
Coverage convergence is designed to work on the static structure of

the constraints and coverage. If the structure of the constraints is
changed using in-line constraints or turning constraints or randness
off and on using “constraint_mode” and “rand_mode”, then the
performance of coverage convergence might be compromised.
Automatic Generation a Coverage Model from

Constraints
One of the goals of coverage convergence is to extract a functional

coverage model from the constraint expressions, and automatically
cover it. The intuition is that a better sampling of the stimulus space
will exercise the design behaviors more exhaustively, increasing the
likelihood of hitting coverage goals.

96
The plan is to provide a first-class “contract” to the user which
specifies how the coverage model is inferred and how goals are
named.
Coverage Groups
A cover group will be generated for each class by default.
A cover group will be generated for each class to contain the

coverage model derived from variable declarations in the class. The
cover group for the class that will contain the coverage model for
variables will be called covg_<class_name>.
The members of the cover group (cover points, crosses) will be

annotated with comment attributes in a manner that will allow
tracking back to the original constraint expressions. The following
sections detail the types of cover points and crosses that will be
inferred.
The cover groups will contain items as described below.
Cover Points
Variable Coverage
Each rand variable will have a cover point associated with it, except
for variables that have an unguarded set membership constraint at
the top-level, in any of the constraint blocks of the class. For
example:
enum PktType = {Type1, Type2};

rand bit[7:0] x;
rand PktType p;
PktType prevp;

97
constraint c1 {
x in {0:1, 5};
}
Here, a cover point will be inferred for p, but not for x or prevp. Note
that a set membership cover point will be inferred for x.
The cover point expression will be just the variable. The following
rules apply to the creation of bins:
• Autobinning for enum type variables.

• Equal volume autobinning, with a maximum of 64 bins, for
variables with precision 8 bits or less.
For example:
rand bit[7:0] x;
rand PktType p;
rand bit[31:0] y;
In the above example, autobinned cover points will be created for x

and p, with the bins for x having the ranges 0–3, 4–7, ... , 252–255,
and the bins for p having the values Type1 and Type2.
The built-in function rand_mode can be used to turn off the

randomness of a rand variable. But the collection of coverage for
such variables will continue irrespective of the mode change.
The cover points for variables will be called

covp_<cover_point_id>. <cover_point_id> is a unique
integer identifier for every cover point. The autobins for the cover
points will be named by the usual naming convention for autobins.
The comment for the cover point will indicate details about the
variable.

98
Branch Coverage
Each conditional block will have an associated Boolean cover point.
The cover point expression will be the conjunction of all the
enclosing conditional guards. For example:
if (p) {
if (q) {
x == y;
}
}
In the above example, there will be a coverpoint with the expression

p&&q.
The comment for the cover point will have the expression string.
Condition Coverage (Sensitized)

Each sensitizing guard condition will have a Boolean cover bin
associated with it. For example:
if (p || (q && r)) {
...
}
In the above example, there will be a cover point with expressions p

|| (q && r) with one bin corresponding to the case when
expression p is ON (or true) and one bin corresponding to the case
when expression q&&r is true. The idea is to make sure that the
conditional expression becomes true at least once for every
implicant in the expression being true.
The cover points will be guarded by the conjunction of all the

enclosing conditional guards.

99
Note:
The subexpressions of the guard expression involving operators
other than &&, ||, ! are considered as atomic, and the sensitizing
conditions are defined over these atomic subexpressions.
When the condition expression is a set expression, the condition
coverage model will be generated like the set membership coverage
model. For example:
if (p in {0:4, 7}) {
...
}
Here the cover point expression will be p, and the bins 0, 1–3, 4, 7
will be created.
The comment for the cover point will have the expression string.
Set Membership Coverage

We will infer a cover point for constraints coded using the in and
dist operations. Equivalent ways of writing the same constraints
using other operators might not result in an inferred coverage model.
For example:
x in {0:5};
results in an inferred cover point, whereas
x >= 0 && x <= 5;
does not result in an inferred cover point. Also, use of set

membership in complex constraints does not result in an inferred
cover point.
For membership in sets with constant members:

100
• A single cover point will be created. The sample expression will
be the same as the LHS
• value in the set membership constraint.
• A bin will be created for the low value of each range.
• A bin will be created for the high value of each range, for non-
singleton ranges.
• A bin will be created for the range excluding the low and high
values of each range, if the resulting range is non-empty.
For example:
x in {0:5, 7};
In the above example, a cover point with expression x and four bins,
0, 1–4, 5, 7 will be created.
The functional coverage language does not allow dynamic variables

(those that are not parameters to the coverage groups) to describe
bin ranges. Hence, for membership in sets with nonconstant
members:
• A cover point with three Boolean cover bins will be created for
each of the ranges as follows:
- A bin with the expression (range_low_expression).
- A bin with the expression (range_low_expression + 1 :
range_high_expression -1).
- A bin with the expression (range_high_expression).
For example:
x in {a:5, b};

101
In the above example, a cover point will be created for variable x with
the following bins:
• One bin with value a;

• One bin with value range (a+1:4);
• One bin with value 5;
• One bin with value b;
Note:
If the set membership range expressions use random variables,
then no coverage bin will be inferred for that range. For example,
if a in the above example were specified as rand, then the first
two bins would not be inferred.
Note:
All the cover points above will be guarded by the conjunction of
all the enclosing conditional guards.
Crosses
Combinations of control variables in the class, will be used to
generate crosses.
We will define control variables as variables that are of enumerated

types or bit-vectors that are 8 bits wide or less, for which a variable
coverage cover point is generated.
Cross on Variables Within a Class

If a class contains control variables x, y, then a cross x, y will be
generated. The cross will be autobinned. The cover points and bins
for x, y will be as described in the section on variable coverage.

102
The set of variables that participate in one cross is determined as
follows:
Control variables will be added to a cross until the total number of

expected bins (product of underlying cover point bins) of the cross
does not exceed 64000.
If more control variables still remain after previous step, then a new
cross will be created.
The crosses will be called covc_<cross_id>. <cross_id> is a

unique integer identifier for the cross. The comment for the cross will
indicate details about the crossed variables (class name, file, line,
etc.).
Cross of Condition and Constraint Expressions

The sections on condition coverage and set membership described
two kinds of cover points. In the case of set membership constraints
inside conditionals, we will generate a cross of the cover points for
coverage of the condition (sensitizing). This cross will be autobinned.
For example:
if (p || (q && r)) {
x in {0:5, 7};
}
In the above example, cover points for x will be generated from the
set membership constraint. Cover points for the condition expression
will be generated. A cross for the two cover points will be generated.
Sampling Event
A special built-in sample event called @(randomize) will be used
to determine the sampling for the generated coverage groups.

103
This event can be used in user defined cover groups that are
embedded in classes. The event istriggered when an instance of this
class is randomized, either directly or through containment inan
instance of another class being randomized. When the event is
triggered, coverage is tracked for the instance and/or the cover
group definition (that is, cumulative).
The @(randomize) event is triggered on all rand objects in the

context being randomized, after the solver is done, and values have
been populated in the objects. If objects are being allocated by
randomize, then the allocation of the objects is done before the
values are populated back, hence before @(randomize) is
triggered.
Contribution to Coverage Scoring
The automatically generated coverage model will contribute to the

coverage score by default with a weight of 1.0.
Coverage Model Inference for In-line Constraints
Since in-line constraints (randomize with {..}) is

recommended for use in the specification of test constraints, we will
not infer a coverage model from such constraints. In fact, we expect
the use of test constraints to be minimized after coverage driven
stimulus generation is implemented.

104
Use Model
Autogeneration of coverage model is done as part of the VCS

compile step. The switch to enable coverage model generation is
-ntb_opts cct_cov_gen. All the coverage models will be written
out as text files in the cct_cov_gen directory. The cct_cov_gen
directory will be present wherever the simv.daidir and simv files
are generated by VCS compiler. Both System Verilog and OpenVera
testbench formats are supported. The language in which the
coverage model will be generated is the same as the syntax of the
testbench.
Example command line for an OpenVera testbench:
Example command line for a SystemVerilog testbench.
vcs -sverilog -ntb_opts cct_cov_gen foo.sv
It is expected that the user will first create a coverage model using
the auto_gen option. Then the user will include the coverage model
into their testbench (using ìnclude or #include directives) and
then make sure the coverage model is instantiated in the new task
for the enclosing class (that is, the class where the constraints and
random variables are specified). The user is encouraged to view the
autogenerated coverage model and make changes if required.
The VCS compiler does not compile the design when cct_cov_gen
is specified (that is, no simv is created).

105
Understanding Bias Files and Coverage Convergence
Motivation
Coverage convergence is a new technology that enables coverage

convergence for testbench functional coverage, that is, cover
groups. Coverage convergence seeks to automatically target
coverage holes by identifying the coverage holes and directing the
constraints solver to generate stimulus such that the coverage holes
will be hit. Coverage convergence works at a test level, that is,
coverage convergence tries to hit coverage holes within a test. In
most customer environments, verification tests are run on a
regression farm, where multiple copies of the tests are being
executed in parallel on different machines in the farm, with each
simulation being assigned a different random seed. It is desirable
that with coverage convergence enabled, each test be able to target
different portions of the coverage space in order to meet the
coverage goals in the shortest possible clock time.
What Is a “Test”?
A test for the purpose of this document is an executable that can be

simulated (for example, simv generated by VCS). The source files
(testbench files, design files etc.) are compiled by VCS compiler and
linked with the simulation engine to create the executable. The
executable can then be invoked multiple times with different runtime
options, such as different random seeds or configuration files and
the simulation results can be observed. Note that the executable is
created once, that is, the source files (constraint, coverage models,

106
transactors, modules etc.) do not change with every execution. The
different options passed with every execution lead to different
behavior of the simulation.
From the coverage convergence point of view, a “test” should consist

of a testbench with an “open” set of constraints: the constraints
should represent the entire legal stimulus space. Note that in many
existing methodologies, the constraints in a “test” consist of the legal
constraints as well as a set of test constraints that limit the solution
space of the legal stimulus. This is typically done to focus the test
towards some verification targets such as coverage or specific
features.
The bias file approach described below works best with tests using
an open set of constraints and a full coverage model. Thus any
invocation of the simulation executable can target any of the existing
valid coverage holes.
Using Coverage Convergence Bias File to Pick Target

Coverage Holes
The user can influence the coverage holes being targeted by

coverage convergence in a test run is by using a coverage
convergence bias file. This is a file that contains a list of coverage
holes which the coverage convergence engine will target when the
test starts running. The coverage convergence bias file format is a
text file representing coverage holes. This file can be modified by the
user if needed.

107
Runtime Option to Specify a Bias File
The coverage convergence bias file will be passed in as a runtime
argument for the test run, using
-cct_bias_file=<path_to_cct_bias_file>. When the test
starts executing, the coverage convergence engine will read the bias
file and populate its in-memory coverage hole database with the data
from the coverage convergence bias file. Then it will systematically
start targeting the holes. After all the holes are targeted, if more
randomize calls occur, then they will not be reactive, that is, no
coverage hole will be targeted.
• The holes in the coverage convergence bias file are all at a

coverage group definition level. They will apply to all instances of
the coverage group in the test, for which reactivity can be applied
and can be enabled.
• Only the coverage holes present in the bias file will be targeted.
• The bias file will be read and processed by the coverage
convergence runtime engine. The test does not need to be
recompiled if the bias file is changed or a new bias file is to be
used for the test.
• The bias file has no impact on the coverage engine and on
coverage reporting. It will only influence coverage convergence.
If the data in the bias file is for a coverage group which cannot be
targeted by coverage convergence, then all the data for that
coverage group is ignored by the coverage convergence engine.
• If the coverage convergence bias file as pointed to by the
-cct_bias_file option cannot be read, then an error will be
issued the file will be ignored. The test will run as though no bias
file has been specified.

108
• There are no restrictions on the name of the coverage
convergence bias file.
• The bias file will provide a guideline as to what coverage bins are
targeted by coverage convergence, but coverage convergence
can choose to override these guidelines in certain situations. For
example, coverage convergence will not target coverage bins that
have been assigned a zero weight by the user or coverage bins
belonging to disabled by the user using the collect attribute or by
using coverage_control system task.
Automatic Generation of Coverage Convergence Bias

Files
URG automatically generates coverage convergence bias files for a

particular test. URG can be invoked on a coverage database file and
will generate N bias files, where N is supplied by the user. The utility
can be invoked as follows:
$VCS_HOME/bin/urg –dir <coverage_db_dir> -group

cct_gen_bias <number_of_bias_files_required>
The utility will enumerate all the coverage bins in the input database
files and will create N random partitions of the holes where N is
supplied by the users using the num_bias_files argument. It is an
error if N is greater than the number of coverage bins in the coverage
database. The bias files will be written out in the ${PWD}/
cctBiasConfigs directory as config0, config1, config(N-1).
Other URG options (such as –format) can also be used
simultaneously to process the coverage data. Since the coverage
convergence bias file represents coverage bins at a coverage group
definition level, it will be assumed that there is only one shape for

109
every coverage definition in the input coverage database. If multiple
coverage definitions are detected, then an error will be issued and
not bias files will be generated.
The bias files generated by URG can then be used as input to tests
being run in parallel.
Repeatability of Test Results for Parallel Regression

Runs
An essential requirement for the approach outlined above is that it

should be possible to reproduce the results of a test run in a parallel
regression environment in a stand alone manner. More specifically,
if a test fails in the parallel regression run, it should fail in exactly the
same manner when run on its own. Coverage convergence ensures
that given the same inputs and the same command line arguments,
the sequence of values generated by the solver will be exactly the
same. Here the inputs are the bias file and the test source code, and
the arguments are the random seed and the -cct_bias_file
argument. Note that this means that the regression system needs to
preserve the bias file used by a test in addition to other test source
code and scripts.
Usage Scenarios
This section discusses coverage convergence usage in various

common verification scenarios. In all the scenarios in this section, it
is assumed that the guidelines mentioned in the previous section are
being followed (for example, coverage and constraints are on the
same variables, and so on).

110
You can load a preexisting coverage database in every scenario to
screen out already-covered coverage bins. By doing so, the current
run can focus only on uncovered bins. The coverage database must
be loaded after all the testbench components have been
instantiated, so that the coverage data from the database can be
loaded in the proper (in-memory) runtime database.
Running a Single Test with Randomized Configurations
This scenario generally applies to multimedia devices, in which the

device has many interfaces and many modes and the device can be
configured to select some interfaces and some modes.
The object of verification is to exercise all the interesting

configurations of the device. In the testbench, configurations are
selected, and then data (possibly random) is passed through the
device.
Configurations for a device are typically chosen (through

randomize) a few times per test run. In the extreme case, only one
configuration might be selected (for example, config.randomize
is performed only once).
In this scenario it is important to preload the coverage database to

ensure that already-selected configurations are not chosen.
Running a Single Test with Randomized Transactions
This scenario applies to transaction-based verification

environments. This scenario is required for packet-processing
devices or instruction-based processor verification.

111
The device is set in some mode, and then multiple transactions are
generated and passed through the device. You use constraints to
generate the transaction objects. In this scenario, you can use the
default arguments for coverage convergence.
If you assume that many transactions will be generated

(randomized), then it is appropriate for the convergence heuristics to
take over and apply reactive calls as needed.
status = transObj.randomize();
or
repeat (1000) {
transObj = new;
status = transObj.randomize();
}
Using a Bias File for a Parallel Regression
In this scenario, you use the bias file generation utility to bias inputs
for different parallel test runs.
1. Run the first batch of tests using the following commands:

$SIM -cct_enable +ntb_random_seed = ${SEED}
Assume that each batch contains 100 tests.
2. Wait for first batch run to complete.

3. Merge the coverage results for all 100 tests in the first batch and
store the results in merged.vdb.
4. Perform bias file generation for the next batch of tests using the
following command:

112
$VCS_HOME/bin/urg -dir merged.vdb -group cct_gen_bias
100
This command distributes the remaining coverage holes into 100

bias files.
5. Run the second batch of 100 tests with each test using a different
bias file as an input:
$SIM -cct_enable -cct_bias_file=<bias_filename>
6. Merge results from the second batch of runs.

7. If coverage has not reached your coverage goal, then repeat steps
3 through 5.
Autogenerating a Coverage Model
Coverage convergence can generate a coverage model from the

constraints specification. However, you must instantiate the
coverage model that you intend to use in the simulation.
1. Autogenerate the coverage model:

Coverage convergence generates the model in the file

./cct_cov_gen/MyClass.vr.
2. Examine the generated model to determine if the model meets

your expectations.
3. Add the declaration for the generated cover group as part of the
class member declarations.

113
For example, if the name of the covergroup is MyCov and it is of
the class MyClass, then you must add to the other member
declarations for the class MyClass:
coverage_group MyCov;
4. The autogenerated coverage group must be instantiated in the

new task of the enclosing class. Perform the instantiation with the
following statement:
MyCov = new;
5. Make the cover group instantiation the last statement of the new
task. If the new task does not exist, then you must add the task
to the cover group instantiation.
6. Because the name of the autogenerated cover group is
deterministic, the declaration and instantiation can be done once
during testbench development phase.
Methodology and Flow Issues
This section addresses methodology and regression execution

issues.
Scenario: All Tests Have the Same Constraints and

Coverage Space (Recommended)
When all the tests being executed in parallel have exactly the same
coverage space and the same legal stimulus space (that is, the
constraints are exactly the same for all the tests), then the coverage
convergence bias file approach can be used to achieve high
efficiency test runs. Each test should have its own bias file. The input

114
database for the URG utility can be obtained by running any test and
using the output coverage database. The number of test runs should
be used as the value for the cct_gen_bias argument for URG.
Once the bias files are generated, they can be used again and again
for repeated regression runs. It is desirable that the number of times
the stimulus objects are randomized in a test be at least equal to the
average number of coverage bins in the bias files. After all the tests
are done running, the coverage database from all the tests can be
merged to get the final coverage number. It is possible but not
efficient to use both the random seed and the bias file for every test.
Scenario: Tests Are Grouped Into Categories With Each

Category Having Specific Test Constraints
In this scenario, tests have test specific test constraints which further
constrain the legal stimulus space and thus also reduce the hittable
coverage bins. (Coverage bins whose value ranges lie outside the
space of the test constraints cannot be hit). A bias file can be created
for every category of tests. The bias file should be such that all the
coverage bins in the file are hittable given the test constraints for that
category. Each test within this category can use the same bias file
but with a different random seed. The URG bias generation utility can
be used to generate a bias file template. (Note that the URG does
not look at test constraints when generating the bias files). The test
writer can then modify this template to include the hittable coverage
bins. As in the previous scenario, assuming test constraints remain
constant across regression runs, then the bias files have to be
generated once and can be used for multiple regression runs. Even
if all the bins in a bias file are not hittable, all it causes is less efficient
utilization of resources. Coverage convergence may use some
cycles in the test run to try to target unhittable bins, but remaining
cycles will still target hittable coverage bins. In this scenario too, the

115
coverage data from all the tests can be collected and merged. Then
a sequential run can be used to target any remaining coverage
holes. For this final sequential run, the merged coverage database
can be used as an input along with the fully open constraints.
Scenario: Coverage Database Being Loaded in the

Beginning of a Test Run
If a coverage database is being loaded as part of the configuration

for a test, then there is no need to use a coverage convergence bias
file. Coverage convergence will only target coverage bins that are
not covered in the loaded database, so it is already biased in some
sense. If the same database is loaded in multiple tests, then a
random seed can be used so that each test targets different holes.
This is useful in a batch mode type of regression environment. Here
all tests have the same constraints and coverage space, but one
batch of tests is run at one time. After the batch is complete, the
coverage databases are merged and the merged database is used
as input for the next batch of tests. Note that for repeatability
purposes, the input database associated with a test needs to be
preserved in case the test needs to be run in a stand alone mode. If
a coverage convergence bias file is used, then it will override the
bias from the loaded coverage database, that is, holes in the bias file
will be targeted even if they are marked as covered in the loaded
coverage database. Hence it does not make sense to use both
coverage database load and coverage convergence bias file
approaches for a test.

116
6
DVE Features 1
The following features are included in this release of the Discovery
Visual Environment (DVE):
• “Back Tracing” on page 118

• “Editing the Bus Bit Range” on page 121
• “Creating and Updating Counters” on page 122
• “Deleting Signal Group” on page 125
• “Creating Multiple Groups when Adding Multiple Scopes into
Wave View” on page 126
• “Visualizing X at all Zoom Levels” on page 126
• “Using Filters” on page 127
• “Viewing Interfaces as Ports” on page 128
DVE Features
117
Back Tracing
Back Tracing helps you debug a particular signal by traversing the

design backwards both structurally and temporally. You can back
trace an X value to its source signals, for example, across gates to
identify the signal that caused the X value. You can use the Back
Tracing feature for doing the following tasks:
• Remove the steady state and zero delay restriction for usage
• Reduce the number of drivers identified as causes for an X value
• Interactively drive the tracing process
Back Tracing in DVE is performed by Back Trace Schematic view.
You can invoke the Back Trace Schematic view from any of the
following windows:
• Waveform
• Schematic
• Path Schematic
• Data Pane
The Back Trace Schematic consists of two panes - a Wave View
pane and a Path Schematic pane. The Path Schematic pane is the
main structural view. The Wave view provides a temporal view and
provides information to decide which signals need further tracing.
You can close the Wave view if not needed.
To back trace a signal
1. Open DVE and click File > Open Database.
DVE Features
118
The database is loaded in the Hierarchy pane.
2. Select a scope in the Hierarchy pane.

The signals are displayed in the Data pane.
3. Select the Reset signal in the Data Pane, right-click and select
Back Trace Schematic.
The Back Trace Schematic view opens.
A wave group and Waveform view of the selected signal is

automatically created at the current simulation time. The current
simulation time and value pair are annotated on the output pins
of the driving cell. The input pins of the driving cell are annotated
with the values and times of the next signal transition.
4. Select the Fetch signal in the Data pane, right-click and select
Back Trace to fetch signal for further back tracing.
The traced signal "fetch" is added to the Wave view and its drivers
are added to the Schematic view. The first transitions are added
to the inputs to the drivers. Also, the current simulation time is
moved to the earliest time over all driver inputs.
Note:
Only one-level can be expanded for non-X signals.
DVE Features
119
Setting the Back Trace Properties
The Back Trace Properties window is used to add multiple levels of

trace, so that tracing X signals can automatically trace back multiple
levels following the X value over time. So instead of expanding one
level, you can draw multiple levels and add multiple signals on the
traced path to the Wave view.
To set the Back Trace properties
1. Select Trace Parameters or click the Trace Parameters button

on the toolbar.
The Back Trace Properties window opens that contains the
following options:
- Add traced signals to wave group - Adds the signals on the

traced path to the wave group and displayed in the wave view.
- Number of levels to trace - Controls the maximum number of
levels to search backwards when automatically searching for
X values.
- Maximum time threshold - Controls the maximum amount of
time to search backward in a waveform for a value change. The
delay from an input to output will determine the time window
where a value change can occur.
- Trace stop at - Controls the time to stop the trace. Once a
signal is selected, the default is the time annotated by back
tracing. There are several ways to search the waveform for the
specified signal. You can specify to stop at "Any Edge", "Rising",
"Falling", "Match", "Miss Match", "X Value", or "Value".
DVE Features
120
Using the Back Trace Schematic Toolbar
The Back Trace Schematic toolbar contains the following options:
Table 6-1 Back Trace Schematic toolbar

Options Description
Show/Hide Wave View Shows or hides the Wave view in the Back Trace
Schematic.
Trace Parameter Opens the Trace Parameter dialog.
Search Forward/Search Searches signals forward/backward.
Backward
Back Trace Stars back tracing the signal.
Trace Levels Controls the maximum number of levels to search
backwards when automatically searching for X
values.
Editing the Bus Bit Range
You can edit the bus bit range by simply changing either the MSB
(most significant bit) or the LSB (least significant bit) of the bus.
To edit the bus bit range
1. Select the bus in the Data pane or from the Wave view signal pane
and select Signal > Set Bus from the menu.
The Bus/Expression dialog box appears. You can also drag and
drop the signal in the Bus/Expression dialog.
2. Double-click the signal and edit the range.
DVE Features
121
For example, define a signal ias a[0:7], change the bit range to
a[7:6], and click on create/update. A bus will be created/updated
with the selected 2 bits as a[7], a[6].
If you enter a wrong range, a warning message is displayed and
the text color of the signal becomes red. You need to enter the
correct format to save the bit range.
3. Select the signal and click the “+” icon to expand.
The signal is expanded in the same order as specified in the name.
For example, a[1:3] signal will expand to a[1],a[2],a[3].
You can perform all the toolbar operations on the expanded
signals.
Creating and Updating Counters
You can create counter signal to count the value transitions for
expression or signal. Counter is treated as a special expression and
you can create or update counter in the same way as you create an
expression in the Bus/Expression dialog box.
The counter is supported both in post processing mode and

interactive mode. In interactive mode, with simulation going on, the
count result will be updated as other signals in the Wave view.
To create and update a counter
1. Select a signal in the Data pane and select Signal > Set
Expressions from the menu.
The Bus/Expressions dialog box is displayed.
DVE Features
122
2. Click the Expression tab, then drag and drop the signal that you
want to create for expression counter from the Wave view or
Source view under the Expression area.
3. Type a counter name in the Name field.
For example, EXP:mycount.
4. Select the checkbox Expression is used as a counter (counting
for non-zero results) to create a signal that represents the value
transitions of the expression.
DVE Features
123
The Counter Edge radio buttons get enabled.
5. Select any of the following Counter Edge as desired.

- Any Edge - This option is for any expression/signal. Whenever
the value of the expression/signal changes, counter signal
counts this transaction.
DVE Features
124
- Rising - (Default) This option is only for bit type signals.
Whenever the expression/signal changes from low to high,
counter signal counts the transaction.
- Falling - This option is only for bit type signals. Whenever the
expression/signal changes from high to low, counter signal
counts the transaction.
6. Click Create.
The newly created expression counter is displayed in the Bus/
Expressions dialog box. You can also view the count results in the
Wave view.
7. Drag and drop the counter in the Bus/Expression dialog box to
update it.
For example, you can update the counter edge from “Rising” to
“Any Value”.
8. Click the Update button.
The counter is updated. You can view the count results in the
Wave view.
Deleting Signal Group
When you delete a signal from the Wave view, it will be deleted
globally. If the same signal is present in few other views, and you
want to delete it, a warning message is displayed. You can either
select to delete or hide the signal.
Once you select to delete the signal, it would be deleted globally
from all views. If you select to hide the signal, it will be hidden in
the current view.
DVE Features
125
If the signal groups are deleted, save session will not have the
deleted signal groups. If you hide the signal, it will be hidden when
you are saving or reloading the session.
Creating Multiple Groups when Adding Multiple Scopes

into Wave View
When you add the scopes to the waves, lists, or groups from the
Hierarchy pane, the signal groups will be created based on their
respective scopes.
If you select Display signal group exclusively in the Application

Preference dialog box, and add multiple scopes to Wave view,
multiple scopes will be created, but only the last group will be
displayed.
Visualizing X at all Zoom Levels
While debugging a design, you can visualize the X value in the Wave
view at all zoom levels.
To visualize X value
1. Select a signal in the Signal pane with many value changes.

2. Zoom out the signal until the waveforms are condensed to yellow
bar.
3. Right-click the signal and select Highlight X Values or select
Signal > Highlight X Values from the menu.
DVE Features
126
The waveform is refreshed in the Wave view and X values are
displayed as red color lines for all the zoom levels.
Using Filters
You can enter the filter strings in three different styles:
• Explicit wildcard (Default)

• Implicit wildcard (*) at the beginning and end of filter string
• Regular expression strings
The logical OR operator "||" is supported in Explicit and Implicit
wildcard strings. The Filter drop-down is also available in the Data
pane, Wave Viewer, and Signal Search Results Dialog.
To use the filter
1. Click Edit > Preferences.

The Application Preferences dialog box opens.
2. Click the Global category.
3. In the View Filters group box, select the following options, as
appropriate:
- Apply view filters immediately when typed
- Case sensitive
- Syntax - The following options comprise the Syntax drop-down
list:
DVE Features
127
-Wildcards - Input the wildcard pattern to filter items. The default
string is “*”.
-Simple - Input the regular expression pattern to filter items.
The default string is ““.
-Regular Expressions - Input the simple string to filter items.
The default string is “.*”.
Viewing Interfaces as Ports
You can view Interface/Modport in the Data pane when it is passed

as port. You need to select the module name in the Hierarchy pane
to view the port in the Data pane. You can add the interface/modport
port to the Wave view, List View, or Watch view.
To view the interface port in Data pane
1. Load the database in DVE.

The module is displayed in the Hierarchy pane.
2. Select the module.
DVE Features
128
The interface/modport port and its type is displayed in the Data
pane. The tooltip shows the interface/modport used.
3. Click the “+” button under the Variable column in the Data pane
to expand the interface/modport port.
The signals under the interface/modport port are displayed.
4. Right-click the interface/modport port in the Data pane and select
Show Source.
The source of interface/modport is shown in the Source viewer.
You can also drag and drop the interface/modport from the Data
pane to the Source viewer.
5. Use the Text filter or Type filter drop-down and select the Interface/
Modport port filter to filter the signals.
DVE Features
129
6. Select the interface/modport port in the Data pane and select
Signal > Show Definition from the menu or right-click the signal
and select Show Definition.
The definition is shown in the Hierarchy pane, signals of interface/
modport port in the Data pane, and the definition location is shown
in the Source viewer.
7. Drag and drop the interface/modport port from the Data pane to
the Wave view or right-click and select Add to Waves.
The Interface/Modport port is shown in the Wave view.
Limitations
The following are few limitations of this feature:
• Interface array port is not displayed in the Data pane.
DVE Features
130
• Driver/Load, schematic/path schematic operations do not support
interface port and signals of interface port. A warning message is
displayed when you perform these operations.
• Follow signal doesn't work for interface port and signals of
interface port.
• Modport clocking port is not shown in the Data pane.
DVE Features
131
DVE Features
132
7
Viewing values in Symbolic format 1
You can view the values of signals/variables in the same radix as
specified in the source code. In addition to existing radixes decimal,
hexadecimal, binary, and octal, UCLI supports the symbolic radix
that will enable you to view the values in the same radix. The default
radix will hence be symbolic.
To change the default radix from symbolic to any other (binary,

hexadecimal, octal, and decimal), use the following command
option:
ucli> config -radix hexadecimal

This will set the radix format to hexadecimal.
If the default radix is changed to any other, you can still view the
values with the default symbolic radix by passing symbolic argument
to –radix.
-radix symbolic
“Viewing values in Symbolic format”

133
Example:
ucli> show –value top.dut.x –radix symbolic

134
The following tables list various data types’ use model and illustrate
the output format for the symbolic radix.
Table 7-1 Verilog/SystemVerilog Data Types
Example Symbolic output

wire [3:0] wire4_1 = 4'b01xz; wire4_1 'b01xz
reg16_1 'b1000000000000001
reg [15:0] reg16_1 =15'h8001;"
logic [15:0] logic16_1='h8001; logic16_1 'b1000000000000001
typedef struct struct1 {(opcode => 'b00000001,addr =>

{ bit [7:0] opcode; bit [15:0] addr; } 'b0001001000111111)}
struct1_type;
struct1_type struct1= '{1, 16'h123f};"
enum {red, yellow, green} light 1

light=yellow;
integer int_vec [1:0]='{15,21}; int_vec (15,-21)
string string_sig="verilog_string"; string_sig verilog_string

135
Table 7-2 VHDL Data Types
Example Symbolic output

signal stdl : std_logic := 'H'; STDL 'bH
signal stdl_vec : std_logic_vector (0 to 8) := STDL_VEC'bUX01ZWLHH

"UX01ZWLHH”;
signal real_sig:real := 2.2000000000000002; REAL_SIG 2.200000e+00
type bit_array_type is array (0 to 1) of BIT_ARRAY_SIG ('b00,'b01)

bit_vector (0 to 1);
signal bit_array_sig : bit_array_type := (("00"),
("01"));
signal char_sig : character := 'P'; CHAR_SIG P
signal string_sig : STRING(1 to 17) := "THIS STRING_SIG {THIS IS A MESSAGE}

IS A MESSAGE";
signal time_sig : time := 5 ns; TIME_SIG 5

136
8
Constraints Features 1
• “SystemVerilog Constraint Features” on page 138

- “Array and XMR Support in std::randomize()” on page 138
- “XMR Support in Constraints” on page 141
• “Constraint Debugging and Profiling” on page 144
- “Using Constraint Profiling” on page 144
- “Using the Hierarchical Constraint Debugger Report” on page
147
• “Debugging Constraint Solver Diagnostics” on page 150
- “Solver Overview” on page 151
“Constraints Features”
137
- “Methodology for Using Unidirectional Constraints” on page
152
- “Constraint Solver Search Space and Solution Space” on page
154
- “Search Space Reduction And Random Assignment” on page
155
- “Using the Constraint Solver Diagnostics” on page 156
- “Classes of Constraint Diagnostics” on page 159
SystemVerilog Constraint Features
The following SystemVerilog constraint features are new:
• “Array and XMR Support in std::randomize()” on page 138

• “XMR Support in Constraints” on page 141
Array and XMR Support in std::randomize()
VCS allows you to use cross-module references (XMRs) in class

constraints and inline constraints, in all applicable contexts. Here,
XMR means a variable with static storage (anything accessed as a
global variable).
VCS std::randomize() support has been enhanced to allow the

use of arrays and cross-module references (XMRs) as arguments.
VCS supports all types of arrays:
• fixed-size arrays
138
• associative arrays
• dynamic arrays
• multidimensional arrays
• smart queues
Note:
VCS does not support multidimensional, variable-sized arrays.
Array elements are also supported as arguments to

std::randomize().
VCS supports all types of XMRs:
• class XMRs
• package XMRs
• interface XMRs
• module XMRs
• static variable XMRs
• any combination of the above
You can use arrays, array elements, and XMRs as arguments to
std::randomize().
Syntax
integer fa[3];
success= std::randomize(fa);
success= std::randomize(fa[2]);
success= std::randomize(pkg::xmr);
139
Example
module test;
integer i, success;
integer fa[3];
initial
begin
foreach(fa[i]) $display("%d %d\n", i, fa[i]);
success = std::randomize(fa);
foreach(fa[i]) $display("%d %d\n", i, fa[i]);
end
endmodule
When std::randomize() is called, VCS ignores any rand mode

specified on class member arrays or array elements that are used as
arguments. This is consistent with how std::randomize() is
specified in the SystemVerilog LRM. This means that for purposes of
std::randomize() calls, all arguments have rand mode ON, and
none of them are randc.
Error Conditions
If you specify an argument to a std::randomize() array element
which is outside the range of the array, VCS prints the following error
message:
Error-[CNST-VOAE] Constraint variable outside array error
Random variables are not allowed as part of an array index.
If you specify an XMR argument in a std::randomize() call, and

that XMR that cannot be resolved, VCS prints an error message.
140
XMR Support in Constraints
You can use XMRs in class constraints and inlined constraints. You
can refer to XMR variables directly or by specifying the full
hierarchical name, where appropriate. You can use XMRs for all data
types, including scalars, enums, arrays, and class objects.
VCS supports all types of XMRs:
• class XMRs
• package XMRs
• interface XMRs
• module XMRs
• static variable XMRs
• any combination of the above
Syntax
constraint general
{
varxmr1 == 3;
pkg::varxmr2 == 4;
}
c.randomize with { a.b == 5; }
Examples
Here is an example of a module XMR:
// xmr from module

module mod1;
int x = 10;
class cls1;
rand int i1 [3:0];
141
rand int i2;
constraint constr
{
foreach(i1[a]) i1[a] == mod1.x;
}
endclass
cls1 c1 = new();
initial
begin
c1.randomize() with {i2 == mod1.x + 5;};
end
endmodule
Here is an example of a package XMR:
package pkg;
typedef enum {WEAK,STRONG} STRENGTH;
class C;
static rand STRENGTH stren;
endclass
pkg::C inst = new;

endpackage
module test;
import pkg::*;
initial
begin
inst.randomize() with {pkg::C::stren == STRONG;};
$display("%d", pkg::C::stren);
end
endmodule
Functional Clarifications
XMR resolution in constraints (that is, choosing to which variable
VCS binds an XMR variable) is consistent with XMR resolution in
procedural SystemVerilog code. VCS first tries to resolve an XMR
142
reference in the local scope. If the variable is not found in the local
scope, VCS searches for it in the immediate upper enclosing scope,
and so on, until it finds the variable.
If you specify an XMR variable that cannot be resolved in any parent

scopes of the constraint/scope where it is used, VCS errors out and
prints an error message.
143
Constraint Debugging and Profiling
VCS can generate constraint profiling reports and hierarchical

constraint debugger reports during the simulation run. These
features are explained in the following sections:
• “Using Constraint Profiling” on page 144

• “Using the Hierarchical Constraint Debugger Report” on page 147
Note:
You can use both of these reporting features at once. Just add
the appropriate switches to your simulation run command line.
Using Constraint Profiling
You can use VCS constraint profiling reports to find out how much
runtime and memory is spent on each randomize call in your
testbench. Profiling reports also show cumulative statistics and allow
you to cross-probe into the hierarchical constraint debugger reports.
To run your simulation with constraint profiling on, use the following
runtime switch:
% ./simv +NTB_CSTR_DEBUG_PROFILE=1
After the simulation completes, invoke an HMTL browser on the

cstr_html/profile.xml file. For example:
% firefox $cwd/cstr_html/profile.xml
144
Figure 8-1 on page 146 shows some sample profiler results,
including randomize calls that are consuming the most time and
memory. Note that this illustration shows just the top of the report.
From the report, you can click the randomize call identifier or the
partition identifier to cross-probe to its corresponding constraint
hierarchical debug (trace) section.
When you use +ntb_solver_model=1, the majority of memory

blowup cases are due to binary decision diagram (BDD) blowup. The
profiler report also shows the node count of the largest partitions (the
more nodes, the more memory used).
145
Figure 8-1 VCS Constraint Profiling Example
146
Using the Hierarchical Constraint Debugger Report
VCS can also generate a hierarchical constraint debugging report

after your simulation run completes.
To run your simulation with hierarchical constraint debugging on, add

the following runtime switch:
% ./simv +NTB_ENABLE_XML_SOLVER_TRACE=1
After the simulation completes, invoke an HMTL browser on the

cstr_html/trace.xml file. For example:
% firefox $cwd/cstr_html/trace.xml
Figure 8-2 on page 148 shows some sample hierarchical trace

debugger results. Note that this illustration shows just the top of the
report.
Note:
VCS uses SystemVerilog syntax instead of OpenVera syntax
when printing constraints in the trace.
147
Figure 8-2 VCS Hierarchical Constraint Debugger Report
When you first bring up the HTML randomizer report, all the items
are collapsed. Click a specific item to make it expand. For each
obj.randomize()call, VCS prints the:
• File name and line number in your SystemVerilog or OpenVera

source code where that randomize() call is made.
148
• Visit count, incremented each time the same randomize() call
occurs. For example, a randomize() call inside a for loop has
test.sv:20@1, test.sv:20@2, and so on. This visit count is
also referenced in the profiling tables (see Figure 8-1 on
page 146).
• File name and line number for each variable to point to the place
where it is defined.
• File name and line number of the class where each variable is
defined.
• Runtime and memory usage for each partition, and for each full
randomize call.
Color Coding Constraint Blocks and rand vars

In the randomize reports, each randomize() call has a number of
constraint blocks and variables (rand vars and state vars). VCS uses
color coding to identify constraint blocks and rand vars that are
turned ON, and different colors for those that are turned OFF.
Avoiding Duplicate Printing of Original Constraint Set

VCS does not print the original set of constraints twice when the
constraint debugger or solver_trace=2 are turned ON. The
default printing mode only displays the failure subset instead of both
(see Figure 8-3).
Figure 8-3 Constraint Debugging Report

Solver failed when solving following set of constraints
rand integer y; // rand_mode = ON
rand integer z; // rand_mode = ON
rand integer x; // rand_mode = ON
constraint c // (from this) (constraint_mode = ON)
149
{
( x < 1 ) ;
( x in { 3 , 5 , 7 : 11 } ) ;
}
You can use the

+ntb_enable_solver_trace_on_failure=0,1,2,3 runtime
option as follows:
• 0: Print a one-line failure message with no details.

• 1: Print only the failure subset (this is the default).
• 2: Print the entire constraint problem and failure subset.
• 3: Print only the failure problem. This is useful when the solver
fails to determine the minimum subset.
Debugging Constraint Solver Diagnostics
This section explains how to use the VCS constraint solver

diagnostic feature to debug testbench constraints.
Also included is an overview of the constraint solver that provides

insights into the underlying performance issues with certain
constraint expressions. Other sections contain detailed explanations
of the diagnostic messages and coding recommendations for the
reported constraints.
Use the constraint solver diagnostics feature to analyze solver

performance or when a simulation timeout occurs at a
randomize() call. When performing diagnostics, the solver has
two modes: reactive and proactive.
150
In reactive mode, VCS issues diagnostic messages for actual
constraints applied to a specific randomize() call. The diagnostic
report displays:
• Specific constraints that contributed to the timeout or simulation

halt.
• Messages that indicate the source of constraint issues.
When used in the proactive mode, the constraint solver diagnostics
are based on a pre-solve analysis. The diagnostic report displays
constraints that could cause performance issues. Based on the
diagnostic information in the report, you can modify the constraints
to prevent potential performance issues or timeouts when
randomize() is called.
The constraint solver diagnostics feature analyzes a specific set of

constraint expressions that are known to have performance impacts.
This set of expressions is documented in the section “Classes of
Constraint Diagnostics” on page 159.
Solver Overview
The VCS constraint solver can solve a wide spectrum of difficult

problems such as algebraic factoring, complex Boolean
expressions, and mixed integer and register expressions. The solver
issues an error message when no combination of random values
satisfies the specified constraints. This problem can be caused by
over-constraining the random variables.
By default, the constraint solver treats all constraint expression

operators bidirectionally and solves for all random variables and
constraints simultaneously. This behavior prevents implicit
151
partitioning of constraints by the solver, a common problem in other
industry solvers. As a result, the solver does not over-constrain
random variables or create spurious failures.
The bidirectional nature of constraints and the simultaneous solving

of all random variables and constraints increases the complexity of
problems handled by the solver, which impacts the solver
performance. You can reduce the complexity by using the
unidirectional constraint feature to explicitly partition random
variables in constraints. The solver takes the partition information
and breaks down a single complex problem into a sequence of
simpler problems,. The solver then solves the random variables in
the order determined by the partitions. This results in improved
solver performance overall.
Methodology for Using Unidirectional Constraints
The default solver behavior does not impose implicit partitioning.

This is the recommended best practice. However, if you run into
performance issues, you can use unidirectional constraints to
improve performance.
Use unidirectional constraints to create separate partitions for

control variables. Control variables are random variables that allow
solutions for other random variables regardless of the values
assigned to them. For example, in a CPU instruction sequence
generator, the opcode can be used as a control variable, as shown
in Example 8-1.
Example 8-1 Unidirectional Constraint

class C;
rand integer x;
152
constraint c1 {
x > 0;
}
endclass: C
class D;
rand C c[$];
typedef enum { T1, T2 } trans;
rand trans opcode;
constraint d1 {
foreach (c [i]) {
if (opcode == T1) {
c[i].x == 1;
} else if (opcode == T2) {
c[i].x == 2;
}
}
}
endclass: D
In Example 8-1, opcode is a control variable you can solve for first
to break the solver problem into smaller subsets. To do this, you can
use the $void() function:
foreach (c [i]) {
if ($void(opcode) == T1) {
c[i].x == 1;
c[i].x == 2;
}
}
or use the solve-before-hard directive:
foreach (c [i]) {
if (opcode == T1) {
c[i].x == 1;
c[i].x == 2;
153
}
solve opcode before c[i].x hard;
}
If the control variable partitions do not result in sufficiently improved

solver performance, create additional partitions for the non-control
variables.
Constraint Solver Search Space and Solution Space
For each random variable in a constraint network, the range of

possible values (the search space) is represented by a {low,
high} pair. The initial search space of a random variable is equal to
all possible values of the data type. For example, the initial search
space of an unsigned 32-bit variable is:
{0 ,232-1}
The initial search space of a partition is the composite range that all
random variables of the partition can fall into. For example, the initial
search space for a partition with five unsigned 32-bit variables is:
(232)5 = 2160
However, the set of values that actually meets the constraints you
specify is typically much smaller than the search space. This set of
values (the solution space), is determined by the constraints on the
random variables.
To see how this works, consider Example 8-2. Here, the initial search
space for varA has 232 values. However, the solution space is
limited to the 16 values specified by the inside constraint.
154
Example 8-2 Search Space Reduced by “in” Constraint
class B;
rand bit[31:0] varA;
constraint varA_range {
varA inside {[0:15]};
}
endclass: B
Search Space Reduction And Random Assignment
The goal of the constraint solver is to assign randomly selected

values to random variables, while ensuring that the values satisfy the
constraints on those variables. The process of selecting a valid
solution involves two phases: search space reduction and random
assignment.
In the first phase, the solver narrows down the search space to
match the solution space as closely as possible, while not removing
any element of the solution space from the search space. This
ensures that if a valid solution exists, it is reached without being
prematurely eliminated from consideration.
In the second phase, the solver algorithm assigns a randomly picked

value from the search space to a random variable and performs
implication. Implication is the process of simulating the constraint
network using the value assigned to a random variable to check that
no constraint is violated.
155
Using the Constraint Solver Diagnostics
You can use the constraint solver diagnostic feature to troubleshoot

solver performance issues. The diagnostic report does not provide
information related to constraint solver failures (for example,
inconsistent constraints or dependency loops).
Choosing a Display Mode

There are two display modes for the diagnostic report: non-verbose
and verbose.
• Non-verbose Mode—The diagnostic report displays the search

space of variables to be randomized in the current partition only
if at least one diagnostic message is reported.
• Verbose Mode—The diagnostic report always displays the
search space of variables to be randomized in the current
partition, even if no diagnostic message is reported.
Enabling Diagnostics
You enable the constraint solver diagnostic feature using a set of
runtime options or by passing a macro argument to randomize()
on a per-call basis.
ntb_enable_solver_diagnostics
The +ntb_enable_solver_diagnostics=value option
enables the constraint solver diagnostics. You use the value
argument to specify the desired diagnostic mode. This option
enables display for the entire simulation.
156
Syntax
+ntb_enable_solver_diagnostics=value
where value can be:
• 0 — Constraint solver diagnostics is off (this is the default)

• 1 — Reactive, non-verbose mode
Select this mode if constraints are solved successfully but the
solver performance is unacceptable.
• 2 — Proactive, non-verbose mode

Select this mode if complex constraints exist and you want to
check for expressions that have potential performance impact.
• 3 — Reactive, verbose mode

Select this mode if you want verbose information in reactive mode.
• 4 — Proactive, verbose mode

Select this mode if you want verbose information in proactive
mode.
Note:
Solver diagnostic output is verbose. It is a good idea to run a short
simulation with few randomize() calls when using this feature.
ntb_enable_solver_diagnostics_on_failure
The +ntb_enable_solver_diagnostics_on_failure option
enables the constraint solver diagnostics and reports diagnostic
information only when the solver times out.
157
Syntax
+ntb_enable_solver_diagnostics_on_failure=value
where value can be:
• 0 — Constraint solver diagnostics is off (this is the default)

• 1 — Reactive, non-verbose mode
Diagnostic behavior is the same as the
+ntb_enable_solver_diagnostics=1 option (reactive,
non-verbose mode) except in the printing of the diagnostic
information. Printing of diagnostic information starts only when a
solver timeout occurs.
• 2 — Reactive, verbose mode

Diagnostic behavior is the same as the
+ntb_enable_solver_diagnostics=3 option (reactive,
verbose mode) except in the printing of the diagnostic information.
Printing of diagnostic information starts only when a solver timeout
occurs.
Saving Diagnostic Reports

ntb_solver_diagnostics_filename
By default, VCS displays diagnostic information on standard I/O. Use
the +ntb_solver_diagnostics_filename option to specify a
file for storing the diagnostic information.
Syntax
+ntb_solver_diagnostics_filename=filename
158
In the report, the diagnostic information reported for each constraint
is organized and displayed in the following four sections:
• Diagnostic message
• Variables (random and non-random) involved in the reported
constraint
• Reported constraint
• Search space for random variables involved in the current partition
Classes of Constraint Diagnostics
The constraint solver diagnostics target a set of specific constraint

expressions that are known to have performance impacts. Each of
these constraint expressions, the corresponding diagnostic
messages, and possible solutions are discussed in the following
sections.
• “Operator that Splits Value Ranges Resulting in Sparse Solution

Set” on page 160
• “Low Probability of a Successful Solution—Factorization of a
Constant” on page 161
• “Relational Operator On The Result Of A Shift Operation—
Behavior of Expression” on page 163
159
Operator that Splits Value Ranges Resulting in Sparse
Solution Set
In Example 8-3, the result of the modulus operation is constrained to
a singleton value. The divisor is large (621), and the size of the
resulting range is small {{0:0}}. The probability of finding a
solution is very low (1/621). This causes a solver timeout.
Example 8-3 Operator Splits Value Ranges

class modulus;
rand bit [64:0] base;
constraint residue {
base % 621 == 0;
}
endclass: modulus
Diagnostics Report
MSG 3: There is a low probability of a successful assignment based
on the existing values of the operand.
rand bit[64:0] base; // rand_mode = ON
constraint residue // (from this) (constraint_mode = ON)

{
( ( base % 621 ) == 0 ) ;
}
*** The search spaces for the random variables are:
base: (000000000000000000000000:00000001ffffffffffffffff)
***
160
Changing the Size of a Divisor
In Example 8-4, either decrease the size of the divisor or expand the
options in the RHS to increase the probability of finding a solution.
Example 8-4 Changing Size of Divisor

class B;
rand bit [64:0] base;
rand bit [3:0] res;
constraint residue {
base % 621 == res;
}
endclass: B
Low Probability of a Successful Solution—Factorization

of a Constant
For constraint expressions in the form varA*varB == RHSExp, if
the range of possible values of the RHSExp is small, the solver may
not be able to find values for varA and varB such that varA*varB
is in the range of the RHSExp.
This can happen when VCS solves for random variables in the
RHSExp before it solves for the random variables in the multiplication
operator, or if the RHSExp is a constant. Consider this next example
(Example 8-5).
Example 8-5 Factorization of a Constants

class A;
rand bit [32:0] varA, varB, varC;
constraint factorization {
varA * varB == varC;
varA > varB;
//solve varA before varC;
161
//solve varB before varC;
}
endclass: A
In, Example 8-5, the probability of finding a solution for the constraint
varA*varB == varC is exceedingly low. In this case if you add the
solve-before constraints, the constraint solver solves the two
operands of the multiplier (varA and varB) before varC. In the
absence of the solve-before constraints, this situation causes a
solver timeout.
Diagnostic Report
MSG 14: The expression with the multi-node causes problems.
rand bit[32:0] varA; // rand_mode = ON

rand bit[32:0] varB; // rand_mode = ON
rand bit[32:0] varC; // rand_mode = ON
constraint base_and_limit // (from this) (constraint_mode =

ON)
{
( ( varA * varB ) == varC ) ;
}
*** The search spaces for the random variables are:
varA: (0000000000000001:00000001ffffffff)
varB: (0000000000000000:00000001fffffffe)
varC: (0000000000000000:00000001ffffffff)
***
Specifying Solve Order for Random Variables

In Example 8-6, if varC is solved first, the probability of finding a
solution that satisfies the constraint varA*varB == varC is low.
Example 8-6 Specifying Solving Order for Random Variables

class B;
rand bit [32:0] varA, varB, varC;
162
constraint factorization {
varA * varB == varC;
varA > varB;
solve varA, varB before varC;
}
endclass: B
In Example 8-6, the solve-before directive specifies that the

varA and varB multipliers be solved before the random variable on
the RHS, varC. WIth this change, the probability of finding a solution
increases.
Relational Operator On The Result Of A Shift

Operation—Behavior of Expression
A shift operation (for example, <<) that fans out to a relational
operator (for example, ==) forces a very specific value for the result
of the shift operation. In this case, the probability of finding a solution
is extremely low and results in a solver timeout. Consider this next
example (Example 8-7).
Example 8-7 Relational Operator on Shift Operation Result

rand integer window_size, window_shift;
rand bit [28:0] mask;
constraint use_window_params {
(window_size > 0);
(window_shift > 4);
((window_shift+window_size) < 30);
mask == (((1<<window_size)-1) << window_shift);
//solve window_size,window_shift before mask;
}
163
In Example 8-7, the last constraint combines random shift operations
to match a random mask. If a random selection for the mask value
results in only one digit set to 1, the probability of finding a solution
is 23/229 (almost zero).
Diagnostics Report
MSG 19: The shift node fans out arithmetic/relational operators
which may have a low probability of success.
rand bit[28:0] mask; // rand_mode = ON

rand integer window_size; // rand_mode = ON
rand integer window_shift; // rand_mode = ON
constraint use_window_params // (from this)(constraint_mode
= ON)
{
(mask == (((1 << window_size)- 1)<< window_shift));
}
Using the solve-before Directive

In Example 8-8, if mask is solved first and results in a single digit set
to 1, the probability of finding a solution that satisfies the constraints
is extremely low.
Example 8-8 Using solve-before Directive

class B;
rand integer window_size, window_shift;
rand bit [28:0] mask;
constraint use_window_params {
(window_size > 0);
(window_shift > 4);
((window_shift+window_size) < 30);
mask == (((1<<window_size)-1) << window_shift);
solve window_size, window_shift before mask;
}
endclass: B
164
In Example 8-8, the solve-before directive specifies that the shift
amount be solved before the mask. This ensures that the value of
mask is calculated rather than randomly assigned.
165
166
9
Parallel VCS 1
Parallel VCS (PVCS) takes advantage of the computing power of
multiple processors in one machine to improve simulation
turnaround time
Use the following Parallel VCS options in a simulation:
• Design profiling and simulation

• Assertion profiling and simulation
• Toggle coverage
• Parallel functional coverage
• VPD dumping
Parallel VCS
165
Parallel VCS Options
You use the VCS -parallel option to invoke parallel compilation.

The syntax is:
vcs -parallel [+options | +option[_only]

[-o PVCS_executable_name] [+option(s)]
design=FILENAME
Enables all parallel VCS options and specifies the name of the
partition configuration file. Note: this option is available at compile-
time only.
fc[=NCONS]
Enables Parallel Functional Coverage and with NCONS
specifying the number of PFC consumers.
profile
Enables design and assertion level profiling.
profile_value
Enables value-based design level profiling.
show_features
Shows enabled PVCS features.
sva[=NCONS]
Enables Parallel SVA and with NCONS specifying the number of
parallel SVA consumers..
tgl[=NCONS]
Enables Parallel Toggle Coverage and specifies the number of
parallel toggle coverage consumers.
vpd[=NCONS]
Enables Parallel VCD+ Dumping and specifies the number of
parallel VCD+ consumers.
Parallel VCS
166
vpd_sidebuf=MULT
Sets the size of PVPD side buffer to MULT times the size of the
main buffer.
_only
Conserves processor resources by enabling only the processing
of the PVCS option specified. _only must immediately follow the
-parallel VCS option. It can be used with any PVCS option and
any other PVCS options can follow _only. For example, to enable
the design and vpd options enter:
vcs -parallel+design_only=FILENAME+vpd
[-o PVCS_executable_name]
Using the VCS -o option to specify the simulation executable
binary filename allows work on multiple simultaneous PVCS
compiles and runs. PVCS-specific data is stored in a directory
executable_name.pdaidir. The default path name is
simv.pdaidir.
Use Model for Design Profiling and Simulation
The use model for PVCS is as follows:
1. Compile and simulate your design using the conventional serial

mode (compiling and simulating the design on one processor).
Run the VCS profiler during simulation.
The VCS profiler tells you the subhierarchies in your design that
use the most CPU time. See “Profiling a Serial Simulation” on
page 9-175.
2. Specify the partitions in the PVCS configuration file. See

“Specifying Partitions” on page 9-176.
Parallel VCS
167
3. Run parallel compilation, specifying the PVCS configuration file..
See “Design Simulation” on page 9-169.
4. Run parallel simulation. See “Design Simulation” on page 9-169.
If you wish to increase the performance gains from PVCS, additional
steps follow:
5. Run parallel simulation again and this time collect data for the
PVCS profiler.
6. Run the PVCS profiler. See “Profiling a Parallel Simulation” on
page 9-177.
7. Examine the PVCS profiler results. These results could call for
you to reorganize you partitions or your Verilog source code. See
“Examining the PVCS Profiler Results” on page 9-179.
8. After making the changes called for by the results, run parallel
compilation and simulation over again.
Use Model for Assertion Simulation
1. Run parallel compilation specifying the sva option.

2. Run parallel simulation.
Use Model for Toggle and Functional Coverage
1. Run parallel compilation specifying the PVCS tgl option and

coverage metric options for toggle coverage, and/or the PVCS fc
option for functional coverage. You can optionally specify the
number of consumers for each.
2. Run the simulation to generate coverage results.
Parallel VCS
168
3. Generate coverage result reports.
Use Model for VPD Dumping
1. Run parallel compilation specifying the vpd option.

2. Run the simulation to generate the VPD file.
Running Parallel Simulation
Parallel VCS (PVCS) takes advantage of the computing power of

multiple processors to improve simulation turnaround time
You can generate results for one of all the following Parallel VCS
options in a simulation:
• Design simulation
• Assertion simulation
• Toggle coverage
• Functional coverage
• VPD file generation
Design Simulation
Once you have profiled your design and created a partition

configuration file as described in the previous chapter, you can
simulate only the design or simulate the design with other PVCS
options.
Parallel VCS
169
1. Compile using the PVCS -parallel option and other PVCS and
VCS options.
vcs filename(s).v -parallel+(design |
design_only)=partition_filename.cfg
parallel_vcs_options vcs_options
2. Run the simulation with VCS and PVCS run-time options.

simv
Assertion Simulation
You can process only assertion level results or assertion level

results along with other PVCS options.
1. Compile using the PVCS -parallel option, the assertion

compilation option or options, and other PVCS and VCS options.
vcs filename(s).v -parallel+[sva[=NCONS]]
[-ntb_opts] [ parallel_vcs_options vcs_options
2. Run the simulation with VCS and PVCS run-time options.

simv
Toggle Coverage
Generate results for only toggle coverage or toggle coverage along

with other results by compiling the design with PVCS options and
VCS coverage metrics options. You can use the +count option to
report total executed transactions. After generating coverage results,
you can examine them using the Unified Report Generator.
tgl[+count]
Report total executed transactions.
Parallel VCS
170
1. Compile using the PVCS -parallel option, coverage option or
options, and other PVCS and VCS options.
vcs filename(s).v -parallel+tgl[=NCONS] -cm tgl
[parallel_vcs_options] [vcs_options]

simv -cm tgl [vcs_options]
3. Generate coverage result reports:

urg -dir coverage_directory.cm urg_options
Example
In this example, toggle coverage results only are generated and the
URG report is produced in the default HTML format.
% vcs -cm_tgl mda -q -cm_dir pragmaTest1.cm -cm tgl -sverilog

-parallel+tgl=2 pragmaTest1.v
% simv -cm tgl
% vcs -cm_pp -cm_dir pragmaTest1.cm
% urg -dir pragmaTest1.cm
Parallel VCS
171
Results can then be examined in your default browser.
Functional Coverage
Generate results for only functional coverage or functional coverage

along with other results by compiling the design with PVCS options
and VCS coverage metrics options. After generating coverage
results, you can examine them using the Unified Report Generator.
1. Compile using the PVCS -parallel option, coverage option or

options, and other PVCS and VCS options.
vcs filename(s).v -sverilog -parallel+fc[=NCONS]

simv
3. Generate coverage result reports:
Parallel VCS
172
urg -dir coverage_directory.cm urg_options
Example
In this example, functional coverage results only are generated and
the URG report is produced in the default HTML format.
% vcs iemIntf.v -ntb_opts dtm -sverilog -parallel+fc=2

% simv -covg_cont_on_error
% $urg -dir simv.vdb
% cat urgReport/gr*
%
Results can then be examined in your default browser.
VPD File
You can enable Parallel VCD+ Dumping and specify the number of
parallel VCD+ consumers using the PVCS vpd option.
Parallel VCS
173
1. Compile using the PVCS -parallel option with the vpd[=NCONS]
option, and other PVCS and VCS options.
vcs filename(s).v -debug_pp -parallel+vpd[=NCONS]

2. Run the simulation.

simv
You can post-process the results with the generated +vcd

database.
Example
In this example, a VCD+ file with three specified consumers is
generated.
% vcs -debug_pp -parallel+vpd=3 design.v

% simv
Profiling a Simulation
You can profile your PVCS simulation to ensure efficient use of

resources. This chapters details the profiling process. It contains the
following sections:
• Profiling a Serial Simulation

• Specifying Partitions
• Profiling a Parallel Simulation
• Running PVCS Examples
Parallel VCS
174
Profiling a Serial Simulation
You can profile your simulation to determine if it is a good candidate

for parallel simulation and identify partitions to use. You do this by
telling VCS to run its profiler during simulation with the +prof
compile-time option.
vcs +prof filename(s)

The VCS profiler tells you, among other things, what module
instances use the most CPU time. The CPU time percentages are for
the instance and all instances hierarchically under the instance. The
CPU time percentage thus represents the subhierarchy in which the
instance is the top-level instance.
The VCS profiler writes its profile information in the vcs.prof file in
the current directory. Look at the INSTANCE VIEW section in this file.
This section, or view, tells you the percentage of CPU time used by
each subhierarchy. Figure 9-1 shows this view.
Figure 9-1 Instance View in a vcs.prof File

==========================================================
INSTANCE VIEW
==========================================================
Instance %Totaltime
top (1) 100

top.A1 (2) 30
top.A2 (3) 30
top.A3 (4) 30
----------------------------------------------------------
The subhierarchies that use the most CPU time are good candidates
for PVCS partitions. In Figure 9-1 you would use separate partitions
for the subhierarchies.
Parallel VCS
175
Specifying Partitions
The -design option requires a partition configuration file. You

specify the partitions in the PVCS configuration file using the
following syntax:
partition {hierarchical_name(module_identifier),...} ;
.
.
.
The syntax is as follows:
partition
The keyword that specifies that what follows are the contents of
one partition.
hierarchical_name
The hierarchical name of a Verilog module instance that is the
top-level instance of the subhierarchy that you want to simulate
as a partition.
module_identifier
The name of the module definition that corresponds to the top-
level instance.
All parts of the design not covered in any of the specified partitions
together form an implicitly defined master partition. The user-
specified partitions are called slave partitions.
Example 9-1 PVCS Configuration File

In this example, there is a separate line for each partition. Each
hierarchical name for a top-level module instance must be followed
by its module name in parentheses. You can specify more than one
subhierarchy in a partition.
Parallel VCS
176
partition {top.A1(A1)};
Note: You can use the Verilog comment syntax to comment your
partition file. For more information on creating configuration files, see
the VCS User Guide.
Example 9-2 A Free Format Configuration File

You can also enter a free format of the specifications in a
configuration file entering new lines, blanks, and comments.
partition { top.bus1 (MyBus),

top.cpu (CPU) }; // two instances per partition
partition {
top.bus2 (MyBus)
} /* one instance per partition */
Profiling a Parallel Simulation
Run the simulation by entering a command line with the name of the
master executable (by default named simv) and runtime options. The
syntax for this command line is as follows:
simv -parallel+profile [VCS_runtime_options]
Parallel Profiling Options

If you entered the profile option on the simv command line, Parallel
VCS wrote the data files that the PVCS profiler needs to report on
the parallel simulation.
You start the PVCS profiler with the pvcsProfiler command. Its
syntax is as follows:
Parallel VCS
177
pvcsProfiler [profileDumpDir=simvName.pdaidir]
[doTimeProfiling=1|0] [doToggleProfiling=0|1]
[graphImHeight=integer] [graphImWidth=integer]
[graphTnHeight=integer] [graphTnWidth=integer]
[lowerSimTimeBound=float] [runVersion=string]
[toggleCutOff=float] [upperSimTimeBound=float]
[-help]
These arguments and properties are as follows:
profileDumpDir=simvName.pdaidir
The PVCS profiler writes HTML files that display profile
information about the master and slave simulations. By default
the profiler creates the ppResults_0 directory and writes these
files in this directory.
Use profileDumpDir to specify the directory containing the dump
files that the profiler reads. The directory is the name you specified
for the simulation executable binary file with the extenstion
.pdaidir. The default path name is simv.pdaidir.
doTimeProfiling=1|0
Calculate the time accumulation and produce the graphs. The
default argument is 1. If the argument is 0, the profiler does not
make this calculation or produce the graphs.
doToggleProfiling=0|1
Calculate the partition port toggle counts and produce the high
count listing. The default argument is 1.If the argument is 0, the
profiler does not make this calculation.
graphImHeight=integer
Height of the full size graphs in pixels. The default height is 1000.
graphImWidth=integer
Width of the full size graphs in pixels. The default width is 1000.
graphTnHeight=integer
Height of the thumbnails size graphs in pixels. The default height
is 250.
Parallel VCS
178
graphTnWidth=integer
Width of the thumbnails size graphs in pixels. The default width
is 250.
lowerSimTimeBound=float
A floating point number for the simulation time when profiling
starts. The default argument is 0.0.
runVersion=string
By default the profiler creates the ppResults_0 directory in the
current directory and writes its output HTML files in this directory.
If you want a different name for this directory, enter this property.
With this property the profiler creates the ppResultsstring
directory.
toggleCutOff=float
Specifies that the port toggle count cutoff for a partition is equal
to this percentage of highest toggle count. The default argument
is 1.0.
upperSimTimeBound=float
A floating point number for the simulation time when profiling
stops. The default argument is 1e+100.
-help
Displays the valid properties and their definitions.
Examining the PVCS Profiler Results

The main results file that the profiler writes is named results.html.
By default it writes it in a directory named ppResults_0 in the current
directory. The following is an example of a results.html file (as
viewed in a regular web browser):
Parallel VCS
179
Figure 9-1 results.html File
Click
here to
see
how to
read the
graphs
Click on a graph to see a larger

image of the graph
The results.html file contains four graphs:
• The Processor Segment Totals (graph1.html)

• The Processor Delta Time Totals (graph2.html)
• The S1 Balance Distribution (graph3.html)
• The Active PVCS Features (graph4.html)
Each image in results.html is a hypertext link to an HTML file with
a larger image of the graph.
Parallel VCS
180
There is a link to the howtoInterpretGraphs.html file that explains
how to interpret the graphs.
The following are a series of examples of these graphs that show

different results from the PVCS profiler. The first three graphs are
from a design where the profiler results are good, showing a
balanced design with a good deal of parallelism.
Examples of Good Parallelism

This Processor Segment Totals graph shows that each partition is
doing the same amount of work.
Figure 9-2 A Good Processor Segment Totals Graph
Parallel VCS
181
A delta is a set of events in one or more partitions that cause
subsequent simulation events in other partitions. Figure 9-3 shows
only two deltas, which is good. Delta d0, in which the design
generated the clock signal, and d1, where each partition did its work
in the same delta.
Figure 9-3 A Good Processor Delta Time Totals Graph
In Figure 9-4 the bars are all to the right, indicating good parallelism.
Parallel VCS
182
Figure 9-4 A Good S1 Balance Distribution Graph
Examples of Uneven or Bad Parallelism

The next three graphs are from a design in which the amount of work
done by the partitions is uneven or unbalanced.
Figure 9-5 shows that the partitions are not doing the same amount
of work. Some partitions, as indicated by the dark color at the top of
their bars, are doing a significant amount of waiting for events in
other partitions.
Parallel VCS
183
Figure 9-5 An Uneven Processor Segment Totals Graph
Figure 9-6 shows a small number of deltas, which is good, but also
indicates that the partitions are doing different amounts of work.
Parallel VCS
184
Figure 9-6 An Uneven Processor Delta Time Totals Graph
Figure 9-7 shows that the bars are more to the left, indicating less
parallelism.
Parallel VCS
185
Figure 9-7 An Uneven S1 Balance Distribution
Example of a Design in Need of Clock Signal Analysis

The next four graphs are from a design in need of the clock signal
optimization. Clock signal values propagate from the output of one
partition to the input of another, causing each partition to wait for
events in the other partitions.
Parallel VCS
186
Figure 9-8 Shows that the partitions are doing the same amount of
work, but they are spending much of their time waiting for events in
other partitions.
Figure 9-8 Clock Signals Processor Segment Totals Graph
Figure 9-9 shows Partition A3 has a #1 delay before its activity
Parallel VCS
187
Figure 9-9 Clock Signal Processor Delta Time Totals Graph
Figure 9-10 show workloads are balanced, but partition A3 does

not execute in parallel with A1 and A2.
Parallel VCS
188
Figure 9-10 Clock Signal S1 Balance Distribution
Examples of Worst Case Scenario

The next four graphs are from a design in which the partitions get
their clocks together. Workloads are balanced, but the partitions do
now execute in parallel. This example is slower than a serial run.
Figure 9-11 Shows that the partitions are doing the same amount of
work, but they are spending most of their time waiting for events in
other partitions.
Parallel VCS
189
Figure 9-11 Clock Signals Processor Segment Totals Graph
Figure 9-12 shows that all the work for each partition is done in a
different delta.
Parallel VCS
190
Figure 9-12 Clock Signal Processor Delta Time Totals Graph
Figure 9-13 shows the bars completely to the left, indicating that
there is no parallelism in the design.
Parallel VCS
191
Figure 9-13 Clock Signal S1 Balance Distribution
Running PVCS Examples
Included in your installation is a design example and suite of scripts

that allow you to perform serial / parallel performance comparisons
on your system and profile the results. The tests include:
• A serial run
• A parallel run
Parallel VCS
192
• Profiler runs
- A balanced workload parallel run
- An unbalanced workload parallel run
- A run with a delay in a partition causing one partition not to run
in parallel with the other two partitions
- A run in which a clock is passed from partition to partition
causing non-parallel execution
Please contact VCS Support if you are looking for these examples.
Serial Run Time

The serial run example allows you to view wallclock time for
comparison with the parallel run.
1. Run the script run_serial.csh .

2. Examine DATE.serial for the wallclock time taken for serial
simulation as shown below.
Tue Oct 10 09:59:22 PDT 2006
Tue Oct 10 10:00:45 PDT 2006
Parallel Run Time

The balanced parallel run example allows you to view wallclock time
for comparison with the serial run.
1. Run the script run_balanced.csh .

2. Examine DATE.parallel for the wallclock time taken for parallel
simulation as shown below.
Tue Oct 10 10:13:11 PDT 2006
Parallel VCS
193
Tue Oct 10 10:13:42 PDT 2006
Profiler Runs
Serial Run to Identify Partitions

This is example of a serial run used to identify partitions.
1. The script for the serial profiler run is run_serial_prof.csh .

2. Examine the INSTANCE VIEW section in vcs.prof to see that
instances top.A1, top.A2 and top.A3 are candidates for
partitions, as shown in Figure 9-14.
Figure 9-14 Instance View from a Serial Run
==========================================================
INSTANCE VIEW
==========================================================
Instance %Totaltime
top (1) 100

top.A1 (2) 30
top.A2 (3) 30
top.A3 (4) 30
----------------------------------------------------------
Parallel Runs
+define+BALANCED
This example is the best-case scenario.
1. Run the script run_balanced_prof.csh .

2. Examine the output in the ppResults_balanced directory by
opening the file results.html as shown in Figure 9-15.
Parallel VCS
194
Figure 9-15 Balanced Parallel Run
Partitions receive clocks together. Workloads of the partitions are
balanced and execute in parallel.
Partitions have same amount of activity.
To view details, double-click on a graph in your browser to view the

results in a full-screen.
In this example:
• On the left, the Processor Segment Totals graph shows that each
partition is doing the same amount of work and the partitions
receive their clocks together.
• In he center, the Processor Delta Time Totals Graph shows two
deltas, d0, in which the design generated the clock signal, and d1,
where each partition did its work in the same delta and has the
same amount of activity.
• On the right, the Balance distribution graph shows that workloads
of the partitions are balanced and execute in parallel.
+define+UNBALANCED
In this parallel run unbalanced workloads hinder performance.
Parallel VCS
195
1. Run the script run_unbalanced_prof.csh.
2. Examine the output is in the ppResults_unbalanced directory by
opening the file results.html as shown in Figure 9-16.
Figure 9-16 Unbalanced Parallel Run
Partitions get clocks together. Partitions run in parallel, but
workloads are unbalanced.
Partitions have differing amount of

activity.
In this example:
• The left chart, the Processor Segment Totals graph shows that
the partitions are not doing the same amount of work. Some
partitions are doing a significant amount of waiting for events in
other partitions.
• The center graph, the Processor Delta Time Totals Graph, shows
uneven processor delta time, indicating uneven work distribution
among the partitions.
• On the right, the Balance distribution graph shows that partitions
execute in parallel, but the workloads are unbalanced.
Parallel VCS
196
+define+BALANCED+DELAY
This is an example of a delay in a partition causing one partition not
to run in parallel with the other two partitions.
1. Run the script run_delay_prof.csh.

2. Examine the output is in the ppResults_delay directory by opening
the file results.html. Figure 9-17 shows Partition A3 with a #1
delay before its activity. Hence workloads are balanced, but
partition A3 does not execute in parallel with A1 and A2.
Figure 9-17 A Delay in a Partition
Partitions get clocks together. Partition A3 has a #1 delay before its
activity.
In this example:
each partition is doing the same amount of work but are spends
significant amounts of time waiting for events in other partitions.
Parallel VCS
197
the partitions have the same amount of activity, but they execute
across two deltas
of the partitions are balanced, but partition A3 does not execute
in parallel with A1 and A2.
+define+BALANCED+CLOCK
This is an example of a clock being passed from partition to partition
causing non-parallel execution. This is the worst-case scenario, and
will be slower than the serial run.
1. Run the script run_clock_prof.csh.

2. Examine the output is in the ppResults_clock directory by opening
the file results.html. Figure 9-18 shows the example in which
Partition A2 gets its clock from A1, and A3 gets its clock from A2.
Figure 9-18 A Clock Passed from Partition to Partition
Partitions get clocks together. Workloads are balanced, but none of
A1,A2,A3 execute in parallel.
Parallel VCS
198
In this example:
each partition is doing the same amount of work but are spending
most of the time waiting for events in other partitions.
the partitions have the same amount of activity, but the work for
each partition is done in a different delta.
of the partitions are balanced, but none of the three partitions
execute in parallel.
Supported Platforms
• Linux 32/64bit RH4.0 : Multi-core multi-processor machine.

• Solaris 32 bit: Multi-core Multi-proceesor machine.
Current Limitations
+race
+race is not supported
Partial Elab
This flow is not supported.
SystemVerilog
- Use of SV data types logic and bit types are allowed. Certain
dynamic types are not allowed inside slave partitions.
Parallel VCS
199
VCS-MX
• Only Verilog instances can be added as partitions.
• All VHDL will run in the master partition.
For example, VHDL testbench and Verilog gate-level netlist will
work very well.
VMC, SystemC-C, and AMS
These flows are not supported.
Parallel VCS
200
10
VMM Additions and Enhancements 1
New features and functionality in VMM are described in the following
sections:
• VMM RAL C Interface

• VMM Standard Library Class Additions
• vmm_ral_block_or_sys Base Class Additions
For more information on these features, see the VMM Register
Abstraction Layer User Guide and the VMM User Guide.
VMM Additions and Enhancements

205
VMM RAL C Interface
The RAL C interface allows firmware and application-level code to

be developped and debugged on a simulation of the design.
The fields, registers and memories included in a RAL model can be

accessed in C code through a C API. The C code is executed
natively on the same workstation that is running the SystemVerilog
simulation, eliminating the need for an instruction set simulator or a
RTL model of the processor. The same C code can later be compiled
for the target execution processor.
As illustrated in Figure 10-1, two versions of the RAL C API can be

generated. One is designed to interface to the RAL model running in
the SystemVerilog simulator using the Direct Programming
Interface. The other is pure stand-alone C code and is designed to
be compiled on the target processor in the final application. This
allows the firmware and application-level code to be verified against
a simulation then used, unmodified, in the final application.

206
Figure 10-1 RAL-Generated APIs
Firmware or Application Code
C + SV ralgen C
SV Simulator RALF C Compiler

file
RTL Synthesis H/W
Entry Point
When executing the C code within a simulation, it is necessary for

the C code to be called by the simulation to be executed. To that end,
the application software’s main() routine must be replaced by one
or more entry points known to the simulation.
There are two kinds of entry points: application entry points and
service entry points. Both use the same interface mechanism. They
only differ in their intent and timing of the invocation.
All entry points must take at least one argument that will receive the
base address of the RAL model to be used by the C code. The RAL
model reference is a size_t on the C side The C-side reference is
then used by the RAL C API to access required fields, registers or
memories, as specified in Appendix C.
Entry points must be declared in the $unit scope, typically in the

same file that defines the verification environment, as shown in
Example 10-1. The arguments must require at least one instance of
a block or system base address.

207
Example 10-1 Entry point declaration
‘include "vmm-ral.sv"
import "DPI-C" context task C_func_name(int blk);
The entry point must correspond to a void C function with a

corresponding size_t argument for the base address of the top-
level block or system, as shown in Example 10-2.
Example 10-2 Entry point declaration in C, corresponding to Example 10-1

void C_func_name(size_t blk)
{
...
}
Application Entry Point

An application entry point is invoked only once, at the beginning of
the simulation. It replaces the application’s main() routine that
would normally be automatically invoked by the host operating
system. An application entry point may or may not complete and
return control of the execution thread back to the SystemVerilog
side.
If a simulation contains more than one "application" or if the

application software is fragmented into different functions, the entry
point for each application or application fragment may be called by
the simulation or internally by a top-level entry point.
An application entry point should be invoked by the testcase or

verification environment at a point where the simulated design is
ready to be used by the application software. If the application
software includes (or is) the device configuration firmware, the entry
point should be invoked as the implementation of the cfg_dut()
method, as shown in Example 10-3. If the application software

208
requires a fully functional and configured model of the design, its
entry point should be invoked after the environment has been
started, as shown in Example 10-4. Note how each entry point
invocation is forked to allow for an application software that never
completes.
Example 10-3 Invoking application containing configuration firmware

import "DPI-C" context task appsw(vmm_ral_block blk);
class my_env extends vmm_env;

...
virtual task cfg_dut();
super.cfg_dut();
fork
appsw(this.ral_model.C_addr_of());
join_none
endtask
...
endclass
Example 10-4 Application requiring pre-configured simulation

import "DPI-C" context task appsw(vmm_ral_sys sys);
program test;
tb_env env = new;
initial
begin
env.start();
fork
appsw(env.ral_model.C_addr_of());
join_none
env.run();
end
endprogram

209
Service Entry Point
A service entry point is invoked multiple times, whenever a condition
requiring software servicing is detected. Unlike an application entry
point, a service entry point always returns, at which point it may be
invoked again.
A typical service entry point is the invocation of the interrupt service

code in the application software, as illustrated in Example 10-5.
Notice how its invocation is embedded in a forever loop to ensure
that interrupts will be serviced whenver the tb_top.int signal is
asserted.
Example 10-5 Invoking application containing configuration firmware

import "DPI-C" context task isr(vmm_ral_sys sys);
class my_env extends vmm_env;

...
virtual task start();
super.start();
fork
forever begin
wait (tb_top.int === 1’b1);
isr(this.ral_model);
end
join_none
endtask
...
endclass
Execution Timeline
When executing with a simulation of the design, all C code executes

atomically. It is unlike the real application code running as object
code on a real processor, where the execution of the code happens
concurrently with other processing in the neighboring hardware.

210
When C code executes, only that code performs any form of
processing and the simulation of the rest of the design is frozen. The
only way for the design simulation to proceed, is for the C code to
return, or for the C code to perform a read or write operation through
the RAL model. In the latter case, once the read or write operation
completes and the control is returned back to the C code, the
simulation is again frozen.
This execution timeline is illustrated in Figure 10-2. The entire

execution timeline in the C code occurs in zero-time in the simulation
timeline. The execution timeline is the cause of the important impact
on run-time performance of how the C code interacts with the design.
Figure 10-2 C code and Simulated Design Execution Timeline
C Code
Simulation (read) (write) t
If a polling strategy is used, the simulation will have the opportunity

to advance only during the execution of the repeated polling read
cycles. It would likely require many hundreds of such read cycles for
the design to reach a state that is relevant and significant for the
application software. With physical device, that is not an issue as this
can happens in less than a microsecond. But in a simulation, this
would require a lot of processing for simulating essentially useless
read cycles and exchanging data between the C world and the
simulation world.
If an interrupt-driven strategy is used, the simulation will proceed

until something of interest to the application software has happened
before transfering the control to the C code (through a service entry

211
point) and only the necessary read and write operations would need
to be performed. It is thus important that a service-based approach
be used as much as possible.
It is also very important that the execution of the C code not be

blocked by an external event—such as waiting for user input or a file
to be unlocked—as it will prevent the simulation from moving forward
while it is blocked. If the application software requires such
synchronization, it should similarly use an asynchronous service-
driven approach.
Writing Firmware Code
The RAL C API is designed to ultimately yield compact and efficient

firmware code, while preserving as much as possible the abstraction
offered by the RAL model. To that effect, the RAL C API hides the
physical addresses of registers and the position and size of fields.
The hiding is performed by functions and macros rather than an
object-oriented structure like the native RAL model in SystemVerilog
This is to eliminate the need to compile a complete object-oriented
model in an embedded processor object code with limited amount of
memory.
Figure 10-3 Example register layout

31 11 5 0
0x........0100 a2 X a1 R1
0x........0104 a2 6
29
0x........0108 Y R2
0x........010C a1
0x........0110 a1 R3
Example 10-6 Example RALF specification

block myblk {

212
bytes 4;
endian big;
register R1 @0x0100 {
bytes 4;
field a1 { bits 4; access rw; }
field X { bits 7; access rw; }
}
register R2 @0x104 {
bytes 12;
field Y @32 { bits 7; access rw; }
field a2 @64 { bits 30; access rw; }
}
register R3 @0x110{
bytes 4;
}
memory m {
bits 32
size 1024
}
}
Accessing Registers
Ideally, registers and memories should be of the same size as the
native data bus size of the target process—typically the int type in the
C code—and thus live at a single physical address (called
"segment"). This allows each register to be accessed or updated
using a single read or write operation. The RAL C interface supports
single-segment as well as multi-segment registers.
Registers can be accessed using the ral_read_<reg>_in_<block>

and ral_write_<reg>_in_<block> macros. Example 10-7 shows a
single-segment, such as register R1 specified in Figure 10-3, would
be accessed.
Example 10-7 Accessing single-segment register from C

void C_func_name(void* blk)

213
{
unsigned int r1 = 0xABCD;
ral_write_R1_in_myblk(blk, &r1);
r1 = 0;
ral_read_R1_in_myblk(blk, &r1);
}
If a register spans multiple physical locations, such as register R2 in

Figure 10-3, the entire register can be accessed using the same
macros but by using an array of int with one element per physical
location, as shown in Example 10-8.
Example 10-8 Accessing an entire multi-address register

int r2[3];
r2 = {0xABCD, 0x1234, 0x5678};
ral_write_R2_in_myblk(blk, r2);
r2 = {0x0, 0x0, 0x0};
ral_read_R2_in_myblk(blk, r2);
Endian Support
The RAL C interface always read multi-segment registers into the
'int' array ('r2' in Example 10-8) in little-endian order, irrespective of
their actual hardware layout as specified in the RALF file. This
means that the segments of a multi-segment register in a big-endian
block or system will be in the reverse order in the C int array. RAL
models that use FIFO ordering are not supported.
Accessing Fields
Individual fields can be accessed using the corresponding
ral_read_<field>_in_<block>_<reg> and
ral_write_<field>_in_<block>_<reg> macros. If the field has a
unique name in its enclosing block, then there will also be macros
named ral_read_<field>_in_<block> and
ral_write_<field>_in_<block> with identical respective functionality

214
as the previous set of macros. Example 10-9 and Example 10-
10shows how the field named X, as illustrated in Figure 10-3, would
be accessed.
Example 10-9 Accessing a block-unique field

unsigned int x = 0x0F;
ral_write_X_in_myblk(blk, &x);
x = 0;
ral_read_X_in_myblk(blk, &x);
Example 10-10 Accessing field in a specific register

unsigned int x = 0x0F;
ral_write_X_in_myblk_R1(ral_addr_of_R1_in_myblk(blk), &x);
x = 0;
ral_read_X_in_myblk_R1(ral_addr_of_R1_in_myblk(blk), &x);
Currently, fields with a size greater than sizeof(int) and fields

spanning multiple physical addresses are not supported. If larger
fields are required, or fields need to span more than one physical
address, it will be necessary access them using the multi-segment
register access procedures and the resulting array-of-int value.
Accessing Memories
Memories can be accessed using the ral_read_<mem>_in_<block>
and ral_write_<mem>_in_<block> macros. Example 10-11 shows
how to read and write a memory location, offset 0x100 of memory 'm'
specified in Example 10-6.
Example 10-11 Accessing a single-segment memory location

unsigned int mem_loc = 0xAABBCCDD;
ral_write_m_in_myblk(blk, 0x100, &mem_loc);
mem_loc = 0;
ral_read_m_in_myblk(blk, 0x100, &mem_loc);

215
Note that a multi-segment memory location would be accessed
using the same macro. The only difference is that a suitably sized
array of int would need to be supplied to hold the memory location
value to be read or written.
VMM Standard Library Class Additions
Classes and members that have been added to the VMM Standard
Library are described in the following sections:
• vmm_opts
• vmm_scenario
• vmm_object
• vmm_ms_scenario_gen
• vmm_xactor_iter
• vmm_test
• vmm_channel

216
vmm_opts
This class provides an interface to define and access run-time

options. Run-time options can be specified using a combination of
command-line arguments and option files specified using a plus-
seperated list of filenames to the "+vmm_opts_file=" command-line
option.
Command-line options can be specified using a plus-separated list

of run-time options to the +vmm_opts command-line option, or as
separate command-line options prefixed with "+vmm_". Using the
former is preferable as a warning will be issued if an unknown option
is specified.
No constructor is documented because this class is implemented

using a singleton pattern. Its functionality is accessed strictly through
static methods.
Summary
• vmm_opts::get_bit()
• vmm_opts::get_int()
• vmm_opts::get_string()
• vmm_opts::get_help()

217
vmm_opts::get_bit()
Get a boolean option value.
SystemVerilog
static function bit get_bit(string name, string doc = "");
Description
Return TRUE if the specified option name was specified. Returns
FALSE otherwise.
The boolean run-time option "foo" would be supplied using the

"+vmm_opts+...+foo+..." command-line option, or "+vmm_foo"
command-line option, or the line "+foo" in the option file.
The "doc" argument is a short description of the run-time argument

that will be displayed by the vmm_opts::get_help() method. If it has
been previsouly defined for the specified option through a prior call
of this method, the documentation is not redefined.

218
vmm_opts::get_int()
Get an integer option value.
SystemVerilog
static function int get_int(string name,
int dflt = 0,
string doc = "");
Description
Returns the integer value specified as the argument of the specified
run-time option. If the run-time option was not supplied, returns the
specified default value. Different calls specifying the same option
may have different default values.
The integer value "5" for run-time option "foo" would be supplied
using the "+vmm_opts+...+foo=5+..." command-line option, or
"+vmm_foo=5" command-line option, or the line "+foo=5" in the
option file.


219
vmm_opts::get_string()
Get a string option value.
SystemVerilog
static function string get_string(string name,
string dflt = "",
string doc = "");
Description
Returns the string value specified as the argument of the specified
run-time option. If the run-time option was not supplied, returns the
specified default value. Different calls specifying the same option
may have different default values.
The string value "bar" for run-time option "foo" would be supplied
using the "+vmm_opts+...+foo=bar+..." command-line option, or
"+vmm_foo=bar" command-line option, or the line "+foo=bar" in the
option file.


220
vmm_opts::get_help()
Display a list of all known run-time options.
SystemVerilog
static function void get_help();
Description
Display a human-readable list of all run-time options queried so far.
This method is automatically called, followed by a call to $finish(), by

the vmm_env::reset_dut() method if the +vmm_help command-line
option is supplied.
Examples
Example 10-12
virtual task tb_env::start();
super.start();
if ($test$plusargs("tb_help")) begin
vmm_opts::get_help();
$finish;
end
...
endtask

221
vmm_scenario
Base class for all user-defined scenarios. This class extends from
vmm_data.
Summary
• vmm_scenario::stream_id
• vmm_scenario::scenario_id
• vmm_scenario::scenario_kind
• vmm_scenario::length
• vmm_scenario::repeated
• vmm_scenario::repeat_thresh
• vmm_scenario::repetition
• vmm_scenario::define_scenario()
• vmm_scenario::redefine_scenario()
• vmm_scenario::scenario_name()
• vmm_scenario::psdisplay()
• vmm_scenario::set_parent_scenario()
• vmm_scenario::get_parent_scenario()

222
vmm_scenario::stream_id
Stream identifier of the randomizing generator.
SystemVerilog
int stream_id
Description
This data member is set by the scenario generator before
randomization to the generator’s stream identifier. This state variable
can be used to specifiy stream-specific constraints or to differentiate
stimulus from different streams in a scoreboard.

223
vmm_scenario::scenario_id
Scenario identifier of the randomizing generator.
SystemVerilog
int scenario_id
Description
This data member is set by the scenario generator before
randomization to the generator’s current scenario counter value.
This state variable can be used to specifiy scenario-specific
constraints or to identify the order of different scenarios within a
stream.

224
vmm_scenario::scenario_kind
Scenario kind identified.
SystemVerilog
rand int unsigned scenario_kind
Description
Used to randomly select one of the scenario kinds defined in this
random scenario descriptor.

225
vmm_scenario::length
Length of the scenario.
SystemVerilog
rand int unsigned length
Description
Random number of transaction descriptor in this random scenario.
Constrained to be less than or equal to the maximum number of
transactions in the selected scenario kind.

226
vmm_scenario::repeated
Scenario identifier of the randomizing generator.
SystemVerilog
rand int unsigned repeated
Description
The number of time the entire scenario is repeated. A repetition
value of zero specifies that the scenario will not be repeated, hence
will be applied only once.
Constrained to zero by default by the “vmm_scenario::repetition”

constraint block.
Note that is is best to repeat the same transaction instead of creating

a scenario of many transactions constrained to be identical.

227
vmm_scenario::repeat_thresh
Repetition warning threshold.
SystemVerilog
static int unsigned repeat_thresh
Description
Specifies a threshold value that triggers a warning about possibly
unconstrained “vmm_scenario::repeated”data member. Defaults to
100.

228
vmm_scenario::repetition
Constraint preventing the scenario from being repeated.
SystemVerilog
constraint repetition {
repeated == 0;
}
Description
The “vmm_scenario::repeated” data member specifies the number
of times a scenario is repeated. It is not often used but, if left
unconstrained, can cause stimulus to be erroneously repeatedly
applied over 2 billion times on average.
This constraint block constrains this data member to prevent

repetition by default. To have a scenario be repeated a random
number of times, simply override this constraint block.
Examples
Example 10-13
class many_atomic_scenario
extends eth_frame_atomic_scenario;
constraint repetition {
repeated < 10;
}
endclass

229
vmm_scenario::define_scenario()
Define a new scenario kind.
SystemVerilog
function int unsigned define_scenario(string name,
int unsigned max_len);
Description
Defines a new scenario kind included in this scenario descriptor and
return a unique scenario kind identifier. The
“vmm_scenario::scenario_kind”data member will randomly select
one of the defined scenario kinds. The new scenario kind may have
up to the specified number of random transactions.
The scenario kind identifier should be stored in a state variable that

can then be subsequently used to specified kind-specific constraints.

230
vmm_scenario::redefine_scenario()
Redefine an existing scenario kind.
SystemVerilog
function void redefine_scenario(int unsigned scenario_kind,
string name,
int unsigned max_len);
Description
Redefines an existing scenario kind included in this scenario
descriptor. The scenario kind may be redefined with a different name
or maximum number of random transactions.
Use this method to modify, refine or replace an existing scenario kind

in a pre-defined scenario descriptor.

231
vmm_scenario::scenario_name()
Name of a scenario kind.
SystemVerilog
function string scenario_name(int unsigned scenario_kind);
Description
Return the name of the specified scenario kind, as defined by the
“vmm_scenario::define_scenario()” or
“vmm_scenario::redefine_scenario()” methods.

232
vmm_scenario::psdisplay()
Create an image of the scenario descriptor.
SystemVerilog
virtual function string psdisplay(string prefix = "")
Description
Create human-readable image of the content of the scenario
descriptor.

233
vmm_scenario::set_parent_scenario()
Define higher-level hierarchical scenario.
SystemVerilog
function void set_parent_scenario(
vmm_scenario parent)
Description
Specify the single stream or multiple-stream scenario that is the
parent of this scenario. This will allow this scenario to grab a channel
that has already been grabbed by the parent scenario.

234
vmm_scenario::get_parent_scenario()
Get the higher-level hierarchical scenario.
SystemVerilog
function vmm_scenario get_parent_scenario()
Description
Get the single stream or multiple-stream scenario that was specified
as the parent of this scenario. A scenario with no parent is a top-level
scenario.

235
vmm_object
The vmm_object class is an optional common base class for the

vmm_data, vmm_scenario, vmm_ms_scenario, vmm_channel,
vmm_notify, vmm_xactor, vmm_subenv, vmm_env,
vmm_consensus and vmm_test classes.
This option is enabled by loading the customization definitions files

as follows:
% vcs ... \
+define+VMM_PRE_INCLUDE=$VMM_HOME/sv/std_lib/opt/vmm_object.svh \
+define_VMM_POST_INCLUDE=$VMM_HOME/sv/std_lib/opt/vmm_object.sv \
...
% vcs ... \
+define+VMM_PRE_INCLUDE=$VCS_HOME/etc/rvm/sv/std_lib/opt/vmm_object.svh \
+define_VMM_POST_INCLUDE=$VCS_HOME/etc/rvm/sv/std_lib/opt/vmm_object.sv \
...
Summary
• vmm_object::type_e
• vmm_object::new
• vmm_object::set_parent()
• vmm_object::get_parent()
• vmm_object::get_type()
• vmm_object::get_hier_inst_name()
• vmm_object::display()
• vmm_object::psdisplay()

236
vmm_object::type_e
Type of this object.
SystemVerilog
typedef enum {
VMM_UNKNOWN, VMM_OBJECT, VMM_DATA, VMM_SCENARIO,
VMM_MS_SCENARIO, VMM_CHANNEL, VMM_NOTIFY, VMM_XACTOR,
VMM_SUBENV, VMM_ENV, VMM_CONSENSUS, VMM_TEST
} type_e
Description
Value returned by the “vmm_object::type_e”method to identify the
type of this vmm_object extension. Once the type is known, a
reference to a vmm_object can be cast into the corresponding class
type.
The VMM_UNKNOWN type is an internal value and never returned

by the “vmm_object::type_e”method.
The VMM_OBJECT is returned when the type of the object cannot

be determined, or to specify any object type to the
“vmm_object::type_e”method.

237
vmm_object::new
Constructor.
SystemVerilog
function new(vmm_object parent = NULL);
Description
Optionally specify a parent object to this object when constructing a
vmm_object instance. See “vmm_object::type_e” for more details on
specifying a parent object.

238
vmm_object::set_parent()
Specify a parent object.
SystemVerilog
function void set_parent(vmm_object parent);
Description
Specify a new parent object to this object. Specifying a NULL parent
breaks the any current parent/child relationship. An object may have
only one parent, but the identity of a parent can be changed
dynamically.
If this object and the parent object are known to contain their own
instance of the message service interface, the vmm_log instance in
the parent is specified as being above the vmm_log instance in the
chil by calling parent.is_above(this). The instance names of the
message service interfaces can then be subsequently made
hierarchical by using the “vmm_log::use_hier_inst_name()” method.
The presence of the vmm_object base class being optional, it is not

possible to call this method in code designed to be reusable with and
without this base class. To that effect, the
‘VMM_OBJECT_SET_PARENT(_parent, _child) macro should be
used instead. This macro will call this method if the vmm_object
base class is present but do nothing if not.
Examples
Example 10-14
this.notify = new(this.log);

239
this.notify.set_parent(this);
Example 10-15
this.notify = new(this.log);
‘VMM_OBJECT_SET_PARENT(this.notify, this)

240
vmm_object::get_parent()
Get a parent object.
SystemVerilog
function vmm_object get_parent(
vmm_object::type_e typ = VMM_OBJECT);
Description
Return the parent object of the specified type, if any. Returns NULL
if no such parent is found. Specifying VMM_OBJECT returns the
immediate parent of any type.

241
vmm_object::get_type()
Get the type of the object.
SystemVerilog
function vmm_object::type_e get_type();
Description
Return the type of this vmm_object extension.
Returns VMM_OBJECT if it is not one of the known VMM class

extensions. VMM_UNKNOWN is purely an internal value and is
never returned.

242
vmm_object::get_hier_inst_name()
Get the hierarchical instance name of the object.
SystemVerilog
function string get_hier_inst_name();
Description
Return the hierarchical instance name of the object. The instance
name is composed of the dot-separated instance names of the
message service interface of all the parents of the object.
The hierarchical name is return whether or not the message services

interfaces are using hierarchical or flat names.

243
vmm_object::display()
Display a description of the object to stdout
SystemVerilog
virtual function void display(string prefix = "");
Description
Display the image returned by “vmm_object::type_e”to the standard
output.
If this method conflicts with a previously declared method in a class

now based on the vmm_object class, it can be removed by defining
the ‘VMM_OBJECT_NO_DISPLAY symbol at compile-time.

244
vmm_object::psdisplay()
Create a description of the object
SystemVerilog
virtual function string psdisplay(string prefix = "");
Description
Creates a human-readable image of the content of the object and
returns it as a string. Each line of the image is prefixed with the
specified prefix. The description should not contain a final newline
character.
If this method conflicts with a previously declared method in a class

now based on the vmm_object class, it can be removed by defining
the ‘VMM_OBJECT_NO_DISPLAY symbol at compile-time.

245
vmm_ms_scenario_gen
This class is a pre-defined multi-stream scenario generator.
The following methods are available. See Xref for guidelines on how
the multi-stream scenario generator can be used and how multi-
stream scenarios—including hierarchical scenarios—are defined
and executed.
Summary
• vmm_ms_scenario_gen::stop_after_n_scenarios
• vmm_ms_scenario_gen::inst_count
• vmm_ms_scenario_gen::scenario_count
• vmm_ms_scenario_gen::inst_count
• vmm_ms_scenario_gen::get_n_scenarios()
• vmm_ms_scenario_gen::get_n_insts()
• vmm_ms_scenario_gen::GENERATED
• vmm_ms_scenario_gen::DONE
• vmm_ms_scenario_gen::register_ms_scenario()
• vmm_ms_scenario_gen::ms_scenario_exists()
• vmm_ms_scenario_gen::get_ms_scenario()
• vmm_ms_scenario_gen::get_ms_scenario_name()
• vmm_ms_scenario_gen::get_ms_scenario_index()
• vmm_ms_scenario_gen::get_names_by_ms_scenario()
• vmm_ms_scenario_gen::get_all_ms_scenario_names()
• vmm_ms_scenario_gen::replace_ms_scenario()
• vmm_ms_scenario_gen::unregister_ms_scenario()
• vmm_ms_scenario_gen::unregister_ms_scenario_by_name()
• vmm_ms_scenario_gen::select_scenario
• vmm_ms_scenario_gen::scenario_set[$]
• vmm_ms_scenario_gen::register_channel()
• vmm_ms_scenario_gen::channel_exists()
• vmm_ms_scenario_gen::get_channel()
• vmm_ms_scenario_gen::get_channel_name()
• vmm_ms_scenario_gen::get_names_by_channel()
• vmm_ms_scenario_gen::get_all_channel_names()
• vmm_ms_scenario_gen::replace_channel()
• vmm_ms_scenario_gen::unregister_channel()
• vmm_ms_scenario_gen::unregister_channel_by_name()
• vmm_ms_scenario_gen::register_ms_scenario_gen()
• vmm_ms_scenario_gen::ms_scenario_gen_exists()
• vmm_ms_scenario_gen::get_ms_scenario_gen()
• vmm_ms_scenario_gen::get_ms_scenario_gen_name()
• vmm_ms_scenario_gen::get_all_ms_scenario_gen_names()
• vmm_ms_scenario_gen::replace_ms_scenario_gen()
• vmm_ms_scenario_gen::unregister_ms_scenario_gen()
• vmm_ms_scenario_gen::unregister_ms_scenario_gen_by_name()

246
vmm_ms_scenario_gen::stop_after_n_scenarios
Number of multi-stream scenarios to generate.
SystemVerilog
int unsigned stop_after_n_scenarios
Description
Automatically stop the multi-stream scenario generator when the
number of generated multi-streams scenarios reaches or surpasses
the specified value. A value of zero specifies an infinite number of
multi-stream scenarios.
Only the multi-stream scenarios explicitly executed by this instance

of the multi-stream scenario generator are counted. Sub-scenarios
executed as part of a higher-level multi-stream scenario are not
counted.

247
vmm_ms_scenario_gen::stop_after_n_insts
Number of transaction descriptor to generate.
SystemVerilog
int unsigned stop_after_n_insts
Description
Automatically stop the multi-stream scenario generator when the
number of generated transaction descriptors reaches or surpasses
the specified value. A value of zero indicates an infinite number of
transaction descriptors.
The number of transaction descriptor instances generated by the

execution of a multi-stream scenario is the number of transactions
reported by the vmm_ms_scenario::execute() method when it
returns. Entire scenarios are executed before the generator is
stopped so the actual number of transaction descriptors generated
may be greater than the specified value.

248
vmm_ms_scenario_gen::scenario_count
Number of multi-stream scenarios generated so far.
SystemVerilog
protected int scenario_count;
Description
Current count of the number of top-level multi-stream scenarios
generated the multi-stream scenario generator. When is reaches or
surpasses the value in
vmm_ms_scenario_gen::stop_after_n_scenarios, the generator
stops.
Only the multi-stream scenarios explicitly executed by this instance

of the multi-stream scenario generator are counted. Sub-scenarios
executed as part of a higher-level multi-stream scenario are not
counted.

249
vmm_ms_scenario_gen::inst_count
Number of transaction descriptor generated so far.
SystemVerilog
protected int inst_count;
Description
Current count of the number of individual transaction descriptor
instances generated by the multi-stream scenario generator. When
is reaches or surpasses the value in
vmm_ms_scenario_gen::stop_after_n_insts, the generator stops.
The number of transaction descriptor instances generated by the

execution of a multi-stream scenario is the number of transactions
reported by the vmm_ms_scenario::execute() method when it
returns.

250
vmm_ms_scenario_gen::get_n_scenarios()
Number of multi-stream scenarios generated so far.
SystemVerilog
function int unsigned get_n_scenarios()
Description
Return the current value of the
vmm_ms_scenario_gen::scenario_count property.

251
vmm_ms_scenario_gen::get_n_insts()
Number of transaction descriptors generated so far.
SystemVerilog
function int unsigned get_n_insts()
Description
Return the current value of the vmm_ms_scenario_gen::inst_count
property.

252
vmm_ms_scenario_gen::GENERATED
Notification of a newly generated scenario.
SystemVerilog
typedef enum int {GENERATED} symbols_e
Description
Notification in vmm_xactor::notify that is indicated every time a new
multi-stream scenario is generated and about to be executed.

253
vmm_ms_scenario_gen::DONE
Notification of a generation completed.
SystemVerilog
typedef enum int {DONE} symbols_e
Description
Notification in vmm_xactor::notify that is indicated when the
generation process has completed as specified by the
scenvmm_ms_scenario_gen::stop_after_n_scenarios and
vmm_ms_scenario_gen::stop_after_n_insts class properties.

254
vmm_ms_scenario_gen::register_ms_scenario()
Register a multi-strea, scenario descriptor
SystemVerilog
virtual function void register_ms_scenario(string name,
vmm_ms_scenario scenario)
Description
Registers the specified multi-stream scenario under the specified
name. The same scenario may be registered multiple times under
different names, thus creating an alias to the same scenario.
Registering a scenario implicitly appends it to the scenario set if it is

not already in the vmm_ms_scenario_gen::scenario_set[$] array.
It is an error to attempt to register a scenario under a name that

already exists. Use vmm_ms_scenario_gen::replace_ms_scenario()
to replace a registered scenario.

255
vmm_ms_scenario_gen::ms_scenario_exists()
Checks if a scenario is registered under a specified name
SystemVerilog
virtual function bit ms_scenario_exists(string name)
Description
Returns TRUE if there is a multi-stream scenario registered under
the specified name. Returns FALSE otherwise.
Use vmm_ms_scenario_gen::get_ms_scenario() to retrieve a

scenario under a specified name.

256
vmm_ms_scenario_gen::get_ms_scenario()
Get the scenario registered under a specified name
SystemVerilog
virtual function vmm_ms_scenario get_ms_scenario(
string name)
Description
Returns the multi-stream scenario descriptor registered under the
specified name. Issues a warning message and returns NULL if
there are no scenarios registered under that name.

257
vmm_ms_scenario_gen::get_ms_scenario_name()
Get a name under which a scenario is registered
SystemVerilog
virtual function string get_names_by_ms_scenario(
Description
Returns a name under which the specified multi-stream scenario
descriptor is registered. Returns "" if the scenario is not registered.

258
vmm_ms_scenario_gen::get_ms_scenario_index()
Get the index of the specified scenario
SystemVerilog
virtual function int get_ms_scenario_index(
Description
Returns the index of the specified scenario descriptor in the
vmm_ms_scenario_gen::scenario_set[$] array. A warning message
is issued and returns -1 if the scenario descriptor is not found in the
scenario set.

259
vmm_ms_scenario_gen::get_names_by_ms_scenario(
)
Get the names under which a scenario is registered
SystemVerilog
virtual function int get_names_by_ms_scenario(
vmm_ms_scenario scenario,
ref string name[$])
Description
Appends the names under which the specified multi-stream scenario
descriptor is registered. Returns the number of names that were
added to the array.

260
vmm_ms_scenario_gen::get_all_ms_scenario_names(
)
Get all the names in the scenario registry
SystemVerilog
virtual function int get_all_ms_scenario_names(
ref string name[$])
Description
Appends the names under which a multi-stream scenario descriptor
is registered. Returns the number of names that were added to the
array.

261
vmm_ms_scenario_gen::replace_ms_scenario()
Replace a scenario descriptor
SystemVerilog
virtual function void replace_ms_scenario(string name,
Description
Registers the specified multi-stream scenario under the specified
name, replacing the scenario previously registered under that name
(if any). The same scenario may be registered multiple times under
different names, thus creating an alias to the same scenario.
Registering a scenario implicitly appends it to the scenario set if it is

not already in the vmm_ms_scenario_gen::scenario_set[$] array.
The replaced scenario is removed from
vmm_ms_scenario_gen::scenario_set[$] if it is not also registered
under another name.

262
vmm_ms_scenario_gen::unregister_ms_scenario()
Unregister a scenario descriptor
SystemVerilog
virtual function bit unregister_ms_scenario(
Description
Completely unregisters the specified multi-stream scenario
descriptor and returns TRUE if it exists in the registry. The
unregistered scenario is also removed from the
vmm_ms_scenario_gen::scenario_set[$] array.

263
vmm_ms_scenario_gen::unregister_ms_scenario_by_
name()
Unregister a scenario descriptor
SystemVerilog
virtual function vmm_ms_scenario unregister_ms_scenario(
string name)
Description
Unregisters the multi-stream scenario under the specified name and
returns the unregistered scenario descriptor. Returns NULL if there
is no scenario registered under the specified name.
The unregistered scenario descriptor is removed from

vmm_ms_scenario_gen::scenario_set[$] if it is not also registered
under another name.

264
vmm_ms_scenario_gen::select_scenario
Scenario selection factory
SystemVerilog
vmm_ms_scenario_election select_scenario
Description
Randomly select the next multi-stream scenario to execute from the
vmm_ms_scenario_gen::scenario_set[$] array. The selection is
performed by calling randomize() on this class property then
executing the multi-stream scenario found in the
vmm_ms_scenario_gen::scenario_set[$] array at the index specified
by the vmm_ms_scenario_election::select class property.
The default election instance may be replaced by a user-defined

extension to modify the scenario election policy.

265
vmm_ms_scenario_gen::scenario_set[$]
Multi-stream scenarios available for execution
SystemVerilog
vmm_ms_scenario scenatio_set[$]
Description
Multi-stream scenarios available for execution by this generator. The
scenario executed next is selected by randomizing the
vmm_ms_scenario_gen::select_scenario class property.
Multi-stream scenario instances in this array should be managed

through the vmm_ms_scenario_gen::register_ms_scenario(),
vmm_ms_scenario_gen::replace_ms_scenario() and
vmm_ms_scenario_gen::unregister_ms_scenario() methods.

266
vmm_ms_scenario_gen::register_channel()
Register an output channel
SystemVerilog
virtual function void register_channel(string name,
vmm_channel chan)
Description
Registers the specified output channel under the specified logical
name. The same channel may be registered multiple times under
different names, thus creating an alias to the same channel.
Once registered, the output channel becomes available under the

specified logical name to multi-stream scenarios via the
vmm_ms_scenario::get_channel() method.
It is an error to attempt to register a channel under a name that

already exists. Use vmm_ms_scenario_gen::replace_channel() to
replace a registered scenario.

267
vmm_ms_scenario_gen::channel_exists()
Checks if a channel is registered under a specified name
SystemVerilog
virtual function bit channel_exists(string name)
Description
Returns TRUE if there is an output channel registered under the
specified name. Returns FALSE otherwise.
Use vmm_ms_scenario_gen::get_channel() to retrieve a channel

under a specified name.

268
vmm_ms_scenario_gen::get_channel()
Get the channel registered under a specified name
SystemVerilog
virtual function vmm_channel get_channel(
string name)
Description
Returns the output channel registered under the specified name.
Issues a warning message and returns NULL if there are no
channels registered under that name.

269
vmm_ms_scenario_gen::get_channel_name()
Get a name under which a channel is registered
SystemVerilog
virtual function string get_names_by_channel(
vmm_channel chan)
Description
Return a names under which the specified channel is registered.
Returns "" if the channel is not registered.

270
vmm_ms_scenario_gen::get_names_by_channel()
Get the names under which a channel is registered
SystemVerilog
virtual function int get_names_by_channel(
vmm_channel chan,
ref string name[$])
Description
Appends the names under which the specified output channel is
registered. Returns the number of names that were added to the
array.

271
vmm_ms_scenario_gen::get_all_channel_names()
Get all the names in the channel registry
SystemVerilog
virtual function int get_all_channel_names(
ref string name[$])
Description
Appends the names under which an output channel is registered.
Returns the number of names that were added to the array.

272
vmm_ms_scenario_gen::replace_channel()
Replace an output channel
SystemVerilog
virtual function void replace_channel(string name,
vmm_channel chan)
Description
Registers the specified output channel under the specified name,
replacing the channel previously registered under that name (if any).
The same channel may be registered multiple times under different
names, thus creating an alias to the same output channel.

273
vmm_ms_scenario_gen::unregister_channel()
Unregister an output channel
SystemVerilog
virtual function bit unregister_channel(
vmm_channel chan)
Description
Completely unregisters the specified output channel and returns
TRUE if it exists in the registry.

274
vmm_ms_scenario_gen::unregister_channel_by_nam
e()
Unregister an output channel
SystemVerilog
virtual function vmm_channel unregister_channel(
string name)
Description
Unregisters the output channel under the specified name and returns
the unregistered channel. Returns NULL if there is no channel
registered under the specified name.

275
vmm_ms_scenario_gen::register_ms_scenario_gen()
Register a sub-generator
SystemVerilog
virtual function void register_ms_scenario_gen(string name,
vmm_ms_scenario_gen gen)
Description
Registers the specified sub-generator under the specified logical
name. The same generator may be registered multiple times under
different names, thus creating an alias to the same generator.
Once registered, the multi-stream generator becomes available

under the specified logical name to multi-stream scenarios via the
vmm_ms_scenario::get_ms_scenario() method to create
hierarchical multi-stream scenarios.
It is an error to attempt to register a generator under a name that

already exists. Use
vmm_ms_scenario_gen::replace_ms_scenario_gen() to replace a
registered generator.

276
vmm_ms_scenario_gen::ms_scenario_gen_exists()
Checks if a generator is registered under a specified name
SystemVerilog
virtual function bit ms_scenario_gen_exists(string name)
Description
Returns TRUE if there is a sub-generator registered under the
specified name. Returns FALSE otherwise.
Use vmm_ms_scenario_gen::get_ms_scenario_gen() to retrieve a

sub-generator under a specified name.

277
vmm_ms_scenario_gen::get_ms_scenario_gen()
Get the sub-generator registered under a specified name
SystemVerilog
virtual function vmm_ms_scenario_gen get_ms_scenario_gen(
string name)
Description
Returns the sub-generator registered under the specified name.
Issues a warning message and returns NULL if there are no
generators registered under that name.

278
vmm_ms_scenario_gen::get_ms_scenario_gen_name(
)
Get a names under which a generator is registered
SystemVerilog
virtual function string get_names_by_ms_scenario_gen(
Description
Returns a names under which the specified sub-generator is
registered. Returns "" if the generator is not registered.

279
vmm_ms_scenario_gen::get_names_by_ms_scenario
_gen()
Get the names under which a generator is registered
SystemVerilog
virtual function int get_names_by_ms_scenario_gen(
vmm_ms_scenario_gen gen,
ref string name[$])
Description
Appends the names under which the specified sub-generator is
registered. Returns the number of names that were added to the
array.

280
vmm_ms_scenario_gen::get_all_ms_scenario_gen_na
mes()
Get all the names in the generator registry
SystemVerilog
virtual function int get_all_ms_scenario_gen_names(
ref string name[$])
Description
Appends the names under which a sub-generator is registered.
Returns the number of names that were added to the array.

281
vmm_ms_scenario_gen::replace_ms_scenario_gen()
Replace a sub-generator
SystemVerilog
virtual function void replace_ms_scenario_gen(string name,
Description
Registers the specified sub-generator under the specified name,
replacing the generator previously registered under that name (if
any). The same generator may be registered multiple times under
different names, thus creating an alias to the same sub-generator.

282
vmm_ms_scenario_gen::unregister_ms_scenario_gen
()
Unregister a sub-generator
SystemVerilog
virtual function bit unregister_ms_scenario_gen(
Description
Completely unregisters the specified sub-generator and returns
TRUE if it exists in the registry.

283
vmm_ms_scenario_gen::unregister_ms_scenario_gen
_by_name()
Unregister a sub-generator
SystemVerilog
virtual function vmm_ms_scenario_gen
unregister_ms_scenario_gen(
string name)
Description
Unregisters the generator under the specified name and returns the
unregistered generator. Returns NULL if there is no generator
registered under the specified name.

284
vmm_xactor_iter
This class can iterate over all known vmm_xactor instances, based
on the names and instance names, regardless of their location in the
class hierarchy.
Summary
• vmm_xactor_iter::new()
• vmm_xactor_iter::first()
• vmm_xactor_iter::xactor()
• vmm_xactor_iter::next()

285
vmm_xactor_iter::new()
Create a new transactor iterator.
SystemVerilog
function void new(string name = "/./",
string inst = "/./");
Description
Create a new transactor iterator and initialize it using the specified
name and instance name. If the specified name or instance name is
enclosed between ’/’ characters, their are interpreted as regular
expressions. Otherwise, they are interpreted as the full name or
instance name to match.
“vmm_xactor_iter::first()”is implicitly called. So once created, the first

transactor matching the specified name and instance name patterns
is available using the “vmm_xactor_iter::xactor()” method. The
subsequent transactors can be iterated on, one at a time, using the
“vmm_xactor_iter::next()” method.
Examples
Example 10-16
vmm_xactor_iter iter = new("/AHB/");
while (iter.xactor() != null) begin
ahb_master ahb;
if ($cast(ahb, iter.xactor()) begin
...
end
iter.next();
end

286
vmm_xactor_iter::first()
Reset the iterator to the first transactor.
SystemVerilog
function vmm_xactor first();
Description
Reset the iterator to the first transactor matching the name and
instance name patterns specified when the iterator was created
using vmm_xactor_iter::new() and return a reference to it, if found.
Returns null if no transactors match.
The order in which transactors are iterated on is unspecified.

287
vmm_xactor_iter::xactor()
Return the current transactor iterated on.
SystemVerilog
function vmm_xactor xactor();
Description
Return a reference to a transactor matching the name and instance
name patterns specified when the iterator was created using
vmm_xactor_iter::new().

288
vmm_xactor_iter::next()
Move the iterator to the next transactor.
SystemVerilog
function vmm_xactor next();
Description
Move the iterator to the next transactor matching the name and
instance name patterns specified when the iterator was created
using vmm_xactor_iter::new() and return a reference to it, if found.
The order in which transactors are iterated on is unspecified.

289
‘foreach_vmm_xactor()
Short-hand transactor iterator macro.
SystemVerilog
‘foreach_vmm_xactor(type, name, inst) begin
xact...
end
Description
Short-hand macro to simplify the creating and operation of a
transactor iterator instance, looking for transactors of a specific type,
matching a specific name and instance name. The subsequent
statement is executed for each transactor iterated on.
A variable named "xact" of the type specified as the first argument to

the macro is implicitly declared and iteratively set to each transactor
of the specified type that matches the specified name and instance
name.
The macro must be located immediately after a "begin" keyword.
Examples
Example 10-17 Iterating over all transactors of type "ahb_master"
begin
‘foreach_vmm_xactor(ahb_master, "/./", "/./") begin
xact.register_callback(...);
end
end

290
vmm_log::catch()
Add a user-defined message handler
SystemVerilog
function int catch(
vmm_log_catcher catcher,
string name = "",
string inst = "",
bit recurse = 0,
int typs = ALL_TYPS,
int severity = ALL_SEVS,
string text = "");
Description
Install the specified message handler to catch any message of the
specified type and severity, issued by the specified message service
interface instances, which contains the specified text. By default,
catches all messages issued by this message service interface
instance. A unique message handler identifier is returned that can be
used to later uninstall the message handler using
vmm_log::uncatch().
Messages will be considered caught by the first user-defined handler

found that can handle the message. User-defined message handlers
are considered in reverse order of installation i.e. the last handler
installed will be considered first. Once caught, messages are handed
off to the vmm_log_catcher::caught() method and will not be issued.
A user-defined message handler may choose to explicitly issue the
message using the vmm_log_catcher::issue() method or throw the
message back to the message service by using the
vmm_log_catcher::throw() method to be potentially caught by
another suitable message handler or be issued.

291
Watchpoints are triggered after message catching. If the message
has been modified in the catcher, the modified message will trigger
applicable watchpoints, if any.

292
vmm_test
This base class may be used to implement testcases. It enables run-

time selection of the testcase to run on an environment.
Summary
• vmm_test::log
• vmm_test::new()
• vmm_test::get_name()
• vmm_test::get_doc()
• vmm_test::run()
• vmm_test_begin()
• vmm_test_end()

293
vmm_test::log
Message service interface for the testcase.
SystemVerilog
vmm_log log;
Description
Message service interface instance that can be used to issue
messages in the vmm_test::run() method.
The name of the message service interface is "Testcase" and the

instance name is the name specified to the vmm_test::new()
method.

294
vmm_test::new()
Create a test.
SystemVerilog
function new(string name, string doc = "");
Description
Create an instance of the testcase, its message service interface
and registers it in the global testcase registry under the specified
name. A short description of the testcase may also be specified.
Examples
Example 10-18
class my_test extends vmm_test;
function new();
super.new("my_test");
endfunction
static my_test this_test = new();
virtual task run(vmm_env env);

...
endtask
endclass

295
vmm_test::get_name()
Get the name of a test.
SystemVerilog
function string get_name();
Description
Return the name of the test that was specify in the constructor.
Examples
Example 10-19
function new();
endfunction

‘vmm_note(this.log, {"Running test ",
this.get_name()});
...
endtask
endclass

296
vmm_test::get_doc()
Get the description of a test.
SystemVerilog
function string get_doc();
Description
Return the short description of the test that was specify in the
constructor.
Examples
Example 10-20
function new();
endfunction

‘vmm_note(this.log, {"Running test ",
this.get_name()});
...
endtask
endclass

297
vmm_test::run()
Run a test.
SystemVerilog
Description
The test itself.
The default implementation of this method calls env.run(). If a

different test implementation is required, the default implementation
of this method must not be invoked using super.run().
This method should not call vmm_log::report().
Examples
Example 10-21
...
tb_env my_env;
$cast(my_env, env);
my_env.build();
my_env.gen[0].stop_xactor();
my_env.run();
endtask
endclass

298
vmm_test_begin()
Short-hand macro to define a testcase class.
SystemVerilog
‘vmm_test_begin(testclassname, envclassname, doc string)
Description
Short-hand macro that may be used to define a user-defined
testcase implemented using a class based on the vmm_test class.
The first argument is the name of the testcase class and will also be
used as the name of the testcase in the global testcase registry. The
second argument is the name of the environment class that will be
used to execute the testcase. A data member of that type named
"env" will be defined and assigned, ready to be used. The third
argument is a string documenting the purpose of the test.
This macro can be used to create the testcase class up to and

including the declaration of the vmm_test::run() method. This macro
can then be followed by variable declarations and procedural
statements. The instance of the verification environment of the
specified type can be accessed as "this.env". It must be preceeded
by any import statement required by the test implementation.
Examples
This example shows how the testcase from Example 2-72 and
Example 2-75 can be implemented using short-hand macros
Example 10-22
import tb_env_pkg::*;

299
‘vmm_test_begin(my_test, tb_env, "Simple test")
this.env.build();
this.env.gen[0].stop_xactor();
this.env.run();
‘vmm_test_end(my_test)

300
vmm_test_end()
Short-hand macro to define a testcase class.
SystemVerilog
‘vmm_test_end(testclassname)
Description
Short-hand macro that may be used to define a user-defined
testcase implemented using a class based on the vmm_test class.
The first argument must be the same name specified as the first
argument of the vmm_test_begin() macro.
This macro can be used to end the testcase class, including the
implementation of the vmm_test::run() method.
Examples
This example shows how the testcase from Example 2-72 and
Example 2-75 can be implemented using short-hand macros
Example 10-23
‘vmm_test_begin(my_test, tb_env)
this.env.build();
this.env.gen[0].stop_xactor();
this.env.run();
‘vmm_test_end(my_test)

301
vmm_ms_scenario::get_channel()
Get a registered output channel.
SystemVerilog
function vmm_channel get_channel(string name)
Description
Get the output channel registered under the specified logical name
in the multi-stream generator where the multi-stream scenario
generator is registered. Returns NULL of no such channel exists.

302
vmm_channel
The following function and task have been added to the

vmm_channel base class:
• vmm_channel::record()
• vmm_channel::playback()

303
vmm_channel::record()
Records transaction descriptions, relative flow sequence, and timing

in the specified file.
Syntax
function bit record(string filename);
Description
Starts recording the flow of transaction descriptors through the
channel instance in the specified file. The
vmm_data::byte_pack() or vmm_data::save() method must
be implemented for the flowing transaction descriptors. A transaction
descriptor is recorded when it is injected into the channel by the
vmm_channel::put() or vmm_channel::sneak() method.
Recording is also done when an attempt is made to
vmm_channel::unput() a transaction descriptor from the
channel.
This function works as an ON-OFF switch. When called with a valid

filename, it turns ON recording of transactions. When called with a
null (empty string) filename, recording is stopped. Calling this
function with a valid filename while recording is ON results in a
warning, and no action is taken. Likewise, calling this function with a
null (empty string) filename while recording is OFF results in a
warning, and no action will be taken.
This function returns TRUE if recording was successful. While

recording is on, RECORDING notification is indicated by
vmm_channel::notify().

304
Usage Example
string filename = "./record.dat";
xactor.in_chan.record(filename); //start recording
// Information about all transactions flowing through
// "xactor.in_chan" will be recorded in ’filename’ …
xactor.in_chan.record(""); //stops recording

305
vmm_channel::playback()
Executes the recorded transaction operations into the channel

instance.
Syntax
task playback(output bit success,
input string filename,
input vmm_data factory,
input bit metered = 0);
Description
This task executes the recorded transaction operations (put/unput/
sneak), in the same sequence in which they were recorded, into the
channel instance. It acts as a producer for the channel instance.
Playback does not have to happen in the same simulation run as
recording: it can be executed in a different simulation run. The
vmm_data::byte_unpack() or vmm_data::load() method,
must be implemented for the transaction descriptor, passed to the
factory argument. You must provide a non-null factory argument,
of the same transaction descriptor type as that with which recording
was done. The transaction descriptors are played back one by one
in the order specified in the file. If the metered argument is TRUE,
the transaction descriptors are played back (that is, by sneak/put/
unput) to the channel in the same relative simulation time interval
as the one in which they were originally recorded.
While playback is executing on a channel, all other sources of the

channel are locked (vmm_channel::put is not allowed from any
other source). Sneak is still allowed from other sources, but a
warning is printed on any such attempt.

306
Output parameter success is set to TRUE if the playback was
successful. If playback encounters an error condition such as a null
(empty string) filename, a corrupt file, or an empty file, then success
is set to FALSE.
When playback is completed, PLAYBACK_DONE notification is

indicated by vmm_channel::notify().
Example
Example 10-24
class packet_env extends vmm_env;
bit success;
vmm_channel
bit metered;
data_packet factory;
…
function new();
…
factory = new;
metered = 1’b1; // Playback with same timing as
recording
endfunction
task start();
// Other start code …
ìfndef PLAY_DATA
this.generator.start_xactor();
èlse
fork
begin
//Start playback this.xactor.in_chan.playback(
//this.success,this.filename,this.factory,
//this.metered);
if(!this.success)
`vmm_error(this.log,"vmm_channel::playback()
function failed");

307
end
join_none
èndif
endtask
endclass::packet_env

308
vmm_ral_block_or_sys Base Class Additions
The following functions have been added to the the

vmm_ral_block_or_sys class:
• “vmm_ral_block_or_sys::set_offset()”
• “vmm_ral_block_or_sys::get_reg_by_offset()”

309
vmm_ral_block_or_sys::set_offset()
Modify the base address of the block or system.
SystemVerilog
virtual function bit set_offset(bit [63:0] offset,
string domain = "")
Description
Dynamically relocate the base address of the specified domain in the
block or subsystem in the address space of the immediately
instantiating system. The new address range for the block or
subsystem must not be occupied by another block or subsystem.
Note that after using this method, the behavior of the RAL model will
be different from the RALF specification.
Returns TRUE of the relocation was succesful. Returns FALSE if the

specified domain does not exist in the immediately enclosing system
or the new base address creates an overlap between this block or
subsystem address range and another block or subsystem.
It is not possible to relocate the base address of the top-level system

because is it not instantiated anywhere.

310
vmm_ral_block_or_sys::get_reg_by_offset()
Gets the register at the specified offset in this block or system.
SystemVerilog
virtual function vmm_ral_reg get_reg_by_offset(
bit [63:0] offset,
string domain = "")
Description
Finds the register located at the specified offset within the block or
system address space in the specified domain and returns its
descriptor. If no register is found at the specified offset, returns
NULL.
The entire register may occupy more than one offset within the
address space of the block or system if it is wider than the physical
interface. In such cases, this function looks for the start (lowest)
address of the register’s address space.
This function has a default version and a faster version, which takes
more memory than the default version.
In the default (slower) version, all registers of the underlying blocks

and subsystems are searched, short-circuiting the search wherever
possible, to check if a register exists at the specified block/system
level offset/address.

311
The faster version uses associative arrays to cache block level
register offsets, which helps to speed up the search, given an offset.
Memory consumption is higher in the faster version, due to caching.
You can activate the faster version by defining the runtime macro
VMM_RAL_FAST_SRCH.

312
11
VMM Planner MS Doc Annotation 1
The VMM Planner Doc annotator enables creation of verification
plans using Microsoft Office (.doc) documents, and back-annotation
of coverage and other scores into the .doc plan. The .doc verification
plan must be formatted properly with predefined styles and keywords
built into the VMM Planner Doc annotator.
Either MS-Word 2003 or later can be used to create the .doc

verification plan.
Note:
Unlike the VMM Planner Spreadsheet annotator flow, the Word
Doc flow does not currently support OpenOffice input.
Back-annotation is an extension of the existing VMM Planner

Spreadsheet annotator flow. The hvp annotate command and
most of its switches can be used for back-annotation the same way
that they are used with the spreadsheet annotator.
VMM Planner MS Word Annotation

303
This section contains the following topics:
• “Introduction” on page 304

• “Use Model” on page 305
• “hvp annotate Command Arguments” on page 307
• “Capturing a Verification Plan in Doc XML Format” on page 310
• “Debugging the Doc Plan” on page 319
• “How to Get Scores Back-Annotated in the Doc” on page 322
Introduction
The VMM Planner Doc annotator is used:
• To provide simple hooks in MS Word-compliant documents to

interface with VMM Planner-enabled applications.
• To provide flexibility in formatting verification plan doc XML for
nicely formatted coverage reports.
The same doc XML file is used by VMM Planner as a verification plan
and as an annotated report. Formatting features such as selectable
fonts, text alignment, graphics, charts, tables and descriptions are
applied in both the plan and the annotated output report.

304
Use Model
Figure 11-1 Word Doc annotator use model
External Debugging
Doc Plan XML .hvp Files
External External
Doc XML
Synopsys
Unified Annotated
hvp annotate External
Coverage Doc XML
Database
HVP
User Data
• “Process Flow” on page 306

• “License Model” on page 306
• “Supported Platforms” on page 307
• “Compatibility with the VMM Planner Spreadsheet Annotation
Flow” on page 307

305
Process Flow
1. Capture your verification plan in Doc XML format. This is typically

done by starting with a Synopsys-provided template file and
marking key paragraphs in the created doc with Synopsys-defined
styles, and copying and pasting Synopsys-defined tables.
2. Prepare Synopsys coverage database and HVP user data files.
3. Run hvp annotate with the XML plan, covdb, userdata and
other desired switches.
4. Fix any errors you see. You can find more error information in
filename.dbg.xml. Even if you do not see any errors, open
the filename.dbg.xml file and check to make sure that VMM
Planner processed your verification plan hierarchy and contents
as you intended. This debug check process only needs to be
done on newly created or recently edited plans. Once the plan
becomes stable, this debug check step can be skipped when
annotating with new coverage databases.
5. If there are no errors, open filename.ann.xml to see the
annotated scores.
License Model
VMM Planner in C-2009.06 Beta is a Beta feature, so a Beta license

key is needed in order to use the Doc XML annotation flow.

306
Supported Platforms
linux
amd64
suse32
suse64
sparc64
sparcOS5
Compatibility with the VMM Planner Spreadsheet

Annotation Flow
The VMM Planner Spreadsheet annotator flow and Doc annotator

flow share the hvp annotate command and most of its switches.
When an XML plan file is specified in -plan planfile, VMM
Planner automatically detects the XML file format and invokes the
proper process depending on the format of the XML.
The hvp annotate command is completely backward compatible

with the existing VMM Planner Spreadsheet annotator.
hvp annotate Command Arguments
Syntax
hvp annotate -plan planfile
[-h]
[-mod hvpfiles]
[-plan_out annfile]
[-feature "hierarchies"|-featurefile txtfile]
[-dir covdbpath|-f txtfile]
[-userdata vedata|-userdatafile txtfile]
[-userdata_out outvedata]

307
[-metric_prefix prefix]
[-group ratio|merge_across_scopes]
[-show_ratio]
[-show_incomplete]
[-v]
[-q]
Options
-plan planfile
Spreadsheet, doc XML or HVP file for your verification plan. This
switch is mandatory.
Example: -plan myplan.xml
-h
Show this help message and exit.
-mod hvpfiles
Filter or override files in HVP language format multiple files can
be specified. They are applied in the order in which they are
entered.
Example: -mod override.hvp filter.hvp
-plan_out annfile
Specify the name for the output annotated spreadsheet or doc
XML file. If -plan_out is not entered, a file with the original
filename and .ann.xml extension is generated.
-feature "hierarchy [hierarchy...]"

Specify HVP scopes that you want to annotate with the given
covdb coverage database or ve.data. Multiple scopes can be
specified, and wildcards (*, **, ?) can be used. Enclose the string
with double quotes. Subhierarchies of matched scopes are
automatically annotated. if -hier is not used, covdb and ve.data
are annotated to entire plan.

308
Example:
-feature "myplan.rec_feat.* myplan.play_feat.*"
-featurefile txtfile
A text file that contains list of hierarchical filters.
-dir covdbpath
Specify the path to a Synopsys coverage database (cm, vdb).
Multiple paths can be entered, separated by commas.
Example: -dir wishbone.cm wishbone.vdb
-f txtfile
Specify a text file that contains list of covdb coverage database
paths.
-userdata vedata
Specify a ve.data file path. Multiple paths can be entered,
separated by commas.
Example: -userdata result.txt bugcount.txt
-userdatafile txtfile
Specify a text file that contains a list of user database file paths.
-userdata_out outvedata
Dump an annotated score of all measures into the specified
outvedata user data file.
-metric_prefix prefix
The given prefix is used to change a metric name in the output
user database file used by -userdata_out.
-group ratio | merge_across_scopes

309
-group ratio: Aggregate the group metric score as a ratio type
(covered/coverable) instead of as a percent.
-group merge_across_scopes: Merge the group score

across scopes.
-show_ratio
Display ratio type scores in a ratio form instead of a percent.
-show_incomplete
Indicate incomplete scores with [inc].
-v
Verbose mode: Show progress status messages.
-q
Quiet mode: Turn off all warning messages.
Capturing a Verification Plan in Doc XML Format
• “Built-In Styles” on page 310

• “Table Keyword” on page 314
• “Other Contents” on page 319
Built-In Styles
In the Doc XML plan template, there are predefined styles that are
prefixed with “HVP”. VMM Planner extracts the contents and their
styles to establish the HVP hierarchy. A template document

310
containing predefined styles is provided with the VMM Planner Doc
annotator. Make a copy of that template and then use your copy as
a basis to create a new plan.
HVP Plan Style

Content with the style “HVP Plan” is assigned as the name of the
HVP Plan. Use this style only once in the plan, typically at the very
top of the document.

311
HVP Feature 1 to HVP Feature 9
There are nine levels of “HVP Feature” styles, which are used to
represent HVP feature hierarchy. The index must be seamless in
terms of hierarchy, which means that “HVP Feature 1” can be
followed by another “HVP Feature 1” or “HVP Feature 2”, but
not by “HVP Feature 3” or “HVP Feature 4”, for example. If “HVP
Feature 2” is found, the feature will be a subfeature of the
previous “HVP Feature 1”. If “HVP Feature 1” is found, it will be
sibling of the previous “HVP Feature 1”, if one exists.
This limited number of styles also limits the number of levels of

hierarchical depth in a verification plan. You cannot create a plan
with more than nine levels of features.

312
You can also use “HVP Feature number” for subplan declaration.
To instantiate a subplan, use subplan name-of-plan. You can
also pass attributes and annotation value overrides the using #()
syntax, which is the same syntax as in the HVP language.
Since VMM Planner does not allow the same instance name in the
same node, you must add one more feature level to instantiate
multiple subplans with the same plan, as shown in the following
example.

313
HVP Description
The paragraph with the “HVP description” style is extracted as
the built-in description attribute in the HVP feature. You can also
use an “HVP Assignment” table to override description values.
Table Keyword
When a table is found, VMM Planner looks at the contents in the first
cell of the table, and determines whether the table needs to be
interpreted as part of the HVP hierarchy. The following keywords are
reserved:
• “HVP Assignment” on page 315

• “HVP Measure name” on page 315
• “HVP Metric name” on page 317
• “HVP Attribute name, HVP Annotation name” on page 318
• “HVP Include File” on page 319

314
HVP Assignment
A table with an “HVP Assignment” style is used to override
attributes, annotations and goals for metrics. The keyword cell is
followed by two-column rows. The left cell must have the name of an
attribute or annotation to override the value of the name or
annotation, or the name of a metric to override a goal expression. All
names of attributes, annotations or metrics in this table must be
defined in the plan. Otherwise, VMM Planner generates warnings
and ignores the undefined names.
HVP Assignment
phase 2
owner Snps
Note:
Although the HVP language is case sensitive, VMM Planner
searches for the names of attributes, annotations, and metrics in
its definition tables with case-insensitive matching, because Word
sometimes capitalizes the first character of a word.
HVP Measure name

The table with the HVP Measure name keyword in the first cell is
used to declare HVP measure statements. You can specify a unique
measure name or leave it blank. If no measure name is entered,
then VMM Planner automatically generates a measure name.

315
The keyword cell is followed by two-column rows. You specify at
least one source string. To specify multiple sources, you can list
multiple source strings in the same cell separated by commas, or
add multiple rows with the source keyword in the left cell of each
row.
After the source row, append one or more two-column rows, with a
metric name in the left cell of each of those rows. Leave the right cell
empty. The annotation process fills each empty cell with its score.
HVP Measure m1
source group instance:
memsys_test_top.testbench::cpu::cpu_cov.my_cpu0
Group
HVP Measure
source group: memsys_test_top
source group: memsys_test_top2
Group
HVP Measure
source group: memsys_test_top, group: memsys_test_top2
Group
Assert

316
HVP Metric name
A table with an HVP Metric name keyword in the first cell is used
to define an HVP metric. In the keyword cell, a unique metric name
must be specified after HVP Metric (“bugs” in the example table
below).
The following are rules for creating an HVP metric table:
• One table per one metric definition.

• Following the first row, use two-column rows with predefined
keywords in the left cell. Rows for type and aggregator are
mandatory. A row for goal is optional.
Type can be one of: integer, ratio, real, percent, enum {entry1,
entry2, ...}.
Aggregator can be one of: sum, average, max, min. Not all entries
are available for all types. See “Using the HVP Language” for
more information.
Goal is an expression for the coverage goal.
HVP metric bugs

type Integer
aggregator Sum
goal bugs < 3

317
HVP Attribute name, HVP Annotation name
A table with an HVP Attribute name or HVP Annotation name
keyword in the first cell is used to define an HVP attribute or
annotation, respectively. In the keyword cell, a unique name must be
specified after the HVP Attribute or HVP Annotation keyword
(“phase” in the first example table below, and “spec” in the second
example table).
The following are rules for creating an HVP metric table:
• One table per one definition.

• Following the first row, use two, two-column rows with predefined
keywords type and default in the left cells.
Type can be one of: integer, ratio, real, percent, enum {entry1,
entry2, ...}.
• Default is the default value of the attribute or annotation.
HVP attribute phase

type Integer
default 1
HVP annotation spec

type String
default

318
HVP Include File
A table with the HVP Include File keyword in the first cell is used
to declare other XML plans to be included as subplans. The XML
plans that are included in this table can be used as subplans. Add as
many one-column rows containing XML filenames as you need.
HVP include file

sram_wordplan.xml
dram_wordplan.xml
Other Contents
All other content such as text, images, and charts, that is neither in
a predefined HVP style nor in a table with a predefined keyword, is
ignored during the annotation process, and appears in the annotated
plan exactly as it appears in the original plan document. Formatting
is limited to the formatting features that are allowed in Microsoft
Word 2003 XML .doc format.
Debugging the Doc Plan
When an error is detected in a .doc verification plan, it is difficult to

find where the error occurred. In addition, VMM Planner might
interpret your verification plan in a different way than what you
intended or expected due to reasons such as typographic errors,
incorrect styles, and so on. This is because the paragraph styles are
essentially invisible in the normal WYSIWYG view of the document.
You might, for example, select the wrong style, not knowing that

319
VMM Planner will not recognize the paragraph properly. When you
run hvp annotate, a filename.dbg.xml is created for each plan
file, which provides detailed debugging information.
• “[Style|Table] Keyword Indicator” on page 320

• “Unique Error Code in Error Messages” on page 322
[Style|Table] Keyword Indicator
In the filename.dbg.xml, a blue term enclosed in square

brackets, [Style|Table], indicates that the section was either a
predefined HVP style or a predefined HVP table. Several examples
are shown below. If you do not see [Style|Table] where you expect to
see it, there is an error in your HVP file such as a wrongly used style
or a typographic error.

320
321
Unique Error Code in Error Messages
The following error while running hvp annotate indicates that an

invalid metric, Group 1, was found at the location of ERR001:
Error:[DOC_060] memsys_wordplan.xml:ERR001: Invalid metric

name(Group1) was used in Measure(_m1) in Feature(1.2. cpu1)
To find where Group1 was used, you can open the file named
memsys_wordplan.dbg.xml and search for the ERR001 string.
ERR001 is a unique string in the filename.dbg.xml file, so you
can easily find the location of the error. Then you can open the
original plan and edit it to fix the error.
How to Get Scores Back-Annotated in the Doc
Running hvp annotate, creates one or more

filename.ann.xml files. VMM Planner produces one
filename.ann.xml file per plan or subplan instance in the HVP
hierarchy. If your plan does not include any subplans, then only one
filename.ann.xml is produced.
If a plan is used as subplan multiple times, then VMM Planner

produces filename.ann.1.xml, filename.ann.2.xml and so
on.

322
It is not necessary to open the *ann.*.xml file to view a subplan.
You can open only the top-level plan .ann.xml file and navigate to
any subplan .ann.xml from there.
• “Plan/Feature Score Summary” on page 323

• “Measure Score Table” on page 324
• “Navigating Down to a Subplan” on page 325
Plan/Feature Score Summary
Running hvp annotate produces a score summary table for each

plan or feature. Each score cell in the score summary table is filled
in with a color determined by the score and the goal. The meanings
of the colors are:
• If a goal was specified,

- Green indicates that the goal was met
- Red indicates that the goal was not met
• If no goal was specified:
For Synopsys coverage,
- Green indicates 100% coverage

- Red indicates 0% coverage
- A coverage score between 0 and 100% is indicated by one of
six different colors (see the Unified Coverage Reporting User
Guide for information about setting the colors)

323
For a test metric,
- Green indicates a pass/total ratio of 1 (100%)

- Red indicates a pass/total ratio of 0 (0%)
- A coverage score between 0 and 100% is indicated by one of
six different colors (see the Unified Coverage Reporting User
Guide for information about setting the colors)
Some examples are shown below.
Measure Score Table
In the measure score table, the score cell is colored using the same
scheme as the “Plan/Feature Score Summary”. If no score is
available, then the cell contains “N/A”.

324
If the –show_incomplete switch is used, “[incomplete]”, in orange,
appears in front of any source string that does not match any of the
regions in the coverage database or user data.
Navigating Down to a Subplan
In a filename.ann.xml file, clicking on a subplan name that uses

the HVP Feature style opens the ann.xml file for the subplan
instance. Hold down Ctrl and click the subplan name (for example,
the name starting with subplan sram_plan in the example below)
to open the file.

325
326
12
URG Enhancements 1
• “New URG Features and Changes” on page 327

• “License Model” on page 333
• “Platform Support” on page 333
New URG Features and Changes
The following section contains a summary of each enhancement:
• “Improved HTML Page Format” on page 328

• “Incompleteness Checks” on page 329
• “Omitting Filtered Features” on page 330
URG Enhancements
327
• “Dumping User Data” on page 330
• “Predictable Page Naming Convention” on page 331
• “Add New Hyperlinks from group bin and group instance” on page
331
• “New –show hvpprob Command for Problem Reports” on page
332
• “Test Metric Coloring” on page 332
Improved HTML Page Format
The hvp*.html page format has been changed to the more compact
format used by the hierarchy.html page. This allows for more
information to be displayed per page, which reduces the amount of
scrolling necessary to read the report. Also, linear tables on the
feature*.html pages can be sorted by column. With these changes,
the HVP pages are more consistent with other URG data pages.
Figure 12-1 shows an example of the new hvp*.html page format.
URG Enhancements
328
Figure 12-1 hvp*.html page format
Incompleteness Checks
You can bind HVP features to coverage regions via the measure
statement of the HVP file. Other HVP applications that load both the
.hvp plan and the coverage database can compare those measure
sources against the database and highlight problems where no
match is found, enabling the user to identify and correct those
problems.
Use Model
The user runs URG and observes warning messages about
unbound source statements, then determines the cause of the
warnings. After fixing the code and the plan, the user runs URG
again. This is repeated if there are more incompletness warnings.
URG Enhancements
329
Omitting Filtered Features
A core feature of all HVP applications is the ability to filter out or

prune branches of the verification plan. Previously, when such a
fliter was applied, URG did not annotate those pruned branches, but
it still displayed them in the report as null/grey features, resulting in
visual clutter.
Those filtered features are removed altogether, resulting in a more

concise and usable report.
Use Model
The user can enter the –mod command line argument to supply a
filter modifier. For multiple filtered reports of the same master
design, the user can invoke multiple URG runs.
Dumping User Data
HVP allows you to extend the set of metrics measured by the plan.
In conjunction with those extended metrics, you must also provide

text files (userdata) containing the raw data. That user-defined
data is dumped to the HVP report and hyperlinks are inserted from
the measure sources to the new raw data report. This provides a
more complete report, allowing you to drill down all the way to the
raw data.
Use Model
When questions arise about how top level scores are reported, the
user can use the hyperlinks pointing from the feature*.html pages to
drill down to the raw ve.data listings.
URG Enhancements
330
The –userdata runtime option specifies user-defined data sources
Predictable Page Naming Convention
Users may want to directly reference specific hvp* and feature*

pages in the URG report from other programs. Previously, those
pages had serialized names like hvp1.html and feature123.html.
There was no easy way to know in advance which feature was
placed on which page.
URG has been enhanced with a predictable naming convention

based on the actual feature hierarchy so that users can translate a
feature’s absolute name into a URL, and reference that directly.
This feature is exploited in the hvp annotate application allowing

MS Word and MS Excel documents to hyperlink to URG reports,
enabling drill-down debug and raw data queries.
Use Model
To reference HVP results from external documents, the user must
know the absolute path in terms of feature names to reach the
feature that they seek. For example, to produce an external
document containing the results for feature A.B.C, you could form a
URL like feature named, A.B.C.html. After URG is run, the urgReport
would contain a file with that name.
Add New Hyperlinks from group bin and group instance
Previously, the metric source types group bin and group

instance were not properly hyperlinked to their respective raw data
pages. That deficiency has been corrected.
URG Enhancements
331
Use Model
Hyperlinks can be used to drill down to raw functional coverage
information.
New –show hvpprob Command for Problem Reports
When a user has a very large plan that is nearing tapeout, it might
be helpful to view a report that contains only problems. The -show
hvpprob option produces a report that omits all non-problem
features. A problem is defined as a feature that fails the goals set for
one or more of its metrics.
Use Model
When the –show hvpprob option is used, the default hvp*.html
report shows only the problems.
Test Metric Coloring
The built-in test metric is an enum metric type. There is an

implication that the metric’s default coverage score should be based
on a percentage of passes over the total number of tests.
This feature computes that percentage and then applies the default
red-yellow-green spectrum of colors that are used for other URG
metrics.
If the user overrides the default test metric goal then coloring reverts
to the binary red/green cell coloring.
URG Enhancements
332
License Model
The –lca command line flag is required to invoke any HVP feature
within URG.
Platform Support
linux
amd64
suse32
suse64
sparc64
sparcOS5
aix
URG Enhancements
333
URG Enhancements
334
12
Run Command 1
This chapter describes the options added in the run command in
this release.
run Command
The run command runs all the simulation time units.
Syntax
run [0]
run [-delta]
run [-nba]
[0]
Run Command
347
Runs all of the deltas of a particular simulation time and stops just
before the end of that simulation time. The simulation stops after
signal update phase, before process execution for the last delta.
If UCLI generates more events by forces or release etc., all such
events are processed until things stabilizes at the end of current
time.
[-delta]
Runs one set of deltas at a time and stops before the next delta.
The simulation advances to the next delta and return to UCLI soon
after the signal update phase (before process execution). You can
inspect values of newly deposited signals/variables at that time.
If there are no more events, the simulation advances to the next
time step and stops at the end of the first delta of the new time step.
This command is useful for delta cycle level debugging especially

when it comes to viewing values instantaneously due to forces
and values propagation or debugging races.
[-nba]
Runs all deltas and stops before a new NBA (non-blocking
assignments). The simulation goes into interactive mode right
before the NBA queue starts executing during SemiLER queue
execution.
This ensures all deltas (sched0 queues) are executed and all
blocking assignments are completed.
Run Command
348

2009 06

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2009 06

Hochgeladen von

Copyright:

Verfügbare Formate

VCS® / VCS® MX Beta

Destination Control Statement

1. VCS SystemVerilog Features

4. Coverage Convergence Technology

6. Viewing values in Symbolic format

9. VMM Additions and Enhancements

10. VMM Planner MS Doc Annotation

12. Run Command

Enhancements have been made to the following features. These

VCS SystemVerilog Features

VCS SystemVerilog Features

Parameterized mailboxes use the same parameter syntax as

where dynamic_type is a type that enables runtime type checking

typedef mailbox #(string) s_mbox;

Parameterized mailboxes provide the same methods as dynamic

VCS SystemVerilog Features

String literals can be cast to a packed or unpacked array, following

The syntax for associative arrays is:

VCS SystemVerilog Features

The syntax for other unpacked dimensions is:

'{val1, val2, val3} or '{default: value}

In arrays that have multiple unpacked dimensions, array literals can

Example 1-1 Variable-sized arrays

// Nested array literals

// An associative array of strings indexed by 2-state

// An associative array of 4-state integers indexed by

For an associative array, if a nonexistent element is read, the default

Table 1-1 Default values for associative array elements

Type of array Default value

VCS SystemVerilog Features

• '{default: value} for associative arrays

Assignments such as "aa = '{0:aa[1], 1:aa[0]}" are

SystemVerilog Linked Lists

VCS provides a library implementation for SystemVerilog linked lists

VCS SystemVerilog Features

The following SystemVerilog features have been implemented in

• “Task and Function Calls Using Virtual Interface Variables”

Task and Function Calls Using Virtual Interface

Tasks and functions in a virtual interface can be called using a

VCS SystemVerilog Features

The $typename Function

The $typename system function returns a string that represents the

The return string is constructed using the following steps:

1. A typedef that creates an equivalent type is resolved back to

VCS SystemVerilog Features

When called with an expression as its argument, $typename

VCS SystemVerilog Features

Source code Value returned by $typename

Fine-Grained Process Control Using the process Class

A process is a built-in class that allows one process to access and

The prototype for the process class is as follows:

VCS SystemVerilog Features

A process cannot be extended. An error is issued if this is attempted.

The following terms are used below:

• fork...join represents any of the fork-join/join_any/

process Class Members

The self() function returns a process class handle

VCS SystemVerilog Features

enum state { FINISHED, RUNNING, WAITING, SUSPENDED,

The status() function returns the current state of the process.

FINISHED – The process finished execution normally.

RUNNING – The process is running (not blocked).

The ’FILE and ’LINE compiler directives have been

’FILE expands to the string literal name of the current input

’LINE expands to the decimal current input line number.

’FILE and ’LINE are useful in generating error messages

Example 1-4 ’FILE and ’LINE usage

An ’include directive changes the expansions of ’FILE and

A ’line directive changes ’LINE and might also change

index_type is the data type to be used as an index, or . If is