Verification Continuum™ VCS User

Guide
Version V-2023.12, December 2023
 Feedback

Contents
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Synopsys Statement on Inclusivity and Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

1. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Simulator Support with Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Simulation Preemption Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Setting Up the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Verifying Your System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Obtaining a License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Setting Up Your Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Creating a synopsys_sim.setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
The Concept of a Library in VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Library Name Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Including Other Setup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Using the SYNOPSYS_SIM_SETUP Environment Variable . . . . . . . . . . . . 62
Supporting VHDL Non-Locally Static Aggregates . . . . . . . . . . . . . . . . . . . . 62
Displaying Setup Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Displaying Design Information Analyzed Into a Library . . . . . . . . . . . . . . . . . . . 64
Using the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Two-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Compiling the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Simulating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Three-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Analyzing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Elaborating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Simulating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Basic Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Two-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Three-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Default Time Unit and Time Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Searching Identifiers in the Design Using UNIX Commands . . . . . . . . . . . . . . . . . . 68
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
UTF-8 Unicode File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3
 Feedback

Contents

2. VCS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Three-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Using vhdlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Using vlogan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Disabling Environment Variables Checks on Different Machines . . . . . . . . .80
Analyzing the Design to Different Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 81
Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Using VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Commonly Used Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Two-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using vcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Commonly Used Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Partition Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3. Modeling Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

Avoiding Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Using and Setting a Value at the Same Time . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Setting a Value Twice at the Same Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Flip-Flop Race Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Continuous Assignment Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Counting Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Time Zero Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Race Detection in Verilog Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
The Dynamic Race Detection Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Introduction to the Dynamic Race Detection Tool . . . . . . . . . . . . . . . . . . . . 96
Enabling Race Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
The Race Detection Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Post-Processing the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Debugging Simulation Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
The Static Race Detection Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4
 Feedback

Contents

Race Detection Tool to Identify Race between Clock and Data . . . . . . . . . . . . . . . 105
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Optimizing Testbenches for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Conditional Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Enabling Debugging Features at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Combining the Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Creating Models That Simulate Faster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Unaccelerated Data Types, Primitives, and Statements . . . . . . . . . . . . . . . . . 114
Inferring Faster Simulating Sequential Devices . . . . . . . . . . . . . . . . . . . . . . . . 115
Modeling Faster always Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Using Verilog 2001 Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Case Statement Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Precedence in Text Macro Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Memory Size Limits in the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Memory Size Calculation of Bit Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Memory Size Calculation of Reg Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using Sparse Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Obtaining Scope Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Scope Format Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Returning Information About the Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Avoiding Circular Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Designing With $lsi_dumpports for Simulation and Test . . . . . . . . . . . . . . . . . . . . .129
Dealing With Unassigned Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Code Values at Time 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Cross Module Forces and No Instance Instantiation . . . . . . . . . . . . . . . . . . . . 130
Signal Value/Strength Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Translating VHDL Package to SystemVerilog Package . . . . . . . . . . . . . . . . . . . . . 133
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
VHDL Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
VITAL2000 Negative Constraint Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Using VITAL2000 NCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Disabling VITAL2000 Conformance Checks . . . . . . . . . . . . . . . . . . . . . . . . . . .138

5
 Feedback

Contents

4. Compiling/Elaborating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

Compiling/Elaborating the Design in the Debug Mode . . . . . . . . . . . . . . . . . . . . . . 139
Optimizing Simulation Performance for Desired Debug Visibility With the
-debug_access Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Incrementally Removing Debug Capabilities . . . . . . . . . . . . . . . . . . . . . . . 143
Assertion Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Verdi One Search Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Reporting Global Debug Capability Diagnostics . . . . . . . . . . . . . . . . . . . . 144
Specifying Design Regions for -debug_access Capabilities . . . . . . . . . . . . . . 146
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Region Debug Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Automatic Debug Capability Addition Using $fsdbDumpvars(level,path) . . . . . 151
Enabling Additional Debug Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Driver/Load Debug Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Statement Debug Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Force/Deposit Debug Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Class Debug Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Reduction in the Objects Being Dumped . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Using -debug_access With Tab Files (With -P Option) . . . . . . . . . . . . . . . . . . 152
Unused Tab File Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Including Tab Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Dumping FSDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Interaction With Other Debug Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Dynamic Loading of DPI Libraries at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Dynamic Loading of PLI Libraries at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Key Compilation or Elaboration Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Initializing Verilog Variables, Registers, and Memories . . . . . . . . . . . . . . . . . . 156
Initializing Verilog Variables, Registers, and Memories for an Entire
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Initializing Verilog Variables, Registers, and Memories in Selective Parts of a
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Selections for Initialization of Registers or Memories . . . . . . . . . . . . . . . . 158
Reporting the Initialized Values of Variables, Registers, and Memories . . .159
Overriding Generics and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Overriding Verilog Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Overriding VHDL Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

6
 Feedback

Contents

Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Checking for x and z Values In Conditional Expressions . . . . . . . . . . . . . . . . . 163
Enabling the Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Filtering Out False Negatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Cross Module References (XMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
The hdl_xmr Procedure and the $hdl_xmr System Task . . . . . . . . . . . . . . 167
Data Types Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Using the hdl_xmr Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Using the $hdl_xmr Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
$hdl_xmr Support for VHDL Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Data Type Support and Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . 176
Support for Native XMR force and release . . . . . . . . . . . . . . . . . . . . . . . . 178
Verilog Configurations and Libmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Library Mapping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Hierarchical Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
The -top Compile-Time Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
Limitations of Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Using the -liblist Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Design Cells and Library Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Library Search Order Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Example Testcase Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Usage Examples for Library Search Order Rules for Verilog or SystemVerilog
Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Lint Warning Message for Missing ‘endcelldefine . . . . . . . . . . . . . . . . . . . . . . 216
Error/Warning/Lint Message Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Controlling Error/Warning/Lint Messages Using Compile-Time Options . . 219
Controlling Error/Warning/Lint Messages Using a Configuration File . . . . 230
Extracting the Files Used in Elaboration/Compilation . . . . . . . . . . . . . . . . . . . .236
XML File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
Reducing Compile Time for Post-Process Only Debug . . . . . . . . . . . . . . . . . . 243
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

5. Simulating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244

Using Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Using UCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

7
 Feedback

Contents

-ucli2Proc Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Options for Debugging Using Verdi and UCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Reporting Forces/Injections in a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Reporting Force/Deposit/Release Information . . . . . . . . . . . . . . . . . . . . . . . . . 250
Handling Forces on Bit/Part Select and MDA Word . . . . . . . . . . . . . . . . . 251
Handling Forces on Concatenated Codes . . . . . . . . . . . . . . . . . . . . . . . . . 252
Output Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Generating Force List Report for Desired Instance Hierarchies . . . . . . . . . . . .259
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Displaying Different ID for Each Verilog Force . . . . . . . . . . . . . . . . . . . . . . . . .262
Enhanced Force List Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Displaying Source Information for VHDL Forces . . . . . . . . . . . . . . . . . . . . . . . 263
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Displaying Source Information for External Forces . . . . . . . . . . . . . . . . . . . . . 264
Enhanced Force List Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Viewing Force Information in Interactive Debug Mode . . . . . . . . . . . . . . . . . . .266
Use model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Reporting $deposit Value Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Key Runtime Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Overriding Generics at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Passing Values from the Runtime Command Line . . . . . . . . . . . . . . . . . . . . . .274
Using -f Runtime Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Saving and Restarting the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Save and Restart Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Save and Restart File I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Save and Restart With Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Specifying Long Time Before Stopping the Simulation . . . . . . . . . . . . . . . . . . 279
Preventing Time 0 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Resolving RTL Simulation Races in Mixed HDL Designs . . . . . . . . . . . . . . . . 281
Recommended Approach to Resolve Race Conditions . . . . . . . . . . . . . . . 281
Resolving RTL Simulation Races in Verilog Designs . . . . . . . . . . . . . . . . . . . . 282

8
 Feedback

Contents

Recommended Approach to Resolve Race Conditions . . . . . . . . . . . . . . . 283

Supporting Simulation Executable to Return Non-Zero Value on Error
Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Supporting Memory Load and Dump Task Verbosity . . . . . . . . . . . . . . . . . . . . 288
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

6. The Unified Simulation Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

The Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Specifying a Directory for the Profile Database . . . . . . . . . . . . . . . . . . . . . . . . 293
Post Simulation Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Specifying the Name of the Profile Report . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Omitting Profiling at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Omitting the -simprofile Runtime Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Omitting Profile Report Writing after Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Running the profrpt Profile Report Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Generating Simprofile Dynamic Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Memory Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Memory Construct Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Memory Search View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Specifying Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
The Snapshot Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Specifying Timeline Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Recording and Viewing Memory Stack Traces . . . . . . . . . . . . . . . . . . . . . . . . .315
Reporting PLI, DPI, and DirectC Function Call Information . . . . . . . . . . . . . . . 315
Compiling and Running the Profiler Example . . . . . . . . . . . . . . . . . . . . . . 316
Profiling Time Used by Various Parts of the Design . . . . . . . . . . . . . . . . . 317
Profiling Memory Used by Various Parts of the Design . . . . . . . . . . . . . . . 318
The Output Directories and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
The Enhanced Accumulative Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
The Comparative View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
The Caller-Callee Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Using the -simprofile no-altstack or -simprofile allow-user-sigaltstack Option . 331
HTML Profiler Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Display of Parameterized Class Functions and Tasks in Profiling Reports . . . .351
Hypertext Links to the Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

9
 Feedback

Contents

Single Text Format Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Stack Trace Report Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
SystemC Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Constraint Profiling Integrated in the Unified Profiler . . . . . . . . . . . . . . . . . . . . . . . 364
Changes to the Use Model for Constraint Profiling . . . . . . . . . . . . . . . . . . . . . 365
The Time Constraint Solver View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
The Memory Constraint Solver View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
The Time FlameGraph View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376
Performance/Memory Profiling for Coverage Covergroups . . . . . . . . . . . . . . . . . . 383
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
HTML Profiler Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Default Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384
Time/Memory Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Time/Memory Module View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Time/Memory Construct View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Time/Memory Covergroup View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Reporting Debug Capabilities for Each Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389
HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
Text Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Line-Based CPU Time Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .392
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Simulation Time Slice Based Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395
Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Isolating the Cost of Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
Isolating the Cost of Loading Design Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
Third-Party Shared Library Profiler Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
VHDL Unified Simulation Profiler Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

10
 Feedback

Contents

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
The HSIM View With the Simulation Profiler Report . . . . . . . . . . . . . . . . . . . . . . . 401
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

7. Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Using Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Using –diag Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Compile-time Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Libconfig Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Timescale Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Generating Information on Unused Libraries at vlogan . . . . . . . . . . . . . . . . . . 410
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Generating Information on Unused Libraries at VCS . . . . . . . . . . . . . . . . . . . . 411
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Obtaining Statistics on Package Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Runtime Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Diagnostics for VPI/VHPI PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .414
Keeping the UCLI/Verdi Prompt Active After a Runtime Error . . . . . . . . . . . . . 417
UCLI Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417
Verdi Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418
UCLI Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421
Diagnosing Quickthread Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Diagnosing Quickthread Issues in DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Diagnosing Quickthread Issues in SystemC . . . . . . . . . . . . . . . . . . . . . . . 422
Post-Processing Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
Using the vpdutil Utility to Generate Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 425
The vpdutil Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Sparse Memory Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Compile Time Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Sparse Disable Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

11
 Feedback

Contents

Event Order Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Flop Data Race Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
Diagnostic Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

8. VPD, VCD, and EVCD Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Advantages of VPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .436
Dumping a VPD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Using System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Enable and Disable Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Override the VPD Filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Dump Multi-Dimensional Arrays and Memories . . . . . . . . . . . . . . . . . . . . .439
Using $vcdplusmemorydump System Task . . . . . . . . . . . . . . . . . . . . . . . . 441
Capture Delta Cycle Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Dumping an EVCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Using $dumpports System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Analyzing Direction Only for inout Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443
Dumping EVCD File for Mixed Designs Using UCLI dump Command . . . . . . .443
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Use Model for Dumping CCN Driver Through INOUT . . . . . . . . . . . . . . . . 444
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Unsupported Port Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Unsupported DUT Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
SystemC Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Post-processing Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
The vcdpost Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Scalarizing the Vector Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Uniquifying the Identifier Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
The vcdpost Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
The vcdiff Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
The vcdiff Utility Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454
The vcat Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
The vcat Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Generating Source Files From VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . 459
Writing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460
The vcsplit Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463
The vcsplit Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

12
 Feedback

Contents

The vcd2vpd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Options for Specifying EVCD Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
The vpd2vcd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
The Command File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
The vpdmerge Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474
Value Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
The vpdutil Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

9. Compile Time Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Partition Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Autopartitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Specifying Partitions Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Specifying Partitions in a V2K or SystemVerilog Configuration . . . . . . . . . 480
Specifying Partitions in an +optconfigfile File . . . . . . . . . . . . . . . . . . . . . . 481
Specifying Partitions in a VHDL Configuration File . . . . . . . . . . . . . . . . . . 481
Cell or Instance Based Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .482
Instance or Cell Based Partitions in a V2K/SV Configuration . . . . . . . . . . 483
Package Based Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Partition Compile Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
The Partition Compile Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
The Partition Compile Three Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . .486
Commonly Used Partition-Compile Options . . . . . . . . . . . . . . . . . . . . . . . .487
Limiting Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Specifying a Location for the Partition Data Generation . . . . . . . . . . . . . . 488
Partition Compile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Parallel Compilation With Partition Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Adaptive Scheduling Using fastpartcomp . . . . . . . . . . . . . . . . . . . . . . . . . 490
Turbo Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Multiple Test Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Multiple User Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Relocation Methods with Partition Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Using -simcopy Compile Time Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Using simcopy Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Turbo Compile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499
Cross-Module References (XMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502
Support for Skipping Intra Position Rewrite in Partition Compile Flow . . . . 503
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

13
 Feedback

Contents

Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504
Coding Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504
Scenarios Causing a Recompilation of a Partition . . . . . . . . . . . . . . . . . . . . . . 506
Achieving the Best Turnaround Time with Partition Compile . . . . . . . . . . . . . . 507
Profiling of Compilation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Improving Partition Compile Performance for SDF Designs . . . . . . . . . . . . . . 510
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .512
Rewriting XMRs to VPI Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .514
Partition Compile Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

10. VCS Distributed Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

VCS Distributed Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .517
Distributed Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Defining Communication Among Client Simvs . . . . . . . . . . . . . . . . . . . . . . . . . 520
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
RTL Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Multiple Sync Signals/Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Testbench Phase Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Testbench Phase Synchronization Based on User Task . . . . . . . . . . . . . . 527
UVM Testbench Phase Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Testbench Data Transfer of Class Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . .531
Save Replay Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Save Restore Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540
User Task to Print Class Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
VCD Dump per Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541
Bidirect Support Through Wired OR/AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Include Syntax in Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544

14
 Feedback

Contents

Configuration File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Server Launch as Independent Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
HDL Access Across Simvs from Verilog Source . . . . . . . . . . . . . . . . . . . . . . . 545
Distsim Release Recv Call for TB Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 547
TB Data Open Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Distributed Simulation Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Configuration File Checker Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Specifying User-Defined TCP Port for Server Launch . . . . . . . . . . . . . . . . . . . 550
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Specifying Early Simulation Finish Mechanism Across Simvs . . . . . . . . . . . . . 550
Cygnus PDF Profile Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
TB Sync Comp Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Packed Structure Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .551
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Constant Support in the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Support for Multiple TB Data Recv Requests . . . . . . . . . . . . . . . . . . . . . . . . . 552
Compile Time Configuration File Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .552
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Distsim Flow Without Shared File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Early Finish Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Quick Reference: VCS Distributed Simulation Options . . . . . . . . . . . . . . . . . . . . . 556

11. Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Compile-time Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Compile Once and Run Many Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Parallel Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Improving VCS Compile Performance and Capacity . . . . . . . . . . . . . . . . . . . . 561
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Runtime Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Using Radiant Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Compiling With Radiant Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Applying Radiant Technology to Parts of the Design . . . . . . . . . . . . . . . . .563
Improving Performance When Using PLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573
Enabling TAB File Capabilities in UCLI Using -debug_access . . . . . . . . . . . . .573

15
 Feedback

Contents

Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Impact on Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575
Obtaining VCS Consumption of CPU Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .576
Compile Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Dumping Design Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

12. Using X-Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

Introduction to X-Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Guidelines for Running X-Propagation Simulations . . . . . . . . . . . . . . . . . . . . . 582
Using the X-Propagation Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .584
Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Specifying X-Propagation Merge Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Compile Time Diagnostic Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Querying X-Propagation at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
X-Propagation Instrumentation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
Automatic Hardware Inference of Flip-Flops Enabled by Default . . . . . . . .592
X-Propagation Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
X-Propagation Configuration File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Xprop Instrumentation Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .599
Disabling Xprop on Library Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Process Based X-Propagation Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Support for XIndex Element Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
X-Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Index BSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Addressing Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Merge Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Index Selection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Disabling XIndex Merging for Read or Write Operations . . . . . . . . . . . . . . 605
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .610
Bounds Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

16
 Feedback

Contents

Detecting Unknown Values in Type Conversion Functions . . . . . . . . . . . . . . . 611

Time Zero Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Enabling X-propagation on RTL Block Containing Asserts Having System Task
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Handling Non-pure Functions Due to Static Lifetime . . . . . . . . . . . . . . . . . . . . 612
Supporting UCLI Commands for X-Propagation Control Tasks . . . . . . . . . . . . 613
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .613
UCLI Command to Specify the Merge Mode . . . . . . . . . . . . . . . . . . . . . . . 613
UCLI Command to Control Error Messages or Warning Messages . . . . . .614
VHDL Two-State Objects in X-Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Supported XValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Supported Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Supported Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616
Supported Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
X-Propagation Code Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621
If Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621
Verilog Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
VHDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Verilog Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
VHDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Unique/Priority Case Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Edge Sensitive Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Verilog Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
VHDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Verilog Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
VHDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Support for Active Drivers in X-Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Combinational Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Flip-flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Key points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Support for Ternary Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Renaming [Link] File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

17
 Feedback

Contents

13. Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .641

SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Using the Unified SDF Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642
Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Using the $sdf_annotate System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Using the -xlrm Option for SDF Retain, Gate Pulse Propagation, and Gate Pulse
Detection Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .644
Using the Optimistic Mode in SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .645
Using Gate Pulse Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .646
Generating Warnings During Gate Pulses . . . . . . . . . . . . . . . . . . . . . . . . . 646
Enhancing SDF Annotation to Support Nets Through SPICE . . . . . . . . . . . . . 647
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .649
Precompiling an SDF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Creating the Precompiled Version of the SDF File . . . . . . . . . . . . . . . . . . . . . .650
Precompiling SDF Without Compiling Design Files . . . . . . . . . . . . . . . . . . 650
Writing Precompiled SDF to a Different Directory . . . . . . . . . . . . . . . . . . . 650
SDF Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Delay Objects and Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
SDF Configuration File Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
The INTERCONNECT_MIPD Command . . . . . . . . . . . . . . . . . . . . . . . . . . 653
The MTM Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
The SCALE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .654
An SDF Example With Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Delays and Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Transport and Inertial Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
The Inertial Delay Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Enabling Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Pulse Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Pulse Control With Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Pulse Control With Inertial Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Specifying Pulse on Event or Detect Behavior . . . . . . . . . . . . . . . . . . . . . 665
Specifying the Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .667
Support for Delayed Annotation During Simultaneous Switching on Inputs . . . 669
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .669

18
 Feedback

Contents

Specifying Timing Control Attributes in the +optconfigfile File . . . . . . . . . . . . . 669

Using the Configuration File to Disable Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . .670
Using the timopt Timing Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Editing the [Link] File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Editing Potential Sequential Device Entries . . . . . . . . . . . . . . . . . . . . . . . .673
Editing Clock Signal Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .673
Using Scan Simulation Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
ScanOpt Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
ScanOpt Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Combinational Path Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Length of Test Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Improving the ScanOpt for Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
The Need for Negative Value Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . 679
The $setuphold Timing Check Extended Syntax . . . . . . . . . . . . . . . . . . . . 683
Negative Timing Checks for Asynchronous Controls . . . . . . . . . . . . . . . . .685
The $recrem Timing Check Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Enabling Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Other Timing Checks Using the Delayed Signals . . . . . . . . . . . . . . . . . . . . . . 687
IOPATH Delay Annotation Using Delayed Signals . . . . . . . . . . . . . . . . . . . . . . 690
Checking Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Toggling the Notifier Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
SDF Back-Annotation to Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . 692
How VCS Calculates Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Using VITAL Models and Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Validating and Optimizing a VITAL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Validating the Model for VITAL Conformance . . . . . . . . . . . . . . . . . . . . . . 695
Verifying the Model for Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Optimizing the Model for Performance and Capacity . . . . . . . . . . . . . . . . 696
Re-Verifying the Model for Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Understanding Error and Warning Messages . . . . . . . . . . . . . . . . . . . . . . 697
Distributing a VITAL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Simulating a VITAL Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Applying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Overriding Generic Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Understanding VCS Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Viewing VITAL Subprograms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Timing Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

19
 Feedback

Contents

VCS Naming Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

Negative Constraints Calculation (NCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Simulating in Functional Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .701
Understanding VITAL Timing Delays and Error Messages . . . . . . . . . . . . . . . 703
Negative Constraint Calculation (NCC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Conformance Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Support for Identifying Non-Annotated Timing Arc and Timing Check
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .716
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .716

14. Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Options For Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

15. Using OpenVera Native Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721

Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Importing VHDL Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Exporting OpenVera Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Using Template Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Multiple Program Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Configuration File Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Usage Model for Multiple Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
NTB Options and the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Class Dependency Source File Reordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Circular Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Dependency-based Ordering in Encrypted Files . . . . . . . . . . . . . . . . . . . . 743
Using Encrypted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743
Using Reference Verification Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . .744
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744

20
 Feedback

Contents

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .745

16. Using SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .746

Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Using UVM With VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Update on UVM-1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Update on UVM-ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Update on UVM-ieee-2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Update on UVM-ieee-2020-2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .748
Natively Compiling and Elaborating UVM-1.1d . . . . . . . . . . . . . . . . . . . . . . . . 749
Natively Compiling and Elaborating UVM-1.2 . . . . . . . . . . . . . . . . . . . . . . . . . 749
Natively Compiling and Elaborating UVM-ieee . . . . . . . . . . . . . . . . . . . . . . . . .750
Natively Compiling and Elaborating UVM-ieee-2020 . . . . . . . . . . . . . . . . . . . . 750
Compiling the External UVM Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Using the -ntb_opts uvm Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Explicitly Specifying UVM Files and Arguments . . . . . . . . . . . . . . . . . . . . 751
Accessing HDL Registers Through UVM Backdoor . . . . . . . . . . . . . . . . . . . . . 752
Generating UVM Register Abstraction Layer Code . . . . . . . . . . . . . . . . . . . . . 752
Recording UVM Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Recording UVM Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
UVM Template Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Using Mixed VMM/UVM Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .754
Migrating from OVM to UVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Where to Find UVM Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .756
Where to Find UVM Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .757
UVM-1.1d Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
UVM-VMM Interop Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Using VMM with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Using OVM with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Native Compilation and Elaboration of OVM 2.1.2 . . . . . . . . . . . . . . . . . . . . . .758
Compiling the External OVM Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Using the -ntb_opts ovm Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Explicitly Specifying OVM Files and Arguments . . . . . . . . . . . . . . . . . . . . 759
Recording OVM Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .760
Debugging SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .761
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
SystemVerilog Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

21
 Feedback

Contents

Extern Task and Function Calls through Virtual Interfaces . . . . . . . . . . . . . . . .763

Modport Expressions in an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .766
Interface Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Difference Between Extends and Implements . . . . . . . . . . . . . . . . . . . . . . 768
Cast and Interface Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Name Conflicts and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Interface Class and Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Package Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .774
Severity System Tasks as Procedural Statements . . . . . . . . . . . . . . . . . . . . . .775
Width Casting Using Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
The std::randomize() Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
SystemVerilog Bounded Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
wait() Statement with a Static Class Member Variable . . . . . . . . . . . . . . . . . . .780
Support for Consistent Behavior of Class Static Properties . . . . . . . . . . . . . . . 781
Parameters and Local Parameters in Classes . . . . . . . . . . . . . . . . . . . . . . . . . 782
SystemVerilog Math Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Streaming Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783
Packing (Used on RHS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783
Unpacking (Used on LHS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Packing and Unpacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Propagation and force Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Structures with Streaming Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Support for with Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Constant Functions in Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Support for Aggregate Methods in Constraints Using the “with” Construct . . . 788
Debugging During Initialization SystemVerilog Static Functions and Tasks in
Module Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Explicit External Constraint Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Using an Empty Constraint Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Generate Constructs in Program Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Error Condition for Using a Genvar Variable Outside of its Generate Block . . . 795
Randomizing Unpacked Structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
Using the Scope Randomize Method std::randomize() . . . . . . . . . . . . . . . 796
Using the Class Randomize Method randomize() . . . . . . . . . . . . . . . . . 799
Disabling and Re-enabling Randomization . . . . . . . . . . . . . . . . . . . . . . . . 801

22
 Feedback

Contents

Using In-Line Random Variable Control . . . . . . . . . . . . . . . . . . . . . . . . . . .803

Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .806
Using a Package in a SystemVerilog Module, Program, and Interface
Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .806
Disabling DPI Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Support for Overriding Parameter Values through Configuration . . . . . . . . . . . 808
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Precedence Override Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .810
Support for Inclusion of Dynamic Types in Sensitivity List . . . . . . . . . . . . . . . . 810
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Support for Assignment Pattern Expression in Non-Assignment Like
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
User-Defined Nettypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
The Resolution Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .813
Example of User-Defined Nettype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Example of User-Defined Nettype in Arrays . . . . . . . . . . . . . . . . . . . . . . . 814
Example of Nettype MDAs of Type Real . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Example of Nettype MDAs of Type Unpacked Struct . . . . . . . . . . . . . . . . 816
Support for Connecting Nettypes through Tranif Gates . . . . . . . . . . . . . . . 816
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .817
Generic Interconnect Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .818
Support for Associative Array With Unpacked Structure as Key . . . . . . . . . . . 818
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .818
Specifying a SystemVerilog Keyword Set by LRM Version at Command
Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
The -sv Compile-Time Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
The `begin_keywords and `end_keywords Compiler Directives . . . . . . . . 820
Support for .triggered Property with Clocking Block Name . . . . . . . . . . . . . . . 821
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Support for Intra Assignment Delay With Non-Blocking Assignments in Program
Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .822
Support for Array Query Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Array Query Functions With Associative Array . . . . . . . . . . . . . . . . . . . . . 822
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .823
Support for Nested Randsequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823

23
 Feedback

Contents

Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823

Support for Typed Constructor Call as an Argument to Task or Function . . . . .824
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .825
Support for Select of Unpacked Structure Array as an Argument to Task or
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .825
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .826
Support for Function Returning Unpacked Structure in Conditional Operator in a
Continuous Assignment Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Support for Built-in Method Which Returns Work Library Name . . . . . . . . . . . 827
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .828
Support for Function call in Clocking Block Hierarchical Expression . . . . . . . . 829
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .830
Extensions to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .830
Unique/Priority Case/IF Final Semantic Enhancements (-xlrm uniq_prior_final
Compile-Time Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Using Unique/Priority Case/If with Always Block or Continuous Assign . . .831
Using Unique/Priority Inside a Function . . . . . . . . . . . . . . . . . . . . . . . . . . .834
System Tasks to Control Warning Messages . . . . . . . . . . . . . . . . . . . . . . 836
LRM Compliant Behavior for the atohex Method . . . . . . . . . . . . . . . . . . . .837
Controlling Runtime Warning Messages Generated Using Unique/Priority If
Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .837
Support for Unique0 in Conditional Statements . . . . . . . . . . . . . . . . . . . . .839
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .839
Enhancements to the -xlrm uniq_prior_final Compile-Time Option . . . . . . 840
Single-Sized Packed Dimension Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Covariant Virtual Function Return Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Self Instance of a Virtual Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
UVM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .848
Support for Shuffle Method for Multi-Dimensional Arrays . . . . . . . . . . . . . . . . 848
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Enhanced Clocking Block Behavior When Skew is negedge/posedge . . . . . . 850
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Support for Slice of String Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Support for Randomization of Floating Point Variables . . . . . . . . . . . . . . . . . . 853
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853

24
 Feedback

Contents

Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853

Support for Unpacked Array Concatenation in the HighConn of Inout Port . . . 854
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .855
Support for Index Locator Methods for Multi-Dimensional Arrays . . . . . . . . . . 855
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .856
Support for String Method Substr() with a Single Argument . . . . . . . . . . . . . . 856
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Support for Assignment Pattern with Single-Bit Scalar Nets or Variables . . . . 857
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .858
Support for Reading Value of any Clock Variable . . . . . . . . . . . . . . . . . . . . . . 858
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

17. Aspect Oriented Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

Aspect-Oriented Extensions in SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Processing of Aspect-Oriented Extensions as a Precompilation Expansion . . . . . .861
Weaving Advice Into the Target Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Precompilation Expansion Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .868
Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Adding of Introductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Weaving of advices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Symbol Resolution Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
The hide_list Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .879

18. Using Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888

Support for Array Slice in Unique Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Support for Object Handle Comparison in Constraint Guards . . . . . . . . . . . . . . . . 890
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Support for Pure Constraint Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Support for SystemVerilog Bit Vector Functions in Constraints . . . . . . . . . . . . . . . 898
$countones Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .899

25
 Feedback

Contents

$onehot Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899

$onehot0 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
$countbits Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .901
$bits Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Inconsistent Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
Constraint Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Randomize Serial Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Solver Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Constraint Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Test Case Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .911
Using multiple +ntb_solver_debug arguments . . . . . . . . . . . . . . . . . . . . . . . . . 912
Summary for the +ntb_solver_debug Option . . . . . . . . . . . . . . . . . . . . . . . . . . 912
+ntb_solver_debug=serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
+ntb_solver_debug=trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
+ntb_solver_debug=profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
+ntb_solver_debug=extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
+ntb_solver_debug=verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Support for Save and Restore Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .913
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .914
Constraint Guard Error Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .914
Error Message Suppression Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .915
Flattening Nested Guard Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Pushing Guard Expressions into Foreach Loops . . . . . . . . . . . . . . . . . . . .916
Support for Array and Cross-Module References in std::randomize() . . . . . . . . . . 916
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Support for Cross-Module References in Constraints . . . . . . . . . . . . . . . . . . . . . . 918
XMR Function Calls in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
State Variable Index in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .920
Runtime Check for State Versus Random Variables . . . . . . . . . . . . . . . . . . . . 920
Array Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Using DPI Function Calls in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .921
Invoking Non-pure DPI Functions from Constraints . . . . . . . . . . . . . . . . . . . . . 922
Using Foreach Loops Over Packed Dimensions in Constraints . . . . . . . . . . . . . . . 924
Memories with Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924

26
 Feedback

Contents

Single Packed Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925

Multiple Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
MDAs with Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Single Packed Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Multiple Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Just Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
The foreach Iterative Constraint for Packed Arrays . . . . . . . . . . . . . . . . . . . . . 926
Randomized Objects in a Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Support for Typecast in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Strings in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Support for Dynamic MDA Elements in the Randomize Call Arguments . . . . . . . . 931
Supported Dynamic MDA Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Supported Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .933
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Support for Dynamic MDA in the Inside Expression Used in Constraints . . . . . . . .934
Supported Dynamic MDA Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Supported Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .935
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936
Support for Array Reduction Methods over MDAs in Constraints . . . . . . . . . . . . . .936
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
SystemVerilog LRM 1800™-2012 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Using Soft Constraints in SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Using Soft Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Soft Constraint Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .939
Soft Constraints Defined in Classes Instantiated as rand Members in Another
Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Soft Constraints Inheritance Between Classes . . . . . . . . . . . . . . . . . . . . . 941
Soft Constraints in AOP Extensions to a Class . . . . . . . . . . . . . . . . . . . . . 941
Soft Constraints in View Constraints Blocks . . . . . . . . . . . . . . . . . . . . . . . 944
Discarding Lower-Priority Soft Constraints . . . . . . . . . . . . . . . . . . . . . . . . 944
Unique Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Enhancement to the Randomization of Multidimensional Array Functionality . . . . .949
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Supporting Random Array Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .951

27
 Feedback

Contents

Random Array Index Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951

Function Call in Array Index Expression . . . . . . . . . . . . . . . . . . . . . . . . . . 952
Dynamic MDA With Loop Index Variable in Array Index Expression . . . . . 952
Random Array Indexed Sub-Array In Unique/Inside Constraints . . . . . . . . 953
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Supporting System Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
$size() System Function Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
$clog2() System Function Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Supporting Foreach Loop Iteration over Array Select . . . . . . . . . . . . . . . . . . . . . . .956
Support for Enumerated Type Methods in a Constraint Expression . . . . . . . . . . . . 957
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .957
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Improved Support for Function Evaluation in Constraints . . . . . . . . . . . . . . . . . . . 958

19. VCS Intelligent Coverage Optimization (ICO) . . . . . . . . . . . . . . . . . . . . . . . . . . .960

20. Extensions for SystemVerilog Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963

Support for Reference Arguments in get_coverage() and get_inst_coverage() . . . 963
get_coverage() method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .963
get_inst_coverage() method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964

21. OpenVera-SystemVerilog Testbench Interoperability . . . . . . . . . . . . . . . . . . . . 965

Scope of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Importing OpenVera Types Into SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Mailboxes and Semaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Integers and Bit-Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Structs and Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Connecting to the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Mapping Modports to Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Virtual Modports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975

28
 Feedback

Contents

Importing Clocking Block Members Into a Modport . . . . . . . . . . . . . . . . . . 976

Semantic Issues With Samples, Drives, and Expects . . . . . . . . . . . . . . . . . . . 980
Notes to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Blocking Functions in OpenVera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Constraints and Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .981
Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
For Two-Step Flow: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983

22. Using SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984

Using SVAs in the HDL Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Using VCS Checker Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Instantiating SVA Checkers in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Instantiating SVA Checkers in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Binding SVA to a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Binding SVA to a Design in VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
bind Statements In Your Verilog Source Files . . . . . . . . . . . . . . . . . . . . . . 990
Encapsulating Bind Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Salient Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .993
Inlining SVAs in the Verilog Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Inlining SVA in the VHDL design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Number of SystemVerilog Assertions Supported in a Module . . . . . . . . . . . . . 996
Controlling SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Compilation/Elaboration and Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . .997
Concatenating Assertion Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Assertion Monitoring System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999

29
 Feedback

Contents

Using Assertion Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002

Using System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1002
Using Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Starting and Stopping Assertions Using Assertion System Tasks . . . . . . 1004
Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Using a Report File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1008
Enhanced Reporting for SystemVerilog Assertions in Functions . . . . . . . . . . . . . 1008
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1009
Name Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Checker and Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Controlling Assertion Failure Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Options for Controlling Default Assertion Failure Messages . . . . . . . . . . . . . 1011
Using -assert no_default_msg[=SVA|OVA|PSL] Option . . . . . . . 1011
Using -assert quiet and -assert quiet1 Options . . . . . . . . . . . . 1012
Options to Control Termination of Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Option to Enable Compilation of OVA Case Pragmas . . . . . . . . . . . . . . . . . . 1014
Reporting Values of Variables in the Assertion Failure Messages . . . . . . . . . . . . 1014
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
Using $uniq_prior_checkon and $uniq_prior_checkoff System Tasks . . . . . . . . . 1016
Reporting Messages When $uniq_prior_checkon/$uniq_prior_checkoff System Tasks
are Called . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Assertion and Unique/Priority Re-Trigger Feature . . . . . . . . . . . . . . . . . . . . . . . . 1018
Flushing Off the Assertion Re-Trigger Feature . . . . . . . . . . . . . . . . . . . . . . . .1019
Enabling Lint Messages for Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1020
Fail-Only Assertion Evaluation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Treating x as true on an Assertion Precondition . . . . . . . . . . . . . . . . . . . . . . . . . .1024
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1025
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1025
Using SystemVerilog Constructs Inside vunits . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Calling $error Task When Else Block is Not Present . . . . . . . . . . . . . . . . . . . . . . 1027
Disabling Default Assertion Success Dumping in -debug_access Option . . . . . . 1028

30
 Feedback

Contents

Support for Success Count With -assert summary Option by Default . . . . . . . . . 1028
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1028
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1028
Disabling Success Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1030
Enhancement to Assertion Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1030
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1031
Support of String Variable to Assertion Control System Tasks . . . . . . . . . . . . . . . 1032
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1032
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
Support for Automatic Variables in Sampling Functions . . . . . . . . . . . . . . . . . . . . 1034
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1034
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1034
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
List of supported IEEE Std. 1800-2012 Compliant SVA Features . . . . . . . . . . . . 1035
Support for $countbits System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Support for Real Data Type Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Support for $assertcontrol Assertion Control System Task . . . . . . . . . . . . . . 1038
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1039
Enabling IEEE Std. 1800-2012 Compliant Features . . . . . . . . . . . . . . . . . . . 1039
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1039
Support for Strong Operators in Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Supressing the Run-time out of Bound Access Messages . . . . . . . . . . . . . . . . . .1041
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1041
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Reporting Runtime Violations for Unique/Unique0/Priority For and Foreach
Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1042
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Using -assert errmsg Runtime Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
SystemVerilog Assertions Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Debug Support for New Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Note on Cross Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045

31
 Feedback

Contents

23. Using Property Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046

Including PSL in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1046
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1048
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1049
PSL Assertions Inside VHDL Block Statements in Vunit . . . . . . . . . . . . . . . . . . . 1049
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1050
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
PSL Macro Support in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Using the %for Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Using the %if Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
Using Expressions with %if and %for Constructs . . . . . . . . . . . . . . . . . . . . . 1054
PSL Macro Support Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Using SVA Options, SVA System Tasks, and OV Classes . . . . . . . . . . . . . . . . . . 1055
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056

24. Using SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057

25. C Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059

Using PLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
Writing a PLI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
Functions in a PLI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Header Files for PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
PLI Table File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Using the PLI Table File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1075
Enabling ACC Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Enabling ACC Capabilities Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Using the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1076
Selected ACC Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Using VPI Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Support for VPI Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Integrating a VPI Application With VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083

32
 Feedback

Contents

PLI Table File for VPI Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084

Virtual Interface Debug Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1086
Unimplemented VPI Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1087
Modified VPI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Warning Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1091
Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Using VHPI Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Diagnostics for VPI/VHPI PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Using DirectC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Using Direct C/C++ Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1092
Functioning of C/C++ Code in a Verilog Environment . . . . . . . . . . . . . . . 1094
Declaring the C/C++ Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Calling the C/C++ Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Storing Vector Values in Machine Memory . . . . . . . . . . . . . . . . . . . . . . . 1100
Converting Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Avoiding a Naming Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Using Pass by Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Using Direct Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Example 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Example 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Using the vc_hdrs.h File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Access Routines for Multi-Dimensional Arrays . . . . . . . . . . . . . . . . . . . . 1110
Using Abstract Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
Using vc_handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
Using Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
Summary of Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Enabling C/C++ Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Mixing Direct And Abstract Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
Specifying the DirectC.h File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Extended BNF for External Function Declarations . . . . . . . . . . . . . . . . . . . . . 1149

33
 Feedback

Contents

Using DPI Open Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150

Using Multi-Dimensional Array as an Actual Argument for DPI Function . . . . . . . 1150
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152

26. Support for VHDL 2002, 2008 and 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153

VHDL 2002 Protected Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1153
Limitations of VHDL 2002 Protected Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
VHDL 2008 Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
Array Types and Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Adding Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Use Clause and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Support for Bit String Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Support for TO_STRING Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Support for External Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
Specifying The all Keyword in the Process Sensitivity List . . . . . . . . . . . . . . 1161
Support for Logical Unary Reduction Operator . . . . . . . . . . . . . . . . . . . . . . . 1162
Support for Matching Relational Operators for Bit and std_ulogic . . . . . . . . . 1163
Including Non-Static Expressions in Port Map . . . . . . . . . . . . . . . . . . . . . . . . 1163
Standard Environment Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Package Declaration and Instantiations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Referencing Interface Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1169
Overriding the Value Assigned to a Signal . . . . . . . . . . . . . . . . . . . . . . . . . . .1171
Forcing and Releasing Values of Signals . . . . . . . . . . . . . . . . . . . . . . . . 1172
Forcing and Releasing Ports of a Design . . . . . . . . . . . . . . . . . . . . . . . . 1172
Assigning Composite Value to a Collection of Signals . . . . . . . . . . . . . . .1174
Forcing and Releasing Assignment Written in a Subprogram . . . . . . . . . 1174
Forcing and Releasing Multiple Concurrent Assignments . . . . . . . . . . . . 1174
Debugging the Force and Release Assignments . . . . . . . . . . . . . . . . . . .1174
Matching Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1175
Conditional Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1177
Condition Operator in an Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Reading Output Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
2008 IEEE Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Overview of Additional IEEE Packages . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Resolved Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1191

34
 Feedback

Contents

Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192

Conditional and Selected Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Context Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Improved I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Support for Implicitly Constrained Array Elements . . . . . . . . . . . . . . . . . . . . . 1205
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
Support for Unconstrained Element Types . . . . . . . . . . . . . . . . . . . . . . . . . . .1206
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
Support for Enhanced Generics in Entity Interfaces . . . . . . . . . . . . . . . . . . . 1211
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
Support for Slices in Array Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
Support for Type Conversion in VHDL 2008 . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Support for Case Expression Subtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Example for Case Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223
Support for Subtypes of Ports and Parameters . . . . . . . . . . . . . . . . . . . . . . . 1226
Example for Subtypes of Ports and Parameters . . . . . . . . . . . . . . . . . . . 1226
Support for Static Composite Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Support for VHDL 2008 Enhanced Generics in Components . . . . . . . . . . . . 1234
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235
Support for VHDL 2008 Local Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Support for Unconstrained Elements in Generics and Generic Types . . . . . . 1243
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1244
VHDL 2019 Conditional Analysis Tool Directives . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1244
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1245
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247

27. SAIF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248

35
 Feedback

Contents

Using SAIF Files with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248

SAIF System Tasks for Verilog or Verilog-Top Designs . . . . . . . . . . . . . . . . . . . . 1249
The Flows to Generate a Backward SAIF File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Generating an SDPD Backward SAIF File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Generating a Non-SPDP Backward SAIF File . . . . . . . . . . . . . . . . . . . . . . . . 1252
SAIF Calls That Can Be Used on VHDL or VHDL-Top Designs . . . . . . . . . . . . . .1252
SAIF Support for Two-Dimensional Memories in v2k Designs . . . . . . . . . . . . . . . 1253
UCLI SAIF Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253
Criteria for Choosing Signals for SAIF Dumping . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Improving Simulation Time by Reducing the Overhead due to SAIF File
Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1254
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256

28. Encrypting Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257

IEEE Verilog Standard 1364-2005 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
The Protection Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Unsupported Protection Pragma Expressions . . . . . . . . . . . . . . . . . . . . . 1260
Other Options for IEEE Std 1364-2005 Encryption Mode . . . . . . . . . . . . . . . 1260
How Protection Envelopes Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
VCS Public Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
Creating Interoperable Digital Envelopes Using VCS - Example . . . . . . . . . . 1263
Discontinued -ipkey Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1266
IEEE VHDL Standard 1076-2008 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
VHDL 1076-2008 Encryption Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Encrypting the Entire VHDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . 1268
Encrypting the Parts of VHDL Source Files . . . . . . . . . . . . . . . . . . . . . . .1268
Using the Protection Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1268
Options for VHDL 1076-2008 Encryption Mode . . . . . . . . . . . . . . . . . . . .1270
Protection Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
The VCS Public Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1271
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1272
Example for Full Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1272
Example for Partial Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1273
Debug Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
Combining Encrypted and Unencrypted Code . . . . . . . . . . . . . . . . . . . . .1275

36
 Feedback

Contents

Assertion and Report Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276

Hierarchy Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
VHPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
VPD / VCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
128-bit Advanced Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Compiler Directives for Source Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Using Compiler Directives or Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279
-protect128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Automatic Protection Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Using Automatic Protection Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1283
-autoprotect128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1284
-auto2protect128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1284
-auto3protect128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1285
+protect option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
+putprotect+<Dir-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1286
+autoprotect[file_suffix] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1287
+auto2protect[file_suffix] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1287
+auto3protect[file_suffix] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1288
+deleteprotected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
+pli_unprotected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Protecting ‘include File Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
+autoincludeprotect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Enabling Debug Access to Ports and Instance Hierarchy . . . . . . . . . . . . . . . 1290
+autobodyprotect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Debugging Partially Encrypted Source Code . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Skipping Encrypted Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
gen_vcs_ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1291
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1292
Exporting The IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1293
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1293
IP Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293
IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294
IP User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294

37
 Feedback

Contents

29. VCS Fine-Grained Parallelism Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . .1295

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Compile Option for -fgp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Runtime Options for -fgp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Profiling to Detect Design Suitability for Parallelism . . . . . . . . . . . . . . . . . . . . . . . 1303
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304

30. Integrating VCS With Certitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305

Introduction to Certitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
VCS and Certitude Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Loading Designs Automatically in Verdi with Native Certitude . . . . . . . . . . . . . . . 1306
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1307
Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
Dumping and Comparing Waveforms in Verdi for SystemC Designs . . . . . . . . . . 1308
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1308
Point to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1309
Reducing Compilation Time in Native Certitude With VCS Partition Compile
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1310
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312

31. Integrating VCS with Vera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313

Setting Up Vera and VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Using Vera with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1314
Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315
Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315

32. VCS Mixed-Signal Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316

Introduction to VCS and CustomSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
Analyzing a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318
Elaborating a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318

38
 Feedback

Contents

Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318

Setting up the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1318
Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318
Required UNIX Paths and Variable Settings . . . . . . . . . . . . . . . . . . . . . . . . . 1319
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1319
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Scheduling Analog-to-Digital Events in the NBA Region . . . . . . . . . . . . . . . . . . . 1321
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1321
Support of Verilog Force and Release Assignments on Wreal Nets . . . . . . . . . . .1321
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1322
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323
Support for Wreal Nets in Verilog-AMS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1323
Support for SystemC Designs in Verilog-AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1325
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1325
Support for Wildcard Character and the -exclude Option in the Mixed Signal Control
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1328
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1329
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Enhancement to the force Command to Force SPICE Bus Ports . . . . . . . . . . . . .1329
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Inclusions in the MSV Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1331
UCLI force/release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Verilog force/release Procedural Statements . . . . . . . . . . . . . . . . . . . . . .1333
$hdl_xmr_force/$hdl_xmr_release Verilog System Tasks . . . . . . . . . . . . 1334
HDL_XMR_FORCE/HDL_XMR_RELEASE VHDL Sub-Programs . . . . . 1338
Bit-Select/Part-Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342
VCS with AMS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342
Integrating VCS With AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Setting up the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1343
Analyzing all VHDL, Verilog, Verilog-AMS Files . . . . . . . . . . . . . . . . . . . .1343
Elaborating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1343
Simulating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344

39
 Feedback

Contents

Limitations in VCS-AMS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344

Support for Predefined Nettypes in SystemVerilog-SPICE Flow . . . . . . . . . . . . . 1344
Predefined Nettypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1347
User-Defined Nettypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352
Support for SystemVerilog Nettypes in Mixed-Signal Simulation . . . . . . . . . . . . . 1352
Type Compatibility Between Nettype and VHDL Type/Subtype . . . . . . . . . . . 1353
Editing the Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1353
Rules for Type Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1353
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357
Using SystemVerilog Nettypes in Mixed-Signal Simulation . . . . . . . . . . . . . . . . . 1357
Supported Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357
Case 1 - SystemVerilog Testbench With SPICE and VHDL Children . . . .1357
Case 2 - SPICE Testbench With VHDL and SystemVerilog Children . . . .1358
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1358
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
Support for SystemVerilog Packed Array at Mixed Design Boundary . . . . . . . . . .1362
Editing the Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1363
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1363
Verilog-on-Top Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
VHDL-on-Top Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Support for Unmapped User-Defined Nettypes in SystemVerilog-SPICE Flow . . 1365
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1366
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Support for User-Defined Nettypes in Mixed-Signal Simulation . . . . . . . . . . . . . . 1368
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1368
Mixed-Signal Control Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1369
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
Enhancements in Type Coercion and Converter Insertions . . . . . . . . . . . . . . . . . 1371
Enhancements for Type Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
Support for Basic Type-Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
Enhancement to Type Coercion Issues for SV Interface . . . . . . . . . . . . . 1372

40
 Feedback

Contents

Enhancements in Diagnostics and Report Generation . . . . . . . . . . . . . . . . . .1372

Enhancements to Converter Insertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1372
Support for Merge Mode Converter Insertion . . . . . . . . . . . . . . . . . . . . . 1372
Quality Enhancements for Converter Insertion . . . . . . . . . . . . . . . . . . . . . . . .1373
Options for Coercion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Enhancements to Event Functions in SV-SPICE Flow . . . . . . . . . . . . . . . . . . . . . 1375
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375
Enhancements to Event Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1375
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1376
Example for the snps_cross Event Function . . . . . . . . . . . . . . . . . . . . 1376
Example for the snps_above Event Function . . . . . . . . . . . . . . . . . . . . 1376
Example for the snps_absdelta Event Function . . . . . . . . . . . . . . . . . 1376
Support for UPF Power-Aware Interface Elements in Mixed Signal Simulation
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1379
Association of UPF Supplies to Interface Elements . . . . . . . . . . . . . . . . . . . . 1379
Boundary SPICE Port With SPA Specified in the UPF . . . . . . . . . . . . . . 1380
Boundary SPICE Port With SRSN Specified in the UPF . . . . . . . . . . . . . 1380
SPICE Cell With Liberty Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
SPICE Cell Without SPA, SRSN, and Liberty Information . . . . . . . . . . . . 1380
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
Example-1: Input Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
Example-2: Output Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Real Number Modeling With VIZ Nettypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1386
KCL in Resolution Function for Voltage Calculation . . . . . . . . . . . . . . . . 1386
Using KCL for VIZ Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387
Library of Predefined VIZ Models and Resolution Function . . . . . . . . . . . . . . 1388
Connectivity Technologies in VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Interconnect Versus Wire in System Verilog LRM . . . . . . . . . . . . . . . . . . . . . 1388
Type-Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Detailed Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Basic Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Coercion in Wire Versus SV-Interconnect . . . . . . . . . . . . . . . . . . . . . . . . 1391
Command-Line Options for Coercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
VCS Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392
Local Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Converter Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
Converter Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1394
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1394
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1395

41
 Feedback

Contents

Predefined Converter Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397

Conversion Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399
Conversion Rule for wreal*_to_wreal*_type . . . . . . . . . . . . . . . . . . . . . . .1399
Conversion Rule for logic_to_current_r/logic_to_real/logic_to_voltage_r 1400
Conversion Rule for logic_to_th_wire . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
Conversion Rule for logic_to_v_wire* . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
Conversion Rule for logic_to_wreal* . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Conversion Rule for real_to_logic/voltage_r_to_logic/ wreal*_to_logic/
current_r_to_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Conversion Rule for th_wire_to_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Conversion Rule for v_wire*_to_logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403
Support for Wreal Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1407
Migrating From wreal Flow to nettype Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 1407
Support for Converting Wreal to Nettype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1410
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410

33. Integrating VCS with Specman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411

Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
Setting Up The Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Specman e code accessing VHDL only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Specman e Code Accessing Verilog Only . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
Specman e code accessing both VHDL and Verilog . . . . . . . . . . . . . . . . . . . 1416
Guidelines for Specifying HDL Path or Tick Access with VCS-Specman
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
Using specrun and specview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
Version Checker for Specman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1420
Precedence Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421

34. Integrating VCS with Denali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422

Setting Up Denali Environment for VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1422

42
 Feedback

Contents

Integrating Denali with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422

Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
Use Model for VHDL Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
Use Model for Verilog Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Execute Denali Commands at UCLI Prompt . . . . . . . . . . . . . . . . . . . . . . . . . 1425

35. Integrating VCS With Native Low Power (NLP) . . . . . . . . . . . . . . . . . . . . . . . . 1426

36. Unified UVM Library for VCS and Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427

Transaction/Message Recording in Verdi with VCS . . . . . . . . . . . . . . . . . . . . . . . 1427
Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
Enabling FSDB Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
Dumping Transactions or Messages in Verdi Flow . . . . . . . . . . . . . . . . . 1428

37. Debugging with Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
Generating Verdi KDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1431
Reading Compiled Design with Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
Compiling Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
Setting Up Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
Import KDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
Invoke Verdi in Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
Invoke Verdi in Post-Processing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Dumping FSDB File for Various Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Setting Up Verdi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Use Model for FSDB Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1436
Using VHDL Procedures or Verilog System Tasks . . . . . . . . . . . . . . . . . 1438
Using UCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1438
VCS Two-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
VCS Three-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1439

43
 Feedback

Contents

VCS Two-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439

VCS Three-step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1440
Interactive and Post-Processing Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
Interactive Simulation Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
Simulation Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Key Points to Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Post-Processing Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Reducing Disk Space for Post-Process Only Debug . . . . . . . . . . . . . . . . 1445

A. VCS Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446

Simulation Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1446
Setup Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
Analysis Setup Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
Compilation/Elaboration Setup Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1452
Simulation Setup Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1453
C Compilation and Linking Setup Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
Timescale Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
Understanding `timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1459
Verilog only and Verilog Top Mixed Design . . . . . . . . . . . . . . . . . . . . . . . 1461
VHDL only and VHDL Top Mixed Designs . . . . . . . . . . . . . . . . . . . . . . . 1461
Setting up Simulator Resolution From Command Line . . . . . . . . . . . . . . 1462
Other Useful Timescale Related Options . . . . . . . . . . . . . . . . . . . . . . . . .1463
Non-Compatible Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1465
Optional Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
Using Environment Variables in Verilog Source Code . . . . . . . . . . . . . . . . . . . . . 1468

B. Analysis Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469

The vhdlan Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1469
Using Smart Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1474
Syntax: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
Syntax: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474

44
 Feedback

Contents

Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475
The vlogan Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1475

C. Compilation/Elaboration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488

Option for Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
Options for Accessing Verilog Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
Options for Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1493
Option to Save Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1494
Options for Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
Option for SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
Option to Enable Optimized Debug Capabilities and FSDB Dumping for Testbench
Root Cause Analysis (TBRCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
Options for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1494
Options to Enable Compilation of OVA Case Pragmas . . . . . . . . . . . . . . . . . . . . 1502
Options for Native Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
Options for Different Versions of Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1507
Option for Initializing Verilog Variables, Registers and Memories with Random
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1509
Option for Initializing Verilog Variables, Registers and Memories in Selective Parts of
a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
Options for Selecting Register or Memory Initialization . . . . . . . . . . . . . . . . . . . . 1514
Options for Using Radiant Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
Options for Starting Simulation Right After Compilation . . . . . . . . . . . . . . . . . . . . 1514
Options for Specifying Delays and SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . .1515
Options for Compiling an SDF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
Options for Specify Blocks and Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
Options for Pulse Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1521
Options for Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
Options for Profiling Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
Options to Specify Source Files and Compilation/Elaboration Options in a File . . 1523
Options for Compiling Runtime Options Into the Executable . . . . . . . . . . . . . . . . 1525
Options for PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525

45
 Feedback

Contents

Options to Enable the VCS DirectC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . .1527

Options for Flushing Certain Output Text File Buffers . . . . . . . . . . . . . . . . . . . . . 1528
Options for Simulating SWIFT VMC Models and SmartModels . . . . . . . . . . . . . . 1528
Options for Controlling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1529
Option to Run VCS in Syntax Checking Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
Options for Cell Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
Options for Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
Options for Controlling the Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
Options for Controlling the C Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1537
Options for Source Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1539
Options for Mixed Analog/Digital Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1539
Unified Option to Change Generic and Parameter Values . . . . . . . . . . . . . . . . . . 1540
Options for Changing Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
Checking for x and z Values in Conditional Expressions . . . . . . . . . . . . . . . . . . . 1541
Options for Detecting Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1541
Options to Specify the Time Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
Option to Exclude Environment Variables During Timestamp Checks . . . . . . . . . 1545
Options for Overriding Generics and Parameters . . . . . . . . . . . . . . . . . . . . . . . . .1545
Suppressing Reporting of Generic Override Messages . . . . . . . . . . . . . . . . . 1549
Global -check_all Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1550
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
Option to Enable Bounds Check at Compile-Time . . . . . . . . . . . . . . . . . . . . . . . . 1551
Runtime Checks for Out-of-Bounds Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
Error-[DT-OBAE] Out of Bounds Access for Queues . . . . . . . . . . . . . . . . . . . 1552
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
Error-[DT-OBAE] Out of Bounds Access for Dynamic Arrays . . . . . . . . . . . . 1553
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
Warning-[AOOBAW] Array Out of Bounds Access for Fixed Size Unpacked
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
Warning-[AOOBAW] Array Out of Bounds Access for Fixed Size Packed
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554

46
 Feedback

Contents

Error-[DT-OBAE] Intermediate Access for Dynamic Arrays . . . . . . . . . . . . . . 1555

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
Warning-[AAIIW] Array Access with Intermediate Index . . . . . . . . . . . . . . . . .1555
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
Warning-[AAIIW] Array Access with Intermediate Index for Fixed Size Packed
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
Option to Enable Extra Runtime Checks in VHDL . . . . . . . . . . . . . . . . . . . . . . . . 1556
Error-[SIMERR_FDIVZERO_SCOPE] Divide by Zero Error . . . . . . . . . . . . . .1557
Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
Error-[SIMERR_INCONSISTENTIC] Incorrect Binding Range . . . . . . . . . . . .1557
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
Error-[SIMERR_INCONSISTENTIS] Subtype Constraints Inconsistencies . . 1558
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
Options to Detect Multiple Conflicts on Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1559
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1562
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
Gate-Level Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
Local Timescale Precision on Timing Check for Modules . . . . . . . . . . . . . . . 1569
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
Using configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1569
Using the -auto_tchk_local_precision option . . . . . . . . . . . . . . . . 1570
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
Options for Additional Multiple Driver Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1572
Default behavior: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
Behavior with -varindex_drivers option: . . . . . . . . . . . . . . . . . . . . . 1572
Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1573
Default behavior: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
Behavior with the -ntb_opts multi_driver_no_source_info
option: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
Specifying Directories for ‘include Searches . . . . . . . . . . . . . . . . . . . . . . . . . 1574
Enable the VCS/SystemC Cosimulation Interface . . . . . . . . . . . . . . . . . . . . . 1574
TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1575
Suppressing Port Coersion to inout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575

47
 Feedback

Contents

Allow Inout Port Connection Width Mismatches . . . . . . . . . . . . . . . . . . . . . . .1575

Specifying a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
Enabling Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1575
Enabling Identifier Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1576
Specifying a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
Changing Source File Identifiers to Upper Case . . . . . . . . . . . . . . . . . . . . . . 1577
Defining a Text Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1577
Undefining a Text Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1577
Option for Macro Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1578
Specifying the Name of the Executable File . . . . . . . . . . . . . . . . . . . . . . . . . 1579
Returning The Platform Directory Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
Maximum Donut Layers for a Mixed HDL Design . . . . . . . . . . . . . . . . . . . . . 1579
Enabling feature beyond VHDL LRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
Enabling Loop Detect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
Changing the Time Slot of Sequential UDP Output Evaluation . . . . . . . . . . . 1580
Gate-Level Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1580
Option to Omit Compilation of Code Between Pragmas . . . . . . . . . . . . . . . . 1581
Generating a List of Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1582
Passing Options Starting With "-" to VCS in -R Flow . . . . . . . . . . . . . . . . . . . 1583
Option for Dumping Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . 1583

D. Simulation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585

Options for Simulating Native Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
Options for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1591
Options to Control Termination of Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
Options for Enabling and Disabling Specify Blocks . . . . . . . . . . . . . . . . . . . . . . . 1599
Options for Specifying When Simulation Stops . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
Options for Recording Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
Options for Controlling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1600
Options for VPD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
Options for VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
Options for Specifying Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1603
Options for Flushing Certain Output Text File Buffers . . . . . . . . . . . . . . . . . . . . . 1604
Options for Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
Option to Specify User-Defined Runtime Options in a File . . . . . . . . . . . . . . . . . .1605

48
 Feedback

Contents

Option for the Support of Reading Gzipped Files . . . . . . . . . . . . . . . . . . . . . . . . .1605

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
Supported APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
Option for Initializing Verilog Variables, Registers and Memories at Runtime . . . .1607
Option for Initializing Verilog Variables, Registers and Memories in Selective Parts of
a Design at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Viewing the Compile Time Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Recording Where ACC Capabilities are Used . . . . . . . . . . . . . . . . . . . . . . . . 1609
Suppressing the $stop System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Enabling User-defined Plusarg Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Enabling Overriding the Timing of a SWIFT SmartModel . . . . . . . . . . . . . . . .1610
Enabling feature beyond VHDL LRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Enabling Loop Detect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Specifying acc_handle_simulated_net PLI Routine . . . . . . . . . . . . . . . . . . . . 1611
Loading DPI Libraries Dynamically at Rutime . . . . . . . . . . . . . . . . . . . . . . . . 1611
Loading PLI Libraries Dynamically at Runtime . . . . . . . . . . . . . . . . . . . . . . . .1612
Independent Seeding Across Multiple Instances . . . . . . . . . . . . . . . . . . . . . . 1612

E. Verilog Compiler Directives and System Tasks . . . . . . . . . . . . . . . . . . . . . . . . 1613

Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
Compiler Directives for Cell Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
Compiler Directives for Setting Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1614
Compiler Directives for Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
Compiler Directives for Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
Compiler Directives for Back Annotating SDF Delay Values . . . . . . . . . . . . . 1616
Compiler Directives for Source Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
General Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1617
Compiler Directive for Including a Source File . . . . . . . . . . . . . . . . . . . . .1617
Compiler Directive for Setting the Time Scale . . . . . . . . . . . . . . . . . . . . . 1617
Compiler Directive for Specifying a Library . . . . . . . . . . . . . . . . . . . . . . . 1617
Compiler Directive for File Names and Line Numbers . . . . . . . . . . . . . . .1618
Unimplemented Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
System Tasks for SystemVerilog Assertions Severity . . . . . . . . . . . . . . . . . . 1619
System Tasks for SystemVerilog Assertions Control . . . . . . . . . . . . . . . . . . . 1619

49
 Feedback

Contents

System Tasks for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . 1620

System Tasks for VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1620
System Tasks for LSI Certification VCD and EVCD Files . . . . . . . . . . . . . . . 1622
System Tasks for VPD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1624
System Tasks for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . 1628
System Tasks for Executing Operating System Commands . . . . . . . . . . . . . 1629
System Tasks for Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
System Tasks for Data Type Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
System Tasks for Displaying Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
System Tasks for File I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
System Tasks for Loading Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
System Tasks for Time Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
System Tasks for Simulation Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
System Tasks for Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
Timing Checks for Clock and Control Signals . . . . . . . . . . . . . . . . . . . . . . . . 1635
System Tasks for PLA Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
System Tasks for Stochastic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
System Tasks for Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
System Tasks for Probabilistic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . .1637
System Tasks for Resetting VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
General System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
Checks for a Plusarg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
Counting the Drivers on a Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
Depositing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1639
Fast Processing Stimulus Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
Saving and Restarting The Simulation State . . . . . . . . . . . . . . . . . . . . . . 1639
Checking for X and Z Values in Conditional Expressions . . . . . . . . . . . . 1639
Calculating Bus Widths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
Displaying the Method Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
IEEE Standard System Tasks Not Yet Implemented . . . . . . . . . . . . . . . . . . . 1644

F. PLI Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1645

Access Routines for Reading and Writing to Memories . . . . . . . . . . . . . . . . . . . . 1645
acc_setmem_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
acc_getmem_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
acc_clearmem_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
acc_setmem_hexstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651

50
 Feedback

Contents

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
acc_getmem_hexstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
acc_setmem_bitstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
acc_getmem_bitstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
acc_handle_mem_by_fullname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
acc_readmem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
acc_getmem_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1659
acc_getmem_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
acc_getmem_word_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
acc_getmem_word_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1660
Access Routines for Multidimensional Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . .1661
tf_mdanodeinfo and tf_imdanodeinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
acc_get_mda_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
acc_get_mda_word_range() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
acc_getmda_bitstr() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1665
acc_setmda_bitstr() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1666
Access Routines for Probabilistic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . .1667
vcs_random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1668
vcs_random_const_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
vcs_random_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
vcs_dist_uniform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
vcs_dist_normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
vcs_dist_exponential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
vcs_dist_poisson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Access Routines for Returning a Pointer to a Parameter Value . . . . . . . . . . . . . . 1672
acc_fetch_paramval_str . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
Access Routines for Line Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
acc_mod_lcb_add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
acc_mod_lcb_del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
acc_mod_lcb_enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
acc_mod_lcb_fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
acc_mod_lcb_fetch2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
acc_mod_sfi_fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
Access Routines for Source Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
vcsSpClose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
vcsSpEncodeOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683

51
 Feedback

Contents

vcsSpEncodeOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
vcsSpEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
vcsSpGetFilePtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
vcsSpInitialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
vcsSpOvaDecodeLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1687
vcsSpOvaDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
vcsSpOvaEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1689
vcsSpSetDisplayMsgFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
vcsSpSetFilePtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1690
vcsSpSetLibLicenseCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
vcsSpSetPliProtectionFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
vcsSpWriteChar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
vcsSpWriteString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1693
Access Routine for Signal in a Generate Block . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
acc_object_of_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
VCS API Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1695
Vcsinit() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
VcsSimUntil() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1695

52
 Feedback

Preface
The Verification Methodology Manual (VMM) describes the framework for developing
re-usable verification components, subenvironments and environments. The preface
discusses the following:
• Customer Support
• Synopsys Statement on Inclusivity and Diversity

Customer Support
For any online access to the self-help resources, you can refer to the documentation and
searchable knowledge base available in SolvNetPlus.
To obtain support for your VCS product, choose one of the following:
• Open a Case through SolvNetPlus.
Go to and provide the requested information, including:
◦ Product - L1 as VCS
◦ Case Type
Fill in the remaining fields according to your environment and issue.
• Send an e-mail message to vcs_support@[Link]
Include product name (L1), sub-product name/technology (L2), and product version in
your e-mail, so it can be routed correctly.
Your e-mail will be acknowledged by automatic reply and assigned a Case number
along with Case reference ID in the subject (ref:_...:ref).
For any further communication on this Case via e-mail, send an e-mail to
vcs_support@[Link] and ensure to have the same Case ref ID in the
subject header or else it will open duplicate Cases.
Note:
In general, we need to be able to reproduce the problem in order to fix it, so
a simple model demonstrating the error is the most effective way for us to
identify the bug. If that is not possible, then provide a detailed explanation
of the problem along with complete error and corresponding code, if any/
permissible.

Verification Continuum™ VCS User Guide 53

V-2023.12
 Feedback

Contents

Synopsys Statement on Inclusivity and Diversity

Synopsys is committed to creating an inclusive environment where every employee,
customer, and partner feels welcomed. We are reviewing and removing exclusionary
language from our products and supporting customer-facing collateral. Our effort also
includes internal initiatives to remove biased language from our engineering and working
environment, including terms that are embedded in our software and IPs. At the same
time, we are working to ensure that our web content and software applications are usable
to people of varying abilities. You may still find examples of non-inclusive language in our
software or documentation as our IPs implement industry-standard specifications that are
currently under review to remove exclusionary language.

Verification Continuum™ VCS User Guide 54

V-2023.12
 Feedback

1
Getting Started
®
VCS is a high-performance, high-capacity simulator that incorporates advanced, high-
level abstraction verification technologies into a single open native platform.
VCS is a compiled code simulator. It enables you to analyze, compile, and simulate
Verilog, VHDL, mixed-HDL, SystemVerilog, OpenVera and SystemC design descriptions. It
also provides you with a set of simulation and debugging features to validate your design.
These features provide capabilities for source-level debugging and simulation result
viewing.
VCS accelerates complete system verification by delivering the fastest and highest
capacity Verilog, VHDL, and mixed HDL simulation for RTL functional verification. The
seamless support for mixed-language simulation of VCS provides a high performance
solution to your IP integration problems and gate-level simulation. VCS supports VHDL
External Names feature introduced in the 1076-2008-IEEE Standard VHDL Language
Reference Manual.
This chapter includes the following sections:
• Simulator Support with Technologies
• Simulation Preemption Support
• Setting Up the Simulator
• Using the Simulator
• Default Time Unit and Time Precision
• Searching Identifiers in the Design Using UNIX Commands

Verification Continuum™ VCS User Guide 55

V-2023.12
 Feedback
Chapter 1: Getting Started
Simulator Support with Technologies

Simulator Support with Technologies

VCS supports the following IEEE standards:
• The Verilog language as defined in the Standard Verilog Hardware Description
Language (IEEE Std 1364).
• The VHDL Language as defined in the Standard VHDL Hardware Description
Language (IEEE VHDL 1076-1993).
• The SystemVerilog language (with some exceptions) as defined in the IEEE Standard
for SystemVerilog -- Unified Hardware Design, Specification, and Verification Language
(IEEE Std 1800™ - 2012)
In addition to its standard Verilog, VHDL, and mixed HDL and SystemVerilog compilation
and simulation capabilities, VCS includes the following integrated set of features and tools:
• SystemC - VCS / SystemC Co-simulation Interface enables VCS and the SystemC
cosimulating with Verilog
SystemC

modeling environment to work together when simulating a system described in

the Verilog, VHDL, and SystemC languages. For more information, refer to “Using
SystemC” .
• Verdi — For more information, refer to “Using Verdi”.
• Unified Command-line Interface (UCLI) — For more information, refer to “Using UCLI” .
• Built-In Coverage Metrics — a comprehensive built-in coverage analysis functionality
that includes condition, toggle, line, finite-state-machine (FSM), path, and branch
coverage. You can use coverage metrics to determine the quality of coverage of your
verification test and focus on creating additional test cases. You only need to compile
once to run both simulation and coverage analysis. For more information, refer to
“Coverage” .
• DirectC Interface — this interface allows you to directly embed user-created C/C
++ functions within your Verilog design description. This results in a significant
improvement in ease-of-use and performance over existing PLI-based methods. VCS
atomically recognizes C/C++ function calls and integrates them for simulation, thus
eliminating the need to manually create PLI files.
VCS supports Synopsys DesignWare IPs, VCS Verification Library, VMC models, Vera,
CustomSim, CustomSimHSIM and CustomSim FineSim. For information on integrating
VCS with CustomSim, refer to the Discovery AMS: Mixed-Signal Simulation User Guide.
For more information about CutomSim FineSim, see the FineSim User Guide: Pro and
SPICE Reference.
VCS can also be integrated with third-party tools such as Specman, Denali, and other
acceleration and emulation systems.

Verification Continuum™ VCS User Guide 56

V-2023.12
 Feedback
Chapter 1: Getting Started
Simulation Preemption Support

Simulation Preemption Support

VCS supports simulation preemption. If you suspend a VCS simulation, VCS waits for the
safe memory point to suspend the job and checks in the license. When VCS simulation
is resumed at a later time, it checks out the license and continues the simulation from the
point where it was suspended. You can use ctrl+z or kill –TSTP <pid> to preempt
simulation in VCS.

Setting Up the Simulator

This section outlines the basic steps for preparing to run VCS. It includes the following
topics:
• Verifying Your System Configuration
• Obtaining a License
• Setting Up Your Environment
• Creating a synopsys_sim.setup File
• Displaying Setup Information
• Displaying Design Information Analyzed Into a Library

Verifying Your System Configuration

You can use the [Link] script to check if your system and environment match the
QSC requirements for a given release of a Synopsys product. The QSC (Qualified System
Configurations) represents all system configurations maintained internally and tested by
Synopsys.
To check whether the system you are on meets the QSC requirements, enter:
%

When you encounter any issue, run the script with tracing enabled to capture the output
and contact Synopsys. To enable tracing, you can either uncomment the set -x line in
the [Link] file or enter the following command:
%

Use [Link] -v to generate a more verbose output stream including the exact path for
various binaries used by the script, etc. For example:
%

Verification Continuum™ VCS User Guide 57

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

Note:
If you copy the [Link] script to another location before using it, you must
also copy the [Link] data file to the same directory.
You can also refer to the “Supported Platforms and Products” section of the VCS Release
Notes for the list of supported platforms and recommended C compiler and linker versions.

Obtaining a License
You must have a license to run VCS. To obtain a license, contact your local Synopsys
Sales Representative. Your Sales Representative will need the hostid for your machine.
To start a new license, do the following:
► Verify that your license file is functioning correctly:
% license_file_pathname

Running this licensing utility ensures that the license file is not corrupt. You should see an
“OK” for every INCREMENT statement in the license file.
Note:
The snpslmd platform binaries and accompanying FlexLM utilities are shipped
separately and are not included with this distribution. You can download
these binaries as part of the Synopsys Common Licensing (SCL) kit from the
Synopsys Web Site at:
[Link]

1. Start the license server:

% logfile_pathname

2. Set the LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE environment variable to point to

the license file. For example:
% /u/edatools/vcs/[Link]

or
% /u/edatools/vcs/
[Link]

You can use SNPSLMD_LICENSE_FILE environment variable to set licenses explicitly for
Synopsys tools.
If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the
LM_LICENSE_FILE environment variable.

Verification Continuum™ VCS User Guide 58

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

Note:
A single VCS license (under Synopsys’ Common Licensing Program) enables
you to run Verilog-only, VHDL-only, or mixed-HDL simulations.

Setting Up Your Environment

To run VCS, you need to set the following environment variables:
Environment variables

• $VCS_HOME environment variable

Set the environment variable VCS_HOME to the path where VCS is installed as shown
below:
% installation_path

• $PATH environment variable

Set your UNIX PATH variable to $VCS_HOME/bin as shown below:
% set path = ($VCS_HOME/bin $path)

OR
% setenv PATH $VCS_HOME/bin:$PATH

• LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE environment variable:

Set the license variable LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE to your license file
as shown below:
% Location_to_the_license_file

OR
% /u/edatools/vcs/
[Link]

You can use SNPSLMD_LICENSE_FILE environment variable to set licenses explicitly for
Synopsys tools.
If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the
LM_LICENSE_FILE environment variable.

For additional information on environment variables, see “VCS Environment Variables” .

Verification Continuum™ VCS User Guide 59

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

Creating a synopsys_sim.setup File

VCS uses the synopsys_sim.setup file to configure its environment for VHDL and mixed-
HDL designs. This file maps the VHDL design library names to specific host directories,
sets search paths, and assigns values to simulation control variables.
setup files
synopsys_sim.setup

When you invoke VCS, it looks for the synopsys_sim.setup files in the following three
directories with the same order:
• Master setup directory
The synopsys_sim.setup file in the $VCS_HOME/bin directory contains default settings
for your entire installation. VCS reads this file first.
• Your home directory
VCS reads the setup file in your home directory second, if present. The settings in this
file take precedence over the conflicting settings in your synopsys_sim.setup file in
the master setup directory, and carry over the rest.
• Your run directory
VCS reads the setup file in your design directory last. The settings in this file take
precedence over the conflicting settings in your synopsys_sim.setup file in the master
setup directory, and the synopsys_sim.setup file in your home directory, and will carry
over the rest. You can use this file to customize the environment for a particular design.
Note:
This is the directory you invoke and run VCS from; it is not the directory
where you store or generate your design files.
The key components of the setup file are the name mappings in the design libraries and
the variable assignments. See the following sections for additional information.
The following rules pertain to setup files:
• Blank lines are ignored.
• Physical directory names are case-sensitive.
• All commented lines begin with two dashes (--).
• The backslash character (\) is used for line continuation.
The following is a sample synopsys_sim.setup file:
--VCS setup file for ASIC
--Mapping default work directory

WORK > DEFAULT

DEFAULT : ./work

Verification Continuum™ VCS User Guide 60

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

--Library Mapping

STATS_PKG : ./stat_work
MEM_PKG : ./mem_work

--Simulation variables

TIMEBASE = ps

TIME_RESOLUTION = 1NS

The Concept of a Library in VCS

When you analyze a design, VCS stores the intermediate files in a design library,
also called as a logical library. This logical library is pointed to a physical library,
which is a physical directory in your UNIX file system. You specify this mapping in the
synopsys_sim.setup file as shown in the following lines:
WORK > DEFAULT
DEFAULT : ./worklib

In the above example, WORK is the default logical library and is mapped to the physical
library worklib. With the above setting, by default VCS stores all the intermediate files in
the library work, and it errors out if the library work does not exist in the specified path.

Library Name Mapping

For flexibility in library naming, VCS allows you to create multiple logical libraries each
one pointing to a different physical library. The syntax to map a logical library to a physical
library is shown below:
logical_name : physical_name

Note:
Logical library names are case insensitive.
The following examples show two logical libraries ALU8 and ALU16 mapped to alu_8bit
and alu_16bit physical libraries. During analysis, you can use the -work option to
analyze the files into the respective libraries.
ALU8 : ./alu_8bit
ALU16 : ./alu_16bit

The VCS built-in standard libraries have the following default name mappings:
IEEE : $VCS_HOME/$ARCH/packages/IEEE/lib
SYNOPSYS : $VCS_HOME/$ARCH/packages/synopsys/lib

Verification Continuum™ VCS User Guide 61

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

In these default mappings, $ARCH is any one of the following - sparcOS5, sparc64, linux,
amd64, rs6000, hp32, suse32, or suse64.
Use these built-in libraries in your design, whenever possible, to get maximum
performance from VCS.

Including Other Setup Files

To include any other setup files, specify the following in the synopsys_sim.setup file:
OTHERS = [ ]

Note that you cannot override the environment settings using this file. In addition, files
included in this manner can be nested up to 8 levels.
If VCS is unable to open the specified file, it exits with the following error message:
Error: analysis preParsing vhdl-314
snps_setup fatal error: (Severity SNPS SETUP USER
FATAL) Cannot open included setup file "user_setup.file"

Using the SYNOPSYS_SIM_SETUP Environment Variable

You can also specify a setup file to define VCS setup variables. To do this, set the
SYNOPSYS_SIM_SETUP variable to your setup file as shown below:
% setenv SYNOPSYS_SIM_SETUP my_setup

Note that you can use any name for this setup file; you do not need to use
synopsys_sim.setup.

The settings in this file take precedence over conflicting settings in any regular setup file in
the current directory, home directory, or installation directory, and is also searched during
simulation. If the file you specify in the SYNOPSYS_SIM_SETUP variable cannot be opened,
VCS issues the following message:
Warning: analysis preParsing vhdl-315
snps_setup message: (Severity SNPS SETUP USER WARNING)
Cannot open setup file "synopsys_sim.setup"

Supporting VHDL Non-Locally Static Aggregates

VCS supports non-static aggregates with two choices and with one others choice. This
supported scenarios must satisfy the following conditions:
• Array aggregate with one non-locally static choice plus others. However, if the range
of the aggregate is not locally static, the choice can be locally static or non-locally
static.
• Choice is a single element.

Verification Continuum™ VCS User Guide 62

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

• The element type is scalar.

• For multi-dimensional array aggregates and record aggregates, only the non-locally-
static aggregate must be at the bottom.
Use Model
To enable this feature, use the COMPLEX_AGGREGATES = TRUE variable in the
synopsys_sim.setup file.

Usage Example
Consider the following [Link] file. The new supported value is highlighted in the
example.

Example 1 [Link] file

entity top is
generic (
BITS: natural := 8
);
end entity top;

architecture arch of top is

constant VAL0 : bit_vector(BITS-1 downto 0) := (BITS-1 => '1', others
=> '0');
constant VAL1 : bit_vector(8-1 downto 0) := (8-1 => '1', others =>
'0');
begin
assert VAL0=VAL1 report "wrong aggregate" severity error;
end architecture arch;

Run the example using the following commands:

• vhdlan [Link]
• vcs top
• ./simv

Displaying Setup Information

To list and display all current setup information in your synopsys_sim.setup file, enter the
following command at the prompt:
% show_setup
show_setup command

The full syntax of the show_setup command is as follows:

% show_setup [-v] [-lib]

Verification Continuum™ VCS User Guide 63

V-2023.12
 Feedback
Chapter 1: Getting Started
Setting Up the Simulator

The show_setup command options are:

-v

Displays the version number and exits.

-lib

Displays the library mapping.

The show_setup command lists setup information in alphabetical order.
The following example uses show_setup to check if optimizations are on for event
simulation:
% show_setup | grep OPTIMIZE

The result of this command is:

OPTIMIZE = FALSE

Note:
The show_setup command shows the cumulative effect of reading each of the
three possible synopsys_sim.setup files.

Displaying Design Information Analyzed Into a Library

The llib executable displays the following information:
• Entity name, module name, architecture name, configuration name, location of the
source file, VCS version, and the timestamp information as and when the file is
analyzed.
• All design unit names analyzed in the specified library.
• Architecture name of each entity and package body name of each package.
By default, llib lists all design units analyzed into the default logical library.
The syntax of llib is as follows:
% llib [-l] [-r] [-lib ] design_unit_name

The llib command options are:

-l

Displays entity name, architecture name, configuration name, location of the source file,
VCS version and the timestamp for when the design file was analyzed.
-r

Verification Continuum™ VCS User Guide 64

V-2023.12
 Feedback
Chapter 1: Getting Started
Using the Simulator

Displays architecture name of each entity, and package body name of each package.
-lib path

Displays the list of design units, package name, and the configuration name in the
specified logical library.
design_unit_name

design_unit_name can be a module, entity, architecture, package body, or a

configuration.
Example
% llib -l ZERO

Library: worklibs
ENTITY ZERO
Source file : /u/snps/vhdl/[Link]
VCS Version : Y-2006.06-SP1-5
Timestamp : Mon Aug 13 [Link] 2007
Library (four state only): worklibs

As illustrated in the example, the design unit ZERO is analyzed into the worklibs logical
library. The llib executable also provides the location of the source file, VCS version
used to analyze the design unit, and the timestamp information.

Using the Simulator

You can use the following flows to simulate a design using VCS:
• Two-step Flow
• Three-step Flow
• Basic Usage Model

Two-step Flow
The two-step flow is supported only for Verilog HDL and SystemVerilog designs.
Simulating a design using two-step flow involves the following two basic steps:
• Compiling the Design
• Simulating the Design

Verification Continuum™ VCS User Guide 65

V-2023.12
 Feedback
Chapter 1: Getting Started
Using the Simulator

Compiling the Design

Compiling is the first step to simulate your design. In this phase, VCS builds the instance
hierarchy and generates a binary executable simv. This binary executable is later used for
simulation. For more information, see “Two-step Flow” .

Simulating the Design

During compilation, VCS generates a binary executable, simv. You can use simv to run
the simulation. For more information, see “Two-step Flow” .

Three-step Flow
The three-step flow is supported for Verilog, VHDL, and mixed HDL designs. VCS uses
the following three basic steps to compile, elaborate and simulate any Verilog, VHDL, and
mixed HDL designs:
• Analyzing the Design
• Elaborating the Design
• Simulating the Design

Analyzing the Design

VCS provides you with the vhdlan and vlogan executables to analyze your VHDL and
Verilog design code. vhdlan/vlogan analyzes your design and stores the intermediate
files in the design or a work library.
By default, the vhdlan option is VHDL-93 compliant, and vlogan is Verilog-2000
compliant. You can switch to VHDL-87 using the -vhdl87 option with vhdlan. Similarly,
you can switch to VHDL 2002 or VHDL 2008 by using the -vhdl02 or -vhdl08 option
respectively. For more information, see “Three-step Flow” . You can switch to the
SystemVerilog mode by using the option -sverilog with vlogan.

Elaborating the Design

VCS provides you with the vcs executable to compile and elaborate the design. This
executable compiles/elaborates your design using the intermediate files in the design
or work library, generates the object code, and statically links them to generate a binary
simulation executable, simv. For more information, see “Three-step Flow” .

Simulating the Design

Simulate your design by executing the binary simulation executable, simv. For more
information, see “Three-step Flow” .

Verification Continuum™ VCS User Guide 66

V-2023.12
 Feedback
Chapter 1: Getting Started
Using the Simulator

Basic Usage Model

The following sections describe the basic use model for two-step flow and three-step flow:
• Two-step Flow
• Three-step Flow

Two-step Flow
Compilation
% [ ]

Simulation
% [ ]

Three-step Flow
Analysis
Always analyze Verilog before VHDL.
% vlogan [ ] file1.v file2.v
% vhdlan [ ] [Link] [Link]

Note:
Specify the VHDL bottommost entity first, then move up in order.
Elaboration
% [ ] design_unit

The design_unit can be one of the following:

module

Verilog top module name.

entity

VHDL top entity name.

entity__archname

Name of the top entity and architecture to be simulated. By default, archname is the most
recently analyzed architecture.
cfgname

Name of the top-level event configuration to be simulated.

Verification Continuum™ VCS User Guide 67

V-2023.12
 Feedback
Chapter 1: Getting Started
Default Time Unit and Time Precision

Simulation
% [ ]

Default Time Unit and Time Precision

The default time unit for Verilog and SystemVerilog simulation is 1 s.
The default time precision for Verilog and SystemVerilog simulation is 1 s.
For VHDL simulation there is no concept of a default time unit and delay values, for
example, must have a unit name or unit of measurement, for example:
wait for 10.123123 ns;

The default time precision for an entire VHDL design is specified with the
TIME_RESOLUTION 1 ns entry in the synopsys_sim.setup file in the VCS installation (see
Creating a synopsys_sim.setup File).
The default time precision for the VHDL part of a mixed HDL design is the smallest or
finest of these two:
• What is specified with the TIME_RESOLUTION entry in the synopsys_sim.setup file.
• The smallest time precision from the Verilog or SystemVerilog part of the design.
You can override the default time precision with the -time_res elaboration option.
Note:
The -time_res option has no effect on the Verilog code.

Searching Identifiers in the Design Using UNIX Commands

You can use the following vcsfind UNIX command to search for identifiers in your design.
vcsfind

The vcsfind script is located in $VCS_HOME/bin. You must specify the location of the
[Link] file.

vcsfind [<options> --] [<identifier>] [(+/-)<search group>]+

Where,
options

Search options in the following table. These options must be separated by a “--” from
the search query. Any change to the Verdi GUI settings has no effect on the vcsfind
command.

Verification Continuum™ VCS User Guide 68

V-2023.12
 Feedback
Chapter 1: Getting Started
Searching Identifiers in the Design Using UNIX Commands

Table 1 Supported Search Options

Search Option Description

--version Displays program's version number and exits

-h, --help Displays help message and exits

-b, --bw(Black and White) Highlights with bold and underline only, no colors.

-d N, --dir_levels=N Prints n directory levels for every matching line. Default is 0.

-f DB-FILE, --file=DB-FILE Specifies the database file. Default is [Link]

-H, --gui-help Prints help for GUI use.

-l N, --limit=N Limits search to the first n matches. 0 means no limit. Default

is 1000.

-m, --match_only Matches the query pattern only. Does not display scope
information.

-o OUTPUT-FILE, Outputs into a file. Default is stdout/stderr. This option

--output=OUTPUT-FILE bundles stdout and stderr, so -o - will redirect errors to
stdout.

-p, --plain Does not highlight matches in bold.

-r, --regexp Regular expression search pattern. The pattern is interpreted

as ^<pattern>$, so .* may be desired at the beginning and
end of the pattern.

-t, --translate Translation mode. Prints only the translation of the query
pattern into the internal SQL query string.

-u, --uclimode Enables UCLI mode. This option is used for interaction with
UCLI.

-v, --verbose Enables verbose mode.

identifier

Identifier string to be searched.

search group

The name of the group to be included to search or excluded from search. The following
search groups are supported:
Packages, Modules, Ports, Parameters, Vars, Functions, Assertions, Types,
Members, Instances

Verification Continuum™ VCS User Guide 69

V-2023.12
 Feedback
Chapter 1: Getting Started
Searching Identifiers in the Design Using UNIX Commands

You can also use Verdi to search for the identifiers in your design.

Examples
% vcsfind -f [Link]/debug_dump/fsearch/[Link] -- Top

Following is the sample output:

Matching modules:
top.v:11 module Top
scope: Top

Matching instances:
top.v:11 inst Top of module Top
scope: Top

Total: 4 results found in 0.053 seconds

UTF-8 Unicode File Format

VCS supports UTF-8 Unicode file format during compilation. The UTF-8 Unicode (with
BOM) file format is not supported and results in an error message.

Verification Continuum™ VCS User Guide 70

V-2023.12
 Feedback

2
VCS Flow
This chapter describes the simulation flows supported by VCS. You can use the following
flows to simulate your design using VCS:
• Three-step Flow
• Two-step Flow
• Partition Compile Flow

Three-step Flow
Simulating a design using three-step flow involves three basic steps:
• Analysis
• Elaboration
• Simulation
VCS uses these three steps to compile any design irrespective of the HDL, HVL, and other
supported technologies used. For information on supported technologies, see Simulator
Support with Technologies .
For information on the data types supported across the language boundary for both ports
and generics or parameters, see the VCS Simulation Coding and Modeling Style Guide.
For information on licensing options, see Options for Licensing .

Analysis
Analysis is the first step to simulate your design. In this phase, you analyze your VHDL,
Verilog, SystemVerilog, and OpenVera files using vhdlan or vlogan accordingly. The
following section includes a few example command lines to analyze your design files:
Analyzing your VHDL files:
% vhdlan [ ] [Link] [Link]

Verification Continuum™ VCS User Guide 71

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Analyzing your Verilog files:

% vlogan [ ] file1.v file2.v

Analyzing your SystemVerilog files:

% vlogan -sverilog [ ] [Link] [Link] file3.v

For the complete usage model, see Using SystemVerilog.

Analyzing your OpenVera files:
% vlogan -ntb [ ] [Link] [Link] file3.v

For the complete use model, see Using OpenVera Native Testbench.
Analyzing your SystemVerilog and OpenVera files:
% vlogan -sverilog -ntb [ ] [Link] [Link] file3.v

Note that you can analyze SystemVerilog files or OpenVera files along with other Verilog
files in the same vlogan command line as shown in the examples. Unless it is required,
you do not need to separately analyze these files.
In the analysis phase, VCS checks the design for the syntax errors. In this phase, VCS
generates the intermediate files required for elaboration and saves these files in the
design or work library pointed to by your default logical library. For information on library
mapping, see “The Concept of a Library in VCS” . You can instruct VCS to save these
intermediate files in a different library using the -work option with the vhdlan or vlogan
executables.
Before you analyze your design using vhdlan or vlogan, ensure that the library mappings
are defined in the synopsys_sim.setup file, and that the specified physical library for
the logical library exists. If the physical directory does not exist, VCS exits with an error
message.
VCS provides vhdlan and vlogan executable to analyze VHDL and Verilog design files,
respectively. The following sections describe the usage of these two executables and
some of the commonly used options.

Using vhdlan
The vhdlan executable analyzes your VHDL design files and stores the generated
intermediate files in the design or work library. The syntax for the vhdlan executable is as
follows:
% vhdlan [ ] VHDL_filename_list

Verification Continuum™ VCS User Guide 72

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Commonly Used Analysis Options

This section lists some of the commonly used vhdlan options. For a complete list of
options, see section “The vhdlan Utility” .
Command Options
-help

Displays usage information for vhdlan.

-nc

Suppresses the Synopsys copyright message.

-q

Suppresses all vhdlan messages.

-version

Displays the version number of vhdlan and exits without running analysis.
-full64

Analyzes the design for 64-bit simulation.

-work library

Maps a design library name to the logical library name WORK that receives the output of
vhdlan. Mapping with this command line option overrides any assignment of WORK to
WORK library

another library name in the setup file.

library can also be a physical path that corresponds to a logical library name defined in
the setup file.
-vhdl87

Enables to analyze non-portable VHDL code that contains object names that are now
VHDL-93 reserved words by default. VCS is VHDL-93 compliant.
VHDL-93

-vhdl02

Enables to analyze the VHDL 2002 protected type. For more information, see “Support for
VHDL 2002, 2008 and 2019” .
-vhdl08

Enables to analyze the VHDL 2008 constructs provided in the chapter “Support for VHDL
2002, 2008 and 2019” .
-output outfile

Verification Continuum™ VCS User Guide 73

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Redirects standard output from VCS analysis (that usually goes to the screen) to the file
that you specify as outfile.
-xlrm

Enables VHDL features beyond those described in LRM.

-f filename

Specifies a file that contains a list of source files. You should specify the bottom most
VHDL entity first, and then move up in order.
-functional_vital

Specifies generating code for functional VITAL simulation mode.

-l filename

Specifies a log file where VCS records the analyzer messages.

-no_functional_vital

Specifies generating code for full-timing VITAL simulation mode.

VHDL_filename_list

Specifies the VHDL source file names to be analyzed. If you do not provide an extension,
.vhd is assumed.

The maximum identifier name length is 250 for package, package body and configuration
names. The combined length of an entity name plus architecture name must not exceed
250 characters as well. All other VHDL identifier names and string literals do not have a
limitation.
-init_std_logic

You can initialize all uninitialized VHDL signals, ports and variables of the data type
STD_LOGIC/STD_ULOGIC (scalar/vector) with a given 9-value. A VHDL signal or variable of
this type can take on the following values – ‘U’, ‘X’, '0', '1', 'Z', 'W', 'L', 'H', '-'.
You can supply the value at vhdlan command line option as shown in the following
command line:
% vhdlan [Link] -init_std_logic 0
You can also initialize the value in the synopsys_sim_setup file.
In the synopsys_sim_setup file, you can set the value to any one of the nine values
to the variable INIT_STD_lOGIC. For example, INIT_STD_lOGIC=0. To create a
synopsys_sim_setup file, see “Creating a synopsys_sim.setup File” .

Verification Continuum™ VCS User Guide 74

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Using vlogan
Similar to vhdlan, the vlogan executable analyzes your Verilog design files and stores
the generated intermediate files in the design or work library. The syntax for the vlogan
executable is as follows:
% vlogan [ ] Verilog_filename_list

Commonly Used Analysis Options

This section lists some of the commonly used vlogan options. For a complete list of
options, see “The vlogan Utility” .
Command Options
-help

Displays usage information for vlogan.

-nc

Suppresses the Synopsys copyright message.

-q

Suppresses all vlogan messages.

-f filename

Specifies a file that contains a list of source files.

The maximum line length in the specified file filename must be less than 1024
characters. VCS truncates the line exceeding this limit and issues a warning message.
-full64

Analyzes the design for 64-bit simulation.

-ignore keyword_argument
-ignore[ingnore]
-ignore

Suppresses warning messages depending on which keyword argument is specified. The

keyword arguments are as follows:
unique_checks

Suppresses warning messages about unique if and unique case statements.

priority_checks

Suppresses warning messages about priority if and priority case statements.

all

Verification Continuum™ VCS User Guide 75

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Suppresses warning messages about unique if, unique case, priority if and
priority case statements.

-l filename

Specifies a log file where VCS records the analyzer messages.

-liblist logical_lib1+logical_lib2+...logical_libn

It specifies the library search order for resolving imported package definitions. The
vlogan –liblist option restricts the libraries in which vlogan should search for resolving
package references found while analyzing.
If the -liblist option is not included, vlogan searches all the logical libraries listed in the
synopsys_sim.setup file.

When using multiple vlogan commands with the same -work logical library, run the
commands sequentially, and if one command uses -liblist, then ensure that all the
remaining vlogan commands are using the same -liblist argument list, as shown in the
following command lines:
%vlogan a.v -work shared_lib -liblist shared_lib+ovm_lib+common_lib

%vlogan b.v -work shared_lib -liblist shared_lib+ovm_lib+common_lib

%vlogan c.v -work shared_lib -liblist shared_lib+ovm_lib+common_lib

-ntb
-ntb[-]
-ntb

Enables the use of the OpenVera testbench language constructs described in the
OpenVera Language Reference Manual: Native Testbench.
-ntb_define macro
-ntb_define[ntb_define]
-ntb_define

Specifies any OpenVera macro name on the command line. You can specify multiple
macro names using the plus (+) character.
-ntb_filext .ext
-ntb_filext[ntb_filext]
-ntb_filext

Specifies an OpenVera file name extension. You can specify multiple file name extensions
using the plus (+) character.
-ntb_incdir directory_path
-ntb_incdir[ntb_incdir]
-ntb_incdir

Specifies the include directory path for OpenVera files. You can specify multiple include
directories using the plus (+) character.
-ova_file filename
-ova_file[-]
-ova_file

Identifies filename as an assertion file. It is not required if the file name ends with .ova.
For multiple assertion files, repeat this option with each file.

Verification Continuum™ VCS User Guide 76

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

-sverilog

Enables the analysis of SystemVerilog source code.

-sv_pragma
-sv_pragma[-]
-sv_pragma

Instructs VCS to compile the SystemVerilog Assertions code that follows the sv_pragma
keyword in a single line or multi-line comment.
-timescale=time_unit/time_precision

This option enables you to specify the timescale for the source files that do not contain
‘timescale compiler directive and precede the source files that contain.

Do not include spaces when specifying the arguments to this option.

-v library_file

Specifies a Verilog library file to search for module definitions.

-y library_directory

Enables you to specify a Verilog library directory to search for module definitions. VCS
looks in the source files in this directory for definitions of the module and UDP instances
that VCS found in your source code. However, for which it did not find the corresponding
module or UDP definitions in your source code.
VCS looks in this directory for a file with the same name as the module or UDP identifier in
the instance (not the instance name). If it finds this file, VCS looks in the file for the module
or UDP definition to resolve the instance.
If you have multiple modules with the same name in different libraries, VCS selects the
module defined in the library that is specified with the first -y option.
For example:
If rev1/cell.v and rev2/cell.v and rev3/cell.v all exist and define the module
cell(), and you issue the following command:
% vlogan -y rev1 -y rev2 -y rev3 +libext+.v top.v

VCS selects cell.v from rev1.

However, if the top.v file has a `uselib compiler directive as shown below, then `uselib
takes priority.
//top.v
`uselib directory = /proj/libraries/rev3
//rest of top module code
//end top.v

Verification Continuum™ VCS User Guide 77

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

In this case, VCS uses rev3/cell.v when you issue the following command:
% vlogan -y rev1 -y rev2 +libext+.v top.v

Include the +libext compile time option to specify the file name extension of the files you
want VCS to search for in these directories.
-work library

Maps a design library name to the logical library name WORK that receives the output of
vlogan. Mapping with the command-line option overrides any assignment of WORK to
WORK library

another library name in the setup file.

+define+macro

Defines a text macro. Test this definition in your Verilog source code using the ‘ifdef
compiler directive.
+libext+extension+
+libext[libext]
+libext

Specifies that VCS searches only for files with the specified file name extensions in a
library directory. You can specify more than one extension, separating the extensions with
the plus (+) character. For example, +libext+.v+.V+ specifies searching files with either
the .v or .V extension in a library. The order in which you add file name extensions to this
option does not specify an order in which VCS searches files in the library with these file
name extensions.
+lint=[no]ID|none|all
+lint[lint]
+lint

Enables messages that provides information about when your Verilog code contains
something that is bad style, but is often used in designs.
+liborder
Verilog order
+liborder[liborder]
+liborder
specifying
search library
theofdirectories
search
Verilogorder
library directories

Specifies searching for module definitions for unresolved module instances through the
remainder of the library where vlogan finds the instance, then searching the subsequent
library on the vlogan command line before searching in the first library in the command
line.
+librescan
Verilog order
+librescan[librescan]
+librescan
specifying
search
rescan library
theofdirectories
search
Verilogorder
library directories

Always specifies searching libraries for module definitions of unresolved module instances
beginning with the first library in the vlogan command line.
+incdir+directory

Specifies the directories that contain the files specified with the ‘include compiler
directive. You can specify more than one directory, separating each path name with the “+”
character.
+nowarnTFMPC

Verification Continuum™ VCS User Guide 78

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Suppress the Too few module port connections warning messages during Verilog
Compilation.
+systemverilogext+ext
+systemverilogext[systemverilogext]
+systemverilogext

Specifies a file name extension for SystemVerilog source files. If you use a different file
name extension for the SystemVerilog part of your source code and you use this option,
the –sverilog option has to be omitted.
+verilog2001ext+ext
+verilog2001ext[verilog2001ext]
+verilog2001ext

Specifies a file name extension for Verilog 2001 source files.

+verilog1995ext+ext
+verilog1995ext[verilog1995ext]
+verilog1995ext

Specifies a file name extension for Verilog 1995 files. Using this option allows you to write
Verilog 1995 code that would be invalid in Verilog 2001 or SystemVerilog code, such as
using Verilog 2001 or SystemVerilog keywords, like localparam and logic, as names.
+warn

Enables or disables warning messages.

Verilog_source_filename

Specifies the name of the Verilog source file.

-incr_vlogan
-incr_vlogan

Enables you to abort a vlogan command when there are no changes in the following:
• source files analyzed by that same command in previous parsing iteration.
• imported SV packages referenced at source files analyzed by that command.
• command line user options (+define+) or vlogan command options.
• shell environments. See Disabling Environment Variables Checks on Different
Machines.
Note:
If a change is detected, the vlogan command runs from scratch.
For example:
% vlogan -incr_vlogan

You can configure incremental vlogan to ignore certain changes in shell environments
using the following commands:
% vlogan -incr_vlogan -vts_ignore_env=Env1, Env2,...

Verification Continuum™ VCS User Guide 79

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

For information about the -vts_ignore_env option, see the “Option to Exclude Environment
Variables During Timestamp Checks” section.
Note:
The following options are vlogan parse options:
-ignore unique_checks|priority_checks|all
-ntb_define[ntb_define]
-ntb_define

-ntb_define macro
-ntb_filext .ext
-sv_pragma
-v library_file
-y library_directory
-sverilog
-incr_vlogan
+define+macro
+incdir+[ ]
+libext+
+libext[libext]
+libext

+
+systemverilogext+ext
+verilog1995ext+ext
+verilog2001ext+ext
+lint=[no]ID|none|all
+nowarnTFMPC
+warn

VCS issues a message with appropriate severity if any of these options are not allowed
and used at elaboration.

Disabling Environment Variables Checks on Different Machines

You can use the -vts_ignore_vars option to disable checking of the following
environment values that help not to reparse the design again.
• Environment variables that are controlled by bsub and all the variables starting
with LSB_: HOME, LS_JOBPID, LSB_ACCT_MAP, LSB_EXIT_PRE_ABORT,
LSB_EXIT_REQUEUE, LSB_EVENT_ATTRIB, LSB_HOSTS, LSB_INTERACTIVE,
LSB_INTERACTIVE_SSH, LSB_INTERACTIVE_TTY, LSB_JOBFILENAME,
LSB_JOBGROUP, LSB_JOBID, LSB_JOBNAME, LSB_JOB_STARTER, LSB_QUEUE,
LSB_RESTART, LSB_TRAPSIGS, LSB_XJOB_SSH, LSF_VERSION, PWD, USER,
VIRTUAL_HOSTNAME.

• Environment variables related to non-interactive jobs: TERM, TERMCAP.

• Windows-specific environment variables: COMPUTERNAME, COMSPEC, NTRESKIT,
OS2LIBPATH, PROCESSOR_ARCHITECTURE, PROCESSOR_IDENTIFIER,
PROCESSOR_LEVEL, PROCESSOR_REVISION, SYSTEMDRIVE, SYSTEMROOT, TEMP,
TMP.

• The following environment variables do not take effect on the execution hosts:
LSB_DEFAULTPROJECT, LSB_DEFAULT_JOBGROUP, LSB_TSJOB_ENVNAME,

Verification Continuum™ VCS User Guide 80

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

LSB_TSJOB_PASSWD, LSF_DISPLAY_ALL_TSC, LSF_JOB_SECURITY_LABEL,

LSB_DEFAULT_USERGROUP, LSB_DEFAULT_RESREQ, LSB_DEFAULTQUEUE,
BSUB_CHK_RESREQ, LSB_UNIXGROUP, LSB_JOB_CWD.

For other machine environment change, the design is re-analyzed.

Analyzing the Design to Different Libraries

You can analyze your design to different libraries using the -work option with either the
vhdlan or vlogan executable. However, to use this feature, map the required logical
libraries to physical libraries. For information about mapping libraries, see, “Library Name
Mapping” .
With the -work option, you can specify either the logical library name or the physical
library name, specified in your synopsys_sim.setup file as follows:
% vhdlan -work libname1 VHDL_filename_list
% vlogan -work libname1 Verilog_filename_list

These command lines analyze your VHDL files and Verilog files, and saves the
intermediate files in the libname1 library. VCS resolves all VHDL files having:
library libname1;
use [Link];

Elaboration
Elaborating is the second step to simulate your design. In this phase, using the
intermediate files generated during analysis, VCS builds the instance hierarchy and
generates a binary executable simv. This binary executable is later used for simulation.
In this phase, you can choose to elaborate the design either in the optimized mode or in
the debug mode. The runtime performance of VCS is based on the mode you choose and
the level of flexibility required during simulation. Synopsys recommends you to use full
debug or partial debug mode until the design correctness is achieved, and then switch to
optimized mode.
In optimized mode, also called as batch mode, VCS delivers the best compile time and
runtime performance for a design. You typically choose optimized mode to run regressions
or when you do not require extensive debug capabilities. For more information, see
“Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option” .
You compile the design in debug mode, also called interactive mode, when you are in the
initial phase of your development cycle, or when you need more debug capabilities or tools
to debug the design issues. In this mode, the performance is not the best that VCS can
deliver. However, using some of the compile time options, you can compile your design in

Verification Continuum™ VCS User Guide 81

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

full debug or partial debug mode to get maximum performance in debug mode. For more
information, see “Compiling/Elaborating the Design in the Debug Mode” .

Using VCS
The syntax to use vcs is as follows:
% [elab ] [ ]design_unit

Where,
libname

The library name where you analyzed your top module, entity, or the configuration. If not
specified, VCS looks for the specified design_unit in the list of libraries specified in the
synopsys_sim.setup file as per the order specified. For more information, see Creating a
synopsys_sim.setup File .
Here, the design_unit can be one of the following:
module

Verilog top module name.

entity

VHDL top entity name.

entity__archname

Name of the top entity and architecture to be simulated. By default, archname is the most
recently analyzed architecture.
cfgname

Name of the top-level configuration.

Commonly Used Options
This section lists some of the commonly used vcs options. For a complete list of options,
see Compilation/Elaboration Options .
Options for Help
-h or -help
-h [-] -help [-]

Lists descriptions of the most commonly used VCS compile time and runtime options.
-ID

Returns useful information, such as VCS version and build date, VCS compiler version
(same as VCS), and your work station name, platform, and host ID (used in licensing).

Verification Continuum™ VCS User Guide 82

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Options for 64-bit Elaboration

-full64

Enables elaboration and simulation in 64-bit mode.

Alternatively, you can use the VCS_TARGET_ARCH environment variable to enable
elaboration and simulation in 64-bit mode architecture. For more information, see
VCS_TARGET_ARCH.
Option to Specify Elaboration Options in a File
-file filename
-file

Specifies a file containing elaboration options.

Options for Starting Simulation After Elaboration
-R

Runs the executable file immediately after VCS links it together.

Options for Changing Generics and Parameter Values
-gfile cmdfile

Overrides the default values for design generics or parameters using values from the file
cmdfile. The cmdfile file is an include file that contains assign commands targeting
design generics.
Options for Controlling Messages
-notice
-notice[notice]
-notice

Enables verbose diagnostic messages.

-q
-q [-]

Quiet mode; suppresses messages, such as those about the C compiler VCS is using, the
source files VCS is parsing, the top-level modules, or the specified timescale.
-V
-V [-]

Verbose mode; compiles verbosely. The compiler driver program prints the commands it
verbose messages
compiling

executes as it runs the C compiler, assembler, and linker.

Specifying a Log File
-l filename
-l filename
log
specifying
files compilation
[-] log file

Specifies a file where VCS records elaboration messages. If you also enter the -R option,
VCS records messages from both elaboration and simulation in the same file.

Verification Continuum™ VCS User Guide 83

V-2023.12
 Feedback
Chapter 2: VCS Flow
Three-step Flow

Simulation
During elaboration, using the intermediate files generated, VCS creates a binary
executable, simv. You can use simv to run the simulation. Based on how you elaborate
the design, you can run the simulation using the following two modes:
• Interactive Mode
• Batch Mode
• Commonly Used Runtime Options
For information about elaborating the design, see Elaboration.

Interactive Mode
You can elaborate your design in the interactive mode, also called debug mode, in the
initial phase of your design cycle. In this phase, you require abilities to debug the design
issues using a GUI or through the command line. To debug using a GUI, you can use
Verdi, and to debug through the command-line interface, you can use Unified Command-
line Interface (UCLI).
Note:
To simulate a design in the interactive mode, elaborate the design using
-debug_access+r, -debug_access+all or refer to section Optimizing
Simulation Performance for Desired Debug Visibility With the -debug_access
Option for more debug compile time options. For information on elaborating the
design, see Elaboration

Batch Mode
You can elaborate your design in batch mode, also called as optimized mode, when most
of your design issues are resolved. In this phase, you can achieve better performance to
run regressions with minimum debug abilities.
Note:
The runtime performance reduces if you use -debug_access. Use this option
only when you require runtime debug abilities.
The following command line simulates the design in batch mode:
% simv

Commonly Used Runtime Options

Use the following command line to simulate the design:
% _ [ ]

Verification Continuum™ VCS User Guide 84

V-2023.12
 Feedback
Chapter 2: VCS Flow
Two-step Flow

By default, VCS generates the binary executable simv. However, you can use the compile
time option, -o with the vcs command line to generate the binary executable with the
specified name.
-gui
-gui

This option starts Verdi when VERDI_HOME is set.

-ucli
-ucli

This option starts simv in UCLI mode.

For information on Verdi, see Using Verdi .
For a complete list of runtime options, see Simulation Options.

Two-step Flow
The two-step flow is supported only for Verilog HDL and SystemVerilog designs.
Simulating a design using two-step flow involves two basic steps:
• Compilation
• Simulation

Compilation
Compiling is the first step to simulate your design. In this phase, VCS builds the instance
hierarchy and generates a binary executable simv. This binary executable is later used for
simulation.
In this phase, you can choose to compile the design either in optimized mode or in debug
mode. Runtime performance of VCS is based on the mode you choose and the level of
flexibility required during simulation. Synopsys recommends to use full debug or partial
debug mode until the design correctness is achieved and then switch to optimized mode.
In the optimized mode, also called as batch mode, VCS delivers the best compile
time and runtime performance for a design. You typically choose optimized mode to
run regressions, or when you do not require extensive debug capabilities. For more
information, see “Optimizing Simulation Performance for Desired Debug Visibility With the
-debug_access Option” .
You can compile the design in debug mode, also called interactive mode, when you are
in the initial phase of your development cycle, or when you need more debug capabilities
or tools to debug the design issues. In this mode, the performance is not the best that
VCS can deliver. However, using some of the compile time options, you can compile your

Verification Continuum™ VCS User Guide 85

V-2023.12
 Feedback
Chapter 2: VCS Flow
Two-step Flow

design in full debug or partial debug mode to get maximum performance in debug mode.
For more information, see “Compiling/Elaborating the Design in the Debug Mode” .
For information on licensing options, refer to “Options for Licensing”.

Using vcs
The syntax to use VCS is as follows:
% [ ] Verilog_files

Commonly Used Options

This section lists some of the commonly used vcs options.
Options for Help
-h or -help
-h [-] -help [-]

Lists descriptions of the most commonly used VCS compile and runtime options.
-ID

Returns useful information, such as VCS version and build date, VCS compiler version
(same as VCS), and your work station name, platform, and host ID (used in licensing).
Options for Accessing Verilog Libraries
-v filename
-v [-]

Enables you to specify a Verilog library file. VCS looks in this file for definitions of the
module and UDP instances that VCS found in your source code, however, for which it did
not find the corresponding module or UDP definitions in your source code.
-y directory
-y [-]

Enables you to specify a Verilog library directory. VCS searches in the source files in this
directory for definitions of the module and UDP instances that VCS found in your source
code but for which it did not find the corresponding module or UDP definitions in your
source code. VCS searches in this directory for a file with the same name as the module
or UDP identifier in the instance (not the instance name). If it finds this file, VCS searches
in the file for the module or UDP definition to resolve the instance.
If you have multiple modules with the same name in different libraries, VCS selects the
module defined in the library that is specified with the first -y option.
For example:
If rev1/cell.v and rev2/cell.v and rev3/cell.v all exist and define the module
cell(), and you issue the following command:
% vcs -y rev1 -y rev2 -y rev3 +libext+.v top.v

Verification Continuum™ VCS User Guide 86

V-2023.12
 Feedback
Chapter 2: VCS Flow
Two-step Flow

VCS selects cell.v from rev1.

However, if the top.v file has a `uselib compiler directive as follows:
//top.v
`uselib directory = /proj/libraries/rev3
//rest of top module code
//end top.v

then, `uselib takes priority. In this case, VCS uses rev3/cell.v when you issue the
following command:
% vcs -y rev1 -y rev2 +libext+.v top.v

Include the +libext compile time option to specify the file name extension of the files you
want VCS to look for in these directories.
+incdir+directory+
+incdir[incdir]
+incdir

Specifies the directory or directories that VCS searches for include files used in the
`include compiler directive. You can specify multiple directories using the plus (+)
character.
+libext+extension+
+libext[libext]
+libext

Specifies that VCS searches only for files with the specified file name extensions in a
library directory. You can specify more than one extension, separating the extensions with
the plus (+) character. For example, +libext+.v+.V+ specifies searching for files with
either the .v or .V extension in a library. The order in which you add file name extensions to
this option does not specify an order in which VCS searches files in the library with these
file name extensions.
+liborder
+liborder[liborder]
+liborder

Specifies searching for module definitions for unresolved module instances through
the remainder of the library where VCS finds the instance, then searching the next and
then the next library on the vcs command line before searching in the first library on the
command line.
+liborder and +librescan switches on elaboration command line will have impact only
when the user specifies -y/-v on elaboration command line.
Options for 64-bit Compilation
-full64

Enables compilation and simulation in 64-bit mode.

Option to Specify Files and Compile Time Options in a File
-file filename
-file

Verification Continuum™ VCS User Guide 87

V-2023.12
 Feedback
Chapter 2: VCS Flow
Two-step Flow

Specifies a file containing a list of files and compile-time options.

Options for Verdi
-verdi
-gui[-]
-gui

This option starts Verdi.

Options for Starting Simulation After Compilation
-R

Runs the executable file immediately after VCS links it together.

Options for Changing Parameter Values
-pvalue+parameter_hierarchical_name=value
-pvalue[-]
-pvalue

Changes the specified parameter to the specified value.

-parameters filename
-parameters[-]
-parameters

Changes parameters specified in the file to values specified in the file. The syntax for a
line in the file is as follows:
assign path_to_parameter

The path to the parameter is similar to a hierarchical name except that you use the forward
slash character (/) instead of a period as the delimiter.
Options for Controlling Messages
-notice
-notice[notice]
-notice

Enables verbose diagnostic messages.

-q
-q [-]

Quiet mode; suppresses messages such as those about the C compiler VCS is using, the
source files VCS is parsing, the top-level modules, or the specified timescale.
-V
-V [-]

Verbose mode; compiles verbosely. The compiler driver program prints the commands it
verbose messages
compiling

executes as it runs the C compiler, assembler, and linker.

Specifying a Log File
-l filename
-l filename
log
specifying
files compilation
[-] log file

Specifies a file where VCS records compilation messages. If you also enter the -R option,
VCS records messages from both compilation and simulation in the same file.

Verification Continuum™ VCS User Guide 88

V-2023.12
 Feedback
Chapter 2: VCS Flow
Two-step Flow

Defining a Text Macro

+define+macro=value+
+define+macro=value[define+macro]
+define+macro=value

Defines a text macro in your source code to a value or character string. You can test this
definition in your Verilog source code using the ‘ifdef compiler directive.
The =value argument is optional.
For example:
% vcs design.v +define+USETHIS

The macro is used inside the source file using the ‘ifdef compiler directive. If this macro
is not defined using the +define option, then the else portion in the code takes priority.
`ifdef USETHIS
package p1;
endpackage
`else
package p2;
Endpackage
`endif

Simulation
During compilation, VCS generates a binary executable, simv. You can use simv to run
the simulation. Based on how you compile the design, you can run your simulation using
the following modes:
• Interactive Mode
• Batch Mode
• Commonly Used Runtime Options
For information on compiling the design, see Compilation.

Interactive Mode
You can compile your design in interactive mode, also called debug mode, in the initial
phase of your design cycle. In this phase, you require abilities to debug the design issues
using a GUI or through the command line. To debug using a GUI, you can use Verdi, and
to debug through the command-line interface, you can use the Unified Command-line
Interface (UCLI).
Note:
To simulate the design in the interactive mode, compile the design using the
-debug_access(+<option>) compile time option.

Verification Continuum™ VCS User Guide 89

V-2023.12
 Feedback
Chapter 2: VCS Flow
Partition Compile Flow

For information on compiling the design, see Compilation.

Batch Mode
You can compile your design in batch mode, also called as optimized mode, when most of
your design issues are resolved. In this phase, you can achieve better performance to run
regressions and with minimum debug abilities.
Note:
The runtime performance reduces if you use the -debug_access(+<option>)
option. Use this option only when you require runtime debug abilities.
The following command line simulates the design in batch mode:
% simv

Commonly Used Runtime Options

Use the following command line to simulate the design:
% [ ]

By default, VCS generates the binary executable simv. However, you can use the compile
time option, -o with the vcs command line to generate the binary executable with the
specified name.
-gui

This option starts Verdi when VERDI_HOME is set.

-ucli

This option starts simv in UCLI mode.

For information on Verdi, see Using Verdi.
For a complete list of runtime options, see Simulation Options .

Partition Compile Flow

Compile your design using the Partition Compile flow to enhance compile productivity
for the iterative process of compilation and recompilation phases. It works with both VCS
three-step and two-step flows.
For more information, refer to the Partition Compile section in Compile Time Productivity.

Verification Continuum™ VCS User Guide 90

V-2023.12
 Feedback

3
Modeling Your Design
Verilog coding style is the most important factor that affects the simulation performance
of a design. How you write your design can make the difference between a fast error-free
simulation, and one that suffers from race conditions and poor performance. This chapter
describes some Verilog modeling techniques that helps you to simulate your designs most
efficiently with VCS.
This chapter includes the following topics:
• Avoiding Race Conditions
• Race Detection in Verilog Code
• Race Detection Tool to Identify Race between Clock and Data
• Optimizing Testbenches for Debugging
• Creating Models That Simulate Faster
• Creating Models That Simulate Faster
• Case Statement Behavior
• Precedence in Text Macro Definitions
• Memory Size Limits in the Simulator
• Using Sparse Memory Models
• Obtaining Scope Information
• Avoiding Circular Dependency
• Designing With $lsi_dumpports for Simulation and Test
• Translating VHDL Package to SystemVerilog Package
• VITAL2000 Negative Constraint Calculation

Verification Continuum™ VCS User Guide 91

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Avoiding Race Conditions

Avoiding Race Conditions

A race condition is defined as a coding style for which there is more than one correct
result. Since the output of the race condition is unpredictable, it can cause unexpected
problems during simulation. It is easy to accidentally code race conditions in Verilog. For
example, in Digital Design with Verilog HDL by Sternheim, Singh, and Trivedi, at least two
of the examples provided with the book (adder and cachemem) have race conditions. VCS
provides some tools for race detection.
Some common race conditions and ways of avoiding them are described in the following
sections.

Using and Setting a Value at the Same Time

In this example, the two parallel blocks have no guaranteed ordering, so it is ambiguous
whether the $display statement will be executed.
module race;
reg a;
initial begin
a = 0;
#10 a = 1;
end
initial begin
#10 if (a) $display("may not print");
end
endmodule

The solution is to delay the $display statement with a #0 delay:

initial begin
#10 if (a)
#0 $display("may not print");
end

You can also move it to the next time step with a non-zero delay.

Setting a Value Twice at the Same Time

In this example, the race condition occurs at time 10 because no ordering is guaranteed
between the two parallel initial blocks.
module race;
reg r1;
initial #10 r1 = 0;
initial #10 r1 = 1;
initial

Verification Continuum™ VCS User Guide 92

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Avoiding Race Conditions

#20 if (r1) $display("may not print");

endmodule

The solution is to stagger the assignments to register r1 by finite time, so that the ordering
of the assignments is guaranteed. Note that using the non-blocking assignment (<=) in
both assignments to r1 would not remove the race condition in this example.

Flip-Flop Race Condition

It is very common to have race conditions near latches or flip-flops. Here is one variant in
which an intermediate node a between two flip-flops is set and sampled at the same time:
module test(out,in,clk);
input in,clk;
output out;
wire a;
dff dff0(a,in,clk);
dff dff1(out,a,clk);
endmodule
module dff(q,d,clk);
output q;
input d,clk;
reg q;
always @(posedge clk)
q = d; // race!
endmodule

The solution for this case is straightforward. Use the non-blocking assignment in the flip-
flop to guarantee the order of assignments to the output of the instances of the flip-flop
and sampling of that output. The change looks like this:
always @(posedge clk)
q <= d; // ok

Or add a nonzero delay on the output of the flip-flop:

always @(posedge clk)
q = #1 d; // ok

Or use a non-zero delay in addition to the non-blocking form:

always @(posedge clk)
q <= #1 d; // ok

Note that the following change does not resolve the race condition:
always @(posedge clk)
#1 q = d; // race!

Verification Continuum™ VCS User Guide 93

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Avoiding Race Conditions

The #1 delay simply shifts the original race by one time unit, so that the intermediate node
is set and sampled one time unit after the posedge of clock, rather than on the posedge of
clock. Avoid this coding style.
If you are modeling flip-flops using sequential UDPs (User-Defined Primitives), note that
VCS evaluates the output terminals of sequential UDP (User-Defined Primitive) in the
sequentialoutput
changing UDPsevaluation to the NBA tile slot sequentialoutput
UDPs
changing UDPsevaluation to the NBA time slot Active

NBA region. This can cause a race condition. The default behavior is required by the
time slot UDP output evaluation to the NBA time slot
changing

SystemVerilog LRM, IEEE Std 1800-2009.

Continuous Assignment Evaluation

Continuous assignments with no delay are sometimes propagated earlier in VCS than in
Verilog-XL. This is fully correct behavior, but exposes race conditions such as the one in
the following code fragment:
assign x = y;
initial begin
y = 1;
#1
y = 0;
$display(x);
end

In VCS, this displays 0, while in Verilog-XL, it displays 1, because the assignment of the
value to x races with the usage of that value by the $display.
Another example of this type of race condition is the following:
assign state0 = (state == 3'h0);
always @(posedge clk)
begin
state = 0;
if (state0)
// do something
end

The modification of state may propagate to state0 before the if statement, causing
unexpected behavior. You can avoid this by using the non-blocking assignment to state in
the procedural code as follows:
state <= 0;
if (state0)
// do something

This guarantees that state is not updated until the end of the time step, that is, after the
if statement is executed.

Verification Continuum™ VCS User Guide 94

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Avoiding Race Conditions

Counting Events
A different type of race condition occurs when code depends on the number of times
events are triggered in the same time step. For instance, in the following example, if A
and B change at the same time, it is unpredictable whether count is incremented once or
twice:
always @(A or B)
count = count + 1;

Another form of this race condition is to toggle a register within the always block. If
toggled once or twice, the result may be unexpected behavior.
The solution to this race condition is to make the code inside the always block insensitive
to the number of times it is called.

Time Zero Race Conditions

The following race condition is subtle, but very common:
always @(posedge clock)
$display("May or may not display");
initial begin
clock = 1;
forever #50 clock = ~clock;
end

This is a race condition because the transition of clock to 1 (posedge) may happen before
or after the event trigger (always @(posedge clock)) is established. Often the race is not
evident in the simulation result because reset occurs at time zero.
The solution to this race condition is to guarantee that no transitions take place at time
zero of any signals inside event triggers. Rewrite the clock driver in the above example as
follows:
initial begin
clock = 1’bx;
#50 clock = 1’b0;
forever #50 clock = ~clock;
end

Verification Continuum™ VCS User Guide 95

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Race Detection in Verilog Code

VCS provides the following race detection tools:
• Dynamic Race Detection Tool - Finds the race conditions during simulation.
• Static Race Detection Tool - Finds the race conditions by analyzing source code
during compilation.
The above two tools are described in the following sections:
• The Dynamic Race Detection Tool
• The Static Race Detection Tool

The Dynamic Race Detection Tool

This section consists of following topics:
• Introduction to the Dynamic Race Detection Tool
• Enabling Race Detection
• The Race Detection Report
• Post-Processing the Report
• Debugging Simulation Mismatches

Introduction to the Dynamic Race Detection Tool

The dynamic race detection tool finds two basic types of race conditions during simulation:
• Read - Write Race Condition
• Write - Write Race Condition
Read - Write Race Condition
The Read - Write race condition occurs when both Read and Write on a signal take place
at the same simulation time.
Example:
initial
#5 var1 = 0; // write operation on signal var1

initial
#5 var2 = var1; // read operation on signal var2

Verification Continuum™ VCS User Guide 96

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Read
Procedural assignment in any one of the always or initial block, or a continuous
assignment samples the value of signal var1 to drive signal var2.
Write
Procedural assignment in another always or initial block, or another continuous
assignment assigns a new value to signal var1.
In the above example, at the simulation time 5, there is both read and write operation on
signal var1. When simulation time 5 is over, you do not know if signal var2 will have the
value 0 or the previous value of signal var1.
Write - Write Race Condition
The Write - Write race condition occurs when multiple writes on a signal take place at the
same simulation time.
Example:
initial
#5 var1 = 0; // write operation on signal var1

initial
#5 var1 = 1; // write operation on signal var1

Write-Write
Value of the signal var1 is non-deterministic when there are multiple concurrent procedural
assignments on the same variable at the same simulation time.
In the above example, at simulation time 5, different initial blocks assign 0 and 1 to signal
var1. When simulation time 5 is over, you do not know if var1 signal value is 0 or 1.

Finding these race conditions is important because in Verilog simulation you cannot
control the order of execution of statements in different always or initial blocks, or
continuous assignments that execute at the same simulation time. This means that a
race condition can produce different simulation results when you simulate a design with
different, but both properly functioning Verilog simulators.
Even worse, a race condition can result in different simulation results with different
versions of a particular simulator, or with different optimizations or performance features of
the same version of a simulator.
Note:
$dumpvars can also expose races.

Also, sometimes modifications in one part of a design can cause hidden race conditions to
surface even in unmodified parts of a design, thereby causing different simulation results
from the unmodified part of the design.

Verification Continuum™ VCS User Guide 97

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

The indications of a race condition are the following:

• Simulation results do not match when comparing simulators
• Design modifications cause inexplicable results
• Simulation results do not match between different simulation runs of the same
simulator, when different versions or different optimization features of that simulator are
used
Therefore, even when a Verilog design appears to be simulating correctly, and you see
the results you want, you should look for race conditions and remove them so that you will
continue to see the same simulation results from an unrevised design well into the future.
Also, you should look for race conditions while a design is in development.
VCS can help you find these race conditions by writing report files about the race
conditions in your design.
VCS writes the reports at runtime, but you should enable race detection at compile-time
with a compile-time option.
The reports can be lengthy for large designs. You can post-process the report to generate
another shorter report that is limited, for example, to only part of the design or to only
between certain simulation times.

Enabling Race Detection

When you compile your design, you can enable race detection during simulation for your
entire design or part of your design.
The -race compile-time option enables race detection for your entire design.
The -racecd compile-time option enables race detection for the part of your design that is
enclosed between the ‘race and ‘endrace compiler directives.
Note:
The -race and -racecd compile-time options support dynamic race detection
for both pure Verilog and SystemVerilog data types.

The Race Detection Report

While VCS simulates your design, it writes race detection reports to the [Link] and
[Link] files.

The [Link] file contains a line for all race conditions that it finds at all times throughout
the simulation. If VCS executes two different statements in the same time step for several
times, the [Link] file contains a line for each of these times.
The [Link] file contains only the lines for race conditions that are unique, and
which have not been reported in a previous line.

Verification Continuum™ VCS User Guide 98

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Note:
The [Link] is automatically created by the [Link] Perl script
after the simulation. This script needs a perl5 interpreter. The first line of the
script points to Perl at a specific location, see Modifying the [Link] Script.
If that location at your site is not a perl5 interpreter, the script fails with syntax
errors.
The report describes read-write and write-write race conditions. The following is an
example of the contents of a small [Link] file:
Synopsys Simulation VCS RACE REPORT

0 "c": write test (exp1.v: 5) && read test (exp1.v:23)

1 "a": write test (exp1.v: 16) && write test (exp1.v:10)
1 "c": write test (exp1.v: 5) && read test (exp1.v:17)

END RACE REPORT

The following explains a line in the [Link] file:

Verification Continuum™ VCS User Guide 99

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Shorthand term for

assigning a value to Shorthand term for
the signal using a signal’s
Simulation time value in another operation
when VCS detected
the race condition
Filename and line Filename and line
number where VCS number where VCS
finds the write operation finds the read operation

1 "c": write test (exp1.v: 5) && read test (exp1.v:17)

Identifier of the Identifier of the Delimiter between Identifier of the

signal whose module definition information for a module definition
value change is in where VCS finds the a write and a read where VCS finds
the race condition write operation operation or between the read operation.
two write operations

Shorthand term for

assigning a value to Shorthand term for
the signal using a signal’s
Simulation time value in another operation
when VCS detected
the race condition
Filename and line Filename and line
number where VCS number where VCS
finds the write operation finds the read operation

1 "c": write test (exp1.v: 5) && read test (exp1.v:17)

Identifier of the Identifier of the Delimiter between Identifier of the

signal whose module definition information for a module definition
value change is in where VCS finds a write and a read where VCS finds
the race condition the write operation operation or between the read operation.
two write operations

The following is the source file, with line numbers added for this race condition report:
1. module test;
2. reg a,b,c,d;
3.
4. always @(a or b)
5. c = a & b;
6.

Verification Continuum™ VCS User Guide 100

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

7. always
8. begin
9. a = 1;
10. #1 a = 0;
11. #2;
12. end
13.
14. always
15. begin
16. #1 a = 1;
17. d = b | c;
18. #2;
19. end
20.
21. initial
22. begin
23. $display("%m c = %b",c);
24. #2 $finish;
25. end
26. endmodule

As stipulated in [Link]:
• At simulation time 0, there is a procedural assignment to reg c on line 5, and also
$display system task displays the value of reg c on line 23.

• At simulation time 1, there is a procedural assignment to reg a on line 10 and another

procedural assignment to reg a on line 16.
• Also, at simulation time 1, there is a procedural assignment to reg c on line 5, and
the value of reg c is in an expression that is evaluated in a procedural assignment to
another register on line 17.
Races of No Consequence
Sometimes race conditions exist, such as write-write race to a signal at the same
simulation time, but the two statements that are assigning to the signal are assigning the
same value. This is a race of no consequence, and the race tool indicates this with **NC at
the end of the line for the race in the [Link] file.
0 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC **NC[NC]
**NC

20 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC

40 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC
60 "r4": write test (nc1.v: 40) && write test (nc1.v:44)
80 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC

Post-Processing the Report

VCS comes with the [Link] Perl script that you can use to post-process the
[Link] report to generate another report that contains a subset of the race conditions in

Verification Continuum™ VCS User Guide 101

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

the [Link] file. You should include options on the command line for the [Link]
script to specify this subset. These options are as follows:
-hier module_instance Specifies the hierarchical name of a module instance. The
-hier module_instance

new report lists only the race conditions found in this instance and all module instances
hierarchically under this instance.
-sig signal Specifies the signal that you want to examine for race conditions. You
-sig signal

can only specify one signal, and must not include a hierarchical name for the signal. If
two signals in different module instances have the same identifier, the report lists race
conditions for both signals.
-minmax min max Specifies the minimum (or earliest) and the maximum (or latest)
-minmax

simulation time in the report.

-nozero Omits race conditions that occur at simulation time 0.
-nozero

-uniq Omits race conditions that also occurred earlier in the simulation. The output is the
-uniq

same as the contents of the [Link] file.

-f filename Specifies the name of the input file. Use this option if you have changed the
-f

name of the [Link] file.

-o filename The default name of the output file is [Link]. If you want a different
-o

name, specify it with this option.

You can enter more than one of these options on the [Link] command line.
If you enter an option more than once, the script uses the last of these multiple entries.
Unless you specify a different name with the -o option, the report generated by the
[Link] script is in the [Link] file.

The following is an example of the command line:

[Link] -minmax 80 250 -f [Link] -o
[Link]

In this example, the output file is named [Link], and reports

the race conditions between 80 and 250 time units. The post-process file is named
[Link].

Modifying the [Link] Script

The first line of the [Link] Perl script is as follows:
#! /usr/local/bin/perl

If Perl is installed at a different location at your site, you must modify the first line of this
script. This script needs a perl5 interpreter. You can find this script at the following location:
vcs_install_dir/bin/[Link]

Verification Continuum™ VCS User Guide 102

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Debugging Simulation Mismatches

A design can contain several race conditions where many of them behave the same in
different simulations, so they are not the cause of a simulation mismatch. For a simulation
mismatch, you must find critical races. Critical races are the race conditions that cause the
simulation mismatch. This section describes how to do this.
Add system tasks to generate VCD files to the source code of the simulations that
mismatch. Recompile them with the -race or -racecd options and run the simulations
-racecd

again.
When you have two VCD files, find their differences with the vcdiff utility. This utility
is located in the vcs_install_dir/bin directory. The command line for vcdiff is as
follows:
vcdiff [Link] [Link] -options > output_filename

If you enter the vcdiff command without arguments, you see the usage information
vcdiff

including the options.

Method 1: If the Number of Unique Race Conditions is Small
A unique race condition is a race condition that can occur several times during simulation,
but only the first occurrence is reported in the [Link] file. If the number of
lines in the [Link] file is smaller than the number of unique race conditions,
then for each signal in the [Link] file:
1. Look in the output file from the vcdiff utility. If the signal values are different, you have
found a critical write-write race condition.
2. If the signal values are not different, look for the signals that are assigned the value of
this signal, or assigned expressions that include this signal (read operations).
3. If the values of these other signals are different at any point in the two simulations,
note the simulation times of these differences on the other signals, and post-process
the [Link] file looking for race conditions in the first signal at around the simulation
times of the value differences on the other signals. Specify simulation times before and
after the time of these differences with the -minmax option. Enter:
[Link] -sig -minmax time time2

If the [Link] file contains the first signal, then it is a critical race condition, and
must be corrected.

Verification Continuum™ VCS User Guide 103

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection in Verilog Code

Method 2: If the Number of Unique Races is Large

If there are many lines in the [Link] file and a large number of unique race
conditions, then the method of finding the critical race conditions is to do the following:
1. Look in the output file from the vcdiff utility for the simulation time of the first
difference in simulation values.
2. Post-process the [Link] file looking for races at the time of the first simulation value
difference. Specify simulation times before and after the time of these differences with
the -minmax option. Enter:
[Link] -minmax time time2

3. For each signal in the resulting [Link] file:

◦ If the simulation values differ in the two simulations, then the race condition in the
[Link] file is a critical race condition.

◦ If the simulation values are not different, check the signals that are assigned the
value of this signal or assigned expressions that include this signal. If the values of
these other signals are different, then the race condition in the [Link] file
is a critical race condition.
Method 3: An Alternative When the Number of Unique Race Conditions is Large
1. Look in the output file from the vcdiff utility for the simulation time of the first
difference in simulation values.
2. For each signal that has a difference at this simulation time:
a. Traverse the signal dependency backwards in the design until you find a signal
whose values are same in both simulations.
b. Look for a race condition on that signal at that time. Enter: [Link] -sig
signal -minmax time time2. If there is a race condition at that time on that signal,
then it is a critical race condition.

The Static Race Detection Tool

It is possible for a group of statements to combine and form a loop, so that the loop is
executed once by VCS and more than once by other Verilog simulators. This is a race
condition.
These situations arise when level-sensitive sensitivity lists (event controls which
immediately follow the always keyword in an always block, and which do not contain
the posedge or negedge keywords) and procedural assignment statements in the
always blocks combine with other statements such as continuous assignment or module
instantiation statements to form a potential loop. It is observed that these situations do

Verification Continuum™ VCS User Guide 104

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection Tool to Identify Race between Clock and Data

not occur if the always blocks contain delays or other timing information, non-blocking
assignment statements, or PLI calls through user-defined system tasks.
You can use the +race=all compile-time option to start the static race detection tool.
+race=all[race=all]
+race=all

Note:
The +race=all compile-time option supports only pure Verilog constructs.
+race=all[race=all]
+race=all

After compilation, the static race detection tool writes the file named [Link]
which reports the race conditions.
The following example shows an always block that combines with other statements to
form a loop:
35 always @( A or C ) begin
36 D = C;
37 B = A;
38 end
39
40 assign C = B;

The [Link] file from the compilation of this source code follows:
Race-[CLF] Combinational loop found
"source.v", 35: The trigger ’C’ of the always block can cause
the following sequence of event(s) which can again trigger
the always block.
"source.v", 37: B = A;
which triggers ’B’.
"source.v", 40: assign C = B;
which triggers ’C’.

Race Detection Tool to Identify Race between Clock and Data

VCS supports a race detection tool that finds the race condition between clock and data
and generates the diagnostic output.
This race detect tool detects race for the following conditions:
• Whenever the clock and data arrives at the same time, VCS detects the race condition
and provides the RTL information.
• Race is reported when the data is updated before the clock for the same timestamp.

Verification Continuum™ VCS User Guide 105

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection Tool to Identify Race between Clock and Data

This race detection tool helps you to know the following:

• Glitches in the design that are encountered during simulation.
• Flops that are affected by the glitch during simulation.
• The frequency and timing of glitches in the design.

Use Model
When you compile your design, you can enable the race detection tool during simulation
for your entire design.
The -hsopt=racedetect option enables the race detection tool for your entire design.
-hsopt=racedetect

If no clock-data race is detected during simulation, VCS reports the following information:
Clock Data Race: No Race detected.

VCS stores the RTL information in the [Link] file.

The format of the output is as follows:
Clock Data Race detected @ <n> Module: <Module_name> Instance:
<Instance_name> Line: <Line_no> File: <File_name> RTL_MOD_NAME:
<Module_name> Object: <Data_signal>

Here,
n
Time at which the race occurred.
Module_name

Module in which the race was detected.

Instance_name

Hierarchy pointing to the specific instance of the module.

Line_no

Line number pointing to the source file.

File_name

Name of the source file.

Module_name

Name of the module.

Verification Continuum™ VCS User Guide 106

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection Tool to Identify Race between Clock and Data

Data_signal

Data signal in the detected clock data race.

Examples
Consider the following example. The lines where the race is detected is highlighted in the
example:

Example 2 The content of the test.v file.

`noinline
module top;
reg clk; reg clk1;
wire [31:0] o1, o2, o3, o4, o5, o6;
integer d; reg r;
bot1 b1(o1,o2,o3, clk,clk1, d, (d+1), (d+2));
bot2 b2(o4,o5,o6, clk,clk1, (d + 10), (d+11), (d+12));

always begin #10; clk <= ~clk; end

always begin #7; clk1 <= ~clk1; end

always begin #50; d = d + 1; end

always begin #21; d = d + 1; end

initial
begin
r = 1'b1; clk = 1'b0; clk1 = 1'b0; d = 20;
#200;
$display(o1, o2, o3, o4, o5, o6); $finish;
end
endmodule

`noinline
module bot1(q,q1, q2, clk,clk1, d, d1,d2);
integer q,q1,q2;
output q,q1,q2;
input clk,clk1;
input [31:0] d,d1,d2;

always @(posedge clk1) q1 <= d1;

always @(posedge clk) q2 <= d2;
endmodule

`noinline
module bot2(q,q1, q2, clk, clk1, d, d1,d2);
integer q,q1,q2;
output q,q1,q2;

Verification Continuum™ VCS User Guide 107

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Race Detection Tool to Identify Race between Clock and Data

input clk,clk1;
input [31:0] d,d1,d2;
integer dtemp;

always @(posedge clk) q1 <= d1;

always @(posedge clk1) q2 <= d2;
endmodule

Compile the test cases as follows:

% vcs test.v -hsopt=racedetect
-hsopt=racedetect

% simv
% cat [Link]

It generates the following output:

Clock Data Race detected @ 21 Module: bot1 Instance: top.b1
Line: 33 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d1
Clock Data Race detected @ 21 Module: bot2 Instance: top.b2
Line: 45 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d
Line: 47 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d2
Clock Data Race detected @ 50 Module: bot1 Instance: top.b1
Line: 32 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d
Line: 34 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d2
Clock Data Race detected @ 50 Module: bot2 Instance: top.b2
Line: 46 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d1
Clock Data Race detected @ 63 Module: bot1 Instance: top.b1
Line: 33 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d1
Clock Data Race detected @ 63 Module: bot2 Instance: top.b2
Line: 45 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d
Line: 47 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d2
Clock Data Race detected @ 105 Module: bot1 Instance: top.b1
Line: 33 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d1
Clock Data Race detected @ 105 Module: bot2 Instance: top.b2
Line: 45 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d
Line: 47 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d2
Clock Data Race detected @ 147 Module: bot1 Instance: top.b1
Line: 33 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d1
Clock Data Race detected @ 147 Module: bot2 Instance: top.b2
Line: 45 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d
Line: 47 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d2
Clock Data Race detected @ 150 Module: bot1 Instance: top.b1
Line: 32 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d
Line: 34 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d2
Clock Data Race detected @ 150 Module: bot2 Instance: top.b2
Line: 46 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d1
Clock Data Race detected @ 189 Module: bot1 Instance: top.b1
Line: 33 File: data_2clk_race.v RTL_MOD_NAME: bot1 Object: d1
Clock Data Race detected @ 189 Module: bot2 Instance: top.b2
Line: 45 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d
Line: 47 File: data_2clk_race.v RTL_MOD_NAME: bot2 Object: d2

Verification Continuum™ VCS User Guide 108

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Optimizing Testbenches for Debugging

Limitations
The feature has the following limitations:
• RTL information is not provided for clock-only glitches.
• No race detect output file is generated if you are using any of the following VCS
technologies:
◦ X-propagation
◦ Congruency
◦ Partition Compile flow
◦ Mixed-Signal design
◦ FGP flow
◦ -dbsflagsbytearray option

Optimizing Testbenches for Debugging

Testbenches typically execute debugging features, for example, displaying text in certain
situations as specified with the $monitor or $display system tasks. Another debugging
feature, which is typically enabled in testbenches, is writing simulation history files during
simulation so that you can view the results after simulation.
Among other things, these simulation history files record the simulation times at which the
signals in your design change value. These simulation history files can be either ASCII
Value-Change-Dump (VCD) files that you can input into a number of third-party viewers, or
binary FSDB files that you can input into Verdi.
The $dumpvars system task specifies writing a VCD file, and the $fsdbDumpvars system
task specifies writing a FSDB file. You can use the vcd2fsdb utility to also convert VCD
file into FSDB, which translates the VCD file to a FSDB file and then displays the results in
Verdi.
Debugging features significantly slow down the simulation performance of any logic
simulator including VCS. This is particularly true for operations that make VCS display text
on the screen and even more so for operations that make VCS write information to a file.
For this reason, you will want to be selective about where in your design and where in the
development cycle of your design you enable debugging features. The following sections
describe a number of techniques that you can use to choose when debugging features are
enabled.

Verification Continuum™ VCS User Guide 109

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Optimizing Testbenches for Debugging

Conditional Compilation
Use ‘ifdef, ‘else, and ‘endif compiler directives in your testbench to specify which
system tasks you want to compile for debugging features. Then, when you compile the
design with the +define compile-time option on the command line (or when the ‘define
compiler directive appears in the source code), VCS compiles these tasks for debugging
features. For example:
initial
begin
`ifdef postprocess
$vcdpluson(0,design_1);
$vcdplusdeltacycleon;
$vcdplusglitchon;
`endif
end

In this case, the vcs command is as follows:

% +define+postprocess

The system tasks in this initial block record several types of information in a FSDB file. In
this particular case, the information is for all the signals in the design, so the performance
cost is extensive. You would only want to do this early in the development cycle of the
design when finding bugs is more important than simulation speed.
The command line includes the +define+postprocess compile-time option, which tells
VCS to compile the design with these system tasks compiled into the testbench.
Later in the development cycle of the design, you can compile the design without the
+define+postprocess compile-time option, and VCS does not compile these system
tasks into the testbench. Doing so enables VCS to simulate your design much faster.
Advantages and Disadvantages
The advantage of this technique is that simulation can run faster than if you enable
debugging features at runtime. When you use conditional compilation, VCS has all the
information it needs at compile-time.
The disadvantage of this technique is that you have to recompile the testbench to include
these system tasks in the testbench, thus increasing the overall compilation time in the
development cycle of your design.
Synopsys recommends that you consider this technique as a way to prevent these system
tasks from inadvertently remaining compiled into the testbench, later in the development
cycle, when you want faster performance.

Verification Continuum™ VCS User Guide 110

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Optimizing Testbenches for Debugging

Enabling Debugging Features at Runtime

Use the $test$plusargs system function in place of the ‘ifdef compiler directives.
The $test$plusargs system function checks for a plusarg runtime option on the simv
command line.
Note:
A plusarg option is an option that has a plus (+) symbol as a prefix.
An example of the $test$plusargs system function is as follows:
initial
if ($test$plusargs("postprocess"))
begin
$vcdpluson(0,design_1);
$vcdplusdeltacycleon;
$vcdplusglitchon;
end

In this technique you do not include the +define compile-time argument on the vcs
command line. Instead you compile the system tasks into the testbench and then enable
the execution of the system tasks with the runtime argument to the $test$plusargs
system function. Therefore, in this example, the simv command line is as follows:
% simv +postprocess

During simulation, VCS writes the VPD file with all the information specified by
these system tasks. Later, you can execute another simv command line without the
+postprocess runtime option. As a result, VCS does not write the VPD file, and therefore
runs faster.
There is a pitfall to this technique. This system function matches any plusarg that has the
function’s argument as a prefix. For example:
module top;
initial
begin
if ( $test$plusargs("a") )
$display("\n<<< Now a >>>\n");
else if ( $test$plusargs("ab") )
$display("\n<<< Now ab >>>\n");
else if ( $test$plusargs("abc") )
$display("\n<<< Now abc >>>\n");
end
endmodule

No matter whether you enter the +a, +ab, or +abc plusarg, when you simulate the
executable, VCS always displays the following:
<<< Now a >>>

Verification Continuum™ VCS User Guide 111

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Optimizing Testbenches for Debugging

To avoid this pitfall, enter the longest plusarg first. For example, you would revise the
previous example as follows:
module top;
initial
begin
if ( $test$plusargs("abc") )
$display("\n<<< Now abc >>>\n");
else if ( $test$plusargs("ab") )
$display("\n<<< Now ab >>>\n");
else if ( $test$plusargs("a") )
$display("\n<<< Now a >>>\n");
end
endmodule

Advantages and Disadvantages

The advantage to using this technique is that you do not have to recompile the testbench
to stop VCS from writing the VPD file. This technique is something to consider using,
particularly early in the development cycle of your design, when you are fixing a lot of bugs
and already doing a lot of recompilation.
The disadvantages to this technique are considerable. Compiling these system tasks,
or any system tasks that write to a file, into the testbench requires VCS to compile the
simv executable so that it is possible for it to write the VPD file when the runtime option
is included on the command line. This means that the simulation runs significantly
slower than if you don’t compile these system tasks into the testbench. This impact
on performance remains even when you don’t include the runtime option on the simv
command line.
Using the $test$plusargs system function forces VCS to consider the worst case
scenario — plusargs are used at runtime — and VCS generates the simv executable with
the corresponding overhead to prepare for these plusargs. The more fixed information
VCS has at compile-time, the more VCS can optimize simv for efficient simulation.
Alternatively, the more user control at runtime, the more overhead VCS has to add to simv
to accept runtime options, and the less efficient the simulation.
For this reason, Synopsys recommends that if you use this technique, you should plan
to abandon it fairly early in the development cycle and switch to either the conditional
compilation technique for writing simulation history files, or a combination of the two
techniques.

Verification Continuum™ VCS User Guide 112

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

Combining the Techniques

Some users find that they have the greatest amount of control over the advantages and
disadvantages of these techniques when they combine them. Consider the following
example:
`ifdef comppostprocess
initial
if ($test$plusargs("runpostprocess"))
begin
$vcdpluson(0,design_1);
$vcdplusdeltacycleon;
$vcdplusglitchon;
end
`endif

In this instance, both the +define+comppostprocess compile-time option and the

+runpostprocess runtime option are required for VCS to write the VPD file. This
technique allows you to avoid recompiling just to prevent VCS from writing the file during
the next simulation and also provides you with a way to recompile the testbench, later in
the development cycle, to exclude these system tasks without first editing the source code
for the testbench.

Creating Models That Simulate Faster

When modeling your design, for faster simulation, use higher levels of abstraction.
Behavioral and RTL models simulate much faster than gate and switch level models. This
rule of thumb is not unique to VCS; it applies to all Verilog simulators and even all logic
simulators in general.
What is unique to VCS are the acceleration algorithms that make behavioral and RTL
models simulate even faster. In fact, VCS is particularly optimized for RTL models for
which simulation performance is critical.
These acceleration algorithms work better for some designs than for others. Certain types
of designs prevent VCS from applying some of these algorithms. This section describes
the design styles that simulate faster or slower.
The acceleration algorithms apply to most data types and primitives and most types of
statements, but not all of them. This section also describes the data types, primitives, and
types of statements that you should try to avoid.
VCS is optimized for simulating sequential devices. Under certain circumstances, VCS
infers that an always block is a sequential device and simulates the always block much
faster. This section describes the coding guidelines you should follow to make VCS infer
an always block as a sequential device.

Verification Continuum™ VCS User Guide 113

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

When writing an always block, if you cannot follow the inferencing rules for a sequential
device, there are still things that you should keep in mind so that VCS simulates the
always block faster. This section also describes the guidelines for coding faster simulating
always blocks that VCS infers to be combinatorial instead of sequential devices.

Unaccelerated Data Types, Primitives, and Statements

VCS cannot accelerate certain data types and primitives. VCS also cannot accelerate
certain types of statements. This section describes the data types, primitives, and types of
statements that you should try to avoid.
Avoid Unaccelerated Data Types
VCS cannot accelerate certain data types. The following table lists these data types:

Data Type Description in IEEE Std

1364-2001

time and realtime Page 22

real Page 22

named event Page 138

trireg net Page 26

integer array Page 22

Avoid Unaccelerated Primitives

VCS cannot accelerate tranif1, tranif0, rtranif1, rtranif0, tran, and rtran switches. They are
defined in the IEEE Std 1364-2001.
Avoid Calls to User-defined Tasks or Functions Declared in Another Module
VCS cannot accelerate user-defined tasks or functions declared in another module. For
example:
module bottom (x,y);
.
.
.
always @ y
top.task_indentifier(y,rb);
endmodule

Verification Continuum™ VCS User Guide 114

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

Avoid Strength Specifications in Continuous Assignment Statements

Omit strength specifications in continuous assignment statements. For example:
assign net1 = flag1;

Simulates faster than:

assign (strong1, pull0) net1= flag1;

Continuous assignment statements are described in the IEEE Std 1364-2001.

Inferring Faster Simulating Sequential Devices

VCS is optimized to simulate sequential devices. If VCS can infer that an always block
behaves like a sequential device, VCS can simulate the always block much faster.
The IEEE Std 1364-2001 defines always constructs on page 149. Verilog users commonly
use the term always block when referring to an always construct.
VCS can infer whether an always block is a combinatorial or sequential device. This
section describes the basis on which VCS makes this inference.
Avoid Unaccelerated Statements
VCS does not infer an always block to be a sequential device if it contains any of the
following statements:

Statement Description in IEEE Std 1364-2001

force release procedural Page 126-127

statements

repeat statements Page 134-135, see the other looping statements on

these pages and consider them as an alternative.

wait statements, also called as Page 141

level-sensitive event controls

disable statements Page 162-164

fork-join block statements, also Page 146-147

called as parallel blocks

Using either blocking or non-blocking procedural assignment statements in the always

block does not prevent VCS from inferring a sequential device, but in VCS blocking
procedural assignment statements are more efficient.

Verification Continuum™ VCS User Guide 115

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

Synopsys recommends zero delay non-blocking assignment statements to avoid race

conditions.
IEEE Std 1364-2001 describes blocking and non-blocking procedural assignment
statements on pages 119-124.
Place Task Enabling Statements in Their Own always Block and Use No Delays
IEEE Std 1364-2001 defines tasks and task enabling statements on pages 151-156.
VCS infers that an always block that contains a task enabling statement is a sequential
device only when there are no delays in the task declaration.
All Sequential Controls Must Be in the Sensitivity List
To borrow a concept from VHDL, the sensitivity list for an always block is the event control
that immediately follows the always keyword.
IEEE Std 1364-2001 defines event controls on page 138 and mentions sensitivity lists on
page 139.
For correct inference, all sequential controls must be in the sensitivity list. The following
code examples illustrate this rule:
• VCS does not infer the following DFF to be a sequential device:
always @ (d)
@ (posedge clk) q <=d;

Even though clk is in an event control, it is not in the sensitivity list event control.
• VCS does not infer the following latch to be a sequential device:
always begin
wait clk; q <= d; @ d;
end

There is no sensitivity list event control.

• VCS infers the following latch to be a sequential device:
always @ (clk or d)
if (clk) q <= d;

The sequential controls, clk and d, are in the sensitivity list event control.

Verification Continuum™ VCS User Guide 116

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

Avoid Level-Sensitive Sensitivity Lists Whose Signals are Used “Completely”

VCS infers a combinational device instead of a sequential device if the following conditions
are both met:
• The sensitivity list event control is level sensitive.
A level sensitive event control does not contain the posedge or negedge keywords.
• The signals in the sensitivity list event control are used “completely” in the always
block.
Used “completely” means that there is a possible simulation event if the signal has a
true or a false (1 or 0) value.
The following code examples illustrate this rule:
Example 1
VCS infers that the following always block is combinatorial, not sequential:
always @ (a or b)
y = a or b

Here, the sensitivity list event control is level sensitive and VCS assigns a value to y
whether a or b are true or false.
Example 2
VCS also infers that the following always block is combinatorial, not sequential:
always @ (sel or a or b)
if (sel)
y=a;
else
y=b;

Here, the sensitivity list event control is also level sensitive and VCS assigns a value to
y whether a, b, or sel are true or false. Note that the if-else conditional statement uses
signal sel completely, VCS executes an assignment statement whether sel is true or
false.
Example 3
VCS infers that the following always block is sequential:
always @ (sel or a or b)
if (sel)
y=a;

In this instance, there is no simulation event when signal sel is false (0).

Verification Continuum™ VCS User Guide 117

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

Modeling Faster always Blocks

Whether VCS infers an always block to be a sequential device or not, there are modeling
techniques you should use for faster simulation.
Place All Signals Being Read in the Sensitivity List
The sensitivity list for an always block is the event control that immediately follows the
always keyword. Place all nets and registers, whose values you are assigning to other
registers, in the always block, and place all nets and registers, whose value changes
trigger simulation events, in the sensitivity list control.
Use Blocking Procedural Assignment Statements
In VCS, blocking procedural assignment statements are more efficient.
Synopsys recommends zero delay non-blocking procedural assignment statements to
avoid race conditions.
IEEE Std 1364-2001 describes blocking and non-blocking procedural assignment
statements on pages 119-124.
Avoid force and release Procedural Statements
IEEE Std 1364-2001 defines these statements on pages 126-127. A few occurrences
of these statements in combinatorial always blocks does not noticeably slow down
simulation, but their frequent use does lead to a performance cost.

Using Verilog 2001 Constructs

In G-2012.09 and newer releases, Verilog 2001 or V2K source code conforms to the
Verilog IEEE Std 1364-2001 instead of the Verilog IEEE Std 1364-1995.
If your Verilog code contains a V2K keyword as an identifier, you can tell VCS not to
recognize V2K keywords with the -v95 compile time option, for example:
module cell (...,...);

The module identifier cell is a keyword in Verilog 2001, so to use it as an identifier,

include the -v95 compile-time option.
The following table lists the implemented constructs in IEEE Std 1364-2001 and whether
you need a compile-time option to use them.

IEEE Std 1364-2001 Construct Default

comma separated event control expressions:always @ (r1,r2,r3) yes

Verification Continuum™ VCS User Guide 118

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Creating Models That Simulate Faster

IEEE Std 1364-2001 Construct Default

name-based parameter passing:modname #(.param_name(value)) yes

inst_name(sig1,...);

ANSI-style port and argument lists:module dev(output reg [7:0] out1, input yes
wire [7:0] w1);

initialize a reg in its declaration:reg [15:0] r2 = 0; yes

conditional compiler directives: ifndef and ‘elseif yes

disabling the default net data type:‘default_nettype yes

signed arithmetic extensions:reg signed [7:0] r1; yes

file I/O system tasks:$fopen $fsanf $scanf and more yes

passing values from the runtime command line:$value$plusarg system yes

function

indexed part-selects:reg1[8+:5]=5’b11111; yes

multi-dimensional arrays:reg [7:0] r1 [3:0] [3:0]; yes

maintaining file name and line number:‘line yes

implicit event control expression lists:always @* yes

the power operator:r1=r2**r3; yes

attributes:(* optimize_power=1 *)module dev (res,out,clk,data1,data2); yes

generate statements yes

localparam declarations yes

Automatic tasks and functionstask automatic t1(); requires the

-sverilog
compile-time
option

constant functionslocalparam lp1 = const_func(p1); yes

parameters with a bit rangeparameter bit [7:0][31:0] P = requires the

{32'd1,32'd2,32'd3,32'd4,32'd5,32'd6,32'd7,32'd8}; -sverilog
compile-time
option

Verification Continuum™ VCS User Guide 119

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Case Statement Behavior

Case Statement Behavior

The IEEE Std 1364-2001 standards for the Verilog language state that you can enter
the question mark character (?) in place of the z character in the casex and casez
statements. The standard does not specify that you can also make this substitution in
the case statements, and you might infer that this substitution is not allowed in the case
statements.
VCS, like other Verilog simulators, does not make this inference, and allows you to also
substitute ? for z in the case statements. If you do, remember that z does not stand for
“don’t care” in a case statement, like it does in a casez or casex statement. In a case
statement, z stands for the usual high impedance, and therefore so does ?.

Precedence in Text Macro Definitions

In text macros, the line continuation character ( \ ) has a higher precedence than the one
line comment characters ( // ). This means that VCS can merge a subsequent line with
the text in a one-line comment, for example:
`define print_me_1 \
$display( "Hello 1" ); // just a comment \
$display( "I'm OK" );

VCS merges the second $display system task with the comment on the previous line and
does not display the text string I’m OK.
The following are the precedence rules for text macro definitions:
1. The `undef compiler directive has a higher precedence than the +define compile-time
option.
2. The +define compile-time option has a higher precedence than the `define and
`undefineall compiler directives.

Memory Size Limits in the Simulator

The bit width for a word or an element in a memory in VCS must be less than 0x100000
memory size limits

(or 220 or 1,048,576) bits.

The number of elements or words (sometimes also called rows) in a memory in VCS must
be less than 0x3FFF_FFFE-1 (or 230 - 2 or 1,073,741,822) elements or words.
The total bit count of a memory (total number of elements * word size) must be less than 8
* (1024 * 1024 * 1024 - 2) or 8589934576.

Verification Continuum™ VCS User Guide 120

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Memory Size Limits in the Simulator

The memory consumption of reg and bit variables is not the same. The reg data type
has 4 states and the bit data type has 2 states.
Consider the following testcase:
module top;
bit [127:0] mem_bit [0:1<<26];
reg [127:0] mem_reg [0:1<<26];
initial begin mem_bit = '{default: 'b0} ; end
initial begin mem_reg = '{default: 'b1}; end
endmodule

Memory Size Calculation of Bit Data Type

The bit data type is a 2-state variable and requires 1 bit to store. In the above testcase, the
memory consumed by the bit variable mem_bit is:
1 * (2 ** 26 * 128) = 8,589,934,592 bits (1GB)

The size of the memory is within the (2GB -1) limit.

Verification Continuum™ VCS User Guide 121

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Using Sparse Memory Models

Memory Size Calculation of Reg Data Type

The reg data type is a 4-state variable and requires 2 bits to store. In the above testcase,
the memory consumed by the reg variable mem_reg is:
2 * (2**26 * 128) = 17,179,869,184 bits (2GB)

The size of memory is outside range (> 2GB -1), so VCS issues the Error-[MTL] Memory
Too Large error message. To resolve this error message, you should reduce the size of
the memory as follows:
reg [127:0] mem_reg [0:1<<25];

Note:
• Starting with the VCS S-2020.12 version, sparse memory optimizations are enabled by
default. VCS treats huge Verilog memories (> 2GB -1) as sparse memories (allocates
memory dynamically) and does not issue the Error-[MTL] Memory Too Large error
message for such memories.
• By default, an information message is generated when Address Space
Layout Randomization (ASLR) is enabled on your machine. You can use the
-suppress=ASLR_DETECTED_INFO runtime option to suppress printing of this message
in standard output (stdout) and the runtime log file.

Using Sparse Memory Models

If your design contains a large memory, the simv executable needs large amounts of
machine memory to simulate it. However, if /*sparse*/ is specified, the large memory
does not occupy the IP space, so the above 2G-1 size limit (See Memory Size Limits in
the Simulator) does not exist. The maximum memory size depends on address space
size. If /*sparse*/ is not specified, both full 64-bit and 32-bit VCS have the same
limitation (2G-1 size limit), because even with full 64-bit, VCS still uses 32-bit IP index in
back-end and runtime. So, if the memory size exceeds 2G, simulation will have errors.
You can use the /*sparse*/ pragma or meta comment in the memory declaration to
specify a sparse memory model. For example:
reg /*sparse*/ [31:0] pattern [0:10_000_000];
integer i, j;
initial
begin
for (j=1; j<10_000; j=j+1)
for (i=0; i<10_000_000; i=i+1_000)
pattern[i] = i+j;
end
endmodule

Verification Continuum™ VCS User Guide 122

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Obtaining Scope Information

In simulations, this memory model uses 4 MB of machine memory with the /*sparse*/
pragma, 81 MB without it.
The larger the memory, and the fewer elements in the memory that your design reads or
writes to, the more machine memory you will save by using this feature. It is intended for
memories that contain at least a few MBs. If your design accesses 1% of its elements you
could save 97% of machine memory. If your design accesses 50% of its elements, you
save 25% of machine memory. Do not use this feature if your design accesses more than
50% of its elements because using the feature in these cases may lead to more memory
consumption than not using it.
Note:
• Sparse memory models cannot be manipulated by PLI applications through tf calls
(the tf_nodeinfo routine issues a warning for sparse memory and returns NULL for the
memory handle).
• Sparse memory models cannot be used as a personality matrix in PLA system tasks.

Obtaining Scope Information

VCS has custom format specifications (IEEE Std 1364-2001 does not define these) for
displaying scope information. It also has system functions for returning information about
the current scope.

Scope Format Specifications

The IEEE Std 1364-2001 describes the %m format specification for system tasks for
displaying information such as $write and $display. The %m specification tells VCS to
display the hierarchical name of the module instance that contains the system task. If the
system task is in a scope lower than a module instance, it tells VCS to do the following:
• In named begin-end or fork-join blocks, it adds the block name to the hierarchical
name.
• In user-defined tasks or functions, it considers the hierarchical name of the task
declaration or function definition as the hierarchical name of the module instance.
VCS has the following additional format specifications for displaying scope information:
%i

Specifies the same as %m with the following difference: when in a user-defined task or
function, the hierarchical name is the name of an instance or named block containing the
task enabling statement or function call, not the hierarchical name of the task or function
declaration.

Verification Continuum™ VCS User Guide 123

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Obtaining Scope Information

If the task enabling statement is in another user-defined task, the hierarchical name is the
name of an instance or named block containing the task enabling statement for this other
user-defined task.
If the function call is in another user-defined function, the hierarchical name is the name of
an instance or named block containing the function call for this other user-defined function.
If the function call is in a user-defined task, the hierarchical name is the name of an
instance or named block containing the task enabling statement for this user-defined task.
%-i

Specifies that the hierarchical name is always of a module instance, not a named block or
user-defined task or function. If the system task (such as $write and $display) is in:
• A named block — the hierarchical name is that of the module instance that contains the
named block
• A user-defined task or function — the hierarchical name is that of the module instance
containing the task enabling statement or function call
Note:
The %i and %-i format specifications are not supported with the $monitor
system task.
The following commented code example shows what these format specifications do:
module top;
reg r1;

task my_task;
input taskin;
begin
$display("%m"); // displays "top.my_task"
$display("%i"); // displays "[Link]"
$display("%-i"); // displays "top.d1"
end
endtask

function my_func;
input taskin;
begin
$display("%m"); // displays "top.my_func"
$display("%i"); // displays "[Link]"
$display("%-i"); // displays "top.d1"
end
endfunction

dev1 d1 (r1);
endmodule

Verification Continuum™ VCS User Guide 124

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Obtaining Scope Information

module dev1(inport);
input inport;

initial
begin:named
reg namedreg;
$display("%m"); // displays "[Link]"
$display("%i"); // displays "[Link]"
$display("%-i"); // displays "top.d1"
namedreg=1;
top.my_task(namedreg);
namedreg = top.my_func(namedreg);
end

endmodule

Note:
• Scope hierarchical names using the %m format specifier always starts with a black
slash(\) and has a white space added to the Verilog instance name, when Verilog is the
last instance in the hierarchy. The following example illustrates a case where scope
hierarchy name uses %m format specifier.
Table 2 Content of the test.v and [Link] file

test.v [Link]

module leaf(input clk); initial $display entity top is end top; architecture arch of top
("%m"); bot bt_inst(); sub_leaf isbegin leaf_inst : entity [Link];end;entity
inst();endmodule: leaf module bot isend bot;architecture arch of bot isbegin
sub_leaf(); initial $display("%m"); bot2 sub_leaf_inst : entity work.sub_leaf;end;
inst();endmodulemodule bot2; initial
$display("%m");endmodule

Run the files using the following commands:

• vlogan -sverilog test.v
• vhdlan [Link]
• vcs top
• ./simv
The output generated is as follows:
\TOP.LEAF_INST .inst
\TOP.LEAF_INST .[Link]
\TOP.LEAF_INST
\TOP.LEAF_INST.bot_inst.SUB_LEAF_INST
\TOP.LEAF_INST.bot_inst.SUB_LEAF_INST .inst

Verification Continuum™ VCS User Guide 125

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Obtaining Scope Information

In the output from Table 2, you see that the scope hierarchical names starts with a black
slash(\) and a white space is added to the Verilog instance name

Returning Information About the Scope

The $activeinst system function returns information about the module instance that
$activeinst

contains this system function. The $activescope system function returns information
$activescope

about the scope that contains the system function. This scope can be a module instance,
a named block, a user-defined task, or a function in a module instance.
When VCS executes these system functions, it performs the following:
1. Stores the current scope in a temporary location.
2. If there are no arguments, it returns a pointer to the temporary location. Pointers are
not used in Verilog, but they are in DirectC applications.
The possible arguments are hierarchical names. If there are arguments, it compares
them from left to right with the current scope. If an argument matches, the system
function returns a 32-bit non-zero value. If none of the arguments match the current
scope, the system function returns a 32-bit zero value.
The following example contains these system functions:
module top;
reg r1;
initial
r1=1;
dev1 d1(r1);
endmodule

module dev1(in);
input in;
always @ (posedge in)
begin:named
if ($activeinst("top.d0","top.d1"))
$display("%i");
if ($activescope("[Link]","[Link]"))
$display("%-i");
end
endmodule

The following is an example of a DirectC application that uses the $activeinst system
function:

Verification Continuum™ VCS User Guide 126

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Obtaining Scope Information

extern void showInst(input bit[31:0]);

module discriminator; declaration of C function named showInst
task t;
reg[31:0] r; $activeinst system function without arguments
begin passed to the C function
showInst($activeinst);
if($activeinst("top.c1", "top.c3"))
begin
r = $activeinst;
$display("for instance %i the pointer is %s", r ? "non-zero" : "zero");
end
end
endtask
endmodule

module child;
initial discriminator.t;
endmodule

module top;
child c1();
child c2();
child c3();
child c4();
endmodule

In task t, the following occurs:

1. The $activeinst system function returns a pointer to the current scope, which is
passed to the C function showInst. It is a pointer to a volatile or temporary char buffer
containing the name of the instance.
2. A nested begin block executes only if the current scope is either top.c1 or top.c3.
3. VCS displays whether $activeinst points to a zero or non-zero value.
The C code is as follows:
#include <stdio.h>

void showInst(unsigned str_arg)

{
const char *str = (const char *)str_arg;
printf("DirectC: [%s]\n", str);
}

Function showInst declares the char pointer str and assigns to it the value of its
parameter, which is the pointer in $activeinst in the Verilog code. Then with a printf
statement, it displays the hierarchical name that str is pointing to. Notice that the function
begins the information it displays with DirectC: so that you can differentiate it from what
VCS displays.

Verification Continuum™ VCS User Guide 127

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Avoiding Circular Dependency

During simulation, VCS and the C function display the following:

DirectC: [top.c1]
for instance top.c1 the pointer is non-zero
DirectC: [top.c2]
DirectC: [top.c3]
for instance top.c3 the pointer is non-zero
DirectC: [top.c4]

Avoiding Circular Dependency

The $random system function has an optional seed argument. You can use this argument
$random[random]
$random

to make the return value of this system function the assigned value in a continuous
assignment, procedural continuous assignment, or force statement. For example:
assign out = $random(in);

initial
begin
assign dr1 = $random(in);
force dr2 = $random(in);

When you do this, you might set up a circular dependency between the seed value and
the statement, resulting in an infinite loop and a simulation failure.
This circular dependency doesn’t usually occur, but it can occur, so VCS displays a
warning message when you use a seeded argument with these kinds of statements. This
warning message is as follows:
Warning-[RWSI] $random() with a ’seed’ input
$random in the following statement was called with a ’seed’ input
This may cause an infinite loop and an eventual crash at runtime.
"exp1.v", 24: assign dr1 = $random(in);

The warning message ends with the source file name and line number of the statement,
followed by the statement itself.
This possible circular dependency does not occur either when you use a seed argument
and the return value is the assigned value in a procedural assignment statement, or when
you do not use the seed argument in a continuous, procedural continuous, or force
statement.
For example:
assign out = $random();

initial
begin
assign dr1 = $random();
force dr2 = $random();
dr3 = $random(in);

Verification Continuum™ VCS User Guide 128

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Designing With $lsi_dumpports for Simulation and Test

These statements do not generate the warning message.

You can tell VCS not to display the warning message by using the +warn=noRWSI compile-
+warn[warn]
+warn

time argument and option.

Designing With $lsi_dumpports for Simulation and Test

This section is intended to provide guidance when using $lsi_dumpports with Automatic
$lsi_dumpports[lsi_dumpports]
$lsi_dumpports $lsi_dumpports

Test Pattern Generation (ATPG) tools. Occasionally, ATPG tools strictly follow port
direction and do not allow unidirectional ports to be driven from within the device. If
you are not careful while writing the test fixture, the results of $lsi_dumpports causes
problems for ATPG tools.
Note:
See Signal Value/Strength Codes. These are based on the TSSI Standard
Events Format State Character set.

Dealing With Unassigned Nets

Consider the following example:
module test(A);
input A;
wire A;
DUT DUT_1 (A);
// assign A = 1'bz;
initial
$lsi_dumpports(DUT_1,"[Link]");
endmodule

module DUT(A);
input A;
wire A;
child child_1(A);
endmodule

module child(A);
input A;
wire Z,A,B;
and (Z,A,B);
endmodule

In this case, the top-level wire A is undriven at the top level. It is an input which goes to
an input in DUT_1, then to an input in CHILD_1 and finally to an input of an AND gate in
CHILD_1. When $lsi_dumpports evaluates the drivers on port A of test.DUT_1, it finds no
drivers on either side of port A of DUT_1, and therefore gives a code of F, tristate (input
and output unconnected).

Verification Continuum™ VCS User Guide 129

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Designing With $lsi_dumpports for Simulation and Test

The designer actually meant for a code of Z to be returned, input tristated. To achieve this
code, the input A needs to be assigned a value of z. This is achieved by removing the
comment from the line, // assign A = 1'bz;, in the above code. Now, when the code is
executed, VCS is able to identify that the wire A going into DUT_1 is being driven to a z.
With the wire driven from the outside and not the inside, $lsi_dumpports returns a code of
Z.

Code Values at Time 0

Another issue can occur at time 0, before values have been assigned to ports as you
intended. As a result, $lsi_dumpports makes an evaluation for drivers when all of the
users intended assignments have not been made. To correct this situation, you need to
advance simulation time just enough to have your assignments take place. This can be
accomplished by adding a #1 before $lsi_dumpports as follows:
initial
begin
#1 $lsi_dumpports(instance,"[Link]");
end

Cross Module Forces and No Instance Instantiation

In the following example, there are two problems.
module test;
initial
begin
force top.u1.a = 1'b0;
$lsi_dumpports(top.u1,"[Link]");
end
endmodule

module top;
middle u1 (a);
endmodule

module middle(a);
input a;
wire b;
buf(b,a);
endmodule

First, there is no instance name specified for $lsi_dumpports. The syntax for
$lsi_dumpports calls for an instance name. Since the user didn't instantiate module
top in the test fixture, they are left specifying the MODULE name top. This generates a
warning message from VCS. Because top appears only once, that instance is assumed.

Verification Continuum™ VCS User Guide 130

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Designing With $lsi_dumpports for Simulation and Test

The second problem comes from the cross-module reference (XMR) that the force
command uses. Since the module test does not instantiate top, the example uses an XMR
to force the desired signal. The signal being forced is port a in instance u1. The problem
here is that this force is done on the port from within the instance u1. The user expects this
port a of u1 to be an input, but when $lsi_dumpports evaluates the ports for the drivers,
it finds that port a of instance u1 is being driven from inside and therefore returns a code of
L.

To correct these two problems, you need to instantiate top inside test, and drive the
signal a within test. This is done in the following way:
module test;
wire a;
initial
begin
force a = 1'b0;
$lsi_dumpports(test.u0.u1,"dump.out2");
end
top u0 (a);
endmodule

module top(a);
input a;
middle u1 (a);
endmodule

module middle(a);
input a;
wire b;
buf(b,a);
endmodule

By using the method in this example, the port a of instance u1 is driven from the outside,
and when $lsi_dumpports checks for the drivers it reports a code of D as desired.

Signal Value/Strength Codes

The enhanced state character set is based on the TSSI Standard Events Format State
Character set with additional expansion to include more unknown states. The supported
character set is as follows:

Testbench Level (only z drivers from the DUT)

D low

U high

N unknown

Verification Continuum™ VCS User Guide 131

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Designing With $lsi_dumpports for Simulation and Test

Z tristate

d low (2 or more test fixture drivers active)

u high (2 or more test fixture drivers active)

DUT Level (only z drivers from the testbench)

L low

H high

X unknown (don’t care)

T tristate

l low (2 or more DUT drivers active)

Testbench Level (only z drivers from the DUT)

h high (2 or more DUT drivers active

Drivers Active on Both Levels

0 low (both input and output are active with 0

values)

1 high (both input and output are active with 1

values)

? unknown

F tristate (input and output unconnected)

A unknown (input 0 and output unconnected)

a unknown (input 0 and output X)

B unknown (input 1 and output 0)

b unknown (input 1 and output X)

C unknown (input X and output 0)

c unknown (input X and output 1)

f unknown (input and output tristate)

Verification Continuum™ VCS User Guide 132

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Translating VHDL Package to SystemVerilog Package

Translating VHDL Package to SystemVerilog Package

VCS mixed-HDL simulation supports the translation of VHDL types and constants in a
package to its equivalent SystemVerilog types and constants. The VHDL package is
translated automatically when the -gen_sv_pkg option is included during the analysis
-gen_sv_pkg

phase.

Use Model
To translate the VHDL types and constants in a package to its equivalent SystemVerilog
package, include the -gen_sv_pkg option during the analysis phase. All packages must
be self-contained. That is, the types, constants, and so on declared within a package
might not use types, constants, and so on declared in another package unless the
dependent entities are declared in STANDARD or IEEE packages. Such types, constants,
and so on are not translated and a warning message is displayed.
See the following table Table 3 for the supported VHDL types and constants and its
equivalent mapping in the SystemVerilog package.
By default, the translated package is saved in the invocation directory of vhdlan (the
target directory). You can override the default directory using the -gen_sv_pkg_dir
<target directory> option.

For example, consider this VHDL package:

bit_conv.vhd
library IEEE;
use IEEE.STD_LOGIC_1164.all;

package bit_pkg is
type bit_null_t is array (0 to 0) of bit;
type s_t is array (1024 downto 0) of std_logic;
type s_vec_t is array (0 to 1024) of std_ulogic_vector(1 downto 0);
type bit_mda is array (integer range 0 to 1024,integer range 0 to 1024)
of bit_vector(1 downto 0);
TYPE bit_range is array (-10 to 25) of bit;
TYPE pet IS (dog,cat,bird,horse,kid);
TYPE pet_it IS ARRAY (pet RANGE dog TO cat) OF bit;
TYPE Byte IS ARRAY (7 DOWNTO 0) OF bit;
TYPE Memory IS ARRAY (0 TO 2**16-1) OF Byte;
subtype s1_t is bit;
subtype s1_vec_t is bit_vector(1024 downto 0);
subtype s1_vec_t_2d is s1_vec_t;
subtype s1_vec_t_3d is s1_vec_t_2d;
type int_t is array (7 downto 0) of integer;
type nat_t is array (7 downto 0) of natural;
type pos_t is array (7 downto 0) of positive;

Verification Continuum™ VCS User Guide 133

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Translating VHDL Package to SystemVerilog Package

end bit_pkg;

package body bit_pkg is

end bit_pkg;

Use these command lines to convert the bit_conv.vhd package to its equivalent
SystemVerilog package, bit_pkg.sv. Analyze the resultant file using the -sverilog
switch.
% vhdlan -nc bit_conv.vhd -gen_sv_pkg
% vlogan -sverilog bit_pkg.sv

This SystemVerilog package is generated:

bit_pkg.sv
package bit_pkg;
typedef bit [0:0] bit_null_t;
typedef logic [1024:0] s_t;
typedef logic [1:0] s_vec_t [0:1024];
typedef bit [1:0] bit_mda [0:1024][0:1024];
typedef bit [-10:25] bit_range;
typedef enum {
dog=0,
cat=1,
bird=2,
horse=3,
kid=4
} pet;
typedef bit [0:1] pet_it;
typedef bit [7:0] Byte;
typedef Byte Memory [0:65535];
typedef bit s1_t;
typedef bit [1024:0] s1_vec_t;
typedef bit [1024:0] s1_vec_t_2d;
typedef bit [1024:0] s1_vec_t_3d;
typedef int int_t [7:0];
typedef int nat_t [7:0];
typedef int pos_t [7:0];
endpackage

VHDL Type Mapping

This table lists the mapping of VHDL types with its equivalent SystemVerilog types:
Table 3 VHDL Type Mapping With Its SystemVerilog Equivalent

VHDL Type SystemVerilog

User defined Enumerated type 2-state enumeration type

Verification Continuum™ VCS User Guide 134

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Translating VHDL Package to SystemVerilog Package

Table 3 VHDL Type Mapping With Its SystemVerilog Equivalent (Continued)

VHDL Type SystemVerilog

character byte

string byte array

bit bit

boolean bit

std_logic, std_ulogic logic

integer, discrete ranged types, and subtypes int

real real

Constrained array of real Unpacked array of real

Constrained std_logic_vector, 1 dimensional packed array of logic (signed if there is a

std_ulogic_vector ‘use ieee.std_logic_signed.all’)

Constrained unsigned 1 dimensional packed array of logic (unsigned)

Constrained signed 1 dimensional packed array of logic (signed)

1 dimensional constrained array of 1 dimensional packed array of logic (unsigned)

std_[u]logic

1 dimensional constrained array of bit, 1 dimensional packed array of bit (unsigned)

Boolean

1 dimensional constrained array of integer or 1 dimensional unpacked array of int or 2-state enum type
enumerated type (Verilog does not allow packed int/enum array)

Record with elements of packable field types: Packed struct

std_[u]logic, array of std_[u]logic/, integer,
bit, boolean, enumeration, array of bit, array
of boolean, and other records with packable
fields.

Records containing types that do not map to Unpacked struct

packable field types

1- or N-dimensional: array of Respectively: unpacked array

std_[u]logic_vector, bit_vector array of (1-dimensional/N- dimensional) of packed logic
std_[u]logic, bit array same as above

Multidimensional array (M1:M2,N1:N2) of Unpacked array ([M1:M2] [N1:N2]) of packed logic array
std_[u]logic_vector, bit_vector

1-dimensional array of packable record Unpacked array of packed struct

Verification Continuum™ VCS User Guide 135

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
Translating VHDL Package to SystemVerilog Package

Table 3 VHDL Type Mapping With Its SystemVerilog Equivalent (Continued)

VHDL Type SystemVerilog

Arrays of records containing types that do not Not supported

map to packable field types

Multidimensional array of scalar types other Not supported

than std_[u]logic and bit, record types, and
array types other than std_[u]logic_vector and
bit_vector

Packable field types are types that are allowed in packed arrays and structs in Verilog.
These are single bit data types (bit, logic, reg), integral types (byte, shortint, int, longint,
integer), and two-state enumerated types along with arrays and structs thereof.
Note:
The translation does not happen for the unsupported types and a warning
message is displayed. However, the translation proceeds to the subsequent
types. You can see these details as a comment in the translated SystemVerilog
package, which states the reason for non-translation.

Limitations
Following are the VHDL types that are not supported for translation:
• Character enumeration types.
• Physical types.
• Unconstrained array types.
• File types.
• Access types.
• Non-type package constructs, such as functions, procedures, shared variables, and
package signals.
• Declarations containing extended identifiers.
• VHDL resolved [Link] cannot have their resolution function translated. However,
the data type without the resolution function is translated.
In addition, these conditions disable translation:
• Types or constants that are named using a SystemVerilog keyword.
• Arrays containing null ranges.

Verification Continuum™ VCS User Guide 136

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
VITAL2000 Negative Constraint Calculation

• Types dependent upon other types that have not been translated. This excludes the
types dependent upon constants that have not been translated; the evaluated value
of constant is used rather than a reference to the constant itself. The named constant
declarations in the package are also translated into the named constant declarations
in the resultant SystemVerilog package. The value of the constant (the RHS of the
declaration) is also translated by value rather than by reference similar to types.
• Enumeration types containing character literals (except built-in enumeration types,
such as std_ulogic, bit, and character)

VITAL2000 Negative Constraint Calculation

VCS supports the VITAL2000 Negative Constraint Calculation (NCC) algorithm.
Following are the key changes in the VITAL2000 NCC algorithm:
• Vector support for VITAL generics has been added.
• Additional errors and warnings are reported by the VITAL2000 NCC routines:
◦ After the NCC stage, if the resulting value of any timing generic sub-element is
negative, the value is set to 0 ns, and a warning is issued.
◦ A vector timing generic must be CrossArc or ParallelArc. Any other size of this
timing generic is not allowed.
CrossArc is a vector timing arc whose size is equal to the product of the sizes of
the two ports corresponding to the timing generic. ParallelArc is a vector timing arc
whose size is equal to the individual sizes of the two ports corresponding to the
timing generic.

Using VITAL2000 NCC

VCS, by default, applies the VITAL95 NCC algorithm to VITAL models. To use VITAL2000
NCC, set the USE_VITAL_2000 variable to TRUE in the synopsys_sim.setup file.
The VCS four-step approach for negative constraint calculation remains unchanged for
VITAL2000 NCC. For more information about this approach, see the “Negative Constraint
Calculation (NCC)” section.

Verification Continuum™ VCS User Guide 137

V-2023.12
 Feedback
Chapter 3: Modeling Your Design
VITAL2000 Negative Constraint Calculation

Disabling VITAL2000 Conformance Checks

To disable conformance checks while using VITAL2000 NCC, set RELAX_CONFORMANCE
and RELAX_CONFORMANCE_2K variables to TRUE in the synopsys_sim.setup file as shown
below:
RELAX_CONFORMANCE_2K = TRUE
RELAX_CONFORMANCE = TRUE

By default, both these variables are set to FALSE.

Verification Continuum™ VCS User Guide 138

V-2023.12
 Feedback

4
Compiling/Elaborating the Design
This chapter describes the following sections:
• Compiling/Elaborating the Design in the Debug Mode
• Optimizing Simulation Performance for Desired Debug Visibility With the
-debug_access Option
• Dynamic Loading of DPI Libraries at Runtime
• Dynamic Loading of PLI Libraries at Runtime
• Key Compilation or Elaboration Features

Compiling/Elaborating the Design in the Debug Mode

Debug mode, also called interactive mode, is typically used (but not limited to):
• During your initial phase of the design, when you need to debug the design using
debug tools, such as Verdi or UCLI.
• When you are using PLIs.
• When you use UCLI commands to force a signal to write into registers/nets.
VCS provides the following compile-time options for the debug mode:
-debug_access(+<option>),
-debug_access

-debug_region=(<option>)(+<option>)

The following examples show how to compile the design in full, partial, and minimum
debug modes:
Compiling/Elaborating the Design in the Partial Debug Read Mode
% vcs -debug_access+r [ ] TOP.v

Compiling/Elaborating the Design in the Full Debug Mode

% vcs -debug_access+all [ ] TOP.v

Verification Continuum™ VCS User Guide 139

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Compiling/Elaborating the Design With the Desired Debug Capability

% vcs -debug_access<+options> [compile_options] TOP.v

For more information on -debug_access and -debug_region options, see the Optimizing
Simulation Performance for Desired Debug Visibility With the -debug_access Option
section.

Optimizing Simulation Performance for Desired Debug Visibility

With the -debug_access Option
You can use the -debug_access option at compile time to selectively enable the required
debug capabilities in a simulation. You can optimize simulation performance by enabling
only the required debug capabilities.
This following topics describe this feature in detail:
• Use Model
• Specifying Design Regions for -debug_access Capabilities
• Automatic Debug Capability Addition Using $fsdbDumpvars(level,path)
• Enabling Additional Debug Capabilities
• Reduction in the Objects Being Dumped
• Using -debug_access With Tab Files (With -P Option)
• Unused Tab File Calls
• Including Tab Files
• Interaction With Other Debug Options

Use Model
Following is the use model of the -debug_access option:
-debug_access(+<option_name>)*
-debug_access

Table 4 describes the supported options of -debug_access.

The -debug_access option without any additional option_name enables VPD and FSDB
dumping capability. This option allows you to enter the UCLI prompt and use only the run,
quit, and dump commands.

Verification Continuum™ VCS User Guide 140

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Table 4 Supported Options of -debug_access

Option Name Description

r This option enables the read capability for the entire design. This enables PLI
access to get value, and enables the UCLI get command. This is the minimum
debug option to invoke the Verdi interactive mode.

w This option applies write (deposit) capability to the registers and variables for the
entire design.

wn This option applies write (deposit) capability to the nets for the entire design.

fn This option applies force capability to the nets for the entire [Link] option is
equivalent to -debug_access+r+fn.

fwn This option applies write (deposit) and force capability to all nets in the [Link]
option is equivalent to -debug_access+r+wn+fn.

f This option enables the following: Read capability on registers, variables, and
nets Write (deposit) capability on registers and variables Force capability on
registers, variables, and netsThis option is equivalent to -debug_access+r+w+fn+f

drivers This option enables driver debugging [Link] option is equivalent to

drivers

-debug_access+r+drivers.

line This option enables line debugging. It allows you to use the commands for
line

step/next and line [Link] option is equivalent to -debug_access+r+line.

cbk This option enables dumping of SystemVerilog string type signals and
cbk

PLI-based callbacks on nets, registers, and [Link] option is equivalent to

-debug_access+r+cbk.

cbkd This option enables both dumping and PLI-based callbacks on dynamic nets,
cbkd

registers, and variables defined in classes. Class object debugging is also

[Link] option is equivalent to -debug_access+r+line+cbkd.

thread This option enables the debugging of the SystemVerilog [Link] option is
thread

equivalent to -debug_access+r+thread.

class This option enables debugging of the SystemVerilog classes and class
class

objects, but the capability is also applied to the remaining portion of the
design as specified by the -debug_region [Link] option is equivalent
to:-debug_access+r+w+thread+line+cbk+cbkd

pp This option enables write capability on registers and variables, callbacks for the
pp

entire design, driver capability, and assertion debug capability. This option is
equivalent to:-debug_access+w+cbk+drivers

dmptf This option enables dumping of ports and internal nodes/memories of

dmptf

tasks/functions.

Verification Continuum™ VCS User Guide 141

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Table 4 Supported Options of -debug_access (Continued)

Option Name Description

all This option enables all the above options. This option is equivalent
to:-debug_access+r+w+wn+f+fn+fwn+drivers+line+cbk+cbkd+
thread+class+pp+dmptf

-memcbk The -debug_access-memcbk option disables callbacks for memories and

-memcbk

multidimensional arrays (MDAs). By default, -debug_access enables callbacks for

memories and [Link] more information, see the Incrementally Removing Debug
Capabilities section.

reverse This option enables the reverse debugging feature.

reverse

designer This option enables the following debug capabilities:

designer

• Read and write for both variables and nets

• PLI and value change callbacks and line callback
• FSDB/VPD dumping capability
• Debugging or dumping of cell ports
• Class and thread debugging (no SystemVerilog Testbench debugging) • Driver
debugging
This option is equivalent to: -debug_access+line+r+w+wn+cbk
-debug_region+cellports
You can use the -debug_access+designer option for debugging design and
simulation mismatches.
This option does not support the following:
• Class and thread debugging (no SystemVerilog Testbench debugging)
• Driver debugging

simctrl This option does not support the following: Class and thread debugging (no
simctrl

SystemVerilog Testbench debugging) Driver debugging Line stepping

This option enables the following debug capabilities:
• PLI and value change callbacks
• Assertion control (not assertion dumping)
• FSDB/VPD dumping capability
You can use the -debug_access+simctrl option for simulation control. This option
is equivalent to:-debug_access+r+cbk+assert_c
For more information on +assert_c, see the Assertion Debug Support section.
• Class and thread debugging (no SystemVerilog Testbench debugging)
• Driver debugging
• Line stepping

verbose Reports the summary of all the -debug_access and -debug_region options
verbose

passed to the vcs command line.

Example: -debug_access+r+line+class+drivers

Verification Continuum™ VCS User Guide 142

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Key Points to Note

• The -debug_access options are case-insensitive.
• Read capability is disabled by default with the -debug_access option.
• The following abbreviation of -debug_access is supported:
-debug_acc

• The dynamic value change callbacks are enabled as part of the all and class
options.

Incrementally Removing Debug Capabilities

VCS allows you to remove the debug capabilities specified with the -debug_access
option. The following is the syntax to remove the debug capabilities:
-debug_access(+)*(-)*

VCS removes the debug capabilities of the options specified with the “-” sign. For
example, you can use the -debug_acc+all-f option to remove force capability.
Key Points to Note
• VCS issues a warning message when you specify the same option with -debug_acc
for both addition and removal of debug capability. For example, VCS issues a warning
message when both -debug_acc+all-f and -debug_acc+f options are specified.
• If the -debug_acc+all option is specified initially and later if you specify -debug_acc-,
the final option is as follows: -debug_acc+all- For example, if both -debug_acc+all
and -debug_acc-f options are specified, the final option -debug_acc+all-f removes
the force capability.
• VCS issues a warning message if you use -all, -class, -designer, or -simctrl
options with -debug_access.
• If you try to remove the capability that has not been added, VCS issues a warning
message saying that the specified -<option> is ignored.
• Multiple additions/subtractions of the same capability are treated as a single addition/
subtraction. No warning message is issued in this case.
• It is recommended to use this feature with the all, class, designer, and simctrl
options of -debug_access.

Verification Continuum™ VCS User Guide 143

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Assertion Debug Support

The following assertion debug options are supported with -debug_access:
Table 5 Assertion Debug Options of -debug_access

Option Description

-assert_d This option allows you to remove the

assertion dumping capabilities from
the -debug_access+designer and
-debug_access+simctrl options.

+assert_c This option enables assertion control

capabilities.

+assert_f This option enables the following:

• Dumping failures and successes for both
concurrent and immediate assertions
• Assertions control

Verdi One Search Support

The Verdi One Search feature allows you to search for design information in a database.
By default, One Search feature searches for symbols inside the simv executable. Shared
libraries that are dynamically linked to simv are not searched. The -debug_access
+idents_so option enables searching inside the shared libraries.

The Verdi One Search feature uses an internal database to quickly perform identifier
search in the design. The -debug_access+idents_db option allows you to build the
database at compile time for Verdi One Search.

Reporting Global Debug Capability Diagnostics

You can use the -debug_report option at compile time to enable the reporting of debug
capability added to the design.
The diagnostics are reported in an ASCII text file named [Link]. This file is
generated in the current working directory and cannot be renamed during compilation. You
can rename the file after compilation. There is no VCS option to rename the file.
The debug capability diagnostics report allows you to identify the source of debug
capability and to reduce debug capability in an informed manner.

Verification Continuum™ VCS User Guide 144

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

The following information is recorded in the debug diagnostics report file:

• Debug capability derived from compile options. You can view this diagnostic report
after compilation.
• Debug capability declared within a tab file. This diagnostic report contains File IDs
associated with the capability.
• Global Verilog functionality that enables debug capability.
Example
Consider the following files for the global debug capability diagnostic report:

Example 3 [Link]

module dutA(input clk, output reg a,b);

always@(negedge clk)
begin
a=clk;
b=a;
end
endmodule

`celldefine
module dutB(input clk, output reg a);
wire fgh;
always@(posedge clk)
a=clk;
endmodule
`endcelldefine

module mytop;
reg clk=0;
wire a [0:2];
dutA d1(clk,a[0],a[2]);
dutB d2(clk,a[1]);
initial begin
clk=0;
forever #1 clk = ~clk;
end
initial #100 $finish;
endmodule

Example 4 [Link]
acc+=frc:*

To compile the [Link] file, execute the following command:

% vcs -P [Link] -debug_access+cbk -debug_report [Link]

Verification Continuum™ VCS User Guide 145

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

To view the global debug capability diagnostic report, execute the following command:
% cat [Link]

Following is the debug diagnostic report file:

Figure 1 Debug Diagnostic Report

Limitations
This feature does not support the following compile-time options:
• The +optconfigfile option as it is replaced by the instance-based tab file.
• The +acc* option.

Specifying Design Regions for -debug_access Capabilities

You can use the -debug_region option to have better control over the performance of
-debug_region

-debug_access. The -debug_region option enables you to apply debugging capabilities

to the desired portion of a design.

Verification Continuum™ VCS User Guide 146

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

You must use the -debug_region option along with the -debug_access option at compile
time.
Following is the use model of -debug_region:
-debug_region(option_name)(option_name)*

Table 6 describes the options supported by -debug_region.

Table 6 Test

Option Name Description Default Functionality if

-debug_region is not specified

+cell Applies debug capabilities to both real Debug capability is not applied to
+cell

cell modules and the ports of real cell both real cell modules and the ports
[Link] modules are Verilog modules of real cell modules.
that are bound with `celldefine and
`endcelldefine compiler directives, as
described in Verilog 1800-2012 LRM,
section 22.10.

+cellports Applies debug capabilities only to the ports Debug capability is not added to the
+cellports

of real cell modules and lib cell modules. ports of real cell modules.

-lib The -debug_region-lib option removes Debug capabilities are applied to the
-lib

debug capabilities from libraries (files libraries.

passed to VCS with the preceding -v/-y
compiler options).

+encrypt Applies debug capabilities to the Debug capability is not applied to

+encrypt

fully-encrypted instances (modules, the fully-encrypted instances.

programs, packages, and interfaces).

=sv The -debug_region=sv option applies Debug capability is applied to

=sv

debug capabilities only to the program, Verilog, VHDL, and SystemC.

package, interface or module containing
SystemVerilog constructs, and to
SystemC. Debug capabilities are applied
to SystemVerilog code inside cells and
fully encrypted blocks only when the +cell
option is also used. Debug capabilities
are applied to the Verilog code inside fully
encrypted modules only when the +encrypt
option is also used.

Verification Continuum™ VCS User Guide 147

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Table 6 Test (Continued)

Option Name Description Default Functionality if

-debug_region is not specified

=verilog The -debug_region=verilog option Debug capability is applied to

=verilog

applies debug capabilities to all Verilog code Verilog, VHDL, and SystemC.
and to SystemC. Debug capabilities are
applied to the Verilog code inside cells only
when the +cell option is also used. Debug
capabilities are applied to the Verilog code
inside fully encrypted modules only when
the +encrypt option is also used.

=vhdl The -debug_region=vhdl option applies Debug capability is applied to

=vhdl

debug capabilities to the VHDL code and to Verilog, VHDL, and SystemC.
SystemC.

Note:
• VCS applies debug capability to the standard packages by default.
• The -debug_region options are case-insensitive.

Example
• -debug_access+class -debug_region+cell
Applies class debug capabilities to the design and cell modules.

Key Points to Note

• The -debug_region option works only for the capabilities specified by the
-debug_access option. It has no effect on the capabilities specified in tab files or
configuration files.
• An error message is issued if you use -debug_region without an option.
• An error message is issued if you use -debug_region without -debug_access.

Region Debug Enhancements

The -debug_region functionality is enhanced to include the following features:
• Apply debug capabilities to a specific instance hierarchy
• Apply debug capabilities to the partially encrypted modules
This enhancement gives you more flexibility in applying debug capabilities to a specific
instance hierarchy of the design, thereby reducing the number of objects having debug
capability.

Verification Continuum™ VCS User Guide 148

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Debugging Desired Instance of a Design Using -debug_region

Following is the use model for debugging desired instance of a design using
-debug_region:

-debug_region=level,path(<option>)*

or,
-debug_region+level,path(<option>)*

Where,
• path identifies the hierarchical path of the specified instance. An error message is
issued if the specified path does not exist in the design. If path is a top module, and
only one top module exists in the design, a warning message is issued.
path can also include escaped names, but for this case you must enclose the
command in double quotes. For example,
% vcs -debug_access "-debug_region=0,\my%top .dut" …

• level specifies the hierarchical depth of the instance. If level=0, then debug
capability is applied to the specified instance and all instances under it.
The -debug_region=level,pathoption applies debug capabilities only to the specified
instances of a module. The application of debug capability stops when a leaf instance, cell,
fully encrypted instance, or an mixed HDL boundary is detected.
You must specify the -debug_region+cell option to consider cells (modules that are
wrapped with `celldefine - `endcelldefine compiler directives) for debugging. If
-debug_region+cell is not specified, the application of debug capability stops if a cell is
detected when traversing down the level of hierarchy.
For allowing debug of cells only in a specific design branch, you must use the
-debug_region=level,path+cell or -debug_region=level,path -debug_region
+cell option.

You can specify multiple -debug_region=level,path commands as follows:

-debug_region=level1,path1 -debug_region=level2,path2

or,
-debug_region=level,path1,path2

For example,
-debug_region=0,path1 -debug_region=0,path2

In this case -debug_access capability is applied to both module instances starting with
path1 and path2.

Verification Continuum™ VCS User Guide 149

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Examples:
• -debug_region=0,my_top.dut
Applies -debug_access capabilities only to the module instances starting at instance
my_top.dut and all module instances under my_top.dut. The application of debug
capability stops when a leaf instance, cell, fully encrypted instance, or an mixed HDL
boundary is reached.
• -debug_region=0,my_top.dut+cell
Applies -debug_access capabilities to the following:
◦ Module instances starting at instance my_top.dut and all module instances under
my_top.dut.

◦ Cells under my_top.dut.

• -debug_region=2,my_top.dut
Applies -debug_access capabilities only to the module instances starting at instance
my_top.dut and the child instances of my_top.dut. Where, my_top.dut is the first
level and the child instances are second level.
• -debug_region=0,my_top.dut+dut
This option combination is not allowed. An error message is issued in this case.
• -debug_region=0,my_top.dut+tb
This option combination is not allowed. An error message is issued in this case.
Key Points to Note
• You cannot use the -debug_region=level,path option in combination with the
-debug_region=sv|verilog|vhdl option.

• The -debug_region option applies only to the Verilog portion of a design. If you have a
mixed design and the -debug_region=level,path option is specified, then the debug
capabilities are applied only to the Verilog portion of the specified instance.
• For a mixed design, -debug_access is applied to the entire VHDL portion of the
design.

Verification Continuum™ VCS User Guide 150

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Automatic Debug Capability Addition Using

$fsdbDumpvars(level,path)
If the design is not compiled with any -debug_access* option and VERDI_HOME is set,
you can use the $fsdbDumpvars(level,path) system task to automatically add debug
capability to the applicable portion of the design being dumped. For example,
• $fsdbDumpvars() automatically adds -debug_access option to the compile command.
• $fsdbDumpvars(level,path) automatically adds -debug_access
-debug_region=level,path options to the compile command.

Enabling Additional Debug Capabilities

This section consists of the following subsections:
• Driver/Load Debug Capability
• Statement Debug Capability
• Force/Deposit Debug Capability
• Class Debug Capability

Driver/Load Debug Capability

By default, the driver/load debug support is disabled. You must use the -debug_access
+drivers option at compile time to enable the driver/load debug support. This option
enables the following capabilities:
• Active drivers
• UCLI show driver/load
$countdrivers

Note:
An error message is issued when you use driver/load debug functionality
without specifying -debug_access+drivers.

Statement Debug Capability

By default, statement debugging is disabled. In UCLI, the step, next, and file/line
breakpoints are disabled. To enable the statement debug capability, use the
-debug_access+line option at compile time.

Verification Continuum™ VCS User Guide 151

V-2023.12
Chapter 4: Compiling/Elaborating the Design Feedback
Optimizing Simulation Performance for Desired Debug Visibility With the -debug_access
Option

Force/Deposit Debug Capability

By default, changing the value of a signal, variable, or net is disabled. In UCLI, the force
command is disabled, and in VPI, the vpi_put_value() function is disabled. To enable
value change debug capability, use the following options at compile time:
• -debug_access+w: For writing (depositing) values to the registers or variables.
• -debug_access+wn: For writing (depositing) values to the nets.
• -debug_access+f: For writing (depositing) values to the registers and variables, and
for forcing values onto the registers, variables, and nets.
• -debug_access+fn: For forcing values onto the nets.

Class Debug Capability

Class debugging capability enables line stepping, object IDs, thread debugging, and write
capability.
This allows for object-browser debugging and the usage/display of object IDs in Verdi. It
also allows for constraint debugging and thread debugging in Verdi/UCLI.
By default, class debugging is disabled. To enable class debugging, use the
-debug_access+class option at compile time.

Reduction in the Objects Being Dumped

The -debug_access option does not dump the ports of tasks and functions by default. You
can use the -debug_access+dmptf option to dump the ports of tasks and functions.
-debug_access+dmptf

Using -debug_access With Tab Files (With -P Option)

If you use -debug_access with tab files, the capabilities of -debug_access and the tab
files are combined. If you have a tab file with force capability applied using the -P option
on a module (for example, testmod), and -debug_access+r is specified, then the debug
access capability is applied to all instances, but the force capability is applied only to the
instances of the testmod module.
The -debug_access capabilities are ignored if the design is also compiled with
+applylearn. In this case, interactive debug mode is enabled.

Unused Tab File Calls

VCS does not apply the debug capabilities of unused tab file calls to the design, except
when the design contains SystemC or Spice usage. If a tab file call is marked “persistent”,
then the associated debug capabilities are applied to the design.

Verification Continuum™ VCS User Guide 152

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Dynamic Loading of DPI Libraries at Runtime

Including Tab Files

The -debug_access option automatically includes all the compile options required for VPD
and FSDB dumping. There is no need to specify additional options to enable dumping,
adding tab files, or adding PLI objects to link with simv.

Dumping FSDB
If the VERDI_HOME environment variable is set, you can use -debug_access to dump
FSDB. There is no need to specify Verdi PLI and tab files on the VCS command line to
dump FSDB.

Interaction With Other Debug Options

If you specify multiple -debug_access options on the same command line, then the
functionality is combined. For example, specifying -debug_acc+w -debug_acc+drivers
is equivalent to -debug_acc+w+drivers.

Dynamic Loading of DPI Libraries at Runtime

This feature is the implementation of the SV LRM appendix on including non-Verilog
or non-SystemVerilog code, through the DPI, in a design or testbench. For details,
see, Annex J, “Inclusion of foreign language code” in SystemVerilog LRM IEEE Std.
1800-2012.
For partition compile, if you declare an import DPI function, and you do not provide the C
source code on the VCS command line, VCS displays the following error message:
ibvcspc_test_IAwm9b.so: undefined reference to `my_export_dpi'
collect2: ld returned 1 exit status

With dynamic loading, this error condition with partition compile and C/C++ source code
does not occur.

Use Model
Dynamic loading of a DPI shared library at runtime requires a number of steps before the
simv command line. These steps are as follows:

► For three-step flow, analyze and elaborate the Verilog or SystemVerilog code. For
example:
%vlogan -sverilog test.v

% vcs top_level

Verification Continuum™ VCS User Guide 153

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Dynamic Loading of DPI Libraries at Runtime

For two-step flow, compile the Verilog or SystemVerilog code. For example:
%> vcs -sverilog test.v

1. Compile the C code and create a shared object, for example:

%> gcc -fPIC -Wall ${CFLAGS} -I${VCS_HOME}/include \
-c test.c

%> gcc -fPIC -shared ${CFLAGS} -o [Link] test.o

2. Load the shared object at runtime using one of the following runtime options:
-sv_lib -sv_root -sv_liblist
-sv_liblist

For example, simv command lines for loading the shared object are as follows:

where the bootstrap file contains an entry specifying the location of the
library

%> simv -sv_liblist bootstrap_file

%> simv –sv_root path_relative_or_absolute_to_shared_object \

-sv_lib test

%> simv -sv_lib test

where the path is relative or absolute to the shared object

the extension for the shared object is omitted

The following is an example of a bootstrap file:

#!SV_LIBRARIES
myclibs/lib1
myclibs/lib3
proj1/clibs/lib4
proj3/clibs/lib2

Where, lib1, lib2, lib3, and lib4 are shared object file names that need to be specified
without extension.

Verification Continuum™ VCS User Guide 154

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Dynamic Loading of PLI Libraries at Runtime

Dynamic Loading of PLI Libraries at Runtime

You can dynamically load a PLI library at runtime instead of linking the PLI library at
PLI library
loading dynamically at runtime

compile time. For this, perform the following steps:

1. Compile the design including the PLI table file for PLI libraries with the -P compile-time
option:
% vcs -P [Link] design_source_files

2. Load the libraries dynamically at runtime, specify the libraries with the -load runtime
-load[-]
-load

option, and enter -load for each library:

% simv -load ./[Link] -load ./[Link]

In this example, there are two -load options for the libraries named [Link] and
[Link].

Note:
If the PLI library is linked at compile time, the library has precedence over a PLI
library loaded at runtime.

Key Compilation or Elaboration Features

This section describes the following features in detail with a usage model and an example:
• Initializing Verilog Variables, Registers, and Memories
• Overriding Generics and Parameters
• Checking for x and z Values In Conditional Expressions
• Cross Module References (XMRs)
• Verilog Configurations and Libmaps
• Lint Warning Message for Missing ‘endcelldefine
• Error/Warning/Lint Message Control
• Extracting the Files Used in Elaboration/Compilation
• Reducing Compile Time for Post-Process Only Debug

Verification Continuum™ VCS User Guide 155

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Initializing Verilog Variables, Registers, and Memories

You can use one of the following options to initialize Verilog variables, registers, and
memories in a design:
• +vcs+initreg+random
Enables initialization for an entire design.
• +vcs+initreg+config+config_file
Enables initialization for selective parts of a design.
This section discusses the following topics:
• Initializing Verilog Variables, Registers, and Memories for an Entire Design
• Initializing Verilog Variables, Registers, and Memories in Selective Parts of a Design
• Selections for Initialization of Registers or Memories
• Reporting the Initialized Values of Variables, Registers, and Memories

Initializing Verilog Variables, Registers, and Memories for an

Entire Design
You can use the +vcs+initreg+random option to initialize all bits of Verilog variables and
registers defined in sequential UDPs and memories, including multi-dimensional arrays
(MDAs) in your design to a random value of 0 or 1, at time zero. The default random seed
is used.
The supported data types are:
• reg
• bit
• integer
• int
• logic
To enable initialization for an entire design, the +vcs+initreg+random option must be
+vcs+initreg+random

specified at compile time, and one of the following options must be specified at runtime:
• +vcs+initreg+0
• +vcs+initreg+1

Verification Continuum™ VCS User Guide 156

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• +vcs+initreg+random
• +vcs+initreg+seed_value
Example-1:
% vlogan [ ] file4.v file5.v file6.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]

Note:
In the vhdlan command line, specify the bottom-most entity first, then move up
in order.
% vcs +vcs+initreg+random [ ] .v
.v .v

% simv +vcs+initreg+random [ ]

All Verilog variables, registers, and memories are assigned random initial values.
Example-2:
% vlogan [ ] file4.v file5.v file6.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]
% vcs +vcs+initreg+random [ ] .v .v .v

% simv +vcs+initreg+0 [ ]

All Verilog variables, registers, and memories are assigned initial value of 0.
For more information on the +vcs+initreg+random compile-time option, see “Option for
Initializing Verilog Variables, Registers and Memories with Random Values”.
For more information on the runtime initialization options, see “Option for Initializing Verilog
Variables, Registers and Memories at Runtime”.
The initialization options may cause potential race conditions due to the initialized values
specified. For more information on race condition prevention, see “Option for Initializing
Verilog Variables, Registers and Memories with Random Values”.

Initializing Verilog Variables, Registers, and Memories in Selective

Parts of a Design
You can use the +vcs+initreg+config+config_file option to specify a configuration
+vcs+initreg+config[vcs+initreg+config
+vcs+initreg+config

file for initializing Verilog variables, registers defined in sequential UDPs and memories,
including multi-dimensional arrays (MDAs) in your design, at time zero. In the configuration
file, you can define the parts of a design to apply the initialization and the initialization
values of the variables.

Verification Continuum™ VCS User Guide 157

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The supported data types are:

• reg
• bit
• integer
• int
• logic
To enable the initialization in selective parts of a design, you can specify the +vcs
+initreg+config+config_file option at compile time and/or at runtime. The
config_file option is the configuration file used for the initialization.

If you specify the +vcs+initreg+config+config_file option at both compile time and

runtime, then the configuration file specified at runtime overrides the configuration file
specified at compile time. Specifying the configuration file at runtime allows you to rerun
the existing simv with the new configuration file without the need to recompile. For more
information, see “Option for Initializing Verilog Variables, Registers and Memories in
Selective Parts of a Design at Runtime”.
Example: Using the +vcs+initreg+config+config_file Option at Compile Time
% vlogan [ ] file4.v file5.v file6.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]

Note:
In the vhdlan command line, specify the bottom-most entity first, then move up
in order.
% vcs +vcs+initreg+config+test_config
[ ] .v .v .v

% simv [ ]

The configuration file, test_config, is used for initialization.

For details on the configuration file entries, see “Option for Initializing Verilog Variables,
Registers and Memories in Selective Parts of a Design”.

Selections for Initialization of Registers or Memories

When the +vcs+initreg+random +vcs+initreg+config+config_file option is
specified at compile time, you can include one of the following initialization options:
• +vcs+initreg+random+nomem
• +vcs+initreg+random+noreg

Verification Continuum™ VCS User Guide 158

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The +vcs+initreg+random+nomem option disables initialization of memories or multi-

dimensional arrays (MDAs). This option allows initialization of variables that do not have a
dimension.
Conversely, the +vcs+initreg+random+noreg option disables initialization of variables
that do not have a dimension. This option allows initialization of memories or MDAs.

Reporting the Initialized Values of Variables, Registers, and

Memories
The VCS_PRINT_INITREG_INITIALIZATION environment variable enables printing
of all initialized variables, registers, memories, and their initialized values to the
vcs_initreg_random_value.txt file at runtime. The following is the use model:
% setenv VCS_PRINT_INITREG_INITIALIZATION 1
VCS_PRINT_INITREG_INITIALIZATION
enabling writing initialized values
environment
to a filevariable

The following is the format of vcs_initreg_random_value.txt file:

[Hierarchical_path] = [Decimal_Value] // [Number_Of_Bits] [REG|MEM]
Where, the [Decimal_Value] of 0, 1, 2 represents values of 0, 1, and z respectively.
Packed arrays can be represented with decimal values greater than 2.
The following is the sample report of the vcs_initreg_random_value.txt file:
tb.d1.v1[0] = 2 // 1 MEM
tb.d1.v1[1] = 2 // 1 MEM
tb.d1.v1[2] = 2 // 1 MEM
tb.d1.v1[3] = 2 // 1 MEM
tb.d1.c = 2 // 1 REG
tb.t1.a = 0 // 1 REG
tb.t1.b = 1 // 1 REG
tb.d1.p1 = 65535 // 16 REG

Where 4-bit unpacked array v1 is initialized to z (each element of an unpacked array

is reported as MEM), register c is initialized to z, register a is initialized to 0, register b is
initialized to 1, and 16-bit packed array p1 is initialized to decimal value 65535.

Overriding Generics and Parameters

This section discusses the following topics:
• Overriding Verilog Parameters
• Overriding VHDL Generics
• Usage Model

Verification Continuum™ VCS User Guide 159

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Overriding Verilog Parameters

There are two compile-time options for changing parameter values from the vcs command
line:
• -pvalue
-pvalue[-]
-pvalue

• -parameters
-parameters[-]
-parameters

You specify a parameter with the -pvalue option. It has the following syntax:
vcs -pvalue+ =value

For example:
vcs source.v -pvalue+test.d1.param1=33

You specify a file with the -parameters option. The file contains command lines for
changing values. A line in the file has the following syntax:
assign path_to_the_parameter

Here:
assign

Keyword that starts a line in the file.

value

New value of the parameter.

path_to_the_parameter

Hierarchical path to the parameter. This entry is similar to a Verilog hierarchical name
except that you use forward slash characters (/), instead of periods, as the delimiters.
The following is an example of the contents of this file:
assign 33 test/d1/param1
assign 27 test/d1/param2

Note:
The -parameters and -pvalue options do not work with a localparam or a
specparam.

Verification Continuum™ VCS User Guide 160

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Overriding VHDL Generics

There are two compile-time options for changing generic values from the vcs command
line:
• -gvalue
• -generics
The -gvalue option overrides the generic value defined in the source code with the value
specified in the command line.
The -generics option overrides the default values for the design generics by using values
from the file cmdfile. The cmdfile file is an include file that contains assign commands
targeting design generics.
VCS allows you to override both generic or parameter values in the design using the
compile-time option, -gfile [Link].
For more information on generic values, refer to the “Options for Overriding Generics and
Parameters” section of the Appendix C, "Compilation/Elaboration Options" chapter.
Here, [Link] is an include file containing assign commands to override generic or
parameter values. The syntax of the assign command is as follows:
assign value generics/parameters

Note:
You can also override generics at runtime. See, Using Verdi.
Using this option, you can override any generic or parameter of the following datatypes:
• integer
• real
• string
You can also specify more than one generic or parameter in the same line as shown
below:
assign 1 g1 g2

For example:
The usage model to override the default value of a generic "WIDTH" in your top-level
VHDL file to "16", is as follows:
% vhdlan [Link] [Link]
% vcs top -gfile [Link]
% simv

Verification Continuum™ VCS User Guide 161

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The include [Link] file contains the following commands:

% cat [Link]
assign 16 WIDTH

Similarly, you can use the same assign commands to override the parameters in the
Verilog modules as shown in the following example:
module top();
parameter filename="[Link]"
initial
$display("The filename is %s", filename);
endmodule

You can override the default value of the filename parameter in the above example, to
[Link], as shown below:
% vlogan top.v
% vcs top -gfile [Link]
% simv

The include [Link] file contains the following commands:

% cat [Link]
assign "[Link]" filename

Usage Model
Analysis
% vlogan [ ] file4.v file5.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]

Note:
Specify the VHDL bottommost entity first, then move up in order.
Elaboration
% vcs [vcs_options] top_cfg/entity/module -gfile [Link]

Simulation
% simv [simv_options]

Note:
Verilog module can have parameters where the type is not specified or an
initial value is not defined. When such a module is instantiated in VHDL, these
parameters are considered of type integer.

Verification Continuum™ VCS User Guide 162

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

When VHDL does not override a parameter, either by declaring the generic as
“open,” or by not mentioning generic, then the default values on the Verilog side
are 0 (for integer), 0.0 (for real), and an empty string.
Any other parameter or generic assignment than an integer value, leads to an
elaboration error.
For example,
module dut #(parameter int_par1 = 42,
parameter int_par2,
parameter string str_par1,
parameter str_par2) (input clk);
...
endmodule

entity top; end entity top;

architecture top_arch of top is

component dut is
generic ( int_par1 : natural;
int_par2 : natural;
str_par1 : string;
str_par2 : string)
port (clk : in std_logic);
end component dut
signal clk : std_logic;
begin
V : dut generic map (
int_par1 => 1,
int_par2 => 2, – this is allowed
str_par1 => “another string”, – this is allowed
str_par2 => “hi there”) – this leads to an
elaboration error: integer expected
port map ( clk => clk);
end architecture top_arch

Note:
For more details, refer to the Instantiating Verilog or VHDL in Your Design
chapter of VCS Simulation Coding and Modeling Style Guide.

Checking for x and z Values In Conditional Expressions

The -xzcheck compile-time option tells VCS to display a warning message when it
-xzcheck

evaluates a conditional expression and finds it to have an x or Z value.

Verification Continuum™ VCS User Guide 163

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

A conditional expression is of the following types or statements:

• A conditional or if statement:
if(conditional_exp)
$display("conditional_exp is true");

• A case statement:
case(conditional_exp)
1’b1: sig2=1;
1’b0: sig3=1;
1’bx: sig4=1;
1’bz: sig5=1;
endcase

• A statement using the conditional operator:

reg1 = conditional_exp ? 1’b1 : 1’b0;

The following is an example of the warning message that VCS displays when it evaluates
the conditional expression and finds it to have an x or z value:
warning ’ ’ within scope in :
to x/z at time simulation_time

VCS displays this warning every time it evaluates the conditional expression to have an
x or z value, not just when the signal or signals in the expression transition to an x or z
value.
VCS does not display a warning message when a sub-expression has the value x or z, but
the conditional expression evaluates to 1 or 0 value. For example:
r1 = 1’bz;
r2 = 1’b1;
if ( (r1 && r2 ) || 1’b1)
r3 = 1;

In this example, the conditional expression always evaluates to a value of 1. Therefore,

VCS does not display a warning message.
This section discusses the following topics:
• Enabling the Checking
• Filtering Out False Negatives

Enabling the Checking

The -xzcheck compile-time option globally checks all the conditional expressions
in the design and displays a warning message every time it evaluates a conditional
expression to have an x or z value. You can suppress or enable these warning messages

Verification Continuum™ VCS User Guide 164

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

on selected modules using $xzcheckoff and $xzcheckon system tasks. For more details
on $xzcheckoff and $xzcheckon system tasks, see “Checking for X and Z Values in
Conditional Expressions”.
The -xzcheck compile-time option has an optional argument to suppress the warning for
glitches evaluating to x or z value. Synopsys calls these glitches as false negatives. See
Filtering Out False Negatives.

Filtering Out False Negatives

By default, if a signal in a conditional expression transitions to an x or z value and then to
0 or 1 in the same simulation time step, VCS displays the warning.
Example 1
In this example, VCS displays the warning message when reg r1 transitions from 0 to x to
1 during simulation time 1.

Example 5 False Negative Example

module test;
reg r1;

initial
begin
r1=1'b0;
#1 r1=1'bx;

#0 r1=1'b1;
end

always @ (r1)
begin
if (r1)
$display("\n r1 true at %0t\n",$time);
else
$display("\n r1 false at %0t\n",$time);
end
endmodule

Example 2
In this example, VCS displays the warning message when reg r1 transitions from 1 to x
during simulation time 1.

Example 6 False Negative Example

module test;
reg r1;

initial
begin
r1=1'b0;

Verification Continuum™ VCS User Guide 165

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

#1 r1<=1'b1;
r1=1'bx;
end
always @ (r1)
begin
if (r1)
$display("\n r1 true at %0t\n",$time);
else
$display("\n r1 false at %0t\n",$time);
end

endmodule

If you consider these warning messages to be false negatives, use the nofalseneg
argument to the -xzcheck option to suppress the messages.
For example:
% vcs -xzcheck nofalseneg example.v

If you compile and simulate Example1 or Example2 with the -xzcheck elaboration/
compilation option, but without the nofalseneg argument, VCS displays the following
warning about signal r1 transitioning to x or z value:
r1 false at 0
Warning: 'r1' within scope test in .v: 13 goes to x/z at time 1

r1 false at 1

r1 true at 1

If you compile and simulate the examples shown earlier in this chapter, Example 1
or Example 2, with the -xzcheck elaboration/compilation option and the nofalseneg
argument, VCS does not display the warning message.

Cross Module References (XMRs)

Verilog enables you to access any internal signal from any other hierarchical block without
having to route it through a user interface.
VHDL does not have the language support to allow you to access internal signals from
any other hierarchical block. Therefore, it is not possible to either assign or test the value
of a signal deep in the design hierarchy without defining it in a global package, and then
referencing it in a hierarchical block where it is used.
The hdl_xmr procedure (in VHDL code) and the $hdl_xmr system task enables you to
access internal signals in a mixed HDL design and Verilog only. Therefore, you can handle
the signals in the VHDL database. In a mixed HDL or Verilog only environment, you can
access VHDL or Verilog signals across language boundaries using this feature.

Verification Continuum™ VCS User Guide 166

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The hdl_xmr procedure and the $hdl_xmr system task work only when the source and
destination objects match in both type and size.
This section discusses the following topics:
• The hdl_xmr Procedure and the $hdl_xmr System Task
• Data Types Supported
• Using the hdl_xmr Procedure
• Using the $hdl_xmr Task
• Use Model
• Examples
• $hdl_xmr Support for VHDL Variables
• Data Type Support and Usage Examples
• Support for Native XMR force and release

The hdl_xmr Procedure and the $hdl_xmr System Task

The hdl_xmr procedure and the $hdl_xmr system task creates a permanent bond
between the two objects, called source and destination. Each time an event occurs on the
source object, the destination object is assigned a new value of the source object. Note
that if the destination object has other sources, like an assignment statement, the last
event value (from hdl_xmr/$hdl_xmr or the assignment statement) is assigned to the
destination object, thus, overwriting the previous value.
When the hdl_xmr procedure or the $hdl_xmr system task is executed, source and
destination objects are bound together until the end of the simulation. Therefore, it is
important that hdl_xmr/$hdl_xmr calls are specified in the code only once.
Note:
• All these following delimiters are supported. "/", ".", ":" except for a pure VHDL design
where you cannot use “.” as a delimiter.
• For mixed HDL designs, you must use the -debug_access option for the $hdl_xmr
system task to work.

Verification Continuum™ VCS User Guide 167

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Data Types Supported

hdl_xmr and $hdl_xmr supports the following data types:
hdl_xmr

• Scalars, vectors, bit-selects, and part-selects (slices) are supported for both source and
destination objects. Global VHDL signals are also supported.
• The following types of VHDL signals are supported with their corresponding Verilog
types:
◦ integer
◦ bit and bit vector
◦ string
◦ std_logic/std_ulogic/std_logic_vector/std_ulogic_vector
◦ Enumerated datatypes
In case of an integer type, a Verilog type of size 32, for example, reg[31:0], is allowed as
a matching type. Similarly, for a packed struct std_logic_vector/std_ulogic_vector is
allowed as a matching type.
• The following SystemVerilog datatypes are supported across VCS boundary:
shortint, int, longint, byte, bit, logic, and reg.

The following table lists the supported SystemVerilog datatypes with their matching VHDL
datatypes.
Table 7 SystemVerilog Datatypes With Their Matching VHDL Datatypes

SystemVerilog Integer Integer Bit vector std_logic std_ulogic

Data Types Subtype vector vector

Shortint No No Yes Yes Yes

Int Yes Yes Yes Yes Yes

Longint No No Yes Yes Yes

Bit array Yes Yes Yes Yes Yes

Logic array Yes Yes Yes Yes Yes

Integer Yes Yes Yes Yes Yes

Verification Continuum™ VCS User Guide 168

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Using the hdl_xmr Procedure

The syntax of the hdl_xmr procedure is as follows
hdl_xmr(" ", " ", [ ]);

source_object

source_object can be a VHDL signal or Verilog register or net. An absolute path or a

relative path to the object can be specified.
Use an absolute path instead of a relative path, if the source node resides in VHDL part of
the code or if the hierarchical path has a VHDL layer.
destination_object

destination_object could be a VHDL signal or a Verilog register. An absolute path or a

relative path to the object can be specified.
Note:
Use an absolute path instead of a relative path, if the hierarchical path contains
a VHDL layer. Verilog net type as a destination object is not supported.
verbosity

Third optional argument to the hdl_xmr call is a verbosity index. If the argument is not
specified then the default value is '0', otherwise possible integer values are '0' or '1'. Value
'0' indicates no verbosity, and value ‘1’ enables verbosity. If you specify ‘1’, then every time
a value of the source object is copied onto the destination object, a message is displayed.
To use the hdl_xmr procedure, you should include the XMR package in your VHDL source
code as shown below:
Library Synopsys;
Use Synopsys.hdl_xmr_pkg.all;

You can call the hdl_xmr procedure concurrently or within a process having no sensitivity
list and a wait, at the end of the process block, as shown in the following example:
hdl_xmr(":vh:vl:cout0",":vh:coutin_xmr");
hdl_xmr("/vh/vl/cout0","/vh/in[3]", 1);

When there is an escaped/extended-identifier instance present in the source and if it is

required to be specified, the hierarchical path must be enclosed within “\” when a call is
made.
For example, when a signal is inside an escaped instance and it is referred to as "/VH/
VL/\U_VL/U_ESC /signal1", the same signal inside the hdl_xmr procedure must be
referred to as "/VH/VL/\U_VL/U_ESC\/signal1", essentially the hierarchical instance

Verification Continuum™ VCS User Guide 169

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

path is enclosed with “\”. You can use the hdl_xmr procedure as shown in the following
example:
hdl_xmr("/VH/VL/\U_VL/U_ESC\/signal1", "/VH/signal2", 1);

Similarly, if there is an escaped instance, \U_NETLIST/NETLIST_TOP with the

NETLSIT_TOP/U_AND_2.Z signal, the same signal inside the hdl_xmr procedure must be
referred to as:
hdl_xmr("/TBTOP/U_TOP/U_NETLIST/\U_NETLIST/NETLIST_TOP\/NETLIST_TOP/U_AND
_2.Z","/TBTOP/CLK" , 1);

Using hdl_xmr With Generate Blocks

You can use the following syntax for names within generate blocks:
• For generate block in Verilog, the name for instances within generate block that has
escaped name is “escaped_generate_name.instance_name”
• For generate block in VHDL, the name for instances within generate block that has
extended name is “extended_generate_name.instance_name”

Using the $hdl_xmr Task

The syntax of the $hdl_xmr procedure is as follows
$hdl_xmr(" " , " ",
[ ]);

source_object

source_object could be a VHDL signal or Verilog register or net. An absolute path or a

relative path to the object can be specified.
Use an absolute path instead of a relative path, if the source node resides in VHDL part of
the code or if the hierarchical path has a VHDL layer.
destination_object

destination_object could be a VHDL signal or a Verilog register. An absolute path or a

relative path to the object can be specified.
Note:
Use an absolute path instead of a relative path, if the hierarchical path contains
a VHDL layer. Verilog net type as a destination object is not supported.
verbosity

Third optional argument to the hdl_xmr call is a verbosity index. If the argument is not
specified then the default value is '0', otherwise possible integer values are '0' or '1'. Value
'0' indicates no verbosity. When verbosity is required, that is, '1' is the third argument, then

Verification Continuum™ VCS User Guide 170

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

every time when the value of the source object is copied on to the destination object, a
message is displayed.
You can use the $hdl_xmr system task as shown in the following example:
initial begin
$hdl_xmr("[Link]", "[Link]");
$hdl_xmr("/vl/vh/reset_n", "/vl/vrst_n[0]", 0);
$hdl_xmr("vl:vh:state[3:0]", "vl:state[4:7]", 1);
end

When there is an escaped/extended-identifier instance present in the source and if it is

required to be specified, the hierarchical path should be enclosed within “\\” when a call is
made.
For example, when a signal is inside an escaped instance and it is referred to as "VL.
\U_VL/U_ESC .VH.Signal1", the same signal inside the hdl_xmr task must be referred
to as "VL.\\U_VL/U_ESC\\.VH.Signal1", essentially the hierarchical instance path
is enclosed with “\\”. You can use the $hdl_xmr system task as shown in the following
example:
$hdl_xmr("VL.\\U_VL/U_ESC\\.VH.Signal1", "VL.signal2",1);

Similarly, if there is an escaped instance \U_NETLIST/NETLIST_TOP with the

NETLSIT_TOP.U_AND_2.Z signal, the same signal inside the $hdl_xmr task is referred to
as:
$hdl_xmr("top.U_NETLIST.\\U_NETLIST/NETLIST_TOP\
\.NETLIST_TOP.U_AND_2.Z","[Link]", 1);

Using $hdl_xmr With Generate Blocks

You can use the following syntax for names within generate blocks:
• For generate block in Verilog, the name for instances within generate block that has
escaped name is “\escaped_generate_name.instance_name\\”
• For generate block in VHDL, the name for instances within generate block that has
extended name is “\extended_generate_name\.instance_name”

Use Model
Analysis
% vlogan [ ] file4.v file5.v file6.v
% vhdlan [ ] [Link] [Link] [Link]

Note:
Specify the VHDL bottom most entity first, then move up in order.

Verification Continuum™ VCS User Guide 171

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Elaboration
% vcs [ ] -debug_access+r+cbk top_cfg/entity/module

Simulation
% simv [simv_options]

Examples
• hdl_xmr with escaped/extended identifiers
Consider the following design code — test.v and [Link] that are cross referenced using
escaped/extended identifiers.
test.v
cat test.v
`timescale 1ns/1ns
module top;
reg clk;
middle \m_inst/m_inst ();
initial
begin
$hdl_xmr ("[Link]",
"top.\\m_inst/m_inst\\.leaf_inst.\\I1/I1\\.vhtop", 1);
$hdl_xmr ("[Link]",
"/top/\\m_inst/m_inst\\/leaf_inst/\I1/I1\/vhtop", 1);
clk = 0;
#10 clk = 1 ;
#10 $finish;
end

endmodule

module middle ;
leaf leaf_inst();
endmodule

[Link]
library ieee;
use ieee.std_logic_1164.all ;

entity vhleaf is

end vhleaf ;

architecture a of vhleaf is

signal vhtop : std_logic ;

begin

Verification Continuum™ VCS User Guide 172

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

end a ;

library ieee;
use ieee.std_logic_1164.all ;
library synopsys;
use synopsys.hdl_xmr_pkg.all ;

entity leaf is

end leaf ;

architecture a of leaf is

component vhleaf
end component ;

begin

hdl_xmr ("[Link]",
"top.\m_inst/m_inst\.leaf_inst.\I1/I1\.vhtop", 1);
hdl_xmr ("[Link]",
"/top/\m_inst/m_inst\/leaf_inst/\I1/I1\/vhtop", 1);
\I1/I1\ : vhleaf
end a ;

If the call ids are made from Verilog, both escaped and extended identifier must be
enclosed within “\”. Whereas, if the call is made from VHDL, both escaped and extended
identifier must be enclosed within “\\”. The hdl_xmr procedures for this example are
defined as shown in the following table:

Call Format hdl_xmr Procedures and Tasks

From

Escape identifier in Verilog - Verilog dot $hdl_xmr ("[Link]",

\m_inst/m_inst;Extended "top.\\m_inst/m_inst\\.leaf_inst.\
identifier in VHDL- \I1/I1\\.vhtop", 1);
\I1/I1\ : vhleaf;
slash $hdl_xmr ("[Link]",
"/top/\\m_inst/m_inst\\/leaf_inst/\
\I1/I1\\/vhtop", 1);

Escape identifier in Verilog - VHDL dot hdl_xmr ("[Link]",

\m_inst/m_inst;Extended "top.\m_inst/m_inst\.leaf_inst.\I1/I1\
identifier in VHDL - .vhtop", 1);
\I1/I1\ : vhleaf;
slash hdl_xmr ("[Link]",
"/top/\m_inst/m_inst\/leaf_inst/\I1/I
1\/vhtop", 1);

Verification Continuum™ VCS User Guide 173

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• hdl_xmr with generate blocks

Consider the following design code— test.v and [Link] that are cross referenced using
generate blocks.
test.v
`timescale 1ns/1ns
module top;
reg clk;
middle m_inst ();
initial
begin
$hdl_xmr ("[Link]",
"top.m_inst.\\gen[0].leaf_inst\\.\\GEN[0]\\.[Link]", 1);
$hdl_xmr ("[Link]",
"/top/m_inst/ \\gen[0].leaf_inst\\/ \\GEN[0]\\/I1/vhtop", 1);

clk = 0;
#10 clk = 1 ;
#10 $finish;
end
endmodule

module middle ;
generate
begin : \gen[0]
leaf leaf_inst();
end
endgenerate
endmodule

[Link]
library ieee;
use ieee.std_logic_1164.all ;

entity vhleaf is

end vhleaf;

architecture a of vhleaf is

signal vhtop : std_logic ;

begin

end a ;

library ieee;
use ieee.std_logic_1164.all ;
library synopsys;
use synopsys.hdl_xmr_pkg.all ;

Verification Continuum™ VCS User Guide 174

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

entity leaf is

end leaf ;

architecture a of leaf is

component vhleaf

end component ;

begin
hdl_xmr ("[Link]",
"top.m_inst.\gen[0].leaf_inst\.\GEN[0]\.[Link]", 1);
hdl_xmr ("[Link]",
"/top/m_inst/\gen[0].leaf_inst\/\GEN[0]\/I1/vhtop", 1);

I1 : vhleaf ;
end generate \GEN[0]\ ;
end a ;

The hdl_xmr tasks for this example are defined as shown in the following table:

Call From Format hdl_xmr tasks

Generate instance in Verilog - Verilog dot $hdl_xmr ("[Link]",

generate begin : \gen[0] "top.m_inst.\\gen[0].leaf_inst\\.\
leaf leaf_inst(); end \GEN[0]\\.[Link]", 1);
endgenerateGenerate
instance in VHDL- \GEN[0]\ : slash $hdl_xmr ("[Link]",
if ( true ) generate I1 : "/top/m_inst/\\gen[0].leaf_inst\\/\
vhleaf ; end generate \GEN[0]\\/I1/vhtop", 1);
\GEN[0]\ ;

The hdl_xmr procedures for this example are shown in the following table:

Call From Format hdl_xmr Procedures

Generate instance in Verilog - VHDL dot hdl_xmr ("[Link]",

generate begin : \gen[0] "top.m_inst.\gen[0].leaf_inst\.
leaf leaf_inst() ; end \GEN[0]\.[Link]", 1);
endgenerateGenerate
instance in VHDL - slash hdl_xmr ("[Link]",
\GEN[0]\ : if ( true ) "/top/m_inst/\gen[0].leaf_inst\/\GEN
generate I1 : vhleaf ; [0]\/I1/vhtop", 1);
end generate \GEN[0]\ ;

Verification Continuum™ VCS User Guide 175

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

$hdl_xmr Support for VHDL Variables

VCS supports the usage of VHDL objects of type, variable, in the $hdl_xmr system
task. This support enables you to use VHDL variables, as source or destination, in the
$hdl_xmr (not hdl_xmr in VHDL side) call.

Use Model
In Verilog source, you should call $hdl_xmr as:
$hdl_xmr (<”source variable”>, <”destination signal”>, <verbosity_value>)

$hdl_xmr (<”source signal”>, <”destination variable”>, <verbosity_value>)

You can specify the source variable and the destination variable in a relative or an
absolute path. The last integer value, verbosity_value, is optional. It is only used for
verbosity. The variable object is the VHDL object.
To enable the support for $hdl_xmr with VHDL variables, you must use one of the
following compile-time options:
• vcs <top> -debug_access* -vdbg_watch
• vcs <top> -debug_access+all
Note:
◦ In VHDL variables, you must pass the -vdbg_watch option along with the
-debug_access* option. If you are using the -debug_access+all option, then
there is no need to pass the -vdbg_watch option.
◦ For mixed HDL designs, you must use the -debug_access* option for the
$hdl_xmr system task to work.

Data Type Support and Usage Examples

The following table shows data type support and usage examples:
Table 8 Data Type Support and Usage Examples

Verilog Data Types VHDL Data Types for Variable

reg bit/std_logic/std_ulogicVHDL record elements.

Datatypes for record elements can be bit/
std_logic/std_ulogic.

Verification Continuum™ VCS User Guide 176

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Table 8 Data Type Support and Usage Examples (Continued)

Verilog Data Types VHDL Data Types for Variable

module tb;reg r1,r2; reg [0:3] entity leaf is end leaf; architecture
r3,r4;leaf inst1();initial begin beh of leaf istype pkt is recordr1 :
$hdl_xmr("inst1.r1","r1",1); bit; r2 : std_logic;end record; shared
$hdl_xmr("r2”,inst1.r2",1); variable rec : pkt ;shared variable
$hdl_xmr("inst1.r1","r3[1:1]",1); r1 : std_logic ;shared variable r2 :
$hdl_xmr("r4[1:1]”,inst1.r2",1); std_ulogic ; begin end;
$hdl_xmr("[Link].r1","r1",1);
$hdl_xmr("r2”,[Link].r2",1);
$hdl_xmr("[Link].r1","r3[1:1]",1);
$hdl_xmr("r4[1:1]”,[Link].r2",1); end
endmodule

reg vector bit_vector/std_logic_vector/signed/unsigned/in

teger/naturalVHDL record elements.
Datatypes for record elements can be
bit_vector/ std_logic_vector/signed/ unsigned/
integer/natural

module tb;reg [31:0] r1,r2,r3,r4; entity leaf is end leaf; architecture

leaf inst1();initial begin beh of leaf istype pkt is recordr1 :
$hdl_xmr("inst1.r1","r1",1); natural; r2 : std_logic_vector(31
$hdl_xmr("r2”,inst1.r2",1); downto 0);end record; shared variable
$hdl_xmr("inst1.r1[15:0]","r3[31:16]",1); rec : pkt;shared variable r1,r2 :
$hdl_xmr("r4[15:0]”,inst1.r2[15:0]",1); std_logic_vector(31 downto 0): begin
$hdl_xmr("[Link].r1","r1",1); end;
$hdl_xmr("r2”,[Link].r2",1);
$hdl_xmr("r4[3:0]”,[Link].r2[3:0]",1); end
endmodule

reg mda vhdl mda. Base data type

for array elements can be
bit/std_logic/std_ulogic/bit_vector/std_logic_ve
ctor/integer/natural

module tb;reg [31:0] r1,r2,r3 [0:7] entity leaf is end leaf; architecture
reg [31:0] r4; leaf inst1();initial beh of leaf istype ram is array(0
begin $hdl_xmr("inst1.r1","r1",1); to 7) of std_logic_vector(31 downto
$hdl_xmr("r2”,inst1.r2",1); 0);type ram1 is array(0 to 7) of
$hdl_xmr("inst1.r3","r3",1); bit_vector(31 downto 0);type ram2
$hdl_xmr("r4”,inst1.r2[1]",1); is array(0 to 7) of natural;shared
$hdl_xmr("inst1.r1[2]","r4",1); variable r1 : ram;shared variable r2 :
$hdl_xmr("r2[2]”,inst1.r2[2]",1); end ram1;shared variable r3 : ram2; begin
endmodule end;

realreal real mda Note: Verilog real vectors are not vhdl realreal field of vhdl record real mda
supported.

Verification Continuum™ VCS User Guide 177

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Table 8 Data Type Support and Usage Examples (Continued)

Verilog Data Types VHDL Data Types for Variable

module tb;real r1 [0:7];real entity leaf is end leaf; architecture

r2; leaf inst1();initial begin beh of leaf istype ram is array(0
$hdl_xmr("inst1.r1","r1",1); to 7) of real;shared variable r1 :
$hdl_xmr("r2”,inst1.r2",1); ram;shared variable r2 : real;begin
$hdl_xmr("r2”,inst1.r1[1]",1); end;
$hdl_xmr("inst1.r1[1]","r2",1); end endmodule

packed struct array of packed struct Data types for vhdl record array of vhdl recordsData
elements of packed struct : reg/logicreg/logic vector real types for elements of vhdl
record:bit/std_logic/std_ulogicbit_vector/std_[u
]logic_vector/signed/unsigned/natural/integerr
eal

module tb; typedef struct packed {reg entity leaf is end leaf; architecture
[31:0] t ; reg [15:0] b;} st;st r1,r2;st beh of leaf is type rec is recorda1 :
r3 [0:1];leaf inst1(); initial begin integer ;a2 : bit_vector(15 downto
$hdl_xmr("r2","inst1.r2",1);$hdl_xmr("inst1.r1 0);end record; shared variable r1,r2 :
","r1",1);$hdl_xmr("inst1.r3","r3",1);$hdl_xmr rec; type arr is array(0 to 1) of
("inst1.r3[1]","r3[1]",1);$hdl_xmr("inst1.r3[0 rec;shared variable r3 : arr;begin end
]","r1",1);$hdl_xmr("r2","inst1.r3[1]");end beh;
endmodule

Support for Native XMR force and release

VCS supports force and release on VHDL objects with native Verilog XMRs without
debug capabilities by using the -mx_force option at runtime.
Use Model
Use the following option at runtime:
% simv -mx_force

Example
The following example demonstrates the use of force and release. The new supported
values are highlighted in the example.

Example 7 Usage of force and release

test.v file is as follows:
`timescale 1ns/1ns
module top;

reg clk, rst;

wire [3:0] count;

dut inst (,,count);

Verification Continuum™ VCS User Guide 178

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

always
begin
force [Link] = 1'b0;
#5;
force [Link] = 1'b1;
#5;
end
initial
begin
force [Link] = 1'b1;
#3;
release [Link];
#1;
force [Link] = 1'b0;
#155;
$finish;
end
initial $monitor("time = %0t rst = %b count
=%0d",$time,[Link],count);
endmodule

[Link] file is as follows:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity dut is
port(
clk : in std_logic;
rst : in std_logic;
count : out std_logic_vector(3 downto 0)
);
end entity dut;

architecture arch of dut is

begin
process(clk,rst)
variable temp_count : std_logic_vector( 3 downto 0);
begin
if(rst='1') then
temp_count := (others => '0');
elsif(clk'event and clk='1') then
temp_count := temp_count + 1;
end if;
count <= temp_count;
end process;
end arch;

Run the example using the following commands:

Verification Continuum™ VCS User Guide 179

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• % vhdlan -full64 [Link]

• % vlogan -full64 test.v
• % vcs -full64 top
• % simv -mx_force
The output is as follows:
time = 0 rst = 1 count =0
time = 3 rst = z count =0
time = 4 rst = 0 count =0
time = 5 rst = 0 count =1
time = 15 rst = 0 count =2
time = 25 rst = 0 count =3
time = 35 rst = 0 count =4
time = 45 rst = 0 count =5
time = 55 rst = 0 count =6
time = 65 rst = 0 count =7
time = 75 rst = 0 count =8
time = 85 rst = 0 count =9
time = 95 rst = 0 count =10
time = 105 rst = 0 count =11
time = 115 rst = 0 count =12
time = 125 rst = 0 count =13
time = 135 rst = 0 count =14
time = 145 rst = 0 count =15
time = 155 rst = 0 count =0

Limitations
• This feature is only supported on -full64 mode.
The following forms of XMRs are not supported:
• XMRs to VHDL array elements, bits of a bit-vector and bit-slice of a bit-vector. For
example,
VHDL:
type vecarr is array (0 to 2) of std_logic_vector(3 downto 0);
signal vecsigarr1 : vecarr := ( ("0000"), ("1111"), ("ZX01") );

Verilog:
force = 4’b0011;

VHDL::
signal sig1 : std_logic_vector(3 downto 0) := “0011”;

Verification Continuum™ VCS User Guide 180

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Verilog::
force = 1’b0;
force = 2’bx1;

• XMRs to the VHDL user-defined types. For example,

VHDL:
library ieee;
use ieee.fixed_pkg.all;
signal a : ufixed(3 downto -3);

Verilog::
force = 3.14;

• XMRs to the VHDL aliased signals. For example,

VHDL:
type real_vector is array (2 downto 0) of real;
type slogic_vector is array(1 downto 0) of std_logic;
signal r1 : real_vector;
signal real1 : real;
signal temp : slogic_vector;
alias my_real : real is r1(1);
alias my_real1 : real is real1;
alias r2 : std_logic is temp(1);

Verilog:
force = “3.14”;
force = “42.42”;
force = 1’bz;

VHDL XMRs cannot be used in the following scenarios:

• Assign/continuous assign. For example,
Verilog:
reg [3:0] local_sig1;
= 4’b0011;
assign = local_sig1;

• XMRs used for reading and writing. For example,

Verilog:
force = 4’b01zx;
$display($time, “ sig1: %b”, );

Verification Continuum™ VCS User Guide 181

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• XMRs to VHDL unconnected ports used for both reading and writing. For example,
VHDL:
entity dut is port (clk : in std_logic; count: out std_logic_vector(3
downto 0)); end entity dut;

Verilog:

wire [3:0] count;

dut VHDL(, count); // clk port is open
Initial begin
force = 1’b1;
#3 release ;
end
initial $monitor($time, “ clk: %b”, );

Verilog Configurations and Libmaps

Library mapping files are an alternative to the de facto standard way of specifying Verilog
library directories and files with the -v, -y, and +libext+ext compile-time/analysis
+libext+ext

options and the ‘uselib compiler directive.

Configurations use the contents of library mapping files to specify what source code to use
to resolve instances in other parts of your source code.
Library mapping and configurations are described in SystemVerilog LRM IEEE Std.
1800-2012. It specifies that SystemVerilog interfaces can be assigned to logical libraries.
This section discusses the following topics:
• Library Mapping Files
• Configurations
• Hierarchical Configurations
• The -top Compile-Time Option
• Limitations of Configurations
• Use Model
• Example
• Using the -liblist Option
• Design Cells and Library Cells
• Library Search Order Rules

Verification Continuum™ VCS User Guide 182

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• Example Testcase Files

• Usage Examples for Library Search Order Rules for Verilog or SystemVerilog Designs

Library Mapping Files

A library mapping file enables you to specify logical libraries and assign source files to
these libraries. You can specify one or more logical libraries in the library mapping file. If
you specify more than one logical library, you are also specifying the search order VCS
uses to resolve instances in your design.
The following is an example of the contents of a library mapping file:
library lib1 /net/design1/design1_1/*.v;
library lib2 /net/design1/design1_2/*.v;

Note:
Path names can be absolute or relative to the current directory that contains the
library mapping file.
In this example of the library mapping file, there are two logical libraries. VCS searches the
source code assigned to lib1 first to resolve module instances (or user-defined primitive or
SystemVerilog interface instances) because that logical library is listed first in the library
mapping file.
When you use a library mapping file, source files that are not assigned to a logical library
in this file are assigned to the default logical library named work.
You specify the library mapping file with the -libmap during compilation/analysis.
-libmap

Resolving ‘include Compiler Directives

The source file in a logical library might include the ‘include compiler directive. If so,
you can include the -incdir option on the line in the library mapping file that declares the
logical library, for example:
library gatelib /net/design1/gatelib/*.v -incdir /net/
design1/spec1lib, /net/design1/spec2lib;

Note:
The -incdir option specified in the library mapping file overrides the +incdir
option specified in the VCS command line.

Configurations
Verilog 2001 configurations are sets of rules that specify what source code is used for
particular instances.
Verilog 2001 introduces the concept of configurations and it also introduces the concept of
cells. A cell is like a VHDL design unit. A module definition is a type of cell, as it is a user-

Verification Continuum™ VCS User Guide 183

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

defined primitive. Similarly, a configuration is also a cell. A SystemVerilog interface and

testbench program block are also types of cells.
Configurations provide the following functionalities:
• Specifies a library search order for resolving cell instances (as does a library mapping
file).
• Specifies overrides to the logical library search order for the specified instances.
• Specifies overrides to the logical library search order for all instances of the specified
cells.
You can define a configuration in a library mapping file or in any type of Verilog source file
outside the module definition as shown in the Example.
Configurations can be mapped to a logical library like any other type of cell.
Configuration Syntax
A configuration contains the following statements:
config ;
design [ .] ;
;
endconfig

where,
config

A keyword that begins a configuration.

config_identifier

A name you enter for the configuration.

design

A keyword that starts a design statement for specifying the top of the design.
[library_identifier.]cell_identifier;
Specifies the top-level module (or top-level modules) in the design and the logical library
for this module (modules).
config_rule_statement

Zero, one, or more of the following clauses: default, instance, or cell.

endconfig

A keyword that ends a configuration.

Verification Continuum™ VCS User Guide 184

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The default Clause

The default clause specifies logical libraries in which to search to resolve a default cell
instance. A default cell instance is an instance in the design that is not specified in a
subsequent instance or cell clause in the configuration.
You specify these libraries with the liblist keyword. The following is an example of a
default clause:
default liblist lib1 lib2;

This default clause specifies resolving default instances in the logical libraries names
lib1 and lib 2.
Note:
• Do not enter a comma (,) between logical libraries.
• The default logical library work, if not listed in the list of logical libraries, is appended to
the list of logical libraries and VCS searches the source files in work last.
The instance Clause
The instance clause specifies details about a specific instance. These details depend on
the use of the liblist or use keywords:
liblist

liblist

Specifies the logical libraries to search to resolve the instance.

use

Specifies that the instance is an instance of the specified cell in the specified logical library.
The following are examples of the instance clause:
instance top.dev1 liblist lib1 lib2;

This instance clause tells VCS to resolve instance top.dev1 with the cells assigned to
logical libraries lib1 and lib2;
instance top.dev1.gm1 use [Link];

This instance clause tells VCS that top.dev1.gm1 is an instance of the cell named
gizmult in the logical library lib2.

Verification Continuum™ VCS User Guide 185

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The cell Clause

The cell clause is similar to the instance clause except that it specifies details about all
cell claus instance clause

instances of a cell definition instead of specifying details about a particular instance. These
details depend on the use of the liblist or use keywords:
liblist

Specifies the logical libraries to search to resolve all instances of the cell.
use
use

The specified cell’s definition is in the specified library.

Hierarchical Configurations
A design can have more than one configuration. You can, for example, define a
configuration that specifies the source code you use in particular instances in a
subhierarchy, then you can define a configuration for a higher level of the design.
Suppose, for example, a subhierarchy of a design was an eight-bit adder and you have
RTL Verilog code describing the adder in a logical library named rtllib and you have
rtllib

gate-level code describing the adder in a logical library named gatelib. If, for example,
gatelib

you wanted the gate-level code used for the 0 (zero) bit of the adder and the RTL level
code used for the other seven bits, the configuration might appear as:
config cfg1;
design aLib.eight_adder;
default liblist rtllib;
instance adder.fulladd0 liblist gatelib;
endconfig

Now, if you instantiate this eight-bit adder eight times to make a 64-bit adder, you would
use configuration cfg1 for the first instance of the eight-bit adder, but not in any other
instance. A configuration that performs this function is as follows:
config cfg2;
design bLib.64_adder;
default liblist bLib;
instance top.64add0 use work.cfg1:config;
endconfig

The -top Compile-Time Option

VCS has the -top compile-time option for specifying the configuration that describes the
-top

top-level configuration or module of the design. For example:

vcs -top top_cfg ...

Verification Continuum™ VCS User Guide 186

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

If you have coded your design to have more than one top-level module, you can enter
more than one -top option, or you can append arguments to the option using the plus
delimiter. For example:
-top top_cfg+test+

Using the -top option tells VCS not to create extraneous top-level modules, that is, one
that you do not specify.

Limitations of Configurations
In the current implementation, Verilog configurations have the following limitations:
• You cannot specify source code for user-defined primitives in a configuration.
• The VPI functionality, described in Section 33.7 “Displaying library binding information”
in the SystemVerilog LRM IEEE Std. 1800-2012, is not implemented.

Use Model
Analysis
% vlogan -libmap libmap.v [vlogan_options] file1.v \
-libmap

file2.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]

Note:
Specify the VHDL bottom-most entity first, then move up in order.
Elaboration
% vcs [vcs_options] top_cfg/entity/config

Simulation
% simv [sim_options]

Example
A design can have more than one configuration. You can, for example, define a
configuration that specifies the source code you use in a particular instance of a
subhierarchy, then you can define a configuration for a higher level of the design.
For example, you have a design with VHDL-top design with the top entity as top
instantiating a Verilog-top module, sub_top. This Verilog module, sub_top, further

Verification Continuum™ VCS User Guide 187

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

instantiates a VHDL entity, sub1 and the VHDL entity, sub1, instantiates VHDL entities,
sub2and sub3 as shown below:

Figure 2 Verilog Module and VHDL Entity Instantiating VHDL Entries

top (Verilog)

sub_top (Verilog)

sub1 (VHDL)

sub2 (VHDL) sub3 (VHDL)

Suppose, you have the Verilog version of the entities, sub1 and sub2, and need to compile
and simulate the design with the Verilog version of sub1 and the VHDL version of sub2.
You can achieve this by defining configuration blocks in the Verilog source file outside the
module definition or in a separate file as shown below:
To bind the Verilog version of sub1, define a configuration block in top.v (outside the
module definition) as shown below:
//---top.v---
Module sub_top (...);
u_sub1 sub1 (...;
endmodule

config top_cfg;
design [Link];
instance top.u_sub1 use work.sub1_cfg:config
endconfig

or in a separate file as shown below:

config top_cfg;
design [Link];
instance top.u_sub1 use work.sub1_cfg:config
endconfig

Verification Continuum™ VCS User Guide 188

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

To bind the VHDL version of "sub2", define a configuration block in sub1.v (outside the
module definition) as shown below:
//---sub1.v---
Module sub1(...);
u_sub2 sub2 (...);
u_sub3 sub3 (...);
endmodule

config sub1_cfg;
design work.sub1;
instance sub1.u_sub2 use work.CFG_SUB2_BEH:config
endconfig

or in a separate file as shown below:

config sub1_cfg;
design work.sub1;
instance sub1.u_sub2 use work.CFG_SUB2_BEH:config
endconfig

The VHDL files, [Link] and [Link], are as shown below:

---[Link]---
Entity SUB2 is
Port ( ... );
End SUB2;

Architecture BEH of SUB2 is

Begin
Process
...
End process;
End BEH;

Configuration work.CFG_SUB2_BEH of SUB2 is

For BEH

End for;
End CFG_SUB2_BEH;
---[Link]---
Entity SUB3 is
Port ( ... );
End SUB3;
Architecture BEH of SUB3 is
Begin
Process
...
End process;
End BEH;

Configuration work.CFG_SUB3_BEH of SUB3 is

For BEH

Verification Continuum™ VCS User Guide 189

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

End for;
End CFG_SUB3_BEH;

The usage model for the above example is shown below:

Analysis
% vlogan top.v sub1.v -libmap libmap.v

% vhdlan [Link] [Link]

Note:
Specify the VHDL bottom-most entity first, then move up in order.
Elaboration
% vcs top

Simulation
% simv

Supported Features
Verilog configuration supports the following features:
• Verilog configurations in mixed HDL designs can configure Verilog instances and
boundary VHDL instances (that is, VHDL entity instantiations in a Verilog module).
However, the Verilog configuration cannot configure any sub-tree below the VHDL
instance in a Verilog module. To configure the sub-tree below the boundary VHDL
instances, a separate Verilog configuration must be instantiated in the VHDL design
unit.
• Supports direct or component instantiation. It also supports Verilog configuration
specification within VHDL.
• The instance resolution happens based on the resolution rules applicable for the
instantiating unit. For example, if the unit is in Verilog, then Verilog rules apply, or if the
unit is in VHDL, then VHDL rules apply.
• A VHDL design can have multiple Verilog instances with same module name, but with
different implementations. They should be analyzed into different logical libraries.
• A VHDL design can instantiate Verilog configuration like VHDL configuration. However,
the configuration and the Verilog module that it is configuring must be analyzed in the
same logical library as per parent VHDL rules.

Verification Continuum™ VCS User Guide 190

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• All configuration rules in Verilog configuration for binding instances are supported.
• While resolving the Verilog configuration, the library resolution happens as per the rules
mentioned in the IEEE Verilog LRM Std 1364-2005 Section [Link]. The library order
in the synopsys_sim.setup file for searching the Verilog or VHDL cell will be ignored.
Limitations of Configurations
In the current implementation, Verilog configurations have the following limitations:
• Verilog configuration cannot have VHDL DUT in the design statement.
• Verilog configurations cannot configure pure VHDL designs.
• The hierarchical path in the instance-based rule of Verilog configuration cannot go
through the VHDL instance. The hierarchical path should be pure Verilog with target
Verilog or VHDL instance.
• Direct instantiation of the Verilog configuration inside a VHDL generate statement is not
supported.
• SystemC with Verilog configurations is not supported for VHDL top-design topology.
• A separate compile flow with Verilog configurations used in mixed HDL designs is not
supported.
• Array of instances is not supported.

Using the -liblist Option

You can specify the -liblist option at elaboration time as follows:
-liblist logic_lib1+logic_lib2+
-liblist

It specifies the library search order for unresolved module or entity instantiated in Verilog.
When -liblist is specified, VCS starts searching libraries in the order specified with
-liblist. It neither honors the library order specified in the synopsys_sim.setup file, nor
look at the other libraries present in the synopsys_sim.setup file. If VCS does not find the
module definition in the libraries specified with the -liblist option, it generates an error
message.
In presence of Verilog configuration, VCS first tries to resolve the instances with the
configuration rules provided in the configuration file. If no instances are found, then VCS
looks for -liblist.
In the following example, -liblist L2 is used to find the instance, top.l1.l2:
Example
cat level1.v
******************

Verification Continuum™ VCS User Guide 191

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

module level1;
level2 l2();
initial $display("%l %m level1 (design)");

endmodule

cat file.v
******************
module level1;

level2 l2();

initial $display("%l %m level1 (library)");

endmodule

module level2;
initial $display("%l %m level2 (library)");
level3 l3();
endmodule

cat file1.v
*****************
module level3;

initial $display("%l %m level3 (library)");

endmodule

cat dummy.v
******************
module dummy;
level1 l();
endmodule

cat dummy1.v
******************
module dummy;
level3 l();
endmodule

cat top.v
******************
module top;
level1 l1();
endmodule

cat topcfg.v
******************
config topcfg;
design [Link];
instance top.l1 liblist L3;

Verification Continuum™ VCS User Guide 192

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

default liblist L2 L1;

endconfig

cat synopsys_sim.setup
WORK > DEFAULT
DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
L3 : ./lib3

cat run
******************
vlogan -sverilog level1.v -work L3
vlogan -sverilog dummy1.v -v file1.v -work L3
vlogan -sverilog dummy.v -v file.v -work L2
vlogan -sverilog file1.v -work L2
vlogan -sverilog top.v -work L1
vlogan -sverilog topcfg.v -work L1
vcs [Link] -diag libconfig -libmap_verbose -liblist L2

The following options enable you to search in different order:

• -liblist_work
-liblist_work

• -liblist_nocelldiff
-liblist_nocelldiff

The -liblist_work elaboration option enables VCS to first search in the parent work
library when attempting to resolve a design cell. This option is relevant only when the
Verilog configuration file is not used.
The -liblist_nocelldiff elaboration option disables the differentiation between design
cell and library cell. You can use this option at elaboration time to override the default
precedence order.

Design Cells and Library Cells

VCS designates Verilog modules as either design cells or library cells. When analyzing
files without -v/-y, Verilog modules are treated as design cells.
When analyzing files using -v/-y, Verilog modules resolved from -v/-y are treated as
library cells.
For example:
• Consider the following command-line:
% vlogan a.v

If a.v contains module a, then a is treated as the design cell.

Verification Continuum™ VCS User Guide 193

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• Consider the following command-line where a.v is passed with -v:

% vlogan top.v -v a.v

If top.v needs module a defined in a.v, then a is treated as the library cell.
By default, design cells take precedence over the library cells while searching for a module
definition. That is, if a library cell and a design cell have the same module name, then VCS
first searches for the design cell in the applicable libraries. If VCS cannot find the design
cell, it will then search for the library cell.
For example, consider the following command:
% vcs top.v b_prime.v –v b.v

If both b_prime.v and b.v define the b module needed by top.v, then VCS gives first
preference to the b module defined in b_prime.v while resolving the instance of the b
module defined inside the top module.
You can use the -liblist_nocelldiff option at elaboration time to override the default
-liblist_nocelldiff

precedence order. This option does not differentiate between design cells and library cells.
Note:
• If the design and library cell definitions of a module are dumped in the same library,
then VCS stores the last dumped design definition. For example, consider the following
commands:
% vlogan level1.v -work L1

% vlogan top.v -v level1.v -work L1

In this case, both design cell and library cell definitions of the level1 module are
analyzed in library L1 one after another.
Same is applicable for multiple design definitions also and VCS stores the last dumped
design definition.
• Design cells take precedence over library cells if the -liblist_nocelldiff is not
passed at elaboration time.

Library Search Order Rules

This section describes the library search order rules for module definitions when Verilog
configuration file is used with -v/-y and -liblist options. This section consists of the
following subsections:
• Library Search Order Rules for Mixed HDL Designs
• Library Search Order Rules for Verilog or SystemVerilog Designs

Verification Continuum™ VCS User Guide 194

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Library Search Order Rules for Mixed HDL Designs

VCS searches for the same language instances as that of the parent. If the same
language child instance is not available, then VCS searches for other language instance.
For example, if both Verilog and VHDL child instances are available in the same library, a
VHDL parent gives priority for a VHDL child instance over a Verilog child instance. Also,
the Verilog parent gives priority for the Verilog child instance over the VHDL child instance.
Further, VHDL parent search order is defined by the VHDL language and Verilog parent
search order for various conditions are explained in detail in the subsequent sections.
For any Verilog parent design cell, Verilog configuration is honored until the VHDL
instance is hit. Subsequent VHDL hierarchy can be configured using VHDL configurations
until Verilog instance is hit. The subsequent Verilog hierarchy beneath VHDL can be
configured using appropriate Verilog configurations. In absence of appropriate Verilog
configuration, regular search order is followed.
The subsequent sections discuss library search order rules for mixed HDL designs with
and without the Verilog configuration file. The library search order rules are listed in order
of priority, where the first rule is given preference before the second rule.
Library Search Order Rules for Mixed HDL Designs Without Configuration File
Library Search order rules for mixed HDL designs without a configuration file are as
follows:
1. VHDL-VHDL Scenario:
Binding rule of VHDL is applied. The -liblist option does not have any impact on
this scenario.
2. VHDL-Verilog Scenario:
Binding rule of VHDL is applied. The -liblist option does not have any impact on
this scenario.
3. Verilog-VHDL Scenario:
The VHDL instantiation gets resolved to a VHDL entity as per the library order specified
in -liblist.
The -liblist option is applicable for Verilog parent only.

Verification Continuum™ VCS User Guide 195

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Library Search Order Rules for Mixed HDL Designs With Configuration File
Library Search order rules for mixed HDL designs with a configuration file are as follows:
1. VHDL-VHDL Scenario:
Binding rule of VHDL is applied. The -liblist option does not have any impact on
this scenario.
2. VHDL-Verilog Scenario:
Binding rule of VHDL is applied. The -liblist option does not have any impact on
this scenario.
3. Verilog-VHDL Scenario:
For Verilog-top designs, Verilog cells are searched, if not found, then VHDL cells are
searched as per the rules. For any Verilog instantiated in the VHDL, the configuration
rules are not applicable.
Library Search Order Rules for Verilog or SystemVerilog Designs
The library search order rules are listed in order of priority, where the first rule is given
preference before the second rule. Each rule contains multiple sub-rules, which are listed
in the order of priority. VCS first determines the rule of highest priority, and then searches
the sub-rules in that rule, in the order of priority.
This section consists of the following subsections:
• Library Search Order Rules for Verilog or SystemVerilog Designs With a Configuration
File
• Library Search Order Rules for Verilog or SystemVerilog Designs Without a
Configuration File
Library Search Order Rules for Verilog or SystemVerilog Designs With a
Configuration File

RULE1:`uselib
1. Any library cell pre-resolved from a `uselib file during vlogan:
a. If a cell is resolved from `uselib, then no configuration rules are applied to an
instance in it if it was pre-resolved in the`uselib library. For usage example, see
Example-1
b. If the `uselib instance is configured to resolve a design cell, then configuration
rules are applied for any hierarchy under it. For usage example, see Example-2
c. If a cell is resolved from `uselib, and an instance in it was not pre-resolved from
`uselib during analysis, then if it finds a design cell during elaboration, it is taken.

Verification Continuum™ VCS User Guide 196

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

In this case, the hierarchy underneath `uselib can be configured. For usage
example, see Example-3
d. If a design cell for an instance is found during vlogan itself, VCS does not look for
`uselib or -v/-y. For usage example, see Example-4

RULE2: Instance use Clause

1. Configuration instance use clause
a. VCS looks for an instance in the use clause specified in the configuration. For
usage example, see Example-5
b. If not found, VCS generates an error message.

RULE3: Instance liblist Clause

1. Configuration instance liblist clause
a. Resolves the design cell using the configuration instance liblist clause, if the
liblist argument is not empty. For usage example, see Example-6.1.

b. Looks for the design cell in the parent cell library, if liblist argument is empty. For
usage example, see Example-6.2.
c. Looks for the design cell in libraries specified with -liblist at the command line.
For usage example, see Example-6.3.
d. If the cell was analyzed using -v or -y in the same vlogan invocation as the parent.
e. Looks for the library cell in the configuration instance liblist clause, if the
liblist argument is not empty.

f. Looks for the library cell in the parent cell library, if the liblist argument is empty.
g. Looks for library cells in the libraries specified with -liblist at the command line.

RULE4: Cell use Clause

1. Configuration Cell use Clause
a. Looks for the design cell in the use clause.
b. If not found, VCS generates an error message.

Verification Continuum™ VCS User Guide 197

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

RULE5: Cell liblist Clause

1. Configuration cell liblist clause
a. Resolves the design cell using the configuration cell liblist clause, if the liblist
argument is not empty.
b. Looks for the design cell in the parent cell library, if the liblist argument is empty.
c. Looks for the design cell in the libraries specified with -liblist at the command
line.
d. If the cell was analyzed using -v or -y in the same vlogan invocation as the parent.
e. Looks for the library cell in the configuration cell liblist clause, if the liblist
argument is empty.
f. Looks for the library cell in the libraries, if the liblist argument is not empty.
g. Looks for the libraries specified with -liblist at the command line.

RULE6: Configuration Inherited liblist Clause

1. Configuration inherited liblist clause (derived from instance liblist or from cell
liblist)

a. Looks for the design cell in the configuration liblist (instance or cell clause)
b. Looks for the design cell in the parent cell library, if the liblist argument is empty.
c. Looks for the libraries specified with -liblist at the command line.
d. If the cell was analyzed using -v or -y in the same vlogan invocation as the parent.
e. Looks for the library cell in the configuration cell liblist clause.
f. Looks for the library cell in the parent cell library, if the liblist argument is empty.
g. Looks for the libraries specified with -liblist at the command line.

RULE7: Configuration Default liblist Clause

1. Configuration default liblist clause
a. Looks for the design cell in the configuration default liblist. For
usage example, see Example-7.1.
b. Looks for the design cell in the parent cell library, if there are no arguments in the
configuration default liblist.

Verification Continuum™ VCS User Guide 198

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

c. Looks for the design cell definition in the libraries specified with -liblist at the
command line. For usage example, see Example-7.2.
d. If the cell was analyzed using -v or -y in the same vlogan invocation as the parent.
e. Looks for the library cell definition in the configuration default liblist.
f. Looks for the library cell definition in the parent cell library, if there are no arguments
in the configuration default liblist.
g. Looks for the library cell definition in the libraries specified with -liblist at the
command line. For usage example, see Example-7.3.

RULE8: No Configuration Rule Applies

1. No configuration rule applies
a. Looks for the design cell in the parent cell library. For usage example, see
Example-8.1.
b. Looks for the libraries specified with -liblist at the command line. For
usage example, see Example-8.2.
c. Looks for the library cell in the parent cell library.
d. Looks for the libraries specified with -liblist at the command line.
Library Search Order Rules for Verilog or SystemVerilog Designs Without a
Configuration File

-liblist
Specify -liblist at the command line.
Search Order:
1. Look in the libraries specified at the command line.
2. If not found, VCS generates an error message.
For usage example, see Example-9.

-liblist_work
This option tells VCS to first look in the parent work library when trying to resolve a design
cell. That is, while resolving module instances, this option ensures to always start search
for child modules from the parent work library before searching in the other analyzed
libraries.

Verification Continuum™ VCS User Guide 199

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

This elaboration option is relevant only for non-configuration flow (that is, when you do not
use the Verilog configuration file).
Search Order:
1. Look for the design cell in the parent cell library.
2. Look for the libraries specified in -liblist at the command line, or look for the
libraries specified in the synopsys_sim.setup file if -liblist is not passed.
3. Not applicable in the configuration flow. It does not apply in the configuration flow. It is
ignored if top is configured.
4. In case of , -liblist_work applies only for Verilog modules, and does not have any
impact on the VHDL module.
For usage example, see Example-10.

-liblist_work and -liblist

-liblist_work takes precedence over -liblist.

-liblist_nocelldiff
If this option is used, VCS does not differentiate between design cells and library cells. By
default, VCS prefers design cells over library cells while resolving instances. It follows the
configuration rules as applied to the -liblist options. For usage example, see Example-11.

Example Testcase Files

Consider the following design files:
Testcase: file1.v
module a(in1, in2, out1);
input in1, in2;
output out1;
initial
$display ( "Instance %m Module a from file1.v %l");
b b1(in1, in2, out1);
endmodule

module t1;

reg r1, r2;

wire w1;

a a1(r1,r2,w1);

initial

Verification Continuum™ VCS User Guide 200

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

$display ( "Instance %m Module t1 from file1.v %l");

endmodule

Testcase: file2.v
module a(in3, in4, out2);
input in3, in4;
output out2;

initial
$display ( "Instance %m Module a from file2.v %l");
b b1(in3,in4,out2);
endmodule

module t2;
reg r2, r4;
wire w2;

a a1(r2,r4,w2);

initial
$display ( "Instance %m Module t2 from file2.v %l");
endmodule

Testcase: modb_1.v
module b(in1, in2, out1);
input in1, in2;
output out1;
initial
$display ( "Instance %m Module b from modb_1.v %l");
endmodule

Testcase: modb_2.v
module b(in3, in4, out2);
input in3, in4;
output out2;
initial
$display ( "Instance %m Module b from modb_2.v %l");
endmodule

Testcase: top.v
module top;

t1 t1_1();
t2 t2_1();

initial
$display ( "Instance %m Module top from top.v %l");
endmodule

Verification Continuum™ VCS User Guide 201

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Usage Examples for Library Search Order Rules for Verilog or

SystemVerilog Designs
Usage Examples for RULE1
This section describes the examples for sub-rules listed under RULE1:`uselib of the
Library Search Order Rules for Verilog or SystemVerilog Designs section.
Example-1
Consider the following design files:
Testcase: file.v
module level1;
level2 l2();
initial $display("%l %m level1 (uselib)");
endmodule

module level2;
initial $display("%l %m level2 (uselib)");
endmodule

Testcase: level2.v
module level2;
initial $display("%l %m level2 (design)");
endmodule

module M;
initial $display("%l %m M");
endmodule

Testcase: top.v
module top;
`uselib file="file.v"
level1 l1();
endmodule

Configuration file: cfg.v

config topcfg;
design [Link];
instance top.l1.l2 use L2.level2;
endconfig

VCS commands:
mkdir L1 L2
vlogan -sverilog level2.v -work L2
vlogan -sverilog top.v -work L1
vlogan -sverilog cfg.v -work L1

Verification Continuum™ VCS User Guide 202

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

vcs [Link] -diag libconfig -libmap_verbose

-diag libconfig -libmap_verbose

simv

synopsys_sim.setup file:
WORK > DEFAULT
DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
L3 : ./lib3

Description
Library search order rules to resolve the top.l1.l2 instance are as follows:
1. The configuration file cfg.v specifies a configuration rule for the top.l1.l2 instance
(as the top.l1.l2 instance uses L2.level2), which indicates to resolve the l2
definition from the L2.level2 library.
2. As per the search rule, as the cell level1 (instance l1) is resolved from the `uselib
file in top.v, instance l2 under l1 is also resolved from the `uselib library only.
3. Instance l2 cannot be resolved from the configuration rule as given in cfg.v.
4. Configuration verbose output shows that l2 is resolved from the `uselib library.
instance: top.l1.l2

Example-2
Consider the following design files:
Testcase: file.v
module level1;
level2 l2();
initial $display("%l %m level1 (uselib)");
endmodule

module level2;
initial $display("%l %m level2 (uselib)");
endmodule

Testcase: level1.v
module level1;
level2 l2();
initial $display("%l %m level1 (design)");
endmodule

module M;

Verification Continuum™ VCS User Guide 203

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

initial $display("%l %m M");

endmodule

Testcase: top.v
module top;
`uselib file="file.v"
level1 l1();
endmodule

Configuration file: cfg.v

config topcfg;
instance top.l1 use L2.level1;
instance top.l1.l2 use L2.M;
endconfig

VCS commands:
mkdir L1
vlogan -sverilog level1.v -work L2
vlogan -sverilog top.v -work L1
vlogan -sverilog topcfg.v -work L1
vcs [Link] -diag libconfig -libmap_verbose

synopsys_sim.setup:
WORK > DEFAULT
DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
L3 : ./lib3

Description
Library search order rules to resolve the top.l1 instance are as follows:
1. As there is a configuration rule mentioned in the cfg.v file (The top.l1 instance uses
L2.level1) to resolve the definition from L2.level1, instance l1 is resolved as per
the configuration rule.
2. The top.l1.l2 instance is also resolved as per the configuration rule and uses L2.M.
instance: top.l1

module: L2.level1

instance: top.l1.l2

module: L2.M

Verification Continuum™ VCS User Guide 204

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Example-3
Consider the following design files:
Testcase: file.v
module level1;
level2 l2();
initial $display("%l %m level1 (uselib)");
endmodule

module level2;
initial $display("%l %m level2 (uselib)");
endmodule

Testcase: level2.v
module level2;
initial $display("%l %m level2 (design)");
endmodule

module M;
initial $display("%l %m M");
endmodule

Testcase: top.v
module top;
`uselib file="file.v"
level1 l1();
endmodule

Configuration file: cfg.v

config topcfg;
design [Link];
instance top.l1.l2 use L2.M;
endconfig

VCS commands:
mkdir L1 L2
vlogan -sverilog level2.v -work L2
vlogan -sverilog top.v -work L1
vlogan -sverilog cfg.v -work L1
vcs [Link] -diag libconfig -libmap_verbose

synopsys_sim.setup file:
WORK > DEFAULT
DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
L3 : ./lib3

Verification Continuum™ VCS User Guide 205

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Description
Library search order rules to resolve the top.l1.l2 instance are as follows:
1. The level1 (instance l1) cell is resolved from the `uselib file, but the l2 instance is
not resolved during vlogan analysis.
2. Configuration rules are applied to resolve the l2 instance, and the instance is resolved
from the L2.M library.
instance: top.l1.l2

module: L2.M

Example-4
Consider the following design files:
Testcase: file.v
module level1;
level2 l2();
initial $display("%l %m level1 (uselib)");
endmodule

Testcase: level1.v
module level1;
initial $display("%l %m level1 (design)");
endmodule

module level2;
initial $display("%l %m level2 (design)");
endmodule
module M;
initial $display("%l %m M");
endmodule

Testcase: top.v
module top;
`uselib file="file.v"
level1 l1();
endmodule

Configuration file: cfg.v

config topcfg;
design [Link];
endconfig

Verification Continuum™ VCS User Guide 206

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

VCS commands:
mkdir L1 L2
vlogan -sverilog level2.v -work L2
vlogan -sverilog top.v level2.v -work L1
vlogan -sverilog cfg.v -work L1
vcs [Link] -diag libconfig -libmap_verbose

synopsys_sim.setup:
WORK > DEFAULT
DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
L3 : ./lib3

Description
To resolve top.l1, VCS does not look at `uselib or -v/-y as the design cell level2 for
an instance l2 is found during vlogan itself.
instance: top.l1

module: L1.level1

Usage Examples for RULE2

This section describes the examples for sub-rules listed under RULE2: Instance use
Clause of the Library Search Order Rules for Verilog or SystemVerilog Designs section.
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
Example-5
Consider the following configuration file and VCS commands:
Configuration file: cfg.v
config topcfg;
design [Link];
instance top.t2_1.a1 use LIB2.a
endconfig

VCS commands:
vlogan modb_1.v -work lib_b1 +v2k -q
vlogan modb_2.v -work lib_b2 +v2k -q
vlogan file1.v -work lib1 +v2k -q
vlogan file2.v -work lib2 +v2k -q
vlogan top.v -work lib3 +v2k -q
vlogan +v2k -work work cfg.v -q
vcs [Link] -liblist lib1+lib2+lib3+lib_b1+lib_b2 -diag libconfig

Description

Verification Continuum™ VCS User Guide 207

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Library search order rules to resolve the top.t2_1.a instance are as follows:
1. VCS searches for a module definition of a in LIB2.a as provided by the configuration
rules.
2. VCS search completes once it finds the definition in LIB2.a.
instance: top.t2_1.a1

module: LIB2.a

Usage Examples for RULE3

This section describes the examples for sub-rules listed under RULE3: Instance liblist
Clause of the Library Search Order Rules for Verilog or SystemVerilog Designs section.
Example-6
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
Configuration file: cfg.v
config cfg;
design [Link];
instance top.t2_1.a1 liblist
instance top.t1_1.a1 liblist lib1
endconfig

VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k file2.v -work lib2
vlogan +v2k file2.v -work lib3
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vlogan +v2k cfg.v
vcs [Link] -liblist lib2+lib1+lib3+lib_b1+lib_b2 -diag libconfig
-libmap_verbose
simv

Example-6.1
VCS resolves the design cell using the configuration instance liblist clause if liblist
is not empty.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-6.
Description

Verification Continuum™ VCS User Guide 208

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Library search order rules to resolve the top.t1_1.a1 instance are as follows:
1. Search for the module definition of a in liblist lib1 as provided by the configuration
rule in cfg.v (instance top.t1_1.a1 liblist lib1)
2. Search completes if the definition is found in lib1.
3. Configuration verbose output:
instance: top.t1_1.a1

module: LIB1.a

Example-6.2
VCS looks for the design cell in parent cell library, if the liblist argument is empty.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-6.
Description
Library search order rules to resolve the top.t2_1.a1 instance are as follows:
1. The liblist argument in the configuration rule is empty (instance top.t2_1.a1
liblist).

2. If the argument after liblist is empty, then VCS looks for the module definition in the
parent cell library.
3. VCS looks for the module definition of a in the parent cell library which is t2_1.
4. Parent cell library of t2_1 is in LIB3.
5. VCS tries to resolve the module definition of a also in LIB3.
6. Search completes if the definition of a is found.
7. Configuration verbose output
instance: top.t2_1.a1

module: LIB3.a

Example-6.3
VCS looks for libraries specified in -liblist at the command line.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-6.
Description

Verification Continuum™ VCS User Guide 209

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

1. For the top.t1_1.a1.b1 instance, there is no specific rule applied in the configuration
file.
2. VCS looks for the module definition a first in the parent cell library, if the default
configuration is not present in the configuration file. In this example, the parent cell
library of the a module is lib1. VCS does not find the b module definition in lib1.
3. VCS then looks for libraries specified at -liblist at the command line in the order
provided.
4. VCS searches in LIB2. If not found in LIB2, VCS searches in LIB1. Then, VCS
searches in LIB3. If it finds the definition, search gets complete.
5. Configuration verbose output:
instance: top.t1_1.a1.b1

module: LIB_B1.b

Usage Examples for RULE7

This section describes the examples for sub-rules listed under RULE7: Configuration
Default liblist Clause of the Library Search Order Rules for Verilog or SystemVerilog
Designs section.
Example-7
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
Configuration file: cfg.v
config cfg;
design [Link];
instance top.t2_1.a1 liblist
default liblist lib_b2 lib2;
endconfig

VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k file2.v -work lib2
vlogan +v2k file2.v -work lib3
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vlogan +v2k cfg.v
vcs [Link] -liblist lib2+lib1+lib3+lib_b1+lib_b2 -diag libconfig
-libmap_verbose

Example-7.1
VCS looks for the design cell in the configuration default liblist.

Verification Continuum™ VCS User Guide 210

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Consider the design files, the configuration file, and VCS commands mentioned in
Example-7.
Description
Library search order rules to resolve the top.t1_1.a1.b1 instance are as follows:
1. VCS looks for default libraries specified in the default liblist in the configuration file
(default liblist lib_b2 lib1 lib2)
2. VCS finds the definition in LIB_B2, and the search gets completed.
instance: top.t1_1.a1.b1

module: LIB_B2.b

Example-7.2
VCS looks for the design cell definition in the libraries specified with -liblist at the
command line.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-7.
Description
Library search order rules to resolve the top.t1_1 instance are as follows:
1. VCS searches in the default configuration liblist provided in the configuration file,
cfg.v (default liblist lib_b2 lib2).

2. VCS could not find in any of the default libraries lib_b2 and lib2 definition of t1_1.
3. VCS looks for the libraries specified with -liblist at the command line
(lib2+lib1+lib3+lib_b1+lib_b2).
4. VCS starts looking for the t1_1 definition and finds in LIB1.
5. VCS search completes.
instance: top.t1_1

module: LIB1.t1

Example-7.3
VCS looks for the library cell definition in the libraries specified in the -liblist at the
command line.
Consider the design files mentioned in Example-7.
Configuration file: cfg.v

Verification Continuum™ VCS User Guide 211

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

config cfg;
design [Link];
instance top.t2_1.a1 liblist;
instance top.t1_1.a1 liblist lib3
default liblist lib_b2 lib1 lib2;
endconfig

VCS commands:
vlogan +v2k file2.v -work lib3 -v modb_2.v
vlogan +v2k file2.v -work lib3
vlogan +v2k file1.v -v modb_1.v -work lib_b1
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vlogan +v2k cfg.v
vcs [Link] -liblist lib1+lib3+lib_b1+lib_b2 -diag libconfig
-libmap_verbose

Description
Library search order rules to resolve the top.t2_1.a1.b1 instance are as follows:
1. VCS searches in the default library list lib_b2, lib, and lib2. However, it could not
find the definition.
2. VCS then looks at the libraries specified in -liblist at the command line in the order
provided lib1+lib3+lib_b1+lib_b2.
3. VCS finds the definition in LIB3 and search gets completed.
instance: top.t2_1.a1.b1

module: LIB3.b

Usage Examples for RULE8

This section describes the examples for sub-rules listed under RULE8: No Configuration
Rule Applies of the Library Search Order Rules for Verilog or SystemVerilog Designs
section.
Example-8
Consider the design files and hierarchy mentioned in the Example Testcase
Files section.

Configuration file: cfg.v

config cfg;
design [Link];
endconfig

Verification Continuum™ VCS User Guide 212

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k file2.v -work lib2
vlogan +v2k file2.v -work lib3
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vlogan +v2k cfg.v
vcs [Link] -liblist lib2+lib1+lib3+lib_b1+lib_b2 -diag libconfig
-libmap_verbose

Example-8.1
VCS looks for the design cell in the parent cell library.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-8.
Description
Library search order rules to resolve the top.t2_1.a1 instance are as follows:
1. No configuration rule applies for the top.t2_1.a1 instance, and there is no default
liblist configuration present. Therefore, VCS looks at the parent cell library.

2. Parent cell library for the parent module t2 is LIB3.

3. VCS finds the definition of a in LIB3 and the search gets completed.
instance: top.t2_1.a1

module: LIB3.a

Example-8.2
VCS looks for the libraries specified with -liblist at the command line.
Consider the design files, the configuration file, and VCS commands mentioned in
Example-8.
Description
Library search order rules to resolve the top.t2_1.a1.b1 instance are as follows:
1. No configuration rules applies for instance top.t2_1.a1.b1.
2. VCS tries to look into the parent cell library but could not find the definition.
3. VCS looks for the libraries mentioned with -liblist at the command line.
4. VCS searches in the libraries specified in the order specified at the command line.
5. VCS finds the definition in LIB_B1, and then the search gets completed.

Verification Continuum™ VCS User Guide 213

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

instance: top.t2_1.a1.b1

module: LIB_B1.b

Usage Examples for Library Search Order Rules for Verilog or SystemVerilog
Designs Without a Configuration File
This section describes the examples for library search order rules for Verilog or
SystemVerilog designs without a configuration file.
Example-9
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k file2.v -work lib2
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vcs top -diag libconfig
-libmap_verbose -liblist_nocelldiff

Description
Library search order rules to resolve the top.t2_1.a1.b1 instance are as follows:
1. Looks for the definition of module b.
2. Starts scanning the library files provided with -liblist from left to right.
3. Looks in library lib1. If it does not find in lib1, it looks in library lib2. If it does not
find in lib2, it looks in library lib3.
4. Looks in library lib_b1, finds the definition of b. The search gets completed.
instance: top.t2_1.a1.b1

module: LIB_B1.b

Example-10
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_2.v -work lib3
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k modb_1.v -work lib3
vlogan +v2k file2.v -work lib2
vlogan +v2k file2.v -work lib3

Verification Continuum™ VCS User Guide 214

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

vlogan +v2k file1.v -work lib1

vlogan +v2k file1.v -work lib3
vlogan +v2k -work lib3 top.v
vcs top -liblist_work -diag libconfig -libmap_verbose

Description
Library search order rules to resolve the top.t2_1.a1.b1 instance are as follows:
1. Looks for the design cell b.
2. As -liblist_work is present at elaboration time, VCS first tries to search the parent
work library.
3. Parent module of b is module a, and is available in the LIB3 library.
4. VCS tries to search the definition of b in LIB3.
5. VCS finds the definition of b in LIB3, and the search gets completed.
instance: top.t2_1.a1.b1

module: LIB3.b

Example-11
Consider the design files and hierarchy mentioned in the Example Testcase Files section.
VCS commands:
vlogan +v2k modb_2.v -work lib_b2
vlogan +v2k modb_1.v -work lib_b1
vlogan +v2k file2.v -v modb_2.v -work lib2
vlogan +v2k file2.v -work lib3
vlogan +v2k file1.v -work lib1
vlogan +v2k -work lib3 top.v
vcs top -liblist lib1+lib2+lib3+lib_b1+lib_b2 -diag libconfig
-libmap_verbose -liblist_nocelldiff

Description
Library search order rules to resolve the top.t2_1.a1.b1 instance are as follows:
1. Looks for the definition of module b in library LIB2 (library cell) and in LIB3 (design
cell).
2. With -liblist_nocelldiff, definition of b is resolved from library LIB2 as it is
available in LIB2.
3. LIB2 comes first in the order of -liblist (lib1+lib2+lib3+lib_b1+lib_b2)
provided at elaboration time.

Verification Continuum™ VCS User Guide 215

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

instance: top.t2_1.a1.b1
rule: default library search order

4. With no presence of -liblist_nocelldiff in the same example, definition of b is

resolved from the LIB_B1(design cell) library as it is available in LIB_B1.
instance: top.t2_1.a1.b1
rule: default library search order

Lint Warning Message for Missing ‘endcelldefine

You can tell VCS to display a lint warning message if your Verilog or SystemVerilog code
contains a ‘celldefine compiler directive without a corresponding ‘endcelldefine
compiler directive and vice versa.
You enable this warning message with the +lint=CDUB VCS compile-time option vlogan
command-line option. The CDUB argument stands for “Compiler Directives Unbalanced.”
The examples in this section show the warning message and the source code that results
in its display.

Example 8 Source Code With Missing ‘endcelldefine

`celldefine
module mod;
endmodule

In this example, there is no corresponding ‘endcelldefine compiler directive.

In VCS two-step flow, if you execute the following vcs command:
vcs exp1.v +lint=CDUB

VCS displays the following Lint warning message:

Lint-[CDUB] Compiler directive unbalanced
exp1.v, 1
Unbalanced compiler directive is detected : `celldefine
has no matching `endcelldefine.
Please make sure that all directives are balanced.

In VCS, vlogan also displays this lint warning message when you execute the following
command:
vlogan exp1.v +lint=CDUB

The source code in Example 9 does not display this warning message when you include
the +lint=CDUB.

Verification Continuum™ VCS User Guide 216

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Example 9 Source Code With ‘celldefine and ‘endcelldefine

`celldefine
module mod;
endmodule
`endcelldefine

It does not display the warning message because there is the ‘endcelldefine compiler
directive after the ‘celldefine compiler directive in the source code.
Instead of the ‘endcelldefine compiler directive, you can substitute the ‘resetall
compiler directive, as shown in Example 10.

Example 10 Source Code With ‘celldefine and ‘resetall

`celldefine
module mod;
endmodule
`resetall

The source code in both Example 9 and Example 10 does not result in the warning
message when you include the +lint=CDUB option.
Also with the +lint=CDUB option, if your source code contains the ‘endcelldefine
compiler directive without the preceding and corresponding ‘celldefine compiler
directive, you see a similar warning message.

Example 11 ‘endcelldefine Without a Preceding and Corresponding ‘celldefine

module mod;
endmodule
`endcelldefine

With the +lint=CDUB option, this source code results in the following lint warning
message:
Lint-[CDUB] Compiler directive unbalanced
exp6.v, 3
Unbalanced compiler directive is detected : `endcelldefine
has no matching `celldefine.
Please make sure that all directives are balanced.

With the +lint=CDUB option, it is not just that the number of ‘endcelldefine compiler
directives must be equal to the number of ‘celldefine compiler directives. The
‘endcelldefine compiler directive must follow the ‘celldefine compiler directive before
there is another ‘celldefine compiler directive.

Example 12 Equal Number of ‘celldefine and ‘endcelldefine, But Not in the Required Sequence
`celldefine \\ line 1
module mod;
endmodule

Verification Continuum™ VCS User Guide 217

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

`celldefine
module schmodule;
endmodule

`endcelldefine

`endcelldefine \\ line 11

In Example 12, the number of ‘celldefine compiler directives matches the number of
‘endcelldefine compiler directives, but they are not in a corresponding sequence, which
results in the following lint warning messages:
Lint-[CDUB] Compiler directive unbalanced
exp5.v, 1
Unbalanced compiler directive is detected : `celldefine
has no matching `endcelldefine.
Please make sure that all directives are balanced.

Lint-[CDUB] Compiler directive unbalanced

exp5.v, 11
Unbalanced compiler directive is detected : `endcelldefine
has no matching `celldefine.
Please make sure that all directives are balanced.

Limitation
The ‘celldefine/‘endcelldefine compiler directives must be matched serially.
Recursive ‘celldefine/‘endcelldefine directives are not supported with the
+lint=CDUB option and keyword argument, for example:

Example 13 Recursive ‘celldefine/‘endcelldefine Compiler Directives

‘celldefine
‘celldefine
module dev (...,...);
‘celldefine
‘celldefine
module dev (...,...);
...
endmodule
‘endcelldefine
‘endcelldefine

Example 13 shows redundant and unnecessary ‘celldefine and ‘endcelldefine

compiler directives, but does not prevent compilation. The +lint=CDUB option and

Verification Continuum™ VCS User Guide 218

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

keyword argument triggers the unbalanced message of Lint compiler directives when VCS
reads another ‘celldefine directive before reading an ‘endcelldefine directive,

Error/Warning/Lint Message Control

You can control error, warning, and lint messages in the following two ways:
• For -error, -suppress, +lint, and +warn compile options, see Controlling Error/
-error[-]
-error -suppress[-]
-suppress +lint[lint]
+lint +warn[warn]
+warn

Warning/Lint Messages Using Compile-Time Options on page 219.

• With a configuration file that you specify with the following compile-time option:
-msg_config=message_configuration_file_name
-msg_config[-]
-msg_config

Using a configuration file, you can control lint, warning, and error messages that VCS
displays according to the following:
◦ by source file name
◦ by module name
◦ by design subhierarchy
See Controlling Error/Warning/Lint Messages Using a Configuration File.

Controlling Error/Warning/Lint Messages Using Compile-Time

Options
The -error, -suppress, +lint, and +warn options control error and warning messages.
-error[-]
-error

With them, you can:

• Disable the display of any lint, warning, or error messages.
• Disable the display of specific messages.
• Limit the display of specific messages to a maximum number that you specify.
To control the display of specific messages, you need their message IDs. A message ID
is the character string in a message between the square brackets [ ]. In Figure 3, the
message ID is MFACF.
Note:
The -error option is also a runtime option.

Verification Continuum™ VCS User Guide 219

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Figure 3 Message IDs

message ID

Warning-[MFACF] Missing flag argument

Argument for flag 'verboseLevel' is missing in config statement, it will be
ignored.
Config file : error_id0_id1.cfg, starting at line 4.

The new compile-time options for controlling messages and their syntax are as follows:
-error=[no] [: ],...|none|all

-error=all,no |noLint_ID

+warn=[no] [: ],...|none|all

+lint=[no] : ],...|none|all

-suppress[= ,...]

Note:
The -error option is also a runtime option. However, only the following feature
is supported at runtime:
-error=[no] [: ],...

These compile-time options and their arguments are described in the following sections:
• Controlling Error Messages
• Controlling Lint Messages
• Suppressing Lint, Warning, and Error Messages
• Error Conditions and Messages That Cannot Be Disabled
• Using Message Control Options Together

Verification Continuum™ VCS User Guide 220

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Controlling Error Messages

You can control error messages with the -error option in the following ways:
-error[-]
-error

• Limit the number of occurrences of an error message to a number you specify. For this,
specify the message ID as an argument to the -error option along with the specified
maximum number of occurrences.
• Disable the display of all error messages which are downgradable with the none
argument.
• Enables the display of all errors/warnings/lint messages with the all argument to the
-error option.

Upgrading Lint and Warning Messages to Error Messages

If you enter the message ID for a warning or lint message as an argument to the -error
option, VCS upgrades the condition causing the warning or lint message to an error
condition and an error message.
Controlling Warning Messages
Like error messages, you can control warning messages with the +warn option in the
following ways:
• Limit the number of occurrences of a warning message to a number you specify.
For this, specify the message ID as an argument to the +warn option along with the
specified maximum number of occurrences.
• Disable the display of a particular warning message by entering the keyword no as an
argument and appending to this keyword the message ID, for example:
+warn=noTFIPC

This option disables the display of the error message with the TFIPC message ID.
Note:
• Do not enter a maximum number of occurrences, even if 0, if also appending the no
keyword to the message ID.
• Disable the display of all warning messages with the none argument to the +warn
option.
• Enable the display of all warning messages with the all argument to the +warn option.
• Controls the display of all notes. For example,
+warn=noFCICIO

This option suppresses the display of the following note:

Note-[FCICIO] Instance coverage is ON

Verification Continuum™ VCS User Guide 221

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Upgrading Lint Messages to Warning Messages

Note:
• All lint/warning messages are suppressible. But only some of the error messages can
be downgraded or suppressed.
• You cannot downgrade all error conditions and messages to a warning condition and
message. Entering a message ID for an error message that cannot be downgraded
as an argument to the +warn option results in VCS ignoring the message ID and
displaying a warning message similar to the following:
Warning-[CSMC] Cannot set message count
Failed to set display count for message id 'TFAFTC' because cannot
set count
for non-warning ID in '+warn' switch.
Specified count is ignored.

For an example of this warning see Example 4: An Error Message That Cannot Be
Controlled.
This warning message is in response to the +warn=TFAFTC:2 option, when TFATFC is
the ID for the following error message:
Error-[TFAFTC] Too few arguments to function/task call
tfatc_err.v, 9
"wrFld4(.bus(1));"
The above function/task call is not done with sufficient arguments.

Controlling Lint Messages

Like error and warning messages, you can control lint messages with the +lint option in
the following ways:
• You can limit the number of occurrences of a lint message to a number you specify.
For this, specify the message ID as an argument to the +lint option along with the
specified maximum number of occurrences.
You can enter a maximum of 0 to disable any display of the message specified by the
message ID, see Example 2: Reducing the Number of lint Messages.
Note:
◦ Do not enter a maximum number of occurrences, even if 0, if also appending the no
keyword to the message ID.
◦ Disable the display of all lint messages with the none argument to the +lint option.

Verification Continuum™ VCS User Guide 222

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

◦ Enable the display of all lint messages with the all argument to the +lint option.
Note:
You cannot downgrade an error or warning condition and message to a lint condition and
message.
Suppressing Lint, Warning, and Error Messages
The -suppress option suppresses lint, warning, and error messages. The -suppress
option with no argument should suppress all warnings/lint and downgradable error
messages
If you enter a message ID argument, and the message is downgradable, VCS does not
display that message. You can enter the ID for any lint, warning, or downgradable error
message.
The -suppress option gives you a message control option that takes a higher precedence
when you enter more that one of these options: -error, +warn, or +lint. For more
-error[-]
-error

details, see Using Message Control Options Together.

Note:
The -error option is also a runtime option.
Error Conditions and Messages That Cannot Be Disabled
Some error conditions always terminate compilation without creating an executable and
cannot be controlled or suppressed by the -error or -suppress options.
• Syntax errors
• Fatal error messages, those from error conditions that immediately halt compilation
Using Message Control Options Together
If you are entering more than one of these message control options, you will need to know
their precedence when used together. The order of precedence from highest to lowest is
as follows:
1. The -suppress option with no arguments, suppresses all possible messages and
cannot be overridden by another message control option.
2. The none argument has a higher precedence than specifying all or a message ID.
3. The order on the vcs command line
The following options and arguments have the same intrinsic precedence:

-suppress=messageID

Verification Continuum™ VCS User Guide 223

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

-error=messageID:max -error=all

+warn=messageID:max +warn=all

+lint=messageID:max +lint=all

Because they have equal intrinsic precedence, the order on the vcs command line
determines relative precedence. The first of these options on the command line has the
least precedence and the last of these has the most.
Message Control Examples
The following examples show how to use these options:
Example 1: Reducing the Number of Warning Messages
If you have small SystemVerilog source file named as diff_clk_wosvaext.sv with the
following content:
1 module top #(Pa = 1);
2 bit a , c, clk;
3 wand b1;
4 wand c1;
5
6 clocking cb2 @(posedge clk);
7 endclocking
8
9 sequence S2();
10 @(cb2) $past($past(a,,$stable($isunknown(1'bx),@(negedge
clk)),@(posedge clk)),,$sampled(a),@(negedge clk));
11 endsequence
12
13 property P1();
14 @(cb2 , posedge clk iff($stable(b1,@(posedge clk))))
$stable($past(b1,,,@(posedge clk)),@(negedge clk));
15 endproperty
16
17 A1: assume property (@(S2) S2 );
18 A2: assume property (@(S2) P1());
19 A3: assume property ( @(cb2) disable iff($stable(c1)) P1);
20 A4: assume property ( @(cb2) disable iff($sampled($past(c1,,,@(clk))))
first_match (S2));
21
22 sequence S3();
23 @(cb2) S2() ##1 @(negedge clk) $stable(b1 || $sampled(c1), @(posedge
clk));
24 endsequence
25
26 A5: cover property ( @(S2) S3);
27 initial begin
28 a = 1;

Verification Continuum™ VCS User Guide 224

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

29 repeat (20)
30 #5 clk = !clk;
31 end
32 endmodule

If you compile the above system Verilog file with the following command,
vcs -sverilog diff_clk_wosvaext.sv

VCS displays the following warning messages:

Warning-[SVA-LCDNAWPSC] Lead and property/sequence clocks differ
diff_clk_wosvaext.sv, 17
top
Leading clock of expression does not agree with property/sequence
clock.
Leading clock will be applied.
property/sequence clock: S2
leading clock: posedge clk

Warning-[SVA-LCDNAWPSC] Lead and property/sequence clocks differ

diff_clk_wosvaext.sv, 18
top
Leading clock of expression does not agree with property/sequence
clock.
Leading clock will be applied.
property/sequence clock: S2
leading clock: top.cb2,posedge clk iff $stable(b1, @(posedge clk))

Warning-[SVA-LCDNAWPSC] Lead and property/sequence clocks differ

diff_clk_wosvaext.sv, 19
top
Leading clock of expression does not agree with property/sequence
clock.
Leading clock will be applied.
property/sequence clock: posedge clk
leading clock: top.cb2,posedge clk iff $stable(b1, @(posedge clk))

Warning-[SVA-LCDNAWPSC] Lead and property/sequence clocks differ

diff_clk_wosvaext.sv, 26
top
Leading clock of expression does not agree with property/sequence
clock.
Leading clock will be applied.
property/sequence clock: S2
leading clock: posedge clk

VCS displays the same warning four times, if you want to control the number of warning
messages, you can use the compile-time option +warn=warn_ID:n...
For example,
vcs -sverilog +warn=SVA-LCDNAWPSC:1 diff_clk_wosvaext.sv

Verification Continuum™ VCS User Guide 225

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

VCS limits the warning messages to one.

Warning-[SVA-LCDNAWPSC] Lead and property/sequence clocks differ
diff_clk_wosvaext.sv, 17
top
Leading clock of expression does not agree with property/sequence
clock.
Leading clock will be applied.
property/sequence clock: S2
leading clock: posedge clk

Example 2: Reducing the Number of lint Messages

If you have small SystemVerilog source file named as [Link] with the following content:
1 `celldefine
2 module sub;
3 endmodule
4
5 `celldefine
6 module sub1;
7 endmodule
8
9 `celldefine
10 module top;
11 sub inst();
12 sub1 inst1();
13 endmodule

By default, all lint messages are disabled if you want to enable the lint message, you need
to use the +lint=lint_ID compile-time option. For example:
vcs -sverilog +lint=CDUB [Link]

VCS displays the following lint messages during compilation:

Lint-[CDUB] Compiler directive unbalanced
[Link], 1
Unbalanced compiler directive is detected : `celldefine has no matching
`endcelldefine.
Please make sure that all directives are balanced.

Lint-[CDUB] Compiler directive unbalanced

[Link], 5
Unbalanced compiler directive is detected : `celldefine has no matching
`endcelldefine.
Please make sure that all directives are balanced.

Lint-[CDUB] Compiler directive unbalanced

[Link], 9
Unbalanced compiler directive is detected : `celldefine has no matching
`endcelldefine.
Please make sure that all directives are balanced.

Verification Continuum™ VCS User Guide 226

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

If you want to control the number of lint messages printed in the compile time, you can use
+lint=lint_ID:n... For example:
vcs -sverilog +lint=CDUB:1 [Link]

Now, VCS controls the number of lint messages printed to one:

Lint-[CDUB] Compiler directive unbalanced
[Link], 1
Unbalanced compiler directive is detected : `celldefine has no matching
`endcelldefine.
Please make sure that all directives are balanced

Example 3: Upgrading Multiple Warnings to One Error

Consider a Verilog file named tfpic.v with the following contents:
module top();
wire a,b,c;
child child_position_instance(a,b);
child child_name_instance(.b(b));
endmodule

module child( input a, input b, input c);

endmodule

The module child has three input ports, but the module instantiation statements have only
two or one port connection.
If you compile the vcs tfpic.v source file without message control, VCS displays the
following during compilation:
Warning-[TFIPC] Too few instance port connections
The following instance has fewer port connections than the module
definition
"tfipc.v", 3: child child_position_instance(a, b);

Warning-[TFIPC] Too few instance port connections

The following instance has fewer port connections than the module
definition
"tfipc.v", 4: child child_name_instance( .b (b));

Warning-[TFIPC] Too few instance port connections

The following instance has fewer port connections than the module
definition
"tfipc.v", 4: child child_name_instance( .b (b));

If you recompile specifying that message ID, TFIPC is upgraded to an error, and set to
display this error message only once:
vcs tfpic.v -error=TFIPC:1

Verification Continuum™ VCS User Guide 227

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

VCS displays the following error message only once:

Error-[TFIPC] Too few instance port connections
The following instance has fewer port connections than the module
definition
"tfipc.v", 3: child child_position_instance(a, b);

1 error

Example 4: An Error Message That Cannot Be Controlled

Consider a Verilog file named tfatf_err.v with the following content:
module top;
task wrFld4(input string fldName, input int bus = 0,input string
fldName2);
$display("In wrFld4");
endtask
task wrFld4_2(input int bus = 0,input string fldName);
$display("In wrFld4");
endtask
initial begin
wrFld4(.bus(1)); // this is line 9
wrFld4(,1); // 10
wrFld4_2(.bus(1)); // 11
end
endmodule

The wrFld4 task has three input ports and the wrFld4_2 task has two input ports.
However, the task enabling statements for them have only one connection.
VCS displays the following during compilation:
Error-[TFAFTC] Too few arguments to function/task call
tfatc_err.v, 9
"wrFld4(.bus(1));"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 10
"wrFld4(, 1);"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 10
top, "wrFld4(, 1);"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 11
top, "wrFld4_2(1);"
The above function/task call is not done with sufficient arguments.

Verification Continuum™ VCS User Guide 228

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

The error message with the ID TFAFTC is displayed four times. If you recompile while
specifying that this error message gets displayed only once:
vcs tfatc_err.v -sverilog -error=TFAFTC:1

VCS displays the following:

Warning-[CSMC] Cannot set message count
Failed to set display count for message id 'TFAFTC' because it cannot
be
suppressed.
Specified count is ignored.

Parsing design file 'tfatc_err.v'

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 9
"wrFld4(.bus(1));"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 10
"wrFld4(, 1);"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 10
top, "wrFld4(, 1);"
The above function/task call is not done with sufficient arguments.

Error-[TFAFTC] Too few arguments to function/task call

tfatc_err.v, 11
top, "wrFld4_2(1);"
The above function/task call is not done with sufficient arguments.

1 warning
4 errors

None of the error messages are disabled and there is a warning saying that VCS cannot
limit the display of the message.
Example 5: Syntax Using the -suppress Option
Consider a SystemVerilog file [Link] with the following content:
1 module top;
2 wire [5:0]data;
3 longint result,result1,result2,result3,result4;
4 assign data = 6'h2345;
5 initial
6 begin
7 result = $clog2(4294967296); //2 ** 32
8 result4 = $clog2(2147483648); //2 ** 31

Verification Continuum™ VCS User Guide 229

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

9 result3 = $clog2(1073741824); //2 ** 30

10 result1=2**16;
11 result2=result1*result1;
12 $display("clog: %0d result2 %0d \n",result,result2);
13 $display("clog3: %0d \n",result3);
14 $display("clog43: %0d \n",result4);
15 end
16 endmodule

If you compile this file as follows:

vcs -sverilog [Link]

VCS displays the following warning messages:

Warning-[TMBIN] Too many bits in Based Number
[Link], 4
The specified width is '6' bits, actually got '16' bits.
The offending number is : '2345'.

Warning-[DCTL] Decimal constant too large

[Link], 7
Decimal constant is too large to be handled in compilation.
Absolute value 4294967296 should be smaller than 2147483648.

Warning-[DCTL] Decimal constant too large

[Link], 8
Decimal constant is too large to be handled in compilation.
Absolute value 2147483648 should be smaller than 2147483648.

If you are using the -suppress option with the command line all warning messages are
suppressed.
For example, if you use the following command:
vcs -sverilog -suppress [Link]

The -suppress option suppresses all warning/lint/downgradable error messages.

Controlling Error/Warning/Lint Messages Using a Configuration

File
Using a configuration file, you can control lint, warning, and error messages that VCS
displays according to the following:
• Source file name
• Module name
• Design subhierarchy

Verification Continuum™ VCS User Guide 230

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

You control these messages with entries in a configuration file that you specify with the
following compile-time option:
-msg_config=message_configuration_file_name
-msg_config[-]
-msg_config

In this message configuration file, the basic rules are as follows:

• Each configuration entry is enclosed in braces or curly brackets { }; for example:
{ +warn=noTFIPC;
+file=$VCS_HOME/[Link];
}

This entry specifies disabling the warning message with the TFIPC message ID about
the content of the [Link] source file in the VCS installation.
• Each entry can have only one message operation command, beginning with one the
following keywords:
+lint +warn -error -suppress

• There can be multiple control conditions specified in the same entry, beginning with the
following keywords:
+file +module +tree -file -module and -tree

• Message operation commands and control conditions that begin with + are for including
something; those that begin with - are for excluding something.
• The message operation command and control conditions are separated with a
semicolon ; or white space or return.
• Comments can be added to the file using the character types // and #. For example:
// This is a single line comment. Multi-line comment /* */ is not supported.
• Any + control condition, such as +file, cannot be used together with its corresponding
- control condition, such as -file, in the same configuration entry.

• VCS reports an error condition if you specify conflicting control conditions for the same
message ID.
This sections consists of the following subsections:
• Controlling Lint Messages
• Controlling Warning Messages
• Controlling Error Messages
• Upgrading Lint and Warning Messages to Error Messages
• Downgrading Error Messages to Warning Messages

Verification Continuum™ VCS User Guide 231

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

• Suppressing All Types of Messages

• Enabling and Disabling by Source File
• Enabling and Disabling by Module Definition
• Enabling and Disabling by Subhierarchy
Controlling Lint Messages
Lint messages are disabled by default so the lines in a configuration file enable their
display.
To enable lint messages with a message operation command in a configuration entry that
begins with +lint=arguments, use the following arguments:
+lint=all
+lint=all

To specify that the lines that follow enable the display of all lint messages.
+lint=ID1,ID2...
+lint=ID1

A comma separated list of lint message IDs to specify that you want to enable these
specific lint messages, for example:
+lint=CDUB,NCEID

This list of IDs enables the display of the lint messages with CDUB and NCEID message
IDs.
+lint=none
+lint=none

To specify that the lines that follow disable the display of all lint messages for a particular
control condition in a configuration entry.
+lint=all,noID1,noID2...
+lint=all

A comma separated list of message IDs, each preceded by no with no space between no
and the IDs, to disable these specified lint messages in a configuration entry.
Note the following about the +lint message operation command:
• It suppresses lint messages for the specified modules (see Enabling and Disabling by
Module Definition) when you enter the +lint=none message operation command.
• It suppresses the specific lint messages for the specified modules when you enter the
+lint=noID message operation command.

Verification Continuum™ VCS User Guide 232

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Controlling Warning Messages

To disable warning messages with the +warn=arguments message operation command,
use the following arguments:
+warn=none

To specify that the lines that follow disable the display of all warning messages.
+warn=noID1,noID2...

A comma separated list of message IDs, each preceded by no with no space between
no and the IDs, to specify that you want to disable these specific warning messages, for
example:
+warn=noMFACF,noCSMC

This list of IDs disables the display of the warning messages with MFACF and CSMC
message IDs.
Note the following about the +warn message operation command:
• It suppresses warning messages for the specified modules when you enter the
+warn=none message operation command.

• It suppresses the specific warning messages for the specified modules when you enter
the +warn=noID message operation command.
Controlling Error Messages
Error messages, like warning messages, are enabled by default. You can use the
configuration file to do the following:
• Upgrade lint and warning messages to error messages.
• Downgrade applicable error messages to warning messages (not all error messages
are downgradable).
Upgrading Lint and Warning Messages to Error Messages
To upgrade lint and warning messages to error messages, use the -error=arguments
message operation command in the configuration entry. The arguments you can enter are
as follows:
-error=all

Upgrades all enabled lint and warning messages to error messages.

+lint=all -error=all

Enables all lint messages, then upgrades all enabled lint and warning messages to error.
The order of these options is important to get the messages with the appropriate severity

Verification Continuum™ VCS User Guide 233

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

level. If you provide the options in opposite order as +lint=all -error=all, then all the
lint messages will not be upgraded to the severity level of error.
-error=ID1,ID2...

A comma separated list of lint and warning message IDs to upgrade them to error
messages, for example:
-error=CDUB,MFACF

This list of IDs upgrades the lint message with the ID of CDUB and the warning message
with the ID of MFACF to error messages.
Downgrading Error Messages to Warning Messages
To downgrade error messages to warning messages, use a message operation command
in the configuration entry that begins with:
-error=noID1,noID2...

The comma separated list is a list of error message IDs, preceded by the keyword no, for
example:
-error=noURMI,noETMFCB

Not all error messages are downgradable. If you enter an error message ID for a non-
downgradable error message, you receive a different error message indicating that it is not
downgradable.
Note:
• You cannot downgrade all error messages to warning messages with the -error=none
option.
Suppressing All Types of Messages
You can disable the display of all types of messages - such as informational, lint, warning,
and error messages. For this, enter a line in the configuration file beginning with the -
-suppress

suppress or -suppress=arguments message operation command except the error

messages that cannot be downgraded.
Note:
The -suppress message operation command cannot suppress non-
downgradable error messages.
The arguments you can enter are as follows:
-suppress without an argument

Suppress all downgradable messages. This message operation command is the

equivalent of the -error=none message operation command.

Verification Continuum™ VCS User Guide 234

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

-suppress=ID1,ID2...
-suppress

A comma separated list of message IDs to suppress specific lint, warning, or error
messages, for example:
-suppress=CDUB,CSMC

This list of IDs suppresses the display of the lint message with the CDUB ID and the
warning message with the CSMC IDs.
Enabling and Disabling by Source File
You can enable or disable lint, warning, and error messages for specific source files. For
this, add the following control conditions to message operation command:
+file=source_file_list
+file=source_file_list

source_file_list is a comma separated list of source files without spaces between

them, for example:
+file=[Link],[Link],[Link]

This control condition specifies that the messages enabled in the preceding message
operation command are enabled only for the source files named [Link], [Link], and
[Link].
-file=source_file_list
-file=source_file_list

This control condition is similar to but opposite from +file=source_file_list. This

control condition specifies the source files not affected by the message operation
command.
Enabling and Disabling by Module Definition
You can enable or disable messages for specific module definitions. For this, add the
following control conditions to a message operation command in a configuration entry:
+module=module_name_list
+module=module_name_list

The module name list is a comma separated list of module names, for example:
+module=top,introctr,arbit

This control condition specifies that the messages enabled in the message operation
command are enabled for the contents of the modules named top, introctr, and arbit.
-module=module_name_list
-module=module_name_list

This control condition is similar to but opposite from +module=module_name_list. This

control condition specifies the module definitions not affected by the message operation
command.

Verification Continuum™ VCS User Guide 235

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Enabling and Disabling by Subhierarchy

Consider a scenario in which your design includes sub-hierarchies, such as in a Verilog
library file that has a top-level module and module definitions hierarchically under it, or
some other discrete set of module definitions in a hierarchy with a top-level module,
such as in design re-use in a larger design. To enable or disable messages for these
subhierarchies, specify the top-level module definition with the following control conditions:
+tree=module_name_list
+tree=module_name_list

The module name list is a comma separated list of top-level module names, for example:
+tree=introctr,arbit

This control condition specifies that the messages enabled in the message operation
command are enabled for module definitions introctr and arbit and the module definitions
hierarchically under them.
-tree=module_name_list
-tree=module_name_list

This control condition is similar to but opposite from +tree=module_name_list. This

control condition specifies the subhierarchies not affected by the message operation
command.

Extracting the Files Used in Elaboration/Compilation

To extract the Extensible Markup Language (XML) files, which are required to create the
top module, use the -metadump compile-time option. Its syntax is as follows:
-metadump

For two-step flow:

% vcs -metadump < -metadump

>

For three-step flow:

% vlogan <analyze_options> < >
% vcs -metadump < >

Using this syntax, you can generate the list of files required to create the top-level module
and create simv.
The -metadump option generates XML files from which you can get information about all
files with the file name and the information about the line number to resolve simv.
The arguments or sub-options for the -metadump option are as follows:
-metadump[=<hierarchy_name>]

Generates the file list used by the sub hierarchy tree.

-metadump_only

Verification Continuum™ VCS User Guide 236

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Exits the compilation without generating simv.

-top "top1+top2" -metadump

Supports multiple top modules.

-metadump_txt

Generates the text files instead of XML files.

The reporting files are in the XML file format. The [Link] file is extracted
for the Verilog portion of the design and the [Link] file is extracted for
the VHDL portion of the design. These files can be accessed from the current working
directory.
Note:
This section describes the feature in the context of the Unified Use Model
(UUM) flow only. The two-step flow is not supported in this implementation.
This section discusses the following topics:
• XML File Format
• Limitations

XML File Format

This section describes the format of the XML document. Synopsys does not provide a
parser for the XML file and it is suggested to choose to process the file in the way you
want.
There are four main sections in the XML file as described in this section.
Section 1
<?xml version="1.0" encoding="ISO-8859-1" ?>
<opml version="1.0">
<head>
<title>VCS Dump File for Post Process</title>
<vcsVersion> H-2013.06-SP1 (ENG)</vcsVersion>
<dateCreated>Tue May 14 [Link] 2013</dateCreated>
</head>

The top-level head section describes the basic statistical information about the file, such
as the VCS version that is used and the date on which it is created. This information can
be used to keep track of when the list of files was extracted.
Section 2
The following example provides the collection of files that are listed in the <filelist>
section. These are the complete set of files that are used in the entire design.

Verification Continuum™ VCS User Guide 237

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

<fileList>
<file fid="0" path="/remote/path1/directory1/Macro/m.h" />
<file fid="1" path="/remote/path2/directory2/y.h" />
<file fid="2" path="/remote/path1/directory1/Macro_n.h" />
<file fid="3" path="/remote/path1/directory1/Macro/x.h" />
<file fid="4" path="="/remote/path1/directory1/Macro/test.v" />
</fileList>

Each of the file fid point to a specific path on the file system from where it is picked up.
This section also provides a list of all the files that make up simv.
In this example, file fid =”1” refers to the /remote/path2/directory2/y.h file on
the file system. The file fid=”0” refers to the m.h file in some other location. The list of
files included in this section are both include files and elaboration files.
Section 3
This section provides the information about the files that are included by other files
as understood by the VCS parser. It provides a list of include files that are used for
elaboration of the design. Note that the list of include files are non-unique. If a file is
included by many files, it is displayed as separate lines in this section of the XML file.
<!-- Include file list for the whole design -->
<includeFileList>
<incfile fid="0" lineno="10" includeID="3" />
<incfile fid="4" lineno="1" includeID="0" />
<incfile fid="4" lineno="2" includeID="2" />
<incfile fid="4" lineno="3" includeID="3" />
</includeFileList>

For example,
<incfile fid="0" lineno="10" includeID="3" />

is interpreted as follows:
file fid=”0”, that is, /remote/path1/directory1/Macro/m.v includes file fid =
“3”,(/remote/path1/directory1/Macro/x.h) on line number 10.

Each file picked up by the parser is reported as explained.

In this example, it is noted that file fid=”3” (that is /remote/path1/directory1/
Macro/x.h) is included by multiple files, and therefore, shows up multiple times in the list.

Section 4
This section is a unified unique list of files that are included in the design using the
`include directive from the previous section, which is a list of unique includeIDs.

This section displays only a subset of the list presented in Section 3. As mentioned earlier,
includedfile fid=”3” has been included multiple times by many files and can be seen
in the XML entries in the previous section. However, it is reported once in this section.

Verification Continuum™ VCS User Guide 238

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

<uniqIncludeFileList>
<includedfile fid=”0” />
<includedfile fid=”2” />
<includedfile fid=”3” />
</uniqIncludeFileList>

Example
If the top module is specified as a design top in elaboration, VCS gathers top.v and
header.v elaboration files. The top.v file is gathered as a non-include file and header.v
is gathered as an include file. If these two files are provided as input to tools, such as
vlogan, multiple-definition errors might occur.
top.v

`include "header.v"
module top;
bottom bot();
endmodule

header.v

module bottom;
endmodule
not_used.v

module not_used;
endmodule

VCS Command Line:

% vcs top.v
% vcs header.v
% vcs not_used.v
% vcs top -sverilog -metadump
% simv

VCS generates the [Link] file, which can be accessed from the current
working directory and contains the following in <body>:
<fileList>

<file fid="0" path="/remote/xxxx/yyy/Documents/header.v" />

<file fid="1" path="/remote/xxxx/yyy/Documents/top.v" />

</fileList>

The [Link] file lists only header.v and top.v. However, it does not list
the not_used.v file as it is not used in simulation.

Verification Continuum™ VCS User Guide 239

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Note:
For any tool that is capable of parsing the Verilog file and substitute the
`include directive, non-include files are sufficient to work.

Example
vllogic.v

module vllogic(a,b,c,d,e);
input a,b,c;
output d,e;
wire d,e;
assign d = a ^ b ^c;
assign e = ((a&b) | (b&c) | (a&c));
endmodule

vltop.v

`include "vllogic.v"
module vltop;
reg a,b,c;
wire d,e;
vhent vh1(.a(a), .b(b), .c(c), .d(d), .e(e));
initial begin
$monitor("a=%b b = %b c=%b d=%b e=%b", a,b,c,d,e,$time);
#2 a = 'b1; b = 'b1; c= 'b0;
#2 a = 'b0; b = 'b1; c= 'b1;
#2 a = 'b1; b = 'b0; c= 'b0;
#5 $finish;
end
endmodule

[Link]

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_arith.all;
entity vhent is
port(a,b,c: in std_logic;
d,e: out std_logic);
end entity;
architecture structural of vhent is
component vllogic
port(a,b,c: in std_logic;
d,e: out std_logic);
end component;
begin
vh1: vllogic port map(a,b,c,d,e);
end structural;

Verification Continuum™ VCS User Guide 240

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

not_used.vhd

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_arith.all;

entity orGate is
port( A, B : in std_logic;
F : out std_logic);
end orGate;

architecture func of orGate is

begin
F <= A or B;
end func;

VCS Command Line:

% vhdlan not_used.vhd
% vlogan vllogic.v
% vlogan vltop.v
% vhdlan [Link]
% vcs vltop -metadump
% simv

VCS generates the [Link] file for the Verilog code and the
[Link] file for the VHDL code, which can be accessed from the current
working directory.
The [Link] file lists the following:
<fileList>
<file fid="0" path="/remote/xxy/yyy/metadump1/[Link]" />
</fileList>

However, the XML file does not list the not_used.vhd file as it is not used in simulation.
Note:
To extract the text files instead of XML files, use the -metadump_txt compile-
-metadump_txt

time option.

Verification Continuum™ VCS User Guide 241

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Limitations
The following are the limitations with the -metadump option:
• The order of elaboration files cannot be guaranteed. For example, in a three-step flow,
if you swap file A and file B for vlogan, one or more of the following can happen:
◦ For the undefined macro references, syntax errors occur if file A uses a macro
defined in file B, and file A does not include file B either directly or recursively.
◦ A different default net type is picked up if file A uses a default net type defined in file
B, and file A does not include file B either directly or recursively.
◦ Error might occur in other related compiler directives.
Even with correct ordering or file A and file B, other problems might arise.
For example, in an elaboration, top1 is named design top, and top1.v gets
copied over to a new directory for insertion and the timescale of top1.v is 1ns/1ns.
In the original analyzed database ([Link]), the timescale could either be 1ps/1ps or
1ns/1ns based on the order of analysis of top1.v and top2.v.
top1.v

`timescale 1ns/1ns
module top1;
initial begin
$display("At %t Hello world\n", $time);
end
endmodule

top2.v
`timescale 1ps/1ps
module top2;
initial begin
$display("Hello world\n");
end
endmodule

The correct ordering does not guarantee simulation of file copies and happens in
the same manner as that of original files.
• Elaboration files do not include configuration files, synopsys_sim.setup, other non-
Verilog files, and non-VHDL files.
• The -metadump option does not work with partition compile flow. The metadump file
can be generated with single compile flow and the same file works in both single
compile and partition compile flow.

Verification Continuum™ VCS User Guide 242

V-2023.12
 Feedback
Chapter 4: Compiling/Elaborating the Design
Key Compilation or Elaboration Features

Reducing Compile Time for Post-Process Only Debug

If you want to perform only post-process debug with an existing VPD file and recreate
[Link], you can use the -static_dbgen_only compile-time option and significantly
reduce the compilation time.

Use Model
Perform the following steps:
1. Use the following syntax to compile your design file:
% vcs -debug_access+pp <other_vcs_options> file_name.v

2. Run the simulation to generate the VPD file.

% simv <simv_options>

3. Use the –static_dbgen_only compile-time option as follows to regenerate

[Link] which is required to do post-process debug.

% vcs –static_dbgen_only -debug_access+pp <other_vcs_options>

file_name.v

Verification Continuum™ VCS User Guide 243

V-2023.12
 Feedback

5
Simulating the Design
This chapter describes the following:
• Using Verdi
• Using UCLI
• Reporting Forces/Injections in a Simulation
• Key Runtime Features
As described in the section Simulation, you can simulate your design in either interactive
mode or batch mode. To simulate your design in interactive mode, you can use Verdi and
UCLI. To simulate your design in batch mode, you must use UCLI. For more information,
refer to the section entitled, Batch Mode.

Using Verdi
Verdi provides you with a graphical user interface to debug your design. Using Verdi, you
can debug the design in interactive mode or in post-processing mode. You must use the
same version of VCS and Verdi to ensure problem-free debugging of your simulation.
In the interactive mode, apart from running the simulation, Verdi allows you to do the
following:
• View waveforms
• Compare waveforms
• Trace drivers and loads
• View schematics and path schematics
• Execute UCLI/Tcl commands
• Set breakpoints (line, time, event, and so on)
• Line stepping

Verification Continuum™ VCS User Guide 244

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Using UCLI

However, in post-processing mode, an FSDB file is created during simulation, and you use
Verdi to:
• View waveforms
• Compare waveforms
• Trace drivers and loads
• View schematics and path schematics
Set VERDI_HOME and perform the following:
• Use the following command to invoke simulation in interactive mode using Verdi:
% simv -gui

• Use the following command to invoke Verdi in post-processing mode:

% verdi -ssf [Link] -nologo

Note:
The interactive mode of Verdi is not supported when you are running VCS
slave mode simulation.
For information on generating an FSDB dump file, see Debugging with Verdi.
For more information on using Verdi, see Verdi and Siloti Command Reference
Guideunder Verdi documentation in SolvNetPlus.

Using UCLI
Unified Command Line Interface (UCLI) provides a common set of commands for
interactive simulation. UCLI is the default command line interface for batch mode
debugging in VCS.
UCLI commands are based on Tcl, therefore you can use any Tcl command with UCLI.
You can also write Tcl procedures and execute them at the UCLI prompt. Using UCLI
commands, you can do the following:
• Control simulation
• Dump the FSDB and VPD files
• Save/Restore the simulation state
• Force/Release a signal
• Debug the design using breakpoints, scope/thread information, and built-in macros

Verification Continuum™ VCS User Guide 245

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Using UCLI

UCLI commands are built based on Tcl. Therefore, you can execute any Tcl command or
procedures at the UCLI prompt. This provides you with more flexibility to debug the design
in interactive mode. The following command starts the simulation from the UCLI prompt:
% simv [simv_options] -ucli

When you execute the above command, VCS takes you to the UCLI command prompt.
To invoke UCLI, ensure that you specify the -debug_access+r option during compilation/
elaboration. You can then use the -ucli option at runtime to enter the UCLI prompt at
time 0 as follows:
% simv -ucli
ucli%

At the ucli prompt, you can execute any UCLI command to debug or run the simulation.
You can also specify the list of required UCLI commands in a file, and source it to the UCLI
prompt or specify the file as an argument to the runtime option, -do, as shown below:
% simv -ucli
ucli% source [Link]

% simv -ucli -do [Link]

Note:
• UCLI is not supported when you are running VCS slave mode simulation.
• You can use the -ucli option at runtime even if you have not used some form of the
-debug_access option during compilation, but in this case only the run and quit UCLI
commands are supported.
Note the following behavioral changes when UCLI is the default command-line interface:
• Command line options, such as simv -i or -do, only accept UCLI commands
• Interrupting the simulation using Ctrl+C takes you to the UCLI prompt by default for
debugging your designs
• UCLI include file options (-i or -do) expect the next argument to be a UCLI script.
%> simv -ucli -i ucli_script.inc

• The -R feature in VCS continues to take you to the old CLI UI, unless you explicitly add
-ucli to VCS command line.

Verification Continuum™ VCS User Guide 246

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Options for Debugging Using Verdi and UCLI

-ucli2Proc Option
By default, UCLI runs in the simv process. There are a few scenarios which may require
running UCLI in its own process, and this is enabled using the -ucli2Proc option:
• In SystemC designs, you must specify the -ucli2Proc command, if you want to call
‘cbug’ in batch mode (ucli). VCS issues a warning message if you do not specify this
command
• When you issue a restore command inside a -i/-do/source, you must pass the
-ucli2Proc. This situation is only applicable when there are commands following the
restore commands that need to be executed in the do script

• Any usage of start/restart/finish/checkpoint/config endofsim/reversedebug

from UCLI needs the -ucli2Proc command
For more information about UCLI, click the link Unified Command-line Interface (UCLI) if
you are using the VCS Online Documentation.
If you are using the PDF interface, see ucli_ug.pdf to view the UCLI User Guide.

Options for Debugging Using Verdi and UCLI

-debug_access
-debug_access

Gives best performance with the ability to generate FSDB/VPD/VCD files for post-process
debug. It is the recommended option for post-process debug.
-debug_access(+<option>)

Allows you to have more granular control over the debug capabilities in a simulation. The
-debug_access option enables the dumping of the VPD and FSDB files for post-process
debug.
You can specify additional options with the -debug_access option to selectively enable the
required debug capabilities. You can optimize the simulation performance by enabling only
the required debug capabilities.
For more information on the -debug_access option, see “Optimizing Simulation
Performance for Desired Debug Visibility With the -debug_access Option”section.
-debug_region(=<option>)(+<option>)
-debug_region

Allows you to have better control over the performance of -debug_access. This option
enables you to apply debugging capabilities to the desired portion of a design.

Verification Continuum™ VCS User Guide 247

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

You must use the -debug_region option along with the -debug_access option at compile
time. For more information on -debug_region, see “Optimizing Simulation Performance
for Desired Debug Visibility With the -debug_access Option”section.
+fsdbfile+filename
-vpd_file <file_name>

FSDB dumping option. This option allows you to specify the FSDB file name. If this option
is not specified, the default FSDB file name is [Link].
Example: +fsdbfile+[Link]
-vpd_file <file_name>
-vpd_file <file_name>

Specifies the name of the generated VPD file. You can also use this option for post-
processing where it specifies the name of the VPD file.
+fsdb+dump_limit=size

Specifies a size limit for the FSDB file. The default and minimum size limit is 10MB.
Example: +fsdb+dump_limit=15
-vpd_fileswitchsize <size_in_MB>
-vpd_fileswitchsize <size_in_MB>

Specifies a size for the VPD file. When the VPD file reaches this size, VCS closes this file
and opens a new one with the same size.

Reporting Forces/Injections in a Simulation

VCS provides the details of all the forces applied on your design during the simulation in a
user-defined ASCII text file. This feature helps you to debug forces by allowing you to view
all the forces that are effective in a simulation.
The following sections describe this feature in detail:
• Use Model
• Reporting Force/Deposit/Release Information
• Generating Force List Report for Desired Instance Hierarchies
• Displaying Different ID for Each Verilog Force
• Displaying Source Information for VHDL Forces
• Displaying Source Information for External Forces
• Viewing Force Information in Interactive Debug Mode

Verification Continuum™ VCS User Guide 248

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

• Reporting $deposit Value Changes

• Limitations

Use Model
Perform the following steps to use this feature:
► Use the -force_list option at compile time, as shown below, to allow the force
-force_list

reporting feature to record language forces/releases.

% vcs <debug_option> filename.v -force_list <other_vcs_options>

Where,
<debug_option>

Reporting external (PLI) forces and deposits requires a minimum of read and callback
debug capability. This corresponds to -debug_access+r+cbk.
This step does not enable force reporting feature by itself. You must use –force_list
<filename> at runtime, as shown in the following step. For more information, see Table 9.

► Use the -force_list option at runtime, as shown below, to enable force reporting
feature and generate an ASCII text file containing information about the forces/
deposits/releases applied during the simulation in time order.
% simv –force_list <filename>

Where, filename is the user-defined ASCII file name. It can be relative path or
absolute path. Compression is disabled by default. Use the -force_list_compress
option at runtime to compress the resulting log file with the gzip compression. The log
file is saved with the same name, but changes its filename extension by appending .gz
at the end of it.
For example, for the following command:
% simv –force_list [Link] –force_list_compress

the output file is: [Link]

Use gunzip to uncompress a force list file. For example, uncompress the above output
file as follows:
gunzip [Link]

This results in the original file [Link] which is uncompressed.

Verification Continuum™ VCS User Guide 249

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Key Points to Note

• If you use the -force_list option at runtime, but not at compile time, only external
forces are logged
• If you use the -force_list option at both compile time and runtime, then both
language forces and external forces are logged
• For mixed signal designs, the -force_list option captures the force events on the
VHDL/VHPI/hdl_xmr targets. Pure VHDL designs are not supported
• Table 9 describes the usage of the -force_list option in detail.
Table 9 Usage of the -force_list Option

-force_list at compile -force_list at runtime Language forces External forces

time logged logged

No/Yes No No No

No Yes No Yes

Yes Yes Yes Yes

Reporting Force/Deposit/Release Information

The ASCII text file consists of the following parts:
• A header section that includes the information given in Table 10, associated with an
ASCII character ID that is 1 to 4 characters long. For more information, see Header
Section.
• A time order sorted list of force/release/deposits, as they occur during the simulation,
indexed by the ID shown in the header section. For more information, see Event List
Section.

Verification Continuum™ VCS User Guide 250

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Table 10 Force Capture and Log Information

Force type Time Instance name Module File / Line data Value
of the target name logged
node where force
occurred

Language Simulation Hierarchical Name of the Full path of the Value represented
force/relea time when node name [Link] file where the as binary except
se/deposit the node being mple: top force statement for int, real, and
was forced [Link] occurs, and the string [Link]
or released. le: line number of the value is prefixed
[Link] statement in the with ‘[Link]
d2.a source file. For will not have
example:/home/w values.
ork/test.v:1234

VPI/ACC/U Simulation Hierarchical Not Not Applicable Value represented

CLI time when node name Applicable as binary except
force/relea the node being forced. for int, real, and
se/deposit was forced string [Link]
or released. value is prefixed
with ‘[Link]
will not have
values.

Handling Forces on Bit/Part Select and MDA Word

If the target of the force is bit-select, part-select, or mda word, the appropriate indices is
included in the target node name, for example, as follows:
Bit select top.a.b[2]
Part select top.a.b[0:3]
MDA bit select top.c.d[2][3][4]
MDA part select top.c.d.[2][3][1:4]

Forces recorded can be any object supported by language and PLI forces.
Expressions are evaluated only if they contain constants and/or parameters. For example,
top.a[(1+paramb)*2)] is evaluated to determine the resulting constant index.

Expressions are not evaluated if they contain variables. For example, consider the
following code. In this case, only the base vector is captured.
logic [0:9] top.a;
for (i= 0; i < 10; i++)
begin
force top.a[i] = 1; // captures the entire vector for top.a and
not a select of top.a
end
end

Verification Continuum™ VCS User Guide 251

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Handling Forces on Concatenated Codes

Forces consisting of more than one signal on a signal line are split up on signal basis.
For example, force {a,b} = 2’b11 results in two header entries, one for a and one for
b. Both a and b display the same file/line number, but carry different IDs since they are
different nodes.

Output Format
The ASCII text file output consists of the following two sections:
• Header Section
• Event List Section
Header Section
The header section contains mapping between forced object list and unique ASCII ID. This
section is divided into two parts: Language Forces and External Forces.
Language forces are unique by statement, whereas external forces are unique by node.
Multiple language forces on the same node from different lines result in multiple header
entries for that node.
Multiple external forces result in one external force header entry for that node. Nodes with
both language and external forces have entries in both Language Forces and External
Forces parts.
For a unique node, only single ID is used for all entries in header for that particular node.
If VCS finds unsupported force/release event, it labels such event with a reason.
Following is the display format for Language Forces and External Forces:
Language Forces:
ID Target Module File:Line

External Forces (VPI/ACC/UCLI):

ID Target

Header Example
Header Section

Language Forces

ID Target Module File Line

1 top.child1.a top /home/user/top.v:10 **

NO_VALUE_CHANGE full mda **

Verification Continuum™ VCS User Guide 252

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

2 [Link] child /home/user/child.v:125

3 top.child1.a_real child /home/user/child.v:127

External Forces

ID Target

4 top.child1.a_int
5 top.child1.b[0:3]
6 top.child1.b[2]

Event List Section

This section displays the following information:
• Time during which the value is forced
• ID from the header
• Type of the force
• Value of force or deposit
Release value is not displayed. Table 11 lists the phrases of the acronyms used in the
Event List section.
Table 11 List of Acronyms Displayed in the Event List Section

Acronym Phrase

LF Language Force

LR Language Release

LD Language Deposit/write

EF External Force

ER External Release

ED External Deposit

Event List Example

ID Type Value
---- Time: 1 ---
2 LF ‘b0
5 EF ‘b1111
6 EF ‘b1
4 ED 25
---- Time: 2 ---
3 EF 2.14

Verification Continuum™ VCS User Guide 253

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

3 ER
5 LR
5 LD ‘b0110
--- Time: 3 ---

The Value column displays the integer and real values as decimal values, strings as
ASCII characters, and rest of them as binary values prefixed with ‘b. Long value strings
are line-wrapped.

Usage Examples
Example-1
Consider the following testcase test.v and the [Link] file which contains UCLI
forces.

Example 14 Design Testcase test.v

module top;

reg clk,rst,d;
wire q;

DUT dut (clk,rst,d,q);

always #1 clk = ~clk;

initial begin
clk = 0 ; rst =0 ; d=0 ;

#5 force rst = 1;
#5 release rst ;
#10 force dut.q =1 ;
#10 release dut.q ;
#100 $finish ;
end
endmodule

module DUT (clk,rst,d,q);

input clk,rst,d;
output q;
wire q;
reg q_reg;

assign q = q_reg;

always @ (posedge clk)

if (rst) begin
q_reg <= 0;
end else begin
q_reg <= d;

Verification Continuum™ VCS User Guide 254

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

end

endmodule

Example 15 [Link]
run 30
force [Link].q 1
release [Link].q
run

Compile the test.v code, as follows:

% vcs -debug_access+r+cbk -sverilog -force_list test.v

Run the simulation, as follows:

% simv -ucli -i [Link] -force_list [Link]

Use the following command to view the [Link] file:

% cat [Link]

Below is the content of the [Link] file:

VCS Force List
Header Section

Language Forces

ID Target Module File Line

1 [Link] top force.v 13

1 [Link] top force.v 14
2 [Link].q top force.v 15
2 [Link].q top force.v 16

External Forces

ID Target

2 [Link].q

Event List Section

---- Time: 0 ----

---- Time: 5 ----
1 LF 'b1
---- Time: 10 ----
1 LR
---- Time: 20 ----
2 LF 'b1
---- Time: 30 ----
2 EF 'b1

Verification Continuum™ VCS User Guide 255

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

2 LF 'b1
2 ER
2 LR
2 LR

Example-2
This example describes the usage of -force_list to capture force events on the hdl_xmr
targets.
Consider the following files:

Example 16 Testcase test_1.v

`timescale 1 ns/1 ns
module ex1 (main_bus bus);

reg reg_hdlxmr;
reg [7:0] reg_hdlxmr_vec;

endmodule

Example 17 Testcase test_2.v

module vtop (wa,wb,wc);

inout wa,wb;
input wc;
main_bus bus (.wa(wa),.wb(wb),.control1(wc));

ex1 ex11 (.bus(bus));

reg source_inter_reg;
byte vbyte1=8'd1,vbyte2=8'd1;
shortint vshort1=16'd1,vshort2=16'd1;
int vint1=32'd1,vint2=32'd1;
longint vlong1=64'd1,vlong2=64'd1;
bit[0:7] vbit1,vbit2;
bit[7:0] vbit3,vbit4;
logic[0:7] vlogic1=8'd1,vlogic2=8'd1;
logic[7:0] vlogic3=8'd1,vlogic4=8'd1;

logic l1=1;

initial
begin
# 10 ;
bus.interfacebyte2 = 8'd10 ;
bus.interfaceshort2 = 16'd10 ;
bus.interfacelong2 = 64'd10 ;
bus.interfacebit4 = 8'd10 ;
bus.interfacebit3 = 8'd10 ;
bus.interfaceint1 = 5 ;
bus.interfaceint2 = 5 ;

Verification Continuum™ VCS User Guide 256

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

bus.interfacelogic3 = 8'd10 ;
end

endmodule

Example 18 Testcase interface_datatypes.v

typedef enum {red,blue,green,yellow} color1;
interface main_bus (inout wa, wb, input control1);

reg interface_reg;
byte interfacebyte1 ,interfacebyte2 ;
shortint interfaceshort1 ,interfaceshort2 ;
integer interfaceint1 ;
int interfaceint2 ;
longint interfacelong1 , interfacelong2 ;
bit[0:7] interfacebit1 ,interfacebit2 ;
bit[7:0] interfacebit3 , interfacebit4 ;
logic[0:7] interfacelogic1 ,interfacelogic2 ;
logic[7:0] interfacelogic3 ,interfacelogic4 ;
logic interfacel1;
logic[0:1] interfacef1,interfacef2;
color1 intfcolor1 , intfcolor2 ;
modport driver (inout wa,
inout wb,
input control1);

modport slave (inout wa,

inout wb,
input control1);

endinterface

Example 19 Testcase [Link]

LIBRARY IEEE;
USE [Link];
USE IEEE.STD_LOGIC_TEXTIO.all;
USE IEEE.std_logic_1164.ALL;
Library Synopsys;
USE Synopsys.hdl_xmr_pkg.all;

entity ex2_vhtop is
port (wa,wb:INOUT std_logic;control1:in std_logic);
end entity;

architecture arch of ex2_vhtop is

component vtop is
port (wa,wb:INOUT std_logic;wc:in std_logic);
end component;
signal w_vector:std_logic_vector(0 to 10);
signal wire_wa,wire_wb,wire_control:std_logic:='0';
signal vhd_sig,vhd_sig1:std_ulogic_vector(0 to 7);

Verification Continuum™ VCS User Guide 257

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

type color_vhd is (red,blue,green,yellow);

signal vhd_enum,vhd_enum1:color_vhd;
signal vhbyte1,vhbyte:std_logic_vector(0 to 7) ;
signal vhshort1,vhshort2:std_logic_vector(0 to 15);
signal vhlong1,vhlong2:std_logic_vector(0 to 63);
signal vhbit1,vhbit2:std_logic_vector(7 downto 0);
signal vhd_sig3,vhd_sig4:std_logic_vector(7 downto 0);
signal vhint1,vhint2:integer;
signal vhbit3,vhbit4:bit_vector(7 downto 0);
signal vh_ustd3,vh_ustd4:std_ulogic_vector(7 downto 0);

begin

--Source interface signals

g1:vtop port map(wire_wa,wire_wb,wire_control);

wa <= wire_wa;
wb <= wire_wb;

end arch;

Execute the following elaboration commands:

% vlogan -sverilog interface_datatypes.v
% vlogan -sverilog test_1.v
% vlogan -sverilog test_2.v
% vhdlan [Link]
% vcs ex2_vhtop -debug_access+r+cbk

Execute the following simulation command:

% simv -force_list [Link]

The following output ([Link]) shows the force events on the hdl_xmr targets:
VCS Force List
Header Section

External Forces

ID Target

1 /EX2_VHTOP/VHBYTE1
2 /EX2_VHTOP/VHSHORT1

Verification Continuum™ VCS User Guide 258

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

3 /EX2_VHTOP/VHLONG1
4 /EX2_VHTOP/VHD_SIG4
5 /EX2_VHTOP/VHBIT3
6 /EX2_VHTOP/VHINT1
7 /EX2_VHTOP/VHINT2
8 /EX2_VHTOP/VH_USTD3

Event List Section

---- Time: 0 ----

1 VD 'b00000000
2 VD 'b0000000000000000
3 VD 'b0000000000000000000000000000000000000000000000000000000000000000
4 VD 'b00000000
5 VD 'b00000000
6 VD 0
7 VD 0
8 VD 'bXXXXXXXX
---- Time: 10 ----
1 VD 'b00001010
2 VD 'b0000000000001010
3 VD 'b0000000000000000000000000000000000000000000000000000000000001010
4 VD 'b00001010
5 VD 'b00001010
6 VD 5
7 VD 5
8 VD 'b00001010

Generating Force List Report for Desired Instance Hierarchies

The -force_list option allows you to generate force list report for the desired instance
hierarchies in the design. This feature helps you to get the force list report for the selected
hierarchies.
Use the following option at runtime to generate force list report for the desired instance
hierarchies in the design:
-force_list_hier <list_file>
-force_list_hier

Where, <list_file> is the configuration file. This file allows you to specify the hierarchy
and levels of hierarchy to be dumped in the resultant -force_list output file.
Note:
To use this feature, you must first compile your designs with the -force_list
option.
Following is the syntax of the <list_file> statements:
+/-<instance> <depth>

Verification Continuum™ VCS User Guide 259

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Where,
+<instance>
+<instance>

Fully rooted path name to a Verilog instance. Dumps the forces on the signals in the
instance tree to the report.
<depth> for +<instance>

Specify the level/levels of hierarchy to be dumped. For example, <depth> of 1 means only
the signals in <instance> are dumped. <depth> of 0 means all levels of sub-instances
are dumped.
-<instance>

The forces on signals in the instance tree are filtered out. They are not dumped to the
report.
<depth> for -<instance>

Specify the level/levels of hierarchy to be filtered out. For example, <depth> of 1 means
only the signals in <instance> are filtered out. <depth> of 0 means all levels of sub-
instances are filtered out.

Examples
The following are the examples:
• Example-1: Generating force list report for the desired instance hierarchies
• Example-2: Reporting $deposit value changes
Example-1: Generating force list report for the desired instance hierarchies

Example 20 test.v
module tb();
reg r;
wire oA, oB;
dut dut(r, oA, oB);
initial begin
r = 0;
#10 force [Link] = 1;
#10 force [Link] = 1;
end
endmodule

module dut(input r, output oA, oB);

A instA(r, oA, oB);
endmodule

module A(input r, output oA, oB);

assign oA = r;

Verification Continuum™ VCS User Guide 260

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

B instB(r, oB);
endmodule

module B(input r, output oB);

assign oB = r;
endmodule

Example 21 [Link]
+[Link] 1

Compile test.v as follows:

% vcs -debug_access -sverilog -force_list test.v

Simulation command:
% simv -force_list=uniqueID [Link] -force_list_hier
[Link]

Following is the [Link] output:

VCS Force List
Header Section

Language Forces

ID Target Module File Line

1 [Link] tb test.v 7

Event List Section

---- Time: 10 ----

1 LF ‘b1

Example-2: Reporting $deposit value changes

Example 22 test.v
module mymod(o,i,phi);
output o;
input i,phi;

and(o,i,phi);

initial begin
$deposit(o,1'b1);
end
endmodule

module test;

reg i,phi;

Verification Continuum™ VCS User Guide 261

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

wire o;

mymod m1(o,i,phi);

initial begin
i=0; phi=0;
#5 i=1;
#5; phi=1;
#5; phi=0;
#10; $finish;
end
endmodule

Compile test.v as follows:

% vcs -debug_access -sverilog -force_list test.v

Simulation command:
% simv -force_list=uniqueID [Link]

Following is the [Link] output:

VCS Force List
Header Section

Language Forces

ID Target Module File Line

1 test.m1.o mymod prim.v 8

Event List Section

---- Time: 0 ----

1 LD 'b1

Displaying Different ID for Each Verilog Force

The force list feature provides separate IDs for each source of a Verilog force, release, or
deposit in the Language Forces section of the force list file.

Enhanced Force List Report

The enhanced force list report looks as follows:
• VCS displays a unique ID for each Verilog force in the Language Forces section.
• The unique ID is used in the Event List Section.

Verification Continuum™ VCS User Guide 262

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Following is the sample report:

VCS Force List
Header Section

Language Forces

ID Target Module File Line

test.a test t.v 3

test.a test t.v 4

Event List Section

---- Time: 0 ----

---- Time: 1 ----
1 LF 'b0
---- Time: 2 ----
2 LF 'b1

Use Model
To enable this feature, perform the following:
• At compile-time, use the following options:
◦ The -force_list option. This option enables the force list feature
◦ Debug capability -debug_access+r+cbk or higher
◦ The -sverilog option, otherwise old Verilog style force may be missing
• At runtime, use the following option to enable the new enhancements:
-force_list=uniqueID
-force_list=uniqueID

Displaying Source Information for VHDL Forces

The force list report is enhanced to mark the VHDL force/release with the file name and
line number of the corresponding force/release assignment statement. For example, see
the following report:
VCS Force List
Header Section

VHDL Language Forces

ID Target File Line

1 /top/et/S_1
2 /top/et/S_1

Verification Continuum™ VCS User Guide 263

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

3 /top/et/S_2

Event List Section

---- Time: 0 ----

1 LF 'b1
---- Time: 1 ----
2 LR
---- Time: 2 ----
3 LF 2
---- Time: 3 ----
4 LR
5 LF 32

Use Model
To enable this feature, perform the following:
• At compile-time, use the following options:
◦ The -force_list option. This option enables the force list feature
◦ Debug capability -debug_access+r+cbk or higher
◦ The -sverilog option, otherwise old Verilog style force may be missing
• At runtime, use the following option to enable the new enhancements:
-force_list=uniqueID
-force_list=uniqueID

Displaying Source Information for External Forces

VCS provides detailed information about the origin of an external force, release, or deposit
in the force list report.
The force list report is enhanced to mark an external force, release, or deposit with the
file name and line number of the corresponding force, release, or deposit assignment
statement.
Table 12 describes this enhancement in detail.
Table 12 Displaying Source Information for External Forces

Origin of the force, Description

release, or deposit

1 hdl_xmr_force, Force, release, or deposit that originates from hdl_xmr* procedures

hdl_xmr_release, is marked with the Verilog/VHDL source file name and line number
hdl_xmr calling the hdl_xmr procedure, if one exists.

Verification Continuum™ VCS User Guide 264

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Table 12 Displaying Source Information for External Forces (Continued)

Origin of the force, Description

release, or deposit

Force, release, or deposit that originates from sourcing a file with

the UCLI Tcl do command is marked with the TCL source file name
and line number. There is no file name and line number information
when the Tcl source command is used.

2 UCLI Force, release, or deposit originating from an interactive command

is marked as INTERACTIVE, and no file name and line number is
given.

Force, release, or deposit originating from mhpi_ucliTclExec is

marked as UCLI_FROM_MHPI, and no file name and line number is
given.

No file name and line number is given for the force command
executed in the UCLI stop -command script.

Third-party tools and other PLI applications are typically not run
from a design file name/line number. Third-party tools are run from
a VPI/VHPI synchronization callback. Therefore, there is no design
file name/line number information.

3 VPI, VHPI, MHPI, VCSD, Force, release, or deposit originating from the user-defined system
and Third-party tools function activation is marked with the design file name and line
number for the activation, if one exists.

If a force, release, or deposit originates from a simulation callback,

no file name and line number is given.

Enhanced Force List Report

Following is the sample report:
External Forces

ID Target

1 [Link]
2 [Link]
3 [Link].vcc_ts

Following is the output when the UCLI force is used:

[Link]

Verification Continuum™ VCS User Guide 265

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Following is the output when the VPI force is used in a third-party PLI called with the
$user_pli user-defined task in the testbench.v Verilog file:

[Link] testbench.v, 11

Use Model
To enable this feature, perform the following:
• At compile-time, use the following options:
◦ The -force_list option. This option enables the force list feature
◦ Debug capability -debug_access+r+cbk or higher
◦ The -sverilog option, otherwise old Verilog style force may be missing
• At runtime, use the following option to enable the new enhancements:
-force_list=uniqueID
-force_list=uniqueID

Viewing Force Information in Interactive Debug Mode

VCS allows you to view all active forces at the current simulation time in interactive debug
mode using the find_forces UCLI command.

Use model
Compile the design as follows:
% vcs -debug_access+r+cbk -sverilog -force_list test.v

Run the simulation as follows:

% simv -force_list -ucli

Use the find_forces UCLI command at the ucli prompt. This command reports the
current active forces in the design or scope.
ucli% find_forces <option_name>

Following is the use model of the find_forces UCLI command:

find_forces <nid>

find_forces -scope <scope_name> [-level <level_number>] [-file

<file_name>]

Verification Continuum™ VCS User Guide 266

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

Where,
• nid is a nested identifier (hierarchical path name).
• -scope allows you to specify the full scope path name to find force.
• -level allows you to specify the level of hierarchy to do force search. Default value is
0 (search all sub-scopes).

• -file <file_name>: Specify a file to report the result. By default, report is generated
as UCLI output.
Examples:
• ucli% find_forces -scope tb
Searches tb scope only
• ucli% find_forces -scope tb/DUT/* -level 3
Searches DUT and additional 2 levels under DUT
• ucli% find_forces tb/DUT/clk_i_node
Specifies whether the node clk_i_node is forced
• ucli% find_forces -scope tb/DUT/* -level 0 [Link]
Searches all levels under DUT and writes to [Link].
Note:
◦ You must specify a signal name when -scope is not specified. Otherwise, VCS
issues an error message.
◦ A force is reported only if it is forced. If the force start time (for example, using
hdl_xmr_force) is beyond current time, but the actual command was already
executed, it will not be reported in the force list.

Example
Consider the following files:

Example 23 [Link]
module test;
reg [0:3] a;
reg clk;
wire aa,b;
assign aa=a[1];

dut dt (clk,aa,b);
initial

Verification Continuum™ VCS User Guide 267

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

begin
clk=0;
a = 4'b1010;
#10 a= 4'b1110;
#10 force a[0] =1'bX;
#10 release a[0];
#100 $finish;
end
initial begin
forever #1 clk = ~clk;
end
endmodule
module top;
reg [0:3] a;
reg clk;
wire aa,b;
assign aa=a[1];

dut dt (clk,aa,b);
endmodule
module dut(input clk,a,output b);
assign b = a;

endmodule

Example 24 [Link]
run 1
catch {find_forces -scope test} err
puts $err
force test.a 3'b1010
catch {find_forces -scope test -level 0} err
puts $err
run 1
force [Link].a 3'b0011
run 1
catch {find_forces -scope [Link] -file [Link]} err
puts $err
exec cat [Link]
run
quit

Execute the following commands:

%vcs -debug_access+r+cbk+f -sverilog -force_list [Link]

%./simv -force_list -ucli -i [Link]

Output:
ucli% run 1
1 s
ucli% catch {find_forces -scope test} err
0

Verification Continuum™ VCS User Guide 268

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

ucli% puts $err

ucli% force test.a 3'b1010

ucli% catch {find_forces -scope test -level 0} err
0
ucli% puts $err
{test.a[0]} freeze 'b1 Design
{test.a} freeze 'b1010 External

ucli% run 1
2 s
ucli% force [Link].a 3'b0011
ucli% run 1
3 s
ucli% catch {find_forces -scope [Link] -file [Link]} err
0
ucli% puts $err
{[Link].a} freeze 'b1 External
Result successfully reported to: [Link]
ucli% exec cat [Link]
{[Link].a} freeze 'b1 External
ucli% run

Reporting $deposit Value Changes

The -force_list option dumps only the $deposit value change events in the force list
report. It does not dump regular value changes caused by the design activity. A unique ID
is assigned for each $deposit statement in the force list [Link] feature helps you to
Identify value changes caused by $deposit.

Limitations
• This feature is not supported for pure VHDL designs.
• The -R option is not supported.
• Language forces from encrypted code are not reported.
• Nodes that are forced by more than one line in the Verilog source are not analyzed for
the exact line that is driving the value. If a force/release event occurs on the node, VCS
records the event, but not the file and line that exactly caused the event. VCS only lists
the possible force drivers, not the exact driver.
• Force on entire mda is not supported for an event list capture. For example, consider
the following code:
logic [1:0] foo [1:0][1:0] = 8’b11111111;
logic [1:0] baz [1:0][1:0];
initial begin

Verification Continuum™ VCS User Guide 269

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Reporting Forces/Injections in a Simulation

#1 force baz = foo; //force entire mda baz

end

VCS does not record this value change on the force at #1, it just captures the header
information for this force. VCS provides a comment in the header saying that value
changes for this force event will not be recorded.
• Values in the event list for the language forces represent the current value at the
time of the force, and not necessarily the forced value. This becomes an issue when
multiple force statements influence one or more but not all of the same bits in the part
selects and full vectors. As an example of this limitation, consider the following code:
logic foo [0:3] = 4’b0000;
Initial begin
#0 force foo[0] = 1; //creates force list header item 1 for the
force on bit select of foo[0].
#1 force foo[0:2] = ‘b111; //creates force list header item2 for the
force on part select foo[0:2], note bit 0.
#1 release foo[0:2] = ‘b000; //creates a new header entry using the
same id as the above line.
#1 foo[0:2] = ‘b000; //reset bits
#1 force foo[0] = 1; //creates a new header entry using same id as
the first force on this node.
end

Following is the output report for the above code. Comments are added to the following
report for illustration purposes only.
Language Forces
ID Target Module File Line
1 [Link][0] top test.v 11
2 [Link][0:2] top test.v 12
2 [Link][0:2] top test.v 17
1 [Link][0] top test.v 18
Event List Section
---- Time: 0 ----
2 LF ‘b100 //at time 0, force occurs on id 1, so values for bits
1 and 2 on id2 are not forced.
1 LF ‘b1 //this is the real force at this time, but forcelist
cannot know whether the force is from id 1 or id 2.
---- Time: 1 ----
2 LF ‘b111 // this is the real force, no issue here because all
values are forced.
1 LF ‘b1
---- Time: 2 ----
2 LR // release fires, this is ok.
---- Time: 4 ----
2 LF ‘b100 //similar to time 0, bits 1 and 2 are not forced but
reported.
1 LF ‘b1 //this is the real force.

Verification Continuum™ VCS User Guide 270

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Key Runtime Features

Key runtime features includes:
• Overriding Generics at Runtime
• Passing Values from the Runtime Command Line
• Saving and Restarting the Simulation
• Specifying Long Time Before Stopping the Simulation
• Using -f Runtime Option
• Resolving RTL Simulation Races in Mixed HDL Designs
• Resolving RTL Simulation Races in Verilog Designs
• Preventing Time 0 Race Conditions
• Supporting Simulation Executable to Return Non-Zero Value on Error Results
• Supporting Memory Load and Dump Task Verbosity

Overriding Generics at Runtime

Using the -g, -gen or -generics runtime option, you can change the following types of
VHDL generics at runtime:
• Any generic that stays in VHDL and is not propagated directly or indirectly into Verilog
• Any generic that does not shape the tree or define the widths of ports through mixed
HDL boundary
• Generics like delays, file names, and timing checks control
The use model is as follows:
% simv -g generics_file

The -g, -gen or -generics option takes a command file as an argument. You must
specify the hierarchical path of the generic and a new value to override. A sample
generics_file is as follows:
% cat generics_file

assign 1 /TOP/LEN
assign "[Link]" /TOP/G1/vhdl1/FILE_NAME
assign (4 ns) /TOP/G1/VHDL1/delay
assign 16 /TOP/width
assign 4 /TOP/add_width

Verification Continuum™ VCS User Guide 271

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Use Model
Analysis
% vlogan [vlogan_options] file1.v file2.v
% vhdlan [vhdlan_options] [Link] [Link] [Link]

Note:
Specify the VHDL bottommost entity first, then move up in order.
Elaboration
% vcs [vcs_options] top_cfg/entity/config

Simulation
% simv [sim_options] -g [Link]

Example
Consider the following example:
--[Link]---

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_signed.All;

ENTITY spmem IS
generic ( add_width : integer := 3;
delay : time := 2 ns;
file_name : string := "[Link]";
WIDTH : integer := 8);

PORT (
clk : IN std_logic;
reset : IN std_logic;
add : IN std_logic_vector(add_width -1 downto 0);
Data_In : IN std_logic_vector(WIDTH -1 DOWNTO 0);
Data_Out : OUT std_logic_vector(WIDTH -1 DOWNTO 0);
WR : IN std_logic);
END spmem;

ARCHITECTURE spmem_v1 OF spmem IS

TYPE data_array IS ARRAY (integer range <>) OF

std_logic_vector(7 DOWNTO 0);

SIGNAL data : data_array(0 to (2** add_width) );

BEGIN -- spmem_v1

PROCESS (clk, reset)

Verification Continuum™ VCS User Guide 272

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

BEGIN -- PROCESS

IF (reset = '0') THEN

data_out <= (OTHERS => 'Z');

ELSIF clk'event AND clk = '1' THEN

IF (WR = '0') THEN
data(conv_integer(add)) <= data_in after delay;
END IF;
data_out <= data(conv_integer(add));
END IF;

END PROCESS;

END spmem_v1;

--[Link]---

library IEEE;
use IEEE.std_logic_1164.all;

entity top is
generic ( add_width : integer := 3;
delay : time := 2 ns;
file_name : string := "[Link]";
WIDTH : integer := 8;
LEN : integer := 1 );

PORT (
clk : IN std_logic;
reset : IN std_logic;
add : IN std_logic_vector(add_width -1 downto 0);
Data_In : IN std_logic_vector(WIDTH -1 DOWNTO 0);
Data_Out : OUT std_logic_vector(WIDTH -1 DOWNTO 0);
WR : IN std_logic);
END top;

architecture top_arch of top is

component spmem
generic ( add_width : integer := 3;
delay : time := 2 ns;
file_name : string := "[Link]";
WIDTH : integer := 8);
PORT (
clk : IN std_logic;
reset : IN std_logic;
add : IN std_logic_vector(add_width -1 downto 0);
data_In : IN std_logic_vector(WIDTH -1 DOWNTO 0);
data_Out : OUT std_logic_vector(WIDTH -1 DOWNTO 0);
WR : IN std_logic);
END component;

begin -- top_arch

Verification Continuum™ VCS User Guide 273

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

G1: if LEN=1 generate

INST1 : spmem generic map (add_width,delay,file_name,width)
port map (clk,reset,add,data_in,data_out,wr);
end generate G1;

G2: if LEN=2 generate

INST2 : spmem generic map (add_width,delay,file_name,width)
port map (clk,reset,add,data_in,data_out,wr);
end generate G2;

end top_arch;

In the above example, you can override the generics at runtime. The use model is as
follows:
Analysis
% vhdlan spec_mem.vhd [Link]

Note:
Specify the VHDL bottommost entity first, then move up in order.
Elaboration
% vcs TOP

Simulation
% simv -g generics_file

Following is the generics_file:

assign 1 /TOP/LEN
assign "[Link]" /TOP/G1/INST1/FILE_NAME
assign (4 ns) /TOP/G1/INST1/delay
assign 16 /TOP/width
assign 4 /TOP/add_width

As per generics_file, VCS overrides the generics LEN, width, and add_width in the
[Link] file, and FILE_NAME and delay generics defined in the [Link] file.

Passing Values from the Runtime Command Line

The $value$plusargs system function can pass a value to a signal from the simv runtime
$value$plusargs[value$plusargs]
$value$plusargs

command line using plusarg. The syntax is as follows:

= $value$plusargs(" ", );

Verification Continuum™ VCS User Guide 274

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

The plusarg_format argument specifies a user-defined runtime option for passing a value
to the specified signal. It specifies the text of the option and the radix of the value that you
pass to the signal.
The following code example contains this system function:
module valueplusargs;
reg [31:0] r1;
integer status;

initial
begin
$monitor("r1=%0d at %0t",r1,$time);
#1 r1=0;
#1 status=$value$plusargs("r1=%d",r1);
end
endmodule

If you enter the following simv command line:

% simv +r1=10

The $monitor system task displays the following:

r1=x at 0
r1=0 at 1
r1=10 at 2

Using -f Runtime Option

You can use the -f <filename.f> runtime option to specify user-defined arguments in a
file. These arguments are those that you specify on the simv command line. This option
works for all mixed HDL designs, pure VHDL, and pure Verilog designs.

Limitations
• Nested file inclusion is not supported
• Environment expansion is not supported
• Complex string options are not supported
• You cannot specify multiple options on the same line. This is illustrated in the below
example:
%simv -f <filename.f>
filename.f

-ova_report
-lca

Verification Continuum™ VCS User Guide 275

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

-cm_name foo
...
...

Saving and Restarting the Simulation

You can use the $save and $restart system tasks to save the checkpoints of the
simulation at arbitrary times. The resulting checkpoint files can be executed at a later time,
causing simulation to resume at the point immediately following the save.
Note:
• Save and restart using the $save and $restart system tasks is for the designs having
both DUT and the testbench in Verilog HDL. You can also use the UCLI save and
restart feature. For more information, see Unified Command-line Interface User
Guide.
• You can restore the gzipped snapshots using system tasks or the UCLI restore
command.
• The files which are created and closed using Verilog system tasks before saving the
simulation state are also retained while restoring the simulation. To enable this feature,
pass the -save_closed_files option at runtime during saving the simulation state.
Benefits of save and restart include:
• Regular checkpoints for interactively debugging problems found during long batch runs
• Use of plusargs to start action such as $dumpvars on restart
• Execution of common simulation system tasks such as $reset just once in a
regression
Restrictions of save and restart include:
• Requires extra Verilog code to manage save and restart
• Must duplicate start-up code if handling plusargs on restart
• File I/O suspend and resume in PLI applications must be given special consideration
• Simprofile flow is not supported
• Not supported with the +vcs+loopreport option

Verification Continuum™ VCS User Guide 276

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

• The -covg_disable_cg runtime option takes effect during the beginning of simulation.
Therefore, if you run the option only during the restore step or remove the option only
from the restore step, it does not have any effect.
• During restore, you must pass the same coverage options that are passed during
saving the simulation state. The changed coverage options do not take effect during
the restore step.

Save and Restart Example

Example 25 illustrates the basic functionality of save and restart.
The $save call is scheduled and executed as the last event in the current time. Therefore,
the events delayed with #1 are the first to be processed upon restart.

Example 25 Save and Restart Example

% cat test.v
module simple_restart;
initial begin
#10
$display("one");
$save("[Link]");
$display("two");
#1 // make the following occur at restart
$display("three");
#10
$display("four");
end
endmodule

Now compile the example source file:

% vcs test.v

Run the simulation:

% simv

VCS displays the following:

one
two
$save: Creating [Link] from current state of simv...
three
four

To restart the simulation from the state saved in the check file, enter:
% simv -r [Link]

Verification Continuum™ VCS User Guide 277

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

VCS displays the following:

Restart of a saved simulation
three
four

Save and Restart File I/O

VCS remembers the files you opened via $fopen and reopens them when you restart the
simulation. If no file with the old file name exists, VCS opens a new file with the old file
name. If a file exists having the same name and length at the time you saved the old file,
then VCS appends further output to that file. Otherwise, VCS attempts to open a file with a
file name equal to the old file name plus the suffix .N. If a file with this name already exists,
VCS exits with an error message.
If your simulation contains PLI routines that do file I/O, the routines must detect both the
save and restart events, closing and reopening files as needed. You can detect save and
restart calls using misctf callbacks with reasons reason_save and reason_restart.

When running the saved checkpoint file, be sure to rename it so that further $save calls
do not overwrite the binary you are running. There is no way from within the Verilog source
code to determine if you are in a previously saved and restarted simulation, therefore, you
cannot suppress the $save calls in a restarted binary.

Save and Restart With Runtime Options

If your simulation behavior depends on the existence of runtime plusargs or any other
runtime action (such as reading a vector file), be aware that the restarted simulation uses
the values from the original run unless you add special code to process runtime events
after the restart action. Depending on the complexity of your environment and your usage
of the save and restart feature, this can be a significant task.
For example, if you load a memory image with $readmemb at the beginning of the
simulation and want to be able to restart from a checkpoint with a different memory
image, you must add Verilog code to load the memory image after every $save call.
This ensures that at the beginning of any restart the correct memory image is loaded
before simulation begins. A reasonable way to manage this is to create a task to handle
processing arguments, and call this task at the start of execution, and after each save.
The following example illustrates this in greater detail. The first run optimizes simulation
speed by omitting the +dump option. If a bug is found, the latest checkpoint file is run with
the +dump option to enable signal dumping.
// file test.v
module dumpvars();
task processargs;
begin
if ($test$plusargs("dump")) begin
$dumpvars;

Verification Continuum™ VCS User Guide 278

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

end
end
end task
//normal start comes here
initial begin
processargs;
end
// checkpoint every 1000 time units
always
#1000 begin
// save some old restarts
$system("mv -f save.1 save.2");
$system("mv -f save save.1");
$save("save");
#1 processargs;
end
endmodule
// The design itself here
module top();
.....
endmodule

Specifying Long Time Before Stopping the Simulation

You can use the +vcs+stop+time runtime option to specify the simulation time when
VCS stops the simulation. This works if the time value you specify is less than 232 or
4,294,967,296. You can also use the +vcs+finish+time runtime option to specify when
VCS either stops or ends the simulation, provided that the time value is less than 232.
For time values greater than 232, you must follow a special procedure that uses two
arguments with the +vcs+stop or +vcs+finish runtime options, as shown below:
+vcs+stop+<first argument>+<second argument>

+vcs+finish+<first argument>+<second argument>

This procedure is as follows:

For example, if you want a time value of 10,000,000,000 (10 billion):
1. Divide the large time value by 232.
In this example:

2. Narrow down this quotient to the nearest whole number. This whole number is the
second argument.
In this example, you would narrow down to 2.

Verification Continuum™ VCS User Guide 279

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

3. Multiply 232 with the second argument (that is, 2), and then subtract the obtained
result from the large time value (that is, subtract 2 X 232 from the large time value), as
shown below:
10,000,000,000-(2*4,294,967,296)=(1,410,065,408)
This difference is the first argument.
You now have the first and second argument. Therefore, in this example, to specify
stopping simulation at time 10,000,00,000, you would enter the following runtime option:
+vcs+stop+1410065408+2

VCS can do some of this work for you by using the following source code:
module wide_time;
time wide;
initial
begin
wide = 64’d10_000_000_000;
$display(“Hi=%0d, Lo=%0d”, wide[63:32], wide[31:0]);
end
endmodule

VCS displays the following:

Hi=2,Lo=1410065408

Preventing Time 0 Race Conditions

At simulation time 0, VCS executes always blocks where any of the signals in the event
control expression that follows the always keyword (the sensitivity list) initializes at time 0.
For example, consider the following code:
module top;
reg rst;
wire w1,w2;
initial
rst=1;
bottom bottom1 (rst,w1,w2);
endmodule

module bottom (rst,q1,q2);

output q1,q2;
input rst;
reg rq1,rq2;

assign q1=rq1;
assign q2=rq2;

always @ rst

Verification Continuum™ VCS User Guide 280

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

begin
rq1=1’b0;
rq2=1’b0;
$display(“This always block executed!”);
end
endmodule

With other Verilog simulators, there are two possibilities at time 0:

• The simulator executes the initial block first, initializing reg rst, then the simulator
evaluates the event control sensitivity list for the always block and executes the
always block because the simulator initialized rst.

• The simulator evaluates the event control sensitivity list for the always block, and so
far, reg rst has not changed its value during this time step. Therefore, the simulator
does not execute the always block. Then the simulator executes the initial block
and initializes rst. When this occurs, the simulator does not re-evaluate the event
control sensitivity list for the always block.

Resolving RTL Simulation Races in Mixed HDL Designs

A race between data and clock signal occurs when both signals change at the same
simulation time and both are input to the same sequential element (flip-flop or latch).
However, it is expected that the clock arrives before data and samples the previous settled
value of data. When clock arrives after or at the same cycle as data, the new value of data
is sampled which causes incorrect results.
VCS helps resolve these RTL simulation races in mixed VHDL-Verilog designs. The
following section illustrates how to resolve race conditions.

Recommended Approach to Resolve Race Conditions

It is recommended to use the following methodologies to resolve the race conditions:
1. Use the VHDL -sn=+rdr race detector option and try to manually fix the RTL code. If it
-sn=+rdr

is not possible to modify the RTL code, use the race detector output as an input to the
configuration file. For the use model, see section Using the VHDL Race Detector.
2. Use the -sn=+rfx automatic option to accelerate the scalars (clocks) over the
-sn=+rfx

boundary and insert NBA delays only for the data drivers that directly provide stimulus
to the Verilog boundary. For information about the using the configuration file, see
section Using the Race Configuration File.

Verification Continuum™ VCS User Guide 281

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Using the VHDL Race Detector

If a simulation race is already detected, delay the data to fix the race. To resolve the
simulation race using the VHDL race detector, execute the following steps:
1. To insert delays, modify the VHDL code and add “after 0.0 sec” on drivers for
data signals reported as racy. The delay can be a non-zero delay or a non-blocking
assignment zero delay specified as follows in the source code:
signal <= data after 0.0 sec;

This is legal VHDL and works with any tool. However, VCS recognizes it as a VHDL
Non-Blocking Assignment (NBA). To enable VHDL NBA assignment, use the vcs -sn=
-sn=+nbavhd

+nbavhd option.

2. Enable the race detector using the -sn=+rdr option, as shown in the following
-sn=+rdr

command:
% vcs -sn=+rdr; simv

This option generates the snps_vcs_vhdl_race.log file, which can be used as an

input to the configuration file to insert NBA delays on those signals.
Using the Race Configuration File
To enable the configuration input, use the -sn=+nbacfg option with
snps_vcs_vhdl_nba.cfg as an input file. The configuration input file contains a list of
signals for which NBA delays are inserted.
The configuration file with the NBA delays can be generated by the race detector using the
following commands:
% vcs -sn=+rdr; simv
% cp snps_vcs_vhdl_race.log snps_vcs_vhdl_nba.cfg
% vcs -sn=+nbacfg; simv

OR
The configuration file with the NBA delays can be generated by the automatic race
solution along with the log file (-sn=+rfx+nbalog). This can be used as a starting list and
enables you to tune the configuration list:
% vcs -sn=+rfx+nbalog; simv
% cp snps_vcs_vhdl_nba.log snps_vcs_vhdl_nba.cfg
% vcs -sn=+nbacfg; simv

Resolving RTL Simulation Races in Verilog Designs

A race between data and clock signal occurs when both signals change at the same
simulation time and both are input to the same sequential element (flip-flop). However, it is

Verification Continuum™ VCS User Guide 282

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

expected that the clock arrives before data and samples the previous settled value of data.
When clock arrives after or at the same cycle as data, the new value of data is sampled
which causes incorrect results.
VCS helps resolve these RTL simulation races in Verilog design. The following section
illustrates how to resolve race conditions.

Recommended Approach to Resolve Race Conditions

It is recommended to use the Verilog -deraceclockdata option to enable the clock-data
resolution for your entire design. For more information, see section Using Clock-Data
Resolution.
Using Clock-Data Resolution
Using clock-data resolution ensures that the previous value of the data is always sampled.
This significantly improves the verification productivity. There is no simulation mismatch
due to races on flops while migrating to a new release or modifying options that are
provided to the VCS command line.
Use Model
To enable the clock-data resolution for your entire design, use the Verilog -
-deraceclockdata option

deraceclockdata option.
% vcs -deraceclockdata <other vcs options>

By default, the -deraceclockdata option samples memory up to 8 MB. You can use the
-deraceclockdata=fullmem option to remove the restriction on the memory size.

Example
Consider the following test case:
module dff(q, d, clk, clr);
output q;
input d, clk, clr;
reg q;

always @(posedge clk ,negedge clr) begin

if(!clr)
q <= 1'b0;
else
q <= d;
end
endmodule

//=====================top module========================
module top(clk, d, clr, out);
input clk, d, clr;
output out;

Verification Continuum™ VCS User Guide 283

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

wire clk2;
wire q1;

dff div2(clk2, ~clk2, clk, clr);

dff f1(q1, d, clk, clr);
dff f2(out, q1, clk2, clr);
endmodule

//=========================testbench======================
module tb;
reg clk;
reg clr;
reg d;

wire dout;
top t1(clk,d,clr,dout);
initial begin
clk = 1'b0;
d = 1'b0;
clr <= 1'b0;

fork
forever clk = #5 ~clk;
#25 d = 1'b1;
#45 d = 1'b0;
#9 clr <= 1'b1;
join_none

#70 $finish();
end
endmodule

This example has three flops. For f1 flop, the clock and the data changes at the same time
in the blocking assignment region. For f2 flop, both clock and data are changing in the
NBA region.

Verification Continuum™ VCS User Guide 284

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

D Q D Q
d q1 out
(BA driven ) f1 (NBA driven ) f2
RST RST
clr clr

div2 clk2
(NBA driven )

Clk
(BA driven)

Compile and run the test case using the following command line:
% vcs -sverilog -deraceclockdata test.v
% simv

To compile the test case with FSDB dumping enabled:

• Enable the FSDB dumping by calling the $fsdbDumpvars dumping task in the initial
block of the tb module.
• Use the following command line:
% vcs -sverilog -deraceclockdata test.v -debug_access
-debug_region+cell

Note:
You must set the VERDI_HOME environment variable for FSDB dumping.
Import the design and load the generated FSDB file into the Verdi platform. The following
waveform is generated:

Verification Continuum™ VCS User Guide 285

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Old data is getting sampled when clock data is arriving at

the same time.

As shown in the waveform, it is able to consistently sample the clock first using the
-deraceclockdata option. Therefore, it picks up the previous value of the data.

Limitations
The feature has the following limitations:
• The feature is supported for inferred flops in Verilog only.
• Process blocks containing following constructs are ignored:
◦ Call to impure function
◦ Having immediate assertions inside
◦ Dynamic variables
◦ System Task Calls other than $display and $monitor
• Flops modeled using both blocking assignment region and non-blocking assignment
region (in same process) are not supported.
• UDPs with synchronous control are not supported.

Verification Continuum™ VCS User Guide 286

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Supporting Simulation Executable to Return Non-Zero Value on

Error Results
Simulation executable generated by VCS returns non-zero value in case of errors, fatal
errors, and assertion failures.
The simulation executable return values on errors, fatal errors, and assertion values are:
• 0 (no indication)
• 1 (as in runtime crash or system crash)
• 2 (error)
• 3 (fatal)
The possible scenarios and return error value for the scenarios are listed in the following
table:
Table 13 List of Scenarios and Return Error Values

Scenario Return Error Value

$fatal/UVM_FATAL/OVM_FATAL/VMM_FATAL 3

$error/UVM_ERROR/ OVM_ERROR/ VMM_ERROR/ Errors 2

promoted from warning messages to errors

NLP ERROR 2

Assertion failure Verilog 2

$warning /UVM_WARNING/ OVM_WARNING/ 0

VMM_WARNING

NLP WARNING 0

Unique/priority RT warnings 0

-xzcheck 0

Note:
The -assert quiet and -assert quiet1 runtime options cannot override the
exit status in case of assertion failures. The exit status value still must be value
2 in case of assertion failures.

Verification Continuum™ VCS User Guide 287

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Use of -error runtime option generates non-zero return values in case

of errors, fatal errors, as well as in case of errors resulting from warning
messages.
If the messages are suppressed using the-error runtime option, non-zero
return values are not generated.
If a simulation has several errors, fatal errors, and/or assertion failures, the
most severe status must be returned. For example, if simulation has both
$error and $fatal messages, the returned status must be of value 3 as in
case of $fatal scenario.

Use Model
The following is the use model for this feature:
• Compile time
The compile time is same as the previous use model. There is no change needed.
• Runtime
% simv -exitstatus
-exitstatus

% echo $status

This returns a value based on the type of exit

Limitation
Following is the limitation of this feature:
• VMM is not supported.

Supporting Memory Load and Dump Task Verbosity

If you use the -diag sys_task_mem compile-time option, $writememh, $writememb,
-diag sys_task_mem

$readmemh and $readmemb system tasks get into a verbose mode and displays the
following information:
• Full path of the file being written by $writememh and $writememb and being read by
$readmemh and $readmemb, such as /foo/bar/filename.

• The full hierarchical instance path of the module from where $writememh, $writememb,
$readmemh, and $readmemb is invoked, such as soc.a1.b1.c1.my_module_instance.
All instances are reported.
• The name of the module template from where it is displayed, such as my_module.
• The full path to the file that includes the module that contains the $writememh,
$writememb, $readmemh, and $readmemb, such as /baz/qux/my_module.vs.

Verification Continuum™ VCS User Guide 288

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

Syntax:
$writememh ( filename , memory_name [ , start_addr [ ,
$writememh

finish_addr ] ] ) ;

$writememb ( filename , memory_name [ , start_addr [ ,

$writememb

finish_addr ] ] ) ;

The system tasks $writememh and $writememb dump memory array contents to files that
are readable by $readmemh and $readmemb respectively.
$readmemh ( mem_name , start_address , finish_address , string { ,
$readmemh

string } ) ;

$readmemb ( mem_name , start_address , finish_address , string { ,

$readmemb

string } ) ;

The system tasks $readmemh and $readmemb load data into memory mem_name from a
character string.
The $readmemh and $readmemb system tasks take memory data values and addresses
as string literal arguments. These strings take the same format as the strings that appear
in the input files and are passed as arguments to $readmemh and $readmemb. The
start_address and finish_address indicate the bounds for the data to be stored in the
memory.

Use Model
The following is the use model to support memory load and dump task verbosity:
%vcs -diag sys_task_mem
-diag sys_task_mem

The following examples illustrate the usage of $writemem and $readmem system tasks:

Example 26 Example to illustrate $writemem system task

//test.v
module test;
reg [31:0] mem[0:11];

initial begin
$writememh("./[Link]", mem);
end
endmodule

Run the example using the following commands:

% vcs test.v -diag sys_task_mem
% simv

Verification Continuum™ VCS User Guide 289

V-2023.12
 Feedback
Chapter 5: Simulating the Design
Key Runtime Features

It generates the following output:

Note-[STASK_WMEM] Encountered Memory Write Task
/home/user/task/test.v, 5
At module test, Instance test
Writing to file /home/user/task/[Link].

Example 27 Example to illustrate $readmem system task

//test.v
module test;
reg [31:0] mem[0:11];

initial begin
$readmemh("./[Link]", mem);
end
endmodule

Run the example using the following commands:

% vcs test.v -diag sys_task_mem
% simv

It generates the following output:

Note-[STASK_RMEM] Encountered Memory Read Task
/home/user/task/test.v, 5
At module test, Instance test
Reading from file /home/user/task/[Link].

Verification Continuum™ VCS User Guide 290

V-2023.12