ModelSim® SE User's Manual

Software Version 10.7

© 1991-2017 Mentor Graphics Corporation

All rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.

Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.

MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: mentor.com/trademarks.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.

Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

 Table of Contents

Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Operational Structure and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Basic Steps for Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Files and Map Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
What is a Library? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Mapping the Logical Work to the Physical Work Directory . . . . . . . . . . . . . . . . . . . . . 63
Step 1 — Create Work and Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 2 — Compile the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Step 3 — Optimize the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 4— Load the Design for Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 5 — Simulate the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 6 — Debug the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
General Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Command Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Startup Variable Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Here-Document Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I/O Redirection Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Basic Command Line Editing and Navigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Supported Commands for Command Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Batch Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Saving Batch Mode Simulation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Redirecting Output With vsim -batch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Capturing Raw stdout in C/C++ Batch Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . 74
Simulator Control Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Default stdout Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Tool Statistics Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Definition of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Standards Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Deprecated Features, Commands, and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Chapter 2
Protecting Your Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Encryption Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Creating Encryption Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Protection Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
The `include Compiler Directive (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Compiling with +protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
The Runtime Encryption Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Language-Specific Usage Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

ModelSim® SE User's Manual, v10.7 3

 Table of Contents

Usage Models for Protecting Verilog Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Delivering IP Code with Undefined Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Delivering IP Code with User-Defined Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Usage Models for Protecting VHDL Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using the vhencrypt Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Proprietary Source Code Encryption Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using Proprietary Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Protecting Source Code Using -nodebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Encryption Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Encryption and Encoding Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
How Encryption Envelopes Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Using Public Encryption Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Using the Mentor Graphics Public Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Chapter 3
Optimizing Designs with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
The -O Optimization Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Inlined Modules and the Implications of Coverage Settings . . . . . . . . . . . . . . . . . . . . . . . 126
Preservation of Object Visibility for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Conflicts in Accessibility When Using Both +acc and +noacc . . . . . . . . . . . . . . . . . . . . . 129
Negation Arguments and Resolution with vopt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Priorities for Resolving Conflicting Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using an External File to Control Visibility Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating Specialized Designs for Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . 132
Increase Visibility to Retain Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Optimization of Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Preoptimizing Regions of Your Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Simulating Designs with Multiple Test Benches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Extracting Visibility Requirements for PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Using Configurations with Preoptimized Verilog Design Units . . . . . . . . . . . . . . . . . . . . 137
Using Configurations with Preoptimized VHDL Design Units . . . . . . . . . . . . . . . . . . . . . 138
Resolving Preoptimized Design Unit Loading Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Alternate Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating Locked Libraries for Multiple-User Simulation Environments . . . . . . . . . . . . . . 142
Optimizing Liberty Cell Libraries for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Preserving Design Visibility with the Learn Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Controlling Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Optimization Considerations for Verilog Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Design Object Visibility for Designs with PLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Optimization on Designs Containing SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Reports for Gate-Level Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Optimization of Precompiled Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Event Order and Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Timing Checks in Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

4 ModelSim® SE User's Manual, v10.7

Table of Contents

Chapter 4
Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
What are the Benefits of Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Project Conversion Between Simulator Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Getting Started with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Open a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Simulate a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
The Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Creating a Simulation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Organizing Projects with Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Adding a Project Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Set File Properties and Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
File Compilation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Convert Pathnames to Softnames for Location Mapping. . . . . . . . . . . . . . . . . . . . . . . . . 170
Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Access Projects from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Chapter 5
Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Design Library Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Design Unit Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Working Library Versus Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Working with Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Creating a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Library Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Library Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Map a Logical Name to a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Mapping a Library with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Mapping a Library from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Manual Mapping of the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Move a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Setting Up Libraries for Group Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Verilog Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Library Search Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Handling Sub-Modules with the Same Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
The LibrarySearchPath Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VHDL Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Predefined Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Alternate IEEE Libraries Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Regenerating Your Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Importing FPGA Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

ModelSim® SE User's Manual, v10.7 5

 Table of Contents

Protect Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Chapter 6
VHDL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Basic VHDL Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Compilation and Simulation of VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Creating a Design Library for VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Compilation of a VHDL Design—the vcom Command . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Simulation of a VHDL Design—the vsim Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Usage Characteristics and Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Differences Between Supported Versions of the VHDL Standard. . . . . . . . . . . . . . . . . . . 199
Naming Behavior of VHDL for Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Foreign Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Simulator Resolution Limit for VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Default Binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Delta Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
The TextIO Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Syntax for File Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
STD_INPUT and STD_OUTPUT Within ModelSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
TextIO Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Alternative Input/Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
The TEXTIO Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Input Stimulus to a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
VITAL Usage and Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VITAL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VITAL 1995 and 2000 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VITAL Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Compiling and Simulating with Accelerated VITAL Packages . . . . . . . . . . . . . . . . . . . . . 216
Compiler Options for VITAL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
VHDL Utilities Package (util) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Modeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Examples of Different Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Effects on Performance by Canceling Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . 231
VHDL Access Object Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Terminology and Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
VHDL Access Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Default Behavior—Logging and Debugging Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Logging and Debugging Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
The examine and describe Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Chapter 7
Verilog and SystemVerilog Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Standards, Nomenclature, and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Supported Variations in Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
for Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Naming Macros with Integers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Basic Verilog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

6 ModelSim® SE User's Manual, v10.7

Table of Contents

Verilog Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Creating a Working Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Invoking the Verilog Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Verilog Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Parsing SystemVerilog Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Recognizing SystemVerilog Files by File Name Extension . . . . . . . . . . . . . . . . . . . . . . 248
Initializing enum Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Library Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
SystemVerilog Multi-File Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Declarations in Compilation Unit Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Macro Definitions and Compiler Directives in Compilation Unit Scope . . . . . . . . . . . . 254
Verilog-XL Compatible Compiler Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Arguments Supporting Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Verilog-XL uselib Compiler Directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Verilog Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Configurations and the Library Named work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Verilog Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Name Visibility in Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Initializing Registers and Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Initialization Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Initializing with Specific Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 264
Initializing with Specific Values — Enabled During Optimization. . . . . . . . . . . . . . . . . 264
Initializing with Random Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 264
Initializing with Random Values — Enabled During Optimization . . . . . . . . . . . . . . . . 265
Recording Initialization Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Verilog Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Simulator Resolution Limit (Verilog). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Modules Without Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Multiple Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Choosing the Resolution for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Event Ordering in Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Event Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Controlling Event Queues with Blocking or Non-Blocking Assignments. . . . . . . . . . . . 272
Debugging Event Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Hazard Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Hazard Detection and Optimization Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Signal Segmentation Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
vsim Arguments Related to Timing Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Commands Supporting Negative Timing Check Limits . . . . . . . . . . . . . . . . . . . . . . . . . 279
Negative Timing Constraint Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Using Delayed Inputs for Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Force and Release Statements in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Verilog-XL Compatible Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Using Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Tcl and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Cell Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
SDF Timing Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

ModelSim® SE User's Manual, v10.7 7

 Table of Contents

Delay Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Delay Modes and the Verilog Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Distributed Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Path Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Unit Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Zero Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Approximating Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
SystemVerilog System Tasks and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
IEEE Std 1800-2012 System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using the $typename Data Query Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Using the $coverage_* System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Using the $coverage_save System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Using the $clog2 Math Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Simulator-Specific System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
$coverage_save_mti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
$get_initial_random_seed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
$messagelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
$psprintf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
$sdf_done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
$stacktrace() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
$wlfdumpvars() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Task and Function Names Without Round Braces ‘()’. . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Verilog-XL Compatible System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Supported Tasks and Functions Mentioned in IEEE Std 1364 . . . . . . . . . . . . . . . . . . . . 321
Supported Tasks and Functions Not Described in IEEE Std 1364 . . . . . . . . . . . . . . . . . 321
Extensions to Supported System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Unsupported Verilog-XL System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
String Class Methods for Matching Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
IEEE Std 1364 Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Compiler Directives for vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Verilog-XL Compatible Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Sparse Memory Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Manually Marking Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Automatically Enabling Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Combining Automatic and Manual Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Priority of Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Determining Which Memories Were Implemented as Sparse . . . . . . . . . . . . . . . . . . . . . . 334
Initializing Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Limitations of Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Unmatched Virtual Interface Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Verilog PLI and SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Standards, Nomenclature, and Conventions for VPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Extensions to SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
SystemVerilog Class Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Enabling Class Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
The Class Instance Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Obtaining the CIID with the examine Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

8 ModelSim® SE User's Manual, v10.7

Table of Contents

Obtaining the CIID With a System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Logging Class Types and Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Working with Class Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Authoritative and Descriptive Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Finding the Class Type Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Viewing Class Types in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Working with Class Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
The Class Instances Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Viewing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
The Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
The Call Stack Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Working with Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Class Path Expression Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Adding a Class Path Expression to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Class Path Expression Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Casting a Class Variable to a Specific Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Class Objects vs Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Disabling Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Conditional Breakpoints in Dynamic Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Stepping Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
The Run Until Here Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Class Instance Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Class Instance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
The classinfo Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Class Instance Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Default Garbage Collector Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Changing the Garbage Collector Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Running the Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Preparing Your Simulation for OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
OVM-Aware Debugging Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Locating Blocking Calls in the OVM Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Finding Matching Get and Set Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
OVM-Aware Debug Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Globals Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Hierarchy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Components Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Sequence Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Chapter 8
SystemC Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Supported Platforms and Compiler Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Building gcc with Custom Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Usage Flow for SystemC-Only Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

ModelSim® SE User's Manual, v10.7 9

 Table of Contents

Recommendations for using sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Simulating with sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Checkpoint and Restore in a SystemC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Creating Shared Object Files for SystemC Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Binding to Verilog or SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Limitations of Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Distributing SystemC IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Compiling SystemC Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Creating a Design Library for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Exporting All Top-Level SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Invoking the SystemC Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Distributed sccom Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Compiling Optimized and/or Debug Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Specifying an Alternate g++ Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Verifying Compiler Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Maintaining Portability Between OSCI and the Simulator . . . . . . . . . . . . . . . . . . . . . . . . 397
Using sccom in Addition to the Raw C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Rules for sccom Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Rules for Using Raw g++ to Compile Non-SystemC C/C++ Code . . . . . . . . . . . . . . . . . 399
Incremental Compilation (Compile of Changed Files Only) . . . . . . . . . . . . . . . . . . . . . . . 400
Issues with C++ Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Templatized SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Organizing Templatized Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Generating SystemC Verification Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
SCV Extensions for User-specified Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Structures and Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Mentor Dynamic Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Named Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Constrained Randomization of the Data Type for Standard Vectors . . . . . . . . . . . . . . . . 411
Randomly Sized Fixed-Max Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Linking the Compiled Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Simulation of SystemC Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Debugging the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Viewable SystemC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Waveform Compare with SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Debugging Source-Level Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Setting Constructor/Destructor Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Setting BPs with Cdebug Init Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Setting BPs with Automated Constructor Breakpoint Flow. . . . . . . . . . . . . . . . . . . . . . . 421
Using Instance Based Breakpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Viewing SystemC Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
SystemC Object and Type Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Support for Globals and Statics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Support for Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
SystemC Dynamic Module Array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Viewing FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Viewing SystemC Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

10 ModelSim® SE User's Manual, v10.7

Table of Contents

Properly Recognizing Derived Module Class Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Custom Debugging of SystemC Channels and Variables . . . . . . . . . . . . . . . . . . . . . . . . . 431
Modifying SystemC Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Converting sc_main() to a Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Replacing sc_start() Function with Run Command and Options . . . . . . . . . . . . . . . . . . . . 436
Removing Calls to sc_initialize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Code Modification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Differences Between the Simulator and OSCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
OSCI 2.3.1 Feature Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Support for OSCI TLM Library in SystemC-2.3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Features Not Supported in SystemC-2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Backwards Compatibility Issues with SystemC-2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
OSCI 2.2 Feature Implementation Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Support for OSCI TLM Library in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Phase Callback in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Accessing Command-Line Arguments in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
sc_stop Behavior in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Construction Parameters for SystemC Types in 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Troubleshooting SystemC Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Unexplained Behaviors During Loading or Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Errors During Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

Chapter 9
Mixed-Language Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Basic Mixed-Language Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Different Compilers with Common Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Hierarchical References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Access Limitations in Mixed-Language Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
The SystemVerilog bind Construct in Mixed-Language Designs . . . . . . . . . . . . . . . . . . . . . 460
Syntax of bind Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Allowed Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Hierarchical References to a VHDL Object from a Verilog/SystemVerilog Scope. . . . . . 462
Mapping of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Optimization with SystemVerilog Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Port Mapping with VHDL and Verilog Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . 464
VHDL Instance Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Limitations to Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Optimizing Mixed Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Simulator Resolution Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Runtime Modeling Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Hierarchical References to SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Hierarchical References In Mixed HDL and SystemC Designs. . . . . . . . . . . . . . . . . . . . . 473
Signal Connections Between Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . . 474
Mapping Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Verilog and SystemVerilog to VHDL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
VHDL To Verilog and SystemVerilog Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings . . . . . . . . . . . 487

ModelSim® SE User's Manual, v10.7 11

 Table of Contents

VHDL and SystemC Signal Interaction and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

VHDL Instantiating Verilog or SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Verilog/SystemVerilog Instantiation Criteria Within VHDL. . . . . . . . . . . . . . . . . . . . . . . 504
Component Declaration for VHDL Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . 504
vgencomp Component Declaration when VHDL Instantiates Verilog . . . . . . . . . . . . . . . 505
Modules with Bidirectional Pass Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Modules with Unnamed Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Verilog or SystemVerilog Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
VHDL Instantiation Criteria Within Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Entity and Architecture Names and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Named Port Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Generic Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Sharing User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Using a Common VHDL Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Using a Common SystemVerilog Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
SystemC Instantiating Verilog or SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Verilog Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
SystemC Foreign Module (Verilog) Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Parameter Support for SystemC Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Verilog or SystemVerilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
SystemC Instantiation Criteria for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Exporting SystemC Modules for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Parameter Support for Verilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
VHDL Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
SystemC Foreign Module (VHDL) Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Generic Support for SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
VHDL Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
SystemC Instantiation Criteria for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Component Declaration for VHDL Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . 537
vgencomp Component Declaration when VHDL Instantiates SystemC . . . . . . . . . . . . . . 538
Exporting SystemC Modules for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Passing Generics From VHDL or Verilog Down to SystemC . . . . . . . . . . . . . . . . . . . . . . 539
SystemC Procedural Interface to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
SystemC DPI Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
SystemC Import Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Calling SystemVerilog Export Tasks / Functions from SystemC . . . . . . . . . . . . . . . . . . . 548
SystemC Data Type Support in SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
SystemC Function Prototype Header File (sc_dpiheader.h). . . . . . . . . . . . . . . . . . . . . . . . 551
Support for Multiple SystemVerilog Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
SystemC DPI Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

Chapter 10
Advanced Simulation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Checkpointing and Restoring Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Checkpoint File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

12 ModelSim® SE User's Manual, v10.7

Table of Contents

Checkpoint Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

Controlling Checkpoint File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
The Difference Between Checkpoint/Restore and Restart . . . . . . . . . . . . . . . . . . . . . . . . . 557
Using Macros with Restart and Checkpoint/Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Checkpointing Foreign C Code That Works with Heap Memory . . . . . . . . . . . . . . . . . . . 558
Checkpointing a Running Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Simulating with an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Why an Elaboration File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Creating an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Loading an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Modifying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Using PLI or FLI Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Chapter 11
Recording and Viewing Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Transaction Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
What is a Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
About the Source Code for Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
About Transaction Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Viewing Transactions in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Transaction Viewing Commonalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Transaction Objects in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Viewing Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Retroactive Recording and Transaction Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Selecting Transactions or Streams in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . 578
Customizing Transaction Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Customizing Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Customizing Appearance of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Viewing a Transaction in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Viewing a Transaction in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Debugging Transactions with Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Transactions in Designs with Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Transaction Recording Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Transaction Recording Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Names of Streams and Substreams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Stream Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Transaction UIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Attribute Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Multiple Uses of the Same Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Anonymous Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Relationship in Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
The Life Cycle of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Transaction Handles and Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Transaction Recording Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Recording Transactions in Verilog and VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Verilog Recorded Transaction Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Valid Verilog Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Recording Transactions in SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

ModelSim® SE User's Manual, v10.7 13

 Table of Contents

Initializing SCV and Creating WLF Database Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602

Transaction Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Recording SCV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
SCV API Code Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
SCV Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
CLI Debugging Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Verilog and VHDL API System Task Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
add_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
add_color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
add_relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
begin_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
create_transaction_stream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
delete_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
end_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
free_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

Chapter 12
Verifying Designs with
Questa Verification IP Library Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
What is Questa Verification IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
What is a Questa Verification IP Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Questa Verification IP Transaction Viewing in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Questa Verification IP Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Arrays in Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Viewing Questa Verification IP Transactions in the Wave Window . . . . . . . . . . . . . . . . . 629
What the Colors Mean in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Appearance of Concurrent Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . 632
Questa Verification IP Arrays in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Color and Questa Verification IP Arrays in Wave Window. . . . . . . . . . . . . . . . . . . . . . . . 634
Viewing Questa Verification IP Transactions in Objects Window . . . . . . . . . . . . . . . . . . 634
Viewing Questa Verification IP Transactions in List Window . . . . . . . . . . . . . . . . . . . . . 636
Questa Verification IP Transaction Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Debugging Using Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Questa Verification IP Transaction Details in Transaction View Window . . . . . . . . . . . . 641
The Transaction View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
The Transaction Stream Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Updating Contents of the Transaction Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Chapter 13
Recording Simulation Results With Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Saving a Simulation to a WLF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Saving at Intervals with Dataset Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Saving Memories to the WLF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
WLF File Parameter Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Limiting the WLF File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Opening Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Dataset Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Structure Window Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

14 ModelSim® SE User's Manual, v10.7

Table of Contents

Managing Multiple Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Managing Multiple Datasets in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Managing Multiple Datasets from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Restricting the Dataset Prefix Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Collapsing Time and Delta Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Virtual Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Virtual Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Virtual Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Virtual Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Virtual Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

Chapter 14
Waveform Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Wave Window Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Objects You Can View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Adding Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Inserting Signals in a Specific Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Adding Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Editing Cursor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Enable Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Additional Mouse Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Expanded Time in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Expanded Time Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 682
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . 685
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Menu Selections for Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Toolbar Selections for Expanded Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Command Selection of Expanded Time Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanding and Collapsing Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Zooming the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Zooming with the Menu, Toolbar and Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Saving Zoom Range and Scroll Position with Bookmarks. . . . . . . . . . . . . . . . . . . . . . . . . 691
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Searching in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Searching for Values or Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

ModelSim® SE User's Manual, v10.7 15

 Table of Contents

Using the Expression Builder for Expression Searches . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Saving an Expression to a Tcl Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Searching for a Particular Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Evaluating Only on Clock Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Filtering the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Formatting the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Setting Wave Window Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Hiding/Showing Path Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Double-Click Behavior in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Setting the Timeline to Count Clock Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Formatting Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Changing Radix (base) for the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Wave Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Creating a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Grouping Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Adding a Group of Contributing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Grouping Signals with the add wave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Grouping Signals with a Keyboard Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Deleting or Ungrouping a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Adding Items to an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Removing Items from an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Composite Signals or Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Creating Composite Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Saving the Window Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Exporting Waveforms from the Wave window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Exporting the Wave Window as a Bitmap Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Saving Waveform Sections for Later Viewing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Saving Waveforms Between Two Cursors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Viewing Saved Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Working With Multiple Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Viewing SystemVerilog Class Objects and Class Path Expressions . . . . . . . . . . . . . . . . . . . 722
Viewing System Verilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Adding Virtual Interface References to the Wave Window. . . . . . . . . . . . . . . . . . . . . . . 726
Combining Objects into Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Extracting a Bus Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Using the Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Miscellaneous Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Examining Waveform Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736

16 ModelSim® SE User's Manual, v10.7

Table of Contents

Creating and Managing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Setting Signal Breakpoints with the when Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Setting Signal Breakpoints with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Modifying Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Setting File-Line Breakpoints Using the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Setting File-Line Breakpoints Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Modifying a File-Line Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Waveform Compare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Mixed-Language Waveform Compare Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Using the Comparison Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Comparison Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Comparison Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Setting Up a Comparison with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Reference Dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Test Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Adding Signals, Regions, and Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Adding Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Adding Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Adding Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Continuous Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Viewing Differences in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Annotating Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Compare Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Viewing Differences in Textual Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Saving and Reloading Comparison Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Comparing Hierarchical and Flattened Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

Chapter 15
Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Schematic Window Usage Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Live Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Two Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Features of the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Common Tasks for Schematic Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Adding Objects to the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Display a Structural Overview in the Full View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Exploring the Schematic Connectivity of the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Investigating Connectivity Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

ModelSim® SE User's Manual, v10.7 17

 Table of Contents

Limiting the Schematic Display of Readers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

Controlling the Schematic Display of Redundant Buffers and Inverters . . . . . . . . . . . . . 775
Tracking Your Path Through the Design with Highlighting . . . . . . . . . . . . . . . . . . . . . . 776
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . 777
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . 787
Finding Objects by Name in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Annotating with Sticky Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Automatically Tracing All Paths Between Two Nets in the Schematic Window . . . . . . . 791
Symbol Mapping in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Schematic Window Graphic Interface FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
What Can I View in the Schematic Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 797
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
How do I Configure Schematic Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

Chapter 16
Debugging with the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Dataflow Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Dataflow Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Live Simulation Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Post-Simulation Debug Flow Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Create the Post-Sim Debug Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Use the Post-Simulation Debug Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Common Tasks for Dataflow Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Add Objects to the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Exploring the Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Analyzing a Scalar Connected to a Wide Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Control the Display of Readers and Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Controlling the Display of Redundant Buffers and Inverters. . . . . . . . . . . . . . . . . . . . . . 817
Track Your Path Through the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Explore Designs with the Embedded Wave Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Tracing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Tracing the Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Finding Objects by Name in the Dataflow Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Automatically Tracing All Paths Between Two Nets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Dataflow Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Symbol Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
User-Defined Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Current vs. Post-Simulation Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Dataflow Window Graphic Interface Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
What Can I View in the Dataflow Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830

18 ModelSim® SE User's Manual, v10.7

Table of Contents

How is the Dataflow Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . . 830

How Can I Print and Save the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Save a .eps File and Printing the Dataflow Display from UNIX . . . . . . . . . . . . . . . . . . . 832
Print from the Dataflow Display on Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . 832
Configure Page Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
How Do I Configure Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834

Chapter 17
Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Opening Source Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Navigating Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Data and Objects in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Object Values and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Search for Source Code Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Searching for One Instance of a String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Searching for All Instances of a String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Searching for the Original Declaration of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Debugging and Textual Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Hyperlinked Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Code Coverage Data in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Coverage Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Using the Modify Breakpoints Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Deleting Individual Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Deleting Groups of Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Setting a Breakpoint For a Specific Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Setting a Breakpoint For a Specified Value of Any Instance. . . . . . . . . . . . . . . . . . . . . . 860
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Source Window Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Setting and Removing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Source Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

Chapter 18
Using Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Creating a Database for Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Initiating Causality Traceback from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 866

ModelSim® SE User's Manual, v10.7 19

 Table of Contents

Using the find drivers Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866

Command Line Options for Setting Report Destination . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Command Line Options for Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Performing Post-simulation Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Initiating Causality Traceback from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Trace to the First Sequential Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Initiating the Trace from the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Initiating the Trace from the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Initiating the Trace from the Objects or Schematics Windows . . . . . . . . . . . . . . . . . . . . 874
Tracing to the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Tracing to the Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Tracing to the Root Cause of an ‘X’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Finding All Possible Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Tracing from a Specific Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
Multiple Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Causality Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Causality Traceback Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888

Chapter 19
Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Overview of Code Coverage Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Language and Datatype Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Usage Flow for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Specifying Coverage Types for Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Union of Coverage Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Rules for Applying Coverage with cover and nocover. . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Enabling Simulation for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Code Coverage in the UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Code Coverage in the Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Displaying Coverage Summary in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . 907
Understanding Unexpected Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Statement Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Branch Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Branch Coverage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Case and Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
AllFalse Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Missing Branches in VHDL and Clock Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Condition and Expression Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Cond and Exp Coverage Collection Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Reporting Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
FEC Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
FEC Report Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
FEC and Short-circuiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Exclusions and FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925

20 ModelSim® SE User's Manual, v10.7

Table of Contents

Legacy FEC Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926

VHDL Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Verilog/SV Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Toggle Coverage and Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
VHDL Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Verilog/SV Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Toggle Ports Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Viewing Toggle Coverage Data in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . 931
Understanding Toggle Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Specifying Toggle Coverage Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Toggle Using the Main Window Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Limiting Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
What Objects can be Excluded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude True or False Branch of if Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude Implicit (AllFalse) Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude AllFalse Branches in Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Exclude Any/All Coverage Data in a Single File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Exclude Individual Metrics with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Supported Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Verilog vs. VHDL Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
coverage on and coverage off Pragma Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Pragma Usage and Nesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Adaptive Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
The Adaptive Exclusion DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Generating an Adaptive Exclusion DO File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Toggle Exclusion Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Two Methods for Excluding Toggles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Exclude Nodes from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Toggle Pragma Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Exclude Bus Bits from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Re-enable Toggles Excluded with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Exclude enum Signals from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
FSM Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Exclude FSM with coverage exclude Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
FSM Pragma Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Code Coverage Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Coverconstructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Code Coverage Mode Interaction with Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . 977
Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981

ModelSim® SE User's Manual, v10.7 21

 Table of Contents

Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981

Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Branch Coverage and Numbering of Items in Coverage Report . . . . . . . . . . . . . . . . . . . 983
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
The toggle report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Using toggle report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Port Collapsing and Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Ordering of Toggle Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Report Using the Coverage Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
XML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Notes on Coverage and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Interaction of Optimization and Coverage Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992

Chapter 20
Finite State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
FSM Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
FSM Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
FSM Multi-State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Collecting FSM Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Reporting Coverage Metrics for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Viewing FSM Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
FSM Coverage Metrics Available in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
Advanced Command Arguments for FSMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Recognized FSM Note. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
FSM Recognition Info Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
FSM Coverage Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004

Chapter 21
Verification with Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Overview of Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Assertion Coding Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Using Assert Directive Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
SystemVerilog Bind Construct. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Processing Assume Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Configuring Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Enabling Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
Enabling Memory and Performance Profiling Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Configuring Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Setting Break Severity for Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Enabling/Disabling Assertion Failure and Pass Logging. . . . . . . . . . . . . . . . . . . . . . . . . 1018
Setting Assertion Failure Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Setting Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Changing the Default Configuration of Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . 1021

22 ModelSim® SE User's Manual, v10.7

Table of Contents

Other Configuration Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023

Simulating Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Maintaining Assertion Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Analyzing Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Viewing Assertions in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Viewing Cover Directives in the Cover Directives Window . . . . . . . . . . . . . . . . . . . . . . 1032
Viewing Memory Profile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Viewing Assertions and Cover Directives in the Wave Window . . . . . . . . . . . . . . . . . . 1034
Utilizing GUI Display Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Comparing Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Saving Metrics to the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Excluding Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Creating Assertion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Using PSL Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Using PSL Directives in Procedural Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
Common PSL Assertions Coding Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
Embedding Assertions in Your Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
HDL Code Inside PSL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
Writing PSL Assertions in an External File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Sharing a Single .psl File Between VHDL and Verilog Models . . . . . . . . . . . . . . . . . . . 1054
Inserting VHDL library and use Clauses in External PSL Assertion Files . . . . . . . . . . . 1054
PSL Clocked and Unclocked Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Using PSL ended() in HDL Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Compiling and Simulating PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Compiling Embedded PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Compiling an External PSL Assertions File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Applying PSL Assertions During Elaboration/Optimization . . . . . . . . . . . . . . . . . . . . . . 1061
Making Changes to PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
PSL Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Using SVA Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Assertions and Action Blocks in SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Deferred Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
SystemVerilog Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
SVA Usage Flow for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Using -assertdebug to Debug with Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1067
Viewing Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Enabling ATV Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Enabling and Disabling ATV Recording During Simulation . . . . . . . . . . . . . . . . . . . . . . . 1069
Saving Assertion and Cover Directive Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window . . . . . . 1072
Using the Assertion Active Thread Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Viewing Assertion Threads in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Navigating Inside an ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Expression Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Thread Viewer Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Local Variables Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Design Objects Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Actions in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Find Sub-Expression That Caused Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083

ModelSim® SE User's Manual, v10.7 23

 Table of Contents

Viewing Multiple Clock Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084

Expanding and Contracting Expression Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Highlighting a Thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Hovering the Mouse for Thread and Directive Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
Annotating Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088

Chapter 22
Verification with Functional Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Functional Coverage Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Functional Coverage Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Guidelines for Functional Coverage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Controlling Functional Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Functional Coverage Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Predefined Coverage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Predefined Coverage System Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
SystemVerilog Functional Coverage Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
IEEE Std 1800-2009 Option Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Example of Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
SystemVerilog 2009 option.per_instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
SystemVerilog 2009 type_option.merge_instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
SystemVerilog 2009 option.get_inst_coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Legacy Behavior and Option Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Type-Based Coverage With Constructor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Default Type-Based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Projected Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Functional Coverage Statistics in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Viewing Functional Coverage Statistics in the Covergroups Window . . . . . . . . . . . . . . . 1107
Functional Coverage Aggregation in Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Reporting on Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Creating Text Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Creating HTML Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Covergroup Bin Reporting and Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Filtering Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
Reporting Via the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Excluding Functional Coverage from the GUI and Reports. . . . . . . . . . . . . . . . . . . . . . . . 1117
Sample Commands for Excluding Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Transitive Cross Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Hiding Covergroup Instances from GUI and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Assertion/Cover Directive Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Covergroup Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Covergroup in a Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Canonical String Representation for Coverpoint Bin Value . . . . . . . . . . . . . . . . . . . . . . . 1122
Saving Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Saving For All Simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Saving For The Current Simulation Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Loading a Functional Coverage Database into Simulation . . . . . . . . . . . . . . . . . . . . . . . . 1126
Loading Behavior Related to option.per_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127

24 ModelSim® SE User's Manual, v10.7

Table of Contents

Chapter 23
Verification with Constrained
Random Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Verification Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Building Constrained Random Test Benches on SystemVerilog Classes . . . . . . . . . . . . . . . 1131
Generating New Random Values with randomize(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132
Attributes Of Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Syntax and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Size Constraints for Random Dynamic Arrays with randomize() . . . . . . . . . . . . . . . . . . 1134
Debugging randomize() Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134
Specifying a Solver Engine with solveengine Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Tuning the ACT Solver Engine with solveactretrycount Attribute . . . . . . . . . . . . . . . . . 1137
Inheriting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Examining Solver Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138
Setting Compatibility with a Previous Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
Seeding the Random Number Generator (RNG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140

Chapter 24
Coverage and Verification Management in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Coverage and Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
Calculation of Total Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Where to Find Coverage Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage and Simulator Use Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Coverage View Mode and the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Running Tests and Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Collecting and Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Name Selection for Test UCDB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Understanding Stored Test Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Test Attribute Records in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Predefined Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Managing Test Data in UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Matching the Paths of Corresponding Coverage Items . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Merging Using a Master UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Information Not Perfectly Preserved During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Multiple Test Data Records with Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Merging and Source Code Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170

ModelSim® SE User's Manual, v10.7 25

 Table of Contents

Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172

About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
Viewing and Analyzing Verification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Storing User Attributes in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Customizing the Column Views in Verification Windows . . . . . . . . . . . . . . . . . . . . . . . . 1185
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Ranking Coverage Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Group Ranking of Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188
Viewing Ranked Test Data in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Merged Results vs. Rank Report Coverage: Why They Can Differ . . . . . . . . . . . . . . . . 1190
Ranking Most Effective Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Test-Associated vs. Iterative Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
The Generation of Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Generating ASCII Text Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Generating HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Enabling Test Lists, Source Code and Coverage Details . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Canonical Toggle Nodes in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
option or type_option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Viewing Bins Hit by Certain Tests in HTML Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
HTML Generation for Large Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Generating Coverage Exclusion Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1201
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Filtered Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Setting up or Modifying a Filter for UCDB Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Applying a Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204
Filtering Results by User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Analysis for Late-stage ECO Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207

Chapter 25
C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Supported Platforms and gdb Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Setting Up C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Running C Debug from a DO File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Stepping in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Quitting C Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214
Finding Function Entry Points with Auto Find bp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Identifying All Registered Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216

26 ModelSim® SE User's Manual, v10.7

Table of Contents

Enabling Auto Step Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216

Auto Find bp Versus Auto Step Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218
Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
Debugging Functions During Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
FLI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
PLI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
VPI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Completing Design Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Debugging Functions when Quitting Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
C Debug Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223

Chapter 26
Profiling Performance and Memory Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227
Introducing Performance and Memory Profiling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Memory Allocation Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Profile Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Getting Started with the Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Handling Large Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Enabling the Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Collecting Memory Allocation and Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Turning Profiling Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Running the Profiler on Windows with FLI/PLI/VPI Code . . . . . . . . . . . . . . . . . . . . . . . . 1232
Interpreting Profiler Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1232
Viewing Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
Ranked Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
Design Units Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Viewing Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Integration with Source Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Analyzing C Code Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Searching Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Reporting Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Enabling or Disabling Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Levels of Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Coarse-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Fine-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Enabling Fine-Grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Consolidated Memory Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Opening the Capacity Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Displaying Capacity Data in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Writing a Text-Based Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Reporting Capacity Analysis Data From a UCDB File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Examining Memory Usage for Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . 1254

ModelSim® SE User's Manual, v10.7 27

 Table of Contents

Chapter 27
Signal Spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
Signal Spy Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Signal Spy Formatting Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Signal Spy Supported Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Signal Spy Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
disable_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
enable_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
init_signal_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266
init_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
signal_force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
signal_release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278

Chapter 28
Monitoring Simulations with JobSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1281
Basic JobSpy Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Set JOBSPY_DAEMON Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Start the JobSpy Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Set the JOBSPY_DAEMON Variable as a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Running JobSpy from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Simulation Commands Available to JobSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Running the JobSpy GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Starting Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Invoking Simulation Commands in Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Interactive Job Session Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287
View Commands and Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
Viewing Results During Active Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Viewing Waveforms from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Licensing and Job Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Checkpointing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Connecting to Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
Checkpointing with Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Configuring LSF for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Configuring Flowtracer for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Configuring Grid Engine for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292

Chapter 29
Generating Stimulus with Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
Getting Started with the Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Using Waveform Editor Prior to Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298
Accessing the Create Pattern Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Creating Waveforms with Wave Create Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Editing Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Stretching and Moving Edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304

28 ModelSim® SE User's Manual, v10.7

Table of Contents

Simulating Directly from Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304

Exporting Waveforms to a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Driving Simulation with the Saved Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
Signal Mapping and Importing EVCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
Using Waveform Compare with Created Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
Saving the Waveform Editor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307

Chapter 30
Standard Delay Format (SDF) Timing Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Specifying SDF Files for Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
Instance Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
SDF Specification with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Compiling SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312
Simulating with Compiled SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312
VHDL VITAL SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
SDF to VHDL Generic Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Resolving Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Verilog SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316
$sdf_annotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
SDF to Verilog Construct Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319
Retain Delay Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322
Optional Edge Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324
Optional Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Rounded Timing Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
SDF for Mixed VHDL and Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Interconnect Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Specifying the Wrong Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Matching a Single Timing Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Mistaking a Component or Module Name for an Instance Label. . . . . . . . . . . . . . . . . . . . 1329
Forgetting to Specify the Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Reporting Unannotated Specify Path Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330

Chapter 31
Value Change Dump (VCD) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333
Creating a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Four-State VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Extended VCD File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
VCD Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Checkpoint/Restore and Writing VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Using Extended VCD as Stimulus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Simulating with Input Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Replacing Instances with Output Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . 1338
Port Order Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339
VCD Commands and VCD Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340
Using VCD Commands with SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341

ModelSim® SE User's Manual, v10.7 29

 Table of Contents

Compressing Files with VCD Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342

VCD File from Source to Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
VHDL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
VCD Simulator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
VCD to WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Capturing Port Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Resolving Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
Default Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
When force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
Extended Data Type for VHDL (vl_logic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349
Ignoring Strength Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1350

Chapter 32
Tcl and DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1353
Tcl Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354
Tcl References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354
Tcl Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355
If Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
set Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
Command Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Command Separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Multiple-Line Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Evaluation Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1361
Tcl Relational Expression Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1361
Variable Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
ModelSim Replacements for Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
Referencing Simulator State Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Special Considerations for the now Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Reading Variable Values From the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Setting Variable Values for the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366
List Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366
Simulator Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Simulator Tcl Time Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Time Conversion Tcl Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Time Relations Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373
Creating DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373
Using Parameters with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Deleting a File from a .do Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Making Script Parameters Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375
Breakpoint Flow Control in Nested DO files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376
Useful Commands for Handling Breakpoints and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 1378
Error Action in DO File Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379
Using the Tcl Source Command with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379

30 ModelSim® SE User's Manual, v10.7

Table of Contents

The Tcl Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380

The Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
The Chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Tcl Debugger Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
TclPro Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384

Appendix A
modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Organization of the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
AcceptLowerCasePragmaOnly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
AmsStandard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
AssertionCover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
AutoExclusionsDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1431
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432
BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433
BatchTranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
BindAtCompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
BreakOnAssertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
CheckPlusargs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
CheckSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
CodeCoverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
CommandHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442

ModelSim® SE User's Manual, v10.7 31

 Table of Contents

CompilerTempDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
CoverCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
CoverClkOptBuiltins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
CoverExcludeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
CoverOpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
CoverREC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1459
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
CoverThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
CoverWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467
CppOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468
CppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
DefaultLibType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475
DefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
DefaultRestartOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1480
DpiCppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
EnableSVCoverpointExprVariable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
EnumBaseInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488
error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1490
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491

32 ModelSim® SE User's Manual, v10.7

Table of Contents

ExtendedToggleMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
FecEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
FlatLibPageDeletePercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
floatfixlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1500
ForceSigNextIter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
ForceUnsignedIntegerToVHDLInteger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503
FsmResetTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
GCThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
GenerateFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1509
GenerateLoopIterationMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510
GenerateRecursionDepthMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513
GlobalSharedObjectsList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
Hazard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
IgnoreFailure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
IgnoreSVAWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
IgnoreWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
InitOutCompositeParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
IterationLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
LargeObjectSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
MaxReportRhsSVCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
MaxSVCoverpointBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540

ModelSim® SE User's Manual, v10.7 33

 Table of Contents

MaxSVCrossBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
MessageFormatFail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
MessageFormatWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
modelsim_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
MsgLimitCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
MultiFileCompilationUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
NoCaseStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
NoRangeCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
NumericStdNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
OnFinishPendingAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
osvvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
PedanticErrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
RequireConfigForAllDefaultBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589

34 ModelSim® SE User's Manual, v10.7

Table of Contents

RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
Sc22Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
ScMainFinishOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
ScStackSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
Show_Warning1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
Show_Warning2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Show_Warning3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Show_Warning4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
Show_Warning5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
SignalForceFunctionUseDefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
SmartDbgSym. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
SolveACTMaxOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
SolveACTMaxTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
SolveACTRetryCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
SolveBeforeErrorSeverity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
SolveFailDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
SolveFailDebugMaxSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
SolveGraphMaxEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
SolveIgnoreOverflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638

ModelSim® SE User's Manual, v10.7 35

 Table of Contents

SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
StackTraceDepth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
Stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
StdArithNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
sv_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
SVCovergroupGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
SVCovergroupPerInstanceDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
SVCovergroupTypeGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
SVCoverpointAutoBinMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
SVCoverpointWildCardBinValueSizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
ToggleMaxRealValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
ToggleVlogEnumBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
TranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691

36 ModelSim® SE User's Manual, v10.7

Table of Contents

UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
UnattemptedImmediateAssertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
UVMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
VhdlSeparatePduPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
WarnConstantChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
WildcardSizeThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
WildcardSizeThresholdVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
WLFCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
WLFCollapseMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
WLFDeleteOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
WLFFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
WLFOptimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
WLFSimCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
WLFTimeLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
WrapColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
WrapWSColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
Commonly Used modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
Common Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
Hierarchical Library Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Warnings from Arithmetic Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
Restart Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735

ModelSim® SE User's Manual, v10.7 37

 Table of Contents

VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736

Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736

Appendix B
Location Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
Referencing Source Files with Location Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
Using Location Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
Pathname Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
How Location Mapping Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739

Appendix C
Error and Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1741
Message System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Getting More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Message Severity Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Syntax Error Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Suppression of Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
Miscellaneous Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1748
Error Messages from the sccom Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
Enforcing Strict 1076 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753

Appendix D
Questa Verification IP Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757
Accessing 60000 Series Error Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758
Why Series 50000 Errors Occur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
Concepts Involved in the Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
Transaction Types and Time Queue ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
Parents and Children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
Deleted Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
Understanding the ‘Time Queue’ ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
Viewing the Time Queue ID Number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
TQ Id Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
Understanding ‘Parents’ and ‘Children’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
Parent/Child Relationship Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
Understanding Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1774
Generation/Recognition Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775
Understanding Deletions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Deletion Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Understanding Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Activated Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1780
Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1782

38 ModelSim® SE User's Manual, v10.7

Table of Contents

Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1783

Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
Understanding Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
Understanding the Volatile Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
Volatile Clause Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
Understanding Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
Activity Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
Understanding ‘Throw’ and ‘Catch’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Throw and Catch Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Understanding TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
WLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
WLM-connected and TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791

Appendix E
Verilog Interfaces to C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1793
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
GCC Compiler Support for use with C Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
Registering PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
Registering VPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797
Registering DPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799
DPI Use Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
DPI and the vlog Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
Deprecated Legacy DPI Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
When Your DPI Export Function is Not Getting Called . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
Troubleshooting a Missing DPI Import Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
Simplified Import of Library Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
Optimizing DPI Import Call Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
DPI Arguments of Parameterized Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
Making Verilog Function Calls from non-DPI C Models . . . . . . . . . . . . . . . . . . . . . . . . . 1806
Calling C/C++ Functions Defined in PLI Shared Objects from DPI Code . . . . . . . . . . . . 1807
PLI Catalog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
PLI Catalog (PCAT) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
PCAT File for Controlling Access Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
PCAT File with PLI Autocompile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
PLI Catalog File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
PLI Catalog Use Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
Using a PCAT File for Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
Using a PCAT File with PLI Autocompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816
Compiling and Linking C Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
For all UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
Windows Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819
Linux Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820
Compiling and Linking C++ Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
For PLI/VPI only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
Windows Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823
Linux Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824

ModelSim® SE User's Manual, v10.7 39

 Table of Contents

Specifying Application Files to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825

PLI and VPI File Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
DPI File Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
Loading Shared Objects with Global Symbol Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
PLI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
VPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
DPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
The PLI Callback reason Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
The sizetf Callback Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
PLI Object Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
Third Party PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
Support for VHDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
IEEE Std 1364 ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
IEEE Std 1364 TF Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
SystemVerilog DPI Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
Verilog-XL Compatible Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
64-bit Support for PLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
PLI/VPI Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
The Purpose of Tracing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Invoking a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Checkpointing and Interface Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
Debugging Interface Application Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843

Appendix F
System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Files Accessed During Startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Initialization Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1848
Expansion of Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1848
Setting Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849
Creating Environment Variables in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854
Library Mapping with Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
Referencing Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
Removal of Temporary Files (VSOUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856

Appendix G
Third-Party Model Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1857
Synopsys SmartModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Enabling the VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Creating Foreign Architectures with sm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1860
sm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1861
SmartModel Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863
Command Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
SmartModel Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865
Memory Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1867
Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1867
Synopsys Hardware Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1868

40 ModelSim® SE User's Manual, v10.7

Table of Contents

VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869

Hardware Model Interface Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869
hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870
Creating Foreign Architectures with hm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870
hm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1871
Hardware Model Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873
Hardware Model Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1874
Index
Third-Party Information
End-User License Agreement

ModelSim® SE User's Manual, v10.7 41

 Table of Contents

42 ModelSim® SE User's Manual, v10.7

 List of Figures

Figure 1-1. Operational Structure and Flow of ModelSim . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure 1-2. Work Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 1-3. Compiled Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 2-1. Create an Encryption Envelope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 2-2. Encryption Envelope Contains Design Data to be Protected . . . . . . . . . . . . . . . 84
Figure 2-3. Encryption Envelope Contains `include Compiler Directives . . . . . . . . . . . . . . 85
Figure 2-4. Results After Compiling with vlog +protect. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 2-5. Verilog/SystemVerilog Encryption Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 2-6. Delivering IP Code with User-Defined Macros . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 2-7. Delivering IP with `protect Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 4-1. Create Project Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Figure 4-2. Project Window Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure 4-3. Add items to the Project Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure 4-4. Create Project File Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 4-5. Add file to Project Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 4-6. Click Plus Sign to Show Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 4-7. Setting Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Figure 4-8. Grouping Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Figure 4-9. Add Simulation Configuration Dialog Box — Design Tab . . . . . . . . . . . . . . . . 161
Figure 4-10. Structure Window with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 4-11. Project Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 4-12. Add Simulation Configuration Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Figure 4-13. Simulation Configuration in the Project Window. . . . . . . . . . . . . . . . . . . . . . . 165
Figure 4-14. Add Folder Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Figure 4-15. Specifying a Project Folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 4-16. Project Compiler Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 4-17. Specifying File Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Figure 4-18. Project Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure 5-1. Creating a New Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Figure 5-2. The Library Window—Design Unit Information in the Workspace . . . . . . . . . 178
Figure 5-3. Edit Library Mapping Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 5-4. Sub-Modules with the Same Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Figure 5-5. Import Library Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 6-1. VHDL Delta Delay Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Figure 7-1. Fatal Signal Segmentation Violation (SIGSEGV) . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 7-2. Current Process Where Error Occurred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 7-3. Blue Arrow Indicating Where Code Stopped Executing . . . . . . . . . . . . . . . . . . 277
Figure 7-4. Null Values in the Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Figure 7-5. Classes in the Class Tree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Figure 7-6. Class in the Class Graph Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

ModelSim® SE User's Manual, v10.7 43

 List of Figures

Figure 7-7. Classes in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Figure 7-8. The Class Instances Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Figure 7-9. Placing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Figure 7-10. Class Information Popup in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 351
Figure 7-11. Class Viewing in the Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Figure 7-12. Class Path Expressions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 355
Figure 7-13. /top/a Cast as c1 and c1prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Figure 7-14. Casting c1 to c1prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Figure 7-15. Extensions for a Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Figure 7-16. Garbage Collector Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Figure 8-1. SystemC Objects in GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Figure 8-2. Breakpoint in SystemC Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Figure 8-3. Setting the Allow lib step Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Figure 8-4. SystemC Objects and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Figure 8-5. Aggregate Data Displayed in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Figure 11-1. Transaction Anatomy in Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Figure 11-2. Transaction Stream in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Figure 11-3. Viewing Transactions and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Figure 11-4. Concurrent Parallel Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Figure 11-5. Transaction in Wave Window - Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Figure 11-6. Transaction Stream Properties Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Figure 11-7. Transaction-Stream Properties Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Figure 11-8. Transactions in List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Figure 11-9. Transactions in Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Figure 11-10. Recording Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Figure 12-1. Questa Verification IP Transaction at Different Levels of Abstraction . . . . . . 624
Figure 12-2. Arrays in Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Figure 12-3. Questa Verification IP Transactions in Wave Window . . . . . . . . . . . . . . . . . . 631
Figure 12-4. Concurrent Transactions Overlapping in Wave Window . . . . . . . . . . . . . . . . . 633
Figure 12-5. Questa Verification IP Array (2X2) in Wave Window. . . . . . . . . . . . . . . . . . . 633
Figure 12-6. Color of Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Figure 12-7. Questa Verification IP Objects in Objects Window . . . . . . . . . . . . . . . . . . . . . 635
Figure 12-8. Questa Verification IP Objects in List Window . . . . . . . . . . . . . . . . . . . . . . . . 636
Figure 12-9. Viewing Questa Verification IP Relationships . . . . . . . . . . . . . . . . . . . . . . . . . 639
Figure 12-10. Transaction Window - Data Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Figure 12-11. Transaction Window - Relations Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Figure 13-1. Displaying Two Datasets in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 648
Figure 13-2. Dataset Snapshot Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Figure 13-3. Open Dataset Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Figure 13-4. Structure Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Figure 13-5. The Dataset Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Figure 13-6. Virtual Objects Indicated by Orange Diamond. . . . . . . . . . . . . . . . . . . . . . . . . 662
Figure 14-1. The Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Figure 14-2. Insertion Point Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Figure 14-3. Grid and Timeline Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

44 ModelSim® SE User's Manual, v10.7

List of Figures

Figure 14-4. Original Names of Wave Window Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Figure 14-5. Sync All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Figure 14-6. Cursor Linking Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Figure 14-7. Configure Cursor Links Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Figure 14-8. Waveform Pane with Collapsed Event and Delta Time . . . . . . . . . . . . . . . . . . 682
Figure 14-9. Waveform Pane with Expanded Time at a Specific Time . . . . . . . . . . . . . . . . 683
Figure 14-10. Waveform Pane with Event Not Logged . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Figure 14-11. Waveform Pane with Expanded Time Over a Time Range . . . . . . . . . . . . . . 684
Figure 14-12. New Bookmark Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Figure 14-13. Wave Signal Search Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Figure 14-14. Expression Builder Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Figure 14-15. Selecting Signals for Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Figure 14-16. Display Tab of the Wave Window Preferences Dialog Box. . . . . . . . . . . . . . 700
Figure 14-17. Grid and Timeline Tab of Wave Window Preferences Dialog Box . . . . . . . . 702
Figure 14-18. Clock Cycles in Timeline of Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 703
Figure 14-19. Wave Format Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Figure 14-20. Format Tab of Wave Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Figure 14-21. Changing Signal Radix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Figure 14-22. Global Signal Radix Dialog in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 706
Figure 14-23. Separate Signals with Wave Window Dividers . . . . . . . . . . . . . . . . . . . . . . . 707
Figure 14-24. Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Figure 14-25. Wave Groups Denoted by Red Diamond . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Figure 14-26. Contributing Signals Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Figure 14-27. Save Format Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Figure 14-28. Waveform Save Between Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Figure 14-29. Wave Filter Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Figure 14-30. Wave Filter Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Figure 14-31. Adding Class Objects in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . 723
Figure 14-32. Class Information Popup in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 724
Figure 14-33. Virtual Interface Objects Added to Wave Window . . . . . . . . . . . . . . . . . . . . 727
Figure 14-34. Signals Combined to Create Virtual Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Figure 14-35. Wave Extract/Pad Bus Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Figure 14-36. Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Figure 14-37. Virtual Signal Builder Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Figure 14-38. Creating a Virtual Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Figure 14-39. Virtual Signal in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Figure 14-40. Modifying the Breakpoints Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Figure 14-41. Signal Breakpoint Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Figure 14-42. Breakpoints in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Figure 14-43. File Breakpoint Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Figure 14-44. Waveform Comparison Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Figure 14-45. Start Comparison Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Figure 14-46. Compare Tab in the Workspace Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Figure 14-47. Structure Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Figure 14-48. Add Comparison by Region Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752

ModelSim® SE User's Manual, v10.7 45

 List of Figures

Figure 14-49. Comparison Methods Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

Figure 14-50. Adding a Clock for a Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Figure 14-51. Waveform Comparison Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Figure 14-52. Viewing Waveform Differences in the Wave Window . . . . . . . . . . . . . . . . . 756
Figure 14-53. Waveform Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Figure 14-54. Reloading and Redisplaying Compare Differences . . . . . . . . . . . . . . . . . . . . 759
Figure 15-1. Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Figure 15-2. Schematic View Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Figure 15-3. Schematic Add to Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Figure 15-4. Colors Help Identify Architectures, Modules, and Processes. . . . . . . . . . . . . . 768
Figure 15-5. Show Incremental View Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Figure 15-6. Hover Mouse for Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Figure 15-7. Code Preview Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Figure 15-8. The Follow Box in the Full View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Figure 15-9. Left-Pointing Mouse Arrow Indicates Drivers . . . . . . . . . . . . . . . . . . . . . . . . . 773
Figure 15-10. Double-Headed Arrow Indicates Inout with Drivers and Readers . . . . . . . . . 774
Figure 15-11. Change Schematic Preference Value Dialog Box. . . . . . . . . . . . . . . . . . . . . . 775
Figure 15-12. Redundant Buffers and Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Figure 15-13. Highlight Selected Trace with Custom Color . . . . . . . . . . . . . . . . . . . . . . . . . 776
Figure 15-14. Folded Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Figure 15-15. Unfolded Instance Not Showing Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Figure 15-16. Unfolded Instance with All Contents Displayed. . . . . . . . . . . . . . . . . . . . . . . 778
Figure 15-17. Abstract Blocks Identified with Unique Number . . . . . . . . . . . . . . . . . . . . . . 779
Figure 15-18. Wave Viewer Displays Inputs and Outputs of Selected Process . . . . . . . . . . 781
Figure 15-19. Event Traceback Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Figure 15-20. CurrentTime Label in Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Figure 15-21. Enter Current Time Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Figure 15-22. Signals for Selected Process in Embedded Wave Viewer . . . . . . . . . . . . . . . 784
Figure 15-23. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Figure 15-24. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . 785
Figure 15-25. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Figure 15-26. Active Driver Path Details for the q Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Figure 15-27. Click Schematic Window Button to View Path Details . . . . . . . . . . . . . . . . . 786
Figure 15-28. Path to Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Figure 15-29. Unknown States Shown as Red Lines in Wave Window . . . . . . . . . . . . . . . . 788
Figure 15-30. Event Traceback Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Figure 15-31. Find Toolbar for Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Figure 15-32. Adding a Sticky Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Figure 15-33. Schematic: Point-to-Point Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Figure 15-34. The Print Postscript Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Figure 15-35. The Schematic Page Setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Figure 15-36. Configuring Incremental View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Figure 15-37. Display Options in Right-Click Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Figure 15-38. Keyboard Shortcut Table in the Schematic Window . . . . . . . . . . . . . . . . . . . 803
Figure 16-1. The Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806

46 ModelSim® SE User's Manual, v10.7

List of Figures

Figure 16-2. Dataflow Debugging Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808

Figure 16-3. Dot Indicates Input in Process Sensitivity List . . . . . . . . . . . . . . . . . . . . . . . . . 812
Figure 16-4. CurrentTime Label in Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Figure 16-5. Controlling Display of Redundant Buffers and Inverters . . . . . . . . . . . . . . . . 817
Figure 16-6. Green Highlighting Shows Your Path Through the Design . . . . . . . . . . . . . . . 817
Figure 16-7. Highlight Selected Trace with Custom Color . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Figure 16-8. Wave Viewer Displays Inputs and Outputs of Selected Process . . . . . . . . . . . 819
Figure 16-9. Unknown States Shown as Red Lines in Wave Window . . . . . . . . . . . . . . . . . 821
Figure 16-10. Dataflow: Point-to-Point Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Figure 16-11. The Print Postscript Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Figure 16-12. The Print Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Figure 16-13. The Page Setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Figure 16-14. Dataflow Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Figure 17-1. Setting Context from Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Figure 17-2. Examine Window Pop Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Figure 17-3. Source Annotation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Figure 17-4. Current Time Label in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Figure 17-5. Enter an Event Time Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Figure 17-6. Bookmark All Instances of a Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Figure 17-7. Popup Menu Choices for Textual Dataflow Information . . . . . . . . . . . . . . . . . 846
Figure 17-8. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Figure 17-9. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . . 847
Figure 17-10. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Figure 17-11. List Menu with All Three Viewing Options On . . . . . . . . . . . . . . . . . . . . . . . 848
Figure 17-12. Click Any Driver to Display It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Figure 17-13. Source Readers Dialog Displays All Signal Readers . . . . . . . . . . . . . . . . . . . 849
Figure 17-14. Coverage in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Figure 17-15. Breakpoint in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Figure 17-16. Editing Existing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Figure 17-17. Source Code for source.sv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Figure 18-1. Event Traceback Toolbar Button Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Figure 18-2. Cause is Highlighted in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Figure 18-3. Click to Show Drivers Control Bar to See Driver(s) . . . . . . . . . . . . . . . . . . . . 871
Figure 18-4. Active Driver Path Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Figure 18-5. Active Cursor Show Time of Causal Process . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Figure 18-6. Causal Process Highlighted in Structure Window . . . . . . . . . . . . . . . . . . . . . . 873
Figure 18-7. Causal Signal Highlighted in the Objects Window . . . . . . . . . . . . . . . . . . . . . 873
Figure 18-8. Time Indicator in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Figure 18-9. Enter an Event Time Value for Causality Tracing . . . . . . . . . . . . . . . . . . . . . . 874
Figure 18-10. Source Window - Show Drivers Control Bar . . . . . . . . . . . . . . . . . . . . . . . . . 876
Figure 18-11. Selecting Show Driver from Show Cause Drop-Down Menu . . . . . . . . . . . . 876
Figure 18-12. Right-click Menu – Show Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Figure 18-13. Details of the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Figure 18-14. Trace Event to Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Figure 18-15. Root Cause Highlighted in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . 878

ModelSim® SE User's Manual, v10.7 47

 List of Figures

Figure 18-16. Show X Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879

Figure 18-17. Show All Possible Drivers Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 880
Figure 18-18. Possible Drivers in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
Figure 18-19. Selecting a Specific Time for a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Figure 18-20. Enter Value Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Figure 18-21. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Figure 18-22. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . 882
Figure 18-23. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Figure 18-24. List Menu with All Three Viewing Options On . . . . . . . . . . . . . . . . . . . . . . . 883
Figure 18-25. Click Any Driver to Display It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Figure 18-26. View Path Details Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Figure 18-27. Causality Path Details in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . 885
Figure 18-28. Time 810 Selected in Path Times Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Figure 18-29. Causality Path Details in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 887
Figure 18-30. Causality Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Figure 19-1. Enabling Code Coverage in the Start Simulation Dialog . . . . . . . . . . . . . . . . . 898
Figure 19-2. Selecting Code Coverage Analysis Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Figure 19-3. Coverage Summary Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Figure 19-4. Summary Begins Each Coverage Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Figure 19-5. Toggle Coverage Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Figure 19-6. Toggle Coverage Data in the Objects Window. . . . . . . . . . . . . . . . . . . . . . . . . 932
Figure 19-7. Adaptive Exclusion Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Figure 19-8. Sample Toggle Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Figure 21-1. Assertion Matches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Figure 21-2. Configure Assertions Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Figure 21-3. Assertion Enable Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
Figure 21-4. Selecting Profile On from Capacity Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Figure 21-5. Selecting Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Figure 21-6. Setting Immediate Assertion Break Severity . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Figure 21-7. Enabling/Disabling Failure or Pass Logging . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Figure 21-8. Setting Assertion Failure Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Figure 21-9. Set Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Figure 21-10. Configure Selected Cover Directives Dialog . . . . . . . . . . . . . . . . . . . . . . . . . 1022
Figure 21-11. Failure Counts in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Figure 21-12. Assertion Failures Indicated by Red Triangles . . . . . . . . . . . . . . . . . . . . . . . . 1026
Figure 21-13. Assertion Counts in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Figure 21-14. Enable Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Figure 21-15. Assertion Indicators When -assertdebug is Used . . . . . . . . . . . . . . . . . . . . . . 1028
Figure 21-16. Counts Columns in Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Figure 21-17. SystemVerilog Assertions in the Assertions Window . . . . . . . . . . . . . . . . . . 1031
Figure 21-18. Assertion Failures Appear in Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Figure 21-19. PSL Cover Directives in the Cover Directives Window. . . . . . . . . . . . . . . . . 1033
Figure 21-20. SystemVerilog Assert and Cover Directives in the Wave Window . . . . . . . . 1035
Figure 21-21. PSL Assert and Cover Directives in the Wave Window. . . . . . . . . . . . . . . . . 1036
Figure 21-22. Antecedent Matches Indicated by Yellow Triangle . . . . . . . . . . . . . . . . . . . . 1037

48 ModelSim® SE User's Manual, v10.7

List of Figures

Figure 21-23. Hierarchy Display Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038

Figure 21-24. Viewing Cover Directive Waveforms in Count Mode . . . . . . . . . . . . . . . . . . 1039
Figure 21-25. Assertions Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Figure 21-26. Usage Flow for PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Figure 21-27. Usage Flow for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Figure 21-28. Enable Assertion Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Figure 21-29. Enable ATV Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
Figure 21-30. Assertion Debug Pane in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Figure 21-31. The ActiveCount Object in the Wave Window - SystemVerilog . . . . . . . . . . 1074
Figure 21-32. Selecting Assertion Thread Start Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Figure 21-33. Opening ATV from the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Figure 21-34. Opening ATV from the Message Viewer Window. . . . . . . . . . . . . . . . . . . . . 1077
Figure 21-35. ATV Panes - SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Figure 21-36. Failed Expressions Highlighted Red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Figure 21-37. Values of Local Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Figure 21-38. View Thread at 150 ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Figure 21-39. ATV Window Shows Where Boolean Sub-Expression Failed. . . . . . . . . . . . 1084
Figure 21-40. ATV Window Displays All Clock Expressions . . . . . . . . . . . . . . . . . . . . . . . 1085
Figure 21-41. Root Thread Analysis of a Directive Failure . . . . . . . . . . . . . . . . . . . . . . . . . 1086
Figure 21-42. Root Thread Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
Figure 21-43. ATV Mouse Hover Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
Figure 21-44. ATV Mouse Hover Information - SystemVerilog . . . . . . . . . . . . . . . . . . . . . 1088
Figure 21-45. Local Variables Annotation in Thread Viewer Pane . . . . . . . . . . . . . . . . . . . 1088
Figure 22-1. SystemVerilog Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Figure 22-2. Turning off Collection for a Coverpoint Using option.no_collect . . . . . . . . . . 1092
Figure 22-3. Functional Coverage Statistics in Covergroups Window . . . . . . . . . . . . . . . . . 1107
Figure 22-4. Creating Functional Coverage Text Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
Figure 22-5. Filter Setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Figure 22-6. Create Filter Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Figure 22-7. Add-Modify Select Criteria Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Figure 22-8. Copy and Rename Filter Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Figure 24-1. Verification of a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Figure 24-2. Command Setup Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Figure 24-3. File Merge Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
Figure 24-4. original.ucdb, dut.ucdb and tb.ucdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Figure 24-5. Test Data in Verification Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Figure 24-6. Differing Merge and Rank Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Figure 24-7. Coverage Report Text Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Figure 24-8. Coverage HTML Report from File Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196
Figure 24-9. HTML Coverage Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Figure 24-10. Exclusion Comment Displays as Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198
Figure 24-11. Hyperlinked Bins in the Hits Column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Figure 24-12. Test-Bins-Hit Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Figure 24-13. Coverage Exclusion Report Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1201
Figure 24-14. Filtering Displayed UCDB Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204

ModelSim® SE User's Manual, v10.7 49

 List of Figures

Figure 24-15. Filtering on User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206

Figure 25-1. Specifying Path in C Debug setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Figure 25-2. Setting Breakpoints in Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Figure 25-3. Right Click Pop-up Menu on Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Figure 25-4. Simulation Stopped at Breakpoint on PLI Task . . . . . . . . . . . . . . . . . . . . . . . . 1217
Figure 25-5. Stepping into Next File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218
Figure 25-6. Function Pointer to Foreign Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
Figure 25-7. Highlighted Line in Associated File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
Figure 25-8. Stop on quit Button in Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223
Figure 26-1. Status Bar: Profile Samples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Figure 26-2. Ranked Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
Figure 26-3. Design Units Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Figure 26-4. Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235
Figure 26-5. Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Figure 26-6. Expand and Collapse Selections in Popup Menu . . . . . . . . . . . . . . . . . . . . . . . 1236
Figure 26-7. Profile Details Window: Function Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Figure 26-8. Profile Details Window: Instance Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Figure 26-9. Profile Details Window: Callers and Callees . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Figure 26-10. Accessing Source from Profile Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Figure 26-11. Profile Report Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Figure 26-12. Profile Report Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Figure 26-13. The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Figure 26-14. Displaying Capacity Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . 1251
Figure 28-1. JobSpy Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287
Figure 28-2. Job Manager View Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Figure 29-1. Waveform Editor: Library Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Figure 29-2. Results of Create Wave Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298
Figure 29-3. Opening Waveform Editor from Objects Windows . . . . . . . . . . . . . . . . . . . . . 1298
Figure 29-4. Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Figure 29-5. Wave Edit Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Figure 29-6. Manipulating Waveforms with the Wave Edit Toolbar and Cursors . . . . . . . . 1303
Figure 29-7. Export Waveform Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Figure 29-8. Evcd Import Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
Figure 30-1. SDF Tab in Start Simulation Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Figure 32-1. Breakpoint Flow Control in Nested DO Files. . . . . . . . . . . . . . . . . . . . . . . . . . 1377
Figure 32-2. Tcl Debugger for vsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381
Figure 32-3. TDebug Choose Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Figure 32-4. Setting a Breakpoint in the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Figure 32-5. Variables Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Figure A-1. Runtime Options Dialog: Defaults Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Figure A-2. Runtime Options Dialog Box: Message Severity Tab . . . . . . . . . . . . . . . . . . . . 1397
Figure A-3. Runtime Options Dialog Box: WLF Files Tab . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Figure D-1. InfoHub for QVIP Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759
Figure D-2. QVIP API Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
Figure D-3. Select Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760

50 ModelSim® SE User's Manual, v10.7

List of Figures

Figure D-4. Questa Verification IP Transactions in Wave Window . . . . . . . . . . . . . . . . . . . 1763

Figure D-5. Generation and Recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
Figure D-6. Questa Verification IP Transaction at Different Levels of Abstraction. . . . . . . 1771
Figure D-7. Generation of Children. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1774
Figure D-8. Recognition into Parents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1774
Figure D-9. Activate MVC_transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
Figure D-10. Activating MVC_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
Figure D-11. Activates MVC_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1780
Figure D-12. Send MVC_Message or MVC_Stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
Figure D-13. Sending MVC_Message or MVC_Stripe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
Figure D-14. Sent MVC_Message or MVC_Stripe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1782
Figure D-15. Receive MVC_transaction, MVC_Message or MVC_Stripe . . . . . . . . . . . . . 1782
Figure D-16. Receiving MVC_transaction, MVC_Message or MVC_Stripe. . . . . . . . . . . . 1783
Figure D-17. Received MVC_Transaction, MVC_Message or MVC_Stripe. . . . . . . . . . . . 1783
Figure D-18. MVC_Transaction and MVC_Message Start and End Times . . . . . . . . . . . . . 1786
Figure D-19. MVC_Stripe Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
Figure E-1. DPI Use Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801

ModelSim® SE User's Manual, v10.7 51

 List of Figures

52 ModelSim® SE User's Manual, v10.7

 List of Tables

Table 1-1. General Modes for ModelSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Table 1-2. Possible Definitions of an Object, by Language . . . . . . . . . . . . . . . . . . . . . . . . . 77
Table 1-3. Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 1-4. Deprecated Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Table 2-1. Compile Options for the -nodebug Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 3-1. vopt Arguments for Access Visibility Being Replaced . . . . . . . . . . . . . . . . . . . . 127
Table 6-1. Using the examine Command to Obtain VHDL Integer Data . . . . . . . . . . . . . . 238
Table 6-2. Using the examine Command to Obtain VHDL String Data . . . . . . . . . . . . . . . 238
Table 6-3. Using the examine Command to Obtain VHDL Record Data . . . . . . . . . . . . . . 239
Table 7-1. Evaluation 1 of always Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Table 7-2. Evaluation 2 of always Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Table 7-3. Utility System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Table 7-4. Utility System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Table 7-5. Utility System Math Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Table 7-6. Utility System Elaboration Tasks and Coverage Functions . . . . . . . . . . . . . . . . 300
Table 7-7. Utility System Severity and Assertion Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Table 7-8. Utility System Analysis Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Table 7-9. Input/Output System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Table 7-10. Input/Output System Memory and Argument Tasks . . . . . . . . . . . . . . . . . . . . 303
Table 7-11. Input/Output System File I/O Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Table 7-12. Other System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Table 7-13. Simulator-Specific Verilog System Tasks and Functions . . . . . . . . . . . . . . . . . 309
Table 7-14. Stepping Within the Current Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Table 7-15. Garbage Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Table 7-16. CLI Garbage Collector Commands and INI Variables . . . . . . . . . . . . . . . . . . . 371
Table 8-1. Supported Platforms for SystemC-2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Table 8-2. Supported Platforms for SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Table 8-3. Specifying SystemC Platform and Compiler Version . . . . . . . . . . . . . . . . . . . . . 382
Table 8-4. Custom gcc Platform Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Table 8-5. Generated Extensions for Each Object Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Table 8-6. Time Unit and Simulator Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Table 8-7. Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Table 8-8. Mixed-language Compares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Table 8-9. Simple Conversion: sc_main to Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Table 8-10. Using sc_main and Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Table 8-11. Modifications Using SCV Transaction Database . . . . . . . . . . . . . . . . . . . . . . . 439
Table 9-1. VHDL Types Mapped To SystemVerilog Port Vectors . . . . . . . . . . . . . . . . . . . 464
Table 9-2. SystemVerilog-to-VHDL Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Table 9-3. Verilog Parameter to VHDL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Table 9-4. Verilog States Mapped to std_logic and bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

ModelSim® SE User's Manual, v10.7 53

 List of Tables

Table 9-5. VHDL to SystemVerilog Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Table 9-6. VHDL Generics to Verilog Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Table 9-7. Mapping VHDL bit to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Table 9-8. Mapping VHDL std_logic Type to Verilog States . . . . . . . . . . . . . . . . . . . . . . . 482
Table 9-9. Mapping Table for Verilog-style Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Table 9-10. Mapping Table for SystemVerilog-style Declarations . . . . . . . . . . . . . . . . . . . 484
Table 9-11. Channel and Port Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Table 9-12. Data Type Mapping – SystemC to Verilog or SystemVerilog . . . . . . . . . . . . . 489
Table 9-13. Data Type Mapping – Verilog or SystemVerilog to SystemC . . . . . . . . . . . . . 492
Table 9-14. Mapping Verilog Port Directions to SystemC . . . . . . . . . . . . . . . . . . . . . . . . . 495
Table 9-15. Mapping Verilog States to SystemC States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Table 9-16. Mapping SystemC bool to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Table 9-17. Mapping SystemC sc_bit to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Table 9-18. Mapping SystemC sc_logic to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Table 9-19. SystemC Port Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Table 9-20. Mapping Between SystemC sc_signal and VHDL Types . . . . . . . . . . . . . . . . . 498
Table 9-21. Mapping VHDL Port Directions to SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Table 9-22. Mapping VHDL std_logic States to SystemC States . . . . . . . . . . . . . . . . . . . . 502
Table 9-23. Mapping SystemC bool to VHDL Boolean States . . . . . . . . . . . . . . . . . . . . . . 502
Table 9-24. Mapping SystemC sc_bit to VHDL bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Table 9-25. Mapping SystemC sc_logic to VHDL std_logic . . . . . . . . . . . . . . . . . . . . . . . . 503
Table 9-26. Mapping Literals from VHDL to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . 513
Table 9-27. Supported Types Inside VHDL Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Table 9-28. Supported Types Inside SystemVerilog Structure . . . . . . . . . . . . . . . . . . . . . . 515
Table 9-29. SystemC Types as Represented in SystemVerilog . . . . . . . . . . . . . . . . . . . . . . 549
Table 10-1. Checkpoint and Restore Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Table 11-1. System Tasks and API for Recording Transactions . . . . . . . . . . . . . . . . . . . . . 587
Table 12-1. Questa Verification IP Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Table 12-2. Questa Verification IP Colors and Causation . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Table 13-1. WLF File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Table 13-2. Structure Tab Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Table 13-3. vsim Arguments for Collapsing Time and Delta Steps . . . . . . . . . . . . . . . . . . . 660
Table 14-1. Add Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Table 14-2. Actions for Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Table 14-3. Find Previous and Next Transition Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Table 14-4. Two Cursor Zoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Table 14-5. Recording Delta and Event Time Information . . . . . . . . . . . . . . . . . . . . . . . . . 681
Table 14-6. Menu Selections for Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . 686
Table 14-7. Actions for Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Table 14-8. Mixed-Language Waveform Compares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Table 15-1. Code Preview Toolbar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Table 15-2. Icon and Menu Selections for Exploring Design Connectivity . . . . . . . . . . . . . 774
Table 15-3. Schematic Window Links to Other Windows and Panes . . . . . . . . . . . . . . . . . 797
Table 15-4. Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Table 16-1. Icon and Menu Selections for Exploring Design Connectivity . . . . . . . . . . . . . 814

54 ModelSim® SE User's Manual, v10.7

List of Tables

Table 16-2. Dataflow Window Links to Other Windows and Panes . . . . . . . . . . . . . . . . . . 830
Table 17-1. Open a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Table 18-1. Setting Causality Traceback Report Destination . . . . . . . . . . . . . . . . . . . . . . . . 867
Table 18-2. Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Table 19-1. Code Coverage in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Table 19-2. Operators with Their Non-Masking States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Table 19-3. Auto-Exclusion Reason Codes in Coverage Reports . . . . . . . . . . . . . . . . . . . . 943
Table 19-4. Coverconstruct Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Table 20-1. Commands Used for FSM Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . 994
Table 20-2. Commands Used to Capture FSM Debug Information . . . . . . . . . . . . . . . . . . . 997
Table 20-3. FSM Coverage Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Table 20-4. Additional FSM-Related Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
Table 20-5. Recognized FSM Note Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Table 20-6. FSM Recognition Info Note Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
Table 21-1. Graphic Elements for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1037
Table 22-1. Questa SIM and SystemVerilog IEEE 1800-2009 Options . . . . . . . . . . . . . . . 1095
Table 22-2. Option Settings and Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Table 22-3. Which Form of Canonical Naming is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Table 23-1. Attributes Usable with randomize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Table 24-1. Coverage Calculation for Each Coverage Type . . . . . . . . . . . . . . . . . . . . . . . . 1148
Table 24-2. Coverage Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Table 24-3. Predefined Fields in UCDB Test Attribute Record . . . . . . . . . . . . . . . . . . . . . . 1159
Table 25-1. Simulation Stepping Options in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Table 25-2. Command Reference for C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223
Table 26-1. Commands for Enabling and Viewing Capacity Analysis . . . . . . . . . . . . . . . . 1245
Table 27-1. Signal Spy Reference Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Table 28-1. Simulation Commands You can Issue from JobSpy . . . . . . . . . . . . . . . . . . . . . 1284
Table 29-1. Signal Attributes in Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Table 29-2. Waveform Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1301
Table 29-3. Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Table 29-4. Wave Editor Mouse/Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Table 29-5. Formats for Saving Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Table 29-6. Examples for Loading a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
Table 30-1. Matching SDF to VHDL Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Table 30-2. Matching SDF IOPATH to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319
Table 30-3. Matching SDF INTERCONNECT and PORT to Verilog . . . . . . . . . . . . . . . . 1319
Table 30-4. Matching SDF PATHPULSE and GLOBALPATHPULSE to Verilog . . . . . . 1319
Table 30-5. Matching SDF DEVICE to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Table 30-6. Matching SDF SETUP to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Table 30-7. Matching SDF HOLD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Table 30-8. Matching SDF SETUPHOLD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Table 30-9. Matching SDF RECOVERY to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
Table 30-10. Matching SDF REMOVAL to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
Table 30-11. Matching SDF RECREM to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
Table 30-12. Matching SDF SKEW to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321

ModelSim® SE User's Manual, v10.7 55

 List of Tables

Table 30-13. Matching SDF WIDTH to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321

Table 30-14. Matching SDF PERIOD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322
Table 30-15. Matching SDF NOCHANGE to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322
Table 30-16. RETAIN Delay Usage (default) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323
Table 30-17. RETAIN Delay Usage (with +vlog_retain_same2same_on) . . . . . . . . . . . . . 1323
Table 30-18. Matching Verilog Timing Checks to SDF SETUP . . . . . . . . . . . . . . . . . . . . . 1324
Table 30-19. SDF Data May Be More Accurate Than Model . . . . . . . . . . . . . . . . . . . . . . . 1324
Table 30-20. Matching Explicit Verilog Edge Transitions to Verilog . . . . . . . . . . . . . . . . . 1324
Table 30-21. SDF Timing Check Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Table 30-22. SDF Path Delay Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Table 30-23. Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Table 31-1. VCD Commands and SystemTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340
Table 31-2. VCD Dumpport Commands and System Tasks . . . . . . . . . . . . . . . . . . . . . . . . 1340
Table 31-3. VCD Commands and System Tasks for Multiple VCD Files . . . . . . . . . . . . . . 1340
Table 31-4. SystemC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341
Table 31-5. Driver States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Table 31-6. State When Direction is Unknown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Table 31-7. Driver Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
Table 31-8. VCD Values When Force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
Table 31-9. Values for file_format Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1350
Table 31-10. Sample Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1351
Table 32-1. Tcl Backslash Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356
Table 32-2. Changes to ModelSim Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
Table 32-3. Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
Table 32-4. Tcl List Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366
Table 32-5. Simulator-Specific Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Table 32-6. Tcl Time Conversion Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Table 32-7. Tcl Time Relation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Table 32-8. Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
Table 32-9. Commands for Handling Breakpoints and Errors in DO scripts . . . . . . . . . . . . 1378
Table 32-10. Tcl Debug States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381
Table A-1. Commands for Overriding the Default Initialization File . . . . . . . . . . . . . . . . . 1395
Table A-2. Runtime Option Dialog: Defaults Tab Contents . . . . . . . . . . . . . . . . . . . . . . . . 1396
Table A-3. Runtime Option Dialog: Message Severity Tab Contents . . . . . . . . . . . . . . . . . 1398
Table A-4. Runtime Option Dialog: WLF Files Tab Contents . . . . . . . . . . . . . . . . . . . . . . . 1399
Table A-5. License Variable: License Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
Table A-6. MessageFormat Variable: Accepted Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
Table C-1. Severity Level Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Table C-2. Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
Table D-1. TQ_Id Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
Table D-2. Parent/Child Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
Table D-3. Generation/Recognition Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . 1775
Table D-4. Deletion Related Series 50000 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Table D-5. Communication Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
Table D-6. Volatile Clause Related Series 50000 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787

56 ModelSim® SE User's Manual, v10.7

List of Tables

Table D-7. Activity Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788

Table D-8. Throw/Catch Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Table D-9. TLM/WLM Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
Table E-1. VPI Compatibility Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
Table E-2. PCAT File — Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
Table E-3. PLI_Linkage Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812
Table E-4. vsim Arguments for DPI Application Using External Compilation Flows . . . . 1825
Table E-5. Supported VHDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1833
Table E-6. Supported ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
Table E-7. Supported TF Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
Table E-8. Values for action Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Table F-1. Files That ModelSim Accesses During Startup . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Table F-2. Add Library Mappings to modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855

ModelSim® SE User's Manual, v10.7 57

 List of Tables

58 ModelSim® SE User's Manual, v10.7

 Chapter 1
Introduction

ModelSim provides you with a simulation, debug, and verification platform for validating
FPGA and SoC designs.
For more complete information on current support for ModelSim, refer to the Installation and
Licensing Guide.

Operational Structure and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Basic Steps for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
General Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Default stdout Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Definition of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Standards Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Deprecated Features, Commands, and Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Operational Structure and Flow

A series of commands provides the structure and flow for verifying a design with ModelSim.

ModelSim® SE User's Manual, v10.7 59

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Operational Structure and Flow

Figure 1-1. Operational Structure and Flow of ModelSim

60 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Basic Steps for Simulation

Basic Steps for Simulation

You must have the proper files and library setup in order to use the commands necessary to
simulate your design using ModelSim.
Files and Map Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Step 1 — Create Work and Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 2 — Compile the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Step 3 — Optimize the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 4— Load the Design for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 5 — Simulate the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 6 — Debug the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

ModelSim® SE User's Manual, v10.7 61

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Files and Map Libraries

Files and Map Libraries

ModelSim must have access to several specific file types in order to simulate your design.
What is a Library?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Resource Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Mapping the Logical Work to the Physical Work Directory. . . . . . . . . . . . . . . . . . . . . . 63

What is a Library?
A library is a location on your file system that contains data to be used for simulation.
ModelSim relies on and can manipulate the data in one or more libraries for simulation. A
library also helps to streamline simulation invocation.
ModelSim uses two types of libraries:

• A local working library that contains the compiled version of your design
• A resource library

Resource Libraries
A resource library is typically unchanging, and serves as a parts source for your design. You can
create your own resource libraries, or they may be supplied by another design team or a third
party (for example, a silicon vendor).
Examples of resource libraries:

• Shared information within your group

• Vendor libraries
• Packages
• Previously compiled elements of your own working design
Instead of compiling all design data each time you simulate, ModelSim makes use of pre-
compiled resource libraries supplied in the installation tree. These libraries help to minimize
errors during compilation and simulation startup. Also, if you make changes to a single Verilog
module in a given library, ModelSim will recompile only that module, rather than all modules in
the design.

Related Topics
Working Library Versus Resource Libraries
Library Window Contents
Working with Design Libraries

62 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Step 1 — Create Work and Resource Libraries

Verilog Resource Libraries

VHDL Resource Libraries
Creating a Library

Mapping the Logical Work to the Physical Work Directory

VHDL uses logical library names that you map to ModelSim library directories. If you do not
map libraries properly before invoking your simulation, the simulation will fail due to not
loading the necessary components. Similarly, compilation does depend on proper library
mapping.
By default, ModelSim can find libraries in your current directory (assuming they have the right
name), but for it to find libraries located elsewhere, you must map a logical library name to the
pathname of the library.

Step 1 — Create Work and Resource Libraries

Before you can compile your source files, you must create a working library in which to store
the compilation results.
You use the vlib command to create your working library. The contents of the library change as
you update your design and recompile.

The vlib command creates a “flat” library type by default. Flat libraries condense library
information into a small collection of files compared to the legacy library type. This remedies
performance and capacity issues seen with very large libraries.

Restrictions and Limitations

• Makefile support for flat libraries is limited due to the lack of per-target file objects.
However, the resulting makefile will trigger a build of all design units should any source
file for any design unit be newer than the library. Optimized design units in flat libraries
are also supported, with more precise dependency tracking.
Flows requiring the vmake command can revert to the legacy library type when you do
any of the following:
o Specify “-type directory” in the vlib command.
o Set the DefaultLibType variable in your modelsim.ini file to the value 0.
o Set the shell environment variable MTI_DEFAULT_LIB_TYPE to the value 0.
• Use braces ({}) for cases where the path contains multiple items that need to be escaped,
such as when the pathname contains spaces or backslash characters. For example:
vmap celllib {$LIB_INSTALL_PATH/Documents And Settings/All/celllib}

ModelSim® SE User's Manual, v10.7 63

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Step 1 — Create Work and Resource Libraries

Prerequisites
• Know the paths to the directories that contain your design files and resource libraries.
• Start ModelSim
Procedure
1. Choose File > Change Directory from the main menu to open the Browse For Folder
dialog box.
2. Navigate to the directory where your source files are located.
3. Create the Logical Work Library with the vlib command in one of the following ways:
• Enter the vlib command in the a UNIX shell or the Transcript window:
vlib work

• Choose File > New > Library from the main menu.
4. Map one or more user provided libraries between a logical library name and a directory
with the vmap command:
vmap <logical_name> <directory_pathname>

Results
Creates a library named work, places it in the current directory and displays the work library in
the Structure window (Figure 1-2).
Figure 1-2. Work Library

Related Topics
Working Library Versus Resource Libraries
Working with Design Libraries
Map a Logical Name to a Design Library
Getting Started with Projects
Creating a Library

64 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Step 2 — Compile the Design

Step 2 — Compile the Design

Use the language-specific compiler command to compile your design files into your working
directory.
• Verilog and SystemVerilog — compile with the vlog command.
• VHDL — compile with the vcom command.
• SystemC — compile with the sccom command.
Prerequisites
• Create the work library and map required resource libraries to the work library. Refer to
Step 1 — Create Work and Resource Libraries for more information.
• SystemC designs require installation of the gcc compiler. Refer to Compiling SystemC
Files for more information.
Procedure
Depending on the language used to create your design, use one of the following ModelSim
commands to compile the design:

If your source files Enter the following in the Transcript window …

are written in …
Verilog and/or You can compile Verilog files in any order. For example:
SystemVerilog vlog gates.v and2.v cache.v memory.v
VHDL The vcom command compiles VHDL units in the order
they appear on the command line. For VHDL, the order
of compilation is important — you must compile any
entities or configurations before an architecture that
references them. For example:
vcom v_and2.vhd util.vhd set.vhd
SystemC ModelSim uses an external C/C++ compiler to compile
SystemC source code into the work library, while sccom
-link takes compiled source code and links the design.
For example:
sccom -g basic.cpp
sccom -link

Where the -g argument compiles the design for debug.

Results
By default, compilation results are stored in the work library. (Figure 1-3)

ModelSim® SE User's Manual, v10.7 65

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Step 3 — Optimize the Design

Figure 1-3. Compiled Design

Related Topics
Verilog Compilation
Compilation and Simulation of VHDL
Auto-Generate the Compile Order
Compiling SystemC Files

Step 3 — Optimize the Design

Optimization is an optional step that can improve performance by limiting the visibility of
design objects. ModelSim performs global optimizations with the vopt command.
Prerequisites
• Create the work library and map required resource libraries to the work library. Refer to
Step 1 — Create Work and Resource Libraries for more information.
• Compile the design. Refer to Step 2 — Compile the Design.
Procedure
Enter the following command on the command line:

vopt top -o topopt

where:
• top is the name of the compiled top level module.
• -o topopt specifies a name (topopt) for the optimized version of the design.

66 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Step 4— Load the Design for Simulation

Related Topics
Optimizing Designs with vopt

Step 4— Load the Design for Simulation

Use the vsim command to load the design, as defined by specifying the names of any top-level
modules (many designs contain only one top-level module).
Prerequisites
• Create the work library and map required resource libraries to the work library. Refer to
Step 1 — Create Work and Resource Libraries for more information.
• Compile the design. Refer to Step 2 — Compile the Design.
Procedure
Enter the following command on the command line:

vsim testbench globals

where testbench and globals are the two top level modules.
Results
The simulator loads the top-level modules then iteratively loads the instantiated modules and
UDPs in the design hierarchy. This links the design together by connecting the ports and
resolving hierarchical references.
Note
You can incorporate actual delay values to the simulation by applying standard delay format
(SDF) back-annotation files to the design.

Related Topics
Specifying SDF Files for Simulation

Step 5 — Simulate the Design

Once you have successfully loaded the design, simulation time is set to zero, and you must enter
a run command to begin simulation.
Prerequisites
• Have a basic understanding of the following commands, which you commonly use to
run a simulation:
o add wave

ModelSim® SE User's Manual, v10.7 67

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Step 6 — Debug the Design

o bp
o force
o run
o step
Procedure
Add stimulus to the design, using any of the following methods.

• Language-based test bench.

• Tcl-based ModelSim interactive commands. For example, force and bp.
• VCD files / commands.
Refer to “Creating a VCD File” and “Using Extended VCD as Stimulus.”
• Third-party test bench generation tools.
Related Topics
Verilog and SystemVerilog Simulation
VHDL Simulation
SystemC Simulation

Step 6 — Debug the Design

You can debug your design from the ModelSim GUI.
Procedure
Use any or all of the following commands to begin interactively debugging your simulation:

• describe
• drivers
• examine
• force
• log
• checkpoint
• restore
• show

68 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
General Modes of Operation

General Modes of Operation

You can use the three general modes of operation to interact with ModelSim: GUI mode,
command line mode, and batch mode.
The ModelSim User’s Manual focuses primarily on the graphical user interface (GUI) mode of
operation — interacting with your simulation by working in the ModelSim desktop with
windows, menus, and dialog boxes. However, ModelSim also has a command line mode and
batch mode for compiling and simulating a design.

The following table provides short descriptions of the three modes.

Table 1-1. General Modes for ModelSim
Mode Characteristics
GUI You can invoke this mode:
• by specifying vsim from the OS command or shell prompt
• by specifying vsim -gui from the OS command or shell prompt
• by specifying vsim -i from the OS command or shell prompt
• from a Windows desktop icon
It is recommended for viewing waveforms and graphic-based
debugging.
Command Line Mode You can invoke this mode with using the -c option:
vsim -c

This mode is non-interactive with no GUI.

Supports all commands that are not GUI based. 1
It is recommended for DO file based simulations, and executing
commands from a prompt
Batch Mode You can invoke this mode with using the -b option:
vsim -b

This mode is a non-interactive batch script. There is no windows or

interactive command line. Most commands and command options are
supported.1
It is recommended for large, high-performance simulations
1. Refer to the Supported Commands table in the Command Reference Manual to see which commands are
available for use with vsim -c and vsim -batch.

Command Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Batch Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

ModelSim® SE User's Manual, v10.7 69

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Command Line Mode

Command Line Mode

Command line simulations are initiated from a Windows or UNIX command prompt and can be
either interactive or non-interactive.
Most command line simulations operate in non-interactive mode. For example, when a DO file
is being processed or a stdin redirect is present. Otherwise, the simulator operates in interactive
mode—for example, when a DO file script requires input from the user to continue.

Note
You can use CTRL-C to terminate batch simulation in both the UNIX and Windows
environments.

Startup Variable Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Here-Document Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I/O Redirection Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Basic Command Line Editing and Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Supported Commands for Command Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Startup Variable Flow

In command line mode, ModelSim runs any startup command specified by the Startup variable
in the modelsim.ini file. If you invoke vsim with the -do “command_string” option, the DO file
executed in this manner overrides any startup command in the modelsim.ini file.
Stand-alone tools pick up project settings in command-line mode if you invoke them in the
project's root directory. If invoked outside the project directory, stand-alone tools pick up
project settings only if you set the MODELSIM environment variable to the path to the project
file (<Project_Root_Dir>/<Project_Name>.mpf).

Related Topics
Startup
vsim [ModelSim SE Command Reference Manual]

Here-Document Flow
You can use the “here-document” technique to enter a string of commands in a UNIX shell or
Windows command window. You invoke vsim and redirect standard input using the
exclamation character (!) to initiate and terminate a sequence of commands.

70 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Command Line Mode

The following is an example of the “here-document” technique:

vsim top <<!

log -r *
run 100
do test.do
quit -f
!

The file test.do can run until completion or contain commands that return control of the
simulation to the command line and wait for user input. You can also use this technique to run
multiple simulations.

I/O Redirection Flow

You can use a script with output and input redirection to and from user specified files. The
script can be set up to run interactively or non-interactively.
For example:

vsim -c counter <infile >outfile

where “counter” is the design top, “infile” represents a script containing various ModelSim
commands, and the angle brackets (< >) are redirection indicators.

Use the batch_mode command to verify that you are in Command Line Mode. stdout returns
“1” if you specify batch_mode while you are in Command Line Mode (vsim -c) or Batch Mode
(vsim -batch).

DO Files Generated from Transcript Files

ModelSim creates a transcript file during simulation that contains stdout messages. You can use
this transcript file as the basis for a DO file if you invoke the transcript on command after the
design loads, which writes all of the commands you invoke to the transcript file.

Run the following command:

vsim -c top

After reviewing the library and design loading messages you can then run the commands:

transcript on
force clk 1 50, 0 100 -repeat 100
run 500
run @5000
quit -f

These commands result in a transcript file, which you can use for command input if you re-
simulate top. Be sure to remove the quit -f command from the transcript file if you want to
remain in the simulator.

ModelSim® SE User's Manual, v10.7 71

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Command Line Mode

You should rename a transcript file that you intend to use as a DO file. If you do not rename the
file, ModelSim overwrites it the next time you run vsim. Also, simulator messages are already
commented out with the pound sign (#), but any messages generated from your design (and
subsequently written to the transcript file) causes the simulator to pause. A transcript file that
contains only valid simulator commands works fine; use a pound sign to comment out anything
else.

Refer to Creating a Transcript File for more information about creating, locating, and saving a
transcript file.

Related Topics
Default stdout Messages
Stats
vsim command [ModelSim SE Command Reference Manual]

Basic Command Line Editing and Navigation

Command line mode enables you to use basic command line editing and navigation techniques
that you may be familiar with from other command line environments.
Familiar editing and navigation techniques include:

• History navigation — use the up and down arrows to select commands you have already
used.
• Command line editing — use the left and right arrows to edit your current command
line.
• Filename completion — use the Tab key to expand filenames.

Supported Commands for Command Line Mode

GUI-based commands are not available for use with vsim -c.
Refer to the Supported Commands table to see which commands you can use with vsim -c.

72 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Batch Mode

Batch Mode
Batch Mode is an operational mode that allows you to perform simulations without invoking the
GUI.
You execute the simulations by invoking scripted files from a Windows command prompt or
Linux®1shell. Batch mode does not provide for interaction with the design during simulation.
The simulation run typically sends data to (standard output) stdout, which you can redirect to a
log file.

Simulating with Batch Mode can yield faster simulation times, especially for simulations that
generate a large amount of textual output. Refer to Saving Batch Mode Simulation Data for
information about saving transcript data.

Multi-threaded C text output is not well synchronized with HDL text output. Refer to Capturing
Raw stdout in C/C++ Batch Mode Simulation for more information.

The commands you can use within a DO file script for Batch Mode simulation are similar to
those available for Command Line Mode (vsim -c). However, you cannot use all commands or
command options with vsim -batch. Refer to the Commands chapter in the Reference Manual to
see which commands you can use with vsim -batch.

You can enable batch mode with either of the following methods:

• Specify vsim -batch with scripted simulations via the -do “<command_string>” |
<do_file_name> argument. You should running vsim -batch with output redirection as it
yields the best simulation performance. Refer to Redirecting Output With vsim -batch
for more information.
• Enable the BatchMode modelsim.ini variable. If you set this variable to 1, vsim runs as if
you specified the vsim -batch option. If this you set this variable to 0 (default), vsim runs
as if you specified the vsim -i option. Transcript data goes to stdout by default. You can
automatically create a log file by enabling the BatchTranscriptFile modelsim.ini
variable.

Note
You receive a warning message if you specify vsim -batch with the -c, -gui, or the -i
options, and -c, -gui, and -i are ignored. If you enable the BatchMode variable, vsim
ignores the variable if you specify the -batch, -c, -gui, or -i options to vsim.

Saving Batch Mode Simulation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Redirecting Output With vsim -batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Capturing Raw stdout in C/C++ Batch Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . 74
Simulator Control Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

1. Linux® is a registered trademark of Linus Torvalds in the U.S. and other countries.

ModelSim® SE User's Manual, v10.7 73

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Batch Mode

Saving Batch Mode Simulation Data

Capture simulation data during batch mode for post-simulation analysis. The default behavior
when using vsim -batch or the BatchMode modelsim.ini variable is to send transcript data to
stdout and not create a log file. You can save simulation data in one of three ways:
Procedure
Save simulation data using any of these methods:

a. Specify vsim -batch with output redirection (recommended).

b. Specify vsim -batch -logfile <file_name>.
c. Enable the BatchTranscriptFile modelsim.ini variable to automatically create a log
file. If you enable BatchTranscriptFile, you can disable log file creation from the
command line or in a DO file by specifying vsim -nolog.
Related Topics
BatchMode

Redirecting Output With vsim -batch

Use command line arguments to perform output redirection in batch mode.
Procedure
Add a output redirection indicator (>) and a filename to your command line to redirect the
output.

Examples
Given the following command:

vsim -batch counter -do "run -all; quit -f" > outfile

-batch instructs vsim to not open the GUI and the output redirection indicator instructs vsim to
write the command output to the filename outfile.

Capturing Raw stdout in C/C++ Batch Mode Simulation

You use API calls to capture raw stdout in C/C++ batch mode simulation.
Restrictions and Limitations
• Raw stdout from user C/C++ code is not captured in the batch transcript file (logfile)
when running with vsim -batch.

74 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Batch Mode

Procedure
Capture stdout using standard redirection mechanisms. For example:

vsim -batch top -do "run -all; quit -f" > vsim.log

Results
API-based stdout from user C/C++ code (generated by API calls such as vpi_printf() or
mti_PrintFormatted()) will appear in the batch transcript file.

Simulator Control Variables

Many modelsim.ini variables and Tcl variables control batch-mode simulation.
A collection of modelsim.ini variables.
AccessObjDebug IgnoreSVAError StdArithNoWarnings
BreakOnAssertion IgnoreSVAFatal UserTimeUnit
CheckpointCompressMode IgnoreSVAInfo PrintSimStats
ClassDebug IgnoreSVAWarning WildcardFilter
DefaultForceKind IgnoreWarning WLFCompress
DefaultRadix IterationLimit WLFFilename
DelayFileOpen NoQuitOnFinish WLFMCL
ForceSigNextIter NumericStdNoWarnings WLFOptimize
GCThreshold OnBreakDefaultAction WLFSizeLimit
IgnoreError OnErrorDefaultAction WLFTimeLimit
IgnoreFailure PathSeparator WLFUseThreads
IgnoreNote RunLength

In addition, simulator behavior is controlled by a number of Tcl variables. Refer to the table
below for the list of default Tcl variables.
now library architecture
delta entity resolution

Related Topics
modelsim.ini Variables

ModelSim® SE User's Manual, v10.7 75

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Default stdout Messages

Default stdout Messages

By default, the simulator sends information about the simulator, commands executed, start time,
end time, warnings, errors, and other data to stdout.
Tool Statistics Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Tool Statistics Messages

Each time you enter a command, data is printed out and sent to the Transcript window and/or a
logfile.
The data is displayed similar to the following format:

1 # vsim topopt -c -do "run -all; quit -f" -warning 3053

2 # Start time: 18:06:45 on May 13,2014
3 # // Questa Sim-64
4 # // Version <information>
5 # Loading sv_std.std
6 # Loading work.top(fast)
7 # Loading work.pads(fast)
8 # ** Warning: (vsim-3053) test.sv(2): Illegal output or inout port
connection for "port 'AVSS'".
9 # Region: /top/pads
10 # run -all
11 # 0: Z=1, AVSS=0
12 # quit -f
13 # End time: 18:06:45 on May 13,2014, Elapsed time: 0:00:00
14 # Errors: 0, Warnings: 1

• Line 1 — The command with arguments.

• Line 2 — The time and date the command was executed.
• Line 3 — Executable information.
• Line 4 — Release information: including the number and letter release, the executable
type, such as compiler (vlog, vcom), OS version, and build date
• Lines 5 through 12 — Logged messages.
• Line 13 — The time and date the command finished, and elapsed time.
• Line 14 — The total number of errors and warnings in the following format: Errors:
[number], Warnings [number], Suppressed Errors: [number], Suppressed Warnings:
[number]. For zero suppressed errors and warnings, the corresponding count message is
not displayed.

76 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Definition of an Object

Definition of an Object
Because ModelSim supports a variety of design languages (SystemC, Unified Power Format
(UPF), PSL, Verilog, VHDL, and SystemVerilog), the documentation and the interface use the
word “object” to refer to any valid design element in those languages.
Table 1-2 summarizes language-specific elements that define an object.
Table 1-2. Possible Definitions of an Object, by Language
Design Language An object can be
VHDL block statement, component instantiation, constant,
generate statement, generic, package, signal, alias,
variable
Verilog function, module instantiation, named fork, named
begin, net, task, register, variable
SystemVerilog In addition to those listed above for Verilog:
class, package, program, interface, array, directive,
property, sequence
SystemC module, channel, port, variable, aggregate
PSL property, sequence, directive, endpoint
Unified Power Format (UPF) power supply ports and nets, power domains.

Standards Supported
ModelSim supports most industry standards.
Standards documents are sometimes informally referred to as a Language Reference Manual
(LRM). Elsewhere the documentation may refer to only the IEEE Std number.

ModelSim supports the following standards:

• VHDL —
o IEEE Std 1076-2008, IEEE Standard VHDL Language Reference Manual.
ModelSim supports the VHDL 2008 standard features, with a few exceptions. For
detailed standard support information see the vhdl2008 technote available at
<install_dir>/docs/technotes/vhdl2008.note, or from the GUI menu pull-down
Help > Technotes > vhdl2008.
The vhdl2008migration technote addresses potential migration issues and mixing
use of VHDL 2008 with older VHDL code.
o IEEE Std 1164-1993, Standard Multivalue Logic System for VHDL Model
Interoperability

ModelSim® SE User's Manual, v10.7 77

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Text Conventions

o IEEE Std 1076.2-1996, Standard VHDL Mathematical Packages

Any design developed with ModelSim is compatible with any other VHDL system that
is compliant with the 1076 specifications.
• Verilog/SystemVerilog —
o IEEE Std 1364-2005, IEEE Standard for Verilog Hardware Description Language
o IEEE Std 1800-2012. IEEE Standard for SystemVerilog -- Unified Hardware
Design, Specification, and Verification Language
ModelSim supports both PLI (Programming Language Interface) and VCD (Value
Change Dump).
• SDF and VITAL —
o SDF – IEEE Std 1497-2001, IEEE Standard for Standard Delay Format (SDF) for
the Electronic Design Process
o VITAL 2000 – IEEE Std 1076.4-2000, IEEE Standard for VITAL ASIC Modeling
Specification
• SystemC-2.3 —
o IEEE Std 1666-2011, SystemC Language Reference Manual
• Unified Power Format (UPF) —
o (UPF 1.0) The Accellera Unified Power Format (UPF) Standard Version 1.0 –
February 22, 2007
o (UPF 2.0) IEEE Std 1801-2009 – Standard for Design and Verification of Low
Power Integrated Circuits – March 27, 2009
o (UPF 2.1) IEEE Std 1801-2013 – Standard for Design and Verification of Low
Power Integrated Circuits – May 29, 2013
ModelSim supports most of the UPF 1.0, UPF 2.0, and UPF 2.1 features. Refer to the
Power Aware Simulation User’s Manual for more details.
• PSL —
o IEEE Std 1850-2005, IEEE Standard for Property Specific Language (PSL). For
exceptions, see the Verification with Assertions and Cover Directives chapter.

Text Conventions
This manual uses a set of textual conventions.

78 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction
Deprecated Features, Commands, and Variables

Table 1-3. Text Conventions

Text Type Description
italic text provides emphasis and sets off filenames,
pathnames, and design unit names
bold text indicates commands, command options, menu
choices, package and library logical names, as
well as variables, dialog box selections, and
language keywords
monospace type monospace type is used for program and
command examples
The right angle (>) is used to connect menu choices when traversing
menus as in: File > Quit
path separators examples will show either UNIX or Windows
path separators - use separators appropriate for
your operating system when trying the examples
UPPER CASE denotes file types used by ModelSim (such as
DO, WLF, INI, MPF, PDF.)

Deprecated Features, Commands, and

Variables
This section provides tables of features, commands, command arguments, and modelsim.ini
variables that have been superseded by new versions.
Although you can still use superseded features, commands, arguments, or variables, Mentor
Graphics deprecates their usage over time. You should use the corresponding new version
whenever possible or convenient. (If no tables are displayed, there are no items currently being
deprecated.)

ModelSim® SE User's Manual, v10.7 79

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Deprecated Features, Commands, and Variables

Table 1-4. Deprecated Features

Feature Version New Feature / Information
novopt 10.7 The -novopt argument to the vlog, vcom,
and vsim commands, as well as the
VoptFlow variable in the modelsim.ini file,
are now deprecated. If you use any these
features you will receive error number
12110. It is strongly recommended to
remove the novopt flow from your design
setup to avoid the 12110 error.
You can suppress this error to become a
warning with the number 8891, which is
not suppressible.
Also note that when vsim refreshes a
module or entity to regenerate ASM code,
this is also considered to be part of the
novopt flow, therefore the above messages
will also be issued.
Beginning with the 10.8 release, the novopt
flow will be removed completely.
UDP coverage support 10.7 In 10.7, UDP coverage is not supported.

80 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 2
Protecting Your Source Code

ModelSim’s encryption solution allows IP authors to deliver encrypted IP code for a wide range
of EDA tools and design flows.
ModelSim supports VHDL, Verilog, and SystemVerilog IP code encryption by means of
protected encryption envelopes. VHDL encryption is defined by the IEEE Std 1076-2008,
section 24.1 (titled “Protect tool directives”) and Annex H, section H.3 (titled “Digital
envelopes”). Verilog encryption is defined by IEEE Std 1364-2005, section 28; and
SystemVerilog encryption is defined by the IEEE Std 1800-2012, section 34 (both sections are
titled “Protected envelopes”). The digital envelopes usage model, as presented in Annex H
section H.3 of these standards, is the recommended methodology for users of VHDL’s `protect
and Verilog's `pragma protect compiler directives. We recommend that you obtain these
specifications for reference.

ModelSim supports version 1 of the recommendations from the IEEE P1735-2014 working
group for encryption interoperability between different encryption and decryption tools. It
addresses use model, algorithm choices, conventions, and minor corrections to the HDL
standards to achieve useful interoperability.

The IEEE Std 1735-2014 is a clarification of the separate Verilog and VHDL definitions of
source protection and applies to both languages. It addresses the inter-operable (that is, digital
envelope concept) parts incompletely defined for Verilog and VHDL. It also describes the idea
that protection involves using standard algorithms to encrypt/encode the original source code
into a form that any compliant tool can use.

ModelSim uses two protected forms:

• The first form is a text file that contains a transformed version of the input original plain
text HDL source file.
• The second form is a protected version of the design unit(s) you compile.
The ModelSim vencrypt utility for Verilog and SystemVerilog produces only text files. It does
not compile anything into a library, nor does it process macros or handle the usual Verilog
switches. In contrast, the Verilog/SystemVerilog compile command, vlog +protect, produces
text files, compiles them into the library, and processes macros (and all the other usual vlog
arguments).

The ModelSim vhencrypt utility for VHDL works the same as the vencrypt utility (though
VHDL does not have macros). The VHDL compile command, vcom +protect, works the same
as vlog.

ModelSim® SE User's Manual, v10.7 81

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code

When compiling source code, you can use either the vcom -nodebug or vlog -nodebug
command to hide the compiled result from an end user.

Encryption Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Compiling with +protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
The Runtime Encryption Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Language-Specific Usage Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Proprietary Source Code Encryption Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Encryption Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

82 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Encryption Envelopes

Encryption Envelopes
Encryption envelopes define a region of textual design data or code to be protected with
protection expressions. The protection expressions specify the encryption algorithm, the
encryption key owner, the key name, and envelope attributes.
The beginning and ending protection expressions for Verilog/SystemVerilog are `pragma
protect begin and `pragma protect end, respectively.

The beginning and ending protection expressions for VHDL are `protect BEGIN
PROTECTED and `protect END PROTECTED, respectively.

The encryption envelope may contain the code to be encrypted or it may contain `include
compiler directives that point to files containing the code to be encrypted.

You can combine symmetric and asymmetric keys in encryption envelopes to provide the safety
of asymmetric keys with the efficiency of symmetric keys (see Encryption and Encoding
Methods). The IP author can also use encryption envelopes to produce encrypted source files
that can be safely decrypted by multiple authors. For these reasons, encryption envelopes are the
preferred method of protection.

Creating Encryption Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Protection Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
The `include Compiler Directive (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Creating Encryption Envelopes

You can configure encryption envelopes to contain the actual code to encrypt or you can use
`include compiler directives to point to files containing the code to encrypt.
Prerequisites
Identify the region(s) of code to be encrypted, or the files that contain the code to be encrypted.

Procedure
1. Enclose the code you want to encrypt within protection directives; or, enclose the names
of the files that contain the code within protection directives.
2. Compile your code with ModelSim the appropriate encryption utility:
• Use the vencrypt command for Verilog and SystemVerilog design code.
• Use the vhencrypt command for VHDL design code.
• Or, use the vcom/vlog +protect command.
The flow diagram for creating encryption envelopes is shown in Figure 2-1.

ModelSim® SE User's Manual, v10.7 83

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Creating Encryption Envelopes

Figure 2-1. Create an Encryption Envelope

Examples
In the example shown in Figure 2-2, Verilog design data to be encrypted follows the `pragma
protect begin expression and ends with the `pragma protect end expression. If the design data
had been written in VHDL, the data to be protected would follow a `protect begin expression
and would end with a `protect end expression.

Figure 2-2. Encryption Envelope Contains Design Data to be Protected

84 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Creating Encryption Envelopes

module test_dff4(output [3:0] q, output err);

parameter WIDTH = 4;
parameter DEBUG = 0;
reg [3:0] d;
reg clk;

dff4 d4(q, clk, d);

assign err = 0;

initial
begin
$dump_all_vpi;
$dump_tree_vpi(test_dff4);
$dump_tree_vpi(test_dff4.d4);
$dump_tree_vpi("test_dff4");
$dump_tree_vpi("test_dff4.d4");
$dump_tree_vpi("test_dff4.d", "test_dff4.clk", "test_dff4.q");
$dump_tree_vpi("test_dff4.d4.d0", "test_dff4.d4.d3");
$dump_tree_vpi("test_dff4.d4.q", "test_dff4.d4.clk");
end
endmodule

module dff4(output [3:0] q, input clk, input [3:0] d);

`pragma protect data_method = "aes128-cbc"
`pragma protect author = "IP Provider"
`pragma protect author_info = "Widget 5 version 3.2"
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect begin
dff_gate d0(q[0], clk, d[0]);
dff_gate d1(q[1], clk, d[1]);
dff_gate d2(q[2], clk, d[2]);
dff_gate d3(q[3], clk, d[3]);
endmodule // dff4

module dff_gate(output q, input clk, input d);

wire preset = 1;
wire clear = 1;

nand #5
g1(l1,preset,l4,l2),
g2(l2,l1,clear,clk),
g3(l3,l2,clk,l4),
g4(l4,l3,clear,d),
g5(q,preset,l2,qbar),
g6(qbar,q,clear,l3);
endmodule
`pragma protect end

In the code shown in Figure 2-3, design data is contained in three files - diff.v, prim.v, and top.v.
This shows how to configure the encryption envelope so the entire contents of diff.v, prim.v, and
top.v are encrypted.

Figure 2-3. Encryption Envelope Contains `include Compiler Directives

ModelSim® SE User's Manual, v10.7 85

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Protection Expressions

`timescale 1ns / 1ps

`cell define

module dff (q, d, clear, preset, clock);

output q;
input d, clear, preset, clock;
reg q;

`pragma protect data_method = "aes128-cbc"

`pragma protect author = "IP Provider", author_info = "Widget 5 v3.2"
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect begin

`include diff.v
`include prim.v
`include top.v

`pragma protect end

always @(posedge clock)

q = d;

endmodule

`endcelldefine

For a more technical explanation, see How Encryption Envelopes Work and The `include
Compiler Directive (Verilog only).

Protection Expressions
The encryption envelope contains `pragma protect (Verilog/SystemVerilog) or `protect
(VHDL) expressions.
The expected encryption envelope expressions include:

• data_method — defines the encryption algorithm for encrypting the designated source
text. ModelSim supports the following encryption algorithms: des-cbc, 3des-cbc,
aes128-cbc, aes256-cbc, blowfish-cbc, cast128-cbc, and rsa.
• key_keyowner — designates the owner of the encryption key.
• key_keyname — specifies the keyowner’s key name.
• key_method — specifies an encryption algorithm for encrypting the key.

Note
The combination of key_keyowner and key_keyname expressions uniquely identify
a key. You must specify the key_method with these two expressions to complete the
definition of the key.

86 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
The `include Compiler Directive (Verilog only)

• begin — designates the beginning of the source code to encrypt.

• end — designates the end of the source code to encrypt.

Note
You cannot next encryption envelopes. A `pragma protect begin/end pair cannot
bracket another `pragma protect begin/end pair.

The optional encryption envelope protection expressions are:

• author — designates the IP provider.

• author_info — designates optional author information.
• encoding — specifies an encoding method. The default encoding method, if none is
specified, is “base 64.”
Protection expressions in a single protection directive are evaluated in order from left to right.
The interpretation of protected envelopes is not dependent on this order occurring in a single
protection expression or an order of protection expressions. However, the encryption utility uses
the most recent value assigned to a protection expression keyword.

Unsupported Protection Expressions

Optional, unsupported protection expressions include:

• any digest_* expression

• decrypt_license
• runtime_license
• viewport

The `include Compiler Directive (Verilog only)

Conceptual information abut using the‘include directive in Verilog files during encryption.
If any `include directives occur within a protected region of Verilog code and you use the vlog
+protect command to compile, the compiler generates a copy of the include file with a “.vp” or
a “.svp” extension and encrypts the entire contents of the include file.

Consider the following header file, header.v, consisting of the following source code:

initial begin
a <= b;
b <= c;
end

ModelSim® SE User's Manual, v10.7 87

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
The `include Compiler Directive (Verilog only)

and the file you want to encrypt, top.v, contains the following source code:

module top;
`pragma protect begin
`include "header.v"
`pragma protect end
endmodule

then, when you use the vlog +protect command to compile it will encrypt the source code of the
header file. If you could decrypt the resulting work/top.vp file it would look like:

module top;
`pragma protect begin
initial begin
a <= b;
b <= c;
end
`pragma protect end
endmodule

In addition, vlog +protect creates an encrypted version of header.v in work/header.vp.

When you use the vencrypt compile utility (see Delivering IP Code with Undefined Macros), it
will treat any `include statements as text just like any other source code and it will encrypt them
with the other Verilog/SystemVerilog source code. So, if you use the vencrypt utility on the
top.v file above, the resulting work/top.vp file would look like the following (if we could
decrypt it):

module top;
`protect
`include "header.v"
`endprotect
endmodule

The vencrypt utility will not create an encrypted version of header.h.

When you use vlog +protect to generate encrypted files, the original source files must all be
complete Verilog or SystemVerilog modules or packages. Compiler errors result if you attempt
to perform compilation of a set of parameter declarations within a module. (See also Compiling
with +protect.)

You can avoid such errors by creating a dummy module that includes the parameter
declarations. For example, if you have a file that contains your parameter declarations and a file
that uses those parameters, you can do the following:

module dummy;
`protect
`include "params.v" // contains various parameters
`include "tasks.v" // uses parameters defined in params.v
`endprotect
endmodule

88 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
The `include Compiler Directive (Verilog only)

Then, compile the dummy module with the +protect switch to generate an encrypted output file
with no compile errors, as follows:

vlog +protect dummy.v

After compilation, the work library contains encrypted versions of params.v and tasks.v, called
params.vp and tasks.vp. You can then copy these encrypted files out of the work directory to
more convenient locations.You can then include these encrypted files within your design. For
example:

module main
'include "params.vp"
'include "tasks.vp"
...

Portable Encryption for Multiple Tools

An IP author can use the concept of multiple key blocks to produce code that is secure and
portable across any tool that supports Version 1 recommendations from the IEEE P1735
working group. This capability is not language-specific—you can use it for VHDL or Verilog.

For example, suppose the author wants to modify the following VHDL sample file so the
encrypted model can be decrypted and simulated by both ModelSim and by a hypothetical
company named XYZ inc.

========== sample file ==========

-- The entity "ip1" is not protected

...
entity ip1 is
...
end ip1;

-- The architecture "a" is protected

-- The internals of "a" are hidden from the user
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" )
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect KEY_BLOCK
`protect begin
architecture a of ip1 is
...
end a;
`protect end

ModelSim® SE User's Manual, v10.7 89

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
The `include Compiler Directive (Verilog only)

-- Both the entity "ip2" and its architecture "a" are completely protected
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" )
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect KEY_BLOCK
`protect begin
library ieee;
use ieee.std_logic_1164.all;
entity ip2 is
...
end ip2;
architecture a of ip2 is
...
end a;
`protect end

========== end of sample file ==========

The author does this by writing a key block for each decrypting tool. If XYZ publishes a public
key, the two key blocks in the IP source code might look like the following:

`protect key_keyowner = "Mentor Graphics Corporation"

`protect key_method = "rsa"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect KEY_BLOCK
`protect key_keyowner = "XYZ inc"
`protect key_method = "rsa"
`protect key_keyname = "XYZ-keyPublicKey"
`protect key_public_key = <public key of XYZ inc.>
`protect KEY_BLOCK

The encrypted code would look very much like the sample file, with the addition of another key
block:

`protect key_keyowner = "XYZ inc"

`protect key_method = "rsa"
`protect key_keyname = "XYZ-keyPublicKey"
`protect KEY_BLOCK
<encoded encrypted key information for "XYZ inc">

ModelSim uses its key block to determine the encrypted session key and XYZ Incorporated
uses the second key block to determine the same key. Consequently, both implementations
could successfully decrypt the code.

Note
The IP owner is responsible for obtaining the appropriate key for the specific tool(s)
protected IP is intended for. The author should also validate the encrypted results with those
tools to ensure the IP is protected and will function as intended in those tools.

90 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Compiling with +protect

Compiling with +protect

To encrypt IP code with ModelSim, you must use the +protect argument must with either the
vcom command (for VHDL) or the vlog command (for Verilog and SystemVerilog).
Procedure
1. If a Verilog source code file containing encryption envelopes is named encrypt.v,
compile it as follows:
vlog +protect encrypt.v

When +protect is used with vcom or vlog, encryption envelope expressions are
transformed into decryption envelope expressions and decryption content expressions.
Source text within encryption envelopes is encrypted using the specified key and is
recorded in the decryption envelope within a data_block. The new encrypted file is
created with the same name as the original unencrypted file but with a ‘p’ added to the
filename extension. For Verilog, the filename extension for the encrypted file is .vp; for
SystemVerilog it is .svp, and for VHDL it is .vhdp. This encrypted file is placed in the
current work library directory.
2. You can designate the name of the encrypted file using the +protect=<filename>
argument with vcom or vlog as follows:
vlog +protect=encrypt.vp encrypt.v

Examples
Example 2-4 shows the resulting source code when the Verilog IP code used in Example 2-2 is
compiled with vlog +protect.

Figure 2-4. Results After Compiling with vlog +protect

module test_dff4(output [3:0] q, output err);

parameter WIDTH = 4;
parameter DEBUG = 0;
reg [3:0] d;
reg clk;
dff4 d4(q, clk, d);
assign err = 0;
initial
begin
$dump_all_vpi;
$dump_tree_vpi(test_dff4);
$dump_tree_vpi(test_dff4.d4);
$dump_tree_vpi("test_dff4");
$dump_tree_vpi("test_dff4.d4");
$dump_tree_vpi("test_dff4.d", "test_dff4.clk", "test_dff4.q");
$dump_tree_vpi("test_dff4.d4.d0", "test_dff4.d4.d3");
$dump_tree_vpi("test_dff4.d4.q", "test_dff4.d4.clk");
end
endmodule

ModelSim® SE User's Manual, v10.7 91

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
The Runtime Encryption Model

module dff4(output [3:0] q, input clk, input [3:0] d);

`pragma protect begin_protected
`pragma protect version = 1
`pragma protect encrypt_agent = "Model Technology"
`pragma protect encrypt_agent_info = "6.6a"
`pragma protect author = "IP Provider"
`pragma protect author_info = "Widget 5 version 3.2"
`pragma protect data_method = "aes128-cbc"
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect key_method = "rsa"
`pragma protect key_block encoding = (enctype = "base64", line_length =
64, bytes = 128)
SdI6t9ewd9GE4va+2BgfnRuBNc45wVwjyPeSD/5qnojnbAHdpjWa/O/Tyhw0aq1T
NbDGrDg6I5dbzbLs5UQGFtB2lgOBMnE4JTpGRfV0sEqUdibBHiTpsNrbLpp1iJLi
7l4kQhnivnUuCx87GuqXIf5AaoLGBz5rCxKyA47ElQM=
`pragma protect data_block encoding = (enctype = "base64", line_length =
64, bytes = 496)
efkkPz4gJSO6zZfYdr37fqEoxgLZ3oTgu8y34GTYkO0ZZGKkyonE9zDQct5d0dfe
/BZwoHCWnq4xqUp2dxF4x6cw6qBJcSEifCPDY1hJASoVX+7owIPGnLh5U0P/Wohp
LvkfhIuk2FENGZh+y3rWZAC1vFYKXwDakSJ3neSglHkwYr+T8vGviohIPKet+CPC
d/RxXOi2ChI64KaMY2/fKlerXrnXV7o9ZIrJRHL/CtQ/uxY7aMioR3/WobFrnuoz
P8fH7x/I30taK25KiL6qvuN0jf7g4LiozSTvcT6iTTHXOmB0fZiC1eREMF835q8D
K5lzU+rcb17Wyt8utm71WSu+2gtwvEp39G6R60fkQAuVGw+xsqtmWyyIOdM+PKWl
sqeoVOsBUHFY3x85F534PQNVIVAT1VzFeioMxmJWV+pfT3OlrcJGqX1AxAG25CkY
M1zF77caF8LAsKbvCTgOVsHb7NEqOVTVJZZydVy23VswClYcrxroOhPzmqNgn4pf
zqcFpP+yBnt4UELa63Os6OfsAu7DZ/4kWPAwExyvaahI2ciWs3HREcZEO+aveuLT
gxEFSm0TvBBsMwLc7UvjjC0aF1vUWhDxhwQDAjYT89r2h1G7Y0PGlGOo24s0/A2+
TjdCcOogiGsTDKx6Bxf91g==
`pragma protect end_protected

In this example, the `pragma protect data_method expression designates the encryption
algorithm used to encrypt the Verilog IP code. The key for this encryption algorithm is also
encrypted – in this case, with the RSA public key. The key is recorded in the key_block of the
protected envelope. The encrypted IP code is recorded in the data_block of the envelope.
ModelSim allows more than one key_block to be included so that a single protected envelope
can be encrypted by ModelSim, then decrypted by tools from different users.

The Runtime Encryption Model

Compiling with the +protect compile argument hides all source text, identifiers, and line
number information from the end user in the resulting compiled object.
Due to this behavior, ModelSim cannot locate or display any information of the encrypted
regions. Specifically, this means the following:

• The Source window will not display the source code of thedesign units.
• The Structure window will not display the internal structure.
• The Objects window will not display internal signals.
• The Processes window will not display internal processes.

92 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
The Runtime Encryption Model

• The Locals window will not display internal variables.

• You cannot access any of the hidden objects through the Dataflow or Schematic window
or with ModelSim commands.

ModelSim® SE User's Manual, v10.7 93

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Language-Specific Usage Models

Language-Specific Usage Models

Usage models for protecting your source code are language-specific.
Usage Models for Protecting Verilog Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Delivering IP Code with Undefined Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Delivering IP Code with User-Defined Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Usage Models for Protecting VHDL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using the vhencrypt Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

94 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

Usage Models for Protecting Verilog Source Code

The encryption capabilities of ModelSim support Verilog and SystemVerilog usage models for
IP authors and their customers.
• IP authors may use the vencrypt utility to deliver Verilog and SystemVerilog code
containing undefined macros and `directives. The IP user can then define the macros and
`directives and use the code in a wide range of EDA tools and design flows. See
Delivering IP Code with Undefined Macros.
• IP authors can use `pragma protect directives to protect Verilog and SystemVerilog
code containing user-defined macros and `directives. Authors can deliver the IP code to
IP customers for use in a wide range of EDA tools and design flows. See Delivering IP
Code with User-Defined Macros.
Delivering IP Code with Undefined Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Delivering IP Code with User-Defined Macros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Delivering IP Code with Undefined Macros

The vencrypt utility enables IP authors to deliver VHDL and Verilog/ SystemVerilog IP code
(respectively) that contains undefined macros and `directives. End users can then deploy the
resulting encrypted IP code in a wide range of EDA tools and design flows.
The recommended encryption usage flow is shown in Figure 2-5.

ModelSim® SE User's Manual, v10.7 95

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

Figure 2-5. Verilog/SystemVerilog Encryption Usage Flow

Procedure
1. The IP author creates code that contains undefined macros and `directives.
2. The IP author creates encryption envelopes (see Encryption Envelopes) to protect
selected regions of code or entire files (see Protection Expressions).
3. The IP author uses the vencrypt utility to encrypt Verilog and SystemVerilog code
contained within encryption envelopes. Macros are not pre-processed before encryption,
so macros and other `directives are unchanged.
The vencrypt utility produces a file with a .vp or a .svp extension to distinguish it from
non-encrypted Verilog and SystemVerilog files, respectively. You can change the file
extension for use with simulators other than ModelSim. The original file extension is
preserved if you specify the -d <dirname> argument with vencrypt, or if you use a
`directive in the file to be encrypted.
The IP author can use the -h <filename> argument for vencrypt to specify a header file
to encrypt a large number of files that do not contain the `pragma protect or proprietary
`protect information—see Proprietary Source Code Encryption Tools about how to
encrypt the file. Instead, encryption information is provided in the <filename> specified
by -h <filename>. This argument concatenates the header file onto the beginning of each
file so that you do not have to manually edit each file to add the same `pragma protect.

96 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

For example:
vencrypt -h encrypt_head top.v cache.v gates.v memory.v

concatenates the information in the encrypt_head file into each Verilog file listed. The
encrypt_head file may look like the following:
`pragma protect data_method = "aes128-cbc"
`pragma protect author = "IP Provider"
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-1"
`pragma protect encoding = (enctype = "base64")
`pragma protect begin

Notice that there is no `pragma protect end expression in the header file, just the
header block that starts the encryption. The `pragma protect end expression is implied
by the end of the file.
4. The IP author delivers encrypted IP with undefined macros and `directives.
5. The IP user defines macros and `directives.
6. The IP user compiles the design with vlog.
7. The IP user simulates the design with ModelSim or other simulation tools.

Delivering IP Code with User-Defined Macros

IP authors can use `pragma protect expressions to protect proprietary code containing user-
defined macros and `directives. End users can then deploy the resulting encrypted IP code in a
wide range of EDA tools and design flows.
The recommended usage flow for Verilog and SystemVerilog IP is shown in Figure 2-6.

ModelSim® SE User's Manual, v10.7 97

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

Figure 2-6. Delivering IP Code with User-Defined Macros

Procedure
1. The IP author creates proprietary code that contains user-defined macros and `directives.
2. The IP author creates encryption envelopes with `pragma protect expressions to protect
regions of code or entire files. See Encryption Envelopes and Protection Expressions.
3. The IP author uses the +protect argument for the vlog command to encrypt IP code
contained within encryption envelopes. The `pragma protect expressions are ignored
unless the +protect argument is used during compile. (See Compiling with +protect.)
4. (Optional) You can change the .vp or .vp extension of the encryted file so that the file
can be used by a simulator orther than ModelSim. The original file extension is
preserved if a `directive is used in the file to be encrypted. For more information, see
Compiling with +protect.
5. The IP author delivers the encrypted IP.
6. The IP user simulates the code like any other file.
Results
When encrypting source text, any macros without parameters defined on the command line are
substituted (not expanded) into the encrypted file. This makes certain macros unavailable in the
encrypted source text.

98 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

ModelSim takes every simple macro that is defined with the compile command (vlog) and
substitutes it into the encrypted text. This prevents third party users of the encrypted blocks
from having access to or modifying these macros.
Note
Macros not specified with vlog via the +define+ option are unmodified in the encrypted
block.

Examples
For example, the code below is an example of a file that might be delivered by an IP provider.
The filename for this module is example00.sv

`pragma protect data_method = "aes128-cbc"

`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect author = "Mentor", author_info = "Mentor_author"
`pragma protect begin
`timescale 1 ps / 1 ps

module example00 ();

`ifdef IPPROTECT
reg `IPPROTECT ;
reg otherReg ;
initial begin
`IPPROTECT = 1;
otherReg = 0;

$display("ifdef defined as true");

`define FOO 0
$display("FOO is defined as: ", `FOO);
$display("reg IPPROTECT has the value: ", `IPPROTECT );
end
`else
initial begin
$display("ifdef defined as false");
end
`endif

endmodule

`pragma protect end

The following vlog command encrypts the example00.sv module:

vlog +define+IPPROTECT=ip_value +protect=encrypted00.sv example00.sv

This creates an encrypted file called encrypted00.sv. You can then compile this file with a
macro override for the macro “FOO” as follows:

vlog +define+FOO=99 encrypted00.sv

ModelSim® SE User's Manual, v10.7 99

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting Verilog Source Code

A customer then can override the macro FOO while the macro IPPROTECT retains the value
specified at the time of encryption, and the macro IPPROTECT no longer exists in the
encrypted file.

100 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

Usage Models for Protecting VHDL Source Code

Encryption capabilities for VHDL are supported for a number of usage models.
Supported usage models include:

• IP authors can use `protect directives to create an encryption envelope (see Encryption
Envelopes) for the VHDL code to be protected and use ModelSim’s vhencrypt utility to
encrypt the code. The encrypted IP code can be delivered to IP customers for use in a
wide range of EDA tools and design flows. See Using the vhencrypt Utility.
• IP authors can use `protect directives to create an encryption envelope (see Encryption
Envelopes) for the VHDL code to be protected and use ModelSim’s default encryption
and decryption actions. The IP code can be delivered to IP customers for use in a wide
range of EDA tools and design flows. See ModelSim Default Encryption for VHDL.
• IP authors can use `protect directives to create an encryption envelope for VHDL code
and select encryption methods and encoding other than ModelSim’s default methods.
See User-Selected Encryption for VHDL.
• IP authors can use “raw” encryption and encoding to aid debugging. See Raw
Encryption for VHDL.
• IP authors can encrypt several parts of the source file, choose the encryption method for
encrypting the source (the data_method), and use a key automatically provided by
ModelSim. See Encryption of Several Parts of a VHDL Source File.
• IP authors can use the concept of multiple key blocks to produce code that is secure and
portable across different simulators. See Portable Encryption for Multiple Tools.

Note
VHDL encryption requires that the KEY_BLOCK (the sequence of key_keyowner,
key_keyname, and key_method directives) end with a `protect KEY_BLOCK directive.

Using the vhencrypt Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Using the vhencrypt Utility

The vhencrypt utility enables IP authors to deliver encrypted VHDL IP code to users. The
resulting encrypted IP code can then be used in a wide range of EDA tools and design flows.
Procedure
1. The IP author creates code.
2. The IP author creates encryption envelopes (see Encryption Envelopes) to protect
selected regions of code or entire files (see Protection Expressions).

ModelSim® SE User's Manual, v10.7 101

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

3. The IP author uses the ModelSim vhencrypt utility to encrypt code contained within
encryption envelopes.
The vhencrypt utility produces a file with a .vhdp or a .vhdlp extension to distinguish it
from non-encrypted VHDL files.
4. (Optional) Change the file extension for use with simulators other than ModelSim.
The original file extension is preserved if the -d <dirname> argument is used with
vhencrypt.
5. (Optional) use the -h <filename> argument for vencrypt the IP author may specify a
header file that can be used to encrypt a large number of files that do not contain the
`protect information about how to encrypt the file.
Instead, encryption information is provided in the <filename> specified by -h
<filename>. This argument essentially concatenates the header file onto the beginning
of each file and saves the user from having to edit hundreds of files in order to add in the
same `protect to every file.
For example:
vhencrypt -h encrypt_head top.vhd cache.vhd gates.vhd memory.vhd

concatenates the information in the encrypt_head file into each VHDL file listed. The
encrypt_head file may look like the following:
`protect data_method = "aes128-cbc"
`protect author = "IP Provider"
`protect encoding = (enctype = "base64")
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_method = "rsa"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect KEY_BLOCK
`protect begin

Notice that there is no `protect end expression in the header file, just the header block
that starts the encryption. The `protect end expression is implied by the end of the file.
6. The IP author delivers encrypted IP.
7. The IP user compiles the design with vcom.
8. The IP user simulates the design with ModelSim or other simulation tools.
Examples
ModelSim Default Encryption for VHDL
Suppose an IP author needs to make a design entity, called IP1, visible to the user so the user
can instantiate the design, but the author wants to hide the architecture implementation from the
user. In addition, suppose that IP1 instantiates entity IP2, which the author wants to hide
completely from the user. The easiest way to accomplish this is to surround the regions to be

102 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

protected with `protect begin and `protect end directives and let ModelSim choose default
actions. For this example, all the source code exists in a single file, example1.vhd:

========== file example1.vhd ==========

-- The entity "ip1" is not protected
...
entity ip1 is
...
end ip1;
-- The architecture "a" is protected
-- The internals of "a" are hidden from the user
`protect begin
architecture a of ip1 is
...
end a;
`protect end
-- Both the entity "ip2" and its architecture "a" are completely protected
`protect begin
entity ip2 is
...
end ip2;
architecture a of ip2 is
...
end a;
`protect end
========== end of file example1.vhd ==========

The IP author compiles this file with the vcom +protect command as follows:

vcom +protect=example1.vhdp example1.vhd

ModelSim® SE User's Manual, v10.7 103

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

The compiler produces an encrypted file, example1.vhdp which looks like the following:

========== file example1.vhdp ==========

-- The entity "ip1" is not protected
...
entity ip1 is
...
end ip1;
-- The architecture "a" is protected
-- The internals of "a" are hidden from the user
`protect BEGIN_PROTECTED
`protect version = 1
`protect encrypt_agent = "Model Technology", encrypt_agent_info = "DEV"
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect encoding = ( enctype = "base64" )
`protect KEY_BLOCK
<encoded encrypted session key>
`protect data_method="aes128-cbc"
`protect encoding = ( enctype = "base64" , bytes = 224 )
`protect DATA_BLOCK
<encoded encrypted IP>
`protect END_PROTECTED
-- Both the entity "ip2" and its architecture "a" are completely protected
`protect BEGIN_PROTECTED
`protect version = 1
`protect encrypt_agent = "Model Technology", encrypt_agent_info = "DEV"
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect encoding = ( enctype = "base64" )
`protect KEY_BLOCK
<encoded encrypted session key>
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" , bytes = 224 )
`protect DATA_BLOCK
<encoded encrypted IP>
`protect END_PROTECTED
========== end of file example1.vhdp ==========

When the IP author surrounds a text region using only `protect begin and `protect end,
ModelSim uses default values for both encryption and encoding. The first few lines following
the `protect BEGIN_PROTECTED region in file example1.vhdp contain the key_keyowner,
key_keyname, key_method and KEY_BLOCK directives. The session key is generated into the
key block, and that key block is encrypted using the “rsa” method. The data_method indicates
that the default data encryption method is aes128-cbc, and the “enctype” value shows that the
default encoding is base64.

Alternatively, the IP author can compile file example1.vhd with the command:

vcom +protect example1.vhd

Here, the author does not supply the name of the file to contain the protected source. Instead,
ModelSim creates a protected file, gives it the name of the original source file with a 'p' placed

104 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

at the end of the file extension, and puts the new file in the current work library directory. With
the command described above, ModelSim creates file work/example1.vhdp. (See Compiling
with +protect.)

The IP user compiles the encrypted file work/example1.vhdp the ordinary way. The +protect
switch is not needed and the IP user does not have to treat the .vhdp file in any special manner.
ModelSim automatically decrypts the file internally and keeps track of protected regions.

If the IP author compiles the file example1.vhd and does not use the +protect argument, then the
file is compiled, various `protect directives are checked for correct syntax, but no protected file
is created and no protection is supplied.

In ModelSim, default encryption methods provide an easy way for IP authors to encrypt VHDL
designs while hiding the architecture implementation from the user. The results are usable only
by ModelSim tools.

User-Selected Encryption for VHDL

Suppose that the IP author wants to reproduce the code shown in the example1.vhd file used
above, but wants to provide specific values and not use any default values. To do this the author

ModelSim® SE User's Manual, v10.7 105

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

adds `protect directives for keys, encryption methods, and encoding, and places them before
each `protect begin directive. The input file would look like the following:

========== file example2.vhd ==========

-- The entity "ip1" is not protected
...
entity ip1 is
...
end ip1;
-- The architecture "a" is protected
-- The internals of "a" are hidden from the user
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" )
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect KEY_BLOCK
`protect begin
architecture a of ip1 is
...
end a;
`protect end
-- Both the entity "ip2" and its architecture "a" are completely protected
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" )
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`protect key_method = "rsa"
`protect KEY_BLOCK
`protect begin
library ieee;
use ieee.std_logic_1164.all;
entity ip2 is
...
end ip2;
architecture a of ip2 is
...
end a;
`protect end
========== end of file example2.vhd ==========

The data_method directive indicates that the encryption algorithm “aes128-cbc” should be used
to encrypt the source code (data). The encoding directive selects the “base64” encoding method,
and the various key directives specify that the Mentor Graphic key named “MGC-VERIF-SIM-
RSA-2” and the “RSA” encryption method are to be used to produce a key block containing a
randomly generated session key to be used with the “aes128-cbc” method to encrypt the source
code. See Using the Mentor Graphics Public Encryption Key.

106 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

Raw Encryption for VHDL

Suppose that the IP author wants to use “raw” encryption and encoding to help with debugging
the following entity:

entity example3_ent is port (

in1 : in bit;
out1 : out bit);
end example3_ent;

Then the architecture the author wants to encrypt might be this:

========== File example3_arch.vhd

`protect data_method = "raw"
`protect encoding = ( enctype = "raw")
`protect begin
architecture arch of example3_ent is begin out1 <= in1 after 1 ns; end
arch;
`protect end
========== End of file example3_arch.vhd ==========

If (after compiling the entity) the example3_arch.vhd file were compiled using the command:

vcom +protect example3_arch.vhd

Then the following file would be produced in the work directory

========== File work/example3_arch.vhdp ==========

`protect data_method = "raw"
`protect encoding = ( enctype = "raw")
`protect BEGIN_PROTECTED
`protect version = 1
`protect encrypt_agent = "Model Technology", encrypt_agent_info = "DEV"
`protect data_method = "raw"
`protect encoding = ( enctype = "raw", bytes = 81 )
`protect DATA_BLOCK
architecture arch of example3_ent is
begin
out1 <= in1 after 1 ns;
end arch;
`protect END_PROTECTED
========== End of file work/example3_arch.vhdp

Notice that the protected file is very similar to the original file. The differences are that `protect
begin is replaced by `protect BEGIN_PROTECTED, `protect end is replaced by `protect
END_PROTECTED, and some additional encryption information is supplied after the BEGIN
PROTECTED directive.

See Encryption and Encoding Methods for more information about raw encryption and
encoding.

Encryption of Several Parts of a VHDL Source File

This example shows the use of symmetric encryption. (See Encryption and Encoding Methods
for more information on symmetric and asymmetric encryption and encoding.) It also

ModelSim® SE User's Manual, v10.7 107

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

demonstrates another common use model, in which the IP author encrypts several parts of a
source file, chooses the encryption method for encrypting the source code (the data_method),
and uses a key automatically provided by ModelSim. (This is very similar to the proprietary
`protect method in Verilog - see Proprietary Source Code Encryption Tools.)

========== file example4.vhd ==========

entity ex4_ent is
end ex4_ent;
architecture ex4_arch of ex4_ent is
signal s1: bit;
`protect data_method = "aes128-cbc"
`protect begin
signal s2: bit;
`protect end
signal s3: bit;
begin -- ex4_arch
`protect data_method = "aes128-cbc"
`protect begin
s2 <= s1 after 1 ns;
`protect end
s3 <= s2 after 1 ns;
end ex4_arch;
========== end of file example4.vhd

If this file were compiled using the command:

vcom +protect example4.vhd

108 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Usage Models for Protecting VHDL Source Code

Then the following file would be produced in the work directory:

========== File work/example4.vhdp ==========

entity ex4_ent is
end ex4_ent;
architecture ex4_arch of ex4_ent is
signal s1: bit;
`protect data_method = "aes128-cbc"
`protect BEGIN_PROTECTED
`protect version = 1
`protect encrypt_agent = "Model Technology", encrypt_agent_info = "DEV"
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" , bytes = 18 )
`protect DATA_BLOCK
<encoded encrypted declaration of s2>
`protect END_PROTECTED
signal s3: bit;
begin -- ex4_arch
`protect data_method = "aes128-cbc"
`protect BEGIN_PROTECTED
`protect version = 1
`protect encrypt_agent = "Model Technology", encrypt_agent_info = "DEV"
`protect data_method = "aes128-cbc"
`protect encoding = ( enctype = "base64" , bytes = 21 )
`protect DATA_BLOCK
<encoded encrypted signal assignment to s2>
`protect END_PROTECTED
s3 <= s2 after 1 ns;
end ex4_arch;
========== End of file work/example4.vhdp

The encrypted example4.vhdp file shows that an IP author can encrypt both declarations and
statements. Also, note that the signal assignment

s3 <= s2 after 1 ns;

is not protected. This assignment compiles and simulates even though signal s2 is protected. In
general, executable VHDL statements and declarations simulate the same whether or not they
refer to protected objects.

ModelSim® SE User's Manual, v10.7 109

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Proprietary Source Code Encryption Tools

Proprietary Source Code Encryption Tools

Mentor Graphics provides two proprietary methods for encrypting source code.
• The `protect / `endprotect compiler directives allow you to encrypt regions within
Verilog and SystemVerilog files.
• The -nodebug argument for the vcom and vlog compile commands allows you to
encrypt entire VHDL, Verilog, or SystemVerilog source files.
Using Proprietary Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Protecting Source Code Using -nodebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Using Proprietary Compiler Directives

The proprietary `protect vlog compiler directive is not compatible with other simulators.
Though other simulators have a `protect directive, the algorithm ModelSim uses to encrypt
Verilog and SystemVerilog source files is different. Therefore, even though an uncompiled
source file with `protect is compatible with another simulator, once the source is compiled in
ModelSim, the resulting .vp or .svp source file is not compatible.
Note
While ModelSim supports both `protect and `pragma protect encryption directives, these
two approaches to encryption are incompatible. Code encrypted by one type of directive
cannot be decrypted by another.

The usage flow for delivering IP with the Mentor Graphics proprietary `protect compiler
directive is as follows:

Figure 2-7. Delivering IP with `protect Compiler Directives

110 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Protecting Source Code Using -nodebug

Procedure
1. The IP author protects selected regions of Verilog or SystemVerilog IP with the `protect
/ `endprotect directive pair. The code in `protect / `endprotect encryption envelopes
has all debug information stripped out. This behaves exactly as if using
vlog -nodebug=ports+pli

except that it applies to selected regions of code rather than the whole file.
2. The IP author uses the vlog +protect command to encrypt IP code contained within
encryption envelopes. The `protect / `endprotect directives are ignored by default
unless the +protect argument is used with vlog.
3. Copy the original source file to a new file in the current work directory.
The vlog +protect command produces a .vp or a .svp extension to distinguish it from
other non-encrypted Verilog and SystemVerilog files, respectively. For example, top.v
becomes top.vp and cache.sv becomes cache.svp.
4. Deliver the new file to be used as a replacement for the original source file. (See
Compiling with +protect.)

Note
Use the vencrypt utility if the code also contains undefined macros or `directives, but
the code must then be compiled and simulated with ModelSim.

You can use vlog +protect=<filename> to create an encrypted output file, with the
designated filename, in the current directory (not in the work directory, as in the default
case where [=<filename>] is not specified). For example:
vlog test.v +protect=test.vp

If the filename is specified in this manner, all source files on the command line will be
concatenated together into a single output file. Any `include files will also be inserted
into the output file.

Restriction
`protect and `endprotect directives cannot be nested.

If errors are detected in a protected region, the error message always reports the first line
of the protected block.

Protecting Source Code Using -nodebug

You or IP authors can use the proprietary vlog -nodebug or vcom -nodebug command to protect
entire files. The -nodebug argument for both vcom and vlog hides internal model data, allowing
you to provide pre-compiled libraries without providing source code and without revealing
internal model variables and structure.

ModelSim® SE User's Manual, v10.7 111

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Protecting Source Code Using -nodebug

Prerequisites
Identify files to be encrypted.

Note
The -nodebug argument encrypts entire files. The `protect compiler directive allows you to
encrypt regions within a file. Refer to Compiler Directives for details.

Procedure
1. Compile VHDL files to be encrypted with the vcom -nodebug command.
2. Compile Verilog/SystemVerilog files to be encrypted with the vlog -nodebug command.
When you compile with -nodebug, all source text, identifiers, and line number
information are stripped from the resulting compiled object, so ModelSim cannot locate
or display any information of the model except for the external pins.
You can access the design units that constitute your model by using the library, and you
can invoke vsim directly on any of these design units to see the ports. To restrict even
this access in the lower levels of your design, you can use the following -nodebug
options when you compile:

Table 2-1. Compile Options for the -nodebug Compiling

Command and Switch Result
vcom -nodebug=ports makes the ports of a VHDL design unit
invisible
vlog -nodebug=ports makes the ports of a Verilog design unit
invisible
vlog -nodebug=pli prevents the use of PLI functions to
interrogate the module for information
vlog -nodebug=ports+pli combines the functions of -nodebug=ports
and -nodebug=pli

Tip
Do not use the =ports option on a design without hierarchy, or on the top level of a
hierarchical design. If you do, no ports will be visible for simulation. Rather,
compile all lower portions of the design with -nodebug=ports first, then compile the top
level with -nodebug alone.

Note
Design units or modules compiled with -nodebug can only instantiate design units
or modules that are also compiled -nodebug.

112 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Protecting Source Code Using -nodebug

Do not use -nodebug=ports when the parent is part of a vopt -pdu (black-box) flow or for
mixed language designs, especially for Verilog modules to be instantiated inside VHDL.

ModelSim® SE User's Manual, v10.7 113

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Encryption Reference

Encryption Reference
The Encryption Reference includes important information about encryption and encoding
methods, details on how encryption envelopes work, how to use public encryption keys, and
how to use the Mentor Graphics public encryption key.
Encryption and Encoding Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
How Encryption Envelopes Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Using Public Encryption Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Using the Mentor Graphics Public Encryption Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Encryption and Encoding Methods

ModelSim supports two encryption techniques — symmetric and asymmetric.
The two encryption techniques are summarized as follows

• Symmetric Encryption uses the same key for both encrypting and decrypting the code
region.
• Asymmetric Encryption uses two keys: a public key for encryption, and a private key for
decryption.

Symmetric Encryption
For symmetric encryption, security of the key is critical and information about the key must be
supplied to ModelSim. Under certain circumstances, ModelSim will generate a random key for
use with a symmetric encryption method or will use an internal key.

The symmetric encryption algorithms ModelSim supports are:

• des-cbc
• 3des-cbc
• aes128-cbc
• aes192-cbc
• aes256-cbc
• blowfish-cbc
• cast128-cbc
The default symmetric encryption method ModelSim uses for encrypting IP source code is
aes128-cbc.

114 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
How Encryption Envelopes Work

Asymmetric Encryption
For asymmetric encryption, the public key is openly available and is published using some form
of key distribution system. The private key is secret and is used by the decrypting tool, such as
ModelSim. Asymmetric methods are more secure than symmetric methods, but take much
longer to encrypt and decrypt data.

The only asymmetric method ModelSim supports is:

• rsa
This method is supported only for specifying key information, not for encrypting IP source code
(that is, only for key methods, not for data methods).

For testing purposes, ModelSim also supports raw encryption, which does not change the
protected source code (the simulator still hides information about the protected region).

All encryption algorithms (except raw) produce byte streams that contain non-graphic
characters. Therefore, there needs to be an encoding mechanism to transform arbitrary byte
streams into portable sequences of graphic characters, which can be used to put encrypted text
into source files. The encoding methods supported by ModelSim are:

• uuencode
• base64
• raw
Base 64 encoding is the default method used by ModelSim. Because it is technically superior to
uuencode, it is the recommended encoding for all applications.

Restriction
Raw encoding must only be used in conjunction with raw encryption for testing purposes.

How Encryption Envelopes Work

Encryption envelopes define how tools handle the code you need to protect.
The general flow of how encryption envelopes works is as follows:

• The encrypting tool generates a random key for use with a symmetric method, called a
“session key.”
• The IP protected source code is encrypted using this session key.
• The encrypting tool communicates the session key to the decrypting tool, which can be
ModelSim or some other tool, by means of a KEY_BLOCK.

ModelSim® SE User's Manual, v10.7 115

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Using Public Encryption Keys

• For each potential decrypting tool, information about that tool must be provided in the
encryption envelope. This information includes the owner of the key (key_keyowner),
the name of the key (key_keyname), the asymmetric method for encrypting/decrypting
the key (key_method), and sometimes the key itself (key_public_key).
• The encrypting tool uses this information to encrypt and encode the session key into a
KEY_BLOCK. The occurrence of a KEY_BLOCK in the source code tells the
encrypting tool to generate an encryption envelope.
• The decrypting tool reads each KEY_BLOCK until it finds one that specifies a key it
knows about. It then decrypts the associated KEY_BLOCK data to determine the
original session key and uses that session key to decrypt the IP source code.

Note
VHDL encryption requires that the KEY_BLOCK (the sequence of key_keyowner,
key_keyname, and key_method directives) end with a `protect KEY_BLOCK
directive.

Using Public Encryption Keys

IP authors who want to encrypt for third party EDA tools you must specify other public keys.
Procedure
Specify the key_public_key directive.

These examples define a new key named “AcmeKeyName” with a key owner of
“Acme.” The data block following key_public_key directive is an example of a base64
encoded version of a public key that should be provided by a tool vendor.
For Verilog and SystemVerilog:
`pragma protect key_keyowner="Acme"
`pragma protect key_keyname="AcmeKeyName"
`pragma protect key_public_key
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnJfQb+LLzTMX3NRARsv7A8+LV5Sg
MEJCvIf9Tif2emi4z0qtp8E+nX7QFzocTlClC6Dcq2qIvEJcpqUgTTD+mJ6grJSJ+R4
AxxCgvHYUwoT80Xs0QgRqkrGYxW1RUnNBcJm4ZULexYz8972Oj6rQ99n5e1kDa/
eBcszMJyOkcGQIDAQAB

For VHDL:
`protect key_keyowner="Acme"
`protect key_keyname="AcmeKeyName"
`protect key_public_key
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnJfQb+LLzTMX3NRARsv7A8+LV5Sg
MEJCvIf9Tif2emi4z0qtp8E+nX7QFzocTlClC6Dcq2qIvEJcpqUgTTD+mJ6grJSJ+R4
AxxCgvHYUwoT80Xs0QgRqkrGYxW1RUnNBcJm4ZULexYz8972Oj6rQ99n5e1kDa/
eBcszMJyOkcGQIDAQAB

116 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Using the Mentor Graphics Public Encryption Key

Using the Mentor Graphics Public Encryption Key

ModelSim provides public encryption keys to support interoperability across products,
including those from different tool vendors.
The ModelSim public key uses RSA 2048 encryption.

The key_keyname value is MGC-VERIF-SIM-RSA-2.

The key_public_key value is:

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtNA6tJ1tV/cXF4K5mL4s
4KCuTKWSbN/BnJJ6elRTWr2+s5Baaul0ctIX/3KYzpITmG9ph/4uZBs+jV5DAC+9
WRZQDc11JdIlRi04dEx/bGVbfPs3pdTPFZjA6gfegdW03ZNhjaJChTwEoXL1xIGP
oodJyhX9r1DoxU2lWB19vpwI5Geygh6pYgkPXb0aQzLh6hyUBhH9yMN6eV+imBbO
eax8ZCO6Gz2CJq3ebS/JoMYrikgcIEf6kVhIOiB9LluTp6TZlSd8ilwPhQmfXWH2
w4CaIpN8kADaVHnDWIdqqHlGf3cNQrlWj6FnFpSam6PjmWp5ZD4Jt6UNJxEoKEsn
gwIDAQAB

The previous key, MGC-VERIF-SIM-RSA-1, has been deprecated and is no longer

recommended for new encryptions. See Deprecated Encryption for use of deprecated keys.

The following is an example of using the key with Verilog and SystemVerilog applications:

`pragma protect key_keyowner = "Mentor Graphics Corporation"

`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect data_method = "aes128-cbc"
`pragma protect key_public_key
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtNA6tJ1tV/cXF4K5mL4s
4KCuTKWSbN/BnJJ6elRTWr2+s5Baaul0ctIX/3KYzpITmG9ph/4uZBs+jV5DAC+9
WRZQDc11JdIlRi04dEx/bGVbfPs3pdTPFZjA6gfegdW03ZNhjaJChTwEoXL1xIGP
oodJyhX9r1DoxU2lWB19vpwI5Geygh6pYgkPXb0aQzLh6hyUBhH9yMN6eV+imBbO
eax8ZCO6Gz2CJq3ebS/JoMYrikgcIEf6kVhIOiB9LluTp6TZlSd8ilwPhQmfXWH2
w4CaIpN8kADaVHnDWIdqqHlGf3cNQrlWj6FnFpSam6PjmWp5ZD4Jt6UNJxEoKEsn
gwIDAQAB
`pragma protect begin

Caution
The encryption key will not work if extraneous characters or spaces of any type are inserted
during copy and paste operations.

The vencrypt utility recognizes the ModelSim public key. If you do not use vencrypt, you must
use the +protect switch with the vlog command during compile.

ModelSim® SE User's Manual, v10.7 117

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Using the Mentor Graphics Public Encryption Key

The following is an example of using the key with VHDL applications:

`protect key_keyowner = "Mentor Graphics Corporation"

`protect key_method = "rsa"
`protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect data_method = "aes128-cbc"
`protect key_public_key
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtNA6tJ1tV/cXF4K5mL4s
4KCuTKWSbN/BnJJ6elRTWr2+s5Baaul0ctIX/3KYzpITmG9ph/4uZBs+jV5DAC+9
WRZQDc11JdIlRi04dEx/bGVbfPs3pdTPFZjA6gfegdW03ZNhjaJChTwEoXL1xIGP
oodJyhX9r1DoxU2lWB19vpwI5Geygh6pYgkPXb0aQzLh6hyUBhH9yMN6eV+imBbO
eax8ZCO6Gz2CJq3ebS/JoMYrikgcIEf6kVhIOiB9LluTp6TZlSd8ilwPhQmfXWH2
w4CaIpN8kADaVHnDWIdqqHlGf3cNQrlWj6FnFpSam6PjmWp5ZD4Jt6UNJxEoKEsn
gwIDAQAB
`pragma protect begin

The vhencrypt utility recognizes the ModelSim public key. If you do not use vhencrypt, you
must use the +protect switch with the vcom command during compile.

Example 2-1 illustrates the encryption envelope methodology for using this key in Verilog/
SystemVerilog. With this methodology you can collect the public keys from the various
companies whose tools process your IP, then create a template to include in the files you want to
encrypt. During the encryption phase, a symmetric session key is created for each block of HDL
source being encrypted. This session key itself is encrypted and encoded using each public key
found in the pragmas that form the encryption envelope that contains the block.

118 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Protecting Your Source Code
Using the Mentor Graphics Public Encryption Key

Example 2-1. Using the Mentor Graphics Public Encryption Key in Verilog/
SystemVerilog

//
// Copyright 1991-2009 Mentor Graphics Corporation
//
// All Rights Reserved.
//
// THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION WHICH IS
THE PROPERTY OF
// MENTOR GRAPHICS CORPORATION OR ITS LICENSORS AND IS SUBJECT TO LICENSE
TERMS.
//
`timescale 1ns / 1ps
`celldefine
module dff (q, d, clear, preset, clock); output q; input d, clear, preset,
clock; reg q;
`pragma protect data_method = "aes128-cbc"
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-2"
`pragma protect key_public_key
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtNA6tJ1tV/cXF4K5mL4s
4KCuTKWSbN/BnJJ6elRTWr2+s5Baaul0ctIX/3KYzpITmG9ph/4uZBs+jV5DAC+9
WRZQDc11JdIlRi04dEx/bGVbfPs3pdTPFZjA6gfegdW03ZNhjaJChTwEoXL1xIGP
oodJyhX9r1DoxU2lWB19vpwI5Geygh6pYgkPXb0aQzLh6hyUBhH9yMN6eV+imBbO
eax8ZCO6Gz2CJq3ebS/JoMYrikgcIEf6kVhIOiB9LluTp6TZlSd8ilwPhQmfXWH2
w4CaIpN8kADaVHnDWIdqqHlGf3cNQrlWj6FnFpSam6PjmWp5ZD4Jt6UNJxEoKEsn
gwIDAQAB
`pragma protect key_keyowner = "XYZ inc"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "XYZ-keyPublicKey"
`pragma protect key_public_key
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRt2vMixpphSrMeo4Ts1NheFBC
nmZ5mWJSs6Rwhov9NDbmKcUDKU1WPcaj4X1PWHHh5cvE8b/mGs6uzfAbXbJbe8qz
0svQ3GqD+moEO3c5pL3CdmksOOx80EgnQUbiqovuc/80UiiosgELROcXHmGKxVpm
W9nRnavODbg8BYMj7QIDAQAB
`pragma protect begin
always @(clear or preset)
if (!clear)
assign q = 0;
else if (!preset)
assign q = 1;
else
deassign q;
`pragma protect end
always @(posedge clock)
q = d;
endmodule
`endcelldefine

Decrease Decoding Time

While the MGC-VERIF-SIM-RSA-2 provides the strongest protection for your code, with RSA
2048 encryption, it comes with a significant performance cost. To enable faster decoding,
ModelSim provides an encryption key of half the size, using RSA 1024 encryption. Since

ModelSim® SE User's Manual, v10.7 119

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Protecting Your Source Code
Using the Mentor Graphics Public Encryption Key

decryption performance varies with the cube of the key size, you can achieve a nominal 8x
performance improvement with the smaller key. This public key is named MGC-VERIF-SIM-
RSA-3. The key is:

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1hm/RxfJSXLzWIpTJWdyCDFXo
bHK1nLmxQCqPK9jjEY+cUgX90lstOWPfCljl3dMOnDNkCS1+owUAiVHCXZGa/agP
gq77ioheQgXpY2kViTdgjdsjoWTIYt2ROpRO0BmJRGpXc1wT9GoFH2MYjomhNqd7
jELfuwfMUnUAft0zXQIDAQAB

Use the MGC-VERIF-SIM-RSA-3 key exactly as you would the MGC-VERIF-SIM-RSA-2

key:

• For Verilog and SystemVerilog applications, copy and paste the entire ModelSim key
block, as follows, into your code:
`pragma protect key_keyowner = "Mentor Graphics Corporation"
`pragma protect key_method = "rsa"
`pragma protect key_keyname = "MGC-VERIF-SIM-RSA-3"
`pragma protect key_public_key
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1hm/RxfJSXLzWIpTJWdyCDFXo
bHK1nLmxQCqPK9jjEY+cUgX90lstOWPfCljl3dMOnDNkCS1+owUAiVHCXZGa/agP
gq77ioheQgXpY2kViTdgjdsjoWTIYt2ROpRO0BmJRGpXc1wT9GoFH2MYjomhNqd7
jELfuwfMUnUAft0zXQIDAQAB

• For VHDL applications, copy and paste the entire ModelSim key block, as follows, into
your code:
`protect key_keyowner = "Mentor Graphics Corporation"
`protect key_method = "rsa"
`protect key_keyname = "MGC-VERIF-SIM-RSA-3"
`protect key_public_key
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1hm/RxfJSXLzWIpTJWdyCDFXo
bHK1nLmxQCqPK9jjEY+cUgX90lstOWPfCljl3dMOnDNkCS1+owUAiVHCXZGa/agP
gq77ioheQgXpY2kViTdgjdsjoWTIYt2ROpRO0BmJRGpXc1wT9GoFH2MYjomhNqd7
jELfuwfMUnUAft0zXQIDAQAB

Deprecated Encryption
As part of our IEEE 1735 encryption work, ModelSim has deprecated some older encryption
keys. Use of these keys during encryption will trigger a warning. This warning may be ignored
if you want to continue to encrypt with the deprecated keys.

The ModelSim methodology for key deprecation is based on file presence, which recognizes
that the decision to deprecate may be made either by the ModelSim encryption tool, or by you—
as a site-management decision. The presence of a file named <keyname>.deprecated in the
installation subdirectory /keyring triggers this warning for <keyname>. The current working
directory is also checked for deprecated files. These files may be managed by the CAD tools
team to indicate that keys are, or are not, deprecated.

120 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 3
Optimizing Designs with vopt

ModelSim, by default, performs built-in optimizations on your design to maximize simulator

performance.
The optimizations limit the visibility of design objects, but you can increase visibility of any
objects for debugging purposes, as described in the section "Preservation of Object Visibility
for Debugging."

The command you use to perform global optimizations in ModelSim is vopt. This chapter
discusses vopt functionality, the effects of optimization on your design, and how to customize
the application of vopt to your design. For more information on syntax and usage of this
command, refer to in the Reference Manual.

Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Preservation of Object Visibility for Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Negation Arguments and Resolution with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Optimization of Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Preoptimizing Regions of Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Alternate Optimization Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Preserving Design Visibility with the Learn Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Controlling Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Optimization Considerations for Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

ModelSim® SE User's Manual, v10.7 121

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Optimization Flows

Optimization Flows
You can use either a three-step or a two-step flow to control optimizations for your simulation
run.
• Three-Step Flow — where you perform compilation, optimization, and simulation in
three separate steps.
• Two-Step Flow — where you perform compilation and simulation in two separate steps
and optimization is implicitly run prior to simulation.

Note
It is recommended that you use the three-step flow for optimizing and simulating your
design. Because this flow includes explicit use of the vopt command, you can take
advantage of its numerous arguments to apply fine-grained control of the optimization step.

The three-step flow also allows you to reuse optimized images, which means you do not have to
repeat optimization for unchanged designs. Further, these images can reside in a separate
library.

Unless you have a specific situation that requires a more simplified flow and are aware of its
limitations, you should use the three-step flow.

Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
The -O Optimization Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Inlined Modules and the Implications of Coverage Settings . . . . . . . . . . . . . . . . . . . . . . 126

Three-Step Flow
The three-step flow includes using the vopt command, which provides you with the most
control over the optimization process.
The steps for this flow consist of the following ModelSim commands:

1. Compilation — vcom or vlog

2. Optimization — vopt
You can use the optimized output of the vopt command for multiple simulation runs.
Refer to Name Requirements for the Optimized Design for additional information on
specifying the name of the generated output.
3. Simulation — vsim

122 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Three-Step Flow

The three-step flow provides several advantages in using ModelSim, including:

• Using preoptimized design units (PDU) — Reduces the amount of time necessary for
future optimization and simulation runs by preoptimizing (black-boxing) regions of your
design using the -pdu argument, as described in the section "Preoptimizing Regions of
Your Design."
• Performing a simulation for debug — Preserves the highest level of visibility by
specifying the +acc argument to vopt. For example:
vlog -work <required_files>
vopt +acc top -o dbugver
vsim dbugver

• Performing a simulation for regression — Reduces the amount of visibility because you
are not as concerned about debugging. For example:
vlog -work <required_files>
vopt top -o optver
vsim optver

Preserving Object Visibility with vopt

With the three-step flow, you can preserve object visibility by using any of several access
visibility arguments available for the vopt command (see Table 3-1 on page 127). That is, do
not omit the vopt command in order to increase object visibility—use vopt with one or more of
these visibility arguments instead.

For more information on supported vopt arguments for visibility, refer to Preservation of Object
Visibility for Debugging.

Note
In general, do not use the -novopt argument with the vcom, vlog, or vsim commands to run
the simulator without optimization—it will cause your simulation to run significantly
slower. Using the -novopt argument is not recommended except when using Power Aware
simulation together with Questa ADMS.

Name Requirements for the Optimized Design

When using the vopt command, you must provide a name for the optimized design using the -o
argument:

vopt testbench -o opt1

Note
The filename must not contain capital letters or any character that is illegal for your
operating system. For example, in Windows, you cannot use backslash (\).

ModelSim® SE User's Manual, v10.7 123

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Two-Step Flow

Incremental Compilation of Named Designs

The default operation of vopt -o <name> is incremental compilation: ModelSim reuses elements
of the design that have not changed, resulting in a reduction of runtime for vopt when a design
has been minimally modified.

Two-Step Flow
The two-step flow omits explicit use of the vopt command, although you can perform design
optimizations using existing scripts because vsim automatically performs optimization.
Note
In most cases, it is recommended that you use the Three-Step Flow for optimizing and
simulating your design. Unless you have a specific situation that requires a more simplified
flow and are aware of its limitations, you should use the three-step flow.

The two steps for this flow are the following actions using ModelSim commands:

1. Compile — vcom or vlog compiles all your modules.

2. Simulate — vsim performs the following actions:
a. Load — Runs in the background when it loads the design.
You can pass arguments to vopt using the -voptargs argument with vsim. For
example,
vsim mydesign -voptargs="+acc=rn"

The optimization step of vsim loads compiled design units from their libraries and
regenerates optimized code.
b. Simulate — Runs vsim on the optimized design unit.
Because vopt is called implicitly when using the two-step flow, ModelSim creates an optimized
internal design for simulation. By default, the maximum number of these designs is set to three,
after which vsim execution removes the oldest optimized design and creates a new one. You can
increase this limit by using the -unnamed_designs argument with the vlib command. Because
the vsim command manages unnamed_designs you cannot use the -o argument in the -voptargs
specification to name an optimized design. For example,
vsim mydesign -voptargs="-o myoptdesign" generates an error message.

Note
The unnamed optimized designs limit may be exceeded if multiple concurrent vsim sessions
are run with the same 'work' library

124 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
The -O Optimization Control Arguments

Preserving Object Visibility in the Two-Step Flow

With the two-step flow you can preserve object visibility by using the -voptargs argument with
the vsim command, which passes the arguments to the automatic invocation of vopt.

The following examples show how to pass optimization arguments from the vsim command
line:

vsim -voptargs="+acc" mydesign

vsim -voptargs="+acc+mod1" mydesign
vsim -voptargs="+acc=rnl" mydesign

The -O Optimization Control Arguments

The Three-Step and Two-Step flows for vopt are the primary usage models for ModelSim
optimization performance. These flows provide global visibility of the design, which the
compiler takes advantage of to make aggressive optimization decisions. In addition, you can
specify any of four -O arguments to control the aggressiveness of optimization decisions.
Note
These -O arguments are available for the vopt, vcom, and vlog commands. The vopt
command applies the specified control level during optimization, whereas the vcom and
vlog commands apply the control level during compilation.

Levels of Optimization Control

You can use the numbered -O arguments on the vcom or vlog command lines to control
optimizations independently from the vopt command. These numbered -O arguments provide
the following levels of control:

• -O0 — Enables the least amount of optimization. Use this to work around bugs, increase
your debugging visibility on a specific cell, or when you want to place breakpoints on
source lines that have been optimized out.
• -O1 — Enables a minimal amount of optimization.

Note
The -O0 and -O1 arguments can negatively impact performance—you should use
them only if you are attempting to analyze the behavior of the simulator.

• -O4 — (default) Enables optimization for most simulations.

• -O5 — Enables the maximum amount of optimization. This argument results more
aggressive native-code generation, which can speed up many designs, but it can slow
down others.

ModelSim® SE User's Manual, v10.7 125

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Inlined Modules and the Implications of Coverage Settings

Tip
In code coverage flows, you should use the vlog, vcom, and vopt -coveropt argument (or the
CoverOpt modelsim.ini variable) to control visibility and other interactions between
optimization and code coverage collection.

Optimization Control versus Visibility

Note that the decisions implemented by the different levels of -O arguments are not particularly
related to the global visibility characteristics of running vopt, which you specify using the +acc
argument. You use vopt +acc to preserve visibility of certain categories of objects that might
otherwise be optimized away. Objects that get optimized away can make your debug and
analysis efforts more difficult.

Inlined Modules and the Implications of Coverage

Settings
Recompiling an inlined module with different coverage settings (such as +cover) than a
previous compile forces a recompile of the inline parent modules. This is due to the fact that
inlined modules inherit the coverage settings of their parent. This forced recompilation can
result in an unexpected increase in compile time.

126 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Preservation of Object Visibility for Debugging

Preservation of Object Visibility for Debugging

For a debugging flow, you can preserve object visibility by using any of various arguments with
the vopt command. These vopt arguments specify which objects are to remain accessible for the
simulation.
Use of the +acc argument with vopt is not recommended for the following reasons:

• The vopt +acc argument is supported, but it is deprecated for future use.
• It may reduce simulation speed.
• The +acc argument and many of its values have been replaced by a collection of
individual arguments. For more information on the arguments, refer to Using vopt for
Access Control for Visibility During Optimization in the Command Reference Manual.
Refer to Table 3-1 for a list of the vopt arguments supported for access visibility, along with the
corresponding vopt +acc arguments that they are replacing.
Table 3-1. vopt Arguments for Access Visibility Being Replaced
Previously Supported Argument1 Replacement Argument
+acc=a -assertdebug
+acc=b -bitscalar
+acc=c -cellaccess
+acc=f -fsmdebug
+floatparameters -floatparameters
+floatgenerics -floatgenericss
+acc=l -linedebug
+nosparse -nosparse
+acc=s -systfoverride
+acc=u -primitiveaccess
+acc=x -randmetastable2
+noacc=a -noassertdebug
+noacc=b -nobitscalar
+noacc=c -nocellaccess
+noacc=f -nofsmdebug
+noacc=l -nolinedebug
+noacc=s -nosystfoverride
+noacc=u -noprimitiveaccess

ModelSim® SE User's Manual, v10.7 127

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Preservation of Object Visibility for Debugging

Table 3-1. vopt Arguments for Access Visibility Being Replaced (cont.)
Previously Supported Argument1 Replacement Argument
+noacc=x -norandmetastable
1. The following values of +acc and +noacc are also deprecated, but they do not have
replacement arguments and are still supported for backward compatibility:
+acc=m, +acc=n, +acc=p, +acc=r, +acc=t, +acc=v
+noacc=m, +noacc=n, +anocc=p, +noacc=r, +noacc=t, +noacc=v
2. Verilog cells only.

The following examples show some common uses of the vopt +acc combination—refer to the
vopt command in the Command Reference Manual for a description of all values.

• Preserve visibility of all objects in the design by specifying no arguments with +acc:
vopt +acc mydesign -o mydesign_opt

• Preserve visibility of all objects in a specific module by specifying the name of the
module as an argument with +acc:
vopt top +acc+mod1 mydesign -o mydesign_opt

• Preserve visibility of only registers (=r) within a specific module:

vopt top +acc=r+mod1 mydesign -o mydesign_opt

• Preserve access to nets (n), ports (p) and registers (r) for 3 levels downwards from a
specific level of hierarchy in a design (top.netlist1):
vopt top +acc=npr3+top.netlist1 mydesign -o mydesign_opt

The following examples assume that you have set the PathSeparator variable to a period (.) for a
Verilog environment.

• Preserve port access to a specific level of hierarchy in a design (top.netlist2):

vopt top +acc=p+top.netlist2 mydesign -o mydesign_opt

• Preserve port access recursively downward from a specific level of hierarchy in a design
(top.netlist2):
vopt top +acc=p+top.netlist2. mydesign -o mydesign_opt

• Preserve visibility for all instances of a particular VHDL design region (ent1):
vopt top +acc=+ent1 mydesign -o mydesign_opt

• Preserve visibility of line numbers (=l) in addition to registers within a specific module:
vopt top +acc=lr+mod1 mydesign -o mydesign_opt

• Preserve visibility of line numbers and registers within a specific module and all
children in that module by adding a period (.) after the module name:
vopt top +acc=lr+mod1. mydesign -o mydesign_opt

128 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Conflicts in Accessibility When Using Both +acc and +noacc

• Preserve visibility of a unique instance:

vopt +acc=mrp+top.u1 mydesign -o mydesign_opt

• Preserve visibility of a unique object:

vopt +acc=r+top.myreg mydesign -o mydesign_opt

• Preserve visibility of all design units whose names match a wildcard specification (glob-
style):
vopt +acc=r+mod?a mydesign -o mydesign_opt

This would perserve access to “mod1a”, “mod2a”, “mod3a”, and so on.

Conflicts in Accessibility When Using Both +acc and +noacc . . . . . . . . . . . . . . . . . . . . . 129

Conflicts in Accessibility When Using Both +acc

and +noacc
Use the +acc and +noacc arguments to the vopt command to specify accessibility for the entire
design or to specific design units and instances. Using both +acc and +noacc (negation of +acc)
arguments introduces some negation effects, so it is important to understand the interaction of
these arguments.
The rules governing priority for resolving conflicts between vopt +acc and +noacc arguments
are described in “Priorities for Resolving Conflicting Control Arguments”.

ModelSim® SE User's Manual, v10.7 129

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Negation Arguments and Resolution with vopt

Negation Arguments and Resolution with vopt

Using vopt commands that contain both +<command> and +no<command> arguments can
introduce some negation effects, so it is important to understand their interaction.
When using the vopt command, you can apply arguments to a particular region in the hierarchy.
For example:

• To apply coverage to hierarchy under scope “<object>”, you would use

“+cover+<object>.”
• When you apply arguments such as “+acc=<region>”, “+cover=t+<object>”, or
“+cover=s+<object>”, they are applied cumulatively to the design.
For increased flexibility, some negation arguments (+nocover, +noacc) are available for vopt.
Use of the arguments, both in their positive form and their negative, interact as described in this
section.

In general, you first identify a region where you want to apply a particular argument. For
example, you might use +cover to specify that initial region. Then, if some part of this region
needed to be excluded from coverage, you would apply the negating argument to that region,
which would be +nocover+<exclusion_region>. Further, you may identify additional regions to
which the +cover argument needs to be re-applied in order to negate the removal by the
previous +nocover argument. You can repeat this process to achieve the desired coverage.

Tip
You can use the period character (.) after <object> to apply an argument recursively.
Alternatively, you can use +<recursion_level> to apply this argument to a specified number
of levels under this scope, where recursion_level is any integer from 0 to 128 (a value of 128
specifies full recursion).

Priorities for Resolving Conflicting Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . 130

Using an External File to Control Visibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating Specialized Designs for Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . 132
Increase Visibility to Retain Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Priorities for Resolving Conflicting Control

Arguments
When you use vopt commands containing both +<command> and +no<command> arguments,
ModelSim applies resolution techniques for any conflicts that result.

130 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Using an External File to Control Visibility Rules

For +<arg>/+no<arg> arguments (examples: +cover/+nocover, +acc/+noacc), any conflict

resulting from the use of multiple + and/or negation (+no) arguments is resolved according to
the following priorities:

• In case of conflicting arguments, those specified later in the command-line override any
argument specified before.
• Any arguments specified to vopt take precedence over those arguments specified with
vcom or vlog.
An example of this prioritization is:

• Given the following vopt command:

vopt +cover=bc+lib1.du +nocover+inst top -o opt

The first argument (+cover) states that branch and condition coverage is applied to all
the instances of lib1.du. The second argument (+nocover) states that coverage is not
applied to specific instance inst.

Using an External File to Control Visibility Rules

You can use the vopt -f argument to specify a file that contains different values for multiple
+acc arguments. The target of the -f argument is simply an external text file whose contents are
multiple instances of the +acc argument. These instanes behave the same way as if you
specified them as individual arguments to a vopt command.
Using a file containing multiple +acc arguments to the vopt command is most useful when you
have numerous +acc arguments that you use regularly or because you provide a very fine
control of visibility.

For example:

vopt -f acc_file.txt mydesign -o mydesign_opt

where acc_file.txt contains:

// Add the follwing flags to the vopt command line.

+acc=rn+tb
+acc=n+tb.dut.u_core
+acc=pn+tb.dut.u_core.u_sub
+acc=pn+tb.dut.u_core.u_sub.u_bp
+acc=rpn+tb.dut.u_core.u_sub.u_bb.U_bb_compare
+acc=pn+tb.dut.u_core.u_sub.u_bb.U_bb_control
+acc=r+tb.dut.u_core.u_sub.u_bb.U_bb_control.U_bb_regs
+acc=rpn+tb.dut.u_core.u_sub.u_bb.U_bb_delay0

Note
This example assumes that you have set the PathSeparator variable to a period (.) for a
Verilog environment.

ModelSim® SE User's Manual, v10.7 131

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Creating Specialized Designs for Parameters and Generics

Creating Specialized Designs for Parameters and

Generics
You can use the vopt command to create specialized designs where generics or parameters are
predefined by using the -g or -G arguments.
For example:

vopt top -G TEST=1 -o test1_opt

vopt top -G TEST=2 -o test2_opt
vsim test1_opt
vsim test2_opt

Increase Visibility to Retain Breakpoints

When you are running ModelSim in full optimization mode, breakpoints cannot be set. To
retain visibility of breakpoints, you should set the vopt +acc argument such that the object
related to the breakpoint is visible.

Optimization of Parameters and Generics

During the optimization step, you can use various arguments of the vopt command to control
how parameters and generics affect the optimization of the design.
Additional optimization effects include the following:

• Override — You can override any design parameters and generics with either the -G or
-g arguments to the vopt command (note the case sensitivity). ModelSim optimizes your
design based on how you have overridden any parameters and generics.
Once you override a parameter or generic in the optimization step, you will not be able
to change its value during the simulation. Therefore, if you attempt to override these
same generics or parameters during the simulation, ModelSim will ignore those
specifications of -g or -G.
vopt -o opt_top top -G timingCheck=1 -G top/a/noAssertions=0

The Language Reference Manual for SystemVerilog (IEEE Std 1800-2005) places some
limits on overriding parameters. You will not be able to override parameters with the -g,
-G, or -floatparameters arguments in the following instances:
o Local parameters (localparam) cannot be overridden.
o You cannot specify a parameter in a generate scope, and if one exists, it should be
treated as a localparam statement.
o No mechanism is provided for overriding parameters declared inside a package or
$unit, and if one exists, it should be treated as a localparam statement.

132 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Optimization of Parameters and Generics

• Float — You can specify that parameters and generics should remain floating by using
the -floatparameters or -floatgenerics arguments, respectively, to the vopt command.
ModelSim will optimize your design, retaining any information related to these floating
parameters and generics so that you can override them during the simulation step.
vopt -o opt_top top -floatparameters+timingCheck+noAssertions

The -floatgenerics or -floatparameters arguments do affect simulation performance. If

this is a concern, it is suggested that you create an optimized design for each generic or
parameter value you may need to simulate. Refer to "Creating Specialized Designs for
Parameters and Generics" for more information.
• Combination — You can combine the use of the -g/-G and -floatparameters/-
floatgenerics arguments with the vopt command to have more control over the use of
parameters and generics for the optimization and simulation steps.
Because the -g/-G and -floatparameters/-floatgenerics arguments allow some use of
wildcards, ambiguities could occur. If, based on specified arguments, a parameter or
generic is considered floating and also is overridden, the override value takes
precedence. For example:
vopt -o opt_top top -floatparameters+timingCheck
-G top/a/noAssertions=0

• No Arguments — If you do not use any of the combinations of arguments described

above, where you do not use -g/-G or -floatparameters/-floatgenerics, ModelSim
optimizes the design based on how the design defines parameter and generic values.
Because of optimizations performed, you may lose the opportunity to override any
parameters or generics of the optimized design at simulation time.
If your design contains a Preoptimized Design Unit (black-boxed region) the -g/-G arguments
will override any floating parameters or generics in the PDU region. For example:

vopt -pdu -o dut_design dut -floatparameters+design.noAssertions

This command reates a Preoptimized Design Unit of dut with design.noAssertions floating.

vopt -o test_design test -G noAssertions=0

Here, the design test uses the PDU portion dut. The vopt command overrides any occurrence of
noAssertions, including the one in dut .vsim test_design performs the simulation where
noAssertions is set to 0.

Refer to the section Preoptimizing Regions of Your Design for more information.

ModelSim® SE User's Manual, v10.7 133

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Preoptimizing Regions of Your Design

Preoptimizing Regions of Your Design

A Preoptimized Design Unit (PDU) is a region of your design that you can identify for a one-
time optimization by using the -pdu argument of the vopt command. You can then reuse the
PDU and exclude it from being optimized. This reduces the amount of time for future
optimization and simulation runs by preoptimizing (black-boxing) static or unchanging regions
of your design.
Identifying a preoptimized design unit (PDU) optimizes portions of the design while allowing
other portions to be modified or recompiled. Using vopt -pdu maximizes throughput for designs
with many different test benches and an unchanged device under test (DUT). You can also use
the -pdu argument for different configurations of the same DUT, such as a fully optimized
configuration and a debug configuration with full or partial visibility. For any future use of this
PDU, ModelSim automatically recognizes and uses it, which reduces the runtime of vopt.

The difference between using a PDU and standard optimization is that you run vopt twice. The
first run creates the PDU (usually the DUT). The optional second run of vopt optimizes the
testbench and loads the previously optimized DUT (under another name). Note that creating a
PDU does not improve simulation run-time compared to standard optimization—a PDU helps
reduce optimization time by reusing optimized portions of the design.

For an example, refer to Simulating Designs with Multiple Test Benches.

When you are using vopt -pdu, you should associate the optimized name with the original name
using the -o argument. For example:

vopt -pdu moda -o moda_pdu_opt

In this example, any design that contains an instantiation of the module moda, ModelSim runs a
design analysis and automatically includes the Preoptimized Design Unit moda_pdu_opt.

When using vopt -pdu, be aware of the following:

• When you instantiate a region that has been preoptimized (black-boxed), you do not
need to run vopt on the top level module.
• During optimization, ModelSim does not descend into the PDU, which results in faster
operation. However, parameters passing through and hierarchical references across the
PDU are restricted. You can retain visibility into a PDU by using the -pdusavehierrefs
argument to vopt, but it can reduce simulation performance.
• You will need to manage both the original portion (moda) and its optimized version
(moda_pdu_opt). Specifically, you must not remove the optimized version without also
removing or recompiling the original version.
Simulating Designs with Multiple Test Benches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Extracting Visibility Requirements for PDUs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Using Configurations with Preoptimized Verilog Design Units . . . . . . . . . . . . . . . . . . . 137

134 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Simulating Designs with Multiple Test Benches

Using Configurations with Preoptimized VHDL Design Units . . . . . . . . . . . . . . . . . . . . 138

Resolving Preoptimized Design Unit Loading Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Simulating Designs with Multiple Test Benches

When using multiple test benches to simulate a design, you typically use vopt -pdu to optimize
each test bench as a preoptimized design unit (PDU). You would then use the Three-Step
simulation on the different test benches, which prevents having to optimize each test bench.
The following steps demonstrate how to simulate and optimize Verilog test benches and design.

Prerequisites
• Current working library.
• Assume the following library and file names:
work asic_lib
cell_lib.v netlist.v
opt_netlist tb.v
test1.v test2.v
opt_tb sim.do

Procedure
1. Compile the work and design libraries.
vlib work
vlib asic_lib

2. Compile the library and netlist.

vlog -work asic_lib cell_lib.v
vlog netlist.v

3. Optimize the netlist using the PDU capability (-pdu netlist).

vopt -L asic_lib -debugCellOpt +checkALL -pdu netlist -o opt_netlist

4. Compile the remainder of the design.

vlog tb.v test1.v

5. Optimize the test bench.

vopt tb -o opt_tb

6. Simulate the first test bench.

vsim -c opt_tb -do sim.do

ModelSim® SE User's Manual, v10.7 135

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Extracting Visibility Requirements for PDUs

7. Compile and optimize a second test and re-simulate without recompiling or optimizing
the PDU netlist.
vlog test2.v
vopt tb -o opt_tb
vsim -c opt_tb -do sim.do

Extracting Visibility Requirements for PDUs

A PDU may contain objects within its hierarchy that need to retain visibility for a successful
simulation.
The following steps demonstrate how to extract acc directives for two Verilog PDU candidates.
The -pduspec argument to vopt enables the extraction of the visibility requirements (acc
statements) for such objects and creates an output file containing +acc statements. The
generated output files are then used by vopt -pdu to create PDUs for the specified boundary
modules or instances. Because the only intent of this step is the extraction of visibility
requirements for the PDUs, vopt exits after the output files are written. Therefore, vopt does not
require the -o argument when specifying -pduspec.

Prerequisites
• In order to maintain necessary visibility, run the vopt command with appropriate
-pduspec values and an acc file that contains all hierarchical references (such as the .acc
file generated by vsim -learn).
Refer to Preserving Design Visibility with the Learn Flow for more information.
Procedure
1. Compile your design:
vlog *.sv

2. Simulate with vsim -learn and full visibility into your design to generate a control file
with instructions for preserving visibility:
vsim -voptargs="+acc" -learn mylearn top

This creates the file mylearn.acc.

3. Create the PDU visibility file, dut1.acc, using the .acc file generated by -learn,
mylearn.acc, and the previously compiled top:
vopt top -pduspec+dut1+facc=dut1.acc -f mylearn.acc

This generates a unified .acc file for the PDU.

4. Create a PDU for dut1_pdu that references the visibility requirements generated in Step
3:
vopt -pdu -o dut1_pdu dut1 -f dut1.acc

136 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Using Configurations with Preoptimized Verilog Design Units

5. Optimize the design with the merged visibility criteria located in mylearn.acc:
vopt -o top_opt top -f mylearn.acc

Using Configurations with Preoptimized Verilog

Design Units
You can use a Verilog configuration with the -pdu argument to vopt.
Prerequisites
• Create the following files, which set up a Verilog configuration to use with the PDU
capability of vopt. Given these files, you can use the procedure below to simulate your
design using Preoptimized Design Units (black-boxed regions).
o topcfg.v
config topcfg;
design work.top;
instance top.u0 use foo10;
instance top.u1 use foo20;
endconfig

o top.v
module top;
foo u0();
foo u1();
endmodule

o foo.v
module foo10;
foo_lower #10 u0();
endmodule

module foo20;
foo_lower #20 u0();
endmodule

module foo_lower;
parameter N=99;
initial begin
$display("N=%d", N);
end
endmodule

Procedure
1. Create the work library:
vlib work

ModelSim® SE User's Manual, v10.7 137

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Using Configurations with Preoptimized VHDL Design Units

2. Compile foo.v into the work library:

vlog foo.v

3. Create a PDU named foo10_pdu based on the foo10 module in foo.v. Whenever a part
of the design is dependent upon foo10, the simulator loads the PDU foo10_pdu to speed
up the elaboration process.
vopt -pdu foo10 -o foo10_pdu

4. Create a PDU named foo20_pdu based on the foo20 module in foo.v:

vopt -pdu foo20 -o foo20_pdu

5. Compile top.v into the work library:

vlog top.v

6. Compile the configuration, topcfg.v, into the work library:

vlog topcfg.v

7. Elaborate the configuration and run the simulation.

vsim topcfg -do "run -all"

Results
When the simulator encounters top.u0, it will use foo10 (as defined in the configuration). The
simulator will then use your PDU foo10_pdu (and apply the same process for top.u1 and
foo20).

Using Configurations with Preoptimized VHDL

Design Units
You can use a VHDL configuration with the -pdu argument to vopt.
Prerequisites
• Create the following files, which show a simplified way to set up a VHDL configuration
to use with the PDU capability of vopt. Given these files, you can use the procedure
below to simulate your design using Preoptimized Design Units (black-boxed regions).
o topcfg.vhd
configuration topcfg of top is
for arch
for u0 : foo_comp
use entity work.foo10(arch);
end for;
for u1 : foo_comp
use entity work.foo20(arch);
end for;
end for;
end configuration;

138 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Using Configurations with Preoptimized VHDL Design Units

o top.vhd
entity top is
end top;

architecture arch of top is

component foo_comp
end component;
begin
u0 : foo_comp;
u1 : foo_comp;
end arch;

o foo.vhd
entity foo_lower is
generic ( N : integer := 99 );
end foo_lower;

architecture arch of foo_lower is

begin
p1 : process
begin
assert false
report "in " & p1'instance_name & ",
N = " & integer'image(N)
severity note;
wait;
end process;
end arch;

entity foo10 is
end foo10;

architecture arch of foo10 is

component foo_lower
generic ( N : integer );
end component;
begin
u0 : foo_lower
generic map (N => 10);
end arch;

entity foo20 is
end foo20;

architecture arch of foo20 is

component foo_lower
generic ( N : integer );
end component;
begin
u0 : foo_lower
generic map (N => 20);
end arch;

ModelSim® SE User's Manual, v10.7 139

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Resolving Preoptimized Design Unit Loading Errors

Procedure
1. Create the work library:
vlib work

2. Compiles foo.vhd into the work library:

vcom foo.vhd

3. Create a Preoptimized Design Unit (black-box) named foo10_pdu based on the foo10
module in foo.vhd. Whenever a part of the design is dependent upon foo10, the
simulator loads the optimized design unit foo10_pdu to speed up the elaboration
process.
vopt -pdu foo10 -o foo10_pdu

4. Create a PDU named foo20_pdu based on the foo20 module in foo.vhd:

vopt -pdu foo20 -o foo20_pdu

5. Compile top.vhd into the work library:

vcom top.vhd

6. Compile the configuration, topcfg.vhd, into the work library:

vcom topcfg.vhd

7. Elaborate the configuration and performs the simulation:

vsim topcfg -do "run -all"

Results
When the simulator encounters u0 : foo_comp it will use foo10 (as defined in the
configuration). The simulator will then use your PDUfoo10_pdu (and apply the same process
for u1 : foo_comp and foo20).

Resolving Preoptimized Design Unit Loading Errors

A Preoptimized Design Unit does not allow mapping of libraries inside the PDU, though you
can use mapping to find the upper-level PDU library. Compiling libraries and optimizing design
units on one machine and then simulating the design on another machine (such as in a grid
environment) can lead to an error condition—most frequently resulting from a changed file
dependency or library path.
Symptoms
The following transcript shows an example of error and warning messages that can result from
compiling and optimizing in a different environment than that used for simulation:

# vsim -L dut -L cells -c top

# Loading work.top(fast)
# Loading work.dut_post(fast)

140 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Resolving Preoptimized Design Unit Loading Errors

# ** Warning: (vsim-56) The dependency file generated by the "vopt" tool

# has either been removed, is for an older version of the tool or has been
# corrupted. Normally re-running vopt on the design will recreate this
# file and solve the issue.
# "/tmp/build1/test/libs/cells/post_cell_bb/_deps" - file open failed.

# ** Error: (vsim-166) Failed to load a Preoptimized Design Unit(black-box)

# created using -pdu. post_cell_bb could not be loaded from
# library '/tmp/build1/test/libs/cells'.
# Region: /top/u1
# Error loading design

Causes
Possible causes of error message vsim-166:

• Dependent file — A dependent file generated by running vopt could not be found, or the
file was generated by an older version of ModelSim.
• Library Path — The physical path to a library containing a Preoptimized Design Unit
(PDU) no longer points to the library. This can occur in nested PDUs (a PDU containing
a PDU) and is due to a PDU fixing all logical references (including library mappings) to
physical references below it.
Solution
• Dependent file — Rerunning vopt on the design will recreate the PDU and resolve the
issue.
• Library Path — Use soft links to resolve these physical links if necessary.

ModelSim® SE User's Manual, v10.7 141

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Alternate Optimization Flows

Alternate Optimization Flows

You can implement optimizations that use variations of the Three- and Two-Step flows.
Although the Three-Step flow is recommended for most ModelSim simulations, you may find
these alternative variations to be useful in your environment.
Creating Locked Libraries for Multiple-User Simulation Environments . . . . . . . . . . . 142
Optimizing Liberty Cell Libraries for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Creating Locked Libraries for Multiple-User

Simulation Environments
In some cases, you and other users may require access to the same library. One conflict that can
arise from this is that another user may try to recompile some design units in that library, which
can negatively affect your environment.
You can prevent other users from recompiling the library by using the -locklib argument to the
vlib command. The -locklib argument prevents any alteration of a library.

Procedure
1. Create the library:
vlib work

2. Compile design units into the library:

vlog top.v a.v b.v
vlog tb.v

3. Create optimized versions of your design:

vopt +acc top_tb -o opt_fullVis
vopt top_tb -o opt_Regression
vopt +acc +cover top_tb -o opt_Cover

If you want to optimize a design, you must do so before locking the library. Otherwise,
entering the vopt command produces the following error:
# ** Fatal: (vopt-1991) Library "\user\design\work" cannot be
modified due to a lock.

4. Lock the library:

vlib -locklib work

Once the library is locked, no one can alter the library in any way—this includes
attempting to run the vlib, vcom, vopt, and vdel commands.

142 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Optimizing Liberty Cell Libraries for Debugging

You can ensure that the library is locked by using the following query, which returns
information about the library that includes the following line:
...
# Library locked/unlocked : locked
...

If you need to recompile a design unit or create a new optimized design, you can unlock
the library as follows:
vlib -unlocklib work

5. Alternatively, you can lock individual design units:

vlib -lock top work
vlib -lock a work

Optimizing Liberty Cell Libraries for Debugging

To debug designs with Liberty logic cells, you must specify the location of the Liberty cell
library file before or during optimization.
Procedure
Set the location of the Liberty library by doing either of the following:

• Set the MTI_LIBERTY_PATH environment variable to the directory location

containing Liberty library source (.lib) files.
• Use the vopt command to optimize your design.
vopt -libertyfiles=<file_name> -debugdb

Results
This enables schematic viewing and causality analysis using Liberty logic cell definitions. The
following command sequence shows basic usage of a Liberty library:
vlog design.v
vopt -o opt tb -libertyfiles=cells.lib -debugdb ...
vsim -c opt -debugdb ...

Preserving Design Visibility with the Learn

Flow
To ensure that you retain the proper level of design visibility when performing an optimized
simulation (using vopt in the Three-Step flow), you can use the vsim -learn command. This
command creates control files that include instructions for preserving visibility of the design.

ModelSim® SE User's Manual, v10.7 143

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Preserving Design Visibility with the Learn Flow

These control files allow you to retain information during optimization for the following:

• ACC/TF PLI routines

• VPI PLI routines
• Signal Spy accesses
• force Run-time command
• FLI instances (regions), signals, ports, and variables.
• Objects specified as arguments to commands executed after -learn is started, such as add
wave /top/p/*.
• Objects under Verilog unnamed generate scopes
• Objects specified in SignalSpy system tasks
The following steps demonstrate the use of vsim -learn for preserving visibility using PLI
routines.

Restrictions and Limitations

• Because the control files are saved at the end of simulation, you should not restart or
restore the simulation when working with the learn mode. Interrupting the simulation
can make control file contents unreliable.
Procedure
1. Create your libraries and compile your design as you normally would.
2. Invoke the simulator, using the -voptargs argument to implicitly optimize the design.
vsim -voptargs=+acc -learn top_pli_learn -pli mypli.sl top

When you specify the -learn argument, where the argument defines the root name
(top_pli_learn) of the generated control files, vsim analyzes your design as well as your
PLI to determine what information to retain during the optimization.
By specifying -voptargs=+acc you are enabling full visibility, which allows the learn
flow to correctly analyze the full functionality of your design.
Based on this analysis, the learn mode process then creates the following control files
and places them in the current directory:
top_pli_learn.acc
top_pli_learn.ocf
top_pli_learn.ocm

The learn mode analysis reads the PathSeparator variable in the modelsim.ini file at the
time it controls the control files. Be sure to use a consistent path separator throughout
the analysis.

144 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Preserving Design Visibility with the Learn Flow

3. Run the simulation to generate the control files (.acc, .ocf, and .ocm).
run <time_step><time_unit>

While the simulation runs, the learn mode process tracks and records the objects
required for your PLI routines or that are used for commands executed before or after
the run, for which you need to retain visibility. Use your knowledge of the design and
test bench to estimate how long to run the simulation.
To ensure that the simulator records every possible access, you should run a complete
simulation (run -all).
4. Create an optimized design, retaining the visibility as defined in the control files. You
can determine which type of control file you wish to use. A command line example for
each type include:
vopt -f top_pli_learn.acc -o top_opt
vopt -ocf top_pli_learn.ocf -o top_opt
vopt -ocf top_pli_learn.ocm -o top_opt

The vopt command creates the optimized design, top_opt, and retains visibility to the
objects required by your PLI routines.
5. Simulate the optimized design.
vsim -pli mypli.sl top_opt

This performs the simulation on the optimized design, where you retained visibility to
the objects required by your PLI routines.
Results
Simulation using learn mode generates three formats of control files that instruct vopt to retain
visibility to objects required by the specified PLI routines. All three file formats are text files
and are considered to be non-lossy—information about every object touched by the PLI during
the -learn run is retained.
• .acc control file — This format (.acc) creates the information in the traditional +acc
format used by the vopt command. However, this format does not allow for precise
targeting of objects that you can get with the .ocf format.
• .ocf control file — This format (.ocf) is the most verbose and precisely targeted of the
three control files. It is recommended that you use this file for situations where there is
sparse access to objects. Note that if you access every object in a module, this file can
get considerably large.
• .ocm control file — This format (.ocm) is similar to the .ocf format, except that the file is
factorized by design unit, which results in a smaller and more easily read file, but
provides less precise targeting.
These files are text-based and anyone can edit them.

ModelSim® SE User's Manual, v10.7 145

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Controlling Optimization from the GUI

Controlling Optimization from the GUI

Optimization (vopt) in the GUI is controlled from the Simulate > Design Optimization dialog
box. You can use the Visibility tab restore total design visibility during optimization.
Procedure
1. From the main menu, choose the following:
Simulate > Design Optimization
2. Click the Visibility tab.
3. Select the following:
Apply full visibility to all modules (full debug mode)
4. Click the Design tab and do the following:
a. Select the top-level design unit to simulate.
b. Specify an Output Design Name.
c. Select Start Immediately.
5. Click OK.

146 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Optimization Considerations for Verilog Designs

Optimization Considerations for Verilog

Designs
The optimization considerations for Verilog designs include design object visibility, standard
delay formating, event ordering, timing checks, handling pre-compiled libraries, and reporting
for gate-level optimizations.
Design Object Visibility for Designs with PLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Optimization on Designs Containing SDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Reports for Gate-Level Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Optimization of Precompiled Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Event Order and Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Timing Checks in Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Design Object Visibility for Designs with PLI

Some of the optimizations performed by vopt affect design object visibility. For example, many
objects do not have PLI Access handles, potentially affecting the operation of PLI (program
language interface) applications. However, a handle is guaranteed to exist for any object that is
an argument to a system task or function.
In the early stages of design, you can use one or more +acc arguments in conjunction with vopt
to enable access to specific design objects. See the vopt command in the Reference Manual for
specific syntax of the +acc argument.

Automatic +acc for Designs with PLI

By default, if your design contains any PLI, and the automatic vopt flow is enabled, vsim
automatically adds a +acc to the sub-invocation of vopt, which disables most optimizations.

If you want to override the automatic disabling of the optimizations for modules containing PLI,
specify the -no_autoacc argument with the vsim command.

Manual +acc for Designs with PLI

If you are manually controlling vopt optimizations, and your design uses PLI applications that
look for object handles in the design hierarchy, then it is likely that you will need to use the +acc
argument.

For example, the built-in $dumpvars system task is an internal PLI application that requires
handles to nets and registers so that it can call the PLI routine acc_vcl_add() to monitor changes
and dump the values to a VCD file. This requires that access is enabled for the nets and registers
on which it operates.

ModelSim® SE User's Manual, v10.7 147

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Optimization on Designs Containing SDF

Example 1 — Dumping All Nets and Registers for the Entire Design
Suppose you want to dump all nets and registers in the entire design, and that you have the
following $dumpvars call in your test bench (no arguments to $dumpvars means to dump
everything in the entire design):

initial $dumpvars;

Then you need to optimize your design as follows to enable net and register access for all
modules in the design:

vopt +acc=rn testbench

Example 2 — Dumping All Nets and Registers for a Single Instance
Suppose you need to dump only nets (n) and registers (r) of a particular instance in the design
(the first argument of 1 means to dump just the variables in the instance specified by the second
argument):

initial $dumpvars(1, testbench.u1);

Then you need to optimize your design as follows (assuming testbench.u1 is an instance of the
module design):

vopt +acc=rn+design testbench

Example 3 — Dumping Child Instances
Suppose you need to dump everything in the child instances of testbench.u1 (the first argument
of 0 means to also include all children of the instance):

initial $dumpvars(0, testbench.u1);

Then you optimize your design as follows:

vopt +acc=rn+design. testbench

To gain maximum performance, it may be necessary to enable the minimum required access
within the design.

Optimization on Designs Containing SDF

Both the Two-Step and the Three-Step optimization flows automatically perform standard delay
format (SDF) compilation using the sdfcom command.
Automatic compilation occurs if any of the following apply:

• The $sdf_annotate system task exists in the test bench.

• The -sdfmin, -sdfmax, or -sdftyp arguments are specified with the vopt command in the
Three-Step Flow.

148 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Reports for Gate-Level Optimizations

• The -sdfmin, -sdfmax, or -sdftyp arguments are specified with the vsim command in the
Two-Step Flow.
The following arguments to vopt are useful when your design includes SDF:

• vopt +notimingchecks — Allows you to simulate your gate-level design without taking
into consideration timing checks, giving you performance benefits. For example:
vlog cells.v netlist.v tb.v
vopt tb -o tb_opt -O5 +checkALL +delay_mode_path +notimingchecks \
-debugCellOpt
vsim tb_opt

By default, vopt does not fix the TimingChecksOn generic in Vital models. Instead, it
lets the value float to allow for overriding at simulation time. If you prefer best
performance and no timing checks, use the +notimingchecks argument with vopt.
vopt +notimingchecks topmod

Specifying vopt +notimingchecks or -G TimingChecks=<FALSE/TRUE> will fix the

generic value for simulation. As a consequence, using vsim +notimingchecks at
simulation may not have any effect on the simulation, depending on the optimization of
the model.
• vopt {-sdfmin | -sdftyp | -sdfmax } [<instance>=]<sdf_filename> — Annotates cells in
the specified SDF files with minimum, typical, or maximum timing. This invocation
triggers the SDF compilation.
• vopt +check{ALL | AWA | CLUP | DELAY | DNET | INTRI | IPODOP | NWOT |
OPRD | SUDP} — Disables specific optimization checks (observe uppercase). Refer to
the vopt reference page for details.

Reports for Gate-Level Optimizations

You can use the write cell_report and the -debugCellOpt argument to the vopt command to
obtain information about which cells have and have not been optimized.
The write cell_report command produces a text file that lists all modules.

vopt tb -o tb_opt -debugCellOpt

vsim tb_opt -do "write cell_report cell.rpt; quit -f"

Modules with "(cell)" following their names are optimized cells. For example,

Module: top
Architecture: fast

Module: bottom (cell)

Architecture: fast

In this case, the module named “top” was not optimized, and the module named “bottom” was.

ModelSim® SE User's Manual, v10.7 149

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Optimization of Precompiled Libraries

Optimization of Precompiled Libraries

If the source code is unavailable for any of the modules referenced in a design, then you must
search libraries for the precompiled modules using the -L or -Lf arguments to the vopt
command. This command optimizes precompiled modules the same as if the source code is
available and writes the optimized code to the default ‘work’ library.
The vopt command automatically searches libraries specified in the `uselib directive (see
Verilog-XL uselib Compiler Directive). If your design uses `uselib directives exclusively to
reference modules in other libraries, then you do not need to specify library search arguments.

Event Order and Optimized Designs

The Verilog language does not require that the simulator execute simultaneous events in any
particular order. Optimizations performed by vopt may expose event order dependencies that
cause a design to behave differently than when run unoptimized.
Event order dependencies are considered errors and should be corrected. Refer to Event
Ordering in Verilog Designs for more information.

Timing Checks in Optimized Designs

When you run a simulation, ModelSim performs timing checks whether you optimize the
design or not. In either, you will generally see the same results of these checks. However, in a
cell where there are both interconnect delays and conditional timing checks, you might see
different timing check results.
• Without vopt — ModelSim evaluates conditional checks with non-delayed values,
complying with the original IEEE Std 1364-1995 specification. You can use the
-v2k_int_delays argument with vsim to ensure compatibility by forcing the IEEE Std
1364-2005 implementation.
• With vopt — ModelSim evaluates conditional checks with delayed values, which
complies with the IEEE Std 1364-2005 specification.

150 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 4
Projects

Projects simplify the process of compiling and simulating a design and are useful for getting
started with ModelSim.
What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
What are the Benefits of Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Project Conversion Between Simulator Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Getting Started with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Open a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Simulate a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
The Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Creating a Simulation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Organizing Projects with Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Adding a Project Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Set File Properties and Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
File Compilation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Access Projects from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

ModelSim® SE User's Manual, v10.7 151

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
What are Projects?

What are Projects?

A project is a collection of files and user-defined settings for designs under specification or test.
At a minimum, a project has a root directory, a work library, and “metadata” which are stored in
an .mpf file located in a project's root directory. The metadata include: compiler switch settings,
compile order, and file mappings.
Projects may also include the following items:

• Source files or references to source files

• Other files, such as READMEs or other project documentation
• Local libraries
• References to global libraries
• Simulation configurations
• Folders
What are the Benefits of Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Project Conversion Between Simulator Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

What are the Benefits of Projects?

Projects offer benefits to both new and advanced users.
• Projects simplify interaction with ModelSim. For example, you do not need to
understand the intricacies of compiler switches and library mappings
• Projects eliminate the need to remember the conceptual model of the design; the compile
order is maintained for you in the project.

Note
Compile order is maintained for HDL-only designs.

• Projects remove the necessity to re-establish compiler switches and settings for each
new session. Settings and compiler switches are stored in the project metadata as are
mappings to source files.
• Projects allow you to share libraries without copying files to a local directory. For
example, you can establish references to source files that are stored remotely or locally.
• Projects allow you to change individual parameters across multiple files. In previous
versions you could only set parameters one file at a time.
• Projects enable "what-if" analysis. For example, you can copy a project, manipulate the
settings, and rerun the simulation to observe the new results.

152 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Project Conversion Between Simulator Versions

• Projects reload the initial settings from the project .mpf file every time you open the
project.
Related Topics
Creating a Simulation Configuration
Organizing Projects with Folders

Project Conversion Between Simulator Versions

Projects are generally not backwards compatible for either number or letter releases. When you
open a project created in an earlier version, you will see a message warning that the project will
be converted to the newer version. You have the option of continuing with the conversion or
canceling the operation.
Choosing to convert a project to a newer version creates a backup of the original project before
the conversion occurs. The backup file is named <project name>.mpf.bak, and it appears in the
same directory in which the original project is located.

ModelSim® SE User's Manual, v10.7 153

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Getting Started with Projects

Getting Started with Projects

Your initial setup, compilation, and simulation of a design consists of working with several
windows and dialog boxes.
Open a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Simulate a Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Open a New Project

To create a new ModelSim project, you open one from scratch and specify the details of its
initial configuration.
Procedure
1. Select File > New > Project to create a new project. This opens the Create Project
dialog box, as shown in Figure 4-1.
2. Specify a project name, location, and default library name. You can generally leave the
Default Library Name field set to "work" (as shown). The name you specify will be
used to create a working library subdirectory within the Project Location. The Copy
Settings From field allows you to import library settings from a selected .ini file instead
of copying them directly into the project.
Figure 4-1. Create Project Dialog Box

3. Click OK.

154 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Open a New Project

Results
A blank Project window opens in the Main window (Figure 4-2)
Figure 4-2. Project Window Detail

and the Add Items to the Project dialog box opens. (Figure 4-3)
Figure 4-3. Add items to the Project Dialog

The name of the current project appears at the bottom bar of the Main window.
If you exit ModelSim with a project open, ModelSim automatically opens that same project
upon startup.
You can open a different or existing project by selecting File > Open and choosing Project Files
from the Files of type dropdown list.
To close a project file, right-click in the Project window and choose Close Project. This closes
the Project window but leaves the Library window open. You cannot close a project while a
simulation is in progress.

ModelSim® SE User's Manual, v10.7 155

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Add Source Files to the Project

Add Source Files to the Project

Once you have created a project, you need to add the design files. You can either write and edit
a new source file, or add a pre-existing file.
Procedure
1. Create a new project file
a. Choose Project > Add to Project > New File (the Project window must be active).
This opens the Create Project File dialog box (Figure 4-4).
Figure 4-4. Create Project File Dialog

b. Specify a name, file type, and folder location for the new file.
When you click OK, the file is listed in the Project window. If you double-click the
name of the new file in the Project window, a Source editor window opens, where you
can create source code.
2. Add an existing file.
a. Choose Project > Add to Project > Existing File.
Figure 4-5. Add file to Project Dialog

b. Click OK.
Results
The files are added to the Project window.

156 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Compile the Files

Tip
You can send a list of all project filenames to the Transcript window by entering the
command project filenames. This command works only when a project is open.

Compile the Files

The question marks in the Status column in the Project window indicate that either the files have
not been compiled into the project or that the source has changed since the last compile.
Note
Project metadata is updated and stored only for actions taken within the project itself. For
example, if you have a file in a project, and you compile that file from the command line
rather than using the project menu commands, the project will not update to reflect any new
compile settings.

Procedure
Choose Compile > Compile All or right-click in the Project window and choose Compile >
Compile All.

Results
Once compilation finishes, click the Library window, expand the library work by clicking the
“+”, and you will see the compiled design units.

ModelSim® SE User's Manual, v10.7 157

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Change Compile Order

Figure 4-6. Click Plus Sign to Show Design Hierarchy

Change Compile Order

The Compile Order dialog box is functional for HDL-only designs. When you compile all files
in a project, ModelSim by default compiles the files in the order in which they were added to the
project.
You have two alternatives for changing the default compile order:

• Select and compile each file individually

• Specify a custom compile order
Procedure
1. Choose Compile > Compile Order from the main menu or from the context menu in
the Project window.

158 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Auto-Generate the Compile Order

Figure 4-7. Setting Compile Order

2. Drag the files into the correct order or use the up and down arrow buttons. Note that you
can select multiple files and drag them simultaneously.

Auto-Generate the Compile Order

If you have an HDL-only design, you can automatically generate the compile order of its files.
When you click the Auto Generate button in the Compile Order dialog box (Figure 4-7),
ModelSim determines the correct compile order by making multiple passes over the files. It
starts compiling from the top; if a file fails to compile due to dependencies, it moves that file to
the bottom and then recompiles it after compiling the rest of the files. It continues in this manner
until all files compile successfully or until a file(s) cannot be compiled for reasons other than
dependency.

You can display files in the Project window in alphabetical or in compilation order (by clicking
the column headings). Keep in mind that the order you see in the Project window is not
necessarily the order in which the files will be compiled.

Grouping Files
You can group two or more files in the Compile Order dialog so they are sent to the compiler at
the same time.
For example, you might have one file with several Verilog define statements and a second file
that is a Verilog module. Typically, you would want to compile these two files together.

ModelSim® SE User's Manual, v10.7 159

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Simulate a Design

Procedure
1. Select the files you want to group.
Figure 4-8. Grouping Files

2. Click the Group button.

To ungroup files, select the group and click the Ungroup button.

Simulate a Design
After you have finished compiling the files contained in your design, you can begin simulation.
To simulate a design, do one of the following.

• Double-click the Name of an appropriate design object (such as a test bench module or
entity) in the Library window.
• Right-click the Name of an appropriate design object and choose Simulate from the
popup menu.
• Choose Simulate > Start Simulation from the main menu to open the Add Simulation
Configuration dialog box (Figure 4-9). Select a design unit in the Design tab. Set other
options in the VHDL, Verilog, Libraries, SDF, and Others tabs. Click OK to start the
simulation.

160 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Simulate a Design

Figure 4-9. Add Simulation Configuration Dialog Box — Design Tab

A new Structure window, named sim, appears that shows the structure of the active simulation
(Figure 4-10).

Figure 4-10. Structure Window with Projects

At this point, you can run the simulation and analyze your results. Typically, you would do this
by adding signals to the Wave window and running the simulation for a given period of time.
See the ModelSim Tutorial for examples.

ModelSim® SE User's Manual, v10.7 161

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
The Project Window

The Project Window

To access:
• New Project: File > New > Project.
• Saved Project: File > Open > Files of Type > Project File (.mpf)
The Project window contains information about the objects in your project. By default the
window is divided into five columns. You can display this window to create a new project or to
work on an existing project that you have saved
Figure 4-11. Project Window Overview

Objects
• Column titles
o Name – The name of a file or object.
o Status – Identifies whether a source file has been successfully compiled. Applies
only to VHDL or Verilog files. A question mark means the file has not been
compiled or the source file has changed since the last successful compile; an X
means the compile failed; a check mark means the compile succeeded; a checkmark
with a yellow triangle behind it means the file compiled but there were warnings
generated.
o Type – The file type as determined by registered file types on Windows or the type
you specify when you add the file to the project.
o Order – The order in which ModelSim compiles the file when you run a Compile
All command.
o Modified – The date and time of the last modification to the file.
You can hide or show columns by right-clicking a column title and selecting or deselecting
entries.

162 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Creating a Simulation Configuration

Usage Notes
You can sort the list by any of the five columns. Click a column heading to sort by that column;
click the heading again to invert the sort order. An arrow in the column heading indicates which
field is used to sort the list, and whether the sort order is descending (down arrow) or ascending
(up arrow).

Creating a Simulation Configuration

A Simulation Configuration associates a design unit(s) and its simulation options. Ordinarily,
you would have to specify simulation options each time you load the design. With a Simulation
Configuration, you specify the design and simulation options and then save the configuration
with a name.
For example, assume you routinely load a particular design and you also have to specify the
simulator resolution limit, generics, and SDF timing files. With a Simulation Configuration, you
would specify the design and those options and then save the configuration and name it
top_config. This name is then listed in the Project window where you can double-click it to load
the design along with its options.

Procedure
1. Add a simulation configuration to the project by doing either of the following:
• Choose Project > Add to Project > Simulation Configuration from the main
menu.
• Right-click the Project window and choose Add to Project > Simulation
Configuration from the popup menu in the Project window.
This displays the dialog box shown in Figure 4-12.

ModelSim® SE User's Manual, v10.7 163

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Creating a Simulation Configuration

Figure 4-12. Add Simulation Configuration Dialog Box

2. Specify a name in the Simulation Configuration Name field.

3. Specify the folder in which you want to place the configuration (see Organizing Projects
with Folders).
4. Select one or more design unit(s). Use the Control and/or Shift keys to select more than
one design unit. The design unit names appear in the Simulate field when you select
them.
5. Use the other tabs in the dialog box to specify any required simulation options.

Tip
Similar to a Simulation Configuration, an Optimization Configuration is a named
object that represents an optimized simulation. The procedure for creating and using
it is similar to the steps for Simulation Configuration, with the following differences:
Choose Project > Add to Project > Optimization Configuration.
Specify options in the Add Optimization Configuration dialog box.

6. Click OK

164 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Creating a Simulation Configuration

Results
• The simulation configuration is added to the Project window, as shown in Figure 4-13.
• As noted, the name of the new simulation configuration you have added is verilog_sim.
• To load the design, double-click on verilog_sim.
Figure 4-13. Simulation Configuration in the Project Window

ModelSim® SE User's Manual, v10.7 165

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Organizing Projects with Folders

Organizing Projects with Folders

Adding more files to a project makes it more difficult o locate the item you need. You can add
one or more folders to a project and use them to organize the files that you have added.
Adding a Project Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Adding a Project Folder

Project folders are similar to directories in that they are containers that allow you to organize
multiple levels of folders and sub-folders. However, no actual project directories are created in
the file system—the folders are present only within the project file.
Procedure
1. Choose Project > Add to Project > Folder or right-click in the Project window and
choose Add to Project > Folder.
Figure 4-14. Add Folder Dialog Box

2. Specify the Folder Name, the location for the folder, and click OK. The folder will be
displayed in the Project tab.
Examples
For example, when you add a file, you can select which folder to place it in.

166 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Adding a Project Folder

Figure 4-15. Specifying a Project Folder

If you want to move a file into a folder later on, you can do so using the Properties dialog box
for the file. To display this dialog box, right-click on the filename in the Project window and
choose Properties from the context menu. This opens the Project Compiler Settings dialog box
(Figure 4-16). Use the Place in Folder field to specify a folder.

Figure 4-16. Project Compiler Settings Dialog Box

On Windows platforms, you can also just drag-and-drop a file into a folder.

ModelSim® SE User's Manual, v10.7 167

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Set File Properties and Project Settings

Set File Properties and Project Settings

You can set two types of properties in a project: file properties and project settings. File
properties affect individual files; project settings affect the entire project.
File Compilation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

File Compilation Properties

The VHDL and Verilog compiler commands (vcom and vlog, respectively) have numerous
arguments that affect how a design is compiled and subsequently simulated. You can use the
arguments of these commands to customize the settings on individual files or a group of files.
Note
Any changes you make to the compile properties outside of the project, whether from the
command line, the GUI, or the modelsim.ini file, will not affect the properties of files
already in the project.

To customize specific files, select the file(s) in the Project window, right click the file names,
and choose Properties to display the Project Compiler Settings dialog box (Figure 4-17). The
appearance of this dialog box can vary, depending on the number and the type of files you have
selected. If you select a single VHDL or Verilog file, you will see the following tabs:

• General tab — properties such as Type, Location, and Size. If you select multiple files,
the file properties on the General tab are not listed.
• Coverage tab
• VHDL or Verilog tab — if you select both a VHDL file and a Verilog file, you will see
all tabs but no file information on the General tab.
If you select a SystemC file, you will see only the General tab.

168 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
File Compilation Properties

Figure 4-17. Specifying File Properties

When setting options on a group of files, keep in mind the following:

• If two or more files have different settings for the same option, the checkbox in the
dialog will be inactive ("grayed out").
• If you change the option, you cannot change it back to a "multi- state setting" without
canceling out of the dialog box.
• If you select a combination of VHDL and Verilog files, the options you set on the
VHDL and Verilog tabs apply only to those file types.
• Once you click OK, ModelSim sets the option the same for all selected files.
PSL assertions are supported in projects. You can click the PSL File button in the VHDL and
Verilog tabs of the Project Compiler Settings dialog to add PSL files. Refer to Verification with
Assertions and Cover Directives for additional information.

ModelSim® SE User's Manual, v10.7 169

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Project Settings

Project Settings
To modify project settings, right-click anywhere within the Project window and choose Project
Settings from the popup menu. This opens the Project Settings Dialog Box.
The Project Settings Dialog Box allows you to select the compile output you want, the location
map, what to do with source files when you open or close a project, and how the double-click
action of your mouse will operate on specific file types.

Figure 4-18. Project Settings Dialog Box

Convert Pathnames to Softnames for Location Mapping . . . . . . . . . . . . . . . . . . . . . . . . 170

Convert Pathnames to Softnames for Location Mapping

If you are using a location map, you can convert relative pathnames, full pathnames, and
pathnames with an environment variable into a soft pathname.
Tip
The term soft pathname (or softname) denotes a pathname that is defined by location
mapping, which uses the environment variable named MGC_LOCATION_MAP. A soft
pathname contains an environment variable that identifies the source of the path instead of
specifying the full absolute path to the physical location. This type of file specification
identifies the source using the location map rather than the current operating environment.

Prerequisites
• Under the Location map section of the Project Settings dialog box (Figure 4-18), enable
the checkbox for “Convert pathnames to softnames.”

170 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Setting Custom Double-click Behavior

Procedure
1. Right-click anywhere within the Project window and select Project Settings
2. Enable “Convert pathnames to softnames” in the Location map area of the Project
Settings dialog box (Figure 4-18).
Results
When you enable the conversion, all pathnames currently in the project are converted to
softnames, as are any that are added later.
During conversion, if there is no softname in the mgc location map that matches the entry, the
pathname is converted to its absolute (hard) pathname. This conversion consists of removing
the environment variable or the relative portion of the path.
Related Topics
Using Location Mapping

Setting Custom Double-click Behavior

Use the Project Settings dialog box to control the double-click behavior of the Project
window.
Procedure
1. Select the desired File Type in the Double-click Behavior pane.
2. Select Custom from the Action dropdown.
3. In the Custom text box, enter a Tcl command that uses %f for filename substitution.
Examples
The following example shows how the Custom text box could appear:

notepad %f

This causes the double-click behavior to substitute %f with the filename that was clicked and
then execute the string.

Access Projects from the Command Line

Generally, you access a project from within the ModelSim GUI. However, you can access a
project from a standalone tool if you invoke it in the project's root directory.
If you want to invoke outside the project directory, set the MODELSIM environment variable
with the path to the project file (<Project_Root_Dir>/<Project_Name>.mpf).

ModelSim® SE User's Manual, v10.7 171

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Access Projects from the Command Line

You can also use the project command from the command line to perform common operations
on projects.

172 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 5
Design Libraries

VHDL designs are associated with libraries, which are objects that contain compiled design
units. SystemC, Verilog and SystemVerilog designs simulated within ModelSim are compiled
into libraries as well.
Design Library Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Working with Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Verilog Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
VHDL Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Importing FPGA Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Protect Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

ModelSim® SE User's Manual, v10.7 173

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Design Library Overview

Design Library Overview

A design library is a directory or archive that serves as a repository for compiled design units.
The design units contained in a design library consist of VHDL entities, packages, architectures,
and configurations; SystemC modules; and Verilog modules and UDPs (user-defined
primitives).

Design units are classified in two ways.

• Primary design units — Entities, package declarations, configuration declarations,

modules, SystemC modules, and UDPs. A primary design unit within a given library
must have a unique name.
• Secondary design units — Consist of optimized Verilog modules, architecture bodies,
and package bodies. A secondary design unit is associated with a primary design unit.
Architectures by the same name can exist if they are associated with different entities or
modules.
Design Unit Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Working Library Versus Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Design Unit Information

Information about each design unit in a design library is stored as part of that library.
The following types of information are stored for each design unit in a design library:

• retargetable, executable code

• debugging information
• dependency information

Working Library Versus Resource Libraries

You can designate a design library as a working library or as a resource library, depending on
how you want to use it for the current simulation.
You can use a design library in either of the following ways:

• A local working library that contains the compiled version of your design. Only one
library can be the working library.
• A resource library.
The contents of your working library change as you update your design and recompile. A
resource library is typically static and serves as a parts source for your design. You can create

174 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Working Library Versus Resource Libraries

your own resource libraries, or they may be supplied by another design team or a third party (for
example, a silicon vendor).

Any number of libraries can be resource libraries during a compilation. You specify which
resource libraries will be used when the design is compiled, and there are rules to specify their
search order (refer to Verilog Resource Libraries and VHDL Resource Libraries).

A common example of using both a working library and a resource library is one in which your
gate-level design and test bench are compiled into the working library and the design references
gate-level models in a separate resource library.

The Library Named “work”

The library named “work” has special attributes within ModelSim — it is predefined in the
compiler, so you do not need to declare it explicitly. It is also the library name used by the
compiler as the default destination of compiled design units, so you do not need to map it. In
other words, the work library is the default working library.

ModelSim® SE User's Manual, v10.7 175

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Working with Design Libraries

Working with Design Libraries

The implementation of a design library is not defined within standard VHDL or Verilog.
ModelSim implements design libraries as directories, which can have any legal name allowed
by the operating system, with one exception: ModelSim does not support extended identifiers
for library names.
Creating a Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Library Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Library Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Map a Logical Name to a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Move a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Setting Up Libraries for Group Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Creating a Library
You need to create a working design library before you run the compiler. This can be done from
either the command line or from the ModelSim graphic interface.
Note
When you create a project, ModelSim automatically creates a working design library.

Procedure
You can use either of the following methods to create a working design library:

• From the ModelSim prompt or from a UNIX/DOS prompt, use the vlib command:
vlib <directory_pathname>

• With the graphic interface, choose File > New > Library.
Either method displays the dialog box shown in Figure 5-1.

176 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Library Size

Figure 5-1. Creating a New Library

Results
When you click OK, ModelSim creates the specified library directory and writes a specially
formatted file named _info into that directory. The _info file must remain in the directory to
distinguish it as a ModelSim library.
The new map entry is written to the modelsim.ini file in the [Library] section. Refer to
modelsim.ini Variables for more information.
Note
Remember that a design library is a special kind of directory. The only way to create a
library is to use the ModelSim GUI (Figure 5-1) or the vlib command. Do not try to create a
library using UNIX, Linux, DOS, or Windows commands.

Related Topics
Getting Started with Projects
modelsim.ini Variables

Library Size
The -smartdbgsym argument of the vcom and vlog commands helps to reduce the size of
debugging database symbol files generated at compile time from the design libraries. When you
specify -smartdbgsym, most design units have their debugging symbol files generated on-
demand by vsim.
Although using this argument provides significant savings in terms of the number of files in the
library and the overall size of the library, there are a few limitations: code coverage flows
cannot support the -smartdbgsym argument and there are limitations to `macro support in
refresh flows.

ModelSim® SE User's Manual, v10.7 177

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Library Window Contents

By default, library size reduction is disabled so that a debugging symbol file database is
generated for all design units. A companion SmartDbgSym variable in modelsim.ini allows you
to enable or disable this capability for all simulations.

Related Topics
vcom and vlog. [ModelSim SE Command Reference Manual]

Library Window Contents

You can use either the graphic user interface (GUI) or the command line to view, delete,
recompile, or edit the contents of a library. The GUI method is provided in the Library window.
The Library window (Figure 5-2) provides access to design units (configurations, modules,
packages, entities, architectures, and SystemC modules) in a library. Categories of information
about the design units appear in columns to the right of the design unit name.

Figure 5-2. The Library Window—Design Unit Information in the Workspace

The Library window provides a popup menu with various commands that you can display by
clicking your right mouse button.

The context menu includes the following commands:

• Simulate — Loads and optimizes the selected design unit(s) and opens Structure (sim)
and Files windows. Related command line command is vsim -voptargs+acc.
• Simulate with full Optimization — Loads and optimizes the selected design unit(s).
Related command line command is vsim -vopt.
• Simulate with Coverage — Loads the selected design unit(s) and collects code
coverage data. Related command line command is vsim -coverage.

178 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Library Window Contents

• Edit — Opens the selected design unit(s) in the Source window; or, if a library is
selected, opens the Edit Library Mapping dialog (refer to Map a Logical Name to a
Design Library).
• Refresh — Rebuilds the library image of the selected library without using source code.
Related command line command is vcom or vlog with the -refresh argument.
• Recompile — Recompiles the selected design unit(s). Related command line command
is vcom or vlog.
• Optimize — Optimizes the selected Verilog design unit(s). Related command line
command is vopt.
• Update — Updates the display of available libraries and design units.
• Create Wave — Opens a Wave window and loads the objects from the selected design
unit(s) as editable waveforms. Related command line command is wave create -pattern
none.

ModelSim® SE User's Manual, v10.7 179

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Map a Logical Name to a Design Library

Map a Logical Name to a Design Library

VHDL uses logical library names that you can map to ModelSim library directories. By default,
ModelSim can find libraries in your current directory (assuming they have the right name), but
for it to find libraries located elsewhere, you need to map a logical library name to the pathname
of the library.
For Verilog and SystemVerilog libraries, ModelSim searches for the mapping of a logical name
in the following order:

• A modelsim.ini file.
• If the search does not find a modelsim.ini file, or if the specified logical name does not
exist in the modelsim.ini file, ModelSim searches the current working directory for a
subdirectory that matches the logical name.
The compiler generates an error if you specify a logical name that does not resolve to an
existing directory.

You can use the GUI, a command, or a project to assign a logical name to a design library. You
can also map multiple logical names to the same design library.

Mapping a Library with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Mapping a Library from the Command Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Manual Mapping of the modelsim.ini File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Mapping a Library with the GUI

You can map a library with the GUI using the Edit Library Mapping dialog box.
Procedure
1. Select the library in the Library window.
2. Right-click on the library name, which displays a popup menu.
3. Choose Edit. This displays a dialog box where you can edit the mapping.

180 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Map a Logical Name to a Design Library

Figure 5-3. Edit Library Mapping Dialog Box

The dialog box includes these options:

• Library Mapping Name — The logical name of the library.
• Library Pathname — The pathname to the library.

Mapping a Library from the Command Line

Use the vmap command to map a library from the command line.
Procedure
1. Use the vmap command. For example:
vmap <logical_name> <directory_pathname>

2. You can invoke this command from UNIX, Linux, or DOS prompt or from the
command line within ModelSim.
3. The vmap command adds the mapping to the library section of the modelsim.ini file.

Manual Mapping of the modelsim.ini File

You can map a library by manually modifying the modelsim.ini file.
Procedure
1. Open the modelsim.ini file with a text editor
2. Add a line under the [Library] section heading using the syntax:
<logical_name> = <directory_pathname>

To map more than one logical name to a single directory:

a. Open the modelsim.ini file with a text editor

ModelSim® SE User's Manual, v10.7 181

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Move a Library

b. Add a library logical name and pathname for the same library under the [Library]
section heading using the syntax. For example:
[Library]
work = /usr/rick/design
my_asic = /usr/rick/design

In this example, you can use either the logical name work or my_asic in a library or
use clause to refer to the same design library.
You can also create a UNIX symbolic link to the library using the ln -s command. For
example:
ln -s <directory_pathname> <logical_name>

3. (optional) Use the vmap command to display the mapping of a logical library name to a
directory. To do this, enter the shortened form of the command:
vmap <logical_name>

Related Topics
modelsim.ini Variables

Move a Library
Individual design units in a design library cannot be moved. However, you can move an entire
design library by using standard operating system commands for moving a directory or an
archive.

Setting Up Libraries for Group Use

By adding an “others” specification to your modelsim.ini file, you can establish a hierarchy of
library mappings. These mappings can reside in other locations. In particular, you can identify a
library in a common location that has been made available for group use.
If ModelSim does not find a mapping in the modelsim.ini file, then it will search the [library]
section of the initialization file specified by the “others” specification.

For example:

[library]
asic_lib = /cae/asic_lib
work = my_work
others = /usr/modeltech/modelsim.ini

You can specify only one others clause in the library section of a given modelsim.ini file.

The “others” clause instructs ModelSim to look only in the specified modelsim.ini file for a
library. It does not load any other part of the specified file.

182 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Setting Up Libraries for Group Use

If two libraries with the same name are mapped to two different locations—one in the current
modelsim.ini file and the other specified by the others clause—then the mapping specified in the
current .ini file takes effect.

ModelSim® SE User's Manual, v10.7 183

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Verilog Resource Libraries

Verilog Resource Libraries

All modules and UDPs in a Verilog design must be compiled into one or more libraries. One
library is usually sufficient for a simple design, but you may want to organize your modules into
various libraries for a complex design. If your design uses different modules having the same
name, then you need to put those modules in different libraries because design unit names must
be unique within a library.
The following is an example of how to organize your ASIC cells into one library and the rest of
your design into another:

vlib work
vlib asiclib
vlog -work asiclib and2.v or2.v
-- Compiling module and2
-- Compiling module or2

Top level modules:

and2
or2
% vlog top.v
-- Compiling module top

Top level modules:

top

Note that the first compilation uses the -work asiclib argument to instruct the compiler to place
the results in the asiclib library rather than the default work library.

Library Search Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Handling Sub-Modules with the Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
The LibrarySearchPath Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Library Search Rules

Because instantiation bindings are not determined at compile time, you must instruct the
simulator to search your libraries when loading the design.
Top-level modules are loaded from the library named work unless you prefix the modules with
the <library> option. If they are not found in the work library, they are searched in the libraries
specified with -Lf arguments, followed by libraries specified with -L arguments.

All other Verilog instantiations are resolved in the following order:

• Search libraries specified with -Lf arguments for the vlog, vopt, or vsim commands in
the order they appear on the command line.

184 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Handling Sub-Modules with the Same Name

• Search the library specified in the Verilog-XL uselib Compiler Directive section.
• Search libraries specified with -L arguments for the vlog, vopt, or vsim commands in the
order they appear on the command line.
• Search the work library.
• Search the library explicitly named in the special escaped identifier instance name.
• Search the libraries containing top design units that are not explicitly present in the set of
-L/-Lf options.

Note
The -libverbose argument for the vopt and vsim commands provides verbose messaging
about library search and resolution operations. Using -libverbose=prlib prints out the -L or -
Lf setting used to locate each design unit.

Related Topics
SystemVerilog Multi-File Compilation

Handling Sub-Modules with the Same Name

Sometimes in one design you need to reference two different modules that have the same name.
This situation can occur if you have hierarchical modules organized into separate libraries, and
multiple libraries have sub-modules that have the same name but with different definitions.
This may happen if you are using vendor-supplied libraries. For example, consider the design
configuration shown in Figure 5-4.

Figure 5-4. Sub-Modules with the Same Name

The normal library search rules do not work in this situation. For example, if you load the
design as follows:

vsim -L lib1 -L lib2 top

ModelSim® SE User's Manual, v10.7 185

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
The LibrarySearchPath Variable

both instantiations of cellX resolve to the lib1 version of cellX. On the other hand, if you specify
-L lib2 -L lib1, both instantiations of cellX resolve to the lib2 version of cellX.

To resolve this situation, ModelSim implements a special interpretation of the expression -L

work. When you specify -L work first in the search library arguments you are directing vsim to
search for the instantiated module or UDP in the library that contains the module that does the
instantiation.

In the example above you would invoke vsim as follows:

vsim -L work -L lib1 -L lib2 top

The LibrarySearchPath Variable

The LibrarySearchPath variable in the modelsim.ini file (in the [vlog] section) defines a space-
separated list of resource library paths and/or library path variables. This behavior is identical to
the -L argument for the vlog command.
LibrarySearchPath = <path>/lib1 <path>/lib2 <path>/lib3

The default for LibrarySearchPath is:

LibrarySearchPath = mtiAvm mtiOvm mtiUvm mtiUPF

Related Topics
LibrarySearchPath
vlog. [ModelSim SE Command Reference Manual]

186 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
VHDL Resource Libraries

VHDL Resource Libraries

Within a VHDL source file, you use the VHDL library clause to specify logical names of one
or more resource libraries to be referenced in the subsequent design unit.
The scope of a library clause includes the text region that starts immediately after the library
clause and extends to the end of the declarative region of the associated design unit. The scope
does not extend to the next design unit in the file.

Tip
Note that the library clause does not specify the working library into which the design unit
is placed after compilation. The vcom command adds compiled design units to the current
working library—by default, this is the library named work. To change the current working
library, use vcom -work and specify the name of the desired target library.

Predefined Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Alternate IEEE Libraries Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Regenerating Your Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Predefined Libraries
Certain resource libraries are predefined in standard VHDL. The library named std contains the
packages standard, env, and textio. The contents of these packages and other aspects of the
predefined language environment are documented in the IEEE Standard VHDL Language
Reference Manual, Std 1076. Do not modify any contents of this predefined library.
A VHDL use clause selects particular declarations in a library or package that are to be visible
within a design unit during compilation. A use clause references the compiled version of the
package—not the source.

By default, every VHDL design unit should contain the following declarations:

LIBRARY std, work;

USE std.standard.all

To specify referencing of all declarations in a library or package, add the suffix .all to the
library/package name. For example, the use clause above specifies that all declarations in the
package standard, in the design library named std, are to be visible to the VHDL design unit
immediately following the use clause. Other libraries or packages are not visible unless they are
explicitly specified using a library or use clause.

Another predefined library is work, the library where a design unit is stored after you have
compiled it. There is no limit to the number of libraries that you can reference , but only one
library is modified during compilation.

ModelSim® SE User's Manual, v10.7 187

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Alternate IEEE Libraries Supplied

Related Topics
The TextIO Package

Alternate IEEE Libraries Supplied

The installation directory may contain two or more versions of the IEEE library.
• ieeepure — Contains only IEEE approved packages (accelerated for ModelSim).
• ieee — (default) Contains precompiled Synopsys and IEEE arithmetic packages which
have been accelerated for ModelSim, including math_complex, math_real, numeric_bit,
numeric_std, std_logic_1164, std_logic_misc, std_logic_textio, std_logic_arith,
std_logic_signed, std_logic_unsigned, vital_primitives, and vital_timing.
You can select which library to use by changing the mapping in the modelsim.ini file.

Regenerating Your Design Libraries

Depending on your current ModelSim version, you may need to regenerate your design libraries
before running a simulation. You do this by using the -refresh argument to either the vcom or
vlog command. Check the installation README file to see if your libraries require an update.
By default, using -refresh updates the current work library. An important feature of using the -
refresh argument is that it rebuilds the library image without using source code. This means that
you can rebuild models delivered as compiled libraries (without source code) for a specific
release of ModelSim. In general, this works for moving forwards or backwards on a release.
Moving backwards on a release may not work if the models used compiler switches, directives,
language constructs, or features that do not exist in the older release.

Restrictions and Limitations

You do not need to regenerate the std, ieee, vital22b, and verilog libraries. Also, you cannot use
the -refresh argument to update libraries that were built before Release 4.6.

You can specify a specific design unit name with the -refresh argument to vcom and vlog in
order to regenerate a library image for only that design, but you cannot specify a file name.

Procedure
1. Identify the HDL of the library you want to regenerate: VHDL or Verilog.

188 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Importing FPGA Libraries

2. Determine whether you want to regenerate design units in the work library from the GUI
or from the command line:

If you want to update from... Do the following...

The GUI Choose Library > Regenerate from the
(VHDL or Verilog) main menu.
The command line Use vcom with the -refresh argument.
(VHDL)
The command line Use vlog with the -refresh argument.
(Verilog)

3. (optional) To update a library other than work from the command line, use either the
vcom or vlog command with the -work <library> argument to regenerate that library.
For example, if you have a library named mylib that contains both VHDL and Verilog
design units, enter the following two commands:
vcom -work mylib -refresh
vlog -work mylib - refresh

Related Topics
Library Window Contents
vcom, and vlog. [ModelSim SE Command Reference Manual]

Importing FPGA Libraries

ModelSim includes an import wizard for referencing and using vendor FPGA libraries. The
wizard scans for and enforces dependencies in the libraries and determines the correct mappings
and target directories.
Prerequisites
The FPGA libraries you import must be pre-compiled. Most FPGA vendors supply pre-
compiled libraries configured for use with ModelSim.

Procedure
1. Select File > Import > Library to open the Import Library Wizard. (Figure 5-5)

ModelSim® SE User's Manual, v10.7 189

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
Protect Source Code

Figure 5-5. Import Library Wizard

2. Follow the instructions in the wizard to complete the import.

Protect Source Code

The Protecting Your Source Code chapter provides details about protecting your internal model
data. This allows a model supplier to provide pre-compiled libraries without providing source
code and without revealing internal model variables and structure.
Related Topics
Protecting Your Source Code

190 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 6
VHDL Simulation

ModelSim enables you to compile, optimize, load, and simulate VHDL designs.
Basic VHDL Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Compilation and Simulation of VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Usage Characteristics and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
The TextIO Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
VITAL Usage and Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VHDL Utilities Package (util) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Modeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
VHDL Access Object Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Basic VHDL Usage

The following steps summarize the basic VHDL usage process:

1. Compile your VHDL code into one or more libraries using the vcom command. Refer to
Compilation of a VHDL Design—the vcom Command for more information.
2. (Optional) Elaborate and optimize your design using the vopt command. Refer to the
chapter Optimizing Designs with vopt for more information.
3. Load your design with the vsim command. Refer to Simulation of a VHDL Design—the
vsim Command.
4. Simulate the loaded design, then debug as needed.

ModelSim® SE User's Manual, v10.7 191

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Compilation and Simulation of VHDL

Compilation and Simulation of VHDL

The basic operations for using VHDL with ModelSim are establishing a library for compilation
results, compilation, and simulation.
Optionally, you can also use the vopt command to optimize your design before simulation.

Creating a Design Library for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Compilation of a VHDL Design—the vcom Command . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Simulation of a VHDL Design—the vsim Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Creating a Design Library for VHDL

Before you can compile your VHDL source files, you must create a library in which to store the
compilation results.
Procedure
Use the vlib command to create a new library. For example:

vlib work

Results
Running the vlib command creates a library named work. By default, compilation results are
stored in the work library.
Caution
The work library is actually a subdirectory named work. This subdirectory contains a
special file named _info. Do not use a system command to create a VHDL library as a
directory—always use the vlib command.

Related Topics
Design Libraries

Compilation of a VHDL Design—the vcom

Command
ModelSim compiles one or more VHDL design units with a single invocation of the vcom
command, which functions as the VHDL compiler.
Design units compile in the order they appear on the command line. For VHDL, the order of
compilation is important—you must compile any entities or configurations before an
architecture that references them.

192 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Compilation of a VHDL Design—the vcom Command

You can simulate a design written with any of the following versions of VHDL, but you must
compile units from each version separately:

• 1076-1987
• 1076-1993
• 1076-2002
• 1076-2008
The vcom command compiles using 1076 -2002 rules by default; use the -87, -93, or -2008
arguments to compile units written with version 1076-1987, 1076 -1993, or 1076-2008
respectively. You can change the default by modifying the VHDL93 variable in the
modelsim.ini file (see modelsim.ini Variables for more information).

Note
Not all VHDL 1076-2008 constructs are currently supported. From the main window, select
Help > Technotes > vhdl2008 for more information.

Dependency Checking
You must re-analyze dependent design units when you change the design units they depend on
in the library. The vcom command determines whether or not the compilation results have
changed.

For example, if you keep an entity and its architectures in the same source file, and you modify
only an architecture and recompile the source file, the entity compilation results remain
unchanged. This means you do not have to recompile design units that depend on the entity.

VHDL Case Sensitivity

VHDL is a case-insensitive language for all basic identifiers. For example, clk and CLK are
regarded as the same name for a given signal or variable.

Note
This differs from the Verilog and SystemVerilog languages, both of which are case-
sensitive.

The vcom command preserves both uppercase and lowercase letters of all user-defined object
names in a VHDL source file.

Usage Notes
• You can use either of the following methods to convert uppercase letters to lowercase:
o Use the -lower argument with the vcom command.

ModelSim® SE User's Manual, v10.7 193

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Compilation of a VHDL Design—the vcom Command

o Set the PreserveCase variable to 0 in your modelsim.ini file.

• The supplied precompiled packages in STD and IEEE have their case preserved. This
results in slightly different version numbers for these packages. As a result, you may
receive out-of-date reference messages when refreshing to the current release. To
resolve this, use vcom -force_refresh instead of vcom -refresh.
• Mixed language interactions are addressed in the following ways:
o Design unit names — Because VHDL and Verilog design units are mixed in the
same library, VHDL design units are treated as if they are lowercase. Treating
VHDL design units as lower case provides compatibility with previous releases, and
provides consistent filenames in the file system for make files and scripts.
o Verilog packages compiled with -mixedsvvh — These packages are not affected
by VHDL uppercase conversion.
o VHDL packages compiled with -mixedsvvh — These packages are not affected by
VHDL uppercase conversion; VHDL basic identifiers are still converted to
lowercase for compatibility with previous releases.
o FLI — Functions that return names of an object do not have the original case unless
you use vcom -lower to compile the source. Port and Generic names in the
mtiInterfaceListT structure convert to lowercase to provide compatibility with
programs doing case sensitive comparisons (strcmp) on the generic and port names.

How Case Affects Default Binding

The following rules describe how ModelSim handles uppercase and lowercase names in default
bindings.

1. All VHDL names are case-insensitive, so ModelSim always stores them in the library in
lowercase to be consistent and compatible with older releases.
2. When looking for a design unit in a library, ModelSim ignores the VHDL case and looks
first for the name in lowercase. If the lowercase name is present, ModelSim uses it.
3. If no lowercase version of the design unit name exists in the library, then ModelSim
checks the library, ignoring case.
a. If ONE match is found this way, ModelSim selects that design unit.
b. If NO matches or TWO or more matches are found, ModelSim does not select
anything.
The following examples demonstrate these rules. In these examples, the VHDL compiler needs
to find a design unit named Test. Because VHDL is case-insensitive, ModelSim looks for "test"
because previous releases always converted identifiers to lowercase.

194 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Compilation of a VHDL Design—the vcom Command

Example 1
Consider the following library:

work
entity test
Module TEST

The VHDL entity test is selected because it is stored in the library in lowercase. The original
VHDL could have contained TEST, Test, or TeSt, but the library always contains the entity as
"test."

Example 2
Consider the following library:

work
Module Test

No design unit named "test" exists, but "Test" matches when case is ignored, so ModelSim
selects it.

Example 3
Consider the following library:

work
Module Test
Module TEST

No design unit named "test" exists, but both "Test" and "TEST" match when case is ignored, so
ModelSim does not select either one.

Range and Index Checking

A range check verifies that a scalar value defined to be of a subtype with a range is always
assigned a value within its range. An index check verifies that whenever an array subscript
expression is evaluated, the subscript will be within the array's range.

Range and index checks are performed by default when you compile your design. You can
disable range checks (potentially offering a performance advantage) using arguments to the
vcom command. Or, you can use the NoRangeCheck and NoIndexCheck variables in the
[vcom] section of the modelsim.ini file to specify not to perform checks. Refer to modelsim.ini
Variables for more information.

Generally, disable these checks only after the design is known to be error-free. If you run a
simulation with range checking disabled, any scalar values that are out of range display the
value in the following format: ?(N) where N is the current value. For example, the range
constraint for STD_ULOGIC is 'U' to '-'; if the value is reported as ?(25), the value is out of

ModelSim® SE User's Manual, v10.7 195

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Compilation of a VHDL Design—the vcom Command

range because the type STD_ULOGIC value internally is between 0 and 8 (inclusive). Values
that are out of range may indicate that an error in the design is not being caught because range
checking was disabled.

Range checks in ModelSim are more restrictive than those specified by the VHDL Language
Reference Manual (LRM). ModelSim requires any assignment to a signal to also be in range,
whereas the LRM requires only that range checks be done whenever a signal is updated. The
more restrictive requirement allows ModelSim to generate better error messages.

Subprogram Inlining
ModelSim attempts to inline subprograms at compile time to improve simulation performance.
This happens automatically and is largely transparent. However, you can disable automatic
inlining two ways:

• Invoke vcom with the -O0 or -O1 argument

• Use the mti_inhibit_inline attribute as described below
Single-stepping through a simulation varies slightly, depending on whether inlining occurred.

• When single-stepping to a subprogram call that has not been inlined, the simulator stops
first at the line of the call, and then proceeds to the line of the first executable statement
in the called subprogram.
• When single-stepping to a subprogram call that has been inlined, the simulator does not
first stop at the subprogram call, but stops immediately at the line of the first executable
statement.

mti_inhibit_inline Attribute
You can use the mti_inhibit_inline attribute to disable inlining for individual design units (a
package, architecture, or entity) and subprograms. Follow these rules to use the attribute:

• Declare the attribute within the design unit's scope as follows:

attribute mti_inhibit_inline : boolean;

• Assign the value true to the attribute for the appropriate scope. For example, to inhibit
inlining for a particular function (for example, "foo"), add the following attribute
assignment:
attribute mti_inhibit_inline of foo : procedure is true;

To inhibit inlining for a particular package (for example, "pack"), add the following
attribute assignment:
attribute mti_inhibit_inline of pack : package is true;

Use the same method to inhibit inlining for entities and architectures.

196 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Simulation of a VHDL Design—the vsim Command

Simulation of a VHDL Design—the vsim Command

A VHDL design is ready for simulation after you compile it with vcom. You can then use the
vsim command to invoke the simulator with the name(s) of the configuration or entity/
architecture pair.
Note
This section discusses invoking simulation from the command line (in UNIX or Windows/
DOS). Alternatively, you can use a project to simulate (refert to Getting Started with
Projects) or use the Start Simulation dialog box (choose Simulate > Start Simulationfrom the
main menu).

If you have used the vopt command to optimize a VHDL design (see Optimizing Designs with
vopt), you can specify multiple optimized top design modules. For more information about
simulation with multiple optimized design modules, refer to the <library_name>.<design_unit>
argument to vsim.

The following example uses the vsim command to begin simulation on a design unit that has an
entity named my_asic and an architecture named structure:

vsim my_asic structure

Timing Specification
The vsim command annotates a design using VITAL-compliant models with timing data from
an SDF file. You can specify delay by using the vsim command with the -sdfmin, -sdftyp, or
-sdfmax arguments.

The following example annotates maximum timing values for the design unit named my _asic
by using an SDF file named f1.sdf in the current work directory:

vsim -sdfmax /my_asic=f1.sdf my_asic

By default, the timing checks within VITAL models are enabled (refer to VITAL Usage and
Compliance). You can disable them with the +notimingchecks argument. For example:

vsim +notimingchecks topmod

If you specify vsim +notimingchecks, the generic TimingChecksOn is set to FALSE for all
VITAL models with the Vital_level0 or Vital_level1 attribute. Setting this generic to FALSE
disables the actual calls to the timing checks and anything else in the model's timing check
block. In addition, if these models use the generic TimingChecksOn to control behavior beyond
timing checks, this behavior will not occur. This can cause designs to simulate differently and
provide different results.

By default, vopt does not fix the TimingChecksOn generic in VITAL models. Instead, it lets the
value float to allow for overriding at simulation time. If best performance and no timing checks
are desired, specify +notimingchecks with vopt.

ModelSim® SE User's Manual, v10.7 197

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Simulation of a VHDL Design—the vsim Command

vopt +notimingchecks topmod

Specifying vopt +notimingchecks or -GTimingChecks=<FALSE/TRUE> sets the generic value

for simulation. As a consequence, using vsim +notimingchecks at simulation may not have any
effect on the simulation, depending on the optimization of the model.

198 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Usage Characteristics and Requirements

Usage Characteristics and Requirements

ModelSim supports the use of VHDL in compliance with the IEEE Standard VHDL Language
Reference Manual (IEEE Std 1076), which was originally adopted in 1987. This standard has
undergone several revisions, each of which is identified by a suffix indicating the year of its
approval by the IEEE. There are considerations in using VHDL with ModelSim that are not
explicitly covered by the Language Reference Manual (LRM).
Differences Between Supported Versions of the VHDL Standard . . . . . . . . . . . . . . . . . 199
Naming Behavior of VHDL for Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Foreign Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Simulator Resolution Limit for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Default Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Delta Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Differences Between Supported Versions of the

VHDL Standard
The four different versions of the VHDL standard (IEEE Std 1076) have names that reflect the
year each version was approved by the IEEE: 1076-1987, 1076-1993, 1076-2002, and 1076-
2008. The default language version supported for ModelSim is 1076-2002.
If your VHDL design was written according to the 1987, 1993, or 2008 version, you may need
to update your code or instruct ModelSim to use rules for a version.

To select a specific language version, do one of the following:

• Select the appropriate version from the compiler options menu in the GUI.
• Invoke vcom using the argument -87, -93, -2002, or -2008.
• Set the VHDL93 variable in the [vcom] section of the modelsim.ini file to one of the
following values:
- 0, 87, or 1987 for 1076-1987
- 1, 93, or 1993 for 1076-1993
- 2, 02, or 2002 for 1076-2002
- 3, 08, or 2008 for 1076-2008

Incompatibilities Among Versions of the VHDL Standard

The following is a list of VHDL standard incompatibilities that may cause problems when
compiling a design.

ModelSim® SE User's Manual, v10.7 199

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Differences Between Supported Versions of the VHDL Standard

Tip
Refer to ModelSim Release Notes for the most current and comprehensive description of
differences between supported versions of the VHDL standard.

• VHDL-93 and VHDL-2002 — The only major problem between VHDL-93 and
VHDL-2002 is the addition of the keyword "PROTECTED". If you have VHDL-93
programs which use PROTECTED as an identifier, you should choose a different name.
All other incompatibilities are between VHDL-87 and VHDL-93.
• VITAL and SDF — It is important to use the correct language version for VITAL.
VITAL2000 must be compiled with VHDL-93 or VHDL-2002. VITAL95 must be
compiled with VHDL-87. A typical error message that indicates the need to compile
under language version VHDL-87 is:
"VITALPathDelay DefaultDelay parameter must be locally static"

• Purity of “now” function— In VHDL-93, the function "now" is impure. Consequently,

any function that invokes "now" must also be declared to be impure. Such calls to "now"
occur in VITAL. A typical error message:
"Cannot call impure function 'now' from inside pure function
'<name>'"

• Files — File syntax and usage changed between VHDL-87 and VHDL-93. In many
cases vcom issues a warning and continues:
"Using 1076-1987 syntax for file declaration."

In addition, passing files as parameters produces the following warning message:

"Subprogram parameter name is declared using VHDL 1987 syntax."

This message often involves calls to endfile(<name>) where <name> is a file parameter.
• Files and packages — Compile each package header and body with the same language
version. Common problems in this area involve files as parameters and the size of type
CHARACTER. For example, consider a package header and body with a procedure that
has a file parameter:
procedure proc1 ( out_file : out std.textio.text) ...

If you compile the package header with VHDL-87 and the body with VHDL-93 or
VHDL-2002, you get an error message such as:
"** Error: mixed_package_b.vhd(4): Parameter kinds do not conform
between declarations in package header and body: 'out_file'."

200 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Differences Between Supported Versions of the VHDL Standard

• Direction of concatenation — To solve some technical problems, the rules for

direction and bounds of concatenation were changed from VHDL-87 to VHDL-93. You
will not see any difference in simple variable/signal assignments such as:
v1 := a & b;

But you get unexpected results if: you have a function that takes an unconstrained array
as a parameter, you then pass a concatenation expression as a formal argument to this
parameter, and the body of the function makes assumptions about the direction or
bounds of the parameter. This can be a problem in environments that assume all arrays
have "downto" direction.
• xnor — "xnor" is a reserved word in VHDL-93. If you declare an xnor function in
VHDL-87 (without quotes) and compile it under VHDL-2002, you get an error message
like the following:
** Error: xnor.vhd(3): near "xnor": expecting: STRING IDENTIFIER

• 'FOREIGN attribute — In the VHDL-93 package, STANDARD declares an attribute

'FOREIGN. If you declare your own attribute with that name in another package, then
ModelSim issues a warning such as the following:
-- Compiling package foopack

** Warning: foreign.vhd(9): (vcom-1140) VHDL-1993 added a definition

of the attribute foreign to package std.standard. The attribute is
also defined in package 'standard'. Using the definition from
package 'standard'.

• Size of CHARACTER type — In VHDL-87 type CHARACTER has 128 values; in

VHDL-93 it has 256 values. Code that depends on one of these sizes can behave
incorrectly between standards. This situation occurs most commonly in test suites that
check VHDL functionality, though it is unlikely to occur in practical designs. A typical
instance is the replacement of warning message:
"range nul downto del is null"

by
"range nul downto 'ÿ' is null" -- range is nul downto y(umlaut)

• bit string literals — In VHDL-87 bit string literals are of type bit_vector. In VHDL-93
they can also be of type STRING or STD_LOGIC_VECTOR. This implies that some
expressions that are unambiguous in VHDL-87 now become ambiguous in VHDL-93. A
typical error message is:
** Error: bit_string_literal.vhd(5): Subprogram '=' is ambiguous.
Suitable definitions exist in packages 'std_logic_1164' and
'standard'.

ModelSim® SE User's Manual, v10.7 201

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Naming Behavior of VHDL for Generate Blocks

• Sub-element association — In VHDL-87, when using individual sub-element

association in an association list, associating individual sub-elements with NULL is
discouraged. In VHDL-93 such association is forbidden. A typical message is:
"Formal '<name>' must not be associated with OPEN when subelements
are associated individually."

• VHDL-2008 packages — ModelSim does not provide VHDL source for VHDL-2008
IEEE-defined standard packages because of copyright restrictions. You can obtain
VHDL source from http://standards.ieee.org//downloads/1076/1076-2008/ for the
following packages:
IEEE.fixed_float_types
IEEE.fixed_generic_pkg
IEEE.fixed_pkg
IEEE.float_generic_pkg
IEEE.float_pkg
IEEE.MATH_REAL
IEEE.MATH_COMPLEX
IEEE.NUMERIC_BIT
IEEE.NUMERIC_BIT_UNSIGNED
IEEE.NUMERIC_STD
IEEE.NUMERIC_STD_UNSIGNED
IEEE.std_logic_1164
IEEE.std_logic_textio

Naming Behavior of VHDL for Generate Blocks

A VHDL for … generate statement, when elaborated in a design, places a given number of
for … generate equivalent blocks into the scope in which the statement exists; either an
architecture, a block, or another generate block. The simulator constructs a design path name for
each of these for … generate equivalent blocks based on the original generate statement's label
and the value of the generate parameter for that particular iteration.
For example, given the following code:

g1: for I in 1 to Depth generate

L: BLK port map (A(I), B(I+1));
end generate g1

the default names of the blocks in the design hierarchy would be:

g1(1), g1(2), ...

The default names appear in the GUI to identify each block. Use the block’s default name with
any commands when referencing a block that is part of the simulation environment. The format
of the name is based on the VHDL Language Reference Manual P1076-2008 section 16.2.5
Predefined Attributes of Named Entities.

If the type of the generate parameter is an enumeration type, the value within the parenthesis is
an enumeration literal of that type; such as: g1(red).

202 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Foreign Language Interface

For mixed-language designs, in which a Verilog hierarchical reference is used to reference

something inside a VHDL for … generate equivalent block, the parentheses are replaced with
brackets ( [] ) to match Verilog syntax. If the name is dependent upon enumeration literals, the
literal is replaced with its position number, because Verilog does not support using enumerated
literals in its for … generate equivalent block.

In releases prior to the 6.6 series, this default name was controlled by the GenerateFormat
modelsim.ini file variable, and would have appeared as:

g1__1, g1__2, ...

All previously-generated scripts using this old format should work by default, but you can use
the GenerateFormat and OldVhdlForGenNames modelsim.ini variables to ensure that the old
and current names are mapped correctly.

Foreign Language Interface

Foreign language interface (FLI) routines are C programming language functions that provide
procedural access to information within the HDL simulator, vsim. A user-written application
can use these functions to traverse the hierarchy of an HDL design, get information about and
set the values of VHDL objects in the design, get information about a simulation, and control (to
some extent) a simulation run.
The ModelSim FLI interface is described in detail in the Foreign Language Interface Reference
Manual.

Simulator Resolution Limit for VHDL

The simulator internally represents time as a 64-bit integer in units equivalent to the smallest
unit of simulation time, also known as the simulator resolution limit.
The default resolution limit is set to the value specified by the Resolution variable in the
modelsim.ini file. You can view the current resolution by invoking the report command with the
simulator state argument.

Note
In Verilog, the representation of time units is referred to as precision or timescale.

ModelSim® SE User's Manual, v10.7 203

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Default Binding

Overriding the Default Resolution

To override the default resolution of ModelSim, specify a value for the -t argument of the vsim
command line, or select a different Simulator Resolution in the Simulate dialog box. Available
values of simulator resolution are:

1 fs, 10 fs, 100 fs

1 ps, 10 ps, 100 ps
1 ns, 10 ns, 100 ns
1 us, 10 us, 100 us
1 ms, 10 ms, 100 ms
1 s, 10 s, 100 s

For example, the following command sets resolution to 10 ps:

vsim -t 10ps topmod

Take care when specifying a resolution value larger than a delay value in your design—delay
values in that design unit are rounded to the closest multiple of the resolution. In the example
above, a delay of 4 ps would be rounded down to 0 ps.

Choosing a Resolution Value for VHDL

You should specify the coarsest value for time resolution that does not result in undesired
rounding of your delay times. The resolution value should not be unnecessarily small because it
decreases the maximum simulation time limit and can cause longer simulations.

Default Binding
By default, ModelSim performs binding when you load the design with the vsim command. The
advantage of this default binding at load time is that it provides more flexibility for compile
order, in that VHDL entities do not necessarily have to be compiled before other entities/
architectures that instantiate them.
However, you can force ModelSim to perform default binding at compile time instead. This can
help you to catch design errors (for example, entities with incorrect port lists) earlier in the flow.
Use one of these two methods to change when default binding occurs:

• Specify the -bindAtCompile argument to vcom

• Set the BindAtCompile variable in the modelsim.ini to 1 (true)

Default Binding Rules

When searching for a VHDL entity with which to bind, ModelSim searches the currently visible
libraries for an entity with the same name as the component. ModelSim does this because IEEE
Std 1076-1987 contained a flaw that made it almost impossible for an entity to be directly
visible if it had the same name as the component. This meant if a component was declared in an

204 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Delta Delays

architecture, any entity with the same name above that declaration would be hidden because
component/entity names cannot be overloaded. To counter the IEEE flaw, ModelSim observes
the following rules for determining default binding:

• If performing default binding at load time, search the libraries specified with the -Lf
argument to vsim.
• If a directly visible entity has the same name as the component, use it.
• If an entity would be directly visible in the absence of the component declaration, use it.
• If the component is declared in a package, search the library that contained the package
for an entity with the same name.
• If a configuration declaration contains library and use clauses, use them.
If none of these methods are successful, ModelSim then does the following:

• Searches the work library.

• Searches all other libraries that are currently visible by means of the library clause.
• If performing default binding at load time, searches the libraries specified with the -L
argument to vsim.
Note that these last three searches are an extension to the 1076 standard.

Disabling Default Binding

If an appropriate binding cannot be made between an entity and an architecture, default port,
and generic maps, ModelSim issues an error or warning. You can disable normal default
binding methods and require a user specified binding by setting the
RequireConfigForAllDefaultBinding variable in the modelsim.ini file to 1 (true), or by
specifying the -ignoredefaultbind argument to vcom.

When you specify the RequireConfigForAllDefaultBinding, ModelSim requires you to provide

a configuration specification or component configuration in order to bind an entity with an
architecture. You must explicitly bind all components in the design through either configuration
specifications or configurations. If an explicit binding is not fully specified, defaults for the
architecture, port maps, and generic maps are used.

Delta Delays
Event-based simulators such as ModelSim can process many events at a given simulation time.
Multiple signals may need updating, statements that are sensitive to these signals must be
executed, and any new events that result from these statements must then be queued and
executed as well. The steps taken to evaluate the design without advancing simulation time are
referred to as "delta times" or just "deltas."

ModelSim® SE User's Manual, v10.7 205

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Delta Delays

Figure 6-1 illustrates the process for VHDL designs. This process continues until the end of
simulation time.

Figure 6-1. VHDL Delta Delay Process

This mechanism in event-based simulators may cause unexpected results. Consider the
following code fragment:

clk2 <= clk;

process (rst, clk)

begin
if(rst = '0')then
s0 <= '0';
elsif(clk'event and clk='1') then
s0 <= inp;
end if;
end process;

process (rst, clk2)

begin
if(rst = '0')then
s1 <= '0';
elsif(clk2'event and clk2='1') then
s1 <= s0;
end if;
end process;

In this example, there are two synchronous processes, one triggered with clk and the other with
clk2. Consider the unexpected situation of the signals changing in the clk2 process on the same
edge as they are set in the clk process. As a result, the value of inp appears at s1 rather than s0.

206 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Delta Delays

During simulation an event on clk occurs (from the test bench). From this event, ModelSim
performs the "clk2 <= clk" assignment and the process that is sensitive to clk. Before advancing
the simulation time, ModelSim finds that the process sensitive to clk2 can also be run. Since
there are no delays present, the value of inp appears at s1 in the same simulation cycle.

In order to correct this and get the expected results, you must do one of the following:

• Insert a delay at every output

• Use the same clock
• Insert a delta delay
To insert a delta delay, modify the code as follows:

process (rst, clk)

begin
if(rst = ’0’)then
s0 <= ’0’;
elsif(clk’event and clk=’1’) then
s0 <= inp;
end if;
end process;
s0_delayed <= s0;
process (rst, clk2)
begin
if(rst = ’0’)then
s1 <= ’0’;
elsif(clk2’event and clk2=’1’) then
s1 <= s0_delayed;
end if;
end process;

The best way to debug delta delay problems is to observe your signals in the Wave Window or
List Window (refer to the GUI Reference Manual for more information on these windows).
There you can see how values change at each delta time.

Detecting Infinite Zero-Delay Loops

If a large number of deltas occur without advancing time, it is usually a symptom of an infinite
zero-delay loop in the design. In order to detect the presence of these loops, ModelSim defines a
limit, the “iteration limit", on the number of successive deltas that can occur. When ModelSim
reaches the iteration limit, it stops the simulation and issues an error message.

The iteration limit default value is 10 million (10000000).

If you receive an iteration limit error, first increase the iteration limit and try to continue
simulation. and then try single stepping to attempt to determine which instances in the design
may be oscillating.

ModelSim® SE User's Manual, v10.7 207

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Delta Delays

You can set the iteration limit from the Simulate > Runtime Options menu or by modifying
the IterationLimit variable in the modelsim.ini. See modelsim.ini Variables for more
information on modifying the modelsim.ini file.

If the problem persists, look for zero-delay loops. Run the simulation and look at the source
code when the error occurs. Use the step button to step through the code and see which signals
or variables are continuously oscillating. Two common causes are a loop that has no exit, or a
series of gates with zero delay where the outputs are connected back to the inputs.

208 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
The TextIO Package

The TextIO Package

The TextIO package for VHDL is defined in the IEEE Std 1076-2002, IEEE Standard VHDL
Language Reference Manual. This package allows human-readable text input from a declared
source within a VHDL file during simulation.
To access the routines in TextIO, include the following statement in your VHDL source code:

USE std.textio.all;

A simple example using the package TextIO is:

USE std.textio.all;
ENTITY simple_textio IS
END;

ARCHITECTURE simple_behavior OF simple_textio IS

BEGIN
PROCESS
VARIABLE i: INTEGER:= 42;
VARIABLE LLL: LINE;
BEGIN
WRITE (LLL, i);
WRITELINE (OUTPUT, LLL);
WAIT;
END PROCESS;
END simple_behavior;

Syntax for File Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

STD_INPUT and STD_OUTPUT Within ModelSim. . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
TextIO Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Alternative Input/Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
The TEXTIO Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Input Stimulus to a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Syntax for File Declaration

The syntax supported for Text IO can vary according to the version of IEEE Std 1076 you are
using.
For IEEE Std 1076-1987, the supported syntax for a file declaration is the following:

file identifier : subtype_indication is [ mode ] file_logical_name ;

where "file_logical_name" must be a string expression.

For newer versions of IEEE Std 1076, supported syntax for a file declaration is the following:

file identifier_list : subtype_indication [ file_open_information ] ;

ModelSim® SE User's Manual, v10.7 209

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
STD_INPUT and STD_OUTPUT Within ModelSim

where "file_open_information" is:

[open file_open_kind_expression] is file_logical_name

You can specify a full or relative path as the file_logical_name. For example (VHDL 1987):

file filename : TEXT is in "/usr/rick/myfile";

Normally, when you declare a file in an architecture, process, or package, the file opens when
you start the simulator, and closes when you exit the simulation. When you declare a file in a
subprogram, the file opens when the subprogram is called and closes when execution
RETURNs from the subprogram.

Alternatively, you can delay the opening of files until the first read or write by setting the
DelayFileOpen variable in the modelsim.ini file. Also, you can control the number of
concurrently open files with the ConcurrentFileLimit variable. These variables help you
manage a large number of files during simulation. See modelsim.ini Variables for more details.

STD_INPUT and STD_OUTPUT Within ModelSim

STD_INPUT is a file_logical_name that refers to characters that you enter interactively from
the keyboard, and STD_OUTPUT refers to text that displays on the screen. The syntax
supported for STD_INPUT and STD_OUTPUT for Text IO can vary according to the version
of IEEE Std 1076 you are using.
In ModelSim, reading from the STD_INPUT file allows you to enter text into the current buffer
from a prompt in the Transcript pane. The lines written to the STD_OUTPUT file appear in the
Transcript.

For IEEE Std 1076-1987, TextIO package contains the following file declarations:

file input: TEXT is in "STD_INPUT";

file output: TEXT is out "STD_OUTPUT";

For newer versions of IEEE Std 1076, TextIO package contains these file declarations:

file input: TEXT open read_mode is "STD_INPUT";

file output: TEXT open write_mode is "STD_OUTPUT";

TextIO Implementation Issues

ModelSim does not fully implement all facets of the TextIO package, which can result in
ambiguous results.

210 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
TextIO Implementation Issues

WRITE Procedures for Strings and Aggregates

A common error in VHDL source code occurs when a call to a WRITE procedure does not
specify whether the argument is of type STRING or BIT_VECTOR. For example, the VHDL
procedure:

WRITE (L, "hello");

causes the following error:

ERROR: Subprogram "WRITE" is ambiguous.

In the TextIO package, the WRITE procedure is overloaded for the types STRING and
BIT_VECTOR. These lines are reproduced here:

procedure WRITE(L: inout LINE; VALUE: in BIT_VECTOR;

JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);

procedure WRITE(L: inout LINE; VALUE: in STRING;

JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);

The error occurs because the argument "hello" could be interpreted as a string or a bit vector,
but the compiler is not allowed to determine the argument type until it knows which function is
being called.

The following procedure call also generates an error:

WRITE (L, "010101");

This call is even more ambiguous, because the compiler cannot determine, even if allowed to,
whether the argument "010101" should be interpreted as a string or a bit vector.

There are two possible solutions to this problem:

• Use a qualified expression to specify the type, as in:

WRITE (L, string’("hello"));

• Call a procedure that is not overloaded, as in:

WRITE_STRING (L, "hello");

The WRITE_STRING procedure defines the value to be a STRING and calls the WRITE
procedure, and it also serves as a shell around the WRITE procedure that solves the overloading
problem. For further details, refer to the WRITE_STRING procedure in the io_utils package,
which is located in the file <install_dir>/modeltech/examples/vhdl/io_utils/io_utils.vhd.

ModelSim® SE User's Manual, v10.7 211

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
TextIO Implementation Issues

Reading and Writing Hexadecimal Numbers

The reading and writing of hexadecimal numbers is not specified in standard VHDL. The Issues
Screening and Analysis Committee of the VHDL Analysis and Standardization Group (ISAC-
VASG) has specified that the TextIO package reads and writes only decimal numbers.

To expand this functionality, ModelSim supplies hexadecimal routines in the io_utils package,
which is located in the file <install_dir>/modeltech/examples/gui/io_utils.vhd. To use these
routines, compile the io_utils package and then include the following use clauses in your VHDL
source code:

use std.textio.all;
use work.io_utils.all;

Dangling Pointers
Dangling pointers often occur when using the TextIO package, because WRITELINE de-
allocates the access type (pointer) that is passed to it. Following are examples of good and bad
VHDL coding styles:

Bad VHDL (because L1 and L2 both point to the same buffer):

READLINE (infile, L1); -- Read and allocate buffer

L2 := L1; -- Copy pointers
WRITELINE (outfile, L1); -- Deallocate buffer

Good VHDL (because L1 and L2 point to different buffers):

READLINE (infile, L1); -- Read and allocate buffer

L2 := new string’(L1.all); -- Copy contents
WRITELINE (outfile, L1); -- Deallocate buffer

The ENDLINE Function

The ENDLINE function — described in the IEEE Std 1076-2002, IEEE Standard VHDL
Language Reference Manual — contains invalid VHDL syntax and cannot be implemented in
VHDL. This is because access values must be passed as variables, but functions do not allow
variable parameters.

Based on an ISAC-VASG recommendation, the ENDLINE function has been removed from the
TextIO package. The following test can be substituted for this function:

(L = NULL) OR (L’LENGTH = 0)

The ENDFILE Function

In the VHDL Language Reference Manual, the ENDFILE function is listed as:

-- function ENDFILE (L: in TEXT) return BOOLEAN;

212 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Alternative Input/Output Files

Note the this function is commented out of the standard TextIO package. This is because the
ENDFILE function is implicitly declared, so you can use it with files of any type, not just files
of type TEXT.

Alternative Input/Output Files

To use the TextIO package to read and write to your own files, you declare an input or output
file of type TEXT.
The following examples show how to do this for an input file.

The VHDL1987 declaration is:

file myinput : TEXT is in "pathname.dat";

The VHDL1993 declaration is:

file myinput : TEXT open read_mode is "pathname.dat";

After making these declarations, you then include the identifier for this file ("myinput" in this
example) in the READLINE or WRITELINE procedure call.

The TEXTIO Buffer

Flushing of the TEXTIO buffer depends on whether VHDL files are open for writing.
You can turn the UnbufferedOutput variable in the modelsim.ini file on (1) or off (0, default) to
control the status.

Input Stimulus to a Design

You can provide an input stimulus to a design by reading data vectors from a file and assigning
their values to signals. You can then verify the results of this input.
The ModelSim installation includes a VHDL test bench as an example. Check for this file in
your installation directory:

<install_dir>/examples/gui/stimulus.vhd

ModelSim® SE User's Manual, v10.7 213

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
VITAL Usage and Compliance

VITAL Usage and Compliance

The VITAL (VHDL Initiative Towards ASIC Libraries) modeling specification is sponsored by
the IEEE to promote the development of highly accurate, efficient simulation models for ASIC
(Application-Specific Integrated Circuit) components in VHDL.
The IEEE Std 1076.4-2000, IEEE Standard for VITAL ASIC Modeling Specification is available
from the Institute of Electrical and Electronics Engineers, Inc.

http://www.ieee.org

VITAL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

VITAL 1995 and 2000 Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
VITAL Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Compiling and Simulating with Accelerated VITAL Packages . . . . . . . . . . . . . . . . . . . 216
Compiler Options for VITAL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

VITAL Source Code

The ModelSim installation includes the source code for VITAL packages.
The source code for VITAL packages is in the following directories:

/<install_dir>/vhdl_src/vital2.2b
/vital1995
/vital2000

VITAL 1995 and 2000 Packages

VITAL 2000 accelerated packages are pre-compiled into the ieee library in the installation
directory. VITAL 1995 accelerated packages are pre-compiled into the vital1995 library. If you
need to use the older library, you either need to change the ieee library mapping or add a use
clause to your VHDL code to access the VITAL 1995 packages.
To change the ieee library mapping, run the following vmap command:

vmap ieee <install_dir>/vital1995

Alternatively, you can add use clauses to your code:

LIBRARY vital1995;
USE vital1995.vital_primitives.all;
USE vital1995.vital_timing.all;
USE vital1995.vital_memory.all;

214 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
VITAL Compliance

Note that if your design uses two libraries—one that depends on vital95 and one that depends on
vital2000—then you will have to change the references in the source code to vital2000.
Changing the library mapping will not work.

ModelSim VITAL built-ins are generally updated as new releases of the VITAL packages
become available.

VITAL Compliance
ModelSim is compliant with IEEE Std 1076.4-2002, IEEE Standard for VITAL ASIC Modeling
Specification. In addition, ModelSim accelerates the VITAL_Timing, VITAL_Primitives, and
VITAL_memory packages. The optimized procedures are functionally equivalent to the IEEE
Std 1076.4 VITAL ASIC Modeling Specification (VITAL 1995 and 2000).

VITAL Compliance Checking

Compliance checking is important in enabling VITAL acceleration; to qualify for global
acceleration, an architecture must be VITAL-level-one compliant. The vcom command
automatically checks for VITAL 2000 compliance on all entities with the VITAL_Level0
attribute set, and all architectures with the VITAL_Level0 or the VITAL_Level1 attribute set.

If you are using VITAL 2.2b, you must turn off the compliance checking either by not setting
the attributes, or by invoking vcom with the argument -novitalcheck.

You can turn off compliance checking for VITAL 1995 and VITAL 2000 as well, but it is
strongly recommended that you leave checking on to ensure optimal simulation.

VITAL Compliance Warnings

The following LRM errors print as warnings (if they were considered errors they would prevent
VITAL level 1 acceleration); they do not affect how the architecture behaves.

• Starting index constraint to DataIn and PreviousDataIn parameters to VITALStateTable

do not match (1076.4 section 6.4.3.2.2)
• Size of PreviousDataIn parameter is larger than the size of the DataIn parameter to
VITALStateTable (1076.4 section 6.4.3.2.2)
• Signal q_w is read by the VITAL process but is not in the sensitivity list (1076.4 section
6.4.3)
The first two warnings are minor cases where the body of the VITAL 1995 LRM is slightly
stricter than the package portion of the LRM. Because either interpretation provides the same
simulation results, both cases are provided as warnings.

ModelSim® SE User's Manual, v10.7 215

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Compiling and Simulating with Accelerated VITAL Packages

The third warning is a relaxation of the restriction on reading an internal signal that is not in the
sensitivity list. This is relaxed only for the CheckEnabled parameters of the timing checks, and
only if they are not read elsewhere.

You can control the visibility of VITAL compliance-check warnings in your vcom transcript.
To suppress them, use the vcom -nowarn command. For example, vcom -nowarn 6, where the
number 6 represents the warning level to display as part of the warning: ** WARNING: [6].
You can also add the following line to your modelsim.ini file in the vcom section:

[vcom]
Show_VitalChecksWarnings = 0

See modelsim.ini Variables for more information.

Compiling and Simulating with Accelerated VITAL

Packages
When you run the vcom command, ModelSim automatically recognizes that a VITAL function
is being referenced from the ieee library and generates code to call the optimized built-in
routines.
Optimization occurs on two levels:

• VITAL Level-0 optimization — Performs function-by-function optimization. It applies

to all level-0 architectures and any level-1 architectures that failed level-1 optimization.
• VITAL Level-1 optimization — Performs global optimization on a VITAL 3.0 level-1
architecture that passes the VITAL compliance checker. This is the default behavior.
Note that your models will run faster, but at the cost of not being able to see the internal
workings of the models.
If you do not want to use the built-in VITAL routines (when debugging for instance), invoke
vcom with the -novital argument. The -novital switch affects calls to VITAL functions only
from the design units currently being compiled. Pre-compiled design units referenced from the
current design units will still call the built-in functions unless they too are compiled with the
-novital argument.

• To exclude all VITAL functions, use -novital all. For example:

vcom -novital all design.vhd

• To exclude selected VITAL functions, use one or more -novital <fname> arguments.
For example:
vcom -novital VitalTimingCheck -novital VitalAND design.vhd

216 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Compiler Options for VITAL Optimization

Compiler Options for VITAL Optimization

The vcom command has several arguments that control and provide feedback on VITAL
optimization.
• -novital
Causes vcom to use VHDL code for VITAL procedures, rather than the accelerated and
optimized timing and primitive packages. Allows breakpoints to be set in the VITAL
behavior process, and permits single stepping through the VITAL procedures to debug
your model. Also displays all of the VITAL data in the Locals or Objects pane.
• -O0 | -O4
Lowers the optimization to a minimum with -O0 (capital oh zero). Optional. Use this to
work around bugs, increase your debugging visibility on a specific cell, or when you
want to place breakpoints on source lines that have been optimized out.
Enable optimizations with -O4 (default).
• -debugVA
Prints a confirmation if a VITAL cell was optimized, or an explanation of why it was
not, during VITAL level-1 acceleration.

VHDL Utilities Package (util)

The util package contains various VHDL utilities that you can run as ModelSim commands.
The package is part of the modelsim_lib library, which is located in the /modeltech tree of your
installation directory and is mapped in the default modelsim.ini file.
To include the utilities in this package, add the following lines to your VHDL code:

library modelsim_lib;
use modelsim_lib.util.all;

get_resolution
The get_resolution utility returns the current simulator resolution as a real number. For
example, a resolution of 1 femtosecond (1 fs) corresponds to 1e-15.

Syntax
resval := get_resolution;

Arguments
None

ModelSim® SE User's Manual, v10.7 217

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
VHDL Utilities Package (util)

Return Values

Name Type Description

resval real The simulator resolution represented as a
real

Related functions
• to_real()
• to_time()

Examples
If the simulator resolution is set to 10ps, and you invoke the command:

resval := get_resolution;

the value returned to resval is 1e-11.

init_signal_driver()
The init_signal_driver() utility drives the value of a VHDL signal or Verilog net onto an
existing VHDL signal or Verilog net. This enables you to drive signals or nets at any level of the
design hierarchy from within a VHDL architecture (such as a test bench).

See init_signal_driver for complete details.

init_signal_spy()
The init_signal_spy() utility mirrors the value of a VHDL signal or Verilog register/net onto an
existing VHDL signal or Verilog register. This enables you to reference signals, registers, or
nets at any level of hierarchy from within a VHDL architecture (such as a test bench).

See init_signal_spy for complete details.

signal_force()
The signal_force() utility forces the value specified onto an existing VHDL signal or Verilog
register or net. This enables you to force signals, registers, or nets at any level of the design
hierarchy from within a VHDL architecture (such as a test bench). A signal_force works the
same as the force command when you set the modelsim.ini variable named ForceSigNextIter to
1. You can set the variable ForceSigNextIter in the modelsim.ini file to honor the signal update
event in next iteration for all force types. Note that the signal_force utility cannot issue a
repeating force.

See signal_force for complete details.

218 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
VHDL Utilities Package (util)

signal_release()
The signal_release() utility releases any force that was applied to an existing VHDL signal or
Verilog register or net. This enables you to release signals, registers, or nets at any level of the
design hierarchy from within a VHDL architecture (such as a test bench). A signal_release
works the same as the noforce command.

See signal_release for complete details.

to_real()
The to_real() utility converts the physical type time value into a real value with respect to the
current value of simulator resolution. The simulator resolution determines the precision of the
converted value.

For example, if you were converting 1900 fs to a real and the simulator resolution was ps, then
the real value would be rounded to 2.0 (that is, 2 ps).

Syntax
realval := to_real(timeval);

Returns

Name Type Description

realval real The time value represented as a real with
respect to the simulator resolution

Arguments

Name Type Description

timeval time The value of the physical type time

Related functions
• get_resolution
• to_time()

Examples
If the simulator resolution is set to ps, and you enter the following function:

realval := to_real(12.99 ns);

ModelSim® SE User's Manual, v10.7 219

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
VHDL Utilities Package (util)

then the value returned to realval would be 12990.0. If you wanted the returned value to be in
units of nanoseconds (ns) instead, you would use the get_resolution function to recalculate the
value:

realval := 1e+9 * (to_real(12.99 ns)) * get_resolution();

If you want the returned value to be in units of femtoseconds (fs), enter the function as follows:

realval := 1e+15 * (to_real(12.99 ns)) * get_resolution();

to_time()
The to_time() utility converts a real value into a time value with respect to the current simulator
resolution. The simulator resolution determines the precision of the converted value. For
example, if you convert 5.9 to a time and the simulator resolution is 1 ps, then the time value is
rounded to 6 ps.

Syntax
timeval := to_time(realval);

Returns

Name Type Description

timeval time The real value represented as a physical
type time with respect to the simulator
resolution

Arguments

Name Type Description

realval real The value of the type real

Related functions
• get_resolution
• to_real()

Examples
If the simulator resolution is set to 1 ps, and you enter the following function:

timeval := to_time(72.49);

then the value returned to timeval would be 72 ps.

220 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Modeling Memory

Modeling Memory
Modeling memory presents some challenges which careful plannning can address.
The challenges include the following common problems with simulation:

• Memory allocation errors, which typically mean the simulator ran out of memory and
failed to allocate enough storage.
• Very long times to load, elaborate, or run.
These problems usually result from the fact that signals consume a substantial amount of
memory (many dozens of bytes per bit), all of which must be loaded or initialized before your
simulation starts.

As an alternative, you can model a memory design using variables or protected types instead of
signals, which provides the following performance benefits:

• Reduced storage required to model the memory, by as much as one or two orders of
magnitude
• Reduced startup and run times
• Elimination of associated memory allocation errors
Examples of Different Memory Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Effects on Performance by Canceling Scheduled Events. . . . . . . . . . . . . . . . . . . . . . . . . 231

Examples of Different Memory Models

You should avoid using VHDL signals to model memory. For large memories especially, the
run time for a VHDL model using a signal is many times longer than the run time for a VHDL
model using variables in the memory process or as part of the architecture. A signal also uses
much more memory.
The first example in this section uses different VHDL architectures for the entity named
memory to provide the following models for storing RAM:

• bad_style_87 — uses a VHDL signal

• style_87 — uses variables in the memory process
• style_93 — uses variables in the architecture
To implement these models, you need functions that convert vectors to integers. To use them,
you may need to convert integers to vectors.

ModelSim® SE User's Manual, v10.7 221

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Examples of Different Memory Models

Converting an Integer Into a bit_vector

The following code shows how to convert an integer variable into a bit_vector.

library ieee;
use ieee.numeric_bit.ALL;

entity test is
end test;

architecture only of test is

signal s1 : bit_vector(7 downto 0);
signal int : integer := 45;
begin
p:process
begin
wait for 10 ns;
s1 <= bit_vector(to_signed(int,8));
end process p;
end only;

Examples Using VHDL1987, VHDL1993, and VHDL2002 Architectures

The VHDL code for the examples demonstrating the approaches to modeling memory is
provided below.

• Example 6-1 contains two VHDL architectures that demonstrate recommended memory
models: style_93 uses shared variables as part of a process, style_87 uses For
comparison, a third architecture, bad_style_87, shows the use of signals.
The style_87 and style_93 architectures work with equal efficiency for this example.
However, VHDL 1993 offers additional flexibility because the RAM storage can be
shared among multiple processes. This example shows a second process that initializes
the memory—you could add other processes to create a multi-ported memory.
• Example 6-2 is a package (named conversions) that is included by the memory model in
Example 6-1.
• Example 6-3 is provided for completeness—it shows protected types using VHDL 2002.
Note that using protected types offers no advantage over shared variables.
Example 6-1. Memory Model Using VHDL87 and VHDL93 Architectures

Example functions are provided below in package “conversions.”

222 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Examples of Different Memory Models

-------------------------------------------------------------------------
-- Source: memory.vhd
-- Component: VHDL synchronous, single-port RAM
-- Remarks: Provides three different architectures
------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use work.conversions.all;

entity memory is
generic(add_bits : integer := 12;
data_bits : integer := 32);
port(add_in : in std_ulogic_vector(add_bits-1 downto 0);
data_in : in std_ulogic_vector(data_bits-1 downto 0);
data_out : out std_ulogic_vector(data_bits-1 downto 0);
cs, mwrite : in std_ulogic;
do_init : in std_ulogic);
subtype word is std_ulogic_vector(data_bits-1 downto 0);
constant nwords : integer := 2 ** add_bits;
type ram_type is array(0 to nwords-1) of word;
end;

architecture style_93 of memory is

------------------------------
shared variable ram : ram_type;
------------------------------
begin
memory:
process (cs)
variable address : natural;
begin
if rising_edge(cs) then
address := sulv_to_natural(add_in);
if (mwrite = '1') then
ram(address) := data_in;
end if;
data_out <= ram(address);
end if;
end process memory;
-- illustrates a second process using the shared variable
initialize:
process (do_init)
variable address : natural;
begin
if rising_edge(do_init) then
for address in 0 to nwords-1 loop
ram(address) := data_in;
end loop;
end if;
end process initialize;
end architecture style_93;
architecture style_87 of memory is
begin
memory:
process (cs)
-----------------------
variable ram : ram_type;
-----------------------

ModelSim® SE User's Manual, v10.7 223

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Examples of Different Memory Models

variable address : natural;

begin
if rising_edge(cs) then
address := sulv_to_natural(add_in);
if (mwrite = '1') then
ram(address) := data_in;
end if;
data_out <= ram(address);
end if;
end process;
end style_87;
architecture bad_style_87 of memory is
----------------------
signal ram : ram_type;
----------------------
begin
memory:
process (cs)
variable address : natural := 0;
begin
if rising_edge(cs) then
address := sulv_to_natural(add_in);
if (mwrite = '1') then
ram(address) <= data_in;
data_out <= data_in;
else
data_out <= ram(address);
end if;
end if;
end process;
end bad_style_87;

224 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Examples of Different Memory Models

Example 6-2. Conversions Package

library ieee;
use ieee.std_logic_1164.all;

package conversions is
function sulv_to_natural(x : std_ulogic_vector) return
natural;
function natural_to_sulv(n, bits : natural) return
std_ulogic_vector;
end conversions;

package body conversions is

function sulv_to_natural(x : std_ulogic_vector) return

natural is
variable n : natural := 0;
variable failure : boolean := false;
begin
assert (x'high - x'low + 1) <= 31
report "Range of sulv_to_natural argument exceeds
natural range"
severity error;
for i in x'range loop
n := n * 2;
case x(i) is
when '1' | 'H' => n := n + 1;
when '0' | 'L' => null;
when others => failure := true;
end case;
end loop;

assert not failure

report "sulv_to_natural cannot convert indefinite
std_ulogic_vector"
severity error;

if failure then
return 0;
else
return n;
end if;
end sulv_to_natural;

function natural_to_sulv(n, bits : natural) return

std_ulogic_vector is
variable x : std_ulogic_vector(bits-1 downto 0) :=
(others => '0');
variable tempn : natural := n;
begin
for i in x'reverse_range loop
if (tempn mod 2) = 1 then
x(i) := '1';
end if;
tempn := tempn / 2;
end loop;
return x;

ModelSim® SE User's Manual, v10.7 225

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Examples of Different Memory Models

end natural_to_sulv;

end conversions;

226 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Examples of Different Memory Models

Example 6-3. Memory Model Using VHDL02 Architecture

-------------------------------------------------------------------------
-- Source: sp_syn_ram_protected.vhd
-- Component: VHDL synchronous, single-port RAM
-- Remarks: Various VHDL examples: random access memory (RAM)
-------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY sp_syn_ram_protected IS
GENERIC (
data_width : positive := 8;
addr_width : positive := 3
);
PORT (
inclk : IN std_logic;
outclk : IN std_logic;
we : IN std_logic;
addr : IN unsigned(addr_width-1 DOWNTO 0);
data_in : IN std_logic_vector(data_width-1 DOWNTO 0);
data_out : OUT std_logic_vector(data_width-1 DOWNTO 0)
);

END sp_syn_ram_protected;

ARCHITECTURE intarch OF sp_syn_ram_protected IS

TYPE mem_type IS PROTECTED

PROCEDURE write ( data : IN std_logic_vector(data_width-1 downto 0);
addr : IN unsigned(addr_width-1 DOWNTO 0));
IMPURE FUNCTION read ( addr : IN unsigned(addr_width-1 DOWNTO 0))
RETURN
std_logic_vector;
END PROTECTED mem_type;

TYPE mem_type IS PROTECTED BODY

TYPE mem_array IS ARRAY (0 TO 2**addr_width-1) OF
std_logic_vector(data_width-1 DOWNTO 0);
VARIABLE mem : mem_array;

PROCEDURE write ( data : IN std_logic_vector(data_width-1 downto 0);

addr : IN unsigned(addr_width-1 DOWNTO 0)) IS
BEGIN
mem(to_integer(addr)) := data;
END;

IMPURE FUNCTION read ( addr : IN unsigned(addr_width-1 DOWNTO 0))

RETURN
std_logic_vector IS
BEGIN
return mem(to_integer(addr));
END;

END PROTECTED BODY mem_type;

ModelSim® SE User's Manual, v10.7 227

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Examples of Different Memory Models

SHARED VARIABLE memory : mem_type;

BEGIN

ASSERT data_width <= 32

REPORT "### Illegal data width detected"
SEVERITY failure;

control_proc : PROCESS (inclk, outclk)

BEGIN
IF (inclk'event AND inclk = '1') THEN
IF (we = '1') THEN
memory.write(data_in, addr);
END IF;
END IF;

IF (outclk'event AND outclk = '1') THEN

data_out <= memory.read(addr);
END IF;
END PROCESS;

END intarch;

-------------------------------------------------------------------------
-- Source: ram_tb.vhd
-- Component: VHDL test bench for RAM memory example
-- Remarks: Simple VHDL example: random access memory (RAM)
-------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY ram_tb IS
END ram_tb;

ARCHITECTURE testbench OF ram_tb IS

-------------------------------------------
-- Component declaration single-port RAM
-------------------------------------------
COMPONENT sp_syn_ram_protected
GENERIC (
data_width : positive := 8;
addr_width : positive := 3
);
PORT (
inclk : IN std_logic;
outclk : IN std_logic;
we : IN std_logic;
addr : IN unsigned(addr_width-1 DOWNTO 0);
data_in : IN std_logic_vector(data_width-1 DOWNTO 0);
data_out : OUT std_logic_vector(data_width-1 DOWNTO 0)
);
END COMPONENT;

-------------------------------------------

228 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Examples of Different Memory Models

-- Intermediate signals and constants

-------------------------------------------
SIGNAL addr : unsigned(19 DOWNTO 0);
SIGNAL inaddr : unsigned(3 DOWNTO 0);
SIGNAL outaddr : unsigned(3 DOWNTO 0);
SIGNAL data_in : unsigned(31 DOWNTO 0);
SIGNAL data_in1 : std_logic_vector(7 DOWNTO 0);
SIGNAL data_sp1 : std_logic_vector(7 DOWNTO 0);
SIGNAL we : std_logic;
SIGNAL clk : std_logic;
CONSTANT clk_pd : time := 100 ns;

BEGIN

---------------------------------------------------
-- instantiations of single-port RAM architectures.
-- All architectures behave equivalently, but they
-- have different implementations. The signal-based
-- architecture (rtl) is not a recommended style.
---------------------------------------------------
spram1 : entity work.sp_syn_ram_protected
GENERIC MAP (
data_width => 8,
addr_width => 12)
PORT MAP (
inclk => clk,
outclk => clk,
we => we,
addr => addr(11 downto 0),
data_in => data_in1,
data_out => data_sp1);

-------------------------------------------
-- clock generator
-------------------------------------------
clock_driver : PROCESS
BEGIN
clk <= '0';
WAIT FOR clk_pd / 2;
LOOP
clk <= '1', '0' AFTER clk_pd / 2;
WAIT FOR clk_pd;
END LOOP;
END PROCESS;

-------------------------------------------
-- data-in process
-------------------------------------------
datain_drivers : PROCESS(data_in)
BEGIN
data_in1 <= std_logic_vector(data_in(7 downto 0));
END PROCESS;

-------------------------------------------
-- simulation control process
-------------------------------------------
ctrl_sim : PROCESS

ModelSim® SE User's Manual, v10.7 229

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Examples of Different Memory Models

BEGIN
FOR i IN 0 TO 1023 LOOP
we <= '1';
data_in <= to_unsigned(9000 + i, data_in'length);
addr <= to_unsigned(i, addr'length);
inaddr <= to_unsigned(i, inaddr'length);
outaddr <= to_unsigned(i, outaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

data_in <= to_unsigned(7 + i, data_in'length);

addr <= to_unsigned(1 + i, addr'length);
inaddr <= to_unsigned(1 + i, inaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

data_in <= to_unsigned(3, data_in'length);

addr <= to_unsigned(2 + i, addr'length);
inaddr <= to_unsigned(2 + i, inaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

data_in <= to_unsigned(30330, data_in'length);

addr <= to_unsigned(3 + i, addr'length);
inaddr <= to_unsigned(3 + i, inaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

we <= '0';
addr <= to_unsigned(i, addr'length);
outaddr <= to_unsigned(i, outaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

addr <= to_unsigned(1 + i, addr'length);

outaddr <= to_unsigned(1 + i, outaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

addr <= to_unsigned(2 + i, addr'length);

outaddr <= to_unsigned(2 + i, outaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

addr <= to_unsigned(3 + i, addr'length);

outaddr <= to_unsigned(3 + i, outaddr'length);
WAIT UNTIL clk'EVENT AND clk = '0';
WAIT UNTIL clk'EVENT AND clk = '0';

END LOOP;
ASSERT false
REPORT "### End of Simulation!"
SEVERITY failure;
END PROCESS;

END testbench;

230 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Effects on Performance by Canceling Scheduled Events

Effects on Performance by Canceling Scheduled

Events
Simulation performance typically suffers if events are scheduled far into the future but then
canceled before they take effect. Canceling scheduled events before they take effect acts as a
memory leak and slows down simulation.
In VHDL, cancellation of scheduled events can occur in several ways. The most common ways
are waits with time-out clauses and projected waveforms in signal assignments.

The following shows a wait with a time-out:

signal synch : bit := '0';

...
p: process
begin
wait for 10 ms until synch = 1;
end process;

synch <= not synch after 10 ns;

At time 0, process p makes an event for time 10ms. When synch goes to 1 at 10 ns, the event at
10 ms is marked as canceled but not deleted, and a new event is scheduled at 10ms + 10ns. The
canceled events are not reclaimed until time 10ms is reached and the canceled event is
processed. As a result, there are 500000 (10ms/20ns) canceled but undeleted events. Once 10ms
is reached, memory no longer increases because the simulator is reclaiming events as fast as
they are added.

For projected waveforms, the following would behave the same way:

signals synch : bit := '0';

...
p: process(synch)
begin
output <= '0', '1' after 10ms;
end process;

synch <= not synch after 10 ns;

ModelSim® SE User's Manual, v10.7 231

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
VHDL Access Object Debugging

VHDL Access Object Debugging

VHDL does not have an objected-oriented modeling capability, but VHDL variables of access
type enable you to use ModelSim to log and display dynamic simulation data. You enable this
logging by specifying vsim -accessobjdebug.
When logging a VHDL variable of an access type, ModelSim also automatically logs any
designated objects that the variable value points to as the simulation progresses. By default,
these objects are unnamed, in accordance with the VHDL LRM (IEEE Std-1076). When you
enable logging, each object is given a unique generated name that you can manipulate as a
design pathname, but the name is not rooted at any particular place in the design hierarchy.
Various windows in the GUI (such as the Wave window, Objects window, Locals window,
Watch window, and Memory window) can display both the access variable and any logged
designated objects.

Tip
You can use the examine and the describe commands in the normal manner for variables
and objects displayed in a ModelSim window.

In general, the automatically logged designated objects have a limited lifespan, which
corresponds to the VHDL allocator "new." This allocator creates a designated object at a
particular time, and the deallocate() procedure destroys the designated object at a particular
time, as the simulation runs. Each designated object receives its unique name when the new
allocation occurs; the name is unique over the life of the simulation.

Terminology and Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

VHDL Access Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Default Behavior—Logging and Debugging Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Logging and Debugging Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
The examine and describe Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Terminology and Naming Conventions

Using VHDL access type variables for logging dynamic data entails various names and
descriptors.
• access variable — A VHDL variable declared to be of an access type. An access
variable can be either shared or not shared.
NOTE: The VHDL LRM defines “access value” to mean the value of such a variable.
This value can be either NULL, or it can denote (point to) some unnamed object, which
is the "designated object" and is referred to as an “access object.” That is, when an
access variable has a value that is not NULL, then it points to an access object.

232 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
VHDL Access Type

• access object — The term "access object" means the designated object of an access
variable. An access object is created with the VHDL allocator “new,” which returns the
access value. This value is then assigned to an access variable, either in an assignment
statement or an association element in a subprogram call.
• AIID — The access instance identifier. Each access object gets a unique identifier, its
access instance identifier, which is named in the manner of the class instance identifier
(CIID) for SystemVerilog (which is also known as a handle—refer to SystemVerilog
Class Debugging).
• DOID — dynamic object identifier. The name of a VHDL access object. The terms
DOID and AIID are interchangeable. Access object names have two different forms,
depending on whether or not the vsim-accessobjdebug command is in effect. Refer to
Default Behavior—Logging and Debugging Disabled and Logging and Debugging
Enabled.
• deep logging — If an access variable is logged, then the DOID of any access object that
it points to during the simulation is also logged automatically. Any embedded access
type subelements of an access type are also logged automatically. Similarly, logging an
access object by name (its access instance identifier) logs not only the access object
itself, but any embedded access objects (if the outer access object is of a composite type
that contains a subelement of an access type).
• prelogging — The logging of an access object by name, even if you have not declared it
(that is, it does not yet exist at the time an "add log" command is issued, but you can still
log it by name). This produces useful results only if you use a DOID (dynamic object
identifier) that matches the name of an access object that will exist at some future
simulation time.

VHDL Access Type

Once you declare an access type, you can declare an access variable within a process or
subprogram. When creating dynamic data in VHDL, the usual strict rules apply to assignment
of newly constructed objects to an access type.
For instance, there is no implicit casting, and no such thing as an access that can point to
anything (such as a void * in C).

For example, you can use any VHDL subtype "foo" to declare an access type that is a pointer to
objects of type foo. (This can be a fully constrained type, but it is also legal to point to an
unconstrained or partially constrained type.) Subtype foo is called the designated subtype, and
the base type of the designated subtype is called the designated type. The designated type of an
access type cannot be a file type or a protected type. Note that composite types cannot contain
elements that are of file types or protected types, so if the designated type of an access type is a
composite type, it will not have any file type or protected type sub-elements.

ModelSim® SE User's Manual, v10.7 233

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Limitations

Lifespan of an Access Object

You construct a dynamic access object in VHDL with a "new" operator and destroy it with a
“de-allocate” procedure. Dynamic access objects are referenced only through pointers declared
by the HDL author. An access object can be assigned a value of NULL, the value of another
compatible access type object, or the result of the new operator that constructs a compatible
object. The only way to track an access object is during this lifespan; before and after the
lifespan, only the access variable is available.

Restrictions and Requirements

• Beginning with VHDL 2002, shared variables technically must be of a protected type
and cannot be of an access type, but ModelSim does not enforce this restriction,
allowing access variables to be shared variables. This presents a different set of
implementation considerations, because shared variables are context tree items, while
non-shared variables (local PROCESS statement variables, local subprogram variables,
and class VARIABLE subprogram formals, in general) are debug section objects and
not context tree items.
• You cannot point to an elaborated object of the same type as a dynamic object—access
types point only to objects constructed by new. (There is no address_of operator. )
• According to the formal definition, dynamic objects have no simple name. That means
logging and debugging requires the generation of an internal, authoritative name for the
table of contents of any logging database.
• You can declare only VHDL variables (ordinary or shared) as access types, not signals
or constants. This access variable has a value of either the literal NULL (which means
there is no designated object), or an AIID, which is a pointer to the designated object
(called the access object). An access variable is of an access type, and an access object is
of the designated type of that access type (not of an access type itself in general). Note
that an access variable, when it is not NULL, always points to an access object.
Conversely, an access object, when pointed to, is pointed to by an access variable.
However, an access object does not have to be pointed to by an access variable, except
when it is originally created with "new". That is, while it is not a good idea to "orphan"
an access object, it is possible. A simulator can deallocate such an orphaned access
object by using some garbage collection method, but is not required to do so. ModelSim
does not deallocate orphaned access objects.

Limitations
Access object debugging has some limitations.
It is not possible to log a variable (access variable or not) that is declared in the declarative
region of a FUNCTION or PROCEDURE. This is not really a limitation of access object debug,
but it is a general limitation. Only shared variables and variables declared in a PROCESS
declarative region can be logged (whether access variables or not).

234 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Default Behavior—Logging and Debugging Disabled

The List window can display the value of an access variable, but cannot display the
corresponding access objects.

Access objects, which are of type STD.STANDARD.STRING, are not logged if variables of
type STD.TEXTIO.LINE are logged. Thus, "deep logging" of variables of type LINE does not
occur.

Optimized designs (those created with the vopt command in either the 2-step or 3-step flow)
may contain access variables with reduced or eliminated visibility. This affects the ability to log
variables in optimized designs. The recommended approach is to retain complete visibility of an
access variable of interest by judicious use of the vopt accessibility arguments. Otherwise,
attempting to log a diminished-visibility access variable produces a Warning message stating
that the variable cannot be logged.

Default Behavior—Logging and Debugging

Disabled
By default, logging access objects by name is turned off. Access variables can be logged and
displayed in the various display windows, but the access object(s) they point to are not logged.
You can display the value of an access variable (the "name" of the access object it points to) but
commands cannot use the value to reference the access variable.
Tip
Default behavior is applied by either of the following methods:

• In modelsim.ini ([vsim] section), set AccessObjDebug = 0

• Run vsim -noaccessobjdebug (overrides AccessObjDebug variable).

You can use and update the value of the access object by using the VHDL keyword “all” as a
suffix to the access variable name.

Examples
• Declare an access variable “v1” that designates some access object. The value of v1
displays as [10001]. This name is for display only—it cannot be used as input to any
command that expects an object name. However, it is a unique identifier for any access
object that the design may produce. Note that this value replaces any hexadecimal
address-based value displayed in previous versions of ModelSim.
• Use variable v1 with the VHDL keyword “all” as an argument to the examine command,
which returns the current value of the access object. This essentially dereferences the
object.
examine v1.all

ModelSim® SE User's Manual, v10.7 235

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Logging and Debugging Enabled

Logging and Debugging Enabled

Logging an access variable logs both the variable value and any access object that the variable
points to during the simulation.
Tip
You can use either of the following methods to apply access object logging and debugging
behavior:

• In modelsim.ini, set AccessObjDebug = 1.

• Run vsim -accessobjdebug (overrides AccessObjDebug variable).

When logging is enabled for a VHDL access variable, display-only names (such as [10001])
take on a different form that includes:

• the initial character, @

• the name of the access type or subtype
• another @
• a unique integer N that represents the sequence number (starting with 1) of the objects of
that designated type that were created with the VHDL allocator called new.

Displaying Objects in ModelSim Windows

When an access variable displays in the Wave window, the wave trace is not expandable (there
is no "+" next to the variable name). When the access variable points to an access object, such
that a DOID (such as @ptr@1) appears in the values column of the Wave window, you can then
right-click to add the access object under the cursor pointer. This allows adding composite type
access objects to the Wave window.

Tip
An alternative method would be to use the add wave command with the DOID of the access
object. For example:

add wave @ptr@1

Example
Logged access variables take the following form:

@ptr@1

Related Topics
Waveform Analysis

236 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
The examine and describe Commands

Wave Window

The examine and describe Commands

You can use the examine and describe commands to obtain a description of a variable’s
characteristics.
Use the examine command with a declared access variable to obtain a display of the current
value of its access object. The returned value depends on whether access logging is enabled, or
disabled.

• Disabled — The returned value of the access object is its display-only DOID (as per
Default Behavior—Logging and Debugging Disabled).
• Enabled — The returned value of the access object is the logged name that you assigned
(as per Logging and Debugging Enabled).

Tip
You can also use the describe command with an access variable (for example, describe
v1.all). The describe command returns a more qualitative description of the variable’s
characteristics.

You can use the examine command to obtain a variety of access object values, depending on the
data type of the access object. In particular, this command returns object values for the
following VHDL data types:

• Integer
• String
• Record
The examples in the following tables show how to use access variables of these three types to
specify arguments to the examine command, with access object logging disabled and enabled.
Each example uses an access variable named v1, declared as one of the data types, and an access
object named @ptr@1.

Integer
Table 6-1 shows examples of how to use v1 and @ptr@1 as arguments to the examine
command to obtain the current value of the access object, @ptr@1, which is an integer. In the
examples, the current integer value is 5. Note that an error results when attempting to use
@ptr@1 as an examine argument with access object logging disabled.

ModelSim® SE User's Manual, v10.7 237

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
The examine and describe Commands

Table 6-1. Using the examine Command to Obtain VHDL Integer Data
Command Value Returned with Value Returned with
Logging Disabled Logging Enabled
(vsim -noaccessobjdebug) (vsim -accessobjdebug)
examine v1 [10001] @ptr@1
examine v1.all 5 5
examine @ptr@1 error 5

String
Table 6-2 shows examples of how to use v1 and @ptr@1 as arguments to the examine
command to obtain the current value of the access object, @ptr@1, which is a string. In the
examples, the value of the entire string is abcdef. Note that specifying an index of 4 in the string
obtains the fourth character of the string, d. Also, note that an error results when attempting to
use @ptr@1 as an examine argument with access object logging disabled
Table 6-2. Using the examine Command to Obtain VHDL String Data
Command Value Returned with Value Returned with
Logging Disabled Logging Enabled
(vsim -noaccessobjdebug) (vsim -accessobjdebug)
examine v1 [10001] @ptr@1
examine v1.all "abcdef" "abcdef"
examine v1(4) ‘d’ ‘d’
examine v1.all(4) ‘d’ ‘d’
examine @ptr@1 error "abcdef"
examine @ptr@1(4) error ‘d’

Record
A VHDL record is composite data type, consisting of multiple fields (also referred to as
elements) each of which contains its own separate data. Record fields may be of the same or of
different types.

Table 6-3 shows examples of using the examine command on a record object with an integer
field (f1) and a string field (f2). In the examples, the current value of integer field f1 is 5, and the
current value of string field f2 is abcdef. Note that an error results when attempting to use
@ptr@1 as an examine argument with access object logging disabled.

238 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
The examine and describe Commands

Table 6-3. Using the examine Command to Obtain VHDL Record Data
Command Value Returned with Value Returned with
Logging Disabled Logging Enabled
(vsim -noaccessobjdebug) (vsim -accessobjdebug)
examine v1 [10001] @ptr@1
examine v1.all {5, "abcdef"} {5, "abcdef"}
examine v1.f1 5 5
examine v1.all.f1 5 5
examine @ptr@1.f1 error 5

Related Topics
describe
examine

ModelSim® SE User's Manual, v10.7 239

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
The examine and describe Commands

240 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 7
Verilog and SystemVerilog Simulation

This chapter describes how to compile and simulate Verilog and SystemVerilog designs with
ModelSim.
Standards, Nomenclature, and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Basic Verilog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Verilog Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Cell Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
SystemVerilog System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Sparse Memory Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Unmatched Virtual Interface Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Verilog PLI and SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
SystemVerilog Class Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

ModelSim® SE User's Manual, v10.7 241

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Standards, Nomenclature, and Conventions

Standards, Nomenclature, and Conventions

SystemVerilog is built “on top of” IEEE Std 1364 for the Verilog HDL and improves the
productivity, readability, and re-usability of Verilog-based code. The language enhancements in
SystemVerilog provide more concise hardware descriptions, while still providing an easy route
with existing design and verification products into current hardware implementation flows.
The enhancements also provide extensive support for directed and constrained random
testbench development, coverage-driven verification, and assertion-based verification.

ModelSim implements the Verilog and SystemVerilog languages as defined by the following
standards:

• IEEE 1364-2005 and 1364-1995 (Verilog)

• IEEE 1800-2012, 1800-2009 and 1800-2005 (SystemVerilog)

Note
ModelSim supports partial implementation of SystemVerilog IEEE Std 1800-2012.
For release-specific information on currently supported implementation, refer to the
following text file located in the ModelSim installation directory: <install_dir>/docs/
technotes/sysvlog.note

The standard for SystemVerilog specifies extensions for a higher level of abstraction for
modeling and verification with the Verilog hardware description language (HDL).

This standard includes design specification methods, embedded assertions language, testbench
language including coverage and assertions application programming interface (API), and a
direct programming interface (DPI).

In this chapter, the following terms apply:

• “Verilog” refers to IEEE Std 1364 for the Verilog HDL.

• “Verilog-1995” refers to IEEE Std 1364-1995 for the Verilog HDL.
• “Verilog-2001” refers to IEEE Std 1364-2001 for the Verilog HDL.
• “Verilog-2005” refers to IEEE Std 1364-2005 for the Verilog HDL.
• “SystemVerilog” refers to the extensions to the Verilog standard (IEEE Std 1364) as
defined in IEEE Std 1800-2012.

Note
The term “Language Reference Manual” (or LRM) is often used informally to refer
to the current IEEE standard for Verilog or SystemVerilog.

Supported Variations in Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

242 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Supported Variations in Source Code

for Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Naming Macros with Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Supported Variations in Source Code

It is possible to use syntax variations of constructs that are not explicitly defined as being
supported in the Verilog LRM (such as “shortcuts” supported for similar constructs in another
language).

for Loops
ModelSim allows using Verilog syntax that omits any or all three specifications of a for loop —
initialization, termination, increment. This is similar to allowed usage in C and is shown in the
following examples.
Note
If you use this variation, a suppressible warning (2252) is displayed, which you can change
to an error if you use the vlog -pedanticerrors command.

• Missing initializer (in order to continue where you left off):

for (; incr < foo; incr++) begin ... end

• Missing incrementer (in order to increment in the loop body):

for (ii = 0; ii <= foo; ) begin ... end

• Missing initializer and terminator (in order to implement a while loop):

for (; goo < foo; ) begin ... end

• Missing all specifications (in order to create an infinite loop):

for (;;) begin ... end

Naming Macros with Integers

The vlog command will compile macros named with integers in addition to identifiers.

ModelSim® SE User's Manual, v10.7 243

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Naming Macros with Integers

For example:

`define 11 22
`define q(s) `" s `"
module defineIdent;
string s2 = `q( `11 );
int i = `11;
initial begin
$display("i: %d\n", i);
#10;
$display("s2: %s\n", s2);
end
endmodule

Also, the following compiler directives accept integer names as well as IEEE-1800 Language
Reference Manual macro names:

‘define
‘else
‘elsif
‘endif
‘fdef
‘undefine

You can disable this functionality with vlog -pedanticerrors.

244 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Basic Verilog Usage

Basic Verilog Usage

Basic Verilog usage consists of a few simple steps that include compiling, optimizing, loading,
and simulating.
The Verilog usage flow generally consists of the following steps:

1. Compile your Verilog code into one or more libraries using the vlog command. See
Verilog Compilation for details.
2. (Optional) Elaborate and optimize your design using the vopt command. For more
information, refer to Chapter 3, Optimizing Designs with vopt and Optimization
Considerations for Verilog Designs.
3. Load your design with the vsim command. Refer to Verilog Simulation.
4. Simulate the loaded design and debug as needed.
Verilog Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Initializing enum Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Library Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
SystemVerilog Multi-File Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Verilog-XL Compatible Compiler Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Verilog Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Verilog Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Initializing Registers and Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

ModelSim® SE User's Manual, v10.7 245

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog Compilation

Verilog Compilation
Compiling your Verilog design for the first time is a two-step process.
1. Create a working library with the vlib command, or select File > New > Library.
2. Compile the design using the vlog command, or select Compile > Compile.
Alternatively, if you have previously been using NCSim, ModelSim provides an alternative
flow that combines the compile, optimize, and simulate phases into one command. Refer to the
qverilog command for more information.

Creating a Working Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Invoking the Verilog Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Verilog Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Parsing SystemVerilog Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Recognizing SystemVerilog Files by File Name Extension . . . . . . . . . . . . . . . . . . . . . . . 248

Creating a Working Library

Before you can compile your design, you must create a library in which to store the compilation
results.
Procedure
Use the vlib command or select File > New > Library to create a new library.

For example, the command vlib work creates a library named work. By default
compilation results are stored in the work library.
The work library is actually a subdirectory named work. This subdirectory contains a
special file named _info. Do not create libraries using UNIX commands – always use the
vlib command.
See Design Libraries for additional information on working with libraries.

Invoking the Verilog Compiler

The Verilog compiler compiles Verilog source code into retargetable, executable code. You can
then simulate your design on any supported platform without having to recompile your design;
the library format is also compatible across all platforms.
Prerequisites
Create a working library.

246 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog Compilation

Procedure
Use the vlog command or the Compile > Compile menu selection to invoke the Verilog
compiler.

As the design compiles, the resulting object code for modules and user-defined
primitives (UDPs) is generated into a library. As noted above, the compiler places
results into the work library by default. You can specify an alternate library with the -
work argument of the vlog command.
The following example shows how to use the vlog command to invoke the Verilog
compiler:
vlog top.v +libext+.v+.u -y vlog_lib

After compiling top.v, vlog searches the vlog_lib library for files with modules with the
same name as primitives referenced, but undefined in top.v. The use of +libext+.v+.u
implies filenames with a .v or .u suffix (any combination of suffixes may be used). Only
referenced definitions are compiled. Compressed SystemVerilog source files (.gz
extension, compressed with zlib) are accepted.

Verilog Case Sensitivity

Note that Verilog and SystemVerilog are case-sensitive languages. For example, clk and CLK
are regarded as different names that you can apply to different signals or variables. This differs
from VHDL, which is case-insensitive.

Parsing SystemVerilog Keywords

With standard Verilog files (<filename>.v), vlog does not automatically parse SystemVerilog
keywords.
SystemVerilog keywords are parsed when either of the following situations exists:

• Any file within the design contains the .sv file extension
• You use the -sv argument with the vlog command
The following examples of the vlog command show how to enable SystemVerilog features and
keywords in ModelSim:

vlog testbench.sv top.v memory.v cache.v

vlog -sv testbench.v proc.v

In the first example, the .sv extension for testbench automatically causes ModelSim to parse
SystemVerilog keywords. In the second example, the -sv argument enables SystemVerilog
features and keywords.

ModelSim® SE User's Manual, v10.7 247

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog Compilation

Keyword Compatibility
One of the primary goals of SystemVerilog standardization has been to ensure full backward
compatibility with the Verilog standard. Questa recognizes all reserved keywords listed in
Table B-1 in Annex B of IEEE Std 1800-2012.

The following reserved keywords have been added since IEEE Std 1800-2009:
implements interconnect nettype
soft

If you use or produce SystemVerilog code that uses any identifiers from a previous release in
which they were not considered reserved keywords, you can do either of the following to avoid
a compilation error:

• Use a different set of strings in your design. You can add one or more characters as a
prefix or suffix (such as an underscore, _) to the string, which will cause the string to be
read in as an identifier and not as a reserved keyword.
• Use the SystemVerilog pragmas `begin_keywords and `end_keywords to define regions
where only the older keywords are recognized.

Recognizing SystemVerilog Files by File Name Extension

If you use the -sv argument with the vlog command, then ModelSim assumes that all input files
are SystemVerilog, regardless of their respective filename extensions.
If you do not use the -sv argument with the vlog command, then ModelSim assumes that only
files with the extension .sv, .svh, or .svp are SystemVerilog.

File extensions of include files

Similarly, if you do not use the -sv argument while reading in a file that uses an `include
statement to specify an include file, then the file extension of the include file is ignored and the
language is assumed to be the same as the file containing the `include. For example, if you do
not use the -sv argument:

If a.v included b.sv, then b.sv would be read as a Verilog file. If c.sv included d.v, then d.v
would be read as a SystemVerilog file.

File extension settings in modelsim.ini

You can define which file extensions indicate SystemVerilog files with the SVFileExtensions
variable in the modelsim.ini file. By default, this variable is defined in modelsim.ini as follows:

; SVFileExtensions = sv svp svh

248 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Initializing enum Variables

For example, the following command:

vlog a.v b.sv c.svh d.v

reads in a.v and d.v as a Verilog files and reads in b.sv and c.svh as SystemVerilog files.

File types affecting compilation units

Note that whether a file is Verilog or SystemVerilog can affect when ModelSim changes from
one compilation unit to another.

By default, ModelSim instructs the compiler to treat all files within a compilation command line
as separate compilation units (single-file compilation unit mode, which is the equivalent of
using vlog -sfcu).

vlog a.v aa.v b.sv c.svh d.v

ModelSim would group these source files into three compilation units:

• Files in first unit — a.v, aa.v, b.sv

• File in second unit — c.svh
• File in third unit — d.v
This behavior is governed by two basic rules:

• Anything read in is added to the current compilation unit.

• A compilation unit ends at the close of a SystemVerilog file.

Initializing enum Variables

By default, ModelSim initializes enum variables using the default value of the base type instead
of the leftmost value.
However, you can change this so that ModelSim sets the initial value of an enum variable to the
left most value in the following ways:

• Run vlog -enumfirstinit when compiling and run vsim -enumfirstinit when simulating.
• Set EnumBaseInit = 0 in the modelsim.ini file.

Incremental Compilation
ModelSim supports incremental compilation of Verilog designs—there is no requirement to
compile an entire design in one invocation of the compiler.

ModelSim® SE User's Manual, v10.7 249

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Incremental Compilation

You are not required to compile your design in any particular order (unless you are using
SystemVerilog packages; see Note below) because all module and UDP instantiations and
external hierarchical references are resolved when the design is loaded by the simulator.

Note
Compilation order may matter when using SystemVerilog packages. As stated in the section
Referencing data in packages of IEEE Std 1800-2005: “Packages must exist in order for the
items they define to be recognized by the scopes in which they are imported.”

Incremental compilation is made possible by deferring these bindings, and as a result some
errors cannot be detected during compilation. Commonly, these errors include: modules that
were referenced but not compiled, incorrect port connections, and incorrect hierarchical
references.

Example 7-1. Incremental Compilation Example

Contents of testbench.sv

module testbench;
timeunit 1ns;
timeprecision 10ps;
bit d=1, clk = 0;
wire q;
initial
for (int cycles=0; cycles < 100; cycles++)
#100 clk = !clk;

design dut(q, d, clk);

endmodule

Contents of design.v:

module design(output bit q, input bit d, clk);

timeunit 1ns;
timeprecision 10ps;
always @(posedge clk)
q = d;
endmodule

Compile the design incrementally as follows:

ModelSim> vlog testbench.sv

.
# Top level modules:
# testbench
ModelSim> vlog -sv test1.v
.
# Top level modules:
# dut

250 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Incremental Compilation

Note that the compiler lists each module as a top-level module, although, ultimately, only
testbench is a top-level module. If a module is not referenced by another module compiled in
the same invocation of the compiler, then it is listed as a top-level module. This is just an
informative message that you can ignore during incremental compilation.

The message is more useful when you compile an entire design in one invocation of the
compiler and need to know the top-level module names for the simulator. For example,

% vlog top.v and2.v or2.v

-- Compiling module top
-- Compiling module and2
-- Compiling module or2

Top level modules:

top

Automatic Incremental Compilation with -incr

The most efficient method of incremental compilation is to manually compile only the design
units that have changed. However, this is not always convenient, especially if your source files
have compiler directive interdependencies (such as macros). In this case, you may prefer to
compile your entire design along with the -incr argument. This causes the compiler to
automatically determine which design units have changed and generate code only for those
design units.

The following is an example of how to compile a design with automatic incremental

compilation:

% vlog -incr top.v and2.v or2.v

-- Compiling module top
-- Compiling module and2
-- Compiling module or2

Top level modules:

top

Now, suppose that you modify the functionality of the or2 module:

% vlog -incr top.v and2.v or2.v

-- Skipping module top
-- Skipping module and2
-- Compiling module or2

Top level modules:

top

The compiler informs you that it skipped the modules top and and2, and compiled or2.

Automatic incremental compilation is intelligent about when to compile a design unit. For
example, changing a comment in your source code does not result in a recompile; however,
changing the compiler command line arguments results in a recompile of all design units.

ModelSim® SE User's Manual, v10.7 251

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Library Usage

Note
Changes to dependency files (such as include files or packages specified by the design unit/
module code) will be analyzed and will cause dependent design unit/module files, as well as
the dependency files, to be recompiled when changes are made to them.

Changes to your source code that do not change functionality but that do affect source code line
numbers (such as adding a comment line) will cause all affected design units to be recompiled.
This happens because debug information must be kept current so that ModelSim can trace back
to the correct areas of the source code.

Library Usage
All modules and UDPs in a Verilog design must be compiled into one or more libraries. One
library is usually sufficient for a simple design, but you may want to organize your modules into
various libraries for a complex design. If your design uses different modules having the same
name, then you need to put those modules in different libraries because design unit names must
be unique within a library.
The following is an example of how to organize your ASIC cells into one library and the rest of
your design into another:

% vlib work
% vlib asiclib
% vlog -work asiclib and2.v or2.v
-- Compiling module and2
-- Compiling module or2

Top level modules:

and2
or2
% vlog top.v
-- Compiling module top

Top level modules:

top

Note that the first compilation uses the -work asiclib argument to instruct the compiler to place
the results in the asiclib library rather than the default work library.

Because instantiation bindings are not determined at compile time, you must instruct the
simulator to search your libraries when loading the design. The top-level modules are loaded
from the library named work unless you prefix the modules with the <library>. option. If they
are not found in the work library, they are searched in the libraries specified with -Lf arguments
followed by libraries specified with -L arguments.

Please refer to Library Search Rules for more information on how to search your libraries.

252 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Library Usage

Related Topics
Library Search Rules
Handling Sub-Modules with the Same Name

ModelSim® SE User's Manual, v10.7 253

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
SystemVerilog Multi-File Compilation

SystemVerilog Multi-File Compilation

ModelSim allows you to compile multiple SystemVerilog files at a time.
Declarations in Compilation Unit Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Macro Definitions and Compiler Directives in Compilation Unit Scope . . . . . . . . . . . . 254

Declarations in Compilation Unit Scope

SystemVerilog allows the declaration of types, variables, functions, tasks, and other constructs
in compilation unit scope ($unit). The visibility of declarations in $unit scope does not extend
outside the current compilation unit. Thus, it is important to understand how compilation units
are defined by the simulator during compilation.
By default, vlog operates in Single File Compilation Unit mode (SFCU). This means the
visibility of declarations in $unit scope terminates at the end of each source file. Visibility does
not carry forward from one file to another, except when a module, interface, or package
declaration begins in one file and ends in another file. In that case, the compilation unit spans
from the file containing the beginning of the declaration to the file containing the end of the
declaration.

The vlog command also supports a non-default mode called Multi File Compilation Unit
(MFCU). In MFCU mode, vlog compiles all files on the command line into one compilation
unit. You can invoke vlog in MFCU mode as follows:

• For a specific, one-time compilation: vlog -mfcu.

• For all compilations: set the variable MultiFileCompilationUnit = 1 in the modelsim.ini
file.
By using either of these methods, you allow declarations in $unit scope to remain in effect
throughout the compilation of all files.

If you have made MFCU the default behavior by setting MultiFileCompilationUnit = 1 in

your modelsim.ini file, you can override this default behavior on a specific compilation by using
vlog -sfcu.

Macro Definitions and Compiler Directives in Compilation

Unit Scope
According to the IEEE Std 1800-2005, the visibility of macro definitions and compiler
directives span the lifetime of a single compilation unit. By default, this means the definitions of
macros and settings of compiler directives terminate at the end of each source file. They do not
carry forward from one file to another, except when a module, interface, or package declaration
begins in one file and ends in another file. In that case, the compilation unit spans from the file
containing the beginning of the definition to the file containing the end of the definition.

254 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
SystemVerilog Multi-File Compilation

See Declarations in Compilation Unit Scope for instructions on how to control vlog's handling
of compilation units.

Note
Compiler directives revert to their default values at the end of a compilation unit.

If a compiler directive is specified as an option to the compiler, this setting is used for all
compilation units present in the current compilation.

ModelSim® SE User's Manual, v10.7 255

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Arguments

Verilog-XL Compatible Compiler Arguments

The compiler arguments listed below are equivalent to Verilog-XL arguments and may ease the
porting of a design to ModelSim.
See the vlog command for a description of each argument.

+define+<macro_name>[=<macro_text>]
+delay_mode_distributed
+delay_mode_path
+delay_mode_unit
+delay_mode_zero
-f <filename>
+incdir+<directory>
+mindelays
+maxdelays
+nowarn<mnemonic>
+typdelays
-u

Arguments Supporting Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Verilog-XL uselib Compiler Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Arguments Supporting Source Libraries

The compiler arguments listed below support source libraries in the same manner as Verilog-
XL.
Note that these source libraries are very different from the libraries that the ModelSim compiler
uses to store compilation results. You may find it convenient to use these arguments if you are
porting a design to ModelSim or if you are familiar with these arguments and prefer to use
them.

Source libraries are searched after the source files on the command line are compiled. If there
are any unresolved references to modules or UDPs, then the compiler searches the source
libraries to satisfy them. The modules compiled from source libraries may in turn have
additional unresolved references that cause the source libraries to be searched again. This
process is repeated until all references are resolved or until no new unresolved references are
found. Source libraries are searched in the order they appear on the command line.

-v <filename>
-y <directory>
+libext+<suffix>
+librescan
+nolibcell
-R [<simargs>]

Related Topics
vlog [ModelSim SE Command Reference Manual]

256 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Arguments

Verilog-XL uselib Compiler Directive

The `uselib compiler directive is an alternative source library management scheme to the -v, -y,
and +libext compiler arguments. It has the advantage that a design may reference different
modules having the same name.
To compile designs that contain `uselib directive statements, use the -compile_uselibs argument
(described below) with the vlog command.

The syntax for the `uselib directive is:

`uselib <library_reference>...

where <library_reference> can be one or more of the following:

• dir=<library_directory>, which is equivalent to the command line argument:

-y <library_directory>

• file=<library_file>, which is equivalent to the command line argument:

-v <library_file>

• libext=<file_extension>, which is equivalent to the command line argument:

+libext+<file_extension>

• lib=<library_name>, which references a library for instantiated objects, specifically

modules, interfaces and program blocks, but not packages. You must ensure the correct
mappings are set up if the library does not exist in the current working directory. The
-compile_uselibs argument does not affect this usage of `uselib.
For example, the following directive

`uselib dir=/h/vendorA libext=.v

is equivalent to the following command line arguments:

-y /h/vendorA +libext+.v

Since the `uselib directives are embedded in the Verilog source code, there is more flexibility in
defining the source libraries for the instantiations in the design. The appearance of a `uselib
directive in the source code explicitly defines how instantiations that follow it are resolved,
completely overriding any previous `uselib directives.

An important feature of ‘uselib is to allow a design to reference multiple modules having the
same name, therefore independent compilation of the source libraries referenced by the `uselib
directives is required.

ModelSim® SE User's Manual, v10.7 257

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Arguments

Each source library should be compiled into its own object library. The compilation of the code
containing the `uselib directives only records which object libraries to search for each module
instantiation when the design is loaded by the simulator.

Because the `uselib directive is intended to reference source libraries, the simulator must infer
the object libraries from the library references. The rule is to assume an object library named
work in the directory defined in the library reference:

dir=<library_directory>

or the directory containing the file in the library reference

file=<library_file>

The simulator will ignore a library reference libext=<file_extension>. For example, the
following `uselib directives infer the same object library:

‘uselib dir=/h/vendorA
‘uselib file=/h/vendorA/libcells.v

In both cases the simulator assumes that the library source is compiled into the object library:

/h/vendorA/work

The simulator also extends the `uselib directive to explicitly specify the object library with the
library reference lib=<library_name>. For example:

‘uselib lib=/h/vendorA/work

The library name can be a complete path to a library, or it can be a logical library name defined
with the vmap command.

-compile_uselibs Argument
Use the -compile_uselibs argument to vlog to reference `uselib directives. The argument finds
the source files referenced in the directive, compiles them into automatically created object
libraries, and updates the modelsim.ini file with the logical mappings to the libraries.

When you use -compile_uselibs, ModelSim determines which directory to compile the object
libraries into by choosing, in order, from the following three values:

• The directory name specified by the -compile_uselibs argument. For example,

-compile_uselibs=./mydir

• The directory specified by the MTI_USELIB_DIR environment variable (see

Environment Variables)
• A directory named mti_uselibs that is created in the current working directory

258 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Arguments

The following code fragment and compiler invocation show how two different modules that
have the same name can be instantiated within the same design:

module top;
`uselib dir=/h/vendorA libext=.v
NAND2 u1(n1, n2, n3);
`uselib dir=/h/vendorB libext=.v
NAND2 u2(n4, n5, n6);
endmodule

vlog -compile_uselibs top

This allows the NAND2 module to have different definitions in the vendorA and vendorB
libraries.

uselib is Persistent
As mentioned above, the appearance of a `uselib directive in the source code explicitly defines
how instantiations that follow it are resolved. This may result in unexpected consequences. For
example, consider the following compile command:

vlog -compile_uselibs dut.v srtr.v

Assume that dut.v contains a `uselib directive. Since srtr.v is compiled after dut.v, the `uselib
directive is still in effect. When srtr is loaded it is using the `uselib directive from dut.v to
decide where to locate modules. If this is not what you intend, then you need to put an empty
`uselib at the end of dut.v to “close” the previous `uselib statement.

ModelSim® SE User's Manual, v10.7 259

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog Configurations

Verilog Configurations
The Verilog 2001 specification added configurations. Configurations specify how a design is
“assembled” during the elaboration phase of simulation. Configurations actually consist of two
pieces: the library mapping and the configuration itself. The library mapping is used at compile
time to determine into which libraries the source files are to be compiled.
Here is an example of a simple library map file:

library work ../top.v;

library rtlLib lrm_ex_top.v;
library gateLib lrm_ex_adder.vg;
library aLib lrm_ex_adder.v;

Here is an example of a library map file that uses the -incdir argument:

library lib1 src_dir/*.v -incdir ../include_dir2, ../, my_incdir;

The name of the library map file is arbitrary. You specify the library map file using the -libmap
argument to the vlog command. Alternatively, you can specify the file name as the first item on
the vlog command line, and the compiler reads it as a library map file.

Tip
You can use vlog -mfcu to compile macros for all files in a given testbench. Any macros
already defined before the -libmap argument appears are still defined for use by the -libmap
files. That is, -mfcu macros are applied to the other libraries in library mapping files.

The library map file must be compiled along with the Verilog source files. Multiple map files
are allowed but each must be preceded by the -libmap argument.

The library map file and the configuration can exist in the same or different files. If they are
separate, only the map file needs the -libmap argument. The configuration is treated as any other
Verilog source file.

Configurations and the Library Named work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Configurations and the Library Named work

ModelSim trreats the library named “work” in a special way for Verilog configurations.
Consider the following code example:

config cfg;
design top;
instance top.u1 use work.u1;
endconfig

In this case, work.u1 indicates to load u1 from the current library.

260 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog Configurations

To create a configuration that loads an instance from a library other than the default work
library, do the following:

1. Make sure the library has been created using the vlib command. For example:
vlib mylib

2. Define this library (mylib) as the new current (working) library:

vlog -work mylib

3. Load instance u1 from the current library, which is now mylib:

config cfg;
design top;
instance top.u1 use mylib.u1;
endconfig

Related Topics
Working Library Versus Resource Libraries

ModelSim® SE User's Manual, v10.7 261

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog Generate Statements

Verilog Generate Statements

ModelSim implements the rules adopted for Verilog 2005, because the Verilog 2001 rules for
generate statements had numerous inconsistencies and ambiguities. Most of the 2005 rules are
backwards compatible, but there is one key difference related to name visibility.
Name Visibility in Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Name Visibility in Generate Statements

Consider the following code example.
module m;
parameter p = 1;

generate
if (p)
integer x = 1;
else
real x = 2.0;
endgenerate

initial $display(x);
endmodule

This example is legal under 2001 rules. However, it is illegal under the 2005 rules and causes an
error in ModelSim. Under the new rules, you cannot hierarchically reference a name in an
anonymous scope from outside that scope. In the example above, x does not propagate its
visibility upwards, and each condition alternative is considered to be an anonymous scope.

For this example to simulate properly in ModelSim, change it to the following:

module m;
parameter p = 1;

if (p) begin:s
integer x = 1;
end
else begin:s
real x = 2.0;
end

initial $display(s.x);
endmodule

Because the scope is named in this example (begin:s), normal hierarchical resolution rules apply
and the code runs without error.

In addition, note that the keyword pair generate - endgenerate is optional under the 2005 rules
and are excluded in the second example.

262 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Initializing Registers and Memories

Initializing Registers and Memories

For Verilog designs you can initialize registers and memories with specific values or randomly
generated values.
Initialization Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Initializing with Specific Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 264
Initializing with Specific Values — Enabled During Optimization . . . . . . . . . . . . . . . . 264
Initializing with Random Values — Enabled During Compilation . . . . . . . . . . . . . . . . 264
Initializing with Random Values — Enabled During Optimization . . . . . . . . . . . . . . . . 265
Recording Initialization Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Initialization Concepts
Two important initialization concepts to understand for initializing registers and memories are
“random stability” and “sequential UDPs.”
• Random stability — From run to run, it is reasonable to expect that simulation results
will be consistent with the same seed value, even when the design is recompiled or
different optimization switches are specified.
However, if the design changes in any way, random stability can not be ensured. These
design changes include:
o Changing the source code (except for comment editing).
o Changing parameter values with vopt -G or vsim -G. This forces a different topology
during design elaboration.
o Changing a +define switch such that different source code is compiled.
o Changing design hierarchy of the design units due to the random initial value being
dependent upon the full path name of the instance.
For sequential UDPs, the simulator guarantees repeatable initial values only if the
design is compiled and run with the same vlog, vopt, and vsim options.
• Sequential UDPs — An initial statement in a sequential UDP overrides all +initreg
functionality.

Limitations
• The following are not initialized with +initmem or +initreg:
o Variables in dynamic types, dynamic arrays, queues, or associative arrays.
o Unpacked structs, or unpacked or tagged unions.

ModelSim® SE User's Manual, v10.7 263

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Initializing Registers and Memories

Requirements
• Prepare your libraries with vlib and vmap as you would normally.

Initializing with Specific Values — Enabled During

Compilation
Initialization with specific values may take place during compilation by using this procedure.
Procedure
1. Compile the design unit with the +initreg or +initmem switches to the vlog command.
Refer to the vlog command reference page for descriptions of the following options.
a. Specify which datatypes should be initialized: +{r | b | e | u}.
b. Specify the initialization value: +{0 | 1 | X | Z}.
2. Simulate as you would normally.

Initializing with Specific Values — Enabled During

Optimization
Initialization with specific values may take place during compilation by using this procedure.
Procedure
1. Compile as you would normally
2. Optimize the design with the +initreg or +initmem switches to the vopt command. Refer
to the vopt command reference page for a description of the following options.
a. Specify which datatypes should be initialized: +{r | b | e | u}.
b. Specify the initialization value: +{0 | 1 | X | Z}.
c. Specify design unit name: +<selection>
3. Simulate as you would normally.

Initializing with Random Values — Enabled During

Compilation
You may also initiallize with random values during compilation.
Procedure
1. Compile the design unit with the +initreg or +initmem switches to the vlog command.
Refer to the vlog command reference page for descriptions of the following options.

264 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Initializing Registers and Memories

a. Specify which datatypes should be initialized: +{r | b | e | u}.

b. Do not specify the initialization value. This enables the specification of a random
seed during simulation.
2. Simulate as you would normally, except for adding the +initmem+<seed> or
+initreg+<seed> switches. Refer to the vsim command reference page for a description
of this switch. The random values will only include 0 or 1.
If no +initreg is present on the vsim command line, a random seed of 0 is used during
initialization.

Initializing with Random Values — Enabled During

Optimization
You may also initiallize with random values during compilation.
Procedure
1. Compile as you would normally
2. Optimize the design with the +initreg or +initmem switches to the vopt command. Refer
to the vopt command reference page for a description of the following options.
a. Specify which datatypes should be initialized: +{r | b | e | u}.
b. Do not specify the initialization value. This enables the specification of a random
seed during simulation.
c. Specify design unit name: +<selection>
3. Simulate as you would normally, except for adding the +initmem+<seed> or
+initreg+<seed> switches. Refer to the vsim command reference page for a description
of this switch. The random values will only include 0 or 1.
If no +initreg is present on the vsim command line, a random seed of 0 is used during
initialization.

Recording Initialization Values

You can save a report of the seed values generated by +initmem and +initreg by specifying
-initreport <filename> on the vsim command line.
Refer to vsim -initreport <filename> for more information.

ModelSim® SE User's Manual, v10.7 265

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog Simulation

Verilog Simulation
A Verilog design is ready for simulation after it has been compiled with vlog and possibly
optimized with vopt. The simulator may then be invoked with the names of the top-level
modules (many designs contain only one top-level module) or the name(s) you assigned to the
optimized version(s) of the design.
For more information on Verilog optimizations, see the Chapter, Optimizing Designs with vopt
and the section Optimization Considerations for Verilog Designs. For more information about
simulation with multiple optimized design modules refer to vsim
<library_name>.<design_unit>.

For example, if your top-level modules are “testbench” and “globals”, then invoke the simulator
as follows:

vsim testbench globals

After the simulator loads the top-level modules, it iteratively loads the instantiated modules and
UDPs in the design hierarchy, linking the design together by connecting the ports and resolving
hierarchical references. By default all modules and UDPs are loaded from the library named
work. You can specify Modules and UDPs from other libraries with the vsim -L or -Lf
arguments (refer to Library Search Rules for details).

On successful loading of the design, the simulation time is set to zero, and you must enter a run
command to begin simulation. Commonly, you enter run -all to run until there are no more
simulation events or until $finish is executed in the Verilog code. You can also run for specific
time periods (for example, run 100 ns). Enter the quit command to exit the simulator.

Simulator Resolution Limit (Verilog) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Modules Without Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Multiple Timescale Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Choosing the Resolution for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Event Ordering in Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Debugging Event Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Signal Segmentation Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Force and Release Statements in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Verilog-XL Compatible Simulator Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Using Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

266 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator Resolution Limit (Verilog)

Simulator Resolution Limit (Verilog)

The simulator internally represents time as a 64-bit integer in units equivalent to the smallest
unit of simulation time (also known as the simulator resolution limit). The resolution limit
defaults to the smallest time units that you specify among all of the `timescale compiler
directives in the design.
Here is an example of a `timescale directive:

`timescale 1 ns / 100 ps

The first number (1 ns) is the time units; the second number (100 ps) is the time precision,
which is the rounding factor for the specified time units. The directive above causes time values
to be read as nanoseconds and rounded to the nearest 100 picoseconds.

Time units and precision can also be specified with SystemVerilog keywords as follows:

timeunit 1 ns
timeprecision 100 ps

Modules Without Timescale Directives

Unexpected behavior may occur if your design contains some modules with timescale directives
and others without. An elaboration error is issued in this situation and it is highly recommended
that all modules having delays also have timescale directives to make sure that the timing of the
design operates as intended.
Timescale elaboration errors may be suppressed or reduced to warnings however, there is a risk
of improper design behavior and reduced performance. The vsim +nowarnTSCALE or
-suppress options may be used to ignore the error, while the -warning option may be used to
reduce the severity to a warning.

-timescale Option
The -timescale option can be used with vlog and vopt to specify the default timescale in effect
during compilation for modules that do not have an explicit `timescale directive. The format of
the -timescale argument is the same as that of the `timescale directive:

-timescale <time_units>/<time_precision>

where <time_units> is <n> <units>. The value of <n> must be 1, 10, or 100. The value of
<units> must be fs, ps, ns, us, ms, or s. In addition, the <time_units> must be greater than or
equal to the <time_precision>.

For example:

-timescale "1ns / 1ps"

ModelSim® SE User's Manual, v10.7 267

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Multiple Timescale Directives

The argument above needs quotes because it contains white space.

Design units that do not have a timescale set in the HDL source, with vlog -timescale, or vopt -
timescale will generate an error similar to the following:

# ** Error (suppressible): (vsim-3009) [TSCALE] - Module 'top2' does not

have a timeunit/timeprecision specification in effect, but other modules
do.
# Time: 0 ps Iteration: 0 Instance: /top2 File: t2.sv
# Loading work.dut2(fast)

but the error can be suppressed causing vsim to use the simulator time resolution.

Multiple Timescale Directives

As previously noted, a design can have multiple timescale directives. Separately compiled
modules can also have different timescales. The simulator determines the smallest timescale of
all the modules in a design and uses that as the simulator resolution.
The timescale directive takes effect where it appears in a source file and applies to all Verilog
source files (.v files) that follow in the same vlog command.

Note
For SystemVerilog source files (.sv files), this requires that you use either the -mfcu
argument or the -mfcu=macro argument with the vlog command.

timescale, -t, and Rounding

The optional vsim argument -t sets the simulator resolution limit for the overall simulation. If
the resolution set by -t is larger than the precision set in a module, the time values in that
module are rounded up. If the resolution set by -t is smaller than the precision of the module, the
precision of that module remains whatever is specified by the `timescale directive.

Consider the following code:

`timescale 1 ns / 100 ps

module foo;

initial
#12.536 $display

The list below shows three possibilities for -t and how the delays in the module are handled in
each case:

• -t not set
The delay is rounded to 12.5 as directed by the module’s ‘timescale directive.

268 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Choosing the Resolution for Verilog

• -t is set to 1 fs
The delay is rounded to 12.5. Again, the module’s precision is determined by the
‘timescale directive. ModelSim does not override the module’s precision.
• -t is set to 1 ns
The delay will be rounded to 13. The module’s precision is determined by the -t setting.
ModelSim can only round the module’s time values because the entire simulation is
operating at 1 ns.

Choosing the Resolution for Verilog

You should choose the coarsest simulator resolution limit possible that does not result in
undesired rounding of your delays. For example, values smaller than the current Time Scale will
be truncated to zero (0) and a warning issued. However, the time precision should also not be set
unnecessarily small, because in some cases performance will be degraded.

ModelSim® SE User's Manual, v10.7 269

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Event Ordering in Verilog Designs

Event Ordering in Verilog Designs

Event-based simulators such as ModelSim may process multiple events at a given simulation
time. The Verilog language is defined such that you cannot explicitly control the order in which
simultaneous events are processed. Unfortunately, some designs rely on a particular event
order, and these designs may behave differently than you expect.
Event Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Controlling Event Queues with Blocking or Non-Blocking Assignments . . . . . . . . . . . 272

Event Queues
Section 11 of IEEE Std 1364-2005 defines several event queues that determine the order in
which events are evaluated.
At the current simulation time, the simulator has the following pending events:

• active events
• inactive events
• non-blocking assignment update events
• monitor events
• future events
o inactive events
o non-blocking assignment update events
The Standard (LRM) dictates that events are processed as follows:

1. All active events are processed.

2. Inactive events are moved to the active event queue and then processed.
3. Non-blocking events are moved to the active event queue and then processed.
4. Monitor events are moved to the active queue and then processed.
5. Simulation advances to the next time where there is an inactive event or a non-blocking
assignment update event.
Within the active event queue, the events can be processed in any order, and new active events
can be added to the queue in any order. In other words, you cannot control event order within
the active queue. The example below illustrates potential ramifications of this situation.

Assume that you have these four statements:

• always@(q) p = q;

270 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Event Ordering in Verilog Designs

• always @(q) p2 = not q;

• always @(p or p2) clk = p and p2;
• always @(posedge clk)
with current variable values: q = 0, p = 0, p2=1

The tables below show two of the many valid evaluations of these statements. Evaluation events
are denoted by a number where the number is the statement to be evaluated. Update events are
denoted <name>(old->new) where <name> indicates the reg being updated and new is the
updated value.\
Table 7-1. Evaluation 1 of always Statements
Event being processed Active event queue
q(0 -> 1)
q(0 -> 1) 1, 2
1 p(0 -> 1), 2
p(0 -> 1) 3, 2
3 clk(0 -> 1), 2
clk(0 -> 1) 4, 2
4 2
2 p2(1 -> 0)
p2(1 -> 0) 3
3 clk(1 -> 0)
clk(1 -> 0) <empty>

Table 7-2. Evaluation 2 of always Statement

Event being processed Active event queue
q(0 -> 1)
q(0 -> 1) 1, 2
1 p(0 -> 1), 2
2 p2(1 -> 0), p(0 -> 1)
p(0 -> 1) 3, p2(1 -> 0)
p2(1 -> 0) 3
3 <empty> (clk does not change)

ModelSim® SE User's Manual, v10.7 271

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Event Ordering in Verilog Designs

Again, both evaluations are valid. However, in Evaluation 1, clk has a glitch on it; in Evaluation
2, clk does not. This indicates that the design has a zero-delay race condition on clk.

Controlling Event Queues with Blocking or Non-Blocking

Assignments
The only control you have over event order is to assign an event to a particular queue. You do
this by using blocking or non-blocking assignments.

Blocking Assignments
Blocking assignments place an event in the active, inactive, or future queues depending on what
type of delay they have:

• a blocking assignment without a delay goes in the active queue

• a blocking assignment with an explicit delay of 0 goes in the inactive queue
• a blocking assignment with a nonzero delay goes in the future queue
Non-Blocking Assignments
A non-blocking assignment goes into either the non-blocking assignment update event queue or
the future non-blocking assignment update event queue. (Non-blocking assignments with no
delays and those with explicit zero delays are treated the same.)

Non-blocking assignments should be used only for outputs of flip-flops. This ensures that all
outputs of flip-flops do not change until after all flip-flops have been evaluated. Attempting to
use non-blocking assignments in combinational logic paths to remove race conditions may only
cause more problems. (In the preceding example, changing all statements to non-blocking
assignments would not remove the race condition.) This includes using non-blocking
assignments in the generation of gated clocks.

The following is an example of how to properly use non-blocking assignments.

gen1: always @(master)

clk1 = master;

gen2: always @(clk1)

clk2 = clk1;

f1 : always @(posedge clk1)

begin
q1 <= d1;
end

f2: always @(posedge clk2)

begin
q2 <= q1;
end

272 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Event Ordering in Verilog Designs

If written this way, a value on d1 always takes two clock cycles to get from d1 to q2.
If you change clk1 = master and clk2 = clk1 to non-blocking assignments or q2 <= q1 and q1
<= d1 to blocking assignments, then d1 may get to q2 is less than two clock cycles.

ModelSim® SE User's Manual, v10.7 273

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Debugging Event Order Issues

Debugging Event Order Issues

Since many models have been developed on Verilog-XL, ModelSim tries to duplicate Verilog-
XL event ordering to ease the porting of those models to ModelSim. However, ModelSim does
not match Verilog-XL event ordering in all cases, and if a model ported to ModelSim does not
behave as expected, then you should suspect that there are event order dependencies.
ModelSim helps you track down event order dependencies with the following compiler
arguments: -compat, -hazards, and -keep_delta.

See the vlog command for descriptions of -compat and -hazards.

Hazard Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Hazard Detection and Optimization Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Hazard Detection
The -hazards argument for the vsim command detects event order hazards involving
simultaneous reading and writing of the same register in concurrently executing processes.
ModelSim detects the following kinds of hazards:

• WRITE/WRITE — Two processes writing to the same variable at the same time.
• READ/WRITE — One process reading a variable at the same time it is being written to
by another process. ModelSim calls this a READ/WRITE hazard if it executed the read
first.
• WRITE/READ — Same as a READ/WRITE hazard except that ModelSim executed the
write first.
vsim issues an error message when it detects a hazard. The message pinpoints the variable and
the two processes involved. You can have the simulator break on the statement where the
hazard is detected by setting the break on assertion level to Error.

To enable hazard detection you must invoke vlog with the -hazards argument when you compile
your source code and you must also invoke vsim with the -hazards argument when you
simulate.

Note
Enabling -hazards implicitly enables the -compat argument. As a result, using this argument
may affect your simulation results.

274 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Signal Segmentation Violations

Hazard Detection and Optimization Levels

In certain cases hazard detection results are affected by the optimization level used in the
simulation. Some optimizations change the read/write operations performed on a variable if the
transformation is determined to yield equivalent results. Because the hazard detection algorithm
cannot determine whether the read/write operations can affect the simulation results, the
optimizations can result in different hazard detection results. Generally, the optimizations
reduce the number of false hazards by eliminating unnecessary reads and writes, but there are
also optimizations that can produce additional false hazards.

Limitations of Hazard Detection

• Reads and writes involving bit and part selects of vectors are not considered for hazard
detection. The overhead of tracking the overlap between the bit and part selects is too
high.
• A WRITE/WRITE hazard is flagged even if the same value is written by both processes.
• A WRITE/READ or READ/WRITE hazard is flagged even if the write does not modify
the variable's value.
• Glitches on nets caused by non-guaranteed event ordering are not detected.
• A non-blocking assignment is not treated as a WRITE for hazard detection purposes.
This is because non-blocking assignments are not normally involved in hazards. (In fact,
they should be used to avoid hazards.)
• Hazards caused by simultaneous forces are not detected.

Signal Segmentation Violations

If you attempt to access a SystemVerilog object that has not been constructed with the new
operator, you will receive a fatal error called a signal segmentation violation (SIGSEGV).
For example, the following code produces a SIGSEGV fatal error:

class C;
int x;
endclass

C obj;
initial obj.x = 5;

This attempts to initialize a property of obj, but obj has not been constructed. The code is
missing the following:

C obj = new;

ModelSim® SE User's Manual, v10.7 275

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Signal Segmentation Violations

The new operator performs three distinct operations:

• Allocates storage for an object of type C

• Calls the “new” method in the class or uses a default method if the class does not define
“new”
• Assigns the handle of the newly constructed object to “obj”
If the object handle obj is not initialized with new, there will be nothing to reference. ModelSim
sets the variable to the value null and the SIGSEGV fatal error will occur.

To debug a SIGSEGV error, first look in the transcript. Figure 7-1 shows an example of a
SIGSEGV error message in the Transcript window.

Figure 7-1. Fatal Signal Segmentation Violation (SIGSEGV)

The Fatal error message identifies the filename and line number where the code violation
occurred (in this example, the file is top.sv and the line number is 19).

ModelSim sets the active scope to the location where the error occurred. In the Processes
window, the current process is highlighted (Figure 7-2).

Figure 7-2. Current Process Where Error Occurred

Double-click the highlighted process to open a Source window. A blue arrow will point to the
statement where the simulation stopped executing (Figure 7-3).

276 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Signal Segmentation Violations

Figure 7-3. Blue Arrow Indicating Where Code Stopped Executing

Next, look for null values in the ModelSim Locals window (Figure 7-4), which displays data
objects declared in the local (current) scope of the active process.

Figure 7-4. Null Values in the Locals Window

The null value in Figure 7-4 indicates that the object handle for obj was not properly
constructed with the new operator.

ModelSim® SE User's Manual, v10.7 277

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

Negative Timing Checks

ModelSim automatically detects cells with negative timing checks and causes timing checks to
be performed on the delayed versions of input ports (used when there are negative timing check
limits).
Negative timing syntax is defined in the IEEE Standard for Verilog Hardware Description
Language, specifically Chapter 15 “Timing Checks”.

The negative timing check algorithm is enabled by default. To explicitly enable the algorithm,
use the +delayed_timing_checks with the vsim command. If you want to disable the
functionality, add the +no_autodtc to the vsim command line.

vsim Arguments Related to Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Commands Supporting Negative Timing Check Limits . . . . . . . . . . . . . . . . . . . . . . . . . 279
Negative Timing Constraint Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Using Delayed Inputs for Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

vsim Arguments Related to Timing Checks

The vsim command supports several timing check-related arguments:
• vsim +delayed_timing_checks — (on by default) Instructs the simulator to
automatically detect cells with negative timing checks.
• vsim +no_autodtc — Disables the default behavior of the +delayed_timing_checks
option
• vsim +no_neg_tchk — Forces all negative timing check limits to a zero value.
• vsim +ntc_warn — Enables messaging for negative timing checks.
• vsim +notimingchecks — Removes all timing check entries from the design as it is
parsed

278 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Negative Timing Checks

Commands Supporting Negative Timing Check Limits

By default, ModelSim supports negative timing check limits in Verilog $setuphold and $recrem
system tasks.
Using the +no_neg_tchk argument with the vsim command causes all negative timing check
limits to be set to zero.

Models that support negative timing check limits must be written properly if they are to be
evaluated correctly. These timing checks specify delayed versions of the input ports, which are
used for functional evaluation. The correct syntax for $setuphold and $recrem is as follows.

$setuphold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
$recrem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Timing Check Syntactical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

ModelSim® SE User's Manual, v10.7 279

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

$setuphold
The $setuphold check determine whether signals obey the timing constraints.
Usage
$setuphold ( reference_event , data_event , timing_check_limit , timing_check_limit ,
[ notifier ] , [ stamptime_condition ] , [ checktime_condition ] , [ delayed_reference ] ,
[ delayed_data ] ) ;
Arguments
• reference_event
(required) Specifies a transition in a reference signal that establishes the reference time for
tracking timing violations on the data_event. Since $setuphold combines the functionality of
the $setup and $hold system tasks, the reference_event sets the lower bound event for $hold
and the upper bound event for $setup.
• data_event
(required) Specifies a transition of a data signal that initiates the timing check. The
data_event sets the upper bound event for $hold and the lower bound limit for $setup.
• timing_check_limit (both instances are required)
Specifies a constant expression or specparam that specifies the minimum interval between:
First instance
the data_event and the clk_event. Any change to the data signal within this interval
results in a timing violation.
Second instance
the interval between the clk_event and the data_event. Any change to the data signal
within this interval results in a timing violation.
• notifier
(optional) Specifies a register whose value is updated whenever a timing violation occurs.
The notifier can be used to define responses to timing violations.
• stamptime_condition
(optional) Conditions the data_event for the setup check and the reference_event for the
hold check. This alternate method of conditioning precludes specifying conditions in the
reference_event and data_event arguments.
• checktime_condition
(optional) Conditions the data_event for the hold check and the reference_event for the
setup check. This alternate method of conditioning precludes specifying conditions in the
reference_event and data_event arguments.

280 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Negative Timing Checks

• delayed_reference
(optional) Specifies a net that is continuously assigned the value of the net specified in the
reference_event. The delay is determined by the simulator and may be nonzero depending
on all the timing check limits.
• delayed_data
(optional) Specifies a net that is continuously assigned the value of the net specified in the
data_event. The delay is determined by the simulator and may be nonzero depending on all
the timing check limits.

ModelSim® SE User's Manual, v10.7 281

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

$recrem
The $recrem timing check determine whether signals obey the timing constraints.
Usage
$recrem ( reference_event , data_event , timing_check_limit , timing_check_limit ,
[ notifier ] , [ stamptime_condition ] , [ checktime_condition ] , [ delayed_reference ] ,
[ delayed_data ] ) ;
Arguments
• reference_event
(required) Specifies an asynchronous control signal with an edge identifier to indicate the
release from an active state.
• data_event
(required) Specifies a clock or gate signal with an edge identifier to indicate the active edge
of the clock or the closing edge of the gate.
• timing_check_limit (both instances are required)
Specifies a minimum interval between:
First instance — the release of the asynchronous control signal and the active edge of the
clock event. Any change to a signal within this interval results in a timing violation.
Second instance — the active edge of the clock event and the release of the
asynchronous control signal. Any change to a signal within this interval results in a
timing violation.
• notifier
(optional) Specifies a register whose value is updated whenever a timing violation occurs.
The notifier can be used to define responses to timing violations.
• stamptime_condition
(optional) Conditions the data_event for the removal check and the reference_event for the
recovery check. This alternate method of conditioning precludes specifying conditions in
the reference_event and data_event arguments.
• checktime_condition
(optional) Conditions the data_event for the recovery check and the reference_event for the
removal check. This alternate method of conditioning precludes specifying conditions in the
reference_event and data_event arguments.
• delayed_reference
(optional) Specifies a net that is continuously assigned the value of the net specified in the
reference_event. The delay is determined by the simulator and may be nonzero depending
on all the timing check limits.

282 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Negative Timing Checks

• delayed_data
(optional) Specifies a net that is continuously assigned the value of the net specified in the
data_event. The delay is determined by the simulator and may be nonzero depending on all
the timing check limits.

Timing Check Syntactical Conventions

Your $setuphold() or $recrem() timing checks must follow the LRM defined syntax exactly.
The simulator will behave in the following ways based on your commands.
The two timing_check_limit values are your delayed reference and delayed data values,
respectively, which can be negative values. In all cases, you must ensure that the sum of these
two values must be greater than zero (0). If they do not meet this requirement, the simulator
silently sets any negative values to zero (0) during elaboration or SDF annotation. You can
force the simulator to show a warning (vsim-3616) in this case with the +ntc_warn argument to
the vsim command.

** Warning: (vsim-3616) cells.v(x): Instance 'dff0' - Bad $setuphold

constraints: 5 ns and -6 ns. Negative limit(s) set to zero.

The internal timing check algorithm will determine the proper delay values, specifically a
negative hold requires the shifting of your DATA signal and a negative setup requires the
shifting of your CLOCK. In some rare cases, typically due to bad SDF values, the timing check
algorithm can not create convergence. Use the +ntc_warn argument to the vsim command to
receive additional warning messages.

The LRM does not allow for you to specify a reference_event or data_event condition using the
&&& operator and also specify a stamptime_condition or checktime_condition. When this does
occur, the simulator issues a warning and ignores the condition defined in either event. For
example, in the task:

$setuphold(posedge clk &&& cond1, posedge d, 10, -5, notifier, cond2, ,

dclk, dd);

the condition “cond1” will be ignored.

The delayed_reference and delayed_data arguments are provided to ease the modeling of
devices that may have negative timing constraints. The model's logic should reference the
delayed_reference and delayed_data nets in place of the normal reference and data nets. This
ensures that the correct data is latched in the presence of negative constraints. The simulator
automatically calculates the delays for delayed_reference and delayed_data such that the correct
data is latched as long as a timing constraint has not been violated. See Using Delayed Inputs
for Timing Checks for more information.

ModelSim® SE User's Manual, v10.7 283

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

Negative Timing Constraint Algorithm

The ModelSim negative timing constraint algorithm attempts to find a set of delays such that the
data net is valid when the clock or control nets transition and the timing checks are satisfied.
The algorithm is iterative because a set of delays that satisfies all timing checks for a pair of
inputs can cause mis-ordering of another pair (where both pairs of inputs share a common
input). When a set of delays that satisfies all timing checks is found, the delays are said to
converge.
When none of the delay sets cause convergence, the algorithm pessimistically changes the
timing check limits to force convergence. Basically, the algorithm zeroes the smallest negative
$setup/$recovery limit. If a negative $setup/$recovery does not exist, then the algorithm zeros
the smallest negative $hold/$removal limit. After zeroing a negative limit, the delay calculation
procedure is repeated. If the delays do not converge, the algorithm zeros another negative limit,
repeating the process until convergence is found.

For example, in this timing check,

$setuphold(posedge CLK, D, -10, 20, notifier,,, dCLK, dD);

dCLK is the delayed version of the input CLK and dD is the delayed version of D. This posedge
D-Flipflop module has a negative setup limit of -10 time units, which allows posedge CLK to
occur up to 10 time units before the stable value of D is latched.

Without delaying CLK by 11, an old value for D could be latched. Note that an additional time
unit of delay is added to prevent race conditions.

284 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Negative Timing Checks

The inputs look like this:

Because the posedge CLK transition is delayed by the amount of the negative setup limit (plus
one time unit to prevent race conditions) no timing violation is reported and the new value of D
is latched.

However, the effect of this delay could also affect other inputs with a specified timing
relationship to CLK. The simulator is responsible for calculating the delay between all inputs
and their delayed versions. The complete set of delays (delay solution convergence) must
consider all timing check limits together so that whenever timing is met the correct data value is
latched.

Consider the following timing checks specified relative to CLK:

$setuphold(posedge CLK, D, -10, 20, notifier,,, dCLK, dD);

$setuphold(posedge CLK, negedge RST, -30, 45, notifier,,, dCLK, dRST);

To solve the timing checks specified relative to CLK the following delay values are necessary:
Rising Falling
dCLK 31 31
dD 20 20
dRST 0 0

ModelSim® SE User's Manual, v10.7 285

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

The simulator's intermediate delay solution shifts the violation regions to overlap the reference
events.

Notice that no timing is specified relative to negedge CLK, but the dCLK falling delay is set to
the dCLK rising delay to minimize pulse rejection on dCLK. Pulse rejection that occurs due to
delayed input delays is reported by:

"WARNING[3819] : Scheduled event on delay net dCLK was cancelled"

Now, consider the following case where a new timing check is added between D and RST and
the simulator cannot find a delay solution. Some timing checks are set to zero. In this case, the
new timing check is not annotated from an SDF file and a default $setuphold limit of 1, 1 is
used:

$setuphold(posedge CLK, D, -10, 20, notifier,,, dCLK, dD);

$setuphold(posedge CLK, negedge RST, -30, 45, notifier,,, dCLK, dRST);
$setuphold(negedge RST, D, 1, 1, notifier,,, dRST, dD);

As illustrated earlier, to solve timing checks on CLK, delays of 20 and 31 time units were
necessary on dD and dCLK, respectively.
Rising Falling
dCLK 31 31
dD 20 20
dRST 0 0

286 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Negative Timing Checks

The simulator's intermediate delay solution is:

But this is not consistent with the timing check specified between RST and D. The falling RST
signal can be delayed by additional 10, but that is still not enough for the delay solution to
converge.
Rising Falling
dCLK 31 31
dD 20 20
dRST 0 10

As stated above, if a delay solution cannot be determined with the specified timing check limits
the smallest negative $setup/$recovery limit is zeroed and the calculation of delays repeated. If
no negative $setup/$recovery limits exist, then the smallest negative $hold/$removal limit is
zeroed. This process is repeated until a delay solution is found.

If a timing check in the design was zeroed because a delay solution was not found, a summary
message like the following will be issued:

# ** Warning: (vsim-3316) No solution possible for some delayed timing

check nets. 1 negative limits were zeroed. Use +ntc_warn for more info.

Invoking vsim with the +ntc_warn option identifies the timing check that is being zeroed.

Finally consider the case where the RST and D timing check is specified on the posedge RST.

ModelSim® SE User's Manual, v10.7 287

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Negative Timing Checks

$setuphold(posedge CLK, D, -10, 20, notifier,,, dCLK, dD);

$setuphold(posedge CLK, negedge RST, -30, 45, notifier,,, dCLK, dRST);
$setuphold(posedge RST, D, 1, 1, notifier,,, dRST, dD);

In this case the delay solution converges when an rising delay on dRST is used.
Rising Falling
dCLK 31 31
dD 20 20
dRST 20 10

Using Delayed Inputs for Timing Checks

By default ModelSim performs timing checks on inputs specified in the timing check. If you
want timing checks performed on the delayed inputs, use the +delayed_timing_checks
argument with the vsim command.
Consider an example. This timing check:

$setuphold(posedge clk, posedge t, 20, -12, NOTIFIER,,, clk_dly, t_dly);

288 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Force and Release Statements in Verilog

reports a timing violation when posedge t occurs in the violation region:

When performed on the delayed inputs, the violation region between the delayed inputs is:

Although the check is performed on the delayed inputs, the timing check violation message is
adjusted to reference the undelayed inputs. Only the report time of the violation message is
noticeably different between the delayed and undelayed timing checks.

By far the greatest difference between these modes is evident when there are conditions on a
delayed check event because the condition is not implicitly delayed. Also, timing checks
specified without explicit delayed signals are delayed, if necessary, when they reference an
input that is delayed for a negative timing check limit.

Other simulators perform timing checks on the delayed inputs. To be compatible, ModelSim
supports both methods. By default timing checks are performed on the delayed inputs. This can
be disabled using the +no_autodtc switch.

Force and Release Statements in Verilog

The Verilog Language Reference Manual IEEE Std 1800-2009. section 10.6.2, states that the
left-hand side of a force statement cannot be a bit-select or part-select. Questa deviates from the
LRM standard by supporting forcing of bit-selects, part-selects, and field-selects in your source
code. The right-hand side of these force statements may not be a variable.
Related Topics
force [ModelSim SE Command Reference Manual]

Verilog-XL Compatible Simulator Arguments

The simulator arguments listed below are equivalent to Verilog-XL arguments and may ease the
porting of a design to ModelSim.
See the vsim command for a description of each argument.

ModelSim® SE User's Manual, v10.7 289

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog-XL Compatible Simulator Arguments

+alt_path_delays
-l <filename>
+maxdelays
+mindelays
+multisource_int_delays
+no_cancelled_e_msg
+no_neg_tchk
+no_notifier
+no_path_edge
+no_pulse_msg
-no_risefall_delaynets
+no_show_cancelled_e
+nosdfwarn
+nowarn<mnemonic>
+ntc_warn
+pulse_e/<percent>
+pulse_e_style_ondetect
+pulse_e_style_onevent
+pulse_int_e/<percent>
+pulse_int_r/<percent>
+pulse_r/<percent>
+sdf_nocheck_celltype
+sdf_verbose
+show_cancelled_e
+transport_int_delays
+transport_path_delays
+typdelays

290 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Using Escaped Identifiers

Using Escaped Identifiers

ModelSim recognizes and maintains Verilog escaped identifier syntax. Prior to version 6.3,
Verilog escaped identifiers were converted to VHDL-style extended identifiers with a backslash
at the end of the identifier. Verilog escaped identifiers then appeared as VHDL extended
identifiers in simulation output and in command line interface (CLI) commands.
For example, a Verilog escaped identifier like the following:

\/top/dut/03

had to be displayed as follows:

\/top/dut/03\

Starting in version 6.3, all object names inside the simulator appear identical to their names in
original HDL source files.

Sometimes, in mixed language designs, hierarchical identifiers might refer to both VHDL
extended identifiers and Verilog escaped identifiers in the same fullpath. For example, top/\
VHDL*ext\/\Vlog*ext /bottom (assuming the PathSeparator variable is set to '/'), or top.\
VHDL*ext\.\Vlog*ext .bottom (assuming the PathSeparator variable is set to '.')

Any fullpath that appears as user input to the simulator (such as on the vsim command line, in a
.do file, or on the vopt command line) should be composed of components with valid escaped
identifier syntax.

A modelsim.ini variable called GenerousIdentifierParsing can control parsing of identifiers. If

this variable is on (the variable is on by default: value = 1), either VHDL extended identifiers or
Verilog escaped identifier syntax may be used for objects of either language kind. This provides
backward compatibility with older .do files, which often contain pure VHDL extended identifier
syntax, even for escaped identifiers in Verilog design regions.

Note that SDF files are always parsed in “generous mode.” Signal Spy function arguments are
also parsed in “generous mode.”

On the vsim command line, the language-correct escaped identifier syntax should be used for
top-level module names. Using incorrect escape syntax on the command line works in the
incremental/debug flow, but not in the default optimized flow (see Optimizing Designs with
vopt). This limitation may be removed in a future release.

Tcl and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Tcl and Escaped Identifiers

In Tcl, the backslash is one of a number of characters that have a special meaning.

ModelSim® SE User's Manual, v10.7 291

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Using Escaped Identifiers

For example,

\n

creates a new line.

When a Tcl command is used in the command line interface, the TCL backslash should be
escaped by adding another backslash. For example:

force -freeze /top/ix/iy/\\yw\[1\]\\ 10 0, 01 {50 ns} -r 100

The Verilog identifier, in this example, is \yw[1]. Here, backslashes are used to escape the
square brackets ([]), which have a special meaning in Tcl.

For a more detailed description of special characters in Tcl and how backslashes should be used
with those characters, click Help > Tcl Syntax in the menu bar, or simply open the
<install_dir>/docs/tcl_help_html/TclCmd directory.

292 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Cell Libraries

Cell Libraries
Mentor Graphics has passed the Verilog test bench from the ASIC Council and achieved the
“Library Tested and Approved” designation from Si2 Labs. This test bench is designed to
ensure Verilog timing accuracy and functionality and is the first significant hurdle to complete
on the way to achieving full ASIC vendor support. As a consequence, many ASIC and FPGA
vendors’ Verilog cell libraries are compatible with ModelSim Verilog.
The cell models generally contain Verilog “specify blocks” that describe the path delays and
timing constraints for the cells. See Section 14 in the IEEE Std 1364-2005 for details on specify
blocks, and Section 15 for details on timing constraints. ModelSim Verilog fully implements
specify blocks and timing constraints as defined in IEEE Std 1364 along with some Verilog-XL
compatible extensions.

SDF Timing Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Delay Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Approximating Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

SDF Timing Annotation

ModelSim Verilog supports timing annotation from Standard Delay Format (SDF) files.
Related Topics
Standard Delay Format (SDF) Timing Annotation

ModelSim® SE User's Manual, v10.7 293

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Delay Modes

Delay Modes
Verilog models may contain both distributed delays and path delays. Distributed delays appear
on primitives, UDPs, and continuous assignments; path delays are the port-to-port delays
specified in specify blocks. These delays interact to determine the actual delay observed. Most
Verilog cells use path delays exclusively, with no distributed delays specified.
The following code shows a simple two-input AND gate cell, where no distributed delay is
specified for the AND primitive.

module and2(y, a, b);

input a, b;
output y;
and(y, a, b);
specify
(a => y) = 5;
(b => y) = 5;
endspecify
endmodule

For cells such as this, the actual delays observed on the module ports are taken from the path
delays. This is typical for most cells, though more complex cells may require nonzero
distributed delays to work properly.

Delay Modes and the Verilog Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Distributed Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Path Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Unit Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Zero Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Delay Modes and the Verilog Standard

The Verilog standard (LRM, IEEE Std 1364-2005) states that if a module contains both path
delays and distributed delays, then the larger of the two delays for each path shall be used
(Section 14.4).
This is the default behavior; however, you can specify alternate delay modes using compiler
directives and arguments to the vlog command:

• Distributed Delay Mode

• Path Delay Mode
• Unit Delay Mode
• Zero Delay Mode

294 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Delay Modes

Tip
Delay mode arguments to the vlog command take precedence over delay mode
directives in the source code.

Note that these directives and arguments are compatible with Verilog-XL. However, using these
modes results in behavior that is not clearly defined by the Verilog standard—the delays that are
set to zero can vary from one simulator to another (some simulators zero out only some delays).

Example 7-2 shows the 2-input AND gate cell using a different compiler directive to apply each
delay mode. In particular, ModelSim does the following:

• The `delay_mode_zero directive sets both the continuous assignment delay (assign #2 c
= b) and the primitive delay (and #3 (y, a,c) ) to zero.
• The `delay_mode_unit directive converts both of these nonzero delays (continuous
assignment and primitive) to 1.
Example 7-2. Delay Mode Directives in a Verilog Cell

The following instances of a 2-input AND gate cell (and2_1, and2_2, and2_3, and2_4) use
compiler directives to apply each delay mode.

ModelSim® SE User's Manual, v10.7 295

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Delay Modes

`delay_mode_zero
module and2_1(y, a, b);
input a, b;
output y;
wire c;
assign #2 c = b;

and #3(y, a, c);

specify
(a => y) = 5;
(b => y) = 5;
endspecify
endmodule

`delay_mode_unit
module and2_2(y, a, b);
input a, b;
output y;
wire c;
assign #2 c = b;

and #3(y, a, c);

specify
(a => y) = 5;
(b => y) = 5;
endspecify
endmodule

`delay_mode_distributed
module and2_3(y, a, b);
input a, b;
output y;
wire c;
assign #2 c = b;

and #3(y, a, c);

specify
(a => y) = 5;
(b => y) = 5;
endspecify
endmodule

`delay_mode_path
module and2_4(y, a, b);
input a, b;
output y;
wire c;
assign #2 c = b;

and #3(y, a, c);

specify
(a => y) = 5;
(b => y) = 5;
endspecify
endmodule

296 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Approximating Metastability

Distributed Delay Mode

In distributed delay mode, the specify path delays are ignored in favor of the distributed delays.
You can specify this delay mode with the +delay_mode_distributed compiler argument or the
`delay_mode_distributed compiler directive.

Path Delay Mode

In path delay mode, the distributed delays are set to zero in any module that contains a path
delay. You can specify this delay mode with the +delay_mode_path compiler argument or the
`delay_mode_path compiler directive.

Unit Delay Mode

In unit delay mode, the nonzero distributed delays are set to one unit of simulation resolution
(determined by the minimum time_precision argument in all ‘timescale directives in your
design or the value specified with the -t argument to vsim), and the specify path delays and
timing constraints are ignored. You can specify this delay mode with the +delay_mode_unit
compiler argument or the `delay_mode_unit compiler directive.

Zero Delay Mode

In zero delay mode, the distributed delays are set to zero, and the specify path delays and timing
constraints are ignored. You can specify this delay mode with the +delay_mode_zero compiler
argument or the `delay_mode_zero compiler directive.

Approximating Metastability
The ability to approximate metastability for Verilog gate-level designs is useful for simulating
synchronizer flops used to synchronize inputs from one clock domain to another. It allows a
known random state to be latched when timing between domains is violated.
Without this feature, you need to selectively use a version of the cell that does not generate
unknowns from timing check violations, or disable/force notifiers to override the timing check
violation toggle that introduced unknown states into the circuit.

Standard timing simulation Verilog cells have timing checks with notifier registers. The notifier
registers are inputs to user defined primitives (UDPs), which are coded to generate an unknown
output state when the notifier input changes.

During standard simulation, a timing check violation generates a violation message and the
notifier register value is toggled. The notifier register change causes an evaluation of the UDP
which generates an unknown state.

ModelSim® SE User's Manual, v10.7 297

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Approximating Metastability

During metastable approximation the timing check operates as normal. When a timing check
violation occurs, the notifier is toggled and the UDP is evaluated in a manner to approximate
metastability. The metastable UDP evaluation does not generate an unknown state, but rather a
random 1 or 0 logic state.

The metastability feature is implemented accepting a standard Verilog UDP description and
interpreting it in a non-standard manner as follows.

Standard UDP definition for a notifier evaluation:

table
// clk d r notif : state : next_state
? ? ? * ? x;

Metastable Approximation (non-standard Verilog):

table
// clk d r notif : state : next_state
? ? ? * ? b;

where b is randomly generated 0 or 1 state from a specified seed.

Usage
To allow metastable approximation simulation, Verilog cells must be optimized (vopt
command) with the proper optimization visibility .

• +acc=x[{+<selection>[.]}] — provides the necessary visibility to allow metastability

simulation of select Verilog cells.
To enable the metastable approximation during simulation, the following simulator command
line option (vsim command) must be specified:

• +notiftoggle01[+<seed>] — uses the metastable UDP evaluation of enabled cells in

simulation. Default seed value is 0.

298 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
SystemVerilog System Tasks and Functions

SystemVerilog System Tasks and Functions

The system tasks and functions listed in this section are built into the simulator, although some
designs depend on user-defined system tasks implemented with the various programming and
procedural interfaces.
If the simulator issues warnings regarding undefined system tasks or functions, then it is likely
that these tasks or functions are defined by a interface application that must be loaded by the
simulator.

ModelSim supports SystemVerilog system tasks and functions as follows:

• Most system tasks and functions defined in SystemVerilog IEEE Std 1800-2012
• Several system tasks and functions that are specific to ModelSim
• Several non-standard, Verilog-XL system tasks
IEEE Std 1800-2012 System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using the $typename Data Query Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Using the $coverage_* System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Using the $coverage_save System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Simulator-Specific System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Task and Function Names Without Round Braces ‘()’ . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Verilog-XL Compatible System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
String Class Methods for Matching Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

IEEE Std 1800-2012 System Tasks and Functions

The following system tasks and functions are supported by ModelSim and are described more
completely in the Language Reference Manual (LRM) for SystemVerilog, IEEE Std
1800-2012.
Note
You can use the change command to modify local variables in Verilog and SystemVerilog
tasks and functions.

Utility System Tasks and Functions

Table 7-3. Utility System Tasks and Functions
Simulator control Simulation time Timescale tasks Data query
tasks functions functions
$finish $realtime $printtimescale $bits

ModelSim® SE User's Manual, v10.7 299

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
IEEE Std 1800-2012 System Tasks and Functions

Table 7-3. Utility System Tasks and Functions (cont.)

Simulator control Simulation time Timescale tasks Data query
tasks functions functions
$stop $stime $timeformat $isunbounded
$exit $time $typename

Table 7-4. Utility System Functions

Conversion Array querying Bit vector system
functions functions functions
$bitstoreal $dimensions countbits
$bitstoshortreal $left countones
$realtobits $right $onehot
$shortrealtobits $low $onehot0
$itor $high $isunknown
$rtoi $increment
$signed $size
$unsigned
$cast

Table 7-5. Utility System Math Functions

Math Functions
$clog2 $floor $acos $cosh
$ln $ceil $atan $tanh
$log10 $sin $atan2 $asinh
$exp $cos $hypot $acosh
$sqrt $tan $sinh $atanh
$pow $asin

Table 7-6. Utility System Elaboration Tasks and Coverage Functions

Elaboration tasks Coverage control
functions
$fatal $coverage_control
$error $coverage_get
$warning $coverage_get_max

300 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
IEEE Std 1800-2012 System Tasks and Functions

Table 7-6. Utility System Elaboration Tasks and Coverage Functions (cont.)
Elaboration tasks Coverage control
functions
$info $coverage merge
$coverage_save
$get_coverage
$load_coverage_db
$set_coverage_db_name

Table 7-7. Utility System Severity and Assertion Tasks

Severity tasks Assertion control tasks
$fatal $asserton $assertoff
$error $assertkill $assertcontrol
$warning $assertpasson assertpassoff
$info $assertfailon assertfailoff
$assertnonvacuouson $assertvacuousoff

Table 7-8. Utility System Analysis Tasks and Functions

Probabilistic Stochastic analysis PLA modeling tasks Miscellaneous tasks
distribution tasks and functions and functions
functions
$dist_chi_square $q_add $async$and$array $system
$dist_erlang $q_exam $async$nand$array
$dist_exponential $q_full $async$or$array
$dist_normal $q_initialize $async$nor$array
$dist_poisson $q_remove $async$and$plane
$dist_t $async$nand$plane
$dist_uniform $async$or$plane
$random $async$nor$plane
$sync$and$array
$sync$nand$array
$sync$or$array
$sync$nor$array
$sync$and$plane

ModelSim® SE User's Manual, v10.7 301

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
IEEE Std 1800-2012 System Tasks and Functions

Table 7-8. Utility System Analysis Tasks and Functions (cont.)

Probabilistic Stochastic analysis PLA modeling tasks Miscellaneous tasks
distribution tasks and functions and functions
functions
$sync$nand$plane
$sync$or$plane
$sync$nor$plane

Input/Output System Tasks and Functions

Table 7-9. Input/Output System Tasks and Functions
Display tasks Value change dump
(VCD) file tasks
$display $dumpall
$displayb $dumpfile
$displayh $dumpflush
$displayo $dumplimit
$monitor $dumpoff
$monitorb $dumpon
$monitorh $dumpvars
$monitoro $dumpportson
$monitoroff $dumpportsoff
$monitoron $dumpportsall
$strobe $dumpportsflush
$strobeb $dumpports
$strobeh $dumpportslimit
$strobeo
$write
$writeb
$writeh
$writeo

302 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
IEEE Std 1800-2012 System Tasks and Functions

Table 7-10. Input/Output System Memory and Argument Tasks

Memory load tasks Memory dump tasks Command line input
$readmemb $writememb $test$plusargs
$readmemh $writememh $value$plusargs

Table 7-11. Input/Output System File I/O Tasks

File I/O tasks
$fclose $fmonitoro $fwriteo
$fdisplay $fopen $rewind
$fdisplayb $fread $sdf_annotate
$fdisplayh $fscanf $sformatf
$fdisplayo $fseek $sscanf
$feof $fstrobe $swrite
$ferror $fstrobeb $swriteb
$fflush $fstrobeh $swriteh
$fgetc $fstrobeo $swriteo
$fgets $ftell $ungetc
$fmonitor $fwrite
$fmonitorb $fwriteb
$fmonitorh $fwriteh

Other System Tasks and Functions

Table 7-12. Other System Tasks and Functions
Timing check tasks Random number functions Other functions
$hold $urandom $root
$nochange $urandom_range $unit
$period
$recovery
$setup
$setuphold
$skew

ModelSim® SE User's Manual, v10.7 303

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Using the $typename Data Query Function

Table 7-12. Other System Tasks and Functions (cont.)

Timing check tasks Random number functions Other functions
$width1
$removal
$recrem
1. Verilog-XL ignores the threshold argument even though it is part of the Verilog spec.
ModelSim does not ignore this argument. Be careful that you do not set the threshold
argument greater-than-or-equal to the limit argument as that essentially disables the
$width check. Also, note that you cannot override the threshold argument by using SDF
annotation.

Using the $typename Data Query Function

The type name string returned by $typename() will not include class, struct and enum members,
nor any class extensions.
This default behavior can be overwritten using any of the following predefined macros as the
optional second argument to $typename():

• `mtiTypenameExpandSuper — Extensions are included in type name.

• `mtiTypenameExpandMembers — Class, struct and enum members are included.
• `mtiTypenameExpandAll — Members and extensions are both included.

Example Usage
$typename(a, `mtiTypenameExpandAll);

The various form of $typename() output for a parametrized class "vector" which extends
another parametrized class "vector_base", both of which are defined in the module scope
"typename_parameterized_class":

• $typename(a) will return:

class typename_parameterized_class/vector #(10, reg, 0)
• $typename(a, `mtiTypenameExpandSuper) will return:
class typename_parameterized_class/vector #(10, reg, 0) extends class
typename_parameterized_class/vector_base #(reg)
• $typename(a, `mtiTypenameExpandMembers) will return:
class typename_parameterized_class/vector #(10, reg, 0){reg b; reg$[9:0] a;}

304 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Using the $coverage_* System Functions

• $typename(a, `mtiTypenameExpandAll) will return:

class typename_parameterized_class/vector #(10, reg, 0){reg b; reg$[9:0] a;} extends
class typename_parameterized_class/vector_base #(reg){reg b;}
Old behavior of $typename(a):

• class {reg b;reg$[9:0] a;}/typename_parameterized_class/vector::vector #( 10, logic, 0)

extends class {reg b;}/typename_parameterized_class/vector_base::vector_base #(logic)

Using the $coverage_* System Functions

The $coverage_* functions allow SystemVerilog code to control and query coverage
information, including assertions.
The full description and specification for these functions is found in section 40.3 of the
SystemVerilog LRM 1800-2012.

Restrictions and Notes

Tip
THE COVERAGE NUMBERS THAT $coverage_get_max(...) and $coverage_get(...)
RETURN WILL OFTEN NOT AGREE WITH THOSE RETURNED BY THE ModelSim
REPORT FUNCTIONS. This is as designed. See below for details.

• The coverage numbers reported by ModelSim differ from the SV system functions due
the fact that the numbers inModelSim reports:
o reflect merge/roll-up coverage numbers (that is, 9 instances of the same assertion is
reported as 1 assertion). The $coverage_* system functions count each instance
separately (that is, 9 assertions).
o ignore recursion when the -du argument is used. The $coverage_* system functions
allow recursion with filtering on a design unit.
• The "$coverage_merge(...)" system function is unsupported: if encountered in the code,
ModelSim issues an 'unsupported' warning message and is ignored.
• The "$coverage_save(...)" system function remains unaltered from its current behavior.
See, Using the $coverage_save System Function.
• The coverage control `SV_COV_CHECK is supported. Currently, the
"$coverage_control(`SV_COV_RESET,...)",
"$coverage_control(`SV_COV_START,...)" and
"$coverage_control(`SV_COV_STOP,...)" system functions are not: they issue an
'unsupported' warning message and otherwise are ignored.

ModelSim® SE User's Manual, v10.7 305

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Using the $coverage_* System Functions

• Currently, only the `SV_COV_ASSERTION coverage type identification is supported.

The `SV_COV_FSM_STATE, `SV_COV_STATEMENT and `SV_COV_TOGGLE
coverage type identifications are currently unsupported.

Example Usage
Check all assertion instances in the entire design to verify one or more has coverage:

if ($coverage_control(`SV_COV_CHECK, `SV_COV_ASSERTION, `SV_COV_HIER,

$root) == `SV_COV_OK) ...

Check all assertions on all instances of the module DUT to verify one or more has coverage.

if ($coverage_control(`SV_COV_CHECK, `SV_COV_ASSERTION, `SV_COV_MODULE,

"DUT") == `SV_COV_OK) ...

306 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Using the $coverage_save System Function

Using the $coverage_save System Function

Implementation of the $coverage_save() SystemVerilog system function is compliant with the
IEEE1800 standard. Existing SV calls to this function that worked in ModelSim version 10.0
and earlier will not work in version 10.1 and higher. They will fail compilation checks. The
recommended action for pre-10.1 designs where the former behavior is acceptable, is to migrate
to the $coverage_save_mti() system call to retain the exact pre-10.1 behavior .
The post 10.1 behavior of $coverage_save() is significantly different from the original behavior
because the original implementation pre-dated the standardization process. An alternate
workaround is provided for customers for whom source changes are not possible: use the vsim
-usenonstdcoveragesavesysf switch to replace the implementation of the built-in system
function with the non-standard variant. The action of this switch is global and thus affects all
calls to $coverage_save(). As such it is not recommended as a long-term solution.

See $coverage_save_mti.

Using the $clog2 Math Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Using the $clog2 Math Function

The IEEE 1800-2012 LRM does not clearly indicate what should happen when the argument for
the $clog2() function contains 'X' or 'Z' values.
Therefore, ModelSim treats any bit position containing an 'X' within a value similar to a '1'.
ModelSim treats any bit with the value of 'Z' as a '0' in that bit position.

ModelSim® SE User's Manual, v10.7 307

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Using the $coverage_save System Function

For example:

========
clog2.sv
========
module clog2;
var logic [95:0] i;
initial begin
i = 1'b0;
$display("$clog2(%h) ==> %h", i, $clog2(i));

i = 40'h3X_XXXX_XXXX;
$display("$clog2(%h) ==> %h", i, $clog2(i));

i = 40'hX3_XXXX_XXXX;
$display("$clog2(%h) ==> %h", i, $clog2(i));

i = 40'h3Z_ZZZZ_ZZZZ;
$display("$clog2(%h) ==> %h", i, $clog2(i));

i = 40'hZ3_ZZZZ_ZZZZ;
$display("$clog2(%h) ==> %h", i, $clog2(i));
end
endmodule

================
output for clog2
================
# $clog2(000000000000000000000000) ==> 00000000
# $clog2(000000000000003xxxxxxxxx) ==> 00000026
# $clog2(00000000000000x3xxxxxxxx) ==> 00000028
# $clog2(000000000000003zzzzzzzzz) ==> 00000026
# $clog2(00000000000000z3zzzzzzzz) ==> 00000022

308 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

Simulator-Specific System Tasks and Functions

The following table lists system tasks and functions that are specific to ModelSim. They are not
included in the IEEE Std 1364, nor are they likely supported in other simulators. Their use may
limit the portability of your code.

Table 7-13. Simulator-Specific Verilog System Tasks and Functions

$disable_signal_spy $psprintf()
$enable_signal_spy $sdf_done
$init_signal_driver $signal_force
$init_signal_spy $signal_release
$messagelog $stacktrace()
$coverage_save_mti $wlfdumpvars()
$get_initial_random_seed

$coverage_save_mti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
$get_initial_random_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
$messagelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
$psprintf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
$sdf_done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
$stacktrace() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
$wlfdumpvars() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

ModelSim® SE User's Manual, v10.7 309

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$coverage_save_mti
The $coverage_save_mti() system function saves only Code Coverage information to a file
during a batch run that typically would terminate with the $finish call.
Syntax
$coverage_save_mti(<filename>, [<instancepath>], [<xml_output>]);
Arguments
none
Description
The $coverage_save() system function is defined in IEEE Std 1800, as explained above in
Using the $coverage_save System Function. The pre-standardization behavior is retained for
backwards-compatibility by the $coverage_save_mti() system function.

The $coverage_save_mti() system function returns a “0” to indicate that the coverage
information was saved successfully or a “-1” to indicate an error (unable to open file, instance
name not found, and so forth.)

If you do not specify <instancepath>, ModelSim saves all coverage data in the current design to
the specified file. If you do specify <instancepath>, ModelSim saves data on that instance, and
all instances below it (recursively), to the specified file.

If set to 1, the [<xml_output>] argument specifies that the output be saved in XML format.

See Code Coverage for more information on Code Coverage.

310 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$get_initial_random_seed
The $get_initial_random_seed system function returns the value of the initial random seed.
Note
You specify this random seed value by using the -sv_seed argument of the vsim command.

Syntax
$get_initial_random_seed;
Arguments
none

ModelSim® SE User's Manual, v10.7 311

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$messagelog
The $messagelog system task allows you to create a message using text and specifiers.
Syntax
$messagelog({"<message>", <value>...}[, ...]);
Arguments
• Task arguments:
o <message> — Your message, enclosed in quotation marks ("), using text and
specifiers to define the output.
o <value> — A scope, object, or literal value that corresponds to the specifiers in the
<message>. You must specify one <value> for each specifier in the <message>.
Specifiers
• Task arguments:
The $messagelog task supports all specifiers available with the $display system task. For
more information about $display, refer to section 17.1 of the IEEE std 1364-2005.
The following specifiers are specific to $messagelog.
Note
The format of these custom specifiers differ from the $display specifiers.
Specifically, “%:” denotes a $messagelog specifier and the letter denotes the type of
specifier.

• %:C — Group/Category
A string argument, enclosed in quotation marks ("). This attribute defines a group or
category used by the message system. If you do not specify %:C, the message system logs
User as the default.
• %:F — Filename
A string argument specifying a simple filename, relative path to a filename, or a full path to
a filename. In the case of a simple filename or relative path to a filename, the simulator
accepts what you specify in the message output, but internally it uses the current directory to
complete these paths to form a full path—this allows the message viewer to link to the
specified file.
If you do not include %:F, the simulator automatically logs the value of the filename in
which the $messagelog is called.
If you do include %:R, %:F, or %:L, or a combination of any two of these, the simulator
does not automatically log values for the undefined specifier(s).

312 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

• %:I — Message ID
A string argument. The Message Viewer displays this value in the ID column. This attribute
is not used internally, therefore you do not need to be concerned about uniqueness or
conflict with other message IDs.
• %:L — Line number
An integer argument.
If you do not include %:L, the simulator automatically logs the value of the line number on
which the $messagelog is called.
If you do include %:R, %:F, or %:L, or a combination of any two of these, the simulator
does not automatically log values for the undefined specifier(s).
• %:O — Object/Signal Name
A hierarchical reference to a variable or net, such as sig1 or top.sigx[0]. You can specify
multiple %:O for each $messagelog, which effectively forms a list of attributes of that kind,
for example:
$messagelog("The signals are %:O, %:O, and %:O.",
sig1, top.sigx[0], ar [3].sig);

• %:R — Instance/Region name

A hierarchical reference to a scope, such as top.sub1 or sub1. You can also specify a string
argument, such as “top.mychild”, where the identifier inside the quotes does not need to
correlate with an actual scope, it can be an artificial scope.
If you do not include %:R, the simulator automatically logs the instance or region in which
the $messagelog is called.
If you do include %:R, %:F, or %:L, or a combination of any two of these, the simulator
does not automatically log values for the undefined specifier(s).
• %:S — Severity Level
A case-insensitive string argument, enclosed in quotes ("), that is one of the following:
Note — This is the default if you do not specify %:S
Warning
Error
Fatal
Info — The error message system recognizes this as a Note
Message — The error message system recognizes this as a Note
• %:V — Verbosity Rating
An integer argument, where the default is zero (0). The verbosity rating allows you to
specify a field you can use to sort or filter messages in the Message Viewer. In most cases
you specify that this attribute is not printed, using the tilde (~) character.

ModelSim® SE User's Manual, v10.7 313

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

Description
• Non-printing attributes (~) — You can specify that an attribute value is not to be printed
in the transcripted message by placing the tilde (~) character after the percent (%)
character, for example:
$messagelog("%:~S Do not print the Severity Level", "Warning");

However, the value of %:S is logged for use in the Message Viewer.
• Logging of simulation time — For each call to $messagelog, the simulation time is
logged, however the simulation time is not considered an attribute of the message
system. This time is available in the Message Viewer.
• Minimum field-width specifiers — are accepted before each specifier character, for
example:
%:0I
%:10I

• Left-right justification specifier (-) — is accepted as it is for $display.

• Macros — You can use the macros ‘__LINE__ (returns line number information) and
‘__FILE__ (returns filename information) when creating your $messagelog tasks. For
example:
module top;

function void wrapper(string file, int line);

$messagelog("Hello: The caller was at %:F,%:0L", file, line);
endfunction

initial begin
wrapper(`__FILE__, `__LINE__);
wrapper(`__FILE__, `__LINE__);
end

endmodule

which would produce the following output

# Hello: The caller was at test.sv,7
# Hello: The caller was at test.sv,8

Examples
• The following $messagelog task:
$messagelog("hello world");

transcripts the message:

hello world

while logging all default attributes, but does not log a category.

314 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

• The following $messagelog task:

$messagelog("%:~S%0t: PCI-X burst read started in transactor %:R",
"Note", $time - 50, top.sysfixture.pcix);

transcripts the message:

150: PCI-X burst read started in transactor top.sysfixture.pcix

while silently logging the severity level of “Note”, and uses a direct reference to the
Verilog scope for the %:R specifier, and does not log any attributes for %:F (filename)
or %:L (line number).
• The following $messagelog task:
$messagelog("%:~V%:S %:C-%:I,%:L: Unexpected AHB interrupt received
in transactor %:R", 1, "Error", "AHB", "UNEXPINTRPT", `__LINE__,
ahbtop.c190);

transcripts the message:

** Error: AHB-UNEXPINTRPT,238: Unexpected AHB interrupt received in
transactor ahbtop.c190

where the verbosity level (%:V) is “1”, severity level (%:S) is “Error”, the category
(%:C) is “AHB”, and the message identifier (%:I) is “UNEXPINTRPT”. There is a
direct reference for the region (%:R) and the macro ‘__LINE__ is used for line number
(%:L), resulting in no attribute logged for %:F (filename).

ModelSim® SE User's Manual, v10.7 315

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$psprintf()
The $psprintf() system function behaves like the $sformat() file I/O task except that the string
result is passed back to the user as the function return value for $psprintf(), not placed in the
first argument as for $sformat(). Thus $psprintf() can be used where a string is valid. Note that
at this time, unlike other system tasks and functions, $psprintf() cannot be overridden by a user-
defined system function in the PLI.
Syntax
$psprintf();
Arguments
none

316 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$sdf_done
This task is a “cleanup” function that removes internal buffers, called MIPDs, that have a delay
value of zero. These MIPDs are inserted in response to the -v2k_int_delay argument for the
vsim command. In general, the simulator automatically removes all zero delay MIPDs.
However, if you have $sdf_annotate() calls in your design that are not getting executed, the
zero-delay MIPDs are not removed. Adding the $sdf_done task after your last $sdf_annotate()
removes any zero-delay MIPDs that have been created.
Syntax
$sdf_done;
Arguments
none

ModelSim® SE User's Manual, v10.7 317

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulator-Specific System Tasks and Functions

$stacktrace()
Produces a call stack trace back from the point where the call is made. A successful
$stacktrace() call returns a non-zero value, a failed call returns zero (0).
Syntax
$stacktrace();
Arguments
<n> — Any positive integer to specify the depth of the stack trace frames returned. Default is
100.
Description
You can specify a different default depth of the stack frames returned by setting the
StackTraceDepth modelsim.ini variable.

Examples
Example 1—output from $stacktrace
# Call Stack:
# Function class_A::f1 src/pack.sv(10)
# Task class_A::t1 src/pack.sv(13)
# Task class_A::t2 src/pack.sv(17)
# Module top src/test5.sv(35)

Example 2—output from $stacktrace with dpi call in between.

# Call Stack:
# Function foo2 src/pack2.v(14)
# C Function bar2
# Function foo src/pack2.v(23)
# Module test src/test.sv(26)

318 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Task and Function Names Without Round Braces ‘()’

$wlfdumpvars()
This Verilog system task specifies variables to be logged in the current simulation's WLF file
(default, vsim.wlf) and is called from within a Verilog design. It is equivalent to the Verilog
system task $dumpvars, except it dumps values to the current simulation's WLF file instead of
a VCD file. While it can not be called directly from within VHDL, it can log VHDL variables
contained under a Verilog scope that is referenced by $wlfdumpvars. The modelsim.ini
variable WildcardFilter will be used to filter types when a scope is logged by $wlfdumpvars.
Multiple scopes and variables are specified as a comma separated list.
Syntax
$wlfdumpvars(<levels>, {<scope> | <variable>}[, <scope> | <variable>]);
Arguments
• <levels>
Specifies the number of hierarchical levels to log, if a scope is specified. Specified as a non-
negative integer.
• <scope>
Specifies a Verilog pathname to a scope, under which all variables are logged.
• <variable>
Specifies a variable to log.
Examples
Log variable "addr_bus" in the current scope

$wlfdumpvars(0, addr_bus);

Log all variables within the scope "alu", and in any submodules

$wlfdumpvars(2, alu);

Log all variables within the scope regfile

$wlfdumpvars(1, $root.top.alu.regfile)

Task and Function Names Without Round Braces

‘()’
Strict compliance with the Language Reference Manual IEEE Std 1364 requires that all
hierarchical task and function names have round braces “()” following the name to call the task
or function. In ModelSim 10.3 and later you may use hierarchical task and function names
without round braces.

ModelSim® SE User's Manual, v10.7 319

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Task and Function Names Without Round Braces ‘()’

The compiler will use the following rules for interpreting task and function names without
round braces:

1. Non class tasks/functions (static or non static) will be interpreted as a search in the scope
of the function and not a function call.
2. Non-static class methods will be treated as a function call.
3. Static class methods will be treated as a lookup in the function scope.
4. Once a function call is made for a hierarchical name, all subsequent function names will
be treated as function calls whether the type of function is static or non-static.

Examples
module top;
class CTest1 ;
string s;
static function CTest1 g();
static CTest1 s = new();
CTest1 t = new();
$display ("hello_static" ) ;
return t;
endfunction
function CTest1 f();
static string s;
CTest1 t = new();
$display ("hello_auto" ) ;
return t;
endfunction
endclass;
CTest1 t1 = new();

initial t1.g.s.f.g.s="hello";

endmodule

In the above code, the dotted name:

t1.g.s.f.g.s

is interpreted by the fourth rule above as:

t1.g.s.f().g().s

The first g is treated as a scope lookup, since it is a static function. Since f is an automatic
function, it is treated as a function call. The next g is treated as a function call g() since
according to rule 4, once an automatic function gets called, all subsequent names in the list
which are Function names, whether static or automatic, are treated as function calls.

320 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog-XL Compatible System Tasks and Functions

Verilog-XL Compatible System Tasks and

Functions
ModelSim supports a number of Verilog-XL specific system tasks and functions.
Supported Tasks and Functions Mentioned in IEEE Std 1364 . . . . . . . . . . . . . . . . . . . . 321
Supported Tasks and Functions Not Described in IEEE Std 1364 . . . . . . . . . . . . . . . . . 321
Extensions to Supported System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Unsupported Verilog-XL System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Supported Tasks and Functions Mentioned in IEEE Std

1364
The following supported system tasks and functions, though not part of the IEEE standard, are
described in an annex of the IEEE Std 1364.
$countdrivers
$getpattern
$sreadmemb
$sreadmemh

Supported Tasks and Functions Not Described in IEEE

Std 1364
The following system tasks are also provided for compatibility with Verilog-XL, though they
are not described in the IEEE Std 1364.
$deposit(variable, value);

This system task sets a Verilog net to the specified value. variable is the net to be changed;
value is the new value for the net. The value remains until there is a subsequent driver
transaction or another $deposit task for the same net. This system task operates identically to the
ModelSim force -deposit command.

$disable_warnings("<keyword>"[,<module_instance>...]);

This system task instructs ModelSim to disable warnings about timing check violations or
triregs that acquire a value of ‘X’ due to charge decay. <keyword> may be decay or timing.
You can specify one or more module instance names. If you do not specify a module instance,
ModelSim disables warnings for the entire simulation.

$enable_warnings("<keyword>"[,<module_instance>...]);

This system task enables warnings about timing check violations or triregs that acquire a value
of ‘X’ due to charge decay. <keyword> may be decay or timing. You can specify one or more

ModelSim® SE User's Manual, v10.7 321

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog-XL Compatible System Tasks and Functions

module instance names. If you do not specify a module_instance, ModelSim enables warnings
for the entire simulation.

$system("command");

This system function takes a literal string argument, executes the specified operating system
command, and displays the status of the underlying OS process. Double quotes are required for
the OS command. For example, to list the contents of the working directory on Unix:

$system("ls -l");

Return value of the $system function is a 32-bit integer that is set to the exit status code of the
underlying OS process.

Note
There is a known issue in the return value of this system function on the win32 platform. If
the OS command is built with a cygwin compiler, the exit status code may not be reported
correctly when an exception is thrown, and thus the return code may be wrong. The workaround
is to avoid building the application using cygwin or to use the switch
-mno-cygwin in cygwin on the gcc command line.

$systemf(list_of_args)

This system function can take any number of arguments. The list_of_args is treated exactly the
same as with the $display() function. The OS command that runs is the final output from
$display() given the same list_of_args. Return value of the $systemf function is a 32-bit integer
that is set to the exit status code of the underlying OS process.

Note
There is a known issue in the return value of this system function on the win32 platform. If
the OS command is built with a cygwin compiler, the exit status code may not be reported
correctly when an exception is thrown, and thus the return code may be wrong. The workaround
is to avoid building the application using cygwin or to use the switch
-mno-cygwin in cygwin on the gcc command line.

$test$plusargs("plus argument")

This system function tests for the presence of a specific plus argument on the simulator's
command line. It returns 1 if the plus argument is present; otherwise, it returns 0. For example,
to test for +verbose:

if ($test$plusargs("verbose"))
$display("Executing cycle 1");

322 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog-XL Compatible System Tasks and Functions

Extensions to Supported System Tasks

Additional functionality has been added to the $fopen, $setuphold, and $recrem system tasks.
New Directory Path With $fopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Negative Timing Checks With $setuphold and $recrem . . . . . . . . . . . . . . . . . . . . . . . . . 323

New Directory Path With $fopen

The $fopen systemtask has been extended to create a new directory path if the path does not
currently exist.
You must set the CreateDirForFileAccess modelsim.ini variable to '1' to enable this feature. For
example: your current directory contains the directory “dir_1 with no other directories below it
and the CreateDirForFileAccess variable is set to “1”. Executing the following line of code:

fileno = $fopen("dir_1/nodir_2/nodir_3/testfile", "w");

creates the directory path nodir_2/nodir_3 and opens the file “testfile” in write mode.

Negative Timing Checks With $setuphold and $recrem

The $setuphold and $recrem system tasks have been extended to provide additional
functionality for negative timing constraints and an alternate method of conditioning, as in
Verilog-XL.
Related Topics
Commands Supporting Negative Timing Check Limits

Unsupported Verilog-XL System Tasks

The following system tasks are Verilog-XL system tasks that are not implemented in ModelSim
Verilog, but have equivalent simulator commands.
$input("filename")

This system task reads commands from the specified filename. The equivalent simulator
command is do <filename>.

$list[(hierarchical_name)]

This system task lists the source code for the specified scope. The equivalent functionality is
provided by selecting a module in the Structure (sim) window. The corresponding source code
is displayed in a Source window.

$reset

ModelSim® SE User's Manual, v10.7 323

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
String Class Methods for Matching Patterns

This system task resets the simulation back to its time 0 state. The equivalent simulator
command is restart.

$restart("filename")

This system task sets the simulation to the state specified by filename, saved in a previous call
to $save. The equivalent simulator command is restore <filename>.

$save("filename")

This system task saves the current simulation state to the file specified by filename. The
equivalent simulator command is checkpoint <filename>.

$scope(hierarchical_name)

This system task sets the interactive scope to the scope specified by hierarchical_name. The
equivalent simulator command is environment <pathname>.

$showscopes

This system task displays a list of scopes defined in the current interactive scope. The
equivalent simulator command is show.

$showvars

This system task displays a list of registers and nets defined in the current interactive scope. The
equivalent simulator command is show.

String Class Methods for Matching Patterns

This group of functions are not a part of the SystemVerilog LRM. However, the ModelSim
simulator supports their use, unless you inlcude the -pedanticerrors argument to vlog, in which
case you will receive an error.
The regular expressions for these functions use Perl pattern syntax.

• search() — This function searches for a pattern in the string and returns the integer index
to the beginning of the pattern.
search(string pattern);

where pattern must be a string. For example:

integer i;
string str = "ABCDEFGHIJKLM";
i = str.search("HIJ");
printf("%d \n", i);

results in printing out “8”.

324 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
String Class Methods for Matching Patterns

• match () — This function processes a regular expression pattern match, returning a 1 if

the expression is found or a 0 if the expression is not found or if there is an error in the
regular expression.
match (string pattern);

where pattern must be a regular expression. For example:

integer i;
string str;
str = "ABCDEFGHIJKLM";
i = str.match("CDE”);

results assigning the value 1 to integer i because the pattern CDE exists within string str.
• prematch() — This function returns the string before a match, based on the result of the
last match() function call.
prematch();

Based on the example for match(), the following:

str1 = str.prematch();

would be assigned the string “AB”

• postmatch() — This function returns the string after a match, based on the result of the
last match() function call.
postmatch();

Based on the example for match(), the following:

str2 = str.postmatch();

would be assigned the string “FGHIJKLM”

• thismatch() — This function returns matched string, based on the result of the last
match() function call.
thismatch();

Based on the example for match(), the following:

str3 = str.thismatch();

would be assigned the string “CDE”

• backref() — This function returns matched patterns, based on the last match() function
call.
backref(integer index);

ModelSim® SE User's Manual, v10.7 325

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
String Class Methods for Matching Patterns

where index is the integer number of the expression being matched (indexing starts at 0).
For example:
integer i;
string str, patt, str1, str2;
str = "12345ABCDE"
patt = "([0-9]+) ([a-zA-Z .]+)";
i = str.match(patt);
str1 = str.backref(0);
str2 = str.backref(1);

results in assigning the value “12345” to the string str1 because of the match to the
expression “[0-9]+”. It also results in assigning the value “ABCDE” to the string str2
because of the match to the expression “[a-zA-Z .]+”.
You can specify any number of additional Perl expressions in the definition of patt and
then call them using sequential index numbers.

326 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Compiler Directives

Compiler Directives
ModelSim SystemVerilog supports all of the compiler directives defined in the IEEE Std 1800,
some Verilog-XL compiler directives, and some that are proprietary.
Many of the compiler directives (such as `timescale) take effect at the point they are defined in
the source code and stay in effect until the directive is redefined or until it is reset to its default
by a `resetall directive. The effect of compiler directives spans source files, so the order of
source files on the compilation command line could be significant. For example, if you have a
file that defines some common macros for the entire design, then you might need to place it first
in the list of files to be compiled.

The `resetall directive affects only the following directives by resetting them back to their
default settings (this information is not provided in the IEEE Std 1800):

`celldefine
‘default_decay_time
`default_nettype
`delay_mode_distributed
`delay_mode_path
`delay_mode_unit
`delay_mode_zero
`protect
`timescale
`unconnected_drive
`uselib

ModelSim Verilog implicitly defines the following macros:

MODEL_TECH
QUESTA
SV_COV_ASSERTION
SV_COV_CHECK
SV_COV_ERROR
SV_COV_FSM_STATE
SV_COV_HIER
SV_COV_MODULE
SV_COV_NOCOV
SV_COV_OK
SV_COV_OVERFLOW
SV_COV_PARTIAL
SV_COV_RESET
SV_COV_START
SV_COV_STATEMENT
SV_COV_STOP
SV_COV_TOGGLE
VLOG_DEF
mtiTypenameExpandAll
mtiTypenameExpandMembers
mtiTypenameExpandSuper

IEEE Std 1364 Compiler Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Compiler Directives for vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

ModelSim® SE User's Manual, v10.7 327

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
IEEE Std 1364 Compiler Directives

Verilog-XL Compatible Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

IEEE Std 1364 Compiler Directives

The following compiler directives are described in detail in the IEEE Std 1364.
`celldefine
`default_nettype
`define
`else
`elsif
`endcelldefine
`endif
`ifdef
‘ifndef
`include
‘line
`nounconnected_drive
`resetall
`timescale
`unconnected_drive
`undef

Compiler Directives for vlog

These vlog directives are specific to ModelSim and are not compatible with other simulators.
`protect ... `endprotect

This directive pair allows you to encrypt selected regions of your source code. The code in
`protect regions has all debug information stripped out. This behaves exactly as if using:

vlog -nodebug=ports+pli

except that it applies to selected regions of code rather than the whole file. This enables usage
scenarios such as making module ports, parameters, and specify blocks publicly visible while
keeping the implementation private.

The `protect directive is ignored by default unless you use the +protect argument to vlog. Once
compiled, the original source file is copied to a new file in the current work directory. The name
of the new file is the same as the original file with a “p” appended to the suffix. For example,
“top.v” is copied to “top.vp”. This new file can be delivered and used as a replacement for the
original source file.

A usage scenario might be that a vendor uses the `protect / `endprotect directives on a module or
a portion of a module in a file named encrypt.v. They compile it with vlog +protect encrypt.v to
produce a new file named encrypt.vp. You can compile encrypt.vp just like any other verilog
file. The protection is not compatible among different simulators, so the vendor must ship you a
different encrypt.vp than they ship to someone who uses a different simulator.

328 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Compiler Directives for vlog

You can use vlog +protect=<filename> to create an encrypted output file, with the designated
filename, in the current directory (not in the work directory, as in the default case where
[=<filename>] is not specified). For example:

vlog test.v +protect=test.vp

If the filename is specified in this manner, all source files on the command line are concatenated
together into a single output file. Any `include files are also inserted into the output file.

`protect and `endprotect directives cannot be nested.

If errors are detected in a protected region, the error message always reports the first line of the
protected block.

`include

If any `include directives occur within a protected region, the compiler generates a copy of the
include file with a .vp suffix and protects the entire contents of the include file. However, when
you use vlog +protect to generate encrypted files, the original source files must all be complete
Verilog modules or packages. Compiler errors result if you attempt to perform compilation of a
set of parameter declarations within a module.

You can avoid such errors by creating a dummy module that includes the parameter
declarations. For example, if you have a file that contains your parameter declarations and a file
that uses those parameters, you can do the following:

module dummy;

`protect
`include "params.v" // contains various parameters
`include "tasks.v" // uses parameters defined in params.v
`endprotect

endmodule

Then, compile the dummy module with the +protect switch to generate an encrypted output file
with no compile errors.

vlog +protect dummy

After compilation, the work library contains encrypted versions of params.v and tasts.v, called
params.vp and tasks.vp. You may then copy these encrypted files out of the work directory to
more convenient locations. These encrypted files can be included within your design files; for
example:

module main
`include "params.vp"
`include "tasks.vp"
...

ModelSim® SE User's Manual, v10.7 329

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Directives

Though other simulators have a `protect directive, the algorithm ModelSim uses to encrypt
source files is different. As a result, even though an uncompiled source file with `protect is
compatible with another simulator, once the source is compiled in ModelSim, you could not
simulate it elsewhere.

Verilog-XL Compatible Compiler Directives

The following compiler directives are provided for compatibility with Verilog-XL.
‘default_decay_time <time>

This directive specifies the default decay time to be used in trireg net declarations that do not
explicitly declare a decay time. The decay time can be expressed as a real or integer number, or
as “infinite” to specify that the charge never decays.

`delay_mode_distributed

This directive disables path delays in favor of distributed delays. See Delay Modes for details.

`delay_mode_path

This directive sets distributed delays to zero in favor of path delays. See Delay Modes for
details.

`delay_mode_unit

This directive sets path delays to zero and nonzero distributed delays to one time unit. See
Delay Modes for details.

`delay_mode_zero

This directive sets path delays and distributed delays to zero. See Delay Modes for details.

`uselib

This directive is an alternative to the -v, -y, and +libext source library compiler arguments. See
Verilog-XL uselib Compiler Directive for details.

The following Verilog-XL compiler directives are silently ignored by ModelSim Verilog. Many
of these directives are irrelevant to ModelSim Verilog, but may appear in code being ported
from Verilog-XL.

330 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog-XL Compatible Compiler Directives

`accelerate
`autoexpand_vectornets
`disable_portfaults
`enable_portfaults
`expand_vectornets
`noaccelerate
`noexpand_vectornets
`noremove_gatenames
`noremove_netnames
`nosuppress_faults
`remove_gatenames
`remove_netnames
`suppress_faults

The following Verilog-XL compiler directives produce warning messages in ModelSim

Verilog. These are not implemented in ModelSim Verilog, and any code containing these
directives may behave differently in ModelSim Verilog than in Verilog-XL.

`default_trireg_strength
`signed
`unsigned

ModelSim® SE User's Manual, v10.7 331

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Sparse Memory Modeling

Sparse Memory Modeling

Sparse memories are a mechanism for allocating storage for memory elements only when they
are needed. You mark which memories should be treated as sparse, and ModelSim dynamically
allocates memory for the accessed addresses during simulation.
Sparse memories are more efficient in terms of memory consumption, but access times to sparse
memory elements during simulation are slower. Thus, sparse memory modeling should be used
only on memories whose active addresses are “few and far between.”

Most operations are available for sparse memories and non-sparse memories alike. You actually
do not need to know whether a memory was sparse or not, except in a few cases which are
documented in "Limitations of Sparse Memories".

Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Priority of Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Determining Which Memories Were Implemented as Sparse . . . . . . . . . . . . . . . . . . . . 334
Initializing Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Limitations of Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

332 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Enabling Sparse Memories

Enabling Sparse Memories

You can enable sparse memories manually by inserting attributes or meta-comments in your
code.
You can also enable sparse memories automatically by setting the SparseMemThreshold
variable in the modelsim.ini file

Manually Marking Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Automatically Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Combining Automatic and Manual Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Manually Marking Sparse Memories

You can mark memories in your code as sparse using either the mti_sparse attribute or the
sparse meta-comment.
For example:

(* mti_sparse *) reg mem [0:1023]; // Using attribute

reg /*sparse*/ [0:7] mem [0:1023]; // Using meta-comment

The meta-comment syntax is supported for compatibility with other simulators.

You can identify memories as “not sparse” by using the +nosparse switch to vlog or vopt.

Automatically Enabling Sparse Memories

Using the SparseMemThreshold modelsim.ini variable, you can instruct ModelSim to mark as
sparse any memory that is a certain size.
Consider this example: If SparseMemThreshold = 2048 then

reg mem[0:2047]; // will be marked as sparse automatically

reg mem[0:2046]; // will not be marked as sparse

The SparseMemThreshold variable is set, by default, to 1048576.

Related Topics
SparseMemThreshold

Combining Automatic and Manual Modes

Because mti_sparse is a Verilog 2001 attribute that accepts values, you can enable automatic
sparse memory modeling but still control individual memories within your code.

ModelSim® SE User's Manual, v10.7 333

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Priority of Sparse Memories

Consider this example: If SparseMemThreshold = 2048 then

reg mem[0:2047]; // will be marked as sparse automatically

reg mem[0:2046]; // will not be marked as sparse

However, you can override this automatic behavior using mti_sparse with a value:

(* mti_sparse = 0 *) reg mem[0:2047];

// will *not* be marked as sparse even though SparseMemThreshold = 2048

(* mti_sparse = 1*) reg mem[0:2046];

// will be marked as sparse even though SparseMemThreshold = 2048

Priority of Sparse Memories

ModelSim labels memories as sparse or not sparse according to the following priority.
1. vlog or vopt +nosparse[+] — These memories are marked as “not sparse”, where vlog
options override vopt options.
2. metacomment /* sparse */ or attribute (* mti_sparse *) — These memories are marked
“sparse” or “not sparse” depending on the attribute value.
3. SparseMemThreshold .ini variable — Memories as deep as or deeper than this threshold
are marked as sparse.

Determining Which Memories Were Implemented as

Sparse
You can identify which memories were implemented as sparse with the write report command.
Procedure
Enter the following command at the command line:

write report -l

Results
The write report command lists summary information about the design, including sparse
memory handling. You would issue this command if you are not certain whether a memory was
successfully implemented as sparse or not. For example, you might add a /*sparse*/
metacomment above a multi-D SystemVerilog memory, which is not supported. In that case,
the simulation will function correctly, but ModelSim will use a non-sparse implementation of
the memory.
If you are planning to optimize your design with vopt, be sure to use the +acc argument in order
to make the sparse memory visible, thus allowing the write report -l command to report the
sparse memory.

334 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Initializing Sparse Memories

Initializing Sparse Memories

You can use either of two methods to initialize a sparse memory.
Procedure
1. Apply the +initmem option to vlog/vopt
2. Use the mem load command during simulation: use this in order to initialize the memory
with a single value other than 1, 0, X or Z.
If initialized to a single value, the sparse memory is not allocated physically, and it
remains sparse.

Limitations of Sparse Memories

The use of sparse memories has some specific limitations.
• PLI functions that get the pointer to the value of a memory will not work with sparse
memories. For example, using the tf_nodeinfo() function to implement $fread or
$fwrite will not work, because ModelSim returns a NULL pointer for tf_nodeinfo() in
the case of sparse memories.
• The following memories can not be processed as sparse memories:
o Memories with more than one of either a packed or unpacked dimension. For
example, neither of these memories can be sparse:
reg [0:3] [2:3] mem [0:1023]
reg [0:1] mem [0:1][0:1023]

o Dynamic or associative arrays

o Memories defined within a structure or class
• By default, when running without vopt, memories with parameterized dimensions are
not implented as sparse. However, you can explicitly mark them as sparse (see Manually
Marking Sparse Memories).

Unmatched Virtual Interface Declarations

The [1800-2012 SV] LRM does not address the relationship between interfaces as design
elements and virtual interfaces as types. The ModelSim flow allows substantial flexibility in
allowing virtual interfaces to exist even when the underlying interface design unit does not
exist, even in the design libraries.
When no matching interface exists, a virtual interface necessarily has a null value throughout
simulation as any incompatible assignment causes an error. In all cases of accessing data during

ModelSim® SE User's Manual, v10.7 335

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Unmatched Virtual Interface Declarations

simulation through such a virtual interface, an error results due to dereferencing a null virtual
interface.

However, there are a few situations in which types from such references can participate in the
design without requiring a dereference of the virtual interface pointer. This is extremely rare in
practice, but due to ModelSims overall elaboration and simulation flow, it is not possible for
ModelSim to determine whether such type references will actually be exercised during
simulation. So, for these cases, you can allow vsim to elaborate the design by adding the
following argument to vsim:

vsim -permit_unmatched_virtual_intf

Tip
Important: When using the -permit_unmatched_virtual_intf argument, take care to ensure
that no simulation time operations occur through unmatched virtual interfaces.

Related Topics
vsim [ModelSim SE Command Reference Manual]

336 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Verilog PLI and SystemVerilog DPI

Verilog PLI and SystemVerilog DPI

ModelSim supports the use of several interfaces.
The interfaces include:

• Verilog PLI (Programming Language Interface)

• SystemVerilog DPI (Direct Programming Interface).
• VPI (Verilog Procedural Interface)
These interfaces provide a mechanism for defining tasks and functions that communicate with
the simulator through a C procedural interface.

Standards, Nomenclature, and Conventions for VPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Extensions to SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Standards, Nomenclature, and Conventions for VPI

The product’s implementation of the Verilog VPI is based on the following standards.
• IEEE 1364-2005 and 1364-2001 (Verilog)
• IEEE 1800-2005 (SystemVerilog)
ModelSim supports partial implementation of the Verilog VPI. For release-specific information
on currently supported implementation, refer to the following text file located in the ModelSim
installation directory: <install_dir>/docs/technotes/Verilog_VPI.note

Note
ModelSim does not support pthread with DPI.

Related Topics
Verilog Interfaces to C

Extensions to SystemVerilog DPI

This section describes extensions to the SystemVerilog DPI for ModelSim.
• SystemVerilog DPI extension to support automatic DPI import tasks and functions.
You can specify the automatic lifetime qualifier to a DPI import declaration in order to
specify that the DPI import task or function can be reentrant.

ModelSim® SE User's Manual, v10.7 337

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Extensions to SystemVerilog DPI

ModelSim supports the following addition to the SystemVerilog DPI import tasks and
functions (additional support is in bold):
dpi_function_proto ::= function_prototype

function_prototype ::= function [lifetime] data_type_or_void

function_identifier ( [ tf_port_list ] )

dpi_task_proto ::= task_prototype

task_prototype ::= task [lifetime] task_identifier

( [ tf_port_list ] )lifetime ::= static | automatic

The following are a couple of examples:

import DPI-C cfoo = task automatic foo(input int p1);
import DPI-C context function automatic int foo (input int p1);

338 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
SystemVerilog Class Debugging

SystemVerilog Class Debugging

Debugging your design starts with an understanding of how the design is put together, the
hierarchy, the environments, the class types. ModelSim gives you a number of avenues for
exploring your design, finding the areas of the design that are causing trouble, pinpointing the
specific part of the code that is at fault, making the changes necessary to fix the code, then
running the simulation again.
This section describes the steps you take to enable the class debugging features and the
windows and commands that display information about the classes in your design.

Enabling Class Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

The Class Instance Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Logging Class Types and Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Working with Class Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Working with Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Working with Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Conditional Breakpoints in Dynamic Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Stepping Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
The Run Until Here Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Class Instance Garbage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Enabling Class Debug

You can enable visibility of class instances in your design in two ways.
Procedure
1. Use the vsim -classdebug option.
2. Set the ClassDebug modelsim.ini variable to 1.

Note
While optimization is not necessary for class based debugging, you might want to
use vsim -voptargs=+acc=lprn to enable visibility into your design for RTL
debugging.

ModelSim® SE User's Manual, v10.7 339

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
The Class Instance Identifier

The Class Instance Identifier

The Class Instance Identifier (CIID or Handle) is a unique name for every class instance created
during a simulation. The CIID format is @<class-type>@<n> where <class_type> is the name
of the class and <n> is the nth instance of that class. For example: @packet@134 is the 134th
instance of the class type packet.
The class type name alone may be used in the CIID if the class type name is unique in the
design. However, if the class type name is not unique the full path to the type declaration is
necessary.

The CIID may be used in commands such as examine, describe, add wave, add list.

Note
A CIID is unique for a given simulation. Modifying a design, or running the same design
with different parameters, randomization seeds, or other configurations that change the
order of operations, may result in a class instance changing. For example, @packet@134 in one
simulation run may not be the same @packet@134 in another simulation run if the design has
changed.

Obtaining the CIID with the examine Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Obtaining the CIID With a System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Obtaining the CIID with the examine Command

You can use the examine -handle command to return the CIID to the transcript.
Procedure
Enter the following command at the command line:

examine -handle <filename>

Obtaining the CIID With a System Function

The built in system function $get_id_from_handle( class_ref ) may be used to obtain the string
representing the class instance id for the specified class reference.
Procedure
The procedure is best illustrated with an example. The following code snippet will display the
CIID of the class item referenced by var.

myclass var;
initial begin
#10

340 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Logging Class Types and Class Instances

var = new();
$display( "%t : var = %s", $time, $get_id_from_handle(var) );
end

Results
10 : var = @myclass@1

Logging Class Types and Class Instances

You must log class variables, class types, or class instances in order to view them in the Wave
and List windows, and to view them post-simulation. The data recorded depends on the type of
class object you log.
1. Log the class variable to create a record of all class objects the variable references from
the time they are assigned to the variable to when they are destroyed. For example:
log sim:/top/simple

You can find the correct syntax for the class variable by dragging and dropping the class
variable from the Objects window into the Transcript.
2. Log a class type to create a contiguous record of each instance of that class type from the
time the instance first comes into existence to the time the instance is destroyed with the
log -class command. For example:
log -class sim:/mem_agent_pkg::mem_item

Refer to Finding the Class Type Syntax for more information.

3. Log a specific instance of a class until it is destroyed by specifying the class identifier
for the specific class instance. For example:
log @myclass@7

Refer to The Class Instance Identifier for more information about finding and specifying
a class instance identifier.
4. Log a Class Path Expression. Refer to Working with Class Path Expressions for more
information.

ModelSim® SE User's Manual, v10.7 341

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Types

Working with Class Types

You can view the class types in your design in the Class Tree, Class Graph, Structure, and other
windows.
Authoritative and Descriptive Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Finding the Class Type Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Viewing Class Types in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

342 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Types

Authoritative and Descriptive Class Type Names

ModelSim maintains two representations for class names: the authoritative class type name and
the descriptive class type name. This name mapping is specifically to support parameterized
class specializations.
Authoritative Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Descriptive Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Authoritative Class Type Names

Authoritative names end with "__n" where 'n' is an integer. For example: /pkg::mypclass__6.
Authoritative names offer a shorter, well-formed name, for a parameterized class specialization.
Authoritative names are used in most places in the user interface. They are also used as input to
commands that take a class type argument.

Descriptive Class Type Names

Descriptive names more closely resemble the class definition, but are longer (sometimes much
longer) and are sometimes difficult to read and parse. For example: /pkg::mypclass #( class
inputclass, 128, class report__2 ). Descriptive names are used in error messages and are shown
in some places in the GUI such as in the class tree window.
The classinfo descriptive command will translate an authoritative name to a descriptive name.
For example:

VSIM> classinfo descriptive /pkg::mypclass__6

# Class /pkg::mypclass__6 maps to /pkg::mypclass #( class inputclass, 128,
class report__2 )

In this example, one of the parameters in the descriptive name is also a specialization of a
parameterized class.

Finding the Class Type Syntax

The <class_type> may be specified using the specific class type name or any path that resolves
to the class type. For example: @packet@134 may also be specified as @/
test_pkg::packet@134 assuming the class packet is defined in /test_pkg.
You can use the classinfo types -n command to determine whether or not a type name is unique
and return the requisite full class type name to the transcript. For example, the following
command returns all the shortest usable names for all class type names containing the string
"foo":

VSIM> classinfo types -n *foo*

ModelSim® SE User's Manual, v10.7 343

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Types

# my_foo
# foo2
# /top/mod1/foo
# /top/mod2/foo

In the output, my_foo and foo2 are unique class types. However, the last two entries show that
there are two distinct class types with the name 'foo'; one defined in mod1 and the other in
mod2. To specify an instance of type 'foo', the full path of the specific “foo” is required, for
example @/top/mod2/foo@19.

You can also find the correct syntax for a class type by dragging and dropping the class type
from the Structure window into the Transcript window.

344 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Types

Viewing Class Types in the GUI

You can view class types in several windows, including the Structure, Class Tree, and Class
Graph windows.
The Class Tree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
The Class Graph Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
The Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

The Class Tree Window

The Class Tree window displays the class inheritance tree in various forms. You can expand
objects to see parent/child relationships, properties, and methods. You can organize by extended
class (default) or base class.
The Class Tree window can help with an overview of your environment and architecture. It also
helps you view information about an object that is both a base and extended class. (Figure 7-5)

Figure 7-5. Classes in the Class Tree Window

Refer to Class Tree Window in the GUI Reference Manual for more information.

The Class Graph Window

The Class Graph window displays interactive relationships between SystemVerilog classes in a
graphical form and includes extensions of other classes and related methods and properties. You

ModelSim® SE User's Manual, v10.7 345

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Types

can organize by extended class (default) or by base class. Use it to show all of the relationships
between the classes in your design.
Figure 7-6. Class in the Class Graph Window

Refer to Class Graph Window in the GUI Reference Manual for more information.

The Structure Window

The Structure window displays the class types in your design. You must select a class type in
the Structure window to view that class type’s instances in the Class Instances window.

346 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Types

Figure 7-7. Classes in the Structure Window

ModelSim® SE User's Manual, v10.7 347

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Instances

Working with Class Instances

Viewing class instances is helpful for finding class, OVM, and UVM components or subtypes
that have been instantiated. You can see how many of the instances have been created in the
Class Instances window or with the classinfo report and classinfo instances commands. You can
search through the list of components or transactions for an object with a specific value in the
Objects window.
The Class Instances Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Viewing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
The Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
The Call Stack Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

The Class Instances Window

The Class Instances window displays information about all instances of a selected class type
that exist at the current simulation time.
You can open the Class Instances window by selecting View > Class Browser > Class
Instances or by specifying view classinstances on the command line. (Figure 7-8)

348 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Instances

Figure 7-8. The Class Instances Window

Prerequisites
The class debug feature must be enabled to use the Class Instances window. Refer to Enabling
Class Debug for more information.

The Class Instances window is dynamically populated by selecting SystemVerilog classes in the
Structure (sim) window. All currently active instances of the selected class are displayed in the
Class Instances window. Class instances that have not yet come into existence or have been
destroyed are not displayed. Refer to The classinfo Commands for more information about
verifying the current state of a class instance.

Once you have chosen the design unit you want to observe, you can lock the Class Instances
window on that design unit by selecting File > Environment > Fix to Current Context when
the Class Instances window is active.

ModelSim® SE User's Manual, v10.7 349

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Instances

Viewing Class Instances in the Wave Window

The suggested workflow for logging SystemVerilog class objects in the Wave window is as
follows.
1. Log the class objects you are interested in viewing (refer to Logging Class Types and
Class Instances for more information)
2. Select a design unit or testbench System Verilog class type in the Structure Window that
contains the class instances you want to see. The class type will be identified as a
System Verilog class object in the Design Unit column. All currently existing class
instances associated with that class type or testbench item are displayed in the Class
Instances window. (Open the Class Instances window by selecting View > Class
Browser > Class Instances from the menus or use the view class instances command.)
3. Place the class objects in the Wave window once they exist by doing one of the
following:
o Drag a class instance from the Class Instances window or the Objects window and
drop it into the Wave window (refer to Figure 7-9).
o Select multiple objects in the Class Instances window, click and hold the Add
Selected to Window button in the Standard toolbar, then select the position of the
placement; the top of the Wave window, the end of the Wave window, or above the
anchor location. The group of class instances are arranged with the most recently
created instance at the top. You can change the order of the class instances to show
the first instance at the top of the window by selecting View > Sort > Ascending.

350 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Instances

Figure 7-9. Placing Class Instances in the Wave Window

You can hover the mouse over any class waveform to display information about the class
variable (Figure 7-10).

Figure 7-10. Class Information Popup in the Wave Window

ModelSim® SE User's Manual, v10.7 351

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Instances

The Locals Window

The Locals window displays data objects that are immediately visible at the current execution
point of the selected context. Clicking in the objects window or Structure window might make
you lose the current context. The Locals window is synchronized with the Call-Stack window
and the contents are updated as you move through the design.
Related Topics
Locals Window [ModelSim SE GUI Reference Manual]

The Watch Window

The Watch window displays signal or variable values at the current simulation time. It helps
you view a subset of local or class variables when stopped on a breakpoint.
Use the Watch window when the Locals window is crowded. You can drag and drop objects
from the Locals window into the Watch window (Figure 7-11).

Figure 7-11. Class Viewing in the Watch Window

Refer to Watch Window in the GUI Reference Manual for more information.

352 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Instances

The Capacity Window

The Capacity-Object and Capacity-Line windows show data about current memory allocation.
You can use them to find areas where memory usage is causing problems, and to display count,
memory usage, and other information.
The default view shows course grain analysis totals for two object types:

• Static objects — analysis includes the object count and current memory usage.
• Dynamic objects — analysis includes object count, current memory usage, peak
memory usage, and the time peak memory usage occurred.
ModelSim collects data as either a coarse-grain analysis (default) or a fine-grain analysis of
memory capacity. The main difference between the two levels is the amount of capacity data
collected. You must enable fine-grain analysis to view count, current and peak memory
allocation for each class type, aggregate information about the class type, including the current
filename and line number where the allocation occurred. Refer to Levels of Capacity Analysis
for more information.

Refer to Capacity-Object and Capacity-Line Windows in the GUI Reference Manual, and
Capacity Analysis in this manual for more information about viewing class memory usage. You
can also display capacity data in the Wave Window. Refer to Displaying Capacity Data in the
Wave Window for more information.

The Call Stack Window

The Call Stack window is useful for viewing your design when you are stopped at a breakpoint.
You can go up the call stack to see the locals context at each stage of your design.
Related Topics
Call Stack Window [ModelSim SE GUI Reference Manual]

ModelSim® SE User's Manual, v10.7 353

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Path Expressions

Working with Class Path Expressions

A class path expression is a hierarchical path through a class hierarchy.
Class path expressions:

• allow you to view class properties in the Wave and Watch windows, and return data
about class properties with the examine command. You can see how the class properties
change over time even when class references within the path expression change values.
• may be added to the Wave window even when they do not exist.
• may be expanded inline in the Wave window without having to add class objects to the
Wave window individually.
• may be cast to the legal types for the expression. In the Wave window, the casting
options are restricted to the set of types of objects actually assigned to the references.
• are automatically logged once the expression is added to the Wave window.
Class Path Expression Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Adding a Class Path Expression to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Class Path Expression Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Casting a Class Variable to a Specific Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Class Objects vs Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Disabling Class Path Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Class Path Expression Syntax

Class path expressions require a specific syntax.
For example, a correct path expression is written as follows:

/top/myref.xarray[2].prop

where

myref is a class variable

xarray is an array of class references

prop is a property in the xarray element class type

In this case the expression allows you to watch the value of prop even if myref changes to point
to a different class object, or if the reference in element [2] of xarray changes.

354 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Working with Class Path Expressions

Adding a Class Path Expression to the Wave Window

You can add a class path expression to the Wave window with the add wave command.
For example:

add wave /top/myref.ref_array[0].prop

Class Path Expression Values

A class path expression may have one of several possible values.
• The expression may have a standard value of the type of the leaf element in the
expression.
• The expression may have a value of ‘Null’ if the leaf element is a class reference and its
value is null.
• The expression may have a value of ‘Does Not Exist’ in the case that an early part of the
expression has a null value. In the earlier example, /top/myref.xarray[2].prop, if myref is
null then prop does not exist.
Figure 7-12. Class Path Expressions in the Wave Window

Casting a Class Variable to a Specific Type

You can cast a class variable to any of the class types that have been assigned to that class
variable. the default is the declared type of the class variable.

ModelSim® SE User's Manual, v10.7 355

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Working with Class Path Expressions

Figure 7-13. /top/a Cast as c1 and c1prime

Procedure
1. Right-click (RMB) the class variable waveform and select Cast to.
2. RMB over the name/value of the class reference in the Pathnames or the Values Pane of
the Wave window to open a popup menu. Select Cast to > <class_type>. The current
value will have check mark next to it. (Figure 7-14)
Figure 7-14. Casting c1 to c1prime

356 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Conditional Breakpoints in Dynamic Code

Class Objects vs Class Path Expressions

By default, a path that includes a class reference will be interpreted in the user interface as a
path expression. There are cases where the interpreted object is what is desired and not the path
expression.
For example,

add wave /top/myref.prop

will add the class path expression to the wave window. The expression will be evaluated
regardless of what class object is referenced by myref.

Using the -obj argument to the add wave command causes the command to interpret the
expression immediately and add the specific class object to the Wave window instead of the
class path expression. For example:

add wave -obj /top/myref.prop

will add the currently class object and property to the Wave window, in this case,
@myref@19.prop. @myref@19 is the specific object at the time the command was executed.

Disabling Class Path Expressions

Setting the MTI_DISABLE_PATHEXPR environment variable will disable the interpretations
of all class path expressions. This is equivalent to the behavior in version 10.2 and earlier.

Conditional Breakpoints in Dynamic Code

You can set a breakpoint or a conditional breakpoint at any place in your source code.

Examples
• Conditional breakpoint in dynamic code
bp mem_driver.svh 60 -cond {this.id == 9}

• Stop on a specific instance ID.

a. Enter the command:
examine -handle

b. Drag and drop the object from the Objects window into the Transcript window.
ModelSim adds the full path to the command.
examine –handle
{sim:/uvm_pkg::uvm_top.top_levels[0].super.m_env.m_mem_agent.m_driver}

c. Press Enter

ModelSim® SE User's Manual, v10.7 357

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Stepping Through Your Design

Returns the class instance ID in the form @<class_type>@<n>:

# @mem_driver@1

d. Enter the class instance ID as the condone in the breakpoint.

bp mem_driver.svh 60 -cond {this == @mem_driver@1}

• Stop on a more complex condition:

bp bfm.svh 50 {
set handle [examine -handle this];
set x_en_val [examine this.x_en_val];
if {($handle != @my_bfm@7) || ($x_en_val != 1)}{
continue
}
}

Refer to Setting Conditional Breakpoints or more information about conditional breakpoints.

Stepping Through Your Design

Stepping through your design is helpful once you have pinpointed the area of the design where
you think there is a problem. In addition to stepping to the next line, statement, function or
procedure, you have the ability to step within the current context (process or thread). This is
helpful when debugging class based code since the next step may take you to a different thread
or section of your code rather than to the next instance of a class type.
For example:
Table 7-14. Stepping Within the Current Context.
Step the simulation into the next statement,
remaining within the current context.
Step the simulation over a function or
procedure remaining within the current
context. Executes the function or procedure
call without stepping into it.
Step the simulation out of the current function
or procedure, remaining within the current
context.

Refer to Step Toolbar in the GUI Reference Manual for a complete description of the stepping
features.

358 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
The Run Until Here Feature

The Run Until Here Feature

To quickly and easily run to a specific line of code, you can use the ‘Run Until Here’ feature.
When you invoke Run Until Here, the simulation will run from the current simulation time and
stop on the specified line of code unless
• The simulator encounters a breakpoint.
• The Run Length preference variable causes the simulation run to stop.
• The simulation encounters a bug.
To specify Run Until Here, right-click the line where you want the simulation to stop and
select Run Until Here from the pop up context menu. The simulation starts running the
moment the right mouse button releases.

Refer to Run Until Here for more information.

ModelSim® SE User's Manual, v10.7 359

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Command Line Interface

Command Line Interface

Enter commands on the Vsim command line in the Transcript window. This allows you to work
with data for class types, their scopes, paths, names, and so forth. You can call SystemVerilog
static functions and class functions with the call command. Commands also help you find the
proper name syntax for referencing class based objects in the GUI.
Class Instance Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Class Instance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
The classinfo Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Class Instance Values

The examine command returns current values for classes or variables to the transcript while
debugging. The examine command can help you debug by displaying the name of a class
instance or the field values for a class instance before setting a conditional breakpoint.

Examples
• Print the current values of a class instance.
examine /ovm_pkg::ovm_test_top

• Print the values when stopped at a breakpoint within a class.

examine this

• Print the unique ID of a specific class instance using the full path to the object.
examine –handle /ovm_pkg::ovm_test_top.i_btn_env

• Print the unique handle of the class object located at the current breakpoint.
examine –handle this

• Print the value of a specific class instance.

examine @mem_item@9

Class Instance Properties

Use the describe command to display data members, properties, methods, tasks, inheritance,
and other information about class instances, and print it in the transcript window.
• Display data for the class instance @questa_messagelogger_report_server@1
describe @questa_messagelogger_report_server@1

360 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Command Line Interface

Returns:
# class /questa_uvm_pkg::questa_messagelogger_report_server extends
/uvm_pkg::uvm_report_server
# static /questa_uvm_pkg::questa_messagelogger_report_server
m_q;
# function new;
# static function message_logger;
# function compose_message;
# function process_report;
# static function get;
# static function init;
# endclass

• Display data for the class type mailbox__1

describe mailbox__1

Returns:
class /std::mailbox::mailbox__1
# Queue items;
# int maxItems;
# chandle read_awaiting;
# chandle write_awaiting;
# chandle qtd;
# /std::semaphore read_semaphore;
# /std::semaphore write_semaphore;
# function new;
# task put;
# function try_put;
# task get;
# function try_get;
# task peek;
# function try_peek;
# function post_randomize;
# function pre_randomize;
# function constraint_mode;
# endclass

Calling Functions
The call command calls SystemVerilog static functions, class functions directly from the vsim
command line in live simulation mode and Verilog interface system tasks and system functions.
Tasks are not supported.
Function return values are returned to the vsim shell as a Tcl string. Returns the class instance
ID when a function returns a class reference.

Call a static function or a static 0 time task from the command line.

ModelSim® SE User's Manual, v10.7 361

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Command Line Interface

Examples:

call /ovm_pkg::ovm_top.find my_comp

call @ovm_root@1.find my_comp
call @ovm_root@1.print_topology
call /uvm_pkg::factory.print

362 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Command Line Interface

The classinfo Commands

The classinfo commands give you high level information about the class types and class
instances in your design.
Finding the Full Path and Name of a Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Determining the Current State of a Class Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Finding All Instances of a Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Reporting Statistics for All Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Reporting Class Instance Statistics for a Simulation Run . . . . . . . . . . . . . . . . . . . . . . . . 366
Reporting Active References to a Class Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Finding Class Type Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Listing Classes Derived or Extended From a Class Type . . . . . . . . . . . . . . . . . . . . . . . . 368
Analyzing Class Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Finding the Full Path and Name of a Class Type

The classinfo descriptive command returns the descriptive class type name given the
authoritative class type name.
The authoritative class type name (for example, mypclass__9 ) has a corresponding descriptive
name that may be more useful in determining the actual class type and the details of it's
specialization. This command allows you to see the mapping from the authoritative name to the
descriptive name.

Prerequisites
Specify the -classdebug argument with the vsim command.

Procedure
Enter the classinfo descriptive command for the desired class type.

classinfo descriptive <class_type>

Examples
• Display the descriptive class type name for /std::mailbox::mailbox__1
classinfo descriptive /std::mailbox::mailbox__1

Returns:
# Class /std::mailbox::mailbox__1 maps to mailbox #(class uvm_phase)

Related Topics
Authoritative and Descriptive Class Type Names

ModelSim® SE User's Manual, v10.7 363

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Command Line Interface

classinfo descriptive [ModelSim SE Command Reference Manual]

Determining the Current State of a Class Instance

The classinfo find command searches the currently active dataset for the state of the specified
Class Instance Identifier, whether it exists, has not yet been created, or has been destroyed. You
can specify an alternate dataset for the search and save the results of the search to a text file or to
the transcript as a tcl string.
Procedure
Enter the classinfo find command with the desired class instance.

classinfo find <class_instance>

Examples
• Verify the existence of the class instance @mem_item@87
classinfo find @mem_item@87

Returns:
# @mem_item@87 exists

or
# @mem_item@87 not yet created

or
# @mem_item@87 has been destroyed

Related Topics
classinfo find [ModelSim SE Command Reference Manual]

Finding All Instances of a Class Type

The classinfo instances command reports the list of existing class instances for a specific class
type. This could be useful in determining what class instances to log or examine. It may also
help in debugging problems where class instances are not being cleaned up as they should be
resulting in run-away memory usage.
Procedure
Enter the classinfo instances command with the desired class type.

classinfo instances <classname>

Examples
• List the currently active instances of the class type mem_item.

364 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Command Line Interface

classinfo instances mem_item

Returns:
# @mem_item@140
# @mem_item@139
# @mem_item@138
# @mem_item@80
# @mem_item@76
# @mem_item@72
# @mem_item@68
# @mem_item@64

Related Topics
classinfo instances [ModelSim SE Command Reference Manual]

Reporting Statistics for All Class Instances

The classinfo report command prints detailed statistics about class instances.
The report includes:

• full relative path

• class instance name
• total number of instances of the named class
• maximum number of instances of a named class that existed simultaneously at any time
in the simulation
• current number of instances of the named class
The columns may be arranged, sorted, or eliminated using the command arguments.

Procedure
Enter the classinfo report command at the command line.

classinfo report

Examples
• Create a report of all class instances in descending order in the Total column. Print the
Class Names, Total, Peak, and Current columns. List only the first six lines of that
report.
classinfo report -s dt -c ntpc -m 6

ModelSim® SE User's Manual, v10.7 365

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Command Line Interface

Returns:
# Class Name Total Peak Current
# uvm_pool__11 318 315 315
# uvm_event 286 55 52
# uvm_callback_iter__1 273 3 2
# uvm_queue__3 197 13 10
# uvm_object_string_pool__1 175 60 58
# mem_item 140 25 23

Related Topics
classinfo report [ModelSim SE Command Reference Manual]

Reporting Class Instance Statistics for a Simulation Run

The classinfo stats command reports statistics about the total number of class types and total,
peak, and current class instance counts during the simulation.
Procedure
Enter the classinfo stats command at the command line.

classinfo stats

Examples
• Display the current number of class types, the maximum number, peak number and
current number of all class instances.
classinfo stats

Returns:
# class type count 451
# class instance count (total) 2070
# class instance count (peak) 1075
# class instance count (current) 1058

Related Topics
classinfo stats [ModelSim SE Command Reference Manual]

Reporting Active References to a Class Instance

The classinfo trace command displays the active references to the specified class instance. This
is very useful in debugging situations where class instances are not being destroyed as expected
because something in the design is still referencing the class instance. Finding those references
may lead to uncovering bugs in managing these class references which often lead to large
memory savings.

366 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Command Line Interface

Procedure
Enter the classinfo trace command with the desired class instance.

classinfo trace <class_instance>

Examples
• Return the first active reference to @my_report_server@1
classinfo trace @my_report_server@1

Returns:
# top.test.t_env.m_rh.m_srvr

Related Topics
classinfo trace [ModelSim SE Command Reference Manual]

Finding Class Type Inheritance

The classinfo ancestry command shows the inheritance of a specific class type. With some
designs and methodologies class hierarchy can become quite deep. This command will show all
of the super classes of a class type back to it's base class.
Procedure
Enter the classinfo ancestry command with the desired class type.

classinfo ancestry <class_type>

Examples
• Return the inheritance for mem_item.
classinfo ancestry mem_item

Returns:
# class /mem_agent_pkg::mem_item extends /
uvm_pkg::uvm_sequence_item
# class /uvm_pkg::uvm_sequence_item extends /
uvm_pkg::uvm_transaction
# class /uvm_pkg::uvm_transaction extends /uvm_pkg::uvm_object
# class /uvm_pkg::uvm_object extends /uvm_pkg::uvm_void
# class /uvm_pkg::uvm_void

Related Topics
classinfo ancestry [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 367

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Command Line Interface

Listing Classes Derived or Extended From a Class Type

The classinfo command lists the classes derived from the specified class type. When one class
(X) extends another class (Y), class X inherits the characteristics of class Y. Class X, therefore,
'isa' class Y. Class X is also a class X, of course. Class Y, however, is not a class X.
Consider a simple example of a class called Fruit (Figure 7-15Extensions for a Class Type).
Class Apple extends Fruit, and class Pear extends Fruit. Further, classes HoneyCrisp,
GoldenDelicious, and Gravenstein extend Apple. The classes Bosc and and Bartlett extend
Pear.

Figure 7-15. Extensions for a Class Type

Asking the question [classinfo isa Apple] would return Apple, HoneyCrisp, GoldenDelicious,
and Gravenstein. Asking [classinfo isa Pear] would return Pear, Bosc, and Bartlett. And finally,
[classinfo isa Fruit] would return Fruit, Apple, Pear, HoneyCrisp, GoldenDelicious,
Gravenstein, Bosc, and Bartlett.This command could be useful for determining all the types
extended from a particular methodology sequencer, for example.

Examples
• Find all extensions for the class type mem_item.
classinfo isa mem_item

368 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Command Line Interface

Returns:
# /mem_agent_pkg::mem_item
# /mem_agent_pkg::mem_item_latency4_change_c
# /mem_agent_pkg::mem_item_latency2_change_c
# /mem_agent_pkg::mem_item_latency6_change_c
# /mem_agent_pkg::mem_item_latency_random_c

Analyzing Class Types

The classinfo types command searches for and analyses class types by matching a regular
expression. Returns the inheritance hierarchy for classes, class extensions, and determines the
full path of class types.
Procedure
Enter the classinfo types command with the desired class type.

classinfo types <class_type>

Examples
• List the full path of the class types that do not match the pattern *uvm*. The scope and
instance name returned are in the format required for logging classes and when setting
some types of breakpoints,
classinfo types -x *uvm*

Returns:
# /environment_pkg::test_predictor
# /environment_pkg::threaded_scoreboard
# /mem_agent_pkg::mem_agent
# /mem_agent_pkg::mem_config
# /mem_agent_pkg::mem_driver

Related Topics
classinfo types [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 369

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Class Instance Garbage Collection

Class Instance Garbage Collection

As your simulation run progresses, class instances are created and destroyed and the data stored
in memory. Though a class instance ceases to be referenced, the data for that instance is retained
in memory. The garbage collector (GC) deletes all un-referenced class objects from memory.
Default Garbage Collector Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Changing the Garbage Collector Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Running the Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Default Garbage Collector Settings

Automatic execution of the garbage collector is dependent upon how your design is simulated.

Table 7-15. Garbage Collector Modes

Mode Modelsim.ini Variable vsim argument
Class debug disabled ClassDebug = 0 vsim -noclassdebug
(default)
Class debug enabled ClassDebug = 1 vsim -classdebug

The default settings for execution of the garbage collector are optimized to balance performance
and memory usage for either mode. The garbage collector executes when one of the following
events occurs depending on the mode:

• After the total of all class objects in memory reaches a specified size in Megabytes.
• At the end of each run command.
• After each step operation.

GC Settings in Class Debug Disbled Mode

• Memory threshold = 100 megabytes
• At the end of each run command: Off
• At the end of each step command: Off

GC Settings in Class Debug Enabled Mode

• Memory threshold = 5 megabytes
• At the end of each run command: On
• At the end of each step command: Off

370 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Class Instance Garbage Collection

Changing the Garbage Collector Configuration

You can change the default garbage collector settings for the current simulation in the Garbage
Collector Configuration dialog box, on the command line, via modelsim.ini variables, or with
vsim command arguments.
Refer to the following table for garbage collector commands, modelsim.ini variables and vsim
command arguments:
Table 7-16. CLI Garbage Collector Commands and INI Variables
Action Commands INI Variable INI Variable
Set Memory gc configure “GCThreshold” on page 1507 vsim
Threshold -threshold <value> or “GCThresholdClassDebug” -gcthreshold <value>
on page 1508
Execute after gc configure vsim -gconrun/
each run -onrun 0|1 -nogconrun
command
Execute after gc configure vsim -gconstep/
each step -onstep 0|1 -nogconstep
command

Procedure
1. To open the Garbage Collector Configuration dialog, select Tools > Garbage Collector
> Configure to open the dialog box.
Figure 7-16. Garbage Collector Configuration

2. The default settings are loaded automatically and set based on whether you have
specified the -classdebug or the -noclassdebug argument with the vsim command.
Related Topics
gc configure [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 371

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Class Instance Garbage Collection

GCThreshold
GCThresholdClassDebug
vsim [ModelSim SE Command Reference Manual]

Running the Garbage Collector

You can run the garbage collector at any time.
Procedure
Enter gc run at the command line.

372 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
OVM-Aware Debug

OVM-Aware Debug
OVM-aware debugging provides you, the verification or design engineer, with information, at
the OVM abstraction level, that connects you to the OVM base-class library.
Preparing Your Simulation for OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
OVM-Aware Debugging Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
OVM-Aware Debug Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Preparing Your Simulation for OVM-Aware Debug

This section describes the steps you must take to enable the OVM-aware debugging features in
your OVM environment.
Prerequisites
• Design Source — SystemVerilog testbench based on the Open Verification
Methodology (OVM) v2.0 or greater. Refer to
http://verificationacademy.com/verification-methodology

for more details.

• Precompiled OVM Library — You must use the precompiled OVM library (mtiOvm)
provided in the installation. This library contains the necessary infrastructure used to
enable the OVM-aware debugging capabilities.
Procedure
1. Compilation — You must use the OVM source included in your installation directory to
take advantage of the built in debugging features. Here are three compilation scenarios
that may apply to your environment.
• If your OVM design does not require macros, you can use a command similar to:
vlog top.sv

and the compiler will use the precompiled OVM library (mtiOvm).
• If your OVM requires macros, you must also include the ovm-2.0, or greater, source
files. For example:
vlog top.sv \
+incdir+<install_dir>/verilog_src/ovm-<version>/src/

ModelSim® SE User's Manual, v10.7 373

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Preparing Your Simulation for OVM-Aware Debug

• If you cannot use the precompiled OVM and need to compile the OVM source
directly, you must specify a +define of OVM_DEBUGGER as follows:
vlog top.sv \
+incdir+<install_dir>/verilog_src/ovm-<version>/src/ \
+define+OVM_DEBUGGER \
<install_dir>/verilog_src/ovm-<version>/src/ovm_pkg.sv

2. Optimization — You can explicitly or implicitly run vopt. There are no special settings
to enable OVM-Aware debugging.
3. Elaboration — You must specify the -OVMdebug switch on the vsim command line.
Note that the switch is case-sensitive. This instructs the simulator to collect debugging
information about your OVM environment.
4. GUI — Display the OVM-aware debugging windows, OVM Globals Window and
OVM Hierarchy Window, by executing the command:
view ovm

You can also display these windows from the View > OVM menu items.
5. Simulation — The OVM Hierarchy window will be empty until the testbench creates the
first OVM environment components. As soon as the simulation enters the OVM build
phase, the OVM structure is built up and the OVM Hierarchy window is populated. You
can enter the OVM build phase by running the simulation to a particular time or by
setting a breakpoint in your design.

374 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
OVM-Aware Debugging Tasks

OVM-Aware Debugging Tasks

This section describes OVM-aware debugging tasks you can perform on your OVM
environment.
Locating Blocking Calls in the OVM Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Finding Matching Get and Set Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Locating Blocking Calls in the OVM Hierarchy

If your OVM environment is at a point where there are blocking calls, the OVM Globals
window contains a tree labeled Blockers.
You can use this tree to locate the corresponding element to a given blocker in the OVM
Hierarchy Window.

Procedure
1. Expand the Blockers tree in the OVM Globals window.
2. Select one of the “Blocker” entries in the tree.
This adds a green arrow to the OVM Hierarchy window indicating the location of the
corresponding element.
3. In the OVM Hierarchy window, continue to expand the tree until the green arrow
disappears and the corresponding element to the blocker is selected. Note also that the
element is also highlighted green if you select any other element of the hierarchy.
4. Right-click the selected hierarchy element and select “View Sequence Details” for
additional information.

Finding Matching Get and Set Configurations

For a given OVM component you can view which get configurations have a matching set
configuration, and vice versa.
Procedure
1. Select an element in the OVM Hierarchy window with a type of either “component” or
“sequencer”.
2. Right-click the element and select View Component Details from the pop-up menu.
This displays an OVM Component window specific to the selected component or
sequencer.
3. In the OVM Component window, expand the Get Configurations tree.

ModelSim® SE User's Manual, v10.7 375

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
OVM-Aware Debugging Tasks

• Any get configuration highlighted in green can be expanded to show the location
that sets the configuration.
Select any matching (green) configuration and your OVM Hierarchy window will
select the corresponding element.
• Any get configuration highlighted in red does not have a matching set configuration.
4. In the OVM Component window expand the Set Configurations tree.
• Any set configuration highlighted in green can be expanded to show the location(s)
that gets the configuration.
Select any matching (green) configuration and your OVM Hierarchy window will
highlight the corresponding elements in green or directly select a single component
that gets that configuration.
• Any set configuration highlighted in red does not have a matching get configuration.

376 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
OVM-Aware Debug Windows

OVM-Aware Debug Windows

This section describes the four OVM windows you can use during OVM-aware debug. The
contents of these windows will change as you advance through the simulation.
OVM Globals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Hierarchy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Components Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
OVM Sequence Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

OVM Globals Window

The OVM Globals window contains information that is not specific to an OVM component.
Specifically it contains information about phases, barriers and blockers. Display this window by
selecting the View > OVM > OVM Globals menu item.
• Phases — Phases are a way to synchronize OVM components. Expand this tree to show
the phases and the current phase.
• Barriers — Barriers, like phases, provide a synchronization mechanism. Unlike Phases
there is no known relationships between barriers, any defined barrier will be shown.
• Blockers — During the simulation, threads may be stopped on various OVM calls. This
tree shows the list of all currently blocked processes. .

OVM Hierarchy Window

The OVM Hierarchy window contains hierarchical information about your OVM environment.
• Name — Provides a hierarchical view of the OVM classes used. The names are based on
the class names created in your OVM environment.
• Type — Identifies the type of object listed in the Name column. Examples include:
component, sequencer, ovm_port, tlm, fifo, sequencer, sequence.
• Phase — Identifies whether the object in the Name column has been started or
completed.
Display this window by selecting the View > OVM > OVM Hierarchy menu item.

OVM Components Window

The OVM Components window contains information about the specific component.
• Get Configurations — and where they are set from.
• Set Configurations — and where they are used.

ModelSim® SE User's Manual, v10.7 377

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
OVM-Aware Debug Windows

• Stop Request information

Display this window by selecting right-clicking on a component in the OVM Hierarchy window
and selecting “View Component Details”.

OVM Sequence Window

The OVM Sequence window contains textual information about the selected sequence and its
current state.
Display this window by right-clicking on a sequence in the OVM Hierarchy window and
selecting View Sequence Details.

378 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 8
SystemC Simulation

This chapter describes how to compile and simulate SystemC designs with ModelSim.
ModelSim implements the SystemC language based on the Open SystemC Initiative (OSCI)
proof-of-concept SystemC simulator. The default suupported version of SystemC is the IEEE
1666-2011 standard, SystemC-2.3.1. Release 2.3.1 of SystemC includes Release 2.0.3 of
Transaction Level Modeling (TLM) code. It is recommended that you obtain the OSCI
functional specification or the latest version of the IEEE Std 1666-2011, IEEE Standard
SystemC Language Reference Manual.
To enable SystemC-2.2 (IEEE 1666-2005 standard), you can use the Sc22Mode modelsim.ini
variable or the -sc22 argument for the sccom, vopt, and vsim commands. The -sc22 argument
should be used with the sccom command during both compile and link steps, and then used
again in the vopt step and in the vsim step to enable SystemC-2.2.

In addition to the functionality described in the OSCI specification, ModelSim for SystemC
includes the following features:

• Single common Graphic Interface for SystemC and HDL languages.

• Extensive support for mixing SystemC, VHDL, Verilog, and SystemVerilog in the same
design (SDF annotation for HDL only). For detailed information on mixing SystemC
with HDL see Mixed-Language Simulation.
• Support for the Accellera SystemC Verification Library (SCV-2.0.0) for both SystemC-
2.3.1 and SystemC-2.2.
Supported Platforms and Compiler Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Usage Flow for SystemC-Only Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Creating Shared Object Files for SystemC Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Binding to Verilog or SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Distributing SystemC IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Compiling SystemC Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Linking the Compiled Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Simulation of SystemC Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Debugging the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
SystemC Object and Type Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Modifying SystemC Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Code Modification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

ModelSim® SE User's Manual, v10.7 379

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation

Differences Between the Simulator and OSCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

OSCI 2.3.1 Feature Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
OSCI 2.2 Feature Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Troubleshooting SystemC Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

380 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Supported Platforms and Compiler Versions

Supported Platforms and Compiler Versions

SystemC runs on a subset of ModelSim supported platforms.
One subset of supported platforms exists for SystemC-2.3.1 (Table 8-1) and another for
SystemC-2.2 (Table 8-2).
Table 8-1. Supported Platforms for SystemC-2.3.1
Platform/OS Supported compiler versions1 32-bit 64-bit TLM
linux, linux_x86_64 gcc-5.3.02 yes yes 2.0.2
gcc-4.7.4
gcc-4.5.0
VCO is linux (32-bit binary)
VCO is linux_x86_64 (64-bit binary)
Windows3 gcc 4.2.1— VCO is win32 yes no 2.0.2

1. Header files location: <path to questa install tree>/include/systemc/sc

2. GNU changed the default standard they support with gcc-5.3.0 from gnu89 to gnu11, as defined at the
location GCC 5 Release Series
3. 32-bit executable and 32-bit gcc can be used with 64-bit Windows systems, though they only run as
32-bit binaries.

Table 8-2. Supported Platforms for SystemC-2.2

Platform/OS Supported compiler versions1 32-bit 64-bit TLM
linux, linux_x86_64 gcc-4.5.0 yes yes 2.0.1
VCO is linux (32-bit binary)
VCO is linux_x86_64 (64-bit
binary)
Windows2 Minimalist GNU for Windows yes no 2.0.1
(MinGW)
gcc 4.2.1— VCO is win32
1. Header files location: <path to questa install tree>/include/systemc/sc22
2. 32-bit executable and 32-bit gcc can be used with 64-bit Windows systems, though they only run as
32-bit binaries.

Table 8-3 shows how to specify a SystemC kernel (either 2.3.1 or 2.2) and a compiler version
using the sccom, vopt, and vsim commands with the -sc22 and -cppinstall options. The -sc22
and -cppinstall options must be used with sccom for compiling and linking, as well as with vopt
for optimization and vsim for simulation.

ModelSim® SE User's Manual, v10.7 381

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Building gcc with Custom Configuration Options

Table 8-3. Specifying SystemC Platform and Compiler Version

Command SystemC kernel/compiler version
sccom/vopt/vsim (No options - default) SC-2.3.1 / gcc-5.3.0
sccom/vopt/vsim cppinstall 4.7.4 SC-2.3.1 / gcc-4.7.4
sccom/vopt/vsim -cppinstall 4.5.0 SC-2.3.1 / gcc-4.5.0
sccom/vopt/vsim -sc22 SC-2.2 / gcc-4.5.0

Building gcc with Custom Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Building gcc with Custom Configuration Options

The gcc configuration for ModelSim has been qualified only for default options. If you use
advanced gcc configuration options, ModelSim may not work with those options.
To use a custom gcc build, set the CppInstall variable in the modelsim.ini file. This variable
specifies the pathname to the compiler binary you intend to use.

When using a custom gcc, ModelSim requires that you build the custom gcc with several
specific configuration options. These vary on a per-platform basis, as shown in the following
table:
Table 8-4. Custom gcc Platform Requirements
Platform Mandatory configuration options
Linux none
Win32 --with-gnu-as
(MinGW) --with-gnu-ld

• sjlj-exceptions or setjump longjump exceptions do not work with SystemC. It can cause
problems with catching exceptions thrown from SC_THREAD and SC_CTHREAD.
• Always build the compiler with --disable-sjlj-exceptions and never with --enable-sjlj-
exceptions.
• binutils-2.17 and binutils-2.18 do not work. Do not attempt to use those on win32
atleast.
If you do not have a GNU binutils2.16 assembler and linker, you can use the as and ld
programs. They are located inside the gcc in directory:

<install_dir>/lib/gcc-lib/<gnuplatform>/<ver>

382 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Building gcc with Custom Configuration Options

The location of the as and ld executables has changed since gcc-3.4. For all gcc-4.x releases, as
and ld are located in:

<install_dir>/libexec/gcc/<gnuplatform>/<ver>

By default ModelSim also uses the following options when configuring built-in gcc:

• --disable-nls
• --enable-languages=c,c++
These are not mandatory, but they do reduce the size of the gcc installation.

ModelSim® SE User's Manual, v10.7 383

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Usage Flow for SystemC-Only Designs

Usage Flow for SystemC-Only Designs

ModelSim allows users to simulate SystemC, either alone or in combination with other VHDL/
Verilog modules.
The following is an overview of the usage flow for strictly SystemC designs. The remainder of
this chapter provides more detailed information on how to use SystemC designs with
ModelSim.

1. Create and map the working design library with the vlib and vmap statements, as
needed.
2. If you are simulating sc_main() as the top-level, skip to Step 3. Also, refer to
“Recommendations for using sc_main at the Top Level,” below.
If you are simulating a SystemC top-level module instead, then modify the SystemC
source code to export the top level SystemC design unit(s) using the
SC_MODULE_EXPORT macro. Refer to “Modifying SystemC Source Code” for
information and examples on how to convert sc_main() to an equivalent module.
3. Analyze the SystemC source using the sccom command, which invokes the native C++
compiler to create the C++ object files in the design library. Optionally, you can
distribute the compile of multiple source files across multiple machines.
See Using sccom in Addition to the Raw C++ Compiler for information on when you
are required to use sccom as opposed to another C++ compiler.
4. Perform a final link of the C++ source using sccom -link, and -sc22 if running SystemC
2.2. This process creates a shared object file in the current work library which will be
loaded by vsim at runtime.
You must rerun sccom -link before simulation if any new sccom compiles were
performed.
5. Load the design into the simulator using the standard ModelSim vsim command.
6. Run the simulation using the run command, which you enter at the VSIM> command
prompt.
7. Debug the design using ModelSim GUI features, including the Source and Wave
windows.
Recommendations for using sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Simulating with sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Checkpoint and Restore in a SystemC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

384 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Recommendations for using sc_main at the Top Level

Recommendations for using sc_main at the Top

Level
Generally, your design should include sc_main() at the top level in order for ModelSim to run
the SystemC/C++ source code. ModelSim executes sc_main() as a thread process. This allows
you to use test bench code and C++ variables (including SystemC primitive channels, ports, and
modules) inside sc_main().
If your design does not have sc_main() at the top level, you must apply several modifications to
your original SystemC source code—refer to “Modifying SystemC Source Code.”

Example 8-1. A Simple SystemC-only sc_main():

int
sc_main(int, char*[])
{
design_top t1 = new design_top("t1");
sc_start(-1);
delete t1;
return 1;
}

Concepts Related to Having sc_main at the Top Level

Several concepts should be kept in mind when you incorporate sc_main at the top level of your
SystemC design.

• ModelSim executes sc_main() in two parts:

o The code before the first call to sc_start() — executed during the construction phase
of all other design tops.
o The code after the first sc_start() or any other subsequent sc_start()'s — executed
based on the sc_start() arguments.
The overall simulation is controlled by the ModelSim prompt and the sc_start() call does
not proceed unless an appropriate run command is issued from the ModelSim prompt.
sc_start() always yields to ModelSim for the time specified in its argument. Example:
int
sc_main(int, char*[])
{
top t1("t1");
sc_signal<int> reset("reset");
t1.reset(reset);
t2->reset(reset);
sc_start(100, SC_NS); <-------- 1st part executed during
construction. Yield to the
kernel for 100 ns.

ModelSim® SE User's Manual, v10.7 385

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Recommendations for using sc_main at the Top Level

reset = 1; <-------- Executed only if

run 100 ns or more is issued
from batch or GUI prompt.

sc_start(100, SC_NS); <-------- Yield to the kernel for

another
100 ns

return 1; <-------- Executed only if

the simulation in run for
more than 200 ns.
}

sc_start(-1) in the OSCI simulator means that the simulation is run until the time it is
halted by sc_stop(), or because there were no future events scheduled at that time. The
sc_start(-1) in means that sc_main() is yielding to the ModelSim simulator until the
current simulation session finishes.
• Avoid sc_main() going out of scope — Since sc_main() is run as a thread, it must not go
out of scope or delete any simulation objects while the current simulation session is
running. The current simulation session is active unless a quit, restart, sc_stop, $finish,
or assert is executed, or a new design is loaded. To avoid sc_main() from going out of
scope or deleting any simulation objects, sc_main() must yield control to the ModelSim
simulation kernel before calling any delete and before returning from sc_main. In
ModelSim, sc_start(-1) gives control to the ModelSim kernel until the current
simulation session is exited. Any code after the sc_start(-1) is executed when the current
simulation ends.
int
sc_main(int, char*[])
{
top t1("t1");
top* t2 = new top("t2");
sc_signal<int> reset("reset");
t1.reset(reset);
t2->reset(reset);
sc_start(100, SC_NS); <-------- 1st part executed during
construction. yield to the
kernel for 100 ns.

reset = 1; <-------- Will be executed only if

run 100 ns or more is issued
from batch or GUI prompt.

sc_start(100, SC_NS); <-------- Yield to the kernel for another

100 ns

sc_start(-1); <-------- Will cause sc_main() to

suspend until the end of
the current simulation session

delete t2; <-------- Will be executed at the

end of the current simulation
session.

386 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Simulating with sc_main at the Top Level

return 1;}

If the run command specified at the simulation prompt before ending the current
simulation session exceeds the cumulative sc_start() times inside sc_main(), the
simulation continues to run on design elements instantiated both by sc_main() and
outside of sc_main(). For example, in this case, if sc_main() instantiates an sc_clock, the
clock will continue to tick if the simulation runs beyond sc_main().
On the other hand, if the current simulation ends before the cumulative sc_start() times
inside sc_main, the remainder of the sc_main will be executed before quitting the
current simulation session if the ScMainFinishOnQuit variable is set to 1 in the
modelsim.ini file. If this variable is set to 0, the remainder of sc_main will not executed.
The default value for this variable is 1. One drawback of not completely running
sc_main() is that memory leaks might occur for objects created by sc_main. Also, it is
possible that simulation stimulus and execution of the test bench will not complete, and
thus the simulation results will not be valid.
• sc_cycle(sc_time) is deprecated in SystemC 2.2. A suggested alternative to sc_cycle is
sc_start(sc_time). In case of a cycle accurate design, this will yield the same behavior.
ModelSim will always convert sc_cycle() to sc_start() with a note.
• sc_initialize() is also deprecated in SystemC 2.2. The replacement for sc_initialize() is
sc_start(SC_ZERO_TIME). ModelSim treats sc_initialize() as
sc_start(SC_ZERO_TIME).
• ModelSim treats sc_main() as a top-level module and creates a hierarchy called sc_main
for it. Any simulation object created by sc_main() will be created under the sc_main
hierarchy in ModelSim. For example, for the sc_main() described above, the following
hierarchy will be created:
/
|
|-- sc_main
|
|-- t1
|-- t2
|-- reset

The name() method for all objects created under the sc_main hierarchy will contain the
sc_main scope name. If applied to vsim, the -noscmainscopename argument will strip
the sc_main scope name from the names returned by the name() method.

Simulating with sc_main at the Top Level

Simulating with sc_main at the top level of your design can be accomplished as described here.
Prerequisites
• Must be running ModelSim 6.3 or higher.

ModelSim® SE User's Manual, v10.7 387

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Checkpoint and Restore in a SystemC Design

Procedure
1. To simulate in ModelSim using sc_main() as the top-level in your design:
2. Run vsim with sc_main as the top-level module:
vsim -c sc_main

3. Explicitly name all simulation objects for mixed-language designs, or to enable debug
support of objects created by sc_main(). Pass the declared name as a constructor
arguments, as follows:
sc_signal<int> sig("sig");
top_module* top = new top("top");

Tip
: For SystemC-only designs, the simulation runs even if debug support is not
enabled. Mixed language designs, however, will not elaborate if explicit naming is
not performed in sc_main(). ModelSim issues an error message to this effect.

4. Optionally, override the default stack size (10Mb) for sc_main() in the modelsim.ini file:
ScMainStackSize 1 Gb

See ScMainStackSize variable for more information.

Checkpoint and Restore in a SystemC Design

Generally, if a design contains one or more SystemC modules, the checkpoint and restore
feature is disabled for the entire design. However, with some SystemC modules, you can use the
-scchkpntrestore argument of the vsim command to allow checkpoint and restore.
In most occurrences of SystemC in a mixed-language design, the checkpoint and restore feature
is disabled for the entire design. However, if the SystemC hierarchy is dummy wrapper without
any active constructs (such as signals, variables, or processes), you can use vsim -
scchkpntrestore to allow checkpoint and restore on the design.

If you use use vsim -scchkpntrestore on a design that has active SystemC regions, ModelSim
will issue one or more warning messages to indicate that allowing checkpoint and restore is not
expected usage—ModelSim will try to ignore unsupported usage and proceed with simulation.
For example:

# ** Warning: (vsim-6699) SystemC checkpoint/restore flow does not allow

sc_event: '/top/dut/myevent' in the design. If 'sc_events(s)' are actively
used by the design, then design may not simulate correctly.

# ** Warning: (vsim-6699) SystemC checkpoint/restore flow does not allow

variable: '/top/dut/myvar' in the design. If 'variable(s)' are actively
used by the design, then design may not simulate correctly.

388 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Creating Shared Object Files for SystemC Code

However, if the usage cannot be ignored (SystemC processes are present), ModelSim will
produce a fatal runtime error. For example:

# ** Warning: (vsim-6699) SystemC checkpoint/restore flow does not allow

# SC_THREAD/SC_CTHREAD: '/top/dut/main_action' in the design.
# If 'SC_THREAD(s)/SC_CTHREAD(s)' are actively used by the design,
# then design may not simulate correctly.

# ** Fatal: (vsim-6604) unable to create process /top/dut/main_action

# ** Fatal: Fatal SystemC error detected, exiting...<
# Time: 0 ns Iteration: 0 Instance: /top/dut File: src/sc_args/test.h
# FATAL ERROR while loading design
# Error loading design

Creating Shared Object Files for SystemC

Code
The simulator has the ability to create intermediate shared object files for SystemC. These
intermediate shared object files can then be linked together to create the final shared object file
for simulation use.
This method of managing can reduce both disk space and linking time for large SystemC
environments.

Consider the following scenario: You have a SystemC file that is used in all of your tests,
common.cpp, and then you have test-specific SystemC files, such as test1.cpp, test2.cpp, and so
on. The following example procedure shows how you can manage your tests and common code.

Prerequisites
• Must be running ModelSim 6.6a or higher.
Procedure
1. Create a library for your intermediate shared object:
vlib common

2. Compile all common SystemC files into this library:

sccom -work common common.cpp

3. Link the files to create an intermediate shared object:

sccom -linkshared -work common

4. Create a library for your SystemC test code:

vlib test1
vlib test2

ModelSim® SE User's Manual, v10.7 389

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Creating Shared Object Files for SystemC Code

5. Compile the test-specific code into each library:

sccom -work test1 test1.cpp
sccom -work test2 test2.cpp

6. Link the test specific object files with the shared object in each of the test libraries:
sccom -link -libshared common -lib test1 -work test1
sccom -link -libshared common -lib test2 -work test2

where -libshared specifies the location of the intermediate shared object, -lib specifies
the library that contains the compiled object files, and -work specifies the location of the
final systemc.so.
7. Run the tests:
vsim -lib work1 top
vsim -lib work2 top

Note
To run the above steps with SystemC-2.2 instead of the default SystemC-2.3.1, use
the
-sc22 argument in each of the steps.

390 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Binding to Verilog or SystemVerilog Designs

Binding to Verilog or SystemVerilog Designs

The SystemVerilog bind construct allows you to bind a Verilog or SystemVerilog design unit to
a SystemC module.
This is especially useful for binding SystemVerilog assertions to your SystemC, VHDL,
Verilog and mixed designs during verification. See The SystemVerilog bind Construct in
Mixed-Language Designs.

Limitations of Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Limitations of Bind Support for SystemC

Certain restrictions apply to actual expressions when you bind to SystemC targets. If the target
of a bind is a SystemC module or an instance of a SystemC module, expressions and literals are
not supported as actuals.
These include, but are not limited to:

• bitwise binary expressions using operators &, |, ~, ^ and ^~

• concatenation expression
• bit select and part select expressions
• variable/constant

Distributing SystemC IP
This section describes several methods you can use to distribute your SystemC IP for others to
use in a ModelSim environment.
One requirement is that you, the IP provider, must distribute the IP library for each major
release version (such as 10.2 or 10.3). Patch releases (such as 10.1b or 10.2a) are mostly
backward compatible, and therefore do not require you to recompile libraries with each patch.
However, sometimes the SystemC header files may be modified. In such situations, you must
distribute a recompiled library for a patch release.

• Distribute source files

You can distribute non-compiled source files that can be compiled and simulated by the
IP user for use with sccom and vsim along with their user code.
• Distribute IP as archived libraries
To create a static library perform the following actions:
vlib <work_library>

ModelSim® SE User's Manual, v10.7 391

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Distributing SystemC IP

sccom <options> <source files>

sccom -archive <archive_file_name>

where you distribute the archived library archive_file_name to IP users. However, you
should note that there will not be any debug information generated for the IP.
• Distribute IP as shared libraries
To create a shared library perform the following actions:
vlib <work library>
sccom <options> <source files>
sccom -linkshared -work <work_library>

where sccom -linkshared creates an intermediate SystemC shared library at

<work_library>/_sc/<platform_compiler-version>/systemc.so.
You should inform the IP user that they must link this intermediate shared object along
with their code to create final systemc.so, which will be loaded during simulation. Refer
to “Creating Shared Object Files for SystemC Code” for more information.
• Distribute IP without debug information
In order to distribute a SystemC IP without any debug information the SystemC sources
need to be compiled using the -nodebug argument with the sccom command. All files
containing an SC_MODULE_EXPORT() macro call must NOT be compiled with the
sccom -nodebug argument; otherwise, the design will fail to load.
o If you are distributing a SystemC test library in an archive format, make sure to
compile with -nodebug argument. There is no need to specify the -nodebug
argument during the 'sccom -archive' step. For example,
sccom -nodebug <source files>
sccom -archive <archive_file_name>

o If you are distributing a SystemC test shared library that was created using the
-linkshared or -link arguments with the sccom command, the -nodebug argument
needs to be specified during the compile time and link time. For example,
Linkshared flow
sccom -nodebug <source files>
sccom -nodebug -linkshared -work <work_library>

Normal link flow

sccom -nodebug <source files>
sccom -nodebug -link -work <work_library>

Compiling and linking a SystemC design using the -nodebug argument with the sccom
command will only affect the debug visibility of the objects in the GUI. This will not
affect the simulation results in any way.

392 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Distributing SystemC IP

The ModelSim SystemC libraries may contain third-party software, including open source
software. Refer to the "Third-Party Software for Questa and ModelSim Products"
documentation for licensing terms. If you distribute your SystemC IP to others, you are required
to meet the licensing terms of the third-party software included in the ModelSim SystemC
libraries, as well as the licensing terms provided to you by Mentor Graphics. Should you have
further questions about your obligations, please seek legal advice.

ModelSim® SE User's Manual, v10.7 393

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Compiling SystemC Files

Compiling SystemC Files

The process of compiling the SystemC files contained in your design consists of several steps.
The basic steps for this overall process to compile a SystemC design are the following:

• Create a design library

• Modify SystemC source code if using design units as top-level
• Run SystemC compiler (the sccom command)
• Run SystemC linker (the sccom -link command argument)
Creating a Design Library for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Exporting All Top-Level SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Invoking the SystemC Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Distributed sccom Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Compiling Optimized and/or Debug Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Specifying an Alternate g++ Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Verifying Compiler Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Maintaining Portability Between OSCI and the Simulator. . . . . . . . . . . . . . . . . . . . . . . 397
Using sccom in Addition to the Raw C++ Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Incremental Compilation (Compile of Changed Files Only) . . . . . . . . . . . . . . . . . . . . . . 400
Issues with C++ Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
SCV Extensions for User-specified Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Mentor Dynamic Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Creating a Design Library for SystemC

Use vlib to create a new library in which to store the compilation results. For example:
vlib work

This creates a library named work. By default, compilation results are stored in the work
library.

The work library is actually a subdirectory named work. This subdirectory contains a special
file named _info.

Note
Do not create libraries using UNIX commands—always use the vlib command.

See vlib and Design Libraries for additional information on working with libraries.

394 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Exporting All Top-Level SystemC Modules

Since it is natural for simulators to elaborate design-unit(s) as tops, it is recommended that you
use design units as your top-level rather than relying on sc_main based elaboration and
simulation. There are a few limitations and requirements for running a sc_main() based
simulation.

If you have a sc_main() based design and would like to convert it to a design-unit based one, a
few modifications must be applied to your SystemC source code. To see example code
containing the code modifications detailed in Modifying SystemC Source Code, see Code
Modification Examples.

Exporting All Top-Level SystemC Modules

SystemC templates are not supported as top level or boundary modules. For SystemC designs,
you must export all top level modules in your design to ModelSim. To accomplish this, use the
SC_MODULE_EXPORT(<sc_module_name>) macro.
• The sc_module_name is the name of the top level module to be simulated in ModelSim.
• You must specify the macro in a C++ source (.cpp) file. If the macro is contained in a
header file instead of a C++ source file, an error may result.
Related Topics
Templatized SystemC Modules

Invoking the SystemC Compiler

ModelSim compiles one or more SystemC design units with a single invocation of sccom, the
SystemC compiler. The design units are compiled in the order that they appear on the command
line.
For SystemC designs, all design units must be compiled just as they would be for any C++
compilation. An example of an sccom command might be:

sccom -I ../myincludes mytop.cpp mydut.cpp

Related Topics
sccom command [ModelSim SE Command Reference Manual]

Distributed sccom Compilation

ModelSim can distribute the sccom compilation.You can instruct the compiler to run the
specified source files in parallel on multiple cores of a single machine (the current machine
running sccom) using the -j <value> option, where <value> is the maximum number of
processes to be run in parallel.

ModelSim® SE User's Manual, v10.7 395

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Compiling Optimized and/or Debug Code

Additionally, you can distribute the compilation process to multiple cores across multiple
machines by specifying the -machines <hosts.txt> option along with the -j <value> option. You
can also specify a maximum number of processes for a particular machine specified in the hosts
file. All host machines specified must be accessible from the machine where the sccom
command is run.

Related Topics
sccom command [ModelSim SE Command Reference Manual]

Compiling Optimized and/or Debug Code

By default, sccom invokes the C++ compiler (g++ or aCC) without any optimizations. If
desired, you can enter any g++/aCC optimization arguments at the sccom command line.
Also, source level debug of SystemC code is not available by default in ModelSim. To compile
your SystemC code for source level debugging in ModelSim, use the g++/aCC -g argument on
the sccom command line.

Reducing Compilation Time for Non-Debug Simulations

If the SystemC objects in the design need not be visible in the ModelSim simulation database,
you can save compilation time by running sccom with the -nodebug argument. This bypasses
the parser which creates the ModelSim debug database. However, all files containing an
SC_MODULE_EXPORT() macro call must NOT be compiled with the sccom -nodebug
argument, otherwise the design fails to load.

This approach is useful if you are running a design in regression mode, or creating a library (.a)
from the object files (.o) created by sccom, to be linked later with the SystemC shared object.

Related Topics
sccom command [ModelSim SE Command Reference Manual]

Specifying an Alternate g++ Installation

Mentor Graphics recommends using the version of g++ that is shipped with ModelSim on its
various supported platforms.
However, if you want to use your own installation, you can do so by setting the CppInstall
variable in the modelsim.ini file to the g++ executable location. For example, if your g++
executable is installed in /u/abc/gcc-4.2.1/bin, then you would set the variable as follows:

CppPath /u/abc/gcc-4.2.1/bin/g++

396 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Verifying Compiler Information

Verifying Compiler Information

Use the sccom command to retrieve information about the GNU compiler to be used for
compilation.
Prerequisites
• Creating a Design Library for SystemC
Procedure
1. Execute the command:
sccom -gnuversion

2. Analyze the results

*** GNU compiler version: <version_number>

*** GNU compiler path: <executable_path>

Maintaining Portability Between OSCI and the

Simulator
If you intend to simulate on both ModelSim and the OSCI proof-of-concept SystemC simulator,
you can use the MTI_SYSTEMC macro to execute the ModelSim specific code in your design
only when running ModelSim. Sccom defines this macro by default during compile time.
Using the original and modified code, you might write the code as follows:

#ifdef MTI_SYSTEMC //If using the ModelSim simulator, sccom compiles this
SC_MODULE(mytop)
{
sc_signal<bool> mysig;
mymod mod;

SC_CTOR(mytop)
: mysig("mysig"),
mod("mod")
{
mod.outp(mysig);
}
};

SC_MODULE_EXPORT(top);

#else //Otherwise, it compiles this

int sc_main(int argc, char* argv[])
{
sc_signal<bool> mysig;
mymod mod("mod");
mod.outp(mysig);

ModelSim® SE User's Manual, v10.7 397

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Maintaining Portability Between OSCI and the Simulator

sc_start(100, SC_NS);
}
#endif

398 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Using sccom in Addition to the Raw C++ Compiler

Using sccom in Addition to the Raw C++ Compiler

When compiling complex C/C++ test bench environments, it is common to compile code with
many separate runs of the compiler. Often, you may compile code into archives (.a files), and
then link the archives at the last minute using the -L and -l link options.
When using SystemC, you may also want to compile a portion of your C design using raw g++
or aCC instead of sccom. (Perhaps you have some legacy code or some non-SystemC utility
code that you want to avoid compiling with sccom.) You can do this; however, some cautions
and rules apply.

Rules for sccom Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Rules for Using Raw g++ to Compile Non-SystemC C/C++ Code . . . . . . . . . . . . . . . . . 399

Rules for sccom Use

The rules governing when and how you must use sccom are as follows.
• You must compile all code that references SystemC types or objects using sccom.
• When using sccom, you should not use the -I compiler option to point the compiler at
any search directories containing OSCI or any other vendor supplied SystemC header
files. sccom does this for you accurately and automatically.
• If you do use the raw C++ compiler to compile C/C++ functionality into archives or
shared objects, you must then link your design using the -L and -l options with the
sccom -link command. These options effectively pull the non-SystemC C/C++ code
into a simulation image that is used at runtime.
Failure to follow the above rules can result in link-time or elaboration-time errors due to
mismatches between the OSCI or any other vendor supplied SystemC header files and the
ModelSim SystemC header files.

Rules for Using Raw g++ to Compile Non-SystemC C/C++

Code
If you use raw g++ to compile your non-systemC C/C++ code, the following rules apply.
• The -fPIC option to g++ should be used during compilation with sccom.
• For C++ code, you must use the built-in g++ delivered with ModelSim, or (if using a
custom g++) use the one you built and specified with the CppInstall variable in the
modelsim.ini file.
Otherwise binary incompatibilities may arise between code compiled by sccom and code
compiled by raw g++.

ModelSim® SE User's Manual, v10.7 399

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Incremental Compilation (Compile of Changed Files Only)

Incremental Compilation (Compile of Changed Files

Only)
You can use sccom -incr to enable automatic incremental compilation so that only changed files
are compiled. This allows ModelSim to determine which source files have changed and
recompile only those source files.
A changed file is re-compiled in the following cases:

• Its pre-processor output is different from the last time it was successfully compiled (see
Note below). This includes changes in included header files and to the source code itself.
• You invoke sccom with a different set of command-line options that have an impact on
the gcc command line. Preserving all settings for the gcc command ensures that
ModelSim re-compiles source files when a different version of gcc is used or when a
platform changes.

Note
Pre-processor output is used because it prevents compilation on a file with the
following types of changes:

• Access or modification time (touch)

• Changes to comments—except changes to the source code that affect
line numbers (such as adding a comment line) will cause all affected files to be
recompiled. This occurs to keep debug information current so that ModelSim
can trace back to the correct areas of the source code.

Example
The following example shows how to compile a SystemC design with automatic incremental
compilation.

1. Run sccom -incr on three files and re-link all compiled files in the design.
% sccom -incr top.cpp and2.cpp or2.cpp
Model Technology ModelSim SE sccom DEV compiler 2003.05 Mar 2 2008
Exported modules:
top
% sccom -incr -link
Model Technology ModelSim SE sccom DEV compiler 2003.05 Mar 2 2008

2. After changing functional content of the top module, re-compile and re-link.
% sccom -incr top.cpp and2.cpp or2.cpp
Model Technology ModelSim SE sccom DEV compiler 2003.05 Mar 2 2008

-- Skipping file and2.cpp

-- Skipping file or2.cpp

400 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Incremental Compilation (Compile of Changed Files Only)

Exported modules:
top

% sccom -incr -link

Model Technology ModelSim SE sccom DEV compiler 2003.05 Mar 2 2008

3. Link again without actually changing any file.

% sccom -incr -link
Model Technology ModelSim SE sccom DEV compiler 2003.05 Mar 2 2008
-- Skipping linking

Note
You must compile all included libraries (using -lib) with -incr for automatic incremental
compilation to work in linking mode. Failing to do so generates an error.

Limitations
• Automatic incremental compile is only supported for source files compiled with sccom.
ModelSim does not track files for changes if they are compiled directly using a C++
compiler.
• Physically moving the library that holds a shared object forces re-creating that shared
object next time. This applies only to the directories holding the shared object, not to the
libraries that hold object files.
• If the SystemC source file includes a static library, then any change in that static library
will not cause ModelSim to recompile the source file.
• If a design file consists of more than one SystemC module, changing even one module
causes ModelSim to recompile the entire source file (and all the modules contained in
it), regardless of whether the other modules were changed or not.
• Automatic incremental archiving is not supported (if you use the -archive argument, the
-incr argument has no effect).

ModelSim® SE User's Manual, v10.7 401

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Issues with C++ Templates

Issues with C++ Templates

Using a C++ template for a SystemC module has restrictions regarding location, member
function visibility to the compiler, and template specialization for SystemC verification (SCV).
The various issues related to C++ templates are as follows.

Templatized SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Organizing Templatized Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Generating SystemC Verification Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Templatized SystemC Modules

Templatized SystemC modules are not supported for use in the following locations:
• the top level of the design
• the boundary between SystemC and higher level HDL modules (for instance, the top
level of the SystemC branch)
To convert a top level templatized SystemC module, you can either specialize the module to
remove the template, or you can create a wrapper module that you can use as the top module.

For example, assume you have the following templatized SystemC module:

template <class T>

class top : public sc_module
{
sc_signal<T> sig1;
...
};

You can specialize the module by setting T = int, thereby removing the template, as follows:

class top : public sc_module

{
sc_signal<int> sig 1;
...
};

402 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Issues with C++ Templates

Or, alternatively, you could write a wrapper to be used over the template module:

class modelsim_top : public sc_module

{
top<int> actual_top;
...
};

SC_MODULE_EXPORT(modelsim_top);

Organizing Templatized Code

Suppose you have a class template, and it contains a certain number of member functions. All
those member functions must be visible to the compiler when it compiles any instance of the
class.
For class templates, the C++ compiler generates code for each unique instance of the class
template. Unless the compiler can read the full implementation of the class template, it cannot
generate code for it, which leaves the invisible parts as undefined. Since it is legal to have
undefined symbols in a .so file, sccom -link will not produce any errors or warnings. To make
functions visible to the compiler, you must move them to the .h file.

Generating SystemC Verification Extensions

The data introspection for SystemC verification (SCV) depends on partial template
specialization of a template called scv_extensions. This template extends data objects with the
abstract interface scv_extensions_if. Each specialization of the scv_extensions template
implements the scv_extensions_if interface in a way appropriate to the type in the template
parameter.
This section introduces a utility (sccom -dumpscvext) that automatically generates SCV
extensions for any given type of data object.

Use of Extensions
You must include the declaration of all types (for which you want extensions to be generated) in
a header file.

For example, assume you want to generate extensions for packet_t.

1. Define a header file similar to the following:

typedef struct {
int packet_type;
int src;
int dest;
int payload;
}packet_t;

ModelSim® SE User's Manual, v10.7 403

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Issues with C++ Templates

2. Creates a C++ file (.cpp) that includes all the header files that have all the type
declarations and define a global variable for each type you want to extend.
Result: The C++ file for the above type looks like this:
#include "test.h"
packet_t pack;

3. For class templates, you need to instantiate each specialization.

For example, if packet_t were a class template, you could do something like this:
packet_t<int> pack1;
packet_t<long> pack2;
...

4. Run the sccom -dumpscvext command to dump SCV extensions for all the types for
whom global variables have been defined in the C++ file.
sccom -dumpscvext mypacket.cpp

where mypacket.cpp is the name of the C++ file containing global variable definitions.
Result: The generated extensions are displayed in stdout (similar to the way scgenmod
dumps a foreign module declaration).

Note
You must define global variables for all types for which extensions need to be
generated. The sccom -dumpscvext command will cause an error out if it cannot find
any global variables defined in the supplied C++ file.

The command also automatically inserts the following header in mypacket.cpp with the
generated extensions:
#ifndef TYPENAME_H
#define TYPENAME_H
#include "scv.h"
<generated extensions>

#endif

Note
If extensions are generated for more than one type, the type name of the first type
will be used as TYPENAME in the ifndef preprocessor.

Supported Object Types

The following is a list of simple data types that are supported by the sccom -dumpscvext
command, along with the extension generated for each type.

404 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Issues with C++ Templates

Table 8-5. Generated Extensions for Each Object Type

SystemC Data Object Type Generated Extension
bool scv_extensions<bool>
char scv_extensions<char>
short scv_extensions<short>
int scv_extensions<int>
long scv_extensions<long>
long long scv_extensions<long long>
unsigned char scv_extensions<unsigned char>
unsigned short scv_extensions<unsigned short>
unsigned int scv_extensions<unsigned int>
unsigned long scv_extensions<unsigned long>
unsigned long long scv_extensions<unsigned long long>
float scv_extensions<float>
double scv_extensions<double>
string scv_extensions<string>
pointer scv_extensions<T*>
array scv_extensions<T[N]>
sc_string scv_extensions<sc_string>
sc_bit scv_extensions<sc_bit>
sc_logic scv_extensions<sc_logic>
sc_int scv_extensions<sc_int<W>>
sc_uint scv_extensions<sc_uint<W>>
sc_bigint scv_extensions<sc_bigint<W>>
sc_biguint scv_extensions<sc_biguint<W>>
sc_bv scv_extensions<sc_bv<W>>
sc_lv scv_extensions<sc_lv<W>>

Related Topics
SCV Extensions for User-specified Types

ModelSim® SE User's Manual, v10.7 405

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
SCV Extensions for User-specified Types

SCV Extensions for User-specified Types

This section explains the rules for generating SCV extensions for user-specified types such as
structures, unions, classes, and enums.
Structures and Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Structures and Classes

Note the following set of rules for generating a SCV extensions for a structure or class.
• Generated extensions start with macro SCV_EXTENSIONS(), and typename is the
name of the user-specified type.
• All types in the generated extension are public and follow the same mapping table as
simple types.
• Private members of the struct/class are ignored unless the extensions class is made a
friend of the user-specified type. In the latter case, all private members of the class are
made public in the generated extension.
• Generated extensions contain a constructor defined by the macro
SCV_EXTENSIONS_CTOR(), and typename is the name of the user-specified type.
• A SCV_FIELD entry is added in constructor for each generated extension.
The following examples demonstrate the generation process for a structure and class types.

Example 8-2. Generating SCV Extensions for a Structure

/* SystemC type */

struct packet_t {
sc_uint<8> addr;
sc_uint<12> data;
};

/* Generated SCV Extention */

SCV_EXTENSIONS(packet_t) {
public:
scv_extensions< sc_uint<8> > addr;
scv_extensions< sc_uint<12> > data;

SCV_EXTENSIONS_CTOR(packet_t) {
SCV_FIELD(addr);
SCV_FIELD(data);
}
};

406 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
SCV Extensions for User-specified Types

Example 8-3. Generating SCV Extensions for a Class without Friend

(Private Data Not Generated)

/* SystemC type */

class restricted_t {
public:
sc_uint<8> public_data;
private:
sc_uint<8> private_data;
};

/* Generated SCV Extension */

SCV_EXTENSIONS(restricted_t) {
public:
scv_extensions< sc_uint<8> > public_data;

SCV_EXTENSIONS_CTOR(restricted_t) {
SCV_FIELD(public_data);
}
};

Example 8-4. Generating SCV Extensions for a Class with Friend

(Private Data Generated)

/* SystemC type */

class restricted_t {
friend class scv_extensions<restricted_t>;

public:
sc_uint<8> public_data;
private:
sc_uint<8> private_data;
};

/* Generated SCV Extension */

SCV_EXTENSIONS(restricted_t) {
public:
scv_extensions< sc_uint<8> > public_data;
scv_extensions< sc_uint<8> > private_data;

SCV_EXTENSIONS_CTOR(restricted_t) {
SCV_FIELD(public_data);
SCV_FIELD(private_data);
}
};

Enums
Note the following set of rules for generating a SCV extensions for enumerated types.

ModelSim® SE User's Manual, v10.7 407

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
SCV Extensions for User-specified Types

• Generated extensions start with macro SCV_ENUM_EXTENSIONS(), and typename is

the name of the enumerated type.
• Generated extensions consists of only a constructor defined by the macro
SCV_ENUM_CTOR(), and typename is the name of the user-specified type.
• A SCV_ENUM entry are added in constructor for each element of the enumerated type.
The following example demonstrates the generation process for an enumerated type.

Example 8-5. Generating SCV Extensions for an Enumerated Type

/* SystemC type */

enum instruction_t { ADD, SUB = 201 };

/* Generated SCV Extension */

SCV_ENUM_EXTENSIONS(instruction_t) {
public:

SCV_ENUM_CTOR(instruction_t) {
SCV_ENUM(ADD);
SCV_ENUM(SUB);
}
};

408 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Mentor Dynamic Extensions

Mentor Dynamic Extensions

The OSCI-SCV library has been modified to support Mentor Dynamic Extensions, which allow
the following:
Named Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Constrained Randomization of the Data Type for Standard Vectors . . . . . . . . . . . . . . 411
Randomly Sized Fixed-Max Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Named Constraints
The open SCV API supports the following macros for creating constraint data expression
initializers data member fields of a user-defined constraint, based on a derivation of class
scv_constraint_base:
#define SCV_CONSTRAINT(expr)
#define SCV_SOFT_CONSTRAINT(expr)

The first defines a hard constraint and the second defines a soft constraint.

The following example shows a user-defined constraint that uses these macros in the SCV
constraint constructor macro, SCV_CONSTRAINT_CTOR().

Example 8-6. User-Defined Constraint

class EtherFrameConstraintT : virtual public scv_constraint_base {

public:
scv_smart_ptr<unsigned> Type;
scv_smart_ptr<unsigned long long> DestAddr;
scv_smart_ptr<unsigned long long> SrcAddr;
scv_smart_ptr<unsigned> CRC;
scv_smart_ptr<EtherFramePayloadT> Payload;

SCV_CONSTRAINT_CTOR( EtherFrameConstraintT ){
printf( "Start initializing EtherFrameConstraint ...\n" );
SCV_CONSTRAINT( Type() == (SDF_BYTE << 8 | SDF_BYTE) );
SCV_CONSTRAINT( DestAddr() != SrcAddr() );
SCV_CONSTRAINT( DestAddr() < 0xffLL ); // Limit to 48 bits
SCV_CONSTRAINT( SrcAddr() < 0xffLL ); // Limit to 48 bits
}
};

To augment these macros, the following macro allows a constraint field to be named:

#define SCV_NAMED_CONSTRAINT(type, name, expr)

which uses the following arguments:

• type — the type of the constraint (HARD/SOFT), specified as

scv_constraint_expr::scv_constraint_type.

ModelSim® SE User's Manual, v10.7 409

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Mentor Dynamic Extensions

• name — the actual name given to the constraint.

• expr — the expression argument that is passed exactly as in the existing macros
SCV_CONSTRAINT() and SCV_SOFT_CONSTRAINT().
To support the constraint type (hard or soft), the following class is defined with an enum type
that you can use specify type:

class scv_constraint_expr {
public:
typedef enum { HARD, SOFT } scv_constraint_type;
scv_constraint_expr(
const char* name, scv_constraint_type type, scv_expression e,
const char* file = "unknown", int line = 0 );

const char *name() const;

const char *file() const;
int line() const;

void disable();
void enable();
bool is_disabled() const;
};

When the constraint is created, the file name and line # are captured in the class
scv_constraint_expr object so that it can be provided later to parts of the internal SCV
implementation for reporting purposes, such as error messages. You can do this by referencing
the ANSI C FILE and LINE directives at the point where the name constraint is constructed.
Accessors ::name(), ::file(), and ::line() are provided to class scv_constraint_expr as shown
above to provide this information for messaging, if needed.

Dynamic Enabling and Disabling of Named Constraints

You can enable and disable constraints that have been created with names in accordance with
the naming macro described in Named Constraints (above). To support this feature, class
scv_constraint_base contains the following methods:

class scv_constraint_base {
...
public:
...
bool disable_constraint( const char* name );
bool enable_constraint( const char* name );
...
};

You can use these methods to enable or disable any named constraint field in a user-defined
constraint object derived from class scv_constraint_base. The implementation of class
scv_constraint_base can use names as lookup keys to an internal table of class
scv_constraint_expr objects. Once looked up, you can call the ::enable() or ::disable() method
on those objects appropriately.

410 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Linking the Compiled Source

Constrained Randomization of the Data Type for

Standard Vectors
The data type for standard vectors (std::vector) has a data introspection capability in the same
way that fixed arrays and other primitive data types do. This means you can define SCV
extensions for vectors by specifying scv_extensions< vector > in a manner similar to what is
supported for arrays: scv_extensions< T[N] >.
In addition to being able to randomize all elements of a C++ STL std::vector, the SCV
constraint solver can randomize the number of elements of a std::vector (its size) to an arbitrary
value.

Further, you can constrain this randomization of vector size simply by calling
vector_size.keep_only() on the ::vector_size member of the scv_extensions< vector > class. The
::keep_only() method can be given a range of values that size can assume.

Randomly Sized Fixed-Max Arrays

This randomly sized "fixed-max" feature for array types was originally provided to test
preliminary implementations of randomization support for the std::vector data type. However, it
is also useful feature for randomization of the number of elements in an array up to a fixed
maximum size denoted by the template N parameter of scv_extensions< T[N] >.
It is fully backward compatible with existing support for array (scv_extensions< T[N] >)
support in the current open SCV API; randomization of size is disabled by default for backward
compatibility, but you can enable it as needed. Default operation is for all N elements to be
randomized as is done in the open SCV API.

Further, you can constrain this randomization simply by calling vector_size.keep_only() on the
::vector_size member of the scv_extensions< T[N] > class. The ::keep_only() method can be
given a range of values that size can assume.

Linking the Compiled Source

Once the design has been compiled, you must link it using the sccom command with the -link
argument.
The sccom -link command collects the object files created in the different design libraries, and
uses them to build a shared library (.so) in the current work library or the library specified by the
-work option. If you have changed your SystemC source code and recompiled it using sccom ,
then you must re-link the design by running sccom -link before invoking vsim. Otherwise, your
changes to the code are not recognized by the simulator. Remember that any dependent .a or .o
files should be listed on the sccom -link command line before the .a or .o on which it depends.
For more details on dependencies and other syntax issues, refer to the sccomcommand in the
Command Reference Manual.

ModelSim® SE User's Manual, v10.7 411

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Simulation of SystemC Designs

Simulation of SystemC Designs

After compiling the SystemC source code, you can use the vsim command to simulate your
design.

Loading the Design

For SystemC, invoke vsim with the top-level module(s) of the design.

Multiple optimized top design modules can be specified. For more information about simulation
with multiple optimized design modules refer to vsim <library_name>.<design_unit>.

For example, use the vsim command to begin simulation on a design named top:

vsim top

When the GUI appears (as shown in Figure 8-1), you can expand the hierarchy of the design to
view the SystemC modules. SystemC objects are denoted by green icons. (Refer to Design
Object Icons and Their Meanings in the GUI Reference Manual for more information).

Figure 8-1. SystemC Objects in GUI

To simulate from a command shell without using the GUI, invoke vsim with the -c argument:

vsim -c <top_level_module>

Tip
If you want to run a design with sc_main() as the top level, refer to Recommendations for
using sc_main at the Top Level.

412 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Simulation of SystemC Designs

Running Simulation
Run the simulation using the run command or choose one of the Simulate > Run selections
from the main menu.

SystemC Time Unit and Simulator Resolution

This section applies to simulations on designs consisting of SystemC only. For simulations of
mixed-language designs, the rules for how ModelSim interprets the resolution vary.

Two related yet distinct concepts are involved with determining the simulation resolution: the
SystemC time unit and the simulator resolution. The following table describes the concepts, lists
the default values, and defines the methods for setting/overriding the values.
Table 8-6. Time Unit and Simulator Resolution
Description Set by Default Override default by
default as value
.ini file
SystemC The unit of time used in ScTimeUnit 1ns ScTimeUnit .ini file variable
time unit your SystemC source or sc_set_default_time_unit()
code. function before an sc_clock or
You need to set this in sc_time statement.
cases where your
SystemC default time
unit is at odds with any
other, non-SystemC
segments of your
design.
Simulator The smallest unit of Resolution 1ns -t argument to vsim (This
resolution time measured by the overrides all other resolution
simulator. settings.)
If a warning is issued or
and your delays get sc_set_time_resolution()
truncated, set the function
resolution smaller; this or
value must be less than GUI: Simulate > Start
or equal to the Simulation > Resolution
UserTimeUnit

Available settings for both time unit and resolution are: 1x, 10x, or 100x of fs, ps, ns, us, ms, or
sec.

See Simulator Resolution Limit for details on mixed-language simulations.

You can view the current simulator resolution by invoking the report command with the
simulator state option.

ModelSim® SE User's Manual, v10.7 413

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Simulation of SystemC Designs

Choosing Your Simulator Resolution

You should choose the coarsest simulator resolution limit possible that does not result in
undesired rounding of your delays. For example, values smaller than the current Time Scale will
be truncated to zero (0) and a warning issued. However, the time precision should also not be set
unnecessarily small, because in some cases performance will be degraded.

When deciding what to set the simulator’s resolution to, you must keep in mind the relationship
between the simulator’s resolution and the SystemC time units specified in the source code. For
example, with a time unit usage of:

sc_wait(10, SC_PS);

a simulator resolution of 10ps would be fine. No rounding off of the ones digits in the time units
would occur. However, a specification of:

sc_wait(9, SC_PS);

would require you to set the resolution limit to 1ps in order to avoid inaccuracies caused by
rounding.

Initialization and Cleanup of SystemC State-Based Code

State-based code should not be used in Constructors and Destructors. Constructors and
Destructors should be reserved for creating and destroying SystemC design objects, such as
sc_modules or sc_signals. State-based code should also not be used in the elaboration phase
callbacks before_end_of_elaboration() and end_of_elaboration().

Note
If you have a design in which some state-based code must be placed in the constructor,
destructor, or the elaboration callbacks, you can use the mti_IsVoptMode() function to
determine if the elaboration is being run by vopt. You can use this function to prevent vopt from
executing any state-based code.

The following virtual functions should be used to initialize and clean up state-based code, such
as logfiles or the VCD trace functionality of SystemC. They are virtual methods of the
following classes: sc_port_base, sc_module, sc_channel, and sc_prim_channel. You can think
of them as phase callback routines in the SystemC language:

• before_end_of_elaboration () — Called after all constructors are called, but before port
binding.
• end_of_elaboration () — Called at the end of elaboration after port binding.
• start_of_simulation () — Called before simulation starts. Simulation-specific
initialization code can be placed in this function.

414 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Simulation of SystemC Designs

• end_of_simulation () — Called before ending the current simulation session.

The call sequence for these functions with respect to the SystemC object construction and
destruction is as follows:

1. Constructors
2. before_end_of_elaboration ()
3. end_of_elaboration ()
4. start_of_simulation ()
5. end_of_simulation ()
6. Destructors

Usage of Callbacks
The start_of_simulation() callback is used to initialize any state-based code. The
corresponding cleanup code should be placed in the end_of_simulation() callback. These
callbacks are called by vsim only during simulation and thus are safe.

Related Topics
SCV Extensions for User-specified Types

ModelSim® SE User's Manual, v10.7 415

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Debugging the Design

Debugging the Design

You can debug SystemC designs using all the debugging features of ModelSim, with the
exception of the Dataflow and Schematic windows. You must have compiled the design using
the sccom -g argument in order to debug the SystemC objects in your design.
Viewable SystemC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Waveform Compare with SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Debugging Source-Level Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Setting Constructor/Destructor Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Viewable SystemC Types

Types (<type>) of the objects which may be viewed for debugging are the following:

Types
bool, sc_bit short, unsigned short
sc_logic long, unsigned long
sc_bv<width> sc_bigint<width>
sc_lv<width> sc_biguint<width>
sc_int<width> sc_ufixed<W,I,Q,O,N>
sc_uint<width> short, unsigned short
sc_fix long long, unsigned long long
sc_fix_fast float
sc_fixed<W,I,Q,O,N> double
sc_fixed_fast<W,I,Q,O,N> enum
sc_ufix pointer
sc_ufix_fast array
sc_ufixed class
sc_ufixed_fast struct
sc_signed union
sc_unsigned ac_int
char, unsigned char ac_fixed
int, unsigned int

416 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Viewable SystemC Objects

Viewable SystemC Objects

Objects which may be viewed in SystemC for debugging purposes are as shown in the
following table.

Table 8-7. Viewable SystemC Objects

Channels Ports Variables Aggregates
sc_clock sc_in<type> Module member Aggregates of
(a hierarchical channel) sc_out<type> variables of all C++ SystemC signals
and SystemC built-in or ports.
sc_event sc_inout<type> types (listed in the Only three types
sc_export sc_in_rv<width> Types list below) are of aggregates are
supported. supported for
sc_mutex1 sc_out_rv<width>
debug:
sc_fifo<type> sc_inout_rv<width>
struct
sc_signal<type> sc_in_resolved
class
sc_signal_rv<width> sc_out_resolved
array
sc_signal_resolved sc_inout_resolved
tlm_fifo<type> sc_in_clk
User defined channels sc_out_clk
derived from sc_inout_clk
sc_prim_channel
sc_fifo_in
sc_fifo_out
User defined ports
derived from sc_port<>
which is :
• connected to a built-
in channel
• connected to a user-
defined channel
derived from an
sc_prim_channel2
1. sc_mutex is derived from sc_object in the IEEE 1666-2011 standard hence is an object and not a channel
in SystemC-2.3.1. The SystemC-2.2 (IEEE 1666-2005) behavior remains unchanged.
2. You must use a special macro to make these ports viewable for debugging. For details See Viewing
Unconnected User-defined Ports.

Viewing Unconnected User-defined Ports

A user-defined port which is not connected to a built-in primitive channel is not viewable for
debugging by default. You can make the port viewable if the actual channel connected to the
port is a channel derived from an sc_prim_channel. If it is, you can add the macro

ModelSim® SE User's Manual, v10.7 417

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Waveform Compare with SystemC

MTI_SC_PORT_ENABLE_DEBUG to the channel class’ public declaration area, as shown in

this example:

class my_channel: public sc_prim_channel

{
...
public:
MTI_SC_PORT_ENABLE_DEBUG
};

Waveform Compare with SystemC

Waveform compare supports the viewing of SystemC signals and variables. You can compare
SystemC objects to SystemC, Verilog or VHDL objects.
For pure SystemC compares, you can compare any two signals that match type and size exactly;
for C/C++ types and some SystemC types, sign is ignored for compares. Thus, you can compare
char to unsigned char or sc_signed to sc_unsigned. All SystemC fixed-point types may be
mixed as long as the total number of bits and the number of integer bits match.

Mixed-language compares are supported as listed in the following table:

Table 8-8. Mixed-language Compares
C/C++ types bool, char, unsigned char, short, unsigned
short, int, unsigned int, long, unsigned long
SystemC types sc_bit, sc_bv, sc_logic, sc_lv, sc_int, sc_uint,
sc_bigint, sc_biguint, sc_signed, sc_unsigned
Verilog types net, reg
VHDL types bit, bit_vector, boolean, std_logic,
std_logic_vector

The number of elements must match for vectors; specific indexes are ignored.

Debugging Source-Level Code

In order to debug your SystemC source code, you must compile the design for debug using the
-g C++ compiler option.
You can add this option directly to the sccom command line on a per run basis, with a command
such as:

sccom mytop -g

Or, if you plan to use it every time you run the compiler, you can specify it in the modelsim.ini
file with the CppOptions variable. See the modelsim.ini Variables for more information.

418 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Debugging Source-Level Code

The source code debugger, C Debug, is automatically invoked when the design is compiled for
debug in this way.

Figure 8-2 shows an example of how to set breakpoints in a Source window (Line 59) and
single-step through your SystemC/C++ source code.

Figure 8-2. Breakpoint in SystemC Source

Note
To disallow source annotation, use the -nodbgsym argument for the sccom command. This
disables the generation of symbols for the debugging database in the library.

Stepping Out From OSCI Library Functions

When you are using C Debug to single-step through the SystemC code, you may find that
stepping through the code often ends up going inside SystemC library routines. This can be a
distraction from debugging your actual code.

By default, auto-stepping out of the library for debugging is enabled, which means stepping into
the library is not allowed (cdbg allow_lib_step off). So, if you step into a library function,
execution will automatically return to your code.

You can use the cdbg command to disable this behavior:

cdbg allow_lib_step on

Now, execution will not automatically step out from library functions, but it will step into the
library code.

ModelSim® SE User's Manual, v10.7 419

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Debugging Source-Level Code

The allow_lib_step argument to the cdbg command takes a value of "on" or "off."

You can also perform this action in the GUI by selecting Tools > CDebug > Allow lib step
from the menus (Figure 8-3).

Figure 8-3. Setting the Allow lib step Function

For example, assume that the debugger has stepped to a library function call. If this were the
only library function call in the current line, execution would go the next line in your code
(there would be no need for the “step out” action). However, if there are more function calls in
the current line, execution comes back to the same line, and the next 'step -over' operation goes
to the next line in your code. So the debugging operation always stays in your code, regardless
of where it steps.

420 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Setting Constructor/Destructor Breakpoints

Setting Constructor/Destructor Breakpoints

You can set breakpoints in constructors and destructors of SystemC objects. Constructor
breakpoints need to be set before the SystemC shared library is loaded.
You can set breakpoints using either the Cdebug Init mode or Automated Constructor
breakpoint flow.

Setting BPs with Cdebug Init Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Setting BPs with Automated Constructor Breakpoint Flow . . . . . . . . . . . . . . . . . . . . . . 421
Using Instance Based Breakpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Viewing SystemC Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Setting BPs with Cdebug Init Mode

You can set breakpoints using Cdebug Init mode.
Procedure
1. Start Cdebug before loading the design.
a. Select Tools > CDebug > Start CDebug from the menus or use the following
command:
cdbg debug_on

2. Turn on the Cdebug Init mode.

a. Select Tools > CDebug > Init mode from the menus or use the following command:
cdbg init_mode_setup

3. Load the design.

ModelSim will stop after loading the shared library.
4. Set breakpoints on constructors.

Setting BPs with Automated Constructor Breakpoint Flow

You can set breakpoints using the automated constructor breakpoint mode.
Procedure
1. Start ModelSim in the GUI or at the command line.
a. Type vsim at a UNIX shell prompt (vsim -c for command line mode) or double-click
the ModelSim icon in Windows.
If the Welcome to ModelSim dialog appears, click Close.

ModelSim® SE User's Manual, v10.7 421

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Setting Constructor/Destructor Breakpoints

2. Set the breakpoints using the following command.

bp -c [<filename>:<line> | <function_name>]

NOTE: You can also set breakpoints by opening a file in source window and clicking on
a line number.
3. Load the design by entering the vsim command. ModelSim automatically stops after
loading the shared library and sets all the constructor breakpoints. You can set additional
constructor breakpoints here.
4. The run -continue command elaborates the design and stops the simulation at the
constructor breakpoint.
5. You can also set destructor breakpoints using these same steps in either the Cdebug Init
mode or the Automated Constructor breakpoint flow; or, after the design is loaded. If
you set destructor breakpoints before loading the design, then ModelSim keeps all the
breakpoints enabled even after design is loaded.
Results
When you set a destructor breakpoint, ModelSim automatically sets up in Stop on quit mode
(see Debugging Functions when Quitting Simulation). The debugger will stop at the breakpoint
after you issue the quit -f command in ModelSim. This allows you to step through and examine
the code. Run the run -continue command when you have finished examining the C code.
Because the Stop on quit mode is set up, when simulation completes, ModelSim automatically
quits C-debugger and the GUI (whether or not a C breakpoint was hit and you return to the
VSIM> prompt).

Using Instance Based Breakpointing

To set a SystemC breakpoints so it applies only to a specified instance, use the -inst argument to
the bp command.
Example command:

bp <filename>:<line#> -inst <instance>

Related Topics
bp [ModelSim SE Command Reference Manual]

Viewing SystemC Objects in the GUI

You can view and expand SystemC objects in the Objects window and processes in the
Processes pane.
The SC objects appear as shown in Figure 8-4.

422 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Setting Constructor/Destructor Breakpoints

Figure 8-4. SystemC Objects and Processes

ModelSim® SE User's Manual, v10.7 423

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
SystemC Object and Type Display

SystemC Object and Type Display

This section contains information on how ModelSim displays certain objects and types, as they
may differ from other simulators.
Support for Globals and Statics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Support for Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
SystemC Dynamic Module Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Viewing FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Viewing SystemC Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Properly Recognizing Derived Module Class Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Custom Debugging of SystemC Channels and Variables . . . . . . . . . . . . . . . . . . . . . . . . 431

Support for Globals and Statics

Context: Debugging
Globals and statics are supported for ModelSim debugging purposes, however some additional
naming conventions must be followed to make them viewable.

Naming Requirements
In order to make a global viewable for debugging purposes, the name given must match the
declared signal name.

An example:

sc_signal<bool> clock("clock");

For statics to be viewable, the name given must be fully qualified, with the module name and
declared name, as follows:

<module_name>::<declared_name>

For example, the static data member "count" is viewable in the following code excerpt:

SC_MODULE(top)
{
static sc_signal<float> count; //static data member
....
}

sc_signal<float> top::count("top::count"); //static named in quotes

424 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Support for Aggregates

Viewing Global and Static Signals

ModelSim translates C++ scopes into a hierarchical arrangement. Because globals and statics
exist at a level above its scope, ModelSim must add a top level, sc_root, to all global and static
signals. Thus, to view these static or global signals in ModelSim, you need to add sc_root to the
hierarchical name for the signal.

In the case of the above examples, the debugging statements for examining "top/count" (a static)
and "clock" (a global) would be:

VSIM> examine /sc_root/top/count

VSIM> examine /sc_root/clock

Support for Aggregates

Context: Debugging
ModelSim supports aggregates of SystemC signals or ports. Three types of aggregates are
supported: structures, classes, and arrays. Unions are not supported for debug. An aggregate of
signals or ports will be shown as a signal of aggregate type. For example, an aggregate such as:
sc_signal <sc_logic> a[3];

is equivalent to:

sc_signal <sc_lv<3>> a;

for debug purposes. ModelSim shows one signal - object "a" - in both cases.

The following aggregate would appear in the Wave window as shown in Figure 8-5:

sc_signal <float> fbus [6];

ModelSim® SE User's Manual, v10.7 425

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
SystemC Dynamic Module Array

Figure 8-5. Aggregate Data Displayed in Wave Window

SystemC Dynamic Module Array

ModelSim supports SystemC dynamic module arrays.
An example of using a dynamic module array:

module **mod_inst;
mod_inst = new module*[2];
mod_inst[0] = new module("mod_inst[0]");
mod_inst[1] = new module("mod_inst[1]");

Limitations
• The instance names of modules containing dynamic arrays must match the
corresponding C++ variables, such as “mod_inst[0]” and “mod_inst[1]” in the example
above. If not named correctly, the module instances simulate correctly, but are not
debuggable.

426 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Viewing FIFOs

• For sc_foreign_module arrays, if [] in the name is desired, please use the extended
identifier syntax to name the module. For example:
foreign_module **foreign_module_inst;
foreign_module_inst = new foreign_module*[2];
foreign_module_inst[0] = new foreign_module
("\\foreign_module_inst[0]\\");
foreign_module_inst[1] = new foreign_module
("\\foreign_module_inst[1]\\");

Viewing FIFOs
Context: SystemC objects
In ModelSim, the values contained in an sc_fifo appear in a definite order. The top-most or left-
most value is always the next to be read from the FIFO. Elements of the FIFO that are not in use
are not displayed.
Example of a signal where the FIFO has five elements:

# examine f_char
# {}
VSIM 4> # run 10
VSIM 6> # examine f_char
# A
VSIM 8> # run 10
VSIM 10> # examine f_char
# {A B}
VSIM 12> # run 10
VSIM 14> # examine f_char
# {A B C}
VSIM 16> # run 10
VSIM 18> # examine f_char
# {A B C D}
VSIM 20> # run 10
VSIM 22> # examine f_char
# {A B C D E}
VSIM 24> # run 10
VSIM 26> # examine f_char
# {B C D E}
VSIM 28> # run 10
VSIM 30> # examine f_char
# {C D E}
VSIM 32> # run 10
VSIM 34> # examine f_char
# {D E}

Viewing SystemC Memories

Context: SystemC objects

ModelSim® SE User's Manual, v10.7 427

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Properly Recognizing Derived Module Class Pointers

The ModelSim tool detects and displays SystemC memories. A memory is defined as any
member variable of a SystemC module which is defined as an array of the following type:

unsigned char sc_bit (of 2-D or more arrays only)

unsigned short sc_logic (of 2-D or more arrays only)
unsigned int sc_lv<N>
unsigned long sc_bv<N>
unsigned long long sc_int<N>
char sc_uint<N>
short sc_bigint<N>
int sc_biguint<N>
float sc_signed
double sc_unsigned
enum

Properly Recognizing Derived Module Class

Pointers
If you declare a pointer as a base class pointer, but actually assign a derived class object to it,
ModelSim still treats it as a base class pointer instead of a derived class pointer, as you intended.
As such, it would be unavailable for debug. To make it available for debug, you must use the
mti_set_typename member function to instruct that it should be treated as a derived class
pointer.
To correctly associate the derived class type with an instance:

1. Use the member function mti_set_typename and apply it to the modules. Pass the
actual derived class name to the function when an instance is constructed, as shown in
Example 8-7.

428 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Properly Recognizing Derived Module Class Pointers

Example 8-7. Use of mti_set_typename

SC_MODULE(top) {

base_mod* inst;

SC_CTOR(top) {

if (some_condition) {
inst = new d1_mod("d1_inst");
inst->mti_set_typename("d1_mod");
} else {
inst = new d2_mod("d2_inst");
inst->mti_set_typename("d2_mod");
}
}
};

Tip
: In this example, the class names are simple names, which may not be the case if the
type is a class template with lots of template parameters. Look up the name in
<work>/moduleinfo.sc file, if you are unsure of the exact names.

ModelSim® SE User's Manual, v10.7 429

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Properly Recognizing Derived Module Class Pointers

Here is the code for which the above SC_MODULE was modified:

class base_mod : public sc_module {

sc_signal<int> base_sig;
int base_var;

...

};

class d1_mod : public base_mod {

sc_signal<int> d1_sig;
int d1_var;

...

};

class d2_mod : public base_mod {

sc_signal<int> d2_sig;
int d2_var;

...

};

SC_MODULE(top) {

base_mod* inst;

SC_CTOR(top) {

if (some_condition)
inst = new d1_mod("d1_inst");
else
inst = new d2_mod("d2_inst");
}
};

In this unmodified code, the sccom compiler could only see the declarative region of a module,
so it thinks "inst" is a pointer to the "base_mod" module. After elaboration, the GUI would only
show "base_sig" and "base_var" in the Objects window for the instance "inst."

You really wanted to see all the variables and signals of that derived class. However, since you
did not associate the proper derived class type with the instance "inst", the signals and variables
of the derived class are not debuggable, even though they exist in the kernel.

The solution is to associate the derived class type with the instance, as shown in the modified
SC_MODULE above.

430 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Custom Debugging of SystemC Channels and Variables

Custom Debugging of SystemC Channels and

Variables
ModelSim offers a string-based debug solution for various simulation objects that are
considered undebuggable by the SystemC compiler command, sccom.
By using the sccom command, you can gain easy access for debugging to the following:

• SystemC variables of a user-defined type

• Built-in channels of a user defined type
• Built-in ports of a user defined type
• User defined channels and ports
This custom interface can be also used to debug objects that may be supported for debug
natively by the simulator, but whose native debug view is too cumbersome.

Supported SystemC Objects

Context: SystemC debugging

The custom debug interface provides debug support for the following SystemC objects (T is a
user defined type, or a user-defined channel or port):

• T
• sc_signal<T>
• sc_fifo<T>
• tlm_fifo<T>
• sc_in<T>
• sc_out<T>
• sc_inout<T>

Debugging Instructions
To provide custom debug for any object:

1. Register a callback function — one for each instance of that object — with the
simulator. Specify the maximum length of the string buffer to be reserved for an object
instance. See Registration and Callback Function Syntax.
2. The simulator calls the callback function, with the appropriate arguments, when it needs
the latest value of the object.

ModelSim® SE User's Manual, v10.7 431

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Custom Debugging of SystemC Channels and Variables

The registration function can be called from the phase callback function
before_end_of_elaboration(), or anytime before this function during the elaboration
phase of the simulator.
3. The ModelSim simulator passes the callback function a pre-allocated string of a length
specified during registration. The callback function must write the value of the object in
that string, and it must be null terminated (\0).
4. The ModelSim simulator takes the string returned by the callback function as-is and
displays it in the Objects window, Wave window, and CLI commands (such as
examine). The describe command on custom debug objects simply reports that the
object is a custom debug object of the specified length.
The macro used to register an object for debugging is
SC_MTI_REGISTER_CUSTOM_DEBUG. Occasionally, ModelSim fails to register an object
because it determines that the object cannot be debugged. In such cases, an error message is
issued to that effect. If this occurs, use the
SC_MTI_REGISTER_NAMED_CUSTOM_DEBUG to both name and register the object for
debugging.

Registration and Callback Function Syntax

Registration:

void SC_MTI_REGISTER_CUSTOM_DEBUG
(void* obj, size_t value_len,
mtiCustomDebugCB cb_func);
void SC_MTI_REGISTER_NAMED_CUSTOM_DEBUG
(void* obj, size_t value_len,
mtiCustomDebugCB cb_func, const char* name);

Callback:

typedef void (*mtiCustomDebugCB)(void* obj, char* value, char

format_char);

• obj — the handle to the object being debugged

• value_len — the maximum length of the debug string to be reserved for this object
• cb_func — the callback function to be called by the simulator for the latest value of the
object being debugged
• name — the name of the object being debugged
• value — A pointer to the string value buffer in which the callback must write the string
value of the object begin debugged
• format_char — the expected format of the value: ascii (‘a’), binary (‘b’), decimal (‘d’),
hex (‘h’), or octal (‘o’)

432 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Custom Debugging of SystemC Channels and Variables

The callback function does not return anything.

Example 8-8. Using the Custom Interface on Different Objects

Consider an arbitrary user-defined type T as follows:

class myclass {

private:

int x;
int y;

public:
void get_string_value(char format_str, char* mti_value);
size_t get_value_length();

...
};

Variable of type T would be:

void mti_myclass_debug_cb(void* var, char* mti_value, char format_str)

{
myclass* real_var = reinterpret_cast<myclass*>(var);
real_var->get_string_value(format_str, mti_value);
}

SC_MODULE(test) {

myclass var1;
myclass* var2;

SC_CTOR(test) {
SC_MTI_REGISTER_CUSTOM_DEBUG(
&var1,
var1.get_value_length(),
mti_myclass_debug_cb);

SC_MTI_REGISTER_CUSTOM_DEBUG(
var2,
var2->get_value_length(),
mti_myclass_debug_cb);
}
};

ModelSim® SE User's Manual, v10.7 433

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Custom Debugging of SystemC Channels and Variables

sc_signal, sc_fifo and tlm_fifo of type T and Associated Ports would be:

void mti_myclass_debug_cb(void* var, char* mti_value, char format_str)

{
myclass* real_var = reinterpret_cast<myclass*>(var);
real_var->get_string_value(format_str, mti_value);
}

SC_MODULE(test) {

sc_signal<myclass> sig1;
sc_signal<myclass> *sig2;
sc_fifo<myclass> fifo;

SC_CTOR(test) {
myclass temp;

SC_MTI_REGISTER_CUSTOM_DEBUG(
&sig1,
temp.get_value_length(),
mti_myclass_debug_cb);

SC_MTI_REGISTER_CUSTOM_DEBUG(
sig2,
temp.get_value_length(),
mti_myclass_debug_cb);

SC_MTI_REGISTER_CUSTOM_DEBUG(
&fifo,
temp.get_value_length(),
mti_myclass_debug_cb);
}
};

As shown in Example 8-8, although the callback function is registered on a sc_signal<T> or a

sc_fifo<T> object, the callback is called on the T object, instead of the channel itself. The
reason for the callback on T is because sc_signal<T> has two sets of values, current and new
value and sc_fifo can have more than one element in the fifo. The callback is called on each
element of the fifo that is valid at any given time. For an sc_signal<T> the callback is called
only on the current value, not the new value.

By registering the primitive channel sc_signal<T> for custom debug, any standard port
connected to it (sc_in<T>, sc_out<T>, sc_inout<T>, sc_fifo_in<T>, and so forth) automatically
is available for custom debug. It is illegal to register any built-in ports for custom debug
separately.

User-Defined Primitive Channels and Ports

The callback and registration mechanism for a user-defined channel derived from
sc_prim_channel are no different than a variable of an user-defined type.

Please see the section on variables of type T in Example 8-8 for more details on the registration
and callback mechanism for such objects.

434 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Custom Debugging of SystemC Channels and Variables

You have two choices available to you for making user defined ports debuggable:

• Automatic debug of any port connected to a primitive channel

Any port that is connected to a channel derived from sc_prim_channel is automatically
debuggable only if the connected channel is debuggable either natively or using custom
debug. To enable this automatic debugging capability, use the following macro in the
channel class:
MTI_SC_PORT_ENABLE_DEBUG

In this case, you may not separately register the port for custom debug.
• Specific port registration
Register the port separately for custom debug. To do this, simply register the specific
port, without using the macro. The callback and registration mechanism is the same as a
variable of type T.

Hierarchical Channels/Ports Connected to Hierarchical Channels

Hierarchical channels are basically modules, and appear in the structure pane in ModelSim.
Since they are part of the design hierarchy, custom debug cannot be supported for hierarchical
channels. Ports connected to hierarchical channels, however, though not supported for debug
natively in ModelSim, are supported for debug with the custom interface.

Any port object registered for custom debug is treated as a variable of a user defined type.
Please see Example 8-8, variables of type T, for more details on the registration and callback
mechanism for such objects.

Any Other Channels and Ports Connected to Such Channels

It is legal in SystemC to create a channel that implements an interface and is not derived either
from sc_channel or sc_prim_channel. Take the following, for example:

class mychannel : public myinterface {}

class myport : public sc_port<myinterface> {}

Channels and ports of this category are supported for debug natively in ModelSim. ModelSim
treats them as variables of type T. These channels and ports can be registered for custom debug.
The registration and callback mechanism is the same as for a variable of type T, as shown in
Example 8-8 above.

ModelSim® SE User's Manual, v10.7 435

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Modifying SystemC Source Code

Modifying SystemC Source Code

If your design does not have sc_main() at the top level, you must apply several modifications to
your original SystemC source code.
For more information on how to make these modifications, refer to “Code Modification
Examples,” which contains the following examples:

• Converting sc_main to a Module

• Using sc_main and Signal Assignments
• Using an SCV Transaction Database
Converting sc_main() to a Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Replacing sc_start() Function with Run Command and Options . . . . . . . . . . . . . . . . . . 436
Removing Calls to sc_initialize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Converting sc_main() to a Module

If your design does not have sc_main() at the top level, in order for ModelSim to run the
SystemC/C++ source code, you must replace the control function of sc_main() with a
constructor, SC_CTOR(), placed within a module at the top level of the design.
In addition, the following requirements also apply:

• Any test bench code inside sc_main() should be moved to a process, normally an
SC_THREAD process.
• All C++ variables in sc_main(), including SystemC primitive channels, ports, and
modules, must be defined as members of sc_module. Therefore, initialization must take
place in the SC_CTOR. For example, all sc_clock() and sc_signal() initializations must
be moved into the constructor.

Replacing sc_start() Function with Run Command

and Options
ModelSim uses the run command and its options in place of the sc_start() function. If
sc_main() has multiple sc_start() calls mixed in with the test bench code, then use an
SC_THREAD() with wait statements to emulate the same behavior.
An example of using the run command/options in place of sc_start is shown in “Code
Modification Examples” on page 437.

436 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Removing Calls to sc_initialize()

Removing Calls to sc_initialize()

vsim calls sc_initialize() by default at the end of elaboration, so calls to sc_initialize() are
unnecessary.

Code Modification Examples

You can modify sc_main in a number of ways, which are demonstrated in the examples in this
section.
Example 8-9. Converting sc_main to a Module

Table 8-9 shows a simple example of how to convert sc_main to a module that you can
elaborate with the vsim command.
Table 8-9. Simple Conversion: sc_main to Module
Original OSCI code #1 (partial) Modified code #1 (partial)
int sc_main(int argc, char* argv[]) SC_MODULE(mytop)
{ {
sc_signal<bool> mysig; sc_signal<bool> mysig;
mymod mod("mod"); mymod mod;
mod.outp(mysig); SC_CTOR(mytop)
sc_start(100, SC_NS); : mysig("mysig"),
} mod("mod")
{
mod.outp(mysig);
}
};
SC_MODULE_EXPORT(mytop);

Here, you would use the following run command for the modified code as the equivalent to the
sc_start(100, SC_NS) statement in the original OSCI code:

run 100 ns

Example 8-10. Using sc_main and Signal Assignments

Table 8-10 shows a slightly more complex conversion that illustrates the use of sc_main() and
signal assignments, and how you would get the same behavior using ModelSim.

ModelSim® SE User's Manual, v10.7 437

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Code Modification Examples

Table 8-10. Using sc_main and Signal Assignments

OSCI code #2 (partial) Modified code #2 (partial)
int sc_main(int, char**) SC_MODULE(new_top)

{ {

sc_signal<bool> reset; sc_signal<bool> reset;

counter_top top("top"); counter_top top;

sc_clock CLK("CLK", 10, SC_NS, 0.5, 0.0, sc_clock CLK;

SC_NS, false);
void sc_main_body();
top.reset(reset);
SC_CTOR(new_top)
reset.write(1);
: reset("reset"),
sc_start(5, SC_NS);
top("top")
reset.write(0);
CLK("CLK", 10, SC_NS, 0.5, 0.0, SC_NS, false)
sc_start(100, SC_NS);
{
reset.write(1);
top.reset(reset);
sc_start(5, SC_NS);
SC_THREAD(sc_main_body);
reset.write(0);
}
sc_start(100, SC_NS);
};
}
void
new_top::sc_main_body()

reset.write(1);

wait(5, SC_NS);

reset.write(0);

wait(100, SC_NS);

reset.write(1);

wait(5, SC_NS);

reset.write(0);

wait(100, SC_NS);
sc_stop();
}

SC_MODULE_EXPORT(new_top);

438 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Differences Between the Simulator and OSCI

Example 8-11. Using an SCV Transaction Database

Table 8-11 shows a conversion that modifies a design using an SCV transaction database.
ModelSim requires that you create the transaction database before calling the constructors on
the design subelements.
Table 8-11. Modifications Using SCV Transaction Database
Original OSCI code # 3 (partial) Modified ModelSim code #3 (partial)
int sc_main(int argc, char* argv[]) SC_MODULE(top)
{ {
scv_startup(); sc_signal<bool>* rw;
scv_tr_text_init(); test* t;
scv_tr_db db("my_db"); SC_CTOR(top)
scv_tr_db db::set_default_db(&db); {
sc_clock clk ("clk",20,0.5,0,true); scv_startup();
sc_signal<bool> rw; scv_tr_text_init()
test t("t"); scv_tr_db* db = new scv_tr_db("my_db");
t.clk(clk);; scv_tr_db::set_default_db(db):;
t.rw(rw); clk = new sc_clock("clk",20,0.5,0,true);
sc_start(100); rw = new sc_signal<bool> ("rw");
} t = new test("t");
}
};
SC_MODULE_EXPORT(new_top);

Take care to preserve the order of functions called in sc_main() of the original code.

You cannot place subelements in the initializer list, since the constructor body must be executed
prior to their construction. Therefore, you must make the subelements as pointer types by
creating them with "new" in the SC_CTOR() module.

Differences Between the Simulator and OSCI

ModelSim is based upon the OSCI proof-of-concept SystemC simulator. However, there are
some minor but key differences to be aware of.
• The default time resolution of the simulator is 1ps. For vsim it is 1ns. You can change
the value for time resolution by using the vsim command with the -t option or by
modifying the value of the Resolution variable in the modelsim.ini file.

ModelSim® SE User's Manual, v10.7 439

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Differences Between the Simulator and OSCI

• The run command in ModelSim is equivalent to sc_start(). In the SystemC simulator,

sc_start() runs the simulation for the duration of time specified by its argument. In
ModelSim the run command runs the simulation for the amount of time specified by its
argument.
• The sc_cycle(), and sc_start() functions are not supported in ModelSim.
• The default name for sc_object() is bound to the actual C object name. However, this
name binding only occurs after all sc_object constructors are executed. As a result, any
name() function call placed inside a constructor will not pick up the actual C object
name.
• The value returned by the name() method prefixes OSCI-compliant hierarchical paths
with "sc_main", which is ModelSim's implicit SystemC root object. For example, for the
following example code:
#include "systemc.h"

SC_MODULE(bloc)
{
SC_CTOR(bloc) {}
};

SC_MODULE(top)
{
bloc b1 ;
SC_CTOR(top) : b1("b1") { cout << b1.name() << endl ; }
};

int sc_main(int argc, char* argv[])

{
top top_i("top_i");
sc_start(0, SC_NS);
return 0;
}

the OSCI returns:

top_i.b1

and ModelSim returns:

sc_main.top_i.b1

• With the IEEE 1666-2011 std, OSCI introduced a new sc_starvation_policy

SC_EXIT_ON_STARVATION. ModelSim does not support the
SC_EXIT_ON_STARVATION_POLICY. ModelSim supports only the
SC_RUN_TO_TIME policy.
• With the IEEE 1666-2011 std, OSCI issues a warning when sc_start is called with a
zero-valued time argument, the set of runnable processes is empty, the set of update
requests is empty, and the set of delta notifications and time-outs is empty. ModelSim
does not issue this warning.

440 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Differences Between the Simulator and OSCI

Fixed-Point Types
Contrary to OSCI, ModelSim compiles the SystemC kernel with support for fixed-point types.
If you want to compile your own SystemC code to enable that support, you must first define the
compile time macro SC_INCLUDE_FX.

You can do this in one of two ways:

• Enter the g++/aCC argument -DSC_INCLUDE_FX on the sccom command line, such
as:
sccom -DSC_INCLUDE_FX top.cpp

• Add a define statement to the C++ source code before the inclusion of the systemc.h, as
shown below:
#define SC_INCLUDE_FX
#include "systemc.h"
Algorithmic C Datatype Support
ModelSim supports native debug for the Algorithmic-C data types ac_int and ac_fixed. The
Algorithmic C data types are used in Catapult C Synthesis, a tool that generates optimized RTL
from algorithms written as sequential ANSI-standard C/C++ specifications. These data types
are synthesizable and run faster than their SystemC counterparts sc_bigint, sc_biguint, sc_fixed
and sc_ufixed.

To use these data types in the simulator, you must obtain the datatype package and specify the
path containing the Algorithmic C header files with the -I argument on the sccom command
line:

sccom -I <path_to_AC_headers> top.cpp

To enable native debug support for these datatypes, you must also specify the
-DSC_INCLUDE_MTI_AC argument on the sccom command line.

sccom -DSC_INCLUDE_MTI_AC -I <path_to_AC_headers> top.cpp

Native debug is only supported for Version 1.2 and above. If you do not specify
-DSC_INCLUDE_MTI_AC, the GUI displays the C++ layout of the datatype classes.

Support for cin

The ModelSim simulator has a limited support for the C++ standard input cin.

To enable support for cin, the design source files must be compiled with -DUSE_MTI_CIN
sccom option. For example:

sccom -DUSE_MTI_CIN top.cpp

Limitations
ModelSim does not support cin when it is passed as a function parameter of type istream. This is
true for both C++ functions and member functions of a user-defined class/struct.

ModelSim® SE User's Manual, v10.7 441

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Differences Between the Simulator and OSCI

For example, the following cin usage is not supported:

void getInput(istream& is)

{
int input_data;
...
is >> input_data;
....

getinput(cin);

A workaround for this case, the source code needs to be modified as shown below:

void getinput()
{
int input_data;
...
cin >> input_data;
..
}
getinput();

442 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
OSCI 2.3.1 Feature Implementation Details

OSCI 2.3.1 Feature Implementation Details

The implementation details related to OSCI SystemC 2.3.1 release are provided in this section.
Support for OSCI TLM Library in SystemC-2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Features Not Supported in SystemC-2.3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Backwards Compatibility Issues with SystemC-2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Support for OSCI TLM Library in SystemC-2.3.1

OSCI SystemC 2.3.1 release has an integrated TLM implementation (not distributed as a
separate release). If you are using TLM implementation not supplied with SystemC 2.3.1
release (older than TLM 2.0.2 release), you need to add the
-DSC_DISABLE_VIRTUAL_BIND argument during compilation in order for it to work with
SystemC-2.3.1.
The various bind() functions for ports and exports are "virtual" as of IEEE 1666-2011 SytemC
LRM. This leads to an incompatibility with a TLM release than is older than 2.0.2 release. To
use SystemC 2.3.1 together with a TLM relase older than the 2.0.2 release, define
SC_DISABLE_VIRTUAL_BIND during the build of the simulator and before including
systemc.h.

ModelSim includes the header files and exmaples from the OSCI SystemC TLM (Transaction
Level Modeling) Library, Release 2.0.3. The TLM library can be used with simulation, and
requires no extra arguments or files. TLM objects are not debuggable, with the exception of
tlm_fifo.

Examples and documentation are located in install_dir/examples/systemc/tlm. The TLM header

files (tlm_*.h) are located in include/systemc.

Features Not Supported in SystemC-2.3.1

Several SystemC-2.3.1 features are not supported with ModelSim.
• With the IEEE 1666-2011 standard OSCI introduced a new sc_starvation_policy.
SC_EXIT_ON_STARVATION. ModelSim does not support the
SC_EXIT_ON_STARVATION sc_starvation_policy. ModelSim only supports the
SC_RUN_TO_TIME sc_starvation_policy.
• With the IEEE 1666-2011 standard OSCI issues a warning when sc_start is called with
a zero-valued time argument, the set of runnable processes is empty, the set of update
requests is empty, and the set of delta notifications and time-outs is empty. ModelSim
will not issue this warning

ModelSim® SE User's Manual, v10.7 443

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Backwards Compatibility Issues with SystemC-2.3.1

Experimental Features
This release of SystemC contains the "Proof of Concept" simulator for the IEEE 1666-2011
SystemC standard that is provided by Accellera Systems Initiative. Each release of SystemC
also contains experimental features. By default, these features are not enabled in the default
library configuration.

The experimental features of SystemC 2.3.1 are listed below and are not supported by
ModelSim for this release. By default, they are not enabled.

• Extended Simulation Phase Callbacks.

Caution
Do not build the SystemC library using the
SC_ENABLE_SIMULATION_PHASE_CALLBACKS and
SC_ENABLE_SIMULATION_PHASE_CALLBACKS_TRACING defines
(which enable this unsupported feature).

• Creating sc_max_time() objects before fixing the sc_time resolution.

Backwards Compatibility Issues with SystemC-

2.3.1
Several backwards compatibility issues exist with SystemC 2.3.1.
• SC_ID_UNBOUND_PORT warning has been removed:
** Warning: (vsim-6627) Port badtop/a/port is not bound to any
channel.

• sc_cycle() deprecation warning not applicable any more:

** Note: (vsim-6572) sc_cycle() is deprecated in SystemC 2.2. Use
sc_start(sc_time).

ModelSim makes no distinction between sc_cycle(sc_time) and sc_start(sc_time).

• SC_ID_METHOD_TERMINATION_EVENT_ has been removed:
** Error: (vsim-6556) Attempt to get terminated event for a method
process

• sc_mutex and sc_semaphore are derived from sc_object instead of sc_prim_channel.

There is a new feature supported in SystemC-2.3.1 (from Annex D 1666-2011 LRM). Please
refer to Annex D of the IEEE 1666-2011 LRM for more information.

444 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
OSCI 2.2 Feature Implementation Details

OSCI 2.2 Feature Implementation Details

The implementation details related to OSCI SystemC 2.2 release are provided in this section.
Support for OSCI TLM Library in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Phase Callback in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Accessing Command-Line Arguments in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 445
sc_stop Behavior in SystemC-2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Construction Parameters for SystemC Types in 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Support for OSCI TLM Library in SystemC-2.2

ModelSim includes the header files and examples from the OSCI SystemC TLM (Transaction
Level Modeling) Library, Release 2.0.1. The TLM library can be used with simulation, and
requires no extra switches or files. TLM objects are not debuggable, with the exception of
tlm_fifo.
Examples and documentation are located in install_dir/examples/systemc/tlm. The TLM header
files (tlm_*.h) are located in include/systemc22.

Phase Callback in SystemC-2.2

The following functions are supported for phase callbacks:
• before_end_of_elaboration()
• start_of_simulation()
• end_of_simulation()
For more information regarding the use of these functions, see Initialization and Cleanup of
SystemC State-Based Code.

Accessing Command-Line Arguments in SystemC-

2.2
Several global functions allow you to gain access to command-line arguments.
These are:

• sc_argc() — Returns the number of arguments specified on the vsim command line with
the -sc_arg argument. This function can be invoked from anywhere within SystemC
code.

ModelSim® SE User's Manual, v10.7 445

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
sc_stop Behavior in SystemC-2.2

• sc_argv() — Returns the arguments specified on the vsim command line with the
-sc_arg argument. This function can be invoked from anywhere within SystemC code.
Example:

When vsim is invoked with the following command line:

vsim -sc_arg "-a" -c -sc_arg "-b -c" -t ns -sc_arg -d

sc_argc() and sc_argv() will behave as follows:

int argc;
const char * const * argv;

argc = sc_argc();
argv = sc_argv();

The number of arguments (argc) is now 4.

argv[0] is "vopt" // if running vopt explicitly

argv[0] is "vsim" // if not

argv[1] is "-a"
argv[2] is "-b -c"
argv[3] is "-d"

sc_stop Behavior in SystemC-2.2

When encountered during the simulation run in command line mode, the sc_stop() function
stops the current simulation and causes ModelSim to exit.
In the GUI mode, a dialog box appears asking you to confirm the exit. This is the default
operation of sc_stop(). If you want to change the default behavior of sc_stop, you can change
the setting of the OnFinish variable in the modelsim.ini file. To change the behavior
interactively, use the -onfinish argument to the vsim command.

Construction Parameters for SystemC Types in 2.2

The information in this section applies only to SystemC signals, ports, variables, or fifos that
use one of the following fixed-point types:
sc_signed
sc_unsigned
sc_fix
sc_fix_fast
sc_ufix
sc_ufix_fast

446 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Construction Parameters for SystemC Types in 2.2

These are the only SystemC types that have construction time parameters. The default size for
these types is 32. If you require values other than the default parameters, you need to read this
section.

If you are using one of these types in a SystemC signal, port, fifo, or an aggregate of one of
these (such as an array of sc_signal), you cannot pass the size parameters to the type. This is a
limitation imposed by the C++ language. Instead, SystemC provides a global default size (32)
that you can control.

For sc_signed and sc_unsigned, you need to use the two objects, sc_length_param and
sc_length_context, and you need to use them in an unusual way. If you just want the default
vector length, simply do this:

SC_MODULE(dut) {

sc_signal<sc_signed> s1;
sc_signal<sc_signed> s2;

SC_CTOR(dut)
: s1("s1"), s2("s2")
{
}
}

For a single setting, such as using five-bit vectors, your module and its constructor would look
like the following:

SC_MODULE(dut) {
sc_length_param l;
sc_length_context c;

sc_signal<sc_signed> s1;
sc_signal<sc_signed> s2;

SC_CTOR(dut)

: l(5), c(l), s1("s1"), s2("s2")

{
}
}

Notice that the constructor initialization list sets up the length parameter first, assigns the length
parameter to the context object, and then constructs the two signals. You DO pass the name to
the signal constructor, but the name is passed to the signal object, not to the underlying type.
There is no way to reach the underlying type directly. Instead, the default constructors for
sc_signed and sc_unsigned reach out to the global area and get the currently defined length
parameter—the one you just set.

ModelSim® SE User's Manual, v10.7 447

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Construction Parameters for SystemC Types in 2.2

If you need to have signals or ports with different vector sizes, you need to include a pair of
parameter and context objects for each different size. For example, the following uses a five-bit
vector and an eight-bit vector:

SC_MODULE(dut) {

sc_length_param l1;
sc_length_context c1;

sc_signal<sc_signed> s1;
sc_signal<sc_signed> s2;

sc_length_param l2;
sc_length_context c2;

sc_signal<sc_signed> u1;
sc_signal<sc_signed> u2;

SC_CTOR(dut)
: l1(5), c1(l1), s1("s1"), s2("s2"),
l2(8), c2(l2), u1("u1"), u2("u2")
{
}
}

With simple variables of this type, you reuse the context object. However, you must have the
extra parameter and context objects when you are using them in a constructor-initialization list
because the compiler does not allow repeating an item in that list.

The four fixed-point types that use construction parameters work exactly the same way, except
that they use the objects sc_fxtype_contxt and sc_fxtype_params to do the work. Also, there are
more parameters you can set for fixed-point numbers. Assuming you want to set only the length
of the number and the number of fractional bits, the following example is similar to the
preceding example, modified for fixed-point numbers:

SC_MODULE(dut) {

sc_fxtype_params p1;
sc_fxtype_contxt c1;

sc_signal<sc_fix> s1;
sc_signal<sc_fix> s2;

sc_fxtype_params p2;
sc_fxtype_contxt c2;

sc_signal<sc_ufix> u1;
sc_signal<sc_ufix> u2;

448 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Construction Parameters for SystemC Types in 2.2

SC_CTOR(dut)
: p1(5,0), c1(p1), s1("s1"), s2("s2"),
p2(8,5), c2(p2), u1("u1"), u2("u2")
{
}
}

ModelSim® SE User's Manual, v10.7 449

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Troubleshooting SystemC Errors

Troubleshooting SystemC Errors

In the process of modifying your SystemC design to run on ModelSim, you may encounter
several common errors. This section highlights some actions you can take to correct such errors.
Unexplained Behaviors During Loading or Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Errors During Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

Unexplained Behaviors During Loading or Runtime

If your SystemC simulation behaves in otherwise unexplainable ways, you should determine
whether you need to adjust the stack space ModelSim allocates for threads in your design. The
required size for a stack depends on the depth of functions on that stack and the number of bytes
they require for automatic (local) variables.
By default the SystemC stack size is 10,000 bytes per thread.

You may have one or more threads needing a larger stack size. If so, call the SystemC function
set_stack_size() and adjust the stack to accommodate your needs. Note that you can ask for too
much stack space and have unexplained behavior as well.

Errors During Loading

When simulating your SystemC design, you might get a "failed to load sc lib" message because
of an undefined symbol, looking something like this:
# Loading /home/cmg/newport2_systemc/chip/vhdl/work/systemc.so

# ** Error: (vsim-3197) Load of "/home/cmg/newport2_systemc/chip/vhdl/

work/systemc.so" failed: ld.so.1:

/home/icds_nut/modelsim/5.8a/sunos5/vsimk: fatal: relocation error: file

/home/cmg/newport2_systemc/chip/vhdl/work/systemc.so: symbol
_Z28host_respond_to_vhdl_requestPm:

referenced symbol not found.

# ** Error: (vsim-3676) Could not load shared library /home/cmg/

newport2_systemc/chip/vhdl/work/systemc.so for SystemC module
'host_xtor'.

Source of Undefined Symbol Message

The causes for an error such as "failed to load sc lib" could be many.

450 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Errors During Loading

The reasons include:

• missing definition of a function/variable

• missing type
• object file or library containing the defined symbol is not linked
• mixing of C and C++ compilers to compile a testcase
• using SystemC 2.2 header files from other vendors
• bad link order specified in sccom -link
• multiply-defined symbols

Missing Definition
If the undefined symbol is a C function in your code or a library you are linking with, be sure
that you declared it as an extern "C" function:

extern "C" void myFunc();

This should appear in any header files include in your C++ sources compiled by sccom. It tells
the compiler to expect a regular C function; otherwise the compiler decorates the name for C++
and then the symbol cannot be found.

Also, be sure that you actually linked with an object file that fully defines the symbol. You can
use the "nm" utility on Unix platforms to test your SystemC object files and any libraries you
link with your SystemC sources. For example, assume you ran the following commands:

sccom test.cpp
sccom -link libSupport.a

If there is an unresolved symbol and it is not defined in your sources, it should be correctly
defined in any linked libraries:

nm libSupport.a | grep "mySymbol"

Missing Type
When you get errors during design elaboration, be sure that all the items in your SystemC
design hierarchy, including parent elements, are declared in the declarative region of a module.
If not, sccom ignores them.

ModelSim® SE User's Manual, v10.7 451

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Errors During Loading

For example, consider a design containing SystemC over VHDL. The following declaration of a
child module "test" inside the constructor module of the code is not allowed and will produce an
error:

SC_MODULE(Export)
{
SC_CTOR(Export)
{
test *testInst;
testInst = new test("test");
}
};

The error results from the fact that the SystemC parse operation will not see any of the children
of "test". Nor will any debug information be attached to it. Thus, the signal has no type
information and cannot be bound to the VHDL port.

The solution is to move the element declaration into the declarative region of the module.

Using SystemC Header Files Supplied by Other Vendors

Both SystemC 2.3.1 and SystemC 2.2 include version control for SystemC header files. If you
compile your SystemC design using a SystemC header file that was distributed by other
vendors, and then you run sccom -link to link the design, an error similar to the following may
result upon loading the design:

** Error: (vsim-3197) Load of "work/systemc.so" failed: work/systemc.so:

undefined symbol: _ZN20sc_api_version_2_1_0C1Ev.

To resolve the error, recompile the design using sccom. Make sure any include paths read by
sccom do not point to a SystemC 2.2 or 2.3.1 installation. By default, sccom automatically picks
up the ModelSim SystemC header files.

Misplaced -link Option

The order in which you place the -link option within the sccom -link command is critical. There
is a big difference between the following two commands:

sccom -link liblocal.a

and

sccom liblocal.a -link

The first command ensures that your SystemC object files are seen by the linker before the
library "liblocal.a" and the second command ensures that "liblocal.a" is seen first. Some linkers
can look for undefined symbols in libraries that follow the undefined reference while others can
look both ways. For more information on command syntax and dependencies, see sccom.

452 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Errors During Loading

Multiple Symbol Definitions

The most common type of error found during sccom -link operation is the multiple symbol
definition error. The error message looks something like this:

work/sc/gensrc/test_ringbuf.o: In function
`test_ringbuf::clock_generator(void)':

work/sc/gensrc/test_ringbuf.o(.text+0x4): multiple definition of

`test_ringbuf::clock_generator(void)'

work/sc/test_ringbuf.o(.text+0x4): first defined here

This error arises when the same global symbol is present in more than one .o file. There are two
common causes of this problem:

• A stale .o file in the working directory with conflicting symbol names.

In this first case, just remove the stale files with the following command:
vdel -lib <lib_path> -allsystemc

• Incorrect definition of symbols in header files.

In the second case, if you have an out-of-line function (one that is not preceded by the "inline"
keyword) or a variable defined (for instance, not just referenced or prototyped, but truly
defined) in a .h file, you cannot include that .h file in more than one .cpp file.

Text in .h files is included into .cpp files by the C++ preprocessor. By the time the compiler sees
the text, it is just as if you had typed the entire text from the .h file into the .cpp file. So an .h file
included into two .cpp files results in lots of duplicate text being processed by the C++ compiler
when it starts up. Include guards are a common technique to avoid duplicate text problems.

If an .h file has an out-of-line function defined, and that .h file is included into two .c files, then
the out-of-line function symbol will be defined in the two corresponding .o files. This leads to a
multiple symbol definition error during sccom -link.

To solve this problem, add the "inline" keyword to give the function "internal linkage." This
makes the function internal to the .o file, and prevents the function's symbol from colliding with
a symbol in another .o file.

For free functions or variables, you could modify the function definition by adding the "static"
keyword instead of "inline", although "inline" is better for efficiency.

Sometimes compilers do not honor the "inline" keyword. In such cases, you should move your
function(s) from a header file into an out-of-line implementation in a .cpp file.

ModelSim® SE User's Manual, v10.7 453

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Errors During Loading

454 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 9
Mixed-Language Simulation

ModelSim allows you to simulate designs that are written in VHDL, SystemC, Verilog, and
SystemVerilog. While design units must be entirely of one language type, any design unit may
instantiate other design units from another language. Any instance in the design hierarchy may
be a design unit from another language without restriction.
Basic Mixed-Language Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Different Compilers with Common Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
The SystemVerilog bind Construct in Mixed-Language Designs . . . . . . . . . . . . . . . . . . 460
Optimizing Mixed Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Simulator Resolution Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Runtime Modeling Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Mapping Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
VHDL Instantiating Verilog or SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Verilog or SystemVerilog Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Sharing User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
SystemC Instantiating Verilog or SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Verilog or SystemVerilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
SystemC Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
VHDL Instantiating SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
SystemC Procedural Interface to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

Basic Mixed-Language Flow

Simulating mixed-language designs with ModelSim consists of a few basic steps. The actions
you take for each step in the flow depend on which languages your design units are written in
and where they are in the design hierarchy.
1. Compile HDL source code using either the vcom or vlog command. Compile all
modules in the design following order-of-compile rules.
2. Compile SystemC C++ source code using the sccom command.
For SystemC designs with HDL instances — Create a SystemC foreign module
declaration for all Verilog/SystemVerilog and VHDL instances. For more information
on this declaration, refer to SystemC Foreign Module (Verilog) Declaration or SystemC
Foreign Module (VHDL) Declaration.

ModelSim® SE User's Manual, v10.7 455

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Basic Mixed-Language Flow

For Verilog/SystemVerilog/VHDL designs with SystemC instances — Export any

SystemC instances that will be directly instantiated by the other language using the
SC_MODULE_EXPORT macro. Instantiate exported SystemC modules as you would
instantiate any Verilog/SystemVerilog/VHDL module or design unit.
For VHDL with Verilog instances — Do not use vlog -nodebug=ports during
compilation of the Verilog modules because VHDL will not have the necessary access
to the port information.
For binding Verilog design units to VHDL or Verilog design units — See “The
SystemVerilog bind Construct in Mixed-Language Designs.” When using bind in
compilation unit scope, use the -cuname argument with the vlog command (see Separate
Bind Statements in the Compilation Unit Scope).
For binding Verilog design units to VHDL or Verilog design units or SystemC modules
— See “The SystemVerilog bind Construct in Mixed-Language Designs.” When using
bind in compilation unit scope, use the -cuname argument with the vlog command (see
Separate Bind Statements in the Compilation Unit Scope).
3. For designs containing SystemC — Link all objects in the design using sccom -link.
4. Elaborate and optimize your design using the vopt command. See Optimizing Mixed
Designs.
5. Simulate the design with the vsim command.
6. Run and debug your design.

456 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Different Compilers with Common Design Libraries

Different Compilers with Common Design

Libraries
Depending on the language of your design units, you need to use the appropriate compilation
command before running a simulation on the mixed-language design.
• VHDL source code is compiled by using the vcom command. ModelSim stores the
resulting compiled design units (entities, architectures, configurations, and packages) in
the working library.
• Verilog/SystemVerilog source code is compiled by using the vlog command. ModelSim
stores the resulting design units (modules and UDPs) in the working library.
• SystemC/C++ source code is compiled by using the sccom command. ModelSim
compiles the resulting object code into the working library.
Design libraries can store any combination of design units from any of the supported languages,
provided the design unit names do not overlap (VHDL design unit names are changed to lower
case). Refer to Design Libraries for more information about library management.

Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Hierarchical References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Access Limitations in Mixed-Language Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Case Sensitivity
Note that VHDL and Verilog observe different rules for case sensitivity.
• VHDL is not case-sensitive. For example, clk and CLK are regarded as the same name
for the same signal or variable.
• Verilog (and SystemVerilog) are case-sensitive. For example, clk and CLK are regarded
as different names that you could apply to different signals or variables.

Caution
VHDL is not case sensitive, so when you run vcom -mixedsvvh to compile the
VHDL package to use in Verilog or SystemVerilog, it silently converts all names in
the package to lower case (for example, InterfaceStage becomes interfacestage).
Because Verilog and SystemVerilog are case-sensitive, when you run the vlog compiler,
it looks for InterfaceStage in the compiled VHDL package but will not find it because it
does not match interfacestage (which is what vcom -mixedsvvh produced).
This means that you must write anything in a VHDL package that SystemVerilog uses in
lower case in the SystemVerilog source code, regardless of the upper/lower case used in
the VHDL source code.

ModelSim® SE User's Manual, v10.7 457

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Hierarchical References

Hierarchical References
ModelSim supports the IEEE 1076-2008 standard “external name” syntax that allows you to
make hierarchical references from VHDL to VHDL. Currently, these references can cross
Verilog boundaries, but they must begin and end in VHDL.
Note
The target of an external name must be a VHDL object. The location of the VHDL external
name declaration must be in VHDL but the actual path can start anywhere. This only applies
to the absolute path name because the relative path name starts at the enclosing concurrent
scope where the external name occurs.

The external names syntax allows references to be made to signals, constants, or variables, as
follows:

<<SIGNAL external_pathname : subtype_indication>>

<<CONSTANT external_pathname : subtype_indication>>
<<VARIABLE external_pathname : subtype_indication>>

external_pathname <=
absolute_pathname | relative_pathname | package_pathname

Notice that the standard requires the entire syntax be enclosed in double angle brackets, << >>.
It also requires that you specify the type of the object you are referencing.

Here are some examples of external references:

REPORT "Test Pin = " & integer'image(<<SIGNAL .tb.dut.i0.tp : natural>>)

SEVERITY note;

Q <= <<SIGNAL .tb.dut.i0.tp : std_logic_vector(3 DOWNTO 0)>>;

ALIAS test_pin IS <<SIGNAL .tb.dut.i0.tp : std_logic_vector(3 DOWNTO 0)>>;

...

test_pin(3) <= '1';

Q(0) <= test_pin(0);

To use this capability, use the vcom command to compile your VHDL source for the IEEE
1076-2008 syntax as follows:

vcom -2008 design.vhd testbench.vhd

458 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Access Limitations in Mixed-Language Designs

Note
Indexing and slicing of the name appears outside of the external name and is not part of the
external path name itself. For example:
<< signal u1.vector : std_logic_vector>>(3)
instead of
<< signal u1.vector(3): std_logic>>

The 1076-2002 syntax is the compiler's default.

The order of elaboration for Verilog to Verilog references that cross VHDL boundaries does not
matter. However, the object referenced by a VHDL external name must be elaborated before it
can be referenced.

SystemVerilog binds in VHDL scopes are translated to “equivalent” VHDL so that any
restrictions on VHDL external names apply to the hierarchical references in the bind statement
(that is, the target must be a VHDL object.) Because binds are done after all other instances
within a scope, there should be no ordering issues.

Access Limitations in Mixed-Language Designs

You cannot directly read or change a SystemC object with a hierarchical reference within a
mixed-language design. Further, you cannot directly access a Verilog/SystemVerilog object up
or down the hierarchy if there is an interceding SystemC block.
To access obstructed SystemC objects, propagate the value through the ports of all design units
in the hierarchy or use the control/observe functions. You can use either of the following
member functions of sc_signal to control and observe hierarchical signals in a design:

• control_foreign_signal()
• observe_foreign_signal()
For more information on the use of control and observe, refer to “Hierarchical References In
Mixed HDL and SystemC Designs”.

ModelSim® SE User's Manual, v10.7 459

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
The SystemVerilog bind Construct in Mixed-Language Designs

The SystemVerilog bind Construct in Mixed-

Language Designs
The SystemVerilog bind construct allows you to bind a Verilog design unit to another Verilog
design unit or to a VHDL design unit or to a SystemC module. This is especially useful for
binding SystemVerilog assertions to your SystemC, VHDL, Verilog and mixed-language
designs during verification.
Binding one design unit to another is a simple process of creating a module that you want to
bind to a target design unit, then writing a bind statement. For example, the following basic
steps show how to bind a SystemVerilog assertion module to a VHDL design:

1. Write assertions inside a Verilog module.

2. Designate a target VHDL entity or a VHDL entity/architecture pair.
3. Bind the assertion module to the target with a bind statement.
Binding a SystemVerilog assertion module to a SystemC module is similar except that in Step
2, you designate a target top-level SystemC module or an instance of a SystemC module in the
SystemC design hierarchy.

Modules, programs, or interfaces can be bound to:

• All instances of a target SystemC module

• A specific instance of the target SystemC module
• All instances that use a certain architecture in the target module
Binding to a configuration is not allowed.

Syntax of bind Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

Allowed Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Hierarchical References to a VHDL Object from a Verilog/SystemVerilog Scope. . . . 462
Mapping of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Optimization with SystemVerilog Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Port Mapping with VHDL and Verilog Enumerated Types . . . . . . . . . . . . . . . . . . . . . . 464
VHDL Instance Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Limitations to Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

460 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Syntax of bind Statement

Syntax of bind Statement

To bind a SystemVerilog assertion module to a VHDL design, the syntax of the bind statement
is:
bind <target_entity/architecture_name> <assertion_module_name>
<instance_name> <port connections>

To bind a SystemVerilog assertion module to a SystemC module, the syntax is:

bind <target SystemC module/full hierpath of an instance of a SystemC

module>
<assertion_module_name> <instance_name> <port connections>

This bind statement creates an instance of the assertion module inside the target VHDL entity/
architecture or SystemC module with the specified instance name and port connections. When
the target is a VHDL entity, the bind instance is created under the last compiled architecture.
Note that the instance being bound cannot contain another bind statement. In addition, a bound
instance can make hierarchical reference into the design.

Allowed Bindings
The following list provides examples of bindings you can make.
• Bind to all instances of a VHDL entity.
bind e bind_du inst(p1, p2);

• Bind to all instances of a VHDL entity and architecture.

bind \e(a) bind_du inst(p1, p2);

• Bind to multiple VHDL instances.

bind test.dut.inst1 bind_du inst(p1, p2);
bind test.dut.inst2 bind_du inst(p1, p2);
bind test.dut.inst3 bind_du inst(p1, p2);

• Bind to a single VHDL instance.

bind test.dut.inst1 bind_du inst(p1, p2);

• Bind to an instance where the instance path includes a for generate scope.
bind test.dut/forgen__4/inst1 bind_du inst(p1, p2);

• Bind to all instances of a VHDL entity and architecture in a library.

bind \mylib.e(a) bind_du inst(p1, p2);

• Bind to all instances of a SystemC module.

bind sc_mod bind_du inst(p1, p2);

ModelSim® SE User's Manual, v10.7 461

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Hierarchical References to a VHDL Object from a Verilog/SystemVerilog Scope

• Bind to multiple SystemC module instances.

bind test.dut.sc_inst1 bind_du inst(p1, p2);
bind test.dut.sc_inst2 bind_du inst(p1, p2);
bind test.dut.sc_inst3 bind_du inst(p1, p2);

• Bind to a single SystemC module instance.

bind test.dut.sc_inst1 bind_du inst(p1, p2);

Hierarchical References to a VHDL Object from a

Verilog/SystemVerilog Scope
ModelSim supports hierarchical references to VHDL Objects from a Verilog/SystemVerilog
scope.
The SystemVerilog “bind” construct allows you to access VHDL or Verilog objects. The only
restrictions applied are those of the bind context. For example, if you are binding into a VHDL
architecture, any hierarchical references in the bind statement must have targets in VHDL. A
bind into a Verilog context can have hierarchical references resolve to either VHDL or Verilog
objects.

Supported Objects
The only VHDL object types that can be referenced are: signals, shared variables, constants,
and generics not declared within processes. VHDL functions, procedures, and types are not
supported, and you cannot read VHDL process variables.

VHDL signals are treated as Verilog wires. You can use hierarchical references to VHDL
signals in instances and left-hand sides of continuous assignments, which can be read any place
a wire can be read and used in event control. Blocking assignments, non-blocking assignments,
force, and release are not supported for VHDL signals.

VHDL shared variables can be read anywhere a Verilog reg can be read. VHDL variables do
not have event control on them, therefore hierarchical references to VHDL shared variables
used in event control are an error by default. The statement @(vhdl_entity.shared_variable) will
never trigger. Because of this, you cannot use hierarchical references to VHDL shared variables
in instance port maps.

You can use non-blocking assignments and blocking assignments on VHDL shared variables.
VHDL constant and generics can be read anywhere. ModelSim treats them similarly to Verilog
parameters. The one exception is that they should not be used where constant expressions are
required. In addition, VHDL generics cannot be changed by a defparam statement.

462 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Mapping of Types

Supported Types
The following VHDL data types are supported for hierarchical references:

• basic scalar types

• vectors of scalar types
• fields of record that are supported types
If the VHDL type is in a package that is compiled with vcom -mixedsvvh, then the VHDL type
will be accessible in Verilog. If the type is not in a package or not compiled vcom -mixedsvvh
and an enum or record, then Verilog has limited access to it. It can read enum values as integers,
but cannot assign to enum objects because of strict type checking.

Complex types like records are supported if there exists a matching type in the language
generated with the -mixedsvvh switch for either the vcom or vlog commands.

Signal Spy for Hierarchical Access

The ModelSim Signal Spy™ technology provides hierarchical access to bound SystemVerilog
objects from VHDL objects. SystemVerilog modules also can access bound VHDL objects
using Signal Spy, and they can access bounded Verilog objects using standard Verilog
hierarchical references. Refer to the Signal Spy chapter for more information on the use of
Signal Spy.

Mapping of Types
All SystemVerilog data types supported at the SystemVerilog-VHDL boundary are supported
while binding to VHDL target scopes. This includes hierarchical references in actual
expressions if they terminate in a VHDL scope. These data-types follow the same type-mapping
rules followed at the SystemVerilog-VHDL mixed-language boundary for direct instantiation.
All the types supported at the SystemC-SystemVerilog mixed language boundary are also
supported when binding to a SystemC target. Please refer to Verilog or SystemVerilog and
SystemC Signal Interaction And Mappings for a complete list of all supported types.

Related Topics
Mapping Data Types

Optimization with SystemVerilog Bind

The SystemVerilog bind statement, when using the vopt command, is fully compatible with
IEEE Std1800-2009 (the SystemVerilog Language Reference Manual).

ModelSim® SE User's Manual, v10.7 463

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Mapping with VHDL and Verilog Enumerated Types

Related Topics
Optimizing Designs with vopt

Port Mapping with VHDL and Verilog Enumerated

Types
SystemVerilog infers an enumeration concept similar to VHDL enumerated types. In VHDL,
the enumerated names are assigned to a fixed enumerated value, starting left-most with the
value 0. In SystemVerilog, you can also explicitly define the enumerated values. As a result,
you can use the bind construct for port mapping of VHDL enumerated types to Verilog port
vectors.
Port mapping is supported for both input and output ports. ModelSim first converts the integer
value of the enum to a bit vector before connecting to a Verilog formal port. Note that you
cannot connect an enum value on port actual—it has to be signal. In addition, port vectors can
be of any size less than or equal to 32.

This kind of port mapping between VHDL enum and Verilog vector is only allowed when the
Verilog is instantiated under VHDL through the bind construct and is not supported for normal
instances.

Table 9-1 shows the allowed VHDL types for port mapping to SystemVerilog port vectors.
Table 9-1. VHDL Types Mapped To SystemVerilog Port Vectors
bit std_logic vl_logic
bit_vector std_logic_vector vl_logic_vector

Example of Binding to VHDL Enumerated Types

Consider an example of using SystemVerilog assertions to monitor a VHDL finite state
machine that uses enumerated types. With ModelSim, you can use the bind statement to map
VHDL enumerated types directly to SystemVerilog enumerated types.

The following steps show how to follow the same type-sharing rules, which are applicable for
direct instantiations at the SystemVerilog-VHDL mixed-language boundary (refer to Sharing
User-Defined Types).

464 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Mapping with VHDL and Verilog Enumerated Types

Example 9-1. SystemVerilog Assertions Monitor a VHDL Finite State Machine

Consider the following enumerated type defined in a VHDL package:

--/*----------pack.vhd---------------*/
package pack is
type fsm_state is(idle, send_bypass,
load0,send0, load1,send1, load2,send2,
load3,send3, load4,send4, load5,send5,
load6,send6, load7,send7, load8,send8,
load9,send9, load10,send10,
load_bypass, wait_idle);
end package;

The following procedure shows how to use this at the mixed-language boundary of
SystemVerilog and VHDL.

1. Compile this package using the -mixedsvvh argument for the vcom command:
vcom -mixedsvvh pack.vhd

2. Make the package available to the design in either of the following ways:
o Include this package in your VHDL target, like a normal VHDL package:
use work.pack.all;
...
signal int_state : fsm_state;
signal nxt_state : fsm_state;
...

o Import this package to the SystemVerilog module containing the properties to be

monitored, as if it were a SystemVerilog package.
import pack::*;
....
input port:
module interleaver_props (
input clk, in_hs, out_hs,
input fsm_state int_state
);
...
// Check for sync byte at the start of a every packet property
pkt_start_check;
- @(posedge clk) (int_state == idle && in_hs) -> (sync_in_valid);
endproperty
...

3. Assume you want to implement functional coverage of the VHDL finite state machine
states. With ModelSim, you can bind any SystemVerilog functionality, such as

ModelSim® SE User's Manual, v10.7 465

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL Instance Mapping

functional coverage, into a VHDL object. To do this, define the following covergroup in
SystemVerilog:
...
covergroup sm_cvg @(posedge clk);
coverpoint int_state
{
bins idle_bin = {idle};
bins load_bins = {load_bypass, load0, load9, load10};
bins send_bins = {send_bypass, send0, send9, send10};
bins others = {wait_idle};
option.at_least = 500;
}
coverpoint in_hs;
in_hsXint_state: cross in_hs, int_state;
endgroup
sm_cvg sm_cvg_c1 = new;
...

4. As with monitoring VHDL components, you create a wrapper containing the bind
statement to connect the SystemVerilog Assertions to the VHDL component:
module interleaver_binds;
...
// Bind interleaver_props to a specific interleaver instance
// and call this instantiate interleaver_props_bind
bind interleaver_m0 interleaver_props interleaver_props_bind (
// connect the SystemVerilog ports to VHDL ports (clk)
// and to the internal signal (int_state)
.clk(clk), ..
.int_state(int_state)
);
...
endmodule

5. Use either of the following to perform the actual binding in ModelSim:

o instantiation
o loading of multiple top modules into the simulator with the vsim command:
vsim interleaver_tester interleaver_binds

Related Topics
Sharing User-Defined Types

VHDL Instance Mapping

You can use the SystemVerilog bind statement to tie an assertion to VHDL design units that are
defined by generate or configuration statements.
Example 9-2 shows how to use the bind statement in a SystemVerilog wrapper module to
connect a SystemVerilog cover directive to a VHDL component.

466 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL Instance Mapping

Example 9-2. Using the Bind Statement with VHDL Component and
SystemVerilog Assertion

Consider the following VHDL code that uses nested generate statements:

architecture Structure of Test is

signal A, B, C : std_logic_vector(0 to 3);
...
begin
TOP : for i in 0 to 3 generate
First : if i = 0 generate
— configure it..
for all : thing use entity work.thing(architecture_ONE);
begin
Q : thing port map (A(0), B(0), C(0));
end generate;
Second : for i in 1 to 3 generate
— configure it..
for all : thing use entity work.thing(architecture_TWO);
begin
Q : thing port map ( A(i), B(i), C(i) );
end generate;
end generate;
end Structure;

The following SystemVerilog program (SVA) uses a cover directive to define the assertion:

program SVA (input c, a, b);

…
sequence s1;
@(posedge c) a ##1 b ;
endsequence cover property (s1);
…
endprogram

To tie the SystemVerilog cover directive to the VHDL component, you can use a wrapper
module such as the following:

module sva_wrapper;
bind test.top__2.second__1.q // Bind a specific instance
SVA // to SVA and call this
sva_bind // instantiation sva_bind
( .a(A), .b(B), .c(C) ); // Connect the SystemVerilog ports to
// VHDL ports (A, B and C)
endmodule

You can instantiate sva_wrapper in the top level or simply load multiple top modules into the
simulator:

vlib work
vlog *.sv
vcom *.vhd
vsim test sva_wrapper

ModelSim® SE User's Manual, v10.7 467

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL Instance Mapping

This binds the SystemVerilog program, named SVA, to the specific instance defined by the
generate and configuration statements.

Tip
: You can control the format of generate statement labels by using the GenerateFormat
variable in the modelsim.ini file.

Separate Bind Statements in the Compilation Unit Scope

Bind statements are allowed in module, interface, and program blocks, and may exist in the
compilation unit scope. ModelSim treats the compilation unit scope ($unit) as a package,
internally wrapping the content of $unit into a package. Before vsim elaborates a module, it
elaborates all packages upon which that module depends. In other words, it elaborates a $unit
package before a module in the compilation unit scope.

Note that when the bind statement is in the compilation unit scope, the bind becomes effective
only when $unit package gets elaborated by vsim. In addition, the package gets elaborated only
when a design unit that depends on that package gets elaborated. As a result, if you have a file in
a compilation unit scope that contains only bind statements, you can compile that file by itself,
but the bind statements will never be elaborated. A warning to this effect is generated by the
vlog command if bind statements are found in the compilation unit scope.

The -cuname argument for vlog gives a user-defined name to a specified compilation $unit
package (which, in the absence of -cuname, is some internally generated name). You must
provide this named compilation unit package as the top-level design unit with the vsim
command in order to force elaboration.

Tip
: If you are using the vlog -R commands to compile and simulate the design, ModelSim
handles this binding issue automatically.

The vlog -cuname argument is used only in conjunction with the vlog -mfcu argument, which
instructs the compiler to treat all files within a compilation command line as a single
compilation unit.

Example 9-3 shows how to use vlog -cuname and -mfcu arguments to elaborate a bind
statement contained in its own file.

468 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL Instance Mapping

Example 9-3. Using vlog -cuname and -mfcu Arguments to Ensure Proper
Elaboration

Consider the following SystemVerilog module, called checker.sv, that contains an assertion for
checking a counter:

module checker(clk, reset, cnt);

parameter SIZE = 4;
input clk;
input reset;
input [SIZE-1:0] cnt;
property check_count;
@(posedge clk)
!reset |=> cnt == ($past(cnt) + 1);
endproperty assert property (check_count);
endmodule

Next, bind that assertion module to the following counter module named counter.sv.

module counter(clk, reset, cnt);

parameter SIZE = 8;
input clk;
input reset;
output [SIZE-1:0] cnt;
reg [SIZE-1:0] cnt;
always @(posedge clk)
begin
if (reset == 1'b1)
cnt = 0;
else
cnt = cnt + 1;
end
endmodule

using the bind statement contained separately in a file named bind.sv, which will reside in the
compilation unit scope.

bind counter checker #(SIZE) checker_inst(clk, reset, cnt);

This statement instructs ModelSim to create an instance of checker in the target module,
counter.sv.

The final module of this design is a test bench, named tb.sv.

ModelSim® SE User's Manual, v10.7 469

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Limitations to Bind Support for SystemC

module testbench;
reg clk, reset;
wire [15:0] cnt;
counter #(16) inst(clk, reset, cnt);
initial
begin
clk = 1'b0;
reset = 1'b1;
#500 reset = 1'b0;
#1000 $finish;
end
always #50 clk = ~clk;
endmodule

If the bind.sv file is compiled by itself (vlog bind.sv), you will receive a Warning like this one:

** Warning: 'bind' found in a compilation unit scope that either does not
contain any design units or only contains design units that are
instantiated by 'bind'. The 'bind' instance will not be elaborated.

To fix this problem, use the -cuname argument with the vlog command, as follows:

vlog -cuname bind_pkg -mfcu bind.sv

Then enter the following command to simulate the design:

vsim testbench bind_pkg

Limitations to Bind Support for SystemC

If the target of a bind is a SystemC module or an instance of a SystemC module, expressions
and literals are not supported as actuals.
These types of expressions and literals include, but are not limited to,

• bitwise binary expressions using operators &, |, ~, ^ and ^~

• concatenation expression
• bit select and part select expressions
• variable/constant

Optimizing Mixed Designs

The vopt command performs global optimizations to improve simulator performance. You run
vopt on the top-level design unit.
Related Topics
Optimizing Designs with vopt

470 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Simulator Resolution Limit

Simulator Resolution Limit

In a mixed-language design with only one top-level design unit, the resolution for simulation
time of the top design unit is applied to the whole design.
If the root of the mixed design is VHDL, then VHDL simulator resolution rules are used (see
Simulator Resolution Limit for VHDL for VHDL details). If the root of the mixed design is
Verilog or SystemVerilog, Verilog rules are used (refer to Simulator Resolution Limit (Verilog)
for details).

If the root is SystemC, then SystemC rules are used (refer to SystemC Time Unit and Simulator
Resolution for details).

In the case of a mixed-language design with multiple tops, the following algorithm is used:

• If VHDL or SystemC modules are present, then the Verilog resolution is ignored. An
error is issued if the Verilog resolution is finer than the chosen one.
• If VHDL modules are present, then the Verilog resolution is ignored. An error is issued
if the Verilog resolution is finer than the chosen one.
• If both VHDL and SystemC are present, then the resolution is chosen based on which
design unit is elaborated first. For example:
vsim sc_top vhdl_top -do vsim.do

In this case, the SystemC resolution (default 1 ns) is chosen.

vsim vhdl_top sc_top -do vsim.do

In this case, the VHDL resolution is chosen.

• All resolutions specified in the source files are ignored if vsim is invoked with the -t
option. When set, this overrides all other resolutions.

ModelSim® SE User's Manual, v10.7 471

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Runtime Modeling Semantics

Runtime Modeling Semantics

The ModelSim simulator is compliant with all pertinent Language Reference Manuals for each
language of a mixed-language design.
To achieve this compliance, the sequence of operations in one simulation iteration (that is, delta
cycle) is as follows:

1. SystemC processes are run

2. Signal updates are made
3. HDL processes are run
The above scheduling semantics are required to satisfy both the SystemC and the HDL LRM.
Namely, all processes triggered by an event in a SystemC primitive channel shall wake up at the
beginning of the following delta. All processes triggered by an event on an HDL signal shall
wake up at the end of the current delta.

The above scheduling semantics are required to satisfy the HDL LRM. All processes triggered
by an event on an HDL signal shall wake up at the end of the current delta.

For a signal chain that crosses the language boundary, this means that processes on the SystemC
side get woken up one delta later than processes on the HDL side. Consequently, one delta of
skew will be introduced between such processes. However, if the processes are communicating
with each other, correct system behavior will still result.

Hierarchical References to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Hierarchical References In Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . . 473
Signal Connections Between Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . 474

Hierarchical References to SystemVerilog

Hierarchical references to SystemVerilog properties and sequences are supported with the
following restrictions.
• Clock and disable iff expressions cannot have a formal.
• Method 'matched' is not supported on a hierarchically referenced sequence

472 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Hierarchical References In Mixed HDL and SystemC Designs

Hierarchical References In Mixed HDL and SystemC

Designs
A SystemC signal (including sc_signal, sc_buffer, sc_signal_resolved, and sc_signal_rv) can
control or observe an HDL signal using two member functions of sc_signal:
bool control_foreign_signal(const char* name);
bool observe_foreign_signal(const char* name);

The argument (const char* name) is a full hierarchical path to an HDL signal or port. These
functions always return “true” for all cases (even if the call failed). However, an error is issued
if the call could not be completed due to any reason. See tables for Verilog/SystemVerilog
(Data Type Mapping from SystemC to Verilog or SystemVerilog) and VHDL (Data Type
Mapping Between SystemC and VHDL) to view a list of types supported at the mixed language
boundary. If it is a supported boundary type, it is supported for hierarchical references.

Note
SystemC control/observe always return “true” for all cases (even if the call failed).

Control
When a SystemC signal calls control_foreign_signal() on an HDL signal, the HDL signal is
considered a fanout of the SystemC signal. This means that every value change of the SystemC
signal is propagated to the HDL signal. If there is a pre-existing driver on the HDL signal which
has been controlled, the value of the HDL signal is the resolved value of the existing driver and
the SystemC signal. This value remains in effect until a subsequent driver transaction occurs on
the HDL signal, following the semantics of the force -deposit command.

Observe
When a SystemC signal calls observe_foreign_signal() on an HDL signal, the SystemC signal
is considered a fanout of the HDL signal. This means that every value change of the HDL signal
is propagated to the SystemC signal. If there is a pre-existing driver on the SystemC signal
which has been observed, the value is changed to reflect that of the HDL signal. This value
remains in effect until a subsequent driver transaction occurs on the SystemC signal, following
the semantics of the force -deposit command.

ModelSim® SE User's Manual, v10.7 473

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Signal Connections Between Mixed HDL and SystemC Designs

Example
SC_MODULE(test_ringbuf)
{
sc_signal<bool> observe_sig;
sc_signal<sc_lv<4> > control_sig;

// HDL module instance

ringbuf* ring_INST;

SC_CTOR(test_ringbuf)
{
ring_INST = new ringbuf("ring_INST", "ringbuf");
.....
observe_sig.observe_foreign_signal("/test_ringbuf/ring_INST/block1_INST/
buffers(0)");

control_sig.control_foreign_signal("/test_ringbuf/ring_INST/block1_INST/
sig");
}
};

Signal Connections Between Mixed HDL and

SystemC Designs
You can use the scv_connect() API function to connect a SystemC signal (including sc_signal,
sc_buffer, sc_signal_resolved, and sc_signal_rv) to an HDL signal.
Note
The behavior of scv_connect() is identical to the behavior of the Control and Observe
functions, described above in Hierarchical References In Mixed HDL and SystemC
Designs.

The scv_connect() API is provided by the SystemC Verification Standard and is defined as
follows:

/* Function to connect an sc_signal object to an HDL signal. */

template < typename T> void scv_connect(
sc_signal<T> & signal,
const char * hdl_signal,
scv_hdl_direction d = SCV_OUTPUT,
unsigned hdl_sim_inst = 0
);

/* Function to connect an sc_signal_resolved object to an HDL signal. */

void scv_connect(
sc_signal_resolved& signal,
const char * hdl_signal,
scv_hdl_direction d = SCV_OUTPUT,
unsigned hdl_sim_inst = 0
);

474 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Signal Connections Between Mixed HDL and SystemC Designs

/* Function connects an sc_signal_rv object to an HDL signal. */

template < int W> void scv_connect(
sc_signal_rv<W>& signal,
const char * hdl_signal,
scv_hdl_direction d = SCV_OUTPUT,
unsigned hdl_sim_inst = 0
);

where

• signal — is an sc_signal, sc_signal_resolved or sc_signal_rv object

• hdl_signal — is the full hierarchical path to an HDL signal or port
• d — is the direction of the connection given by enum scv_hdl_direction
• hdl_sim_inst — is not supported and any value given for this argument will be ignored
enum scv_hdl_direction {
SCV_INPUT = 1, /* HDL is the only driver */
SCV_OUTPUT = 2 /* SystemC is the only driver */
};

Supported Types
The scv_connect() function supports all datatypes supported at the SystemC-HDL
mixed-language boundaries. Refer to the tables for Verilog/SystemVerilog (Data Type Mapping
from SystemC to Verilog or SystemVerilog) and VHDL (Data Type Mapping Between
SystemC and VHDL) to view a list of types supported at the mixed language boundary. If it is a
supported boundary type, it is supported for hierarchical references.

ModelSim® SE User's Manual, v10.7 475

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Mapping Data Types

Mapping Data Types

Cross-language (HDL) instantiation does not require additional effort on your part. As
ModelSim loads a design, it detects cross-language instantiations because it can determine the
language type of each design unit as it is loaded from a library. ModelSim then performs the
necessary adaptations and data type conversions automatically.
SystemC and HDL cross-language instantiation requires minor modification of SystemC source
code (such as the addition of SC_MODULE_EXPORT and sc_foreign_module).

A VHDL instantiation of Verilog may associate VHDL signals and values with Verilog ports
and parameters. Likewise, a Verilog instantiation of VHDL may associate Verilog nets and
values with VHDL ports and generics.

This is also true for SystemC and VHDL/Verilog/SystemVerilog ports.

The following sections describe data type mappings for mixed-language designs in ModelSim:

Verilog and SystemVerilog to VHDL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

VHDL To Verilog and SystemVerilog Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings . . . . . . . . . 487
VHDL and SystemC Signal Interaction and Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Verilog and SystemVerilog to VHDL Mappings

Verilog or SystemVerilog instantiations of VHDL may associate Verilog nets and values with
VHDL ports and generics.
Table 9-2 shows the mapping of data types from SystemVerilog to VHDL.
Table 9-2. SystemVerilog-to-VHDL Data Type Mapping
SystemVerilog Type VHDL Type Comments
Primary mapping Secondary mapping
bit bit std_logic 2-state scalar data type
logic std_logic bit 4-state scalar data type
reg std_logic bit 4-state scalar data type
wire std_logic bit A scalar wire
bit vector bit_vector std_logic_vector A signed/unsigned,
packed/unpacked single
dimensional bit vector
reg vector std_logic_vector bit_vector A signed/unsigned,
packed/unpacked single
dimensional logic vector

476 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog and SystemVerilog to VHDL Mappings

Table 9-2. SystemVerilog-to-VHDL Data Type Mapping (cont.)

SystemVerilog Type VHDL Type Comments
Primary mapping Secondary mapping
wire vector std_logic_vector bit_vector A signed/unsigned,
packed/unpacked single
dimensional multi-bit
wire
logic vector std_logic_vector bit_vector A signed/unsigned,
packed/unpacked single
dimensional logic vector
integer integer 4-state data type, 32-bit
signed integer
integer unsigned integer 4-state data type, 32-bit
unsigned integer
int integer 2-state data type, 32-bit
signed integer
shortint integer 2-state data type, 16-bit
signed integer
longint integer 2-state data type, 64-bit
signed integer
int unsigned integer 2-state data type, 32-bit
unsigned integer
shortint unsigned integer 2-state data type, 16-bit
unsigned integer
longint unsigned integer 2-state data type, 64-bit
unsigned integer
byte integer 2-state data type, 8-bit
signed integer or ASCII
character
byte unsigned integer 2-state data type, 8-bit
unsigned integer or
ASCII character
enum enum SystemVerilog enums of
only 2-state int base type
supported
struct record unpacked structure
packed struct record std_logic_vector packed structure
bit_vector

ModelSim® SE User's Manual, v10.7 477

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog and SystemVerilog to VHDL Mappings

Table 9-2. SystemVerilog-to-VHDL Data Type Mapping (cont.)

SystemVerilog Type VHDL Type Comments
Primary mapping Secondary mapping
real real 2-state data type, 64-bit
real number
shortreal real 2-state data type, 32-bit
real number
multi-D arrays multi-D arrays multi-dimensional arrays
of supported types

Verilog Parameters
The type of a Verilog parameter is determined by its initial value.
Table 9-3. Verilog Parameter to VHDL Mapping
Verilog type VHDL type
integer1 integer
real real
string string
packed vector std_logic_vector bit_vector
1. By default, untyped Verilog parameters that are initialized with unsigned values
between 231-1 and 232 are converted to VHDL integer generics. Because VHDL integer
parameters are signed numbers, the Verilog values 231-1 to 232 are converted to negative
VHDL values in the range from -231 to -1 (the 2's complement value). To prevent this
mapping, compile using the vlog -noForceUnsignedToVhdlInteger command.

For more information on using Verilog bit type mapping to VHDL, refer to the Usage Notes
under “VHDL Instantiation Criteria Within Verilog.”

Allowed VHDL Types for Verilog Ports

The following is a list of allowed VHDL types for ports connected to Verilog nets and for
signals connected to Verilog ports:
bit real std_ulogic_vector
bit_vector record vl_logic
enum shortreal vl_logic_vector
integer std_logic vl_ulogic
natural std_logic_vector vl_ulogic_vector
positive std_ulogic multi-dimensional arrays

478 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog and SystemVerilog to VHDL Mappings

Note
Note that you can use the wildcard syntax convention (.*) when instantiating Verilog ports
where the instance port name matches the connecting port name and their data types are
equivalent.

The vl_logic type is an enumeration that defines the full state set for Verilog nets, including
ambiguous strengths. The bit and std_logic types are convenient for most applications, but the
vl_logic type is provided in case you need access to the full Verilog state set. For example, you
may wish to convert between vl_logic and your own user-defined type. The vl_logic type is
defined in the vl_types package in the pre-compiled verilog library. This library is provided in
the installation directory along with the other pre-compiled libraries (std and ieee). The vl_logic
type is defined in the following file installed with ModelSim:

<install_dir>/vhdl_src/verilog/vltypes.vhd

Verilog States
Verilog states are mapped to std_logic and bit as follows:
Table 9-4. Verilog States Mapped to std_logic and bit
Verilog std_logic bit
HiZ 'Z' '0'
Sm0 'L' '0'
Sm1 'H' '1'
SmX 'W' '0'
Me0 'L' '0'
Me1 'H' '1'
MeX 'W' '0'
We0 'L' '0'
We1 'H' '1'
WeX 'W' '0'
La0 'L' '0'
La1 'H' '1'
LaX 'W' '0'
Pu0 'L' '0'
Pu1 'H' '1'
PuX 'W' '0'

ModelSim® SE User's Manual, v10.7 479

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

Table 9-4. Verilog States Mapped to std_logic and bit (cont.)

Verilog std_logic bit
St0 '0' '0'
St1 '1' '1'
StX 'X' '0'
Su0 '0' '0'
Su1 '1' '1'
SuX 'X' '0'
For Verilog states with ambiguous strength:

• bit receives '0'

• std_logic receives 'X' if either the 0 or 1 strength component is greater than or equal to
strong strength
• std_logic receives 'W' if both the 0 and 1 strength components are less than strong
strength

VHDL To Verilog and SystemVerilog Mappings

VHDL instantiations of Verilog or SystemVerilog may associate VHDL ports and generics with
Verilog nets and values.
Table 9-5 summarizes the mapping of data types from VHDL to SystemVerilog.
Table 9-5. VHDL to SystemVerilog Data Type Mapping
VHDL Type SystemVerilog Type Comments
Primary mapping Secondary mapping
bit bit reg, logic 2-state scalar data type
boolean bit reg, logic 2-state enum data type
std_logic reg bit, logic 4-state scalar data type
bit_vector bit vector reg vector, wire vector, A signed/unsigned,
logic vector, struct packed/unpacked bit
packed vector
std_logic_vector reg vector bit_vector, wire vector, A signed/unsigned,
logic vector, struct packed/unpacked logic
packed vector

480 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

Table 9-5. VHDL to SystemVerilog Data Type Mapping (cont.)

VHDL Type SystemVerilog Type Comments
Primary mapping Secondary mapping
integer int integer, shortint, 2-state data type, 32-bit
longint, int unsigned, signed integer
shortint unsigned,
longint unsigned, byte,
byte unsigned
enum enum VHDL enumeration
types
record struct packed struct VHDL records
real real shortreal 2-state data type, 64-bit
real number
multi-dimensional multi-dimensional multi-dimensional arrays
arrays arrays of supported types

Mapping VHDL Generics to Verilog Types

Table 9-6 shows the mapping of VHDL Generics to Verilog types.
Table 9-6. VHDL Generics to Verilog Mapping
VHDL type Verilog type
integer, real, time, physical, enumeration integer or real
string string literal
bit, st_logic, bit_vector, std_logic_vector, vl_logic, packed vector
vl_logic_vector1
1. Note that Verilog vectors (such as 3'b011) that can be represented as an integer value are mapped to
generic of integer type (to preserve backward compatibility). Only vectors whose values cannot be
represented as integers (such as 3'b0xx) are mapped to generics of this type.

When a scalar type receives a real value, the real is converted to an integer by truncating the
decimal portion.

Type time is treated specially: the Verilog number is converted to a time value according to the
‘timescale directive of the module.

Physical and enumeration types receive a value that corresponds to the position number
indicated by the Verilog number. In VHDL this is equivalent to T'VAL(P), where T is the type,
VAL is the predefined function attribute that returns a value given a position number, and P is
the position number.

ModelSim® SE User's Manual, v10.7 481

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

VHDL type bit is mapped to Verilog states as shown in Table 9-9:

Table 9-7. Mapping VHDL bit to Verilog States
VHDL bit Verilog State
'0' St0
'1' St1

VHDL type std_logic is mapped to Verilog states as shown in Table 9-8:

Table 9-8. Mapping VHDL std_logic Type to Verilog States
VHDL std_logic Verilog State
'U' StX
'X' StX
'0' St0
'1' St1
'Z' HiZ
'W' PuX
'L' Pu0
'H' Pu1
'–' StX

VHDL Generics at a VHDL-SystemVerilog Mixed-Language Boundary

This section describes support for overriding generics at the boundary of a VHDL-
SystemVerilog design where VHDL instantiates SystemVerilog. Essentially, overriding
generics while instantiating SystemVerilog inside VHDL is identical to overriding parameters
while instantiating SystemVerilog inside SystemVerilog.

ModelSim overrides generics at a VHDL-SystemVerilog boundary based on the style of

declaration for the SystemVerilog parameters at the boundary:

• Verilog-Style Declarations
• SystemVerilog-Style Declarations
• Miscellaneous Declarations

Verilog-Style Declarations
This category is for all parameters that are defined using a Verilog-style declaration. This style
of declaration does not have a type or range specification, so the type of these parameters is
inferred from the final value that gets assigned to them.

482 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

Direct Entity Instantiation

The type of the formal Verilog parameter will be changed based on the type inferred from the
VHDL actual. While resolving type, ModelSim gives preference to the primary type (type that
is inferred from the initial value of the parameter) over other types. Further, ModelSim does not
allow subelement association while overriding such generics from VHDL.

For example:

// SystemVerilog
parameter p1 = 10;

-- VHDL
inst1 : entity work.svmod generic map (p1 => integer'(20));
inst2 : entity work.svmod generic map (p1 => real'(2.5));
inst3 : entity work.svmod generic map (p1 => string'("Hello World"));
inst3 : entity work.svmod generic map (p1 => bit_vector'("01010101"));

Component Instantiation
For Verilog-style declarations, ModelSim allows you to override the default type of the generic
in your component declarations.

For example:

// SystemVerilog
parameter p1 = 10;

-- VHDL
component svmod
generic (p1 : std_logic_vector(7 downto 0));
end component;
...
inst1 : svmod generic map (p1 => "01010101");

Table 9-9. Mapping Table for Verilog-style Declarations

Type of Verilog Type of VHDL Actual
Formal
All supported types All supported types

SystemVerilog-Style Declarations
This category is for all parameters that are defined using a SystemVerilog-style declaration.
This style of declaration has an explicit type defined, which does not change based on the value
that gets assigned to them.

Direct Entity Instantiation

The type of the SystemVerilog parameter is fixed. While ModelSim overrides it through
VHDL, it will be an error if the type of the actual is not one of its equivalent VHDL types.
Table 9-10 provides a mapping table that lists equivalent types.

ModelSim® SE User's Manual, v10.7 483

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

For example:

// SystemVerilog
parameter int p1 = 10;

-- VHDL
inst1 : entity work.svmod generic map (p1 => integer'(20)); -- OK
-- inst2 : entity work.svmod generic map (p1 => real'(3.5)); -- ERROR
-- inst3 : entity work.svmod generic map (p1 => string'("Hello World"));
-- ERROR
inst4 : entity work.svmod generic map (p1 => bit_vector'("010101010101"));
-- OK

Component Instantiation
ModelSim allows only the VHDL equivalent type of the type of the SystemVerilog parameter in
the component declaration. Using any other type will result in a type-mismatch error.

For example:

// SystemVerilog
parameter int p1 = 10;

-- VHDL
component svmod
generic (p1 : bit_vector(7 downto 0));
end component;
...
inst1 : svmod generic map (p1 => "01010101");

Table 9-10. Mapping Table for SystemVerilog-style Declarations

Type of Verilog Formal Type of VHDL Actual
bit, logic, reg std_logic
bit
boolean
integer (truncate)
std_logic_vector (truncate)
bit_vector (truncate)
real (round off to nearest integer and handle as bit vector)
string (truncate)

484 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

Table 9-10. Mapping Table for SystemVerilog-style Declarations (cont.)

Type of Verilog Formal Type of VHDL Actual
bit/logic/reg vector std_logic (pad with 0)
bit (pad with 0)
boolean (pad with 0)
std_logic_vector (truncate or pad with 0)
bit_vector (truncate or pad with 0)
integer (truncate or pad with 0)
real (round off to nearest integer and handle as bit vector)
string (truncate or pad with 0)
integer, int, shortint, longint, byte bit_vector (truncate or pad with 0)
std_logic_vector (truncate or pad with 0)
integer (truncate or pad with 0)
bit (pad with 0)
boolean (pad with 0)
std_logic (pad with 0)
real (round off to nearest integer)
string (truncate or pad with 0)
real, shortreal real
integer
string string
In addition to the mapping in Table 9-10, ModelSim handles sign specification while overriding
SystemVerilog parameters from VHDL in accordance with the following rules:

• A Verilog parameter with a range specification, but with no type specification, shall
have the range of the parameter declaration and shall be unsigned. The sign and range
shall not be affected by value overrides from VHDL.
• A Verilog parameter with a signed type specification and with a range specification shall
be signed and shall have the range of its declaration. The sign and range shall not be
affected by value overrides from VHDL.

Miscellaneous Declarations
The following types of parameter declarations require special handling, as described below.

Untyped SystemVerilog Parameters

These parameters do not have default values and types defined in their declarations.

ModelSim® SE User's Manual, v10.7 485

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL To Verilog and SystemVerilog Mappings

For example:

parameter p1;

Because no default value is specified, you must specify an overriding parameter value in every
instantiation of the parent SystemVerilog module inside VHDL. ModelSim will consider it an
error if these parameters are omitted during instantiation.

Direct Entity Instantiation

Because the parameter does not have a type of its own and takes on the type of the actual, it is
important that you define the type of the actual unambiguously. If ModelSim cannot determine
the type of the actual, it will be considered an error.

For example:

// SystemVerilog
parameter p1;

-- VHDL
inst1 : entity work.svmod generic map (p1 => integer'(20)); -- OK
inst2 : entity work.svmod generic map (p1 => real'(3.5)); -- OK
inst3 : entity work.svmod generic map (p1 => string'("Hello World"));
-- OK

Component Instantiation
It is your responsibility to define a type of generics corresponding to untyped SystemVerilog
parameters in their component declarations. ModelSim will issue an error if an untyped
SystemVerilog parameter is omitted in the component declaration.

The vgencomp command will dump a comment instead of the type of the generic,
corresponding to an untyped parameter, and prompt you to put in your own type there.

For example:

// SystemVerilog
parameter p1;

-- VHDL
component svmod
generic (p1 : bit_vector(7 downto 0) := "00000000" );
end component;
...
inst1 : svmod generic map (p1 => "01010101");

Typed SystemVerilog Parameters

A parameter can also specify a data type, which allows modules, interfaces, or programs to have
ports and data objects whose type is set for each instance. However, these types are not
supported because ModelSim converts Verilog modules into VHDL entity declarations
(_primary.vhd) and supports only those constructs that are currently handled by the VHDL
language.

486 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

For example:

module ma #( parameter p1 = 1, parameter type p2 = shortint) (input logic

[p1:0] i, output logic [p1:0] o);
p2 j = 0; // type of j is set by a parameter, (shortint unless redefined)
endmodule

module mb;
logic [3:0] i,o;
ma #(.p1(3), .p2(int)) u1(i,o); //redefines p2 to a type of int
endmodule

Parameters With Expressions As Default Values or No Default Values

ModelSim provides limited support for parameters that have no default values or have their
default values specified in the form of functions or expressions. If the default value expression/
function can be evaluated to a constant value by the vlog command, that value will be used as
the default value of the generic in the VHDL component. Otherwise, if the parameter is defined
using Verilog-style declaration, ModelSim dumps it with a 'notype' datatype.

You can leave this type of parameter OPEN in entity instantiation, or omit it in component
instantiation. However, if you want to override such a parameter, you can do so by applying
your own data type and value (component declaration), or by using an unambiguous actual
value (direct entity instantiation). If a parameter with no default value or compile-time
non-constant default value is defined using SystemVerilog-style declarations, the corresponding
generic on the VHDL side will have a data type, but no default value. You can also leave such
generics OPEN in entity instantiations, or omit them in component instantiations. But if you
want to override them from VHDL, you can do so in a way similar to the Verilog-Style
Declarations described above—except that the data type of the overriding VHDL actual must be
allowed for mapping with the Verilog formal (refer to Table 9-10 for a list of allowed
mappings).

Verilog or SystemVerilog and SystemC Signal

Interaction And Mappings
SystemC design units are interconnected by using hierarchical and primitive channels. An
sc_signal<> is one type of primitive channel.

Channel and Port Type Mapping

The Channel and Port Type Mapping table lists all channels. Three types of primitive channels
and one hierarchical channel are supported on the language boundary (SystemC modules
connected to Verilog modules).

ModelSim® SE User's Manual, v10.7 487

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-11. Channel and Port Type Mapping

Channels Ports Verilog mapping
sc_signal<T> sc_in<T> Depends on type T. See
sc_out<T>sc_inout<T> table entitled Data Type
Mapping from SystemC to
Verilog or SystemVerilog.
sc_signal_rv<W> sc_in_rv<W> wire [W-1:0]
sc_out_rv<W>
sc_inout_rv<W>
sc_signal_resolved sc_in_resolved wire [W-1:0]
sc_out_resolved
sc_inout_resolved
sc_clock sc_in_clk wire
sc_out_clk
sc_inout_clk
sc_mutex N/A Not supported on language
boundary
sc_fifo sc_fifo_in Not supported on language
sc_fifo_out boundary

sc_semaphore N/A Not supported on language

boundary
sc_buffer N/A Not supported on language
boundary
user-defined user-defined Not supported on language
boundary1
1. User-defined SystemC channels and ports derived from built-in SystemC primitive channels
and ports can be connected to HDL signals. The built-in SystemC primitive channel or port must
be already supported at the mixed-language boundary for the derived class connection to work.

A SystemC sc_out port connected to an HDL signal higher up in the design hierarchy is treated
as a pure output port. A read() operation on such an sc_out port might give incorrect values. Use
an sc_inout port to do both read() and write() operations.

Data Type Mapping from SystemC to Verilog or SystemVerilog

SystemC instantiations of VHDL, Verilog, or SystemVerilog may associate SystemC elements
with VHDL ports and generics as well as Verilog nets and values.

Table 9-12 shows the correspondence of SystemC data types to SystemVerilog data types.

488 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-12. Data Type Mapping – SystemC to Verilog or SystemVerilog

SystemC Type SystemVerilog Primary SystemVerilog Secondary
Mapping Mapping
enum1 enum -
bool bit logic
wire
char byte bit [7:0]
logic [7:0]
wire [7:0]
unsigned char byte unsigned bit [7:0]
logic [7:0]
wire [7:0]
short shortint bit [15:0]
logic [15:0]
wire [15:0]
unsigned short shortint unsigned bit [15:0]
logic [15:0]
wire [15:0]
int int integer
bit [31:0]
logic [31:0]
wire [31:0]
unsigned int int unsigned integer unsigned
bit [31:0]
logic [31:0]
wire [31:0]
long longint (for 64 bit) bit [W-1:0]
int (for 32 bit) logic [W-1:0]
wire [W-1:0], where
W=64 on 64-bit
W=32 on 32-bit

ModelSim® SE User's Manual, v10.7 489

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-12. Data Type Mapping – SystemC to Verilog or SystemVerilog (cont.)

SystemC Type SystemVerilog Primary SystemVerilog Secondary
Mapping Mapping
unsigned long longint unsigned (64-bit) bit [W-1:0]
int unsigned (32-bit) logic [W-1:0]
wire [W-1:0], where
W=64 on 64-bit
W=32 on 32-bit
long long longint bit [63:0]
logic [63:0]
wire [63:0]
unsigned long long longint unsigned bit [63:0]
logic [63:0]
wire [63:0]
sc_bit bit logic
wire
sc_logic logic bit
wire
sc_bv bit [W-1:0] logic [W-1:0]
wire [W-1:0]
sc_lv logic [W-1:0] bit [W-1:0]
wire [W-1:0]
float shortreal N/A
double real N/A
struct2,3 struct struct packed

union2 packed union N/A

sc_int<W> / sc_signed2 shortint (ifW=16) logic [W-1:0]

int (if W=32) wire [W-1:0]
longint (if W=64)
bit [W-1:0] (otherwise)

490 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-12. Data Type Mapping – SystemC to Verilog or SystemVerilog (cont.)

SystemC Type SystemVerilog Primary SystemVerilog Secondary
Mapping Mapping
sc_uint<W> / sc_unsigned shortint unsigned (ifW=16) logic [W-1:0]
int unsigned (if W=32) wire [W-1:0]
longint unsigned (if W=64)
bit [W-1:0] (otherwise)
sc_bigint<W> bit [W-1:0] logic [W-1:0]
wire [W-1:0]
sc_biguint<W> bit [W-1:0] logic [W-1:0]
wire [W-1:0]
sc_fixed<W,I,Q,O,N> bit [W-1:0] logic [W-1:0]
sc_ufixed<W,I,Q,O,N> wire [W-1:0]
sc_fixed_fast<W,I,Q,O,N> bit [W-1:0] logic [W-1:0]
sc_ufixed_fast<W,I,Q,O,N> wire [W-1:0]
sc_fix bit [WL-1:0]4 logic [W-1:0]
sc_ufix wire [W-1:0]
sc_fix_fast bit [WL-1:0] logic [W-1:0]
sc_ufix_fast wire [W-1:0]
signal arrays5 unpacked array6
1. Refer to enum, struct, and union at SystemC-SystemVerilog Mixed-Language Boundary for more
information on these complex types.
2. To make a port of type sc_signed or sc_unsigned of word length other than the default (32), you must use
sc_length_param and sc_length_context to set the word length. For more information, see Construction
Parameters for SystemC Types in 2.2.
3. Supports real and shortreal as field types.
4. WL (word length) is the total number of bits used in the type. It is specified during runtime. To make a port
of type sc_fix, sc_ufix, sc_fix_fast, or sc_ufix_fast of word length other than the default(32), you must use
sc_fxtype_params and sc_fxtype_context to set the word length. For more information, see Construction
Parameters for SystemC Types in 2.2.
5. SystemC signal arrays are supported only for cases where Verilog or SystemVerilog instantiates a SystemC
module - not vice versa.
6. The number of elements in the SystemC signal array and the SV unpacked array must match; and the type
of SystemC signal array must be compatible with the type of the element of the SV unpacked array.

Data Type Mapping from Verilog or SystemVerilog to SystemC

Table 9-13 shows the correspondence of Verilog or SystemVerilog data types to SystemC data
types.

ModelSim® SE User's Manual, v10.7 491

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-13. Data Type Mapping – Verilog or SystemVerilog to SystemC

Verilog/ SystemC Primary SystemC Secondary
SystemVerilog Type Mapping Mapping
bit bool sc_bit
sc_logic
logic sc_logic sc_bit
bool
reg sc_logic sc_bit
bool
bit vector sc_bv<W> sc_lv<W>
sc_int<W>
sc_uint<W>
logic vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>
reg vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>
wire vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>
wire sc_logic sc_bit
bool
integer sc_lv<32> int
sc_int<32>
integer unsigned sc_lv<32> unsigned int
sc_uint<32>
sc_bv<32>
int int sc_lv<32>
sc_int<32>
sc_bv<32>
shortint short sc_lv<16>
sc_int<16>
sc_bv<16>

492 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-13. Data Type Mapping – Verilog or SystemVerilog to SystemC (cont.)

Verilog/ SystemC Primary SystemC Secondary
SystemVerilog Type Mapping Mapping
longint long long sc_lv<64>
sc_int<64>
sc_bv<64>
long (for 64-bit)
longint unsigned unsigned long long sc_lv<64> sc_uint<64>
sc_bv<64>
unsigned long (for 64-bit)
byte char sc_lv<8>
sc_int<8>
sc_bv<8>
byte unsigned unsigned char sc_lv<8> sc_uint<8>
sc_bv<8>
enum1 enum -
struct1 struct -
packed struct struct
packed union1, 2 union -
real2 double -
shortreal2 float -
multi-D array 2, 3 multi-D array -

1. Refer to enum, struct, and union at SystemC-SystemVerilog Mixed-Language Boundary for more
information on these complex types.
2. Unpacked and tagged unions are not supported at the SystemC-SystemVerilog mixed language
boundary.
3. Classes, multi-dimensional arrays, unpacked/tagged unions, strings and handles are not supported for
SystemC control/observe.

Type Checking—Signal Arrays

SystemC signal arrays can be connected to Verilog/SystemVerilog arrays only if the following
conditions hold true:

• The number of elements in the SystemC signal array and the Verilog/SystemVerilog
array is the same.

ModelSim® SE User's Manual, v10.7 493

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

• Mapping between the type of SystemC signal array and the type of the element of the
Verilog/SystemVerilog array is permitted at the SystemC-Verilog/SystemVerilog
boundary.

Note
SystemC signal arrays are supported only for cases where Verilog/SystemVerilog
instantiates a SystemC module—not vice versa.

enum, struct, and union at SystemC-SystemVerilog Mixed-Language

Boundary
The following guidelines apply to the use of enumerations, structures and unions at the
SystemC-SystemVerilog mixed-language boundary.

Enumerations
A SystemVerilog enum may be used at the SystemC-SystemVerilog language boundary if it
meets the following criteria:

• Base type of the SystemVerilog enum must be int (32-bit 2-state integer).
• The value of enum elements are not ambiguous and are equal to the value of the
corresponding value of enum elements on the SystemC side. Enums with different
strings are allowed at the language boundary as long as the values on both sides are
identical.
• SystemVerilog enums with 'range of enumeration elements' are allowed provided the
corresponding enum is correctly defined (manually) on the SystemC side.

Unions and Structures

You can use a SystemVerilog union or structure at a SystemC-SystemVerilog boundary if it
meets the following criteria:

• The type of all elements of the union/structure is one of the supported types.
• The type of the corresponding elements of the SystemC union/structure follow the
supported type mapping for variable ports on the SystemC-SystemVerilog language
boundary. See Channel and Port Type Mapping for mapping information.
• The number and order of elements in the definition of structures on SystemVerilog and
SystemC side is the same. For unions, the order of elements may be different, but the
number of elements must be the same.
• Union must be packed and untagged. While both packed and unpacked structures are
supported, only packed unions are supported at the SystemC-SystemVerilog language
boundary.

494 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Port Direction
Verilog port directions are mapped to SystemC as shown in Table 9-14. Note that you can use
the wildcard syntax convention (.*) when instantiating Verilog ports where the instance port
name matches the connecting port name and their data types are equivalent.
Table 9-14. Mapping Verilog Port Directions to SystemC
Verilog SystemC
input sc_in<T> sc_in_resolved
sc_in_rv<W>
output sc_out<T>
sc_out_resolved
sc_out_rv<W>
inout sc_inout<T>
sc_inout_resolved
sc_inout_rv<W>

Verilog to SystemC State Mappings

Verilog states are mapped to sc_logic, sc_bit, and bool as shown in Table 9-15.
Table 9-15. Mapping Verilog States to SystemC States
Verilog sc_logic sc_bit bool
HiZ 'Z' '0' false
Sm0 '0' '0' false
Sm1 '1' '1' true
SmX 'X' '0' false
Me0 '0' '0' false
Me1 '1' '1' true
MeX 'X' '0' false
We0 '0' '0' false
We1 '1' '1' true
WeX 'X' '0' false
La0 '0' '0' false
La1 '1' '1' true
LaX 'X' '0' false
Pu0 '0' '0' false
Pu1 '1' '1' true

ModelSim® SE User's Manual, v10.7 495

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings

Table 9-15. Mapping Verilog States to SystemC States (cont.)

Verilog sc_logic sc_bit bool
PuX 'X' '0' false
St0 '0' '0' false
St1 '1' '1' true
StX 'X' '0' false
Su0 '0' '0' false
Su1 '1' '1' true
SuX 'X' '0' false
For Verilog states with ambiguous strength:

• sc_bit receives '1' if the value component is 1, else it receives ’0’

• bool receives true if the value component is 1, else it receives false
• sc_logic receives 'X' if the value component is X, H, or L
• sc_logic receives '0' if the value component is 0
• sc_logic receives ’1’ if the value component is 1

SystemC to Verilog State Mappings

SystemC type bool is mapped to Verilog states as shown in Table 9-16:
Table 9-16. Mapping SystemC bool to Verilog States
bool Verilog
false St0
true St1

SystemC type sc_bit is mapped to Verilog states as shown in Table 9-17:

Table 9-17. Mapping SystemC sc_bit to Verilog States
sc_bit Verilog
'0' St0
'1' St1

SystemC type sc_logic is mapped to Verilog states as shown in Table 9-18:

Table 9-18. Mapping SystemC sc_logic to Verilog States
sc_logic Verilog
'0' St0

496 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-18. Mapping SystemC sc_logic to Verilog States (cont.)

sc_logic Verilog
'1' St1
'Z' HiZ
'X' StX

VHDL and SystemC Signal Interaction and Mapping

SystemC has a more complex signal-level interconnect scheme than VHDL. Design units are
interconnected with hierarchical and primitive channels. An sc_signal<> is one type of
primitive channel. The following section discusses how various SystemC channel types map to
VHDL types when connected to each other across the language boundary.

Port Type Mapping

Table 9-19 lists port type mappings for all channels. Three types of primitive channels and one
hierarchical channel are supported on the language boundary (SystemC modules connected to
VHDL modules).
Table 9-19. SystemC Port Type Mapping
Channels Ports VHDL mapping
sc_signal<T> sc_in<T> Depends on type T. See
sc_out<T> table entitled Data Type
Mapping Between SystemC
sc_inout<T> and VHDL.
sc_signal_rv<W> sc_in_rv<W> std_logic_vector(W-1
sc_out_rv<W> downto 0)
sc_inout_rv<W>
sc_signal_resolved sc_in_resolved std_logic
sc_out_resolved
sc_inout_resolved
sc_clock sc_in_clk bit/std_logic/boolean
sc_out_clk
sc_inout_clk
sc_mutex N/A Not supported on language
boundary
sc_fifo sc_fifo_in Not supported on language
sc_fifo_out boundary

ModelSim® SE User's Manual, v10.7 497

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-19. SystemC Port Type Mapping (cont.)

Channels Ports VHDL mapping
sc_semaphore N/A Not supported on language
boundary
sc_buffer N/A Not supported on language
boundary
user-defined user-defined Not supported on language
boundary1
1. User defined SystemC channels and ports derived from built-in SystemC primitive channels and
ports can be connected to HDL signals. The built-in SystemC primitive channel or port must be
already supported at the mixed-language boundary for the derived class connection to work.

A SystemC sc_out port connected to an HDL signal higher up in the design hierarchy is treated
as a pure output port. A read() operation on such an sc_out port might give incorrect values. Use
an sc_inout port to do both read() and write() operations.

Data Type Mapping Between SystemC and VHDL

Table 9-20 lists the mapping between SystemC sc_signal types and VHDL types.
Table 9-20. Mapping Between SystemC sc_signal and VHDL Types
SystemC VHDL
bool, sc_bit bit/std_logic/boolean
sc_logic std_logic
sc_bv<W> bit_vector(W-1 downto 0)
sc_lv<W> std_logic_vector(W-1 downto 0)
sc_bv<32>, integer
sc_lv<32>
sc_bv<64>, real
sc_lv<64>
sc_int<W>, bit_vector(W-1 downto 0)
sc_uint<W> std_logic_vector(W -1 downto 0)
sc_bigint<W>, sc_biguint<W> bit_vector(W-1 downto 0)
std_logic_vector(W-1 downto 0)
sc_fixed<W,I,Q,O,N>, bit_vector(W-1 downto 0)
sc_ufixed<W,I,Q,O,N> std_logic_vector(W-1 downto 0)
sc_fixed_fast<W,I,Q,O,N>, bit_vector(W-1 downto 0)
sc_ufixed_fast<W,I,Q,O,N> std_logic_vector(W-1 downto 0)

498 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-20. Mapping Between SystemC sc_signal and VHDL Types (cont.)
SystemC VHDL
1sc_fix, bit_vector(WL-1 downto 0)
1sc_ufix std_logic_vector(WL- 1 downto 0)
1sc_fix_fast, bit_vector(WL-1 downto 0)
1sc_ufix_fast std_logic_vector(WL- 1 downto 0)
2sc_signed, bit_vector(WL-1 downto 0)
2sc_unsigned std_logic_vector(WL- 1 downto 0)
char, unsigned char bit_vector(7 downto 0)
std_logic_vector(7 downto 0)
short, unsigned short bit_vector(15 downto 0)
std_logic_vector(15 downto 0)
int, unsigned int bit_vector(31 downto 0)
std_logic_vector(7 downto 0)
long, unsigned long bit_vector(31 downto 0)
std_logic_vector(31 downto 0)
long long, unsigned long long bit_vector(63 downto 0)
std_logic_vector(63 downto 0)
float bit_vector(31 downto 0)
std_logic_vector(31 downto 0)
double bit_vector(63 downto 0)
std_logic_vector(63 downto 0)
real
struct record
enum enum
record3 record
element_declaration
{element_declaration}
end record
[ record_type_simple_name ]
signal array4 type signal_name
array (constraint_definition) of
signal_type

ModelSim® SE User's Manual, v10.7 499

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-20. Mapping Between SystemC sc_signal and VHDL Types (cont.)
SystemC VHDL
Not supported on language boundary Multi-dimensional array
(no equivalent SystemC type)
pointer Not supported on language boundary
(no equivalent VHDL type)
class Not supported on language boundary
(no equivalent VHDL type)
union Not supported on language boundary
(no equivalent VHDL type)
bit_fields Not supported on language boundary
(no equivalent VHDL type)
Not supported on language boundary access
(no equivalent SystemC type)
Not supported on language boundary protected
(no equivalent SystemC type)
1. WL (word length) is the total number of bits used in the type. It is specified during
runtime. To make a port of type sc_fix, sc_ufix, sc_fix_fast, or sc_ufix_fast of word
length other than the default(32), you must use sc_fxtype_params and sc_fxtype_context
to set the word length. For more information, see Construction Parameters for SystemC
Types in 2.2.
2. To make a port of type sc_signed or sc_unsigned of word length other than the default
(32), you must use sc_length_param and sc_length_context to set the word length. For
more information, see Construction Parameters for SystemC Types in 2.2.
3. Including nested records.
4. SystemC signal arrays are supported only for cases where VHDL instantiates a
SystemC module—not vice versa.

Type Checking—Records
Two records at the SystemC-VHDL mixed-language boundary will be equivalent if all of the
following conditions hold true:

• The number and order of elements in the definition of records on VHDL and SystemC
side is the same.
• Size of each field of one record is exactly same as the size of the corresponding field in
the second record.
• Type of each field of both the records is supported at the SystemC-VHDL boundary.
• Mapping between corresponding field types is permitted at the SystemC-VHDL
boundary.

500 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Type Checking—Enums
Two enumerated types at the SystemC-VHDL mixed-language boundary will be equivalent if
all of the following conditions hold true for them:

• The number of elements of both enums is the same.

• The element values of both enums is the same. SystemC allows enums to have
noncontinuous enum values, but VHDL allows only consecutive enum values (starting
from 0) for enums. As such, this check limits the element values of SystemC enums to
be consecutive integers starting from 0.
• A warning message will occur if the enum labels (enum strings) for both the enums at
the SystemC-VHDL boundary are different but their values are the same.

Type Checking—Signal Arrays

SystemC signal arrays can be connected to VHDL arrays only if the following conditions hold
true:

• The number of elements in the SystemC signal array and the VHDL array is the same.
• Mapping between the type of SystemC signal array and the type of the element of the
VHDL array is permitted at the SystemC-VHDL boundary.

Note
SystemC signal arrays are supported only for cases where VHDL instantiates a
SystemC module—not vice versa.

Port Direction Mapping

VHDL port directions are mapped to SystemC as shown in Table 9-21:
Table 9-21. Mapping VHDL Port Directions to SystemC
VHDL SystemC
in sc_in<T>,
sc_in_resolved,
sc_in_rv<W>
out sc_out<T>,
sc_out_resolved,
sc_out_rv<W>
inout sc_inout<T>,
sc_inout_resolved,
sc_inout_rv<W>

ModelSim® SE User's Manual, v10.7 501

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-21. Mapping VHDL Port Directions to SystemC (cont.)

VHDL SystemC
buffer sc_out<T>,
sc_out_resolved,
sc_out_rv<W>

Note
VHDL constants are supported for port connections at a VHDL-SystemC boundary.

VHDL to SystemC State Mapping

VHDL states are mapped to sc_logic, sc_bit, and bool as shown in Table 9-22:
Table 9-22. Mapping VHDL std_logic States to SystemC States
std_logic sc_logic sc_bit bool
'U' 'X' '0' false
'X' 'X' '0' false
'0' '0' '0' false
'1' '1' '1' true
'Z' 'Z' '0' false
'W' 'X' '0' false
'L' '0' '0' false
'H' '1' '1' true
'-' 'X' '0' false

SystemC to VHDL State Mapping

SystemC type bool is mapped to VHDL boolean as shown in Table 9-23:
Table 9-23. Mapping SystemC bool to VHDL Boolean States
bool VHDL
false false
true true

SystemC type sc_bit is mapped to VHDL bit as shown in Table 9-24:

Table 9-24. Mapping SystemC sc_bit to VHDL bit
sc_bit VHDL
'0' '0'

502 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL and SystemC Signal Interaction and Mapping

Table 9-24. Mapping SystemC sc_bit to VHDL bit (cont.)

sc_bit VHDL
'1' '1'
SystemC type sc_logic is mapped to VHDL std_logic states as shown in Table 9-25:
Table 9-25. Mapping SystemC sc_logic to VHDL std_logic
sc_logic std_logic
'0' '0'
'1' '1'
'Z' 'Z'
'X' 'X'

ModelSim® SE User's Manual, v10.7 503

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
VHDL Instantiating Verilog or SystemVerilog

VHDL Instantiating Verilog or SystemVerilog

Once you have generated a component declaration for a Verilog module, you can instantiate the
component just like any other VHDL component. You can reference a Verilog module in the
entity aspect of a component configuration—all you need to do is specify a module name
instead of an entity name. You can also specify an optional secondary name for an optimized
sub-module.
Further, you can reference a Verilog configuration in the configuration aspect of a VHDL
component configuration—just specify a Verilog configuration name instead of a VHDL
configuration name.

Verilog/SystemVerilog Instantiation Criteria Within VHDL . . . . . . . . . . . . . . . . . . . . . 504

Component Declaration for VHDL Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . 504
vgencomp Component Declaration when VHDL Instantiates Verilog. . . . . . . . . . . . . . 505
Modules with Bidirectional Pass Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Modules with Unnamed Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Verilog/SystemVerilog Instantiation Criteria Within

VHDL
A Verilog design unit may be instantiated within VHDL if it meets the following criteria:
• The design unit is a module or configuration. UDPs are not allowed.
• The ports are named ports of type: reg, logic, bit, one-dimensional arrays of reg/logic/
bit, integer, int, shortint, longint, byte, integer unsigned, int unsigned, shortint unsigned,
longint unsigned, byte unsigned, enum, and struct. (See also, Modules with Unnamed
Ports).

Component Declaration for VHDL Instantiating

Verilog
A Verilog module that is compiled into a library can be referenced from a VHDL design as
though the module is a VHDL entity. Likewise, a Verilog configuration can be referenced as
though it were a VHDL configuration.
You can extract the interface to the module from the library in the form of a component
declaration by running vgencomp. Given a library and module name, the vgencomp command
writes a component declaration to standard output.

The default component port types are:

• std_logic

504 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
vgencomp Component Declaration when VHDL Instantiates Verilog

• std_logic_vector
Optionally, you can choose one of the following:

• bit and bit_vector

• vl_logic and vl_logic_vector

VHDL and Verilog Identifiers

The VHDL identifiers for the component name, port names, and generic names are the same as
Verilog and SystemVerilog identifiers for the module name, port names, and parameter names.
Except for the cases noted below, ModelSim does nothing to the Verilog identifier when it
generates the entity.

ModelSim converts Verilog identifiers to VHDL 1076-1993 extended identifiers in three cases:

• The Verilog identifier is not a valid VHDL 1076-1987 identifier.

• You compile the Verilog module with the -93 argument. One exception is a valid,
lowercase identifier (for instance, topmod). Valid, lowercase identifiers will not be
converted even if you compile with -93.
• The Verilog identifier is not unique when case is ignored. For example, if you have
TopMod and topmod in the same module, ModelSim will convert the former to
\TopMod\.

vgencomp Component Declaration when VHDL

Instantiates Verilog
The vgencomp command generates a component declaration according to the following rules.
• Generic Clause
The vgencomp command generates a generic clause if the module has parameters. A
corresponding generic is defined for each parameter that has an initial value that does
not depend on any other parameters.
The generic type is determined by the parameter's initial value as follows:

Parameter value Generic type

integer integer
real real
string literal string

ModelSim® SE User's Manual, v10.7 505

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Modules with Bidirectional Pass Switches

The default value of the generic is the same as the parameter's initial value. For example:
Verilog parameter VHDL generic
parameter p1 = 1 - 3; p1 : integer := -2;
parameter p2 = 3.0; p2 : real := 3.000000;
parameter p3 = "Hello"; p3 : string := "Hello";

• Port Clause
The vgencomp command generates a port clause if the module has ports. A
corresponding VHDL port is defined for each named Verilog port.
You can set the VHDL port type to bit, std_logic, or vl_logic. If the Verilog port has a
range, then the VHDL port type is bit_vector, std_logic_vector, or vl_logic_vector. If
the range does not depend on parameters, then the vector type will be constrained
accordingly, otherwise it will be unconstrained. For example:

Verilog port VHDL port

input p1; p1 : in std_logic;
output [7:0] p2; p2 : out std_logic_vector(7 downto 0);
output [4:7] p3; p3 : out std_logic_vector(4 to 7);
inout [W-1:0] p4; p4 : inout std_logic_vector;

Configuration declarations are allowed to reference Verilog modules in the entity aspects of
component configurations. However, the configuration declaration cannot extend into a Verilog
instance to configure the instantiations within the Verilog module.

Modules with Bidirectional Pass Switches

Modules that have bidirectional pass switches (tran primitives) internally connected to their
ports are not fully supported when the module is instantiated by VHDL. This is due to
limitations imposed by the requirements of VHDL signal resolution.
However, full bidirectional operation is supported if the following requirements are met:

• The Verilog port is declared with mode inout.

• The connected VHDL signal is of type or subtype std_logic.
• The connected port hierarchy above the VHDL signal does not cross any other mixed
language boundaries, and the top-level signal is also of type or subtype std_logic.

506 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Modules with Unnamed Ports

In all other cases, the following warning is issued at elaboration and the simulation of the
Verilog port may produce incorrect results if the design actually drives in both directions across
the port:

** Warning: (vsim-3011) testfile(4): [TRAN] - Verilog net 'n' with bidirectional tran primitives
might not function correctly when connected to a VHDL signal.

If you use the port solely in a unidirectional manner, then you should explicitly declare it as
either input or output (whichever matches the direction of the signal flow).

Modules with Unnamed Ports

Verilog allows modules to have unnamed ports, whereas VHDL requires that all ports have
names. If any of the Verilog ports are unnamed, then all are considered to be unnamed, and it is
not possible to create a matching VHDL component. In such cases, the module may not be
instantiated from VHDL.
Unnamed ports occur when the module port list contains bit-selects, part-selects, or
concatenations, as in the following example:

module m(a[3:0], b[1], b[0], {c,d});

input [3:0] a;
input [1:0] b;
input c, d;
endmodule

Note that a[3:0] is considered to be unnamed even though it is a full part-select. A common
mistake is to include the vector bounds in the port list, which has the undesired side effect of
making the ports unnamed (which prevents you from connecting by name even in an all-Verilog
design).

Most modules having unnamed ports can be easily rewritten to explicitly name the ports, thus
allowing the module to be instantiated from VHDL. Consider the following example:

module m(y[1], y[0], a[1], a[0]);

output [1:0] y;
input [1:0] a;
endmodule

Here is the same module rewritten with explicit port names added:

module m(.y1(y[1]), .y0(y[0]), .a1(a[1]), .a0(a[0]));

output [1:0] y;
input [1:0] a;
endmodule

ModelSim® SE User's Manual, v10.7 507

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Modules with Unnamed Ports

Empty Ports
Verilog modules may have “empty” ports, which are also unnamed, but they are treated
differently from other unnamed ports. If the only unnamed ports are empty, then the other ports
may still be connected to by name, as in the following example:

module m(a, , b);

input a, b;
endmodule

Although this module has an empty port between ports a and b, the named ports in the module
can still be connected to or from VHDL.

508 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Verilog or SystemVerilog Instantiating VHDL

Verilog or SystemVerilog Instantiating VHDL

You can reference a VHDL entity or configuration from Verilog or SystemVerilog as though
the design unit is a module or a configuration of the same name.
VHDL Instantiation Criteria Within Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Entity and Architecture Names and Escaped Identifiers. . . . . . . . . . . . . . . . . . . . . . . . . 510
Named Port Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Generic Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

VHDL Instantiation Criteria Within Verilog

You can instantiate a VHDL design unit within Verilog or SystemVerilog if it meets the
following criteria:
• The design unit is an entity/architecture pair or a configuration.
• The entity ports are of type: bit, bit_vector, enum, integer, natural, positive, real,
shortreal, std_logic, std_ulogic, std_logic_vector, std_ulogic_vector, vl_ulogic,
vl_ulogic_vector, or their subtypes; unconstrained arrays; nested records; and records
with fields of type integer, real, enum, and multi-dimensional arrays.
The port clause may have any mix of these types. Multi-dimensional arrays of these
support types are also supported.
• The generics are of type bit, bit_vector, integer, real, std_logic, std_logic_vector,
vl_logic, vl_logic_vector, time, physical, enumeration, or string.

Usage Notes
Passing a parameter values from Verilog or SystemVerilog to a VHDL generic of type std_logic
is slightly different than other VHDL types. Note that std_logic is defined as a 9-state
enumerated type, as follows:

TYPE std_ulogic IS (
‘U’, -- Uninitialized
‘X’, -- Forcing Unknown
‘0’, -- Forcing 0
‘1’, -- Forcing 1
‘Z’, -- High Impedance
‘W’, -- Weak Unknown
‘L’, -- Weak 0
‘H’, -- Weak 1
‘-’ -- Don’t care
);

ModelSim® SE User's Manual, v10.7 509

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Entity and Architecture Names and Escaped Identifiers

To be able to correctly set the VHDL generic to any of the nine states, you must set the value in
the Verilog instance to the element (positional) value in the std_logic enum that corresponds to
the std_logic value (that is, the position not the value itself). For example, to set the generic to a
‘U’, use 1’b0, to set it to an “X”, use 1’b1, to set it to ‘0’, use 2’b10.

Note that this only applies to std_logic types—for std_logic_vector you can simply pass the
value as you would normally expect.

For example, the following VHDL entity shows the generics of type std_logic:

entity ent is
generic (
a : std_logic;
b : std_logic ;
c : std_logic
) ;

with the following Verilog instantiation:

module test ;
// here we will pass 0 to a, 1 to b and z to c
ent #(2’b10, 2’b11, 3’b100) u_ent ())
endmodule

Note that this does not pass the value but the positional number corresponding to the element
value in the std_logic enum.

Alternatively, you can use std_logic_vector for the generics, and you can simply pass the value
as normal.

Entity and Architecture Names and Escaped

Identifiers
An entity name is not case-sensitive in Verilog instantiations. The entity default architecture is
selected from the work library unless specified otherwise. Since instantiation bindings are not
determined at compile time in Verilog, you must instruct the simulator to search your libraries
when loading the design.
Alternatively, you can employ the escaped identifier to provide an extended form of
instantiation:

\mylib.entity(arch) u1 (a, b, c) ;
\mylib.entity u1 (a, b, c) ;
\entity(arch) u1 (a, b, c) ;

If the escaped identifier takes the form of one of the above and is not the name of a design unit
in the work library, then the instantiation is broken down as follows:

• library = mylib

510 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Named Port Associations

• design unit = entity

• architecture = arch
Related Topics
Library Usage

Named Port Associations

Port associations may be named or positional. Use the same port names and port positions that
appear in the entity.
Named port associations are not case sensitive unless a VHDL port name is an extended
identifier (1076-1993). If the VHDL port name is an extended identifier, the association is case-
sensitive, and the leading and trailing backslashes of the VHDL identifier are removed before
comparison.

Generic Associations
Generic associations are provided via the module instance parameter value list. List the values
in the same order that the generics appear in the entity. Parameter assignment to generics is not
case sensitive.
The defparam statement is not allowed for setting generic values.

SDF Annotation
A mixed VHDL/Verilog design can also be annotated with SDF.
Related Topics
SDF for Mixed VHDL and Verilog Designs

ModelSim® SE User's Manual, v10.7 511

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Sharing User-Defined Types

Sharing User-Defined Types

You can use shared VHDL packages for both VHDL and Verilog/SystemVerilog. Each usage
takes a different VHDL construct.
Using a Common VHDL Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Using a Common SystemVerilog Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Using a Common VHDL Package

With the “import” construct of SystemVerilog, you can implement user-defined types (records,
enums, aliases, subtypes, types, and multi-dimensional arrays) and constants from VHDL in a
SystemVerilog design. (Any other user-defined types are not supported.)
For example:

import vh_pack::vh_type

Because VHDL is case-insensitive, design units, variables and constants will be converted to
lower-case.

If you use mixed-case identifiers with its original case in your SystemVerilog code, design
compilation will fail because SystemVerilog is case sensitive. For example, if your VHDL
package contains an identifier named myPacketData the compiler will convert it to
mypacketdata. Therefore, if you use myPacketData in your SystemVerilog code, compilation
would fail due to a case mismatch. Because of this, it is suggested that everything in the shared
package should be lower-case to avoid these mismatch issues.

In order to import a VHDL package into SystemVerilog, you must compile it using the
-mixedsvvh argument with the vcom command (refer to Usage Notes, below).

512 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Using a Common VHDL Package

Note
The following types must be defined in a common package if you want to use them at the
SystemVerilog-VHDL boundary:

• Records
• Enumerations
• One-dimensional array of bit, std_logic, std_ulogic, integer, natural, positive, real &
time
• Multi-dimensional arrays and array of arrays of all supported types
• Subtypes of all supported types
• Alias of records, enums and arrays only
• Types (static ranges only)

ModelSim supports VHDL constants of all types currently supported at the VHDL-
SystemVerilog mixed language boundary as shown in Table 9-5.

Deferred constants are not supported. Only static expressions are supported as constant values.

Table 9-26 shows the mapping of literals from VHDL to SystemVerilog.

Table 9-26. Mapping Literals from VHDL to SystemVerilog
VHDL SystemVerilog
‘0’ (Forcing 0) ‘0’
‘L’ (Weak 0) ‘0’
‘1’ (Forcing 1) ‘1’
‘H’ (Weak 1) ‘1’
‘U’ (Uninitialized) ‘X’
‘X’ (Forcing Unknown) ‘X’
‘W’ (Weak Unknown) ‘X’
‘-’ (Don’t care) ‘X’
‘Z’ (High Impedance) ‘Z’

Table 9-27 lists all supported types inside VHDL Records.

Table 9-27. Supported Types Inside VHDL Records
VHDL Type SystemVerilog Type
bit, boolean bit
std_logic logic

ModelSim® SE User's Manual, v10.7 513

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Using a Common VHDL Package

Table 9-27. Supported Types Inside VHDL Records (cont.)

VHDL Type SystemVerilog Type
std_ulogic logic
bit_vector bit vector
std_logic_vector, std_ulogic_vector, logic vector
signed, unsigned
integer, natural, positive int
real real
record structure
multi-D arrays, array of arrays multi-d arrays

Usage Notes
When using a common VHDL package at a SystemVerilog-VHDL boundary, compile the
VHDL package with the -mixedsvvh argument with the vcom command, as follows:

vcom -mixedsvvh [b | l | r] [i] <vhdl_package>

Example
Consider the following VHDL package that you want to use at a SystemVerilog-VHDL
boundary:

--/*----------pack.vhd---------------*/
package pack is
type st_pack is record
a: bit_vector (3 downto 0);
b: bit;
c: integer;
end record;
constant c : st_pack := (a=>"0110", b=>'0', c=>4);
end package;

You must compile this package with the -mixedsvvh argument for vcom:

vcom -mixedsvvh pack.vhd

Import this package into the SystemVerilog design, as if it were a SystemVerilog package.

514 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Using a Common SystemVerilog Package

--/*------VHDL_entity--------*/
use work.pack.all;
entity top is
end entity;
architecture arch of top is
component bot
port(in1 : in st_pack;
in2 : bit_vector(1 to c.c);
out1 : out st_pack);
end component;
begin
end arch;

/*------SV_file--------*/
import pack::*; // including the VHDL package in SV
module bot(input st_pack in1, input bit [1:c.c] in2, output st_pack out1);
endmodule

Using a Common SystemVerilog Package

With the “use” construct of VHDL, you can implement user-defined types (structures, enums,
and multi-dimensional arrays) from SystemVerilog in a VHDL design. (Any other user-defined
types are not supported.)
For example:

use work.sv_pack.sv_type

In order to include a SystemVerilog package in VHDL, you must compile it using the
-mixedsvvh argument of the vlog command (refer to Usage Notes, below).

Note
You must use the vcom -mixedsvvh option when compiling the common package, and the
following types must be defined in a common package if you want to use them at the
SystemVerilog-VHDL boundary:

• Strucures
• Enumerations with base type as 32-bit 2-state integer
• Multi-dimensional arrays of all supported types

Table 9-28 lists all supported types inside SystemVerilog structures.

Table 9-28. Supported Types Inside SystemVerilog Structure
SystemVerilog Type VHDL Type Comments
bit bit bit types
logic, reg std_logic multi-valued types

ModelSim® SE User's Manual, v10.7 515

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Using a Common SystemVerilog Package

Table 9-28. Supported Types Inside SystemVerilog Structure (cont.)

SystemVerilog Type VHDL Type Comments
enum enum SystemVerilog enums of only 2-state int
base type supported
struct record unpacked structure
packed struct record packed structure
real real 2-state data type, 64-bit real number
shortreal real 2-state data type, 32-bit real number
multi-D arrays multi-D arrays multi-dimensional arrays of supported types
byte, int, shortint, longint integer integer types

Usage Notes
When using a common SystemVerilog package at a SystemVerilog-VHDL boundary, you
should compile the SystemVerilog package with the -mixedsvvh argument of the vlog
command, as follows:

vlog -mixedsvvh [b | s | v] <sv_package>

When you compile a SystemVerilog package with -mixedsvvh, the package can be included in
a VHDL design as if it were defined in VHDL itself.

Note
If you do not specify b, s, or v with -mixedsvvh, the default treatment of data types is
applied.

Example
The following SystemVerilog package contains a type named st_pack, which you want to use at
the SystemVerilog-VHDL mixed-language boundary.

/*----------pack.sv---------------*/
package pack;
typedef struct {
bit [3:0] a;
bit b;
} st_pack;
endpackage

To use this package (and type) at a SystemVerilog-VHDL boundary, you must compile it using
vlog -mixedsvvh:

vlog -mixedsvvh pack.sv

516 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Using a Common SystemVerilog Package

You can now include this package (st_pack) in the VHDL design, as if it were a VHDL
package:

--/*------VHDL_file--------*/
use work.pack.all; -- including the SV package in VHDL

entity top is
end entity;

architecture arch of top is

component bot
port(
in1 : in st_pack; -- using type from the SV package.
out1 : out st_pack);
end component;

signal sin1, sout1 : st_pack;

begin
...
end arch;

/*------SV Module--------*/
import pack::*;

module bot(input st_pack in1, output st_pack out1);

...
endmodule

ModelSim® SE User's Manual, v10.7 517

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Instantiating Verilog or SystemVerilog

SystemC Instantiating Verilog or

SystemVerilog
To instantiate Verilog or SystemVerilog modules into a SystemC design, you must first create a
SystemC foreign module declaration for each Verilog/SystemVerilog module. Once you have
created the foreign module declaration, you can instantiate the foreign module just like any
other SystemC module.
Verilog Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
SystemC Foreign Module (Verilog) Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Parameter Support for SystemC Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Verilog Instantiation Criteria Within SystemC

A Verilog/SystemVerilog design unit may be instantiated within SystemC if it meets the
following criteria:
• The design unit is a module (UDPs and Verilog primitives are not allowed).
• The ports are named ports (Verilog allows unnamed ports).
• The Verilog/SystemVerilog module name must be a valid C++ identifier.
• The ports are not connected to bidirectional pass switches (it is not possible to handle
pass switches in SystemC).
A Verilog/SystemVerilog module that is compiled into a library can be instantiated in a
SystemC design as though the module were a SystemC module by passing the Verilog/
SystemVerilog module name to the foreign module constructor. For an illustration of this, see
Example 9-4.

SystemC and Verilog Identifiers

The SystemC identifiers for the module name and port names are the same as the Verilog
identifiers for the module name and port names. Verilog identifiers must be valid C++
identifiers. SystemC and Verilog are both case-sensitive. ModelSim does nothing to the
SystemC identifiers when it generates the module.

Verilog Configuration Support

You can use a Verilog configuration to configure a Verilog module instantiated in SystemC.
The Verilog configuration must be elaborated (with vsimor vopt) as a top-level design unit, or
be part of another top-level VHDL or Verilog configuration.

518 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Foreign Module (Verilog) Declaration

SystemC Foreign Module (Verilog) Declaration

In cases where you want to run a mixed simulation with SystemC and Verilog/SystemVerilog,
you must generate and declare a foreign module that stands in for each Verilog module
instantiated under SystemC.
You can create foreign modules in one of two ways:

• Run scgenmod, a utility that automatically generates your foreign module declaration
(much like vgencomp generates a component declaration).
• Modify your SystemC source code manually.
After you have analyzed the design, you can generate a foreign module declaration by using
scgenmod as follows:

scgenmod mod1

where mod1 can be any name of a Verilog module. A foreign module declaration for the
specified module is written to stdout.

Guidelines for Manual Creation of Foreign Module Declaration

Apply the following guidelines to the creation of foreign modules. A foreign module:

• Contains ports corresponding to Verilog ports. These ports must be explicitly named in
the constructor initializer list of the foreign module.
• Must not contain any internal design elements such as child instances, primitive
channels, or processes.
• Must pass a secondary constructor argument denoting the module’s HDL name to the
sc_foreign_module base class constructor. For Verilog, the HDL name is simply the
Verilog module name corresponding to the foreign module, or [<lib>].<module>.
• Allows inclusion of parameterized modules. Refer to Parameter Support for SystemC
Instantiating Verilog for details.
Example 9-4. SystemC Instantiating Verilog - 1

A sample Verilog module to be instantiated in a SystemC design is:

module vcounter (clock, topcount, count);

input clock;
input topcount;
output count;
reg count;
...
endmodule

ModelSim® SE User's Manual, v10.7 519

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

The SystemC foreign module declaration for the above Verilog module is:

class counter : public sc_foreign_module {

public:
sc_in<bool> clock;
sc_in<sc_logic> topcount;
sc_out<sc_logic> count;
counter(sc_module_name nm)
: sc_foreign_module(nm, "lib.vcounter"),
clock("clock"),
topcount("topcount"),
count("count")
{}
};

The Verilog module is then instantiated in the SystemC source as follows:

counter dut("dut");

where the constructor argument (dut) is the instance name of the Verilog module.

Example 9-5. SystemC Instantiating Verilog - 2

Another variation of the SystemC foreign module declaration for the same Verilog module
might be:

class counter : public sc_foreign_module {

public:
...

counter(sc_module_name nm, char* hdl_name)

: sc_foreign_module(nm, hdl_name),
clock("clock"),
...
{}
};

The instantiation of this module would be:

counter dut("dut", "lib.counter");

Parameter Support for SystemC Instantiating

Verilog
Because the SystemC language has no concept of parameters, parameterized values must be
passed from a SystemC parent to a Verilog child through the SystemC foreign module
(sc_foreign_module).

520 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

Refer to SystemC Foreign Module (Verilog) Declaration for information regarding the creation
of sc_foreign_module.

Passing Parameters to sc_foreign_module (Verilog)

To instantiate a Verilog module containing parameterized values into the SystemC design, you
can use one of two methods, depending on whether the parameter is an integer.

If the parameter is an integer, you have two choices:

• passing as a template argument to the foreign module

• passing as a constructor argument to the foreign module
Non-integer parameters must be passed to the foreign module using constructor arguments.

Passing Integer and Non-Integer Parameters as Constructor Arguments

Both integer and non-integer parameters can be passed by specifying two parameters to the
sc_foreign_module constructor: the number of parameters (int num_generics), and the
parameter list (const char* generic_list). The generic_list is listed as an array of const char*.

If you create your foreign module manually (see Guidelines for Manual Creation of Foreign
Module Declaration), you must also pass the parameter information to the sc_foreign_module
constructor. If you use scgenmod to create the foreign module declaration, the parameter
information is detected in the HDL child and is incorporated automatically.

Example 9-6. Sample Foreign Module Declaration, with Constructor Arguments

for Parameters

Following Example 9-4, the following parameter information would be passed to the SystemC
foreign module declaration:

class counter : public sc_foreign_module {

public:
sc_in<bool> clk;
...

counter(sc_module_name nm, char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module (nm),
{elaborate_foreign_module(hdl_name, num_generics, generic_list);}
};

Example 9-7. Passing Parameters as Constructor Arguments - 1

Verilog module:

module counter (clk, count)

ModelSim® SE User's Manual, v10.7 521

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

parameter integer_param = 4;
parameter real_param = 2.9;
parameter str_param = "ERROR";

output [7:0] count;

input clk;

...
endmodule

Foreign module (created by the command: scgenmod counter):

class counter : public sc_foreign_module

{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<8> > count;

counter(sc_module_name nm, const char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module(nm),
clk("clk"),
count("count")
{
elaborate_foreign_module(hdl_name, num_generics, generic_list);
}
~counter()
{}
};

Instantiation of the foreign module in SystemC:

SC_MODULE(top) {

counter* counter_inst_1; // Instantiate counter with counter_size = 20

SC_CTOR(top)
{
const char* generic_list[3];
generic_list[0] = strdup("integer_param=16");
generic_list[1] = strdup("real_param=2.6");
generic_list[2] = strdup("str_param=\"Hello\"");

//Pass all parameter overrides using foreign module constructor args

counter_inst_1 = new counter("c_inst", "work.counter", 3, \
generic_list);

// Cleanup the memory allocated for the generic list

for (int i = 0; i < 3; i++;)
free((char*)generic_list[i]);
}
};

522 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

Passing Integer Parameters as Template Arguments

Integer parameters can be passed as template arguments to a foreign module. Doing so enables
port sizes of Verilog modules to be configured using the integer template arguments. Use the
-createtemplate option to scgenmod to generate a class template foreign module.

Example 9-8. SystemC Instantiating Verilog, Passing Integer Parameters as

Template Arguments

Verilog module:

module counter (clk, count)

parameter counter_size = 4;

...

endmodule

Foreign module (created by the command: scgenmod -createtemplate counter):

template <int counter_size = 4>

class counter : public sc_foreign_module
{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<counter_size-1 + 1> > count;

counter(sc_module_name nm, const char* hdl_name)

: sc_foreign_module(nm),
clk("clk"),
count("count")
{
this->add_parameter("counter_size", counter_size);
elaborate_foreign_module(hdl_name);
}
~counter()
{}
};

Instantiation of the foreign module in SystemC:

SC_MODULE(top) {

counter<20> counter_inst_1;
// Instantiates counter with counter_size = 20
counter counter_inst_2;
// Instantiates counter with default counter_size = 4

SC_CTOR(top)
: counter_inst_1(cinst_1, "work.counter"),
counter_inst_2(cinst_2, "work.counter")
{}

ModelSim® SE User's Manual, v10.7 523

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

};

Example 9-9. Passing Integer Parameters as Template Arguments and Non-

integer Parameters as Constructor Arguments

Verilog module:

module counter (clk, count)

parameter counter_size = 4;
parameter real_param = 2.9;
parameter str_param = "ERROR";

output [counter_size - 1 : 0] count;

input clk;

...

endmodule

Foreign module (created by command: scgenmod -createtemplate counter):

class counter : public sc_foreign_module

{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<counter_size-1 + 1> > count;

counter(sc_module_name nm, const char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module(nm),
clk("clk"),
count("count")
{
this->add_parameter("counter_size", counter_size);
elaborate_foreign_module(hdl_name, num_generics, generic_list);
}
~counter()
{}
};

Instantiation of the foreign module in SystemC:

SC_MODULE(top) {

// Instantiate counter with counter_size = 20

counter<20>* counter_inst_1;

524 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Parameter Support for SystemC Instantiating Verilog

SC_CTOR(top)
{
const char* generic_list[2];
generic_list[0] = strdup("real_param=2.6");
generic_list[1] = strdup("str_param=\"Hello\"");

//
// The integer parameter override is already passed as template
// argument. Pass the overrides for the non-integer parameters
// using the foreign module constructor arguments.
//
counter_inst_1 = new counter<20>("c_inst", "work.counter", 2, \
generic_list);

// Cleanup the memory allocated for the generic list

for (int i = 0; i < 2; i++;)
free((char*)generic_list[i]);
}
};

ModelSim® SE User's Manual, v10.7 525

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Verilog or SystemVerilog Instantiating SystemC

Verilog or SystemVerilog Instantiating

SystemC
You can reference a SystemC module from Verilog/SystemVerilog as though the design unit is
a module of the same name.
SystemC Instantiation Criteria for Verilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Exporting SystemC Modules for Verilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Parameter Support for Verilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 526

SystemC Instantiation Criteria for Verilog

A SystemC module can be instantiated in Verilog/SystemVerilog if it meets the following
criteria:
• SystemC module names are case-sensitive. The module name at the SystemC
instantiation site must match exactly with the actual SystemC module name.
• SystemC modules are exported using the SC_MODULE_EXPORT macro. See
Exporting SystemC Modules for Verilog.
• The module ports are as listed in the table shown in Channel and Port Type Mapping.
• Port data type mapping must match exactly. See the table in Data Type Mapping from
SystemC to Verilog or SystemVerilog.
Port associations may be named or positional. Use the same port names and port positions that
appear in the SystemC module declaration. Named port associations are case sensitive.

Exporting SystemC Modules for Verilog

To be able to instantiate a SystemC module from Verilog/SystemVerilog (or use a SystemC
module as a top level module), the module must be exported.
Assume a SystemC module named transceiver exists, and that it is declared in the header file
transceiver.h. Then the module is exported by placing the following code in a .cpp file:

#include "transceiver.h"
SC_MODULE_EXPORT(transceiver);

Parameter Support for Verilog Instantiating

SystemC
You can pass and retrieve parameter values from a Verilog parent and a SystemC child using
Verilog override syntax.

526 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Parameter Support for Verilog Instantiating SystemC

Passing Parameters from Verilog to SystemC

To pass actual parameter values, you can use the native Verilog/SystemVerilog parameter
override syntax. Parameters are passed to SystemC using the module instance parameter value
list.

ModelSim supports passing parameters with a bit range, and types: int, real, and string.

Named parameter association must be used for all Verilog/SystemVerilog modules that
instantiate SystemC.

Retrieving Parameter Values

To retrieve parameter override information from Verilog/SystemVerilog, you can use the
following functions:

int sc_get_param(const char* param_name, int& param_value);

int sc_get_param(const char* param_name, double& param_value);
int sc_get_param(const char* param_name, sc_string& param_value, char
format_char = 'a');

The first argument to sc_get_param defines the parameter name, the second defines the
parameter value. For retrieving string values, ModelSim also provides a third optional
argument, format_char. It is used to specify the format for displaying the retrieved string. The
format can be ASCII (“a” or “A”), binary (“b” or “B”), decimal (“d” or “D”), octal (“o” or “O”),
or hexadecimal (“h” or “H”). Binary is the default. These functions return a 1 if successful,
otherwise they return a 0.

Alternatively, you can use the following forms of the above functions in the constructor
initializer list:

int sc_get_int_param(const char* param_name, int* is_successful);

double sc_get_real_param(const char* param_name, int* issuccessful);
sc_string sc_get_string_param(const char* param_name, char format_char =
'a', int* is_successful);

Example 9-10. Verilog/SystemVerilog Instantiating SystemC, Parameter

Information

The following ring buffer example includes all the files necessary for simulation.

ModelSim® SE User's Manual, v10.7 527

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Parameter Support for Verilog Instantiating SystemC

// test_ringbuf.v

`timescale 1ns / 1ps

module test_ringbuf();
reg clock;
...
parameter int_param = 4;
parameter real_param = 2.6;
parameter str_param = "Hello World";
parameter [7:0] reg_param = 'b001100xz;

// Instantiate SystemC module

ringbuf #(.int_param(int_param),
.real_param(real_param),
.str_param(str_param),
.reg_param(reg_param))
chip(.clock(clock),
...
... };
endmodule

-------------------------------------------------------------------------

// ringbuf.h
#ifndef INCLUDED_RINGBUF
#define INCLUDED_RINGBUF

#include <systemc.h>
#include "control.h"
...

SC_MODULE(ringbuf)
{
public:
// Module ports
sc_in clock;
...
...

SC_CTOR(ringbuf)
: clock("clock"),
...
...
{
int int_param = 0
if (sc_get_param(“int_param”, int_param))
cout << “int_param” << int_param << end1;

double real_param = 0.0;

int is_successful = 0;
real_param = sc_get_real_param(“real_param”, &is_successful);
if (is_successful)
cout << “real_param” << real_param << end1;

528 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Parameter Support for Verilog Instantiating SystemC

std::string str_param;
str_param = sc_get_string_param(“str_param”, ‘a’, &is_successful);
if (is_successful)
cout << “str_param=” << str_param.c_str() << end1;

str::string reg_param;
if (sc_get_param(“reg_param”, ‘b’))
cout << “reg_param=” << reg_param.c_str() << end1;

~ringbuf() {}
};

#endif

------------------------------------------------------------------------

// ringbuf.cpp
#include "ringbuf.h"

SC_MODULE_EXPORT(ringbuf);

To run the simulation, you enter the following commands:

vlib work
sccom ringbuf.cpp
vlog test_ringbuf.v
sccom -link
vsim test_ringbuf

The simulation will return the following:

# int_param=4
# real_param=2.6
# str_param=Hello World
# reg_param=001100xz

ModelSim® SE User's Manual, v10.7 529

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Instantiating VHDL

SystemC Instantiating VHDL

To instantiate VHDL design units into a SystemC design, you must first generate a SystemC
foreign module declaration for each VHDL design unit you want to instantiate.
Once you have generated the foreign module declaration, you can instantiate the foreign module
just like any other SystemC module.

SystemC Foreign Module (VHDL) Declaration

VHDL Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
SystemC Foreign Module (VHDL) Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Generic Support for SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

VHDL Instantiation Criteria Within SystemC

A VHDL design unit may be instantiated from SystemC if it meets the proper criteria.
• The design unit is an entity/architecture pair or a configuration.
• The entity ports are of type bit, bit_vector, real, std_logic, std_logic_vector, std_ulogic,
std_ulogic_vector, or their subtypes. The port clause may have any mix of these types.
Only locally static subtypes are allowed.
Port associations may be named or positional. Use the same port names and port positions that
appear in the entity.

SystemC Foreign Module (VHDL) Declaration

In cases where you want to run a mixed simulation with SystemC and VHDL, you must create
and declare a foreign module that stands in for each VHDL design unit instantiated under
SystemC. You can create the foreign modules in one of two ways:
• Run scgenmod, a utility that automatically generates your foreign module declaration
(much like vgencomp generates a component declaration).
• Modify your SystemC source code manually.
After you have analyzed the design, you can generate a foreign module declaration by using
scgenmod as follows:

scgenmod mod1

where mod1 is any name of a VHDL entity. A foreign module declaration for the specified
entity is written to stdout.

530 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Foreign Module (VHDL) Declaration

Guidelines for VHDL Complex Types

You can use VHDL complex data types with scgenmod. The compatible record/enum is
generated, along with the foreign module declaration, subject to the following rules:

• Names of fields of the SystemC structure/enum must be same as those on the VHDL
side.
• The data types of fields in the SystemC structure must follow the same type conversion
(mapping) rules as normal ports.
• Additional dummy functions (operator<<, sc_trace, operator== functions) must be
generated along with the structure definition.

Guidelines for Manual Creation in VHDL

Apply the following guidelines to the creation of foreign modules. A foreign module:

• Contains ports corresponding to VHDL ports. These ports must be explicitly named in
the constructor initializer list of the foreign module.
• Must not contain any internal design elements such as child instances, primitive
channels, or processes.
• Must pass a secondary constructor argument denoting the module’s HDL name to the
sc_foreign_module base class constructor. For VHDL, the HDL name can be in the
format [<lib>.]<primary>[(<secondary>)] or [<lib>.]<conf>.
• Can contain generics, which are supported for VHDL instantiations in SystemC designs.
See Generic Support for SystemC Instantiating VHDL for more information.
Example 9-11. SystemC Design Instantiating a VHDL Design Unit

A sample VHDL design unit to be instantiated in a SystemC design is:

entity counter is
port (count : buffer bit_vector(8 downto 1);
clk : in bit;
reset : in bit);
end;

architecture only of counter is

...
...

end only;

ModelSim® SE User's Manual, v10.7 531

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Generic Support for SystemC Instantiating VHDL

The SystemC foreign module declaration for the above VHDL module is:

class counter : public sc_foreign_module {

public:
sc_in<bool> clk;
sc_in<bool> reset;
sc_out<sc_logic> count;

counter(sc_module_name nm)
: sc_foreign_module(nm, "work.counter(only)"),
clk("clk"),
reset("reset"),
count("count")
{}
};

The VHDL module is then instantiated in the SystemC source as follows:

counter dut("dut");

where the constructor argument (dut) is the VHDL instance name.

Generic Support for SystemC Instantiating VHDL

Since the SystemC language has no concept of generics, generic values must be passed from a
SystemC parent to an HDL child through the SystemC foreign module (sc_foreign_module).
Refer to SystemC Foreign Module (VHDL) Declaration for information regarding the creation
of sc_foreign_module.

Passing Generics to sc_foreign_module Constructor (VHDL)

To instantiate a VHDL entity containing generics into the SystemC design, you can use one of
two methods, depending on whether the generic is an integer. If the generic is an integer, you
have two choices: passing as a template argument to the foreign module or as a constructor
argument to the foreign module. Non-integer generics must be passed to the foreign module
using constructor arguments.

Passing Integer and Non-Integer Generics as Constructor Arguments

Both integer and non-integer parameters can be passed by specifying two generic parameters to
the sc_foreign_module constructor: the number of generics (int num_generics), and the generic
list (const char* generics_list). The generic_list is listed as an array of const char*.

If you create your foreign module manually (see Guidelines for Manual Creation in VHDL),
you must also pass the generic information to the sc_foreign_module constructor. If you use
scgenmod to create the foreign module declaration, the generic information is detected in the
HDL child and is incorporated automatically.

532 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Generic Support for SystemC Instantiating VHDL

Example 9-12. SystemC Instantiating VHDL, Generic Information

Following Example 9-11, the generic information passed to the SystemC foreign module
declaration is shown below. The generic parameters passed to the constructor are shown in
magenta color:

class counter : public sc_foreign_module {

public:
sc_in<bool> clk;
...

counter(sc_module_name nm, char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module(nm),
{elaborate_foreign_module(hdl_name, num_generics, generic_list);}
};

The instantiation is:

dut = new counter ("dut", "work.counter", 9, generic_list);

Example 9-13. Passing Parameters as Constructor Arguments - 2

VHDL entity:

entity counter is
generic(
integer_gen : integer := 4,
real_gen : real := 0.0,
str_gen : string);
port(
clk : in std_logic;
count : out std_logic_vector(7 downto 0));
end counter;

Foreign module (created by the command: scgenmod counter)):

class counter : public sc_foreign_module

{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<8> > count;

counter(sc_module_name nm, const char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module(nm),
clk("clk"),
count("count")
{
elaborate_foreign_module(hdl_name, num_generics, generic_list);
}
~counter()
{}
};

ModelSim® SE User's Manual, v10.7 533

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Generic Support for SystemC Instantiating VHDL

Instantiation of the foreign module in SystemC:

SC_MODULE(top) {

counter* counter_inst_1; // Instantiate counter with counter_size = 20

SC_CTOR(top)
{
const char* generic_list[3];
generic_list[0] = strdup("integer_param=16");
generic_list[1] = strdup("real_param=2.6");
generic_list[2] = strdup("str_param=\"Hello\"");

//Pass all parameter overrides using foreign module constructor args

counter_inst_1 = new counter("c_inst", "work.counter", 3, \
generic_list);

// Cleanup the memory allocated for the generic list

for (int i = 0; i < 3; i++;)
free((char*)generic_list[i]);
}
};

Passing Integer Generics as Template Arguments

Integer generics can be passed as template arguments to a foreign module. Doing so enables
port sizes of VHDL modules to be configured using the integer template arguments. Use the
-createtemplate option to scgenmod to generate a class template foreign module.

Example 9-14. SystemC Instantiating VHDL, Passing Integer Generics as

Template Arguments

VHDL entity:

entity counter is
generic(counter_size : integer := 4);
port(
clk : in std_logic;
count : out std_logic_vector(counter_size - 1 downto 0));
end counter;

Foreign module (created by the command: scgenmod -createtemplate counter):

template <int counter_size = 4>

class counter : public sc_foreign_module
{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<counter_size-1 + 1> > count;

534 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Generic Support for SystemC Instantiating VHDL

counter(sc_module_name nm, const char* hdl_name)

: sc_foreign_module(nm),
clk("clk"),
count("count")
{
this->add_parameter("counter_size", counter_size);
elaborate_foreign_module(hdl_name);
}
~counter()
{}

Instantiation of the foreign module in SystemC:

counter<20> counter_inst_1;
// Instantiates counter with counter_size = 20
counter counter_inst_2;
// Instantiates counter with default counter_size = 4

SC_CTOR(top)
: counter_inst_1(cinst_1, "work.counter"),
counter_inst_2(cinst_2, "work.counter")
{}

};

Example 9-15. Passing Integer Generics as Template Arguments and Non-

integer Generics as Constructor Arguments

VHDL entity:

entity counter is
generic(counter_size : integer := 4);
port(
clk : in std_logic;
count : out std_logic_vector(counter_size - 1 downto 0));
end counter;

Foreign module (created by the command: scgenmod -createtemplate counter):

template <int counter_size = 4>

class counter : public sc_foreign_module
{
public:
sc_in<sc_logic> clk;
sc_out<sc_lv<counter_size-1 + 1> > count;

ModelSim® SE User's Manual, v10.7 535

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Generic Support for SystemC Instantiating VHDL

counter(sc_module_name nm, const char* hdl_name

int num_generics, const char** generic_list)
: sc_foreign_module(nm),
clk("clk"),
count("count")
{
this->add_parameter("counter_size", counter_size);
elaborate_foreign_module(hdl_name, num_generics, generic_list);
}
~counter()
{}

};

Instantiation of the foreign module in SystemC:

SC_MODULE(top) {

// Instantiate counter with counter_size = 20

counter<20>* counter_inst_1;

SC_CTOR(top)
{
const char* generic_list[2];
generic_list[0] = strdup("real_param=2.6");
generic_list[1] = strdup("str_param=\"Hello\"");

//
// The integer parameter override is already passed as template
// argument. Pass the overrides for the non-integer parameters
// using the foreign module constructor arguments.
//
counter_inst_1 = new counter<20>("c_inst", "work.counter", 2, \
generic_list);

// Cleanup the memory allocated for the generic list

for (int i = 0; i < 2; i++;)
free((char*)generic_list[i]);
}
};

536 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
VHDL Instantiating SystemC

VHDL Instantiating SystemC

To instantiate SystemC in a VHDL design, you must create a component declaration for the
SystemC module. Once you have generated the component declaration, you can instantiate the
SystemC component just like any other VHDL component.
SystemC Instantiation Criteria for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Component Declaration for VHDL Instantiating SystemC. . . . . . . . . . . . . . . . . . . . . . . 537
vgencomp Component Declaration when VHDL Instantiates SystemC . . . . . . . . . . . . 538
Exporting SystemC Modules for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Passing Generics From VHDL or Verilog Down to SystemC . . . . . . . . . . . . . . . . . . . . . 539

SystemC Instantiation Criteria for VHDL

You can instantiate a SystemC design unit within VHDL if it meets the following criteria:
• SystemC module names are case sensitive. The module name at the SystemC
instantiation site must match exactly with the actual SystemC module name.
• The SystemC design unit is exported using the SC_MODULE_EXPORT macro.
• The module ports are as listed in the table in Data Type Mapping Between SystemC and
VHDL
• Port data type mapping must match exactly. See the table in Data Type Mapping from
SystemC to Verilog or SystemVerilog.
Port associations may be named or positional. Use the same port names and port positions that
appear in the SystemC module. Named port associations are case sensitive.

Component Declaration for VHDL Instantiating

SystemC
A SystemC design unit can be referenced from a VHDL design as though it is a VHDL entity.
The interface to the design unit can be extracted from the library in the form of a component
declaration by running vgencomp. Given a library and a SystemC module name, vgencomp
writes a component declaration to standard output.
The default component port types are:

• std_logic
• std_logic_vector

ModelSim® SE User's Manual, v10.7 537

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
vgencomp Component Declaration when VHDL Instantiates SystemC

Optionally, you can choose:

• bit and bit_vector

VHDL and SystemC Identifiers

The VHDL identifiers for the component name and port names are the same as the SystemC
identifiers for the module name and port names. Except for the cases noted below, ModelSim
does nothing to the SystemC identifier when it generates the entity.

ModelSim converts the SystemC identifiers to VHDL 1076-1993 extended identifiers in three
cases:

• The SystemC identifier is not a valid VHDL 1076-1987 identifier.

• SystemC module is compiled with sccom -93. One exception is a valid, lowercase
identifier (such as scmod). Valid, lowercase identifiers are not converted even if you
compile the design with sccom -93.
• The SystemC identifier is not unique when case is ignored. For example, if ScMod and
scmod both appear in the same design, ModelSim will convert the former to \ScMod\).

vgencomp Component Declaration when VHDL

Instantiates SystemC
The vgencomp command generates a component declaration according to the following rules.
• Port Clause — The vgencomp command generates a port clause if the module has ports.
A corresponding VHDL port is defined for each named SystemC port.
You can set the VHDL port type to bit or std_logic. If the SystemC port has a range, then
the VHDL port type is bit_vector or std_logic_vector. For example:

SystemC port VHDL port

sc_in<sc_logic>p1; p1 : in std_logic;
sc_out<sc_lv<8>>p2; p2 : out std_logic_vector(7 downto 0);
sc_inout<sc_lv<8>>p3; p3 : inout std_logic_vector(7 downto 0)

• Configuration declarations are allowed to reference SystemC modules in the entity

aspects of component configurations. However, the configuration declaration cannot
extend into a SystemC instance to configure the instantiations within the SystemC
module.

538 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Exporting SystemC Modules for VHDL

Exporting SystemC Modules for VHDL

To be able to instantiate a SystemC module within VHDL (or use a SystemC module as a top
level module), the module must be exported.
Assume a SystemC module named transceiver exists, and that it is declared in header file
transceiver.h. Then the module is exported by placing the following code in a .cpp file:

#include "transceiver.h"
SC_MODULE_EXPORT(transceiver);

The sccom -link command collects the object files created in the work library, and uses them to
build a shared library (.so) in the current work library. If you have changed your SystemC
source code and recompiled it using sccom, then you must run sccom -link before invoking
vsim. Otherwise your changes to the code are not recognized by the simulator.

Passing Generics From VHDL or Verilog Down to

SystemC
When you have a VHDL or Verilog module instantiating a SystemC module and want to pass
generic information between the two levels, you must add custom macros to your SystemC
module for registering and initializing the generic information.
Prerequisites
The SystemC module must have a Verilog or VHDL parent module

Procedure
1. Add registration macros to the declarative region of the SystemC module. The macros
are:
• SC_GENERIC_INT(<generic_name>, <default_value>);
<default_value> must be an integer literal
• SC_GENERIC_REAL(<generic_name>, <default_value>);
<default_value> must be a real literal
• SC_GENERIC_STRING(<generic_name>, <default_value>);
<default_value> must be a string literal enclosed in double quotes (“).
For all macros, <default_value> must be a constant literal value. You cannot use
variables, constants, signals or other generics.
You can use these macros multiple times to register multiple generics.

ModelSim® SE User's Manual, v10.7 539

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Passing Generics From VHDL or Verilog Down to SystemC

2. Add initializer macros to the initializer list of your SystemC module’s constructor
section. The macros are:
• SC_INIT_GENERIC_INT(<generic_name>)
• SC_INIT_GENERIC_REAL(<generic_name>)
• SC_INIT_GENERIC_STRING(<generic_name>)
These macros will retrieve the correct generic value from the Verilog or VHDL parent
module.
You can use these macros multiple times to initialize multiple generics.
3. (optional) Use a flag “<generic_name>_valid” to ensure the validity of a generic’s
value. This is most useful when you use a generic in a conditional block to create
underlying hierarchy. If you do not test for this validity, or continue to simulation with
invalid information, you could receive the following warning.
# ** Warning: (vsim-6663)
Instance '/test_ringbuf/ring_INST/block1_COPY' created during
elaboration in vsim has not been created during elaboration in vopt.
It is likely that the instantiation statement corresponding to this
instance is dependent on the value of a generic propagated to
SystemC from HDL. Please check to see that the SystemC hierarchy
created in vsim is correct.

4. Compile using sccom as you normally would.

Examples
Below are some examples of the registration and initialization macro syntax. For a complete
example refer to the directory <install_dir>/examples/systemc/vhdl_sc_generics.

SC_MODULE(example)
{
public:

SC_GENERIC_INT(generic_int, 0);
SC_GENERIC_REAL(generic_real, 0.0);
SC_GENERIC_STRING(generic_boolean, "true");

SC_CTOR(example)
: SC_INIT_GENERIC_INT(generic_int),
SC_INIT_GENERIC_REAL(generic_real),
SC_INIT_GENERIC_STRING(generic_boolean)
{
if (generic_int_valid) {
block1_COPY = new control("block1_COPY", "control", 3,
generic_list_1);
block1_COPY->clock(clock);
block1_COPY->reset(reset);
}
}

540 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Passing Generics From VHDL or Verilog Down to SystemC

~example() {}

};

ModelSim® SE User's Manual, v10.7 541

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Procedural Interface to SystemVerilog

SystemC Procedural Interface to

SystemVerilog
SystemC designs can communicate with SystemVerilog through a procedural interface, the
SystemVerilog Direct Programming Interface (DPI). In contrast to a hierarchical interface,
where communication is advanced through signals and ports, DPI communications consists of
task and function calls passing data as arguments. This type of interface can be useful in
transaction level modeling, in which bus functional models are widely used.
This section describes the use flow for using the SystemVerilog DPI to call SystemVerilog
export functions from SystemC, and to call SystemC import functions from SystemVerilog.

The SystemVerilog LRM describes the details of a DPI C import and export interface. This
document describes how to extend the same interface to include SystemC and C++ in general.
The import and export keywords used in this document are in accordance with SystemVerilog
as described in the SystemVerilog LRM. An export function or task is defined in
SystemVerilog, and is called by C or SystemC. An import task or function is defined in
SystemC or C, and is called from SystemVerilog.

Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

SystemC DPI Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
SystemC Import Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Calling SystemVerilog Export Tasks / Functions from SystemC . . . . . . . . . . . . . . . . . . 548
SystemC Data Type Support in SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
SystemC Function Prototype Header File (sc_dpiheader.h) . . . . . . . . . . . . . . . . . . . . . . 551
Support for Multiple SystemVerilog Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
SystemC DPI Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

Definition of Terms
The following terms are used in this section.
• C++ import function
A C++ import function is defined as a free floating C++ function, either in the global or
some private namespace. A C++ import function must not have any SystemC types as
formal arguments. This function must be made available in the SystemC shared library.
• SystemC Import Function
A SystemC import function must be available in the SystemC shared library, and it can
be either of the following:
o A free-floating C++ function, either in the global or private namespace, with formal
arguments of SystemC types.

542 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC DPI Usage Flow

o A SystemC module member function, with or without formal arguments of SystemC

types.
• Export Function
A SystemVerilog export function, as defined in the SystemVerilog LRM.

SystemC DPI Usage Flow

The usage flow of SystemC DPI depends on the function modes, whether they are import or
export. The import and export calls described here can be mixed with each other in any order.

SystemC Import Functions

In order to make a SystemC import function callable from SystemVerilog, it needs to be
registered from the SystemC code before it can be called from SystemVerilog. This can be
thought of as exporting the function outside SystemC, thus making it callable from other
languages. The registration must be done by passing a pointer to the function using an API. The
registration can be done anywhere in the design but it must be done before the call happens in
SystemVerilog, otherwise the call fails with undefined behavior.

Global Functions
A global function can be registered using the API below:

int sc_dpi_register_cpp_function(const char* function_name, PTFN

func_ptr);

This function takes two arguments:

• the name of the function, which can be different than the actual function name. This
name must match the SystemVerilog import declaration. No two functions registered
using this API can have the same name: it creates an error if they do.
• a function pointer to the registered function. On successful registration, this function
will return a 0. A non-zero return status means an error.
Example 9-16. Global Import Function Registration

int scGlobalImport(sc_logic a, sc_lv<9>* b);

sc_dpi_register_cpp_function(“scGlobalImport”, scGlobalImport);

A macro like the one shown below is provided to make the registration even more simple. In
this case the ASCII name of the function will be identical to the name of the function in the
source code.

SC_DPI_REGISTER_CPP_FUNCTION(scGlobalImport);

ModelSim® SE User's Manual, v10.7 543

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Import Functions

In the SystemVerilog code, the import function needs to be defined with a special marker
(“DPI-SC”) that tells the SystemVerilog compiler that this is an import function defined in the
SystemC shared library. The syntax for calling the import function remains the same as
described in the SystemVerilog LRM.

Example 9-17. SystemVerilog Global Import Declaration

For the SystemC import function shown in Example 9-16, the SystemVerilog import
declaration is as follows:

import mti_scdpi::*;
import "DPI-SC" context function int scGlobalImport(
input sc_logic a, output sc_lv[8:0] b);

Example 9-18 shows how to register a global function by introducing a dummy module
specifically for the purpose of the registration.This lets you do the registration in the procedural
context anytime before the import function is used.

Example 9-18. Registering a Global Function

/*Thistop-levelSystemCmoduledoesnothingbutregisterDPI-SCimports
*/
SC_MODULE(dpi_sc_import)
{
SC_CTOR(dpi_sc_import)
{
SC_DPI_REGISTER_CPP_FUNCTION(scGlobalImport);
.............
}
~dpi_sc_import() {};
};
SC_MODULE_EXPORT(dpi_sc_import)

Please refer to Module Member Functions and Calling SystemVerilog Export Tasks / Functions
from SystemC for more details on the SystemC import and export task or function declaration
syntax.

Module Member Functions

Registering Functions
Module member functions can be registered anytime before they are called from the
SystemVerilog code. The following macro can be used to register a non-static member function
if the registration is done from a module constructor or a module member function. For a static
member function, the registration is accomplished using the interface
SC_DPI_REGISTER_CPP_FUNCTION, as described in SystemC Import Functions.

SC_DPI_REGISTER_CPP_MEMBER_FUNCTION(<function_name>, <func_ptr>);

Example:

SC_MODULE(top) {

544 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Import Functions

void sc_func() {
}

SC_CTOR(top) {
SC_DPI_REGISTER_CPP_MEMBER_FUNCTION(“sc_func”, &top::sc_func);
}
};

Note that in the above case, since the registration is done from the module constructor, the
module pointer argument might be redundant. However, the module pointer argument will be
required if the macro is used outside a constructor.

To register a member function from a function that is not a member of the module, the
following registration function must be used:

int sc_dpi_register_cpp_member_function(<function_name>, <module_ptr>,

<func_ptr>);

This function takes three arguments:

• The first argument is the name of the function, which can be different than the actual
function name.
This is the name that must be used in the SystemVerilog import declaration.
• The second argument is a reference to the module instance where the function is
defined.
It is illegal to pass a reference to a class other than a class derived from sc_module and
will lead to undefined behavior.
• The third argument is a function pointer to the member function being registered.
On successful registration, this function will return a 0. A non-zero return status means
an error.
For example, the member function run() of the module “top” in the example above can be
registered as follows:

sc_module* pTop = new top("top");

sc_dpi_register_cpp_member_function("run", pTop, &top::run);

Setting Stack Size for Import Tasks

The tool implicitly creates a SystemC thread to execute the C++ functions declared as
SystemVerilog import tasks. The default stack size is 64KBytes and may not be big enough for
any C++ functions. To change the default stack size, you can use the interface
sc_dpi_set_stack_size. You must use this interface right after the registration routine, for
example:

SC_MODULE(top) {

ModelSim® SE User's Manual, v10.7 545

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Import Functions

void sc_task() {

SC_CTOR(top) {
SC_DPI_REGISTER_CPP_MEMBER_FUNCTION("sc_task", &top::sc_task);
sc_dpi_set_stack_size(1000000); // set stack size to be 1Mbyte.
}
}

For the C++ functions declared as SystemVerilog import functions, you do not need to set the
stack size.

Declaring and Calling Member Import Functions in SystemVerilog

The declaration for a member import function in SystemVerilog is similar to the following:

import "DPI-SC" context function int scMemberImport(

input sc_logic a, output sc_lv[8:0] b);

Registration of static member functions is identical to the registration of global functions using
the API sc_dpi_register_cpp_function().

Only one copy of the overloaded member functions is supported as a DPI import, as DPI can
only identify the import function by its name, not by the function parameters.

To enable the registration of member functions, the SystemC source file must be compiled with
the -DMTI_BIND_SC_MEMBER_FUNCTION macro.

Calling Member Import Functions in a Specific SystemC Scope

A member import function can be registered for multiple module instances, as in the case when
registration routine SC_DPI_REGISTER_CPP_MEMBER_FUNCTION() is called from inside
a SystemC module constructor. At runtime, you must specify the proper scope when the
member import function call is initiated from SystemVerilog side. You can use the following
two routines to manipulate the SystemC scope before making the member import function call:

function string scSetScopeByName(input string sc_scope_name);

and

function string scGetScopeName();

scSetScopeByName() expects the full hierarchical name of a valid SystemC scope as the input.
The hierarchical name must use the Verilog-style path separator. The previous scope
hierarchical name before setting the new scope will be returned.

scGetScopeName() returns the current SystemC scope for next member import function call.

546 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Import Functions

Since both routines are predefined in ModelSim built-in package mti_scdpi, you need to import
this package into the proper scope where the two routines are used, using the following
statement:

import mti_scdpi::*;

Example 9-19. Usage of scSetScopeByName and scGetScopeName

//test.cpp:

SC_MODULE(scmod)
{
void cppImportFn();

SC_CTOR(scmod)
{
........
SC_DPI_REGISTER_CPP_MEMBER_FUNCTION("cppImportFn",
&scmod::cppImportFn);
......
}
};

//test.sv:

module top();

import mti_scdpi::*; // where scSetScopeByName() and scGetScopeName()

are defined.

string prev_sc_scope;
string curr_sc_scope;

scmod inst1(); //scope name "top.inst1"

scmod inst2(); //scope name "top.inst2"

import "DPI-SC" function void cppImportFn();

// call DPI-SC import function under scope "top.inst1"

prev_sc_scope = scSetScopeByName("top.inst1");
curr_sc_scope = scGetScopeName();
cppImportFn();

// call DPI-SC import function under scope "top.inst2"

prev_sc_scope = scSetScopeByName("top.inst2");
curr_sc_scope = scGetScopeName();
cppImportFn();

endmodule

ModelSim® SE User's Manual, v10.7 547

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Calling SystemVerilog Export Tasks / Functions from SystemC

Calling SystemVerilog Export Tasks / Functions

from SystemC
Unless an export call is made from an import function, you must set the scope of the export
function explicitly to provide the SystemVerilog context information to the simulator. You do
this by calling svSetScope() before each export function or task call.
An export function to be called with SystemC arguments must have an export declaration,
similar to the following:

export "DPI-SC" context function Export;

The function declaration must use the SystemC type package, similar to the following:

import mti_scdpi::*;
function int Export(input sc_logic a, output sc_bit b);

The syntax for calling an export function from SystemC is the same as any other C++ function
call.

SystemC Data Type Support in SystemVerilog DPI

The SystemVerilog package “mti_scdpi” must be imported if a SystemC data type is used in the
arguments of import and export functions.
import mti_scdpi::*

The SystemC data type names have been treated as special keywords. Avoid using these
keywords for other purposes in your SystemVerilog source files.

The table below shows how each of the SystemC type will be represented in SystemVerilog.
This table must be followed strictly for passing arguments of SystemC type. The SystemVerilog
typedef statements, listed in the middle column of Table 9-29, are automatically imported
whenever the mti_scdpi package is imported.

548 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Data Type Support in SystemVerilog DPI

Table 9-29. SystemC Types as Represented in SystemVerilog

SystemC Type SystemVerilog Import/Export
Typedef Declaration
sc_logic typedef logic sc_logic sc_logic
sc_bit typedef bit sc_bit sc_bit
sc_bv<N> typedef bit sc_bv sc_bit[N-1:0]
sc_lv<N> typedef logic sc_lv sc_lv[N-1:0]
sc_int<N> typedef bit sc_int sc_int[N-1:0]
sc_uint<N> typedef bit sc_uint sc_uint[N-1:0]
sc_bigint<N> typedef bit sc_bigint sc_bigint[N-1:0]
sc_biguint<N> typedef bit sc_biguint sc_biguint[N-1:0]
sc_fixed<W,I,Q,O,N> typedef bit sc_fixed sc_fixed[I-1:I-W]
sc_ufixed<W,I,Q,O,N> typedef bit sc_ufixed sc_ufixed[I-1:I-W]
sc_fixed_fast<W...> typedef bit sc_fixed_fast sc_fixed[I-1:I-W]
sc_ufixed_fast<W...> typedef bit sc_ufixed_fast sc_fixed[I-1:I-W]
sc_signed typedef bit sc_signed sc_signed[N-1:0]
sc_unsigned typedef bit sc_unsigned sc_unsigned[N-1:0]
sc_fix typedef bit sc_fix sc_fix[I-1:1-W]
sc_ufix typedef bit sc_ufix sc_ufix[I-1:1-W]
sc_fix_fast typedef bit sc_fix_fast sc_fix_fast[I-1:1-W]
sc_ufix_fast typedef bit sc_ufix_fast sc_ufix_fast[I-1:1-W]

According to the table above, a SystemC argument of type sc_uint<32> will be declared as
sc_uint[31:0] in SystemVerilog “DPI-SC” declaration. Similarly, sc_lv<9> would be
sc_lv[8:0]. to enable the fixed point datatypes, the SystemC source file must be compiled with -
DSC_INCLUDE_FX.

For fixed-point types the left and right indexes of the SystemVerilog vector can lead to a
negative number. For example, sc_fixed<3,0> will translate to sc_fixed[0-1:0-3] which is
sc_fixed[-1:-3]. This representation is used for fixed-point numbers in the ModelSim tool, and
must be strictly followed.

For the SystemC types whose size is determined during elaboration, such as sc_signed and
sc_unsigned, a parameterized array must be used on the SystemVerilog side. The array size
parameter value, on the SystemVerilog side, must match correctly with the constructor
arguments passed to types such as sc_signed and sc_unsigned at SystemC elaboration time.

ModelSim® SE User's Manual, v10.7 549

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC Data Type Support in SystemVerilog DPI

Examples
An export declaration with arguments of SystemC type:

export "DPI-SC" context function Export;

import mti_scdpi::*;
function int Export(input sc_logic a, input sc_int[8:0] b);

An import function with arguments of SystemC type:

import mti_scdpi::*;
import "DPI-SC" context function int scGlobalImport(
input sc_logic a, output sc_lv[8:0] b);

An export function with arguments of regular C types:

export "DPI-SC" context function Export;

function int Export(input int a, output int b);

Using a Structure to Group Variables

Both SystemC and SystemVerilog support using a structure, which is a composite data type that
consists of a user-defined group of variables. This grouping capability of a structure provides a
convenient way to work with a large number of related variables. The structure lets you use
multiple instances of these variables without having to repeat them individually for each
instance.

The same typedefs supported for SystemC types as arguments to DPI-SC can be members of
structures.

Example — SystemVerilog
The following structure declaration defines a group of five simple variables: direction, flags,
data, addr, token_number. The name of the structure is defined as packet_sv.

typedef struct {
sc_bit direction;
sc_bv[7:0] flags;
sc_lv[63:0] data;
bit[63:0] addr;
int token_number;
} packet_sv;

You can then use this structure (packet_sv) as a datatype for arguments of DPI-SC, just like any
other variable. For example:

import "DPI-SC" task svImportTask(input packet_sv pack_in,

output packet_sv pack_out);

550 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC Function Prototype Header File (sc_dpiheader.h)

Example — SystemC
An equivalent structure containing corresponding members of SystemC types are available on
the SystemC side of the design. The following structure declaration defines a group of five
simple variables: direction, flags, data, addr, token_number. The name of the structure is
defined as packet_sc.

typedef struct {
sc_bit direction;
sc_bv<8> flags;
sc_lv<64> data;
svBitVecVal addr[SV_PACKED_DATA_NELEMS(64)];
int token_number;
} packet_sc;

You can then use this structure (packet_sc) as a data-type for arguments of DPI-SC, just like
any other variable. For example:

import "DPI-SC" task svImportTask(input packet_sc pack_in,

output packet_sc pack_out);

SystemC Function Prototype Header File

(sc_dpiheader.h)
A SystemC function prototype header file is automatically generated for each SystemVerilog
compilation. By default, this header file is named sc_dpiheader.h. This header file contains the
C function prototype statements consistent with the “DPI-SC” import/export function/task
declarations. You can include this file in the SystemC source files where the prototypes are
needed for SystemC compiles and use this file as a sanity check for the SystemC function
arguments and return type declaration in the SystemC source files.
When the SystemVerilog source files with the usage of “DPI-SC” spans over multiple compiles,
the sc_dpiheader.h generated from an earlier SystemVerilog compilation will potentially be
overwritten by the subsequent compiles. To avoid the name conflict, one can use the
-scdpiheader argument to the vlog command to name the header file differently for each
compilation. For example the following vlog command line will generate a header file called
“top_scdpi.h”:

vlog -scdpiheader top_scdpi.h top.sv

Support for Multiple SystemVerilog Libraries

By default, only the DPI-SC usage in the current work library is processed at the SystemC link
time. If you use additional SystemVerilog libraries that import or export SystemC DPI routines,
the names of these libraries must be provided to the sccom command at link time using
the-dpilib argument.

ModelSim® SE User's Manual, v10.7 551

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC DPI Usage Example

An example of linking with multiple SystemVerilog libraries are:

sccom -link -dpilib dpilib1 -dpilib dpilib2 -dpilib dpilib3

where dpilib1, dpilib2 and dpilib3 are the logical names of SystemVerilog libraries previously
compiled.

An example of a complete compile flow for compiling with multiple libraries is as follows:

// compile SV source files for dpilib1

vlog -work dpilib1 -scdpiheader sc_dpiheader1.h ./src/dpilib1_src.sv

// compile SV source files for dpilib2

vlog -work dpilib2 -scdpiheader sc_dpiheader2.h ./src/dpilib2_src.sv

// compile SV source files for dpilib3

vlog -work dpilib3 -scdpiheader sc_dpiheader3.h ./src/dpilib3_src.sv

// SystemC source file compilations that may include all of the above
three header files.
sccom scmod.cpp

// compile other Verilog sources file if there are any.

vlog -work work non_scdpi_source.sv

// final sccom link phase

sccom -link -dpilib dpilib1 -dpilib dpilib2 -dpilib dpilib3

SystemC DPI Usage Example

The following example shows how to create a top Verilog module that uses a simple file
(hello.v) as input for a direct programming interface (DPI) to SystemC.
----------------------------------------
hello.v:
module top;
hello c_hello();
import "DPI-SC" context function void sc_func();
export "DPI-SC" task verilog_task;
task verilog_task();
$display("hello from verilog_task.");
endtask
initial
begin
sc_func();
#2000 $finish;
end
endmodule

552 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
SystemC DPI Usage Example

----------------------------------------
hello.cpp:
#include "systemc.h"
#include "sc_dpiheader.h"
SC_MODULE(hello)
{
void call_verilog_task();
void sc_func();
SC_CTOR(hello)
{
SC_THREAD(call_verilog_task);
SC_DPI_REGISTER_CPP_MEMBER_FUNCTION("sc_func", &hello::sc_func);
}
~hello() {};
};
void hello::sc_func()
{
printf("hello from sc_func().
}
void hello::call_verilog_task()
{
svSetScope(svGetScopeFromName("top"));
for(int i = 0; i < 3; ++i)
{
verilog_task();
}
}
SC_MODULE_EXPORT(hello);

----------------------------------------
Compilation:
vlog -sv hello.v
sccom -DMTI_BIND_SC_MEMBER_FUNCTION hello.cpp
sccom -link
vsim -c -do "run -all; quit -f" top

ModelSim® SE User's Manual, v10.7 553

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
SystemC DPI Usage Example

554 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 10
Advanced Simulation Techniques

ModelSim allows you to use advanced simulation techniques to control and speed the
simulation process.
Checkpointing and Restoring Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Simulating with an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

ModelSim® SE User's Manual, v10.7 555

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Checkpointing and Restoring Simulations

Checkpointing and Restoring Simulations

The checkpoint and restore commands allow you to save and restore the simulation state
within the same invocation of vsim or between vsim sessions.

Table 10-1. Checkpoint and Restore Commands

Action Definition Command used
checkpoint saves the simulation state checkpoint
<filename>
“warm” restore restores a checkpoint file saved in restore <filename>
a current vsim session
“cold” restore restores a checkpoint file saved in vsim -restore
a previous invocation of vsim <filename>

Checkpoint File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Checkpoint Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Controlling Checkpoint File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
The Difference Between Checkpoint/Restore and Restart. . . . . . . . . . . . . . . . . . . . . . . . 557
Using Macros with Restart and Checkpoint/Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Checkpointing Foreign C Code That Works with Heap Memory . . . . . . . . . . . . . . . . . 558
Checkpointing a Running Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

Checkpoint File Contents

Several items are saved with the checkpoint command, and restored with the restore command.
• modelsim.ini settings
• simulation kernel state
• vsim.wlf file
• signals listed in the List and Wave windows
• file pointer positions for files opened under VHDL
• file pointer positions for files opened by the Verilog $fopen system task
• state of foreign architectures
• state of PLI/VPI/DPI code

556 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Checkpoint Exclusions

Checkpoint Exclusions
There are a few items upon which checkpoint/restore does not work.
You cannot checkpoint/restore the following:

• state of macros
• changes made with the command-line interface (such as user-defined Tcl commands)
• state of graphical user interface windows
• toggle statistics
• SystemC designs
If you use the foreign interface, you will need to add additional function calls in order to use
checkpoint/restore. See the Foreign Language Interface Reference Manual or Verilog
Interfaces to C for more information.

Controlling Checkpoint File Compression

ModelSim allows you to determine whether the checkpoint file is compressed or uncompressed.
The checkpoint file is normally compressed.
Procedure
1. To turn off the compression, use the following command:
set CheckpointCompressMode 0

2. To turn compression back on, use this command:

set CheckpointCompressMode 1

3. You can also control checkpoint compression using the modelsim.ini file in the [vsim]
section (use the same 0 or 1 switch):
[vsim]
CheckpointCompressMode = <switch>

The Difference Between Checkpoint/Restore and

Restart
The restart command resets the simulator to time zero, clears out any logged waveforms, and
closes any files opened under VHDL and the Verilog $fopen system task. You can get the same
effect by first doing a checkpoint at time zero and later doing a restore. Using restart, however,
is likely to be faster and you do not have to save the checkpoint. To set the simulation state to
anything other than time zero, you need to use checkpoint/restore.

ModelSim® SE User's Manual, v10.7 557

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Using Macros with Restart and Checkpoint/Restore

Using Macros with Restart and Checkpoint/Restore

The restart command resets and restarts the simulation kernel, and zeros out any user-defined
commands, but it does not touch the state of the macro interpreter. This lets you perform restart
commands within macros.
The pause mode indicates that a macro has been interrupted. That condition will not be affected
by a restart, and if the restart is done with an interrupted macro, the macro will still be
interrupted after the restart.

The situation is similar for using checkpoint/restore without quitting ModelSim; that is, doing
a checkpoint and later in the same session doing a restore of the earlier checkpoint. The restore
does not touch the state of the macro interpreter so you may also do checkpoint and restore
commands within macros.

Checkpointing Foreign C Code That Works with

Heap Memory
If you are checkpointing foreign C code (FLI/PLI/VPI/DPI) that works with heap memory, use
mti_Malloc() rather than raw malloc() or new. This guarantees the correct restoration of any
memory allocated with mti_Malloc() is. When you allocate any memory with raw malloc() the
simulator will not restore it correctly and a simulator crash may result.

Checkpointing a Running Simulation

In general you can invoke a checkpoint command only when the simulation is stopped. If you
need to checkpoint without stopping the simulation, you need to write a script that utilizes the
when command and variables from your code to trigger a checkpoint. The example below
shows how this might be done with a simple Verilog design.
Keep in mind that the variable(s) in your code must be visible at the simulation time that the
checkpoint will occur. Some global optimizations performed by ModelSim may limit variable
visibility, and you may need to optimize your design using the +acc argument to vopt.

You would compile and run the example like this:

vlog when.v
vsim -c when -do "do when.do"

558 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Checkpointing a Running Simulation

where when.do is:

onbreak {
echo "Resume macro at $now"
resume
}
quietly set continueSim 1
quietly set whenFired 0
quietly set checkpointCntr 0
when { needToSave = 1 } {
echo "when Stopping to allow checkpoint at $now"
set whenFired 1
stop
}
while {$continueSim} {
run -all
if { $whenFired} {
set whenFired 0
echo "Out of run command. Do checkpoint here"
checkpoint cpf.n[incr checkpointCntr].cpt
}
}

ModelSim® SE User's Manual, v10.7 559

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Checkpointing a Running Simulation

and when.v is:

module when;

reg clk;
reg [3:0] cnt;
reg needToSave;

initial
begin
needToSave = 0;
clk = 0;
cnt = 0;
#1000;
$display("Done at time %t", $time);
$finish;
end

always #10 clk = ~clk;

always @(posedge clk)

begin
cnt = cnt + 1;
if (cnt == 4'hF)
begin
$display( "Need to Save : %b", needToSave);
needToSave = 1;
end
end

// Need to reset the flag, but must wait a timestep

// so that the when command has a chance to fire

always @(posedge needToSave)

#1 needToSave = 0;
endmodule

560 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Checkpointing a Running Simulation

and the transcript output is:

# vsim -do {do when.do} -c when

# //
# Loading work.when
# do when.do
# Need to Save : 0
# when Stopping to allow checkpoint at 290 # Simulation stop requested.
# Resume macro at 290
# Out of run command. Do checkpoint here # Need to Save : 0

# when Stopping to allow checkpoint at 610

# Simulation stop requested.
# Resume macro at 610
# Out of run command. Do checkpoint here # Need to Save : 0
# when Stopping to allow checkpoint at 930
# Simulation stop requested.
# Resume macro at 930
# Out of run command. Do checkpoint here
# Done at time 1000
# ** Note: $finish : when.v(14)
# Time: 1 us Iteration: 0 Instance: /when

ModelSim® SE User's Manual, v10.7 561

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Simulating with an Elaboration File

Simulating with an Elaboration File

The ModelSim compiler generates a library format that is compatible across platforms. This
means the simulator can load your design on any supported platform without having to
recompile first. Though this architecture offers a benefit, it also comes with a possible
disadvantage: the simulator has to generate platform-specific code every time you load your
design. This affects the speed with which the design is loaded.
You can generate a loadable image (elaboration file) that can be simulated repeatedly. On
subsequent simulations, you load the elaboration file rather than loading the design “from
scratch.” Elaboration files load quickly.

Why an Elaboration File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Creating an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Loading an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Modifying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Using PLI or FLI Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Why an Elaboration File?

In many cases design loading time is not that important. For example, if you a re doing
“iterative design,” where you simulate the design, modify the source, recompile and resimulate,
the load time is just a small part of the overall flow. However, if your design is locked down and
only the test vectors are modified between runs, loading time may have a significant effect on
overall simulation time, particularly for large designs loading SDF files.
Another reason to use elaboration files is for comparing performance benchmarks. Other
simulator vendors use elaboration files, and they distinguish between elaboration and run times.

One restriction of elaboration files is that they must be created and used in the same
environment. The same environment means the same hardware platform, the same OS and
patch version, and the same version of any PLI/FLI code loaded in the simulation.

Elaboration File Flow

To maximize the benefit of simulating elaboration files, you should observe the following flow:

1. If timing for your design is fixed, include all timing data when you create the elaboration
file (using the -sdf<type> instance=<filename> argument). If your timing is not fixed
in a Verilog design, you will need to use $sdf_annotate system tasks. Note that using
$sdf_annotate applies timing after elaboration.
2. Apply all normal vsim arguments when you create the elaboration file. Some arguments
(primarily related to stimulus) may be superseded later during loading of the elaboration
file (refer to Modifying Stimulus).

562 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Creating an Elaboration File

3. Load the elaboration file along with any arguments that modify the stimulus (refer to
Loading an Elaboration File).

Creating an Elaboration File

Elaboration file creation uses the same vsim settings or switches as a normal simulation plus an
elaboration-specific argument. The elaboration file retains the simulation settings and dictates
subsequent simulation behavior. You can modify some of these simulation settings at the time
of loading the elaboration file, as detailed below.
Procedure
1. To create an elaboration file, use the -elab <filename> or -elab_cont <filename>
arguments to vsim. The arguments support automatic collection of performance profile
data with the -autoprofile argument.
2. Use the -elab_cont argument to create the elaboration file and then continue with the
simulation after creation of the elaboration file. You can use the -c switch with -
elab_cont to continue the simulation in command-line mode.

Note
You can create elaboration files in command-line mode only. You cannot create an
elaboration file while running the ModelSim GUI.

Loading an Elaboration File

By default the elaboration file will load in command-line mode or interactive mode depending
on the argument (-c or -i) used during elaboration file creation. If no argument was used during
creation, the -load_elab argument will default to the interactive mode.
Procedure
To load an elaboration file, use the following command:

vsim -load_elab <filename>

Examples
The vsim arguments listed below can be used with -load_elab to affect the simulation.

ModelSim® SE User's Manual, v10.7 563

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Modifying Stimulus

+<plus_args>
-32
-64
-c, -i, -batch, or -gui
-coverstore
-do <do_file>
-f
-filemap_elab <HDLfilename>=<NEWfilename>
-l <log_file>
-quiet
-stats
-suppress
-sv_seed <integer> | random
-testname
-trace_foreign <level>
+UVM_TESTNAME
-ucdbteststatusmsgfilter
-vcdread <filename>
-vcdstim <filename>
-wlf <filename>

Modification of an argument that was specified at elaboration file creation, in most cases,
causes the previous value to be replaced with the new value. Usage of the -quiet argument at
elaboration load causes the mode to be toggled from its elaboration creation setting.

All other vsim arguments must be specified when you create the elaboration file, and they
cannot be used when you load the elaboration file.

Note
The elaboration file must be loaded under the same environment in which it was created.
The same environment means the same hardware platform, the same OS and patch version,
the same version of any PLI/FLI code loaded in the simulation, and the same release of
ModelSim.

Modifying Stimulus
A primary use of elaboration files is to simulate the same design multiple times using a different
stimulus.
Procedure
The following techniques allow you to modify the stimulus for each simulation run.

• Use the change command to modify parameters or generic values. This affects
values only—it has no effect on triggers, compiler directives, or generate statements
that reference either a generic or parameter.

564 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Using PLI or FLI Models

Note
Note that because the elaborated image is already created, the vsim -g and vsim -
G arguments are ignored for simulation.

• Use the -filemap_elab <HDLfilename>=<NEWfilename> argument to establish a

map between files named in the elaboration file. The <HDLfilename> argument, if
it appears in the design as a file name (for example, a VHDL FILE object as well as
some Verilog system tasks or functions that take file names), is substituted with the
<NEWfilename> argument. This mapping occurs before environment variable
expansion and cannot be used to redirect stdin/stdout.
• VCD stimulus files can be specified when you load the elaboration file. Both
vcdread and vcdstim are supported. Specifying a different VCD file when you load
the elaboration file supersedes a stimulus file you specify when you create the
elaboration file.
• In Verilog, +args values are readable by the PLI routine mc_scan_plusargs().
+args values specified when you create the elaboration file are superseded by +args
values specified when you load the elaboration file.
• Use -sv_seed <integer> | random to change the value used for the root random
number generator for SystemVerilog threads.

Using PLI or FLI Models

PLI models do not require special code to function with an elaboration file as long as the model
does not create simulation objects in its standard tf routines. The sizetf, misctf and checktf calls
that occur during elaboration are played back at -load_elab to ensure the PLI model is in the
correct simulation state. Registered user tf routines called from the Verilog HDL will not occur
until -load_elab is complete and the PLI model's state is restored.
By default, FLI models are activated for checkpoint during elaboration file creation and are
activated for restore during elaboration file load. (See the “Using checkpoint/restore with the
FLI” section of the Foreign Language Interface Reference manual for more information.) FLI
models that support checkpoint/restore will function correctly with elaboration files.

FLI models that do not support checkpoint/restore may work if simulated with the
-elab_defer_fli argument. When used in tandem with -elab, -elab_defer_fli defers calls to the
FLI model's initialization function until elaboration file load time. Deferring FLI initialization
skips the FLI checkpoint/restore activity (callbacks, mti_IsRestore(), ...) and may allow these
models to simulate correctly. However, deferring FLI initialization also causes FLI models in
the design to be initialized in order with the entire design loaded. FLI models that are sensitive
to this ordering may still not work correctly even if you use -elab_defer_fli.

See the vsim command for details on -elab, -elab_cont, -elab_defer_fli, -compress_elab,
-filemap_elab, and -load_elab.

ModelSim® SE User's Manual, v10.7 565

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Using PLI or FLI Models

Upon first simulating the design, use vsim -elab <filename> <library_name.design_unit> to
create an elaboration file that will be used in subsequent simulations.

In subsequent simulations you simply load the elaboration file (rather than the design) with
vsim -load_elab <filename>.

To change the stimulus without recording, recompiling, and reloading the entire design,
ModelSim allows you to map the stimulus file (or files) of the original design unit to an
alternate file (or files) with the -filemap_elab switch. For example, the VHDL code for
initiating stimulus might be:

FILE vector_file : text IS IN "vectors";

where vectors is the stimulus file.

If the alternate stimulus file is named, for example, alt_vectors, then the correct syntax for
changing the stimulus without recording, recompiling, and reloading the entire design is as
follows:

vsim -load_elab <filename> -filemap_elab vectors=alt_vectors

566 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 11
Recording and Viewing Transactions

Transactions provide a powerful means for debugging complex verification environments by

giving you a high level view into your design.
Transaction Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Viewing Transactions in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Debugging Transactions with Tcl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Transactions in Designs with Questa Verification IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Transaction Recording Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Transaction Recording Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Transaction Recording Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
CLI Debugging Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Verilog and VHDL API System Task Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

ModelSim® SE User's Manual, v10.7 567

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Transaction Background

Transaction Background
In order to understand transactions, you must also understand several underlying concepts.
What is a Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
About the Source Code for Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
About Transaction Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569

What is a Transaction?
A transaction is a statement of what the design is doing between one time and another during a
simulation run.
The word “transaction” can be confusing because of its association with Transaction Level
Modeling (TLM). In TLM, design units pass messages across interfaces and these messages are
typically called transactions.

In ModelSim, a transaction is an abstract statement, logged in the WLF file, of what the design
was doing at a specific time. The designer writes a transaction in the source code, which is then
logged into the WLF file during simulation. Often, transactions represent packets of data
moving around between design objects. Transactions allow users to debug and monitor the
design at any level of abstraction.

A transaction should consists of, at minimum: a name, a start time, and an end time. With that
alone, you can record the transitions of a state machine or summarize the activity on a bus. But
additionally, transactions can have user-defined attributes, such as address, data, or status.

Related Topics
Viewing Transactions in the GUI
Selecting Transactions or Streams in the Wave Window

About the Source Code for Transactions

You create/record transactions through the Verilog/VHDL or SystemC API calls placed in your
design source code.
• Verilog/SystemVerilog and VHDL transactions — written using a custom API
specifically developed for designs being verified with the ModelSim simulator. The
term “Verilog” is used throughout this chapter to indicate both forms of the language
(Verilog and SystemVerilog) unless otherwise specified.
• SystemC transactions — written with the SystemC Verification (SCV) library.
See the SystemC Verification Standard Specification, Version 1.0e for SystemC API
syntax for recording transactions.

568 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
About Transaction Streams

As the simulation progresses, individual transactions are recorded into the WLF file and are
available for design debug and performance analysis in both interactive debug and post-
simulation debug.

Related Topics
Viewing Transactions in the GUI
Selecting Transactions or Streams in the Wave Window
Recording Transactions in Verilog and VHDL
Recording Transactions in SystemC
Verilog and VHDL API System Task Reference

About Transaction Streams

ModelSim records transactions on streams, much as it records values on wires and signals.
Streams are debuggable objects that you can add to GUI windows such as the Objects or Wave
windows.
When you record more than one transaction on a stream at one time, the transactions are
“concurrent”. The simulator creates substreams as needed so that concurrent transactions on the
stream remain distinct (see Figure 11-1).

Concurrent transactions appear in the Wave window as:

• parallel transactions — transactions that overlap, but where no intrinsic relationship

exists between the two transactions.
• phase transactions — where the concurrent transaction is actually a child of the initial
transaction.
You specify whether a concurrent transaction is phase or parallel during the recording.

The simulator automatically logs the transactions, making them available for immediate
viewing in the GUI. The Wave window provides the best view of your transactions. For
example, Figure 11-1 shows a Wave window view of a number of transactions. (See Viewing
Transactions in the GUI for procedural details.)

ModelSim® SE User's Manual, v10.7 569

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
About Transaction Streams

Figure 11-1. Transaction Anatomy in Wave Window

Icon Element
Transaction Stream

Substream

Attributes

Parallel transactions

Phase transactions

Concurrent (overlapping)
transactions

Parallel Transactions
The simulator creates a separate substream for each transaction so that they are distinct from
each other in the view. Expanding the substream reveals the attributes on those transactions.

Concurrent transaction instances overlap, with a vertical offset, so that each instance is visible.

570 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
About Transaction Streams

Tip
Substream Creation — Generally, you have no direct control over the creation of
substreams; the simulator creates them for you during simulation, as needed. The rule for
substream creation is: The simulator places a transaction on the first substream that does not
have an active transaction and does not have any transaction in the future of the one being
logged.

Phase / Child Transactions

Phase transactions are a special type of concurrent transaction in ModelSim. The simulator
draws them as phases of a parent transaction.

For example, consider that a busRead transaction may have several steps or phases. Each of
these is represented as a smaller, concurrent transaction that appears on a second substream.
However, you can indicate that these are phase transactions, instructing the tool to draw them as
children of a parent transaction, as shown in Figure 11-1.

Related Topics
Viewing Transactions in the GUI
Selecting Transactions or Streams in the Wave Window

ModelSim® SE User's Manual, v10.7 571

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Viewing Transactions in the GUI

Viewing Transactions in the GUI

The simulator displays transactions in the Wave, List, and Object windows. The Wave window
displays transactions unlike any other objects in the GUI.
Recording Transactions in Verilog and VHDL
Recording Transactions in SystemC
Transaction Viewing Commonalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Transaction Objects in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Viewing Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Retroactive Recording and Transaction Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Selecting Transactions or Streams in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 578
Customizing Transaction Appearance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Viewing a Transaction in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Viewing a Transaction in the Objects Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

Transaction Viewing Commonalities

The simulator displays transactions consistently across all debugging windows and panes.
The simulator records transactions in the WLF file and displays them in debugging windows
when there are transaction instances on the stream.

A stream has children and is expandable if:

• there have been transactions defined on it with attributes

• transactions have overlapped on the stream
When unexpanded, an expandable stream's value includes the names of all current active
transactions; for example, "{busRetry busWrite}". The values of any attributes are available
only if you expand the stream to reveal them.

Figure 11-2 shows several streams, one of which has eight sub-streams.

572 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction Viewing Commonalities

Figure 11-2. Transaction Stream in Wave Window

If no transactions are defined on a particular stream, or none of the transactions have attributes,
then the stream is a simple signal with the name of the current transaction as its value.

The <Inactive> value appears under the following conditions:

• When no transaction is active on a stream.

• Where an element (attribute and/or sub-stream) exists, but is not used by a transaction.
Attributes and sub-streams are additive in ModelSim. The simulator adds these to the
stream's basic definition and keeps them as part of the stream definition from that point
onward. An attribute remains part of the stream even if it is not used on some transaction
SystemC Verification (SCV) allows designs to set explicit, undefined values on begin and end
attributes. The simulator shows these as "<Undefined>".

Transaction streams are dynamic objects under the control of the design. During simulation, the
design may define new streams, define new transaction kinds, overlap transactions or create
phase transactions, add special attributes of all kinds, and so forth. In response, the simulator
actively re-creates the objects in the GUI to reflect the most recent changes.

Dynamic changes are always additive: once an element is added to a stream, it remains there in
all views. In post-simulation debug, the GUI displays all elements as if they existed from the
beginning of the simulation run. For both interactive and post-simulation debug, the simulator
displays elements that did not exist at a particular simulation time as if the nolog command had
been used; their values are "No_Data".

ModelSim® SE User's Manual, v10.7 573

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Transaction Objects in the Structure Window

Related Topics
Viewing Transactions in the GUI

Transaction Objects in the Structure Window

The Structure windows allow you to navigate through the regions in the design, which is similar
to using the env command in command line mode.
Transaction objects look much like signals or nets in the design hierarchy of the Structure
window. When you navigate to a region containing a stream, the stream is visible in the Objects
window.

Related Topics
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Viewing a Transaction in the List Window
Viewing a Transaction in the Objects Window

Viewing Transactions in the Wave Window

The Wave window is where transactions can be viewed most effectively.
Prerequisites
• To view transactions in the Wave window, you must enable logging at the simulation
time when the transaction begins. The simulator automatically enables logging for
transactions written in SCV, Verilog, and VHDL.

Note
Logging can be disabled using the nolog command.

Procedure
1. Run the simulation on a design containing transactions.
vsim top; run -all

2. Add transactions to Wave window by doing any one of the following:

• Drag and drop from Object or Structure (sim) windows to the Wave window. (The
add wave command will be reflected in the Transcript window.)
• Click the middle mouse button when the cursor is over a transaction.
• Select transactions, then choose Add > To window.

574 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Viewing Transactions in the Wave Window

• Enter the following at the command line:

add wave -expand top/*

3. Select the plus icon next to streams having objects beneath them to reveal substreams
and/or any attributes.
Results
The icon for a transaction stream is a four-point star. The color of the star indicates the source
language for the region in which the stream is found: green for SystemC, light blue for Verilog,
and dark blue for VHDL.
In the waveform pane, transactions appear as boxes surrounding all the visible values for that
transaction. Figure 11-3shows an example of a transaction on a stream with only one substream,
where the stream is shown in its expanded and collapsed forms.
Figure 11-3. Viewing Transactions and Attributes

Each box represents an “instance” of a transaction on the stream. The horizontal line drawn
between the first and second transaction indicates a period of either no activity, or a period in
which logging has been disabled; there is no way to know which is the case.
When there are concurrent, parallel transactions, the stream shows concurrent values which are
drawn overlapping with a vertical offset, so that each instance can be seen. Expanding the
stream reveals the sub-streams, separating the transactions neatly, as in Figure 11-4. Each sub-
stream may expand to reveal attributes or phase sub-streams. When you select a transaction
instance, all related transactions are also highlighted, as in Figure 11-4.

ModelSim® SE User's Manual, v10.7 575

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Viewing Transactions in the Wave Window

Figure 11-4. Concurrent Parallel Transactions

Figure 11-5 shows a simple transaction stream that includes simple, user-defined address and
data attributes.
Figure 11-5. Transaction in Wave Window - Viewing

The top row of a transaction is the name of the transaction. When you expand the transaction
stream, as in Figure 11-5, additional rows reveal attributes of the transaction.
Tip
For SystemC begin/end attributes — if a begin end attribute was declared by the generator,
but the value was not defined, the value appears as “Undefined” in the GUI.

576 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Retroactive Recording and Transaction Display

Related Topics
Viewing Transactions in the GUI
Retroactive Recording and Transaction Display
Viewing a Transaction in the List Window
Viewing a Transaction in the Objects Window

Retroactive Recording and Transaction Display

Retroactive recording refers to the recording of a transaction whose start and/or end time occurs
before the current simulation time.
The two most important issues relating to the recording and display of retroactive transactions
are the appearance of retroactive transactions in the Wave window, as well as logged
transactions and retroactive recording.

Appearance of Retroactive Transactions in Wave Window

When retroactive transactions are drawn in the Wave window, more substreams may be shown
than you might expect. This is due to the fact that even though there might be a space between
the two transactions long enough for your retroactive transaction, the tool creates an additional
substream to draw that transaction.

Logged Transactions and Retroactive Recording

When you enable logging at simulation time, a transaction is logged in the WLF file when the
design calls ::begin_transaction() (SystemC), $begin_transaction() (Verilog), or
begin_transaction() (VHDL). The effective start time of the transaction (in other words, the time
passed by the design as a parameter to beginning the transaction) is irrelevant.

For example, a stream could have logging disabled between T1 and T2 and still record a
transaction in that period using retroactive logging after time T2. A transaction is always
entirely logged or not logged.

Related Topics
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Viewing a Transaction in the List Window
Viewing a Transaction in the Objects Window

ModelSim® SE User's Manual, v10.7 577

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Selecting Transactions or Streams in the Wave Window

Selecting Transactions or Streams in the Wave

Window
You can select transactions or streams in the Wave window; or if the transactions are recorded
with relations, from a pop-up menu.

Selection Options
Selecting a Transaction, or Transactions, with the Mouse
Select an individual transaction with a left click of the mouse on the transaction. Any
substreams of that transaction are also selected.

Left click while holding down the SHIFT key to select multiple transactions/streams.

Selecting a Transaction Stream

Left click the mouse on the transaction name in the object name area of the Wave window.

Selecting Related Transactions

1. Select a single transaction.
2. Right mouse click to bring up pop-up menu with the following choices:
o Select Related — to select a transaction to which the current transaction is pointing.
o Select Relating — to select a transaction that is pointing to the current transaction.
o Select Chain — to select all related and relating transactions for the current
transaction. Use this to select an entire causal chain.
o Select Meta — to select all related and relating transactions for the current
transaction. Use this to select any existing branches for the relationship.
Selecting any of these items brings up a submenu which lists all relationship names that
apply.
These pop-up menu items are grayed out if more than one transaction is selected.
For information on how to record relations, see “Specify relationships.” (SC) and
“Specify a relationship between transactions by providing:” (Verilog/VHDL).
Related Topics
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Viewing a Transaction in the List Window
Viewing a Transaction in the Objects Window

578 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Customizing Transaction Appearance

Customizing Transaction Appearance

You can customize the appearance of a transaction instance, or change the look of the entire
transaction stream at debug time. You can apply these custom settings to either the current
Wave window or all Wave windows.
Customizing Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Customizing Appearance of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

Customizing Color
Customizing the color in the Wave window overrides colors set with add_color() (in the design
code) during simulation
Use the GUI or the tr color command to change the color of one or more transactions or streams.

Note
Whether the color is specified using add_color() or in the Wave window, the color name
specified is interpreted by Tcl and the local window manager at debug time. For example,
“red” can appear different from machine to machine, depending on whether or not a system is
performing gamma correction.

Procedure
1. Right-click a transaction or stream name to open a popup menu.
2. Select Transaction Properties to open the Transaction-Stream Properties dialog box
(Figure 11-6).

ModelSim® SE User's Manual, v10.7 579

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Customizing Transaction Appearance

Figure 11-6. Transaction Stream Properties Dialog Box

3. Select the Colors tab.

4. In the Scheme area of the dialog box, select:
• Single-Color to apply the color change to all elements of the stream or transaction.
• Multi-Color to apply different colors to specific elements of the stream or
transaction. When you select one of the following elements and select a color, the
color is applied to that element:
o InactiveLine — line between transactions
o BorderLine — border around the transaction
o NameBackground — background behind the transaction name text
o NameText — text for the transaction name
o AttributeBackground — background behind the attribute text
o AttributeText — text for attribute
5. Choose a color from the palette or enter a color in the field (for example, light blue) and
6. Select Apply to leave dialog box open, or OK to apply and close it.

580 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Customizing Transaction Appearance

The element, transaction or entire stream of transactions changes to the chosen color.
Related Topics
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Customizing Transaction Appearance

Customizing Appearance of Attributes

You can use the GUI (or the tr order command) to change the order of transaction attributes and
hide/show attributes in the stream.
Procedure
1. Right-click a transaction or stream name to open a popup menu.
2. Select Transaction Properties to open the Transaction-Stream Properties dialog box.
3. Select the Order tab (Figure 11-7).
Figure 11-7. Transaction-Stream Properties Dialog Box

ModelSim® SE User's Manual, v10.7 581

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Viewing a Transaction in the List Window

4. Select the attribute from the list of visible attributes and select:
• Show — to display currently hidden attributes in stream
• Hide — to hide attribute from view in the stream
• Up — to move attribute up in the stream up
• Down — to move down
• Default — to restore original view
5. Do either of the following:
• Click Apply to make the changes and leave the dialog box open.
• Click OK to apply the changes and close the dialog box.
Related Topics
tr order [ModelSim SE Command Reference Manual]
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Selecting Transactions or Streams in the Wave Window

Viewing a Transaction in the List Window

You can use the List window to view transactions when you do not need to view transaction
relationships.
Prerequisites
Your design code must log the transactions for them to be visible in the GUI.

See “Recording Transactions in SystemC” or “Recording Transactions in Verilog and VHDL”

for instructions on transaction logging.

Procedure
1. Run simulation on a design containing transactions.
vsim top; run -all

2. Add transaction objects (transaction streams, sub-streams, attributes and attribute

elements) to List window by doing any one of the following:
• Drag and Drop from the Object or Structure (sim) windows.
• Chose Select transactions , then select the Add Selected to Window menu in the
Standard toolbar . Chose Add to List from the toolbar.
• Menu Selection — Add > To List.

582 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Viewing a Transaction in the List Window

Results
When transactions are present in the List window, new rows are written to the List window any
time a transaction's state changes. Specifically, rows are printed when a transaction starts or
ends and when any attribute changes state. State changes can occur between time steps or deltas.
Figure 11-8. Transactions in List Window

This example shows List output for a stream showing two transaction kinds. Each has a begin
attribute, a special attribute, and an end attribute in the style of SCV.
ns /top/abc/busMon
delta
0 +0 <Inactive>
1 +0 <Inactive>
1 +0 <Inactive>
1 +0 {busRead 1 <Inactive> <Inactive>}
3 +0 {busRead 1 100 <Inactive>}
3 +0 {busRead 1 100 10}
3 +0 <Inactive>
4 +0 <Inactive>
4 +0 <Inactive>
4 +0 <Inactive>
4 +0 {busWrite 2 <Inactive> <Inactive>}
6 +0 {busWrite 2 200 <Inactive>}
6 +0 {busWrite 2 200 20}
6 +0 <Inactive>
7 +0 <Inactive>
7 +0 <Inactive>
7 +0 <Inactive>
7 +0 {busRead 3 <Inactive> <Inactive>}
9 +0 {busRead 3 300 <Inactive>}
9 +0 {busRead 3 300 30}
9 +0 <Inactive>

In this example, you can see the same time/delta repeating as changes are made to the
transaction. For example, at 1(0) a busRead begins with the begin attribute set to the value "1".
At time 3(0), the end attribute value "100" arrives. On the next line, also at time 3(0), the special
attribute's value of "10" arrives. On the next line the transaction has ended. This is followed by
a number of lines showing the "<Inactive>" state as the various attributes change state
internally.
Related Topics
tr order [ModelSim SE Command Reference Manual]
Viewing Transactions in the GUI
Viewing Transactions in the Wave Window
Transaction Objects in the Structure Window

ModelSim® SE User's Manual, v10.7 583

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Viewing a Transaction in the Objects Window

Viewing a Transaction in the Objects Window

Use the Objects window to view transactions— but not transaction streams.
Procedure
1. Run simulation on a design containing transactions.
vsim top; run -all

2. Open the Objects window, if not open by default: View > Objects.
Results
Transactions appear in the Objects window as simple or composite signals, depending on the
complexity of transactions. The icon for a transaction is a four pointed star in the color of source
language for the region in which the transaction is found (SystemC - green, Verilog - light blue,
VHDL - dark blue).
Figure 11-9. Transactions in Objects Window

Related Topics
Selecting Transactions or Streams in the Wave Window
Transaction Objects in the Structure Window
Viewing Transactions in the Wave Window

Debugging Transactions with Tcl

In order to access attributes of transactions for debugging, you must know the full path to the
specific stream, substream, or attribute you wish to access. After you set the path to the
transaction, you can use Tcl commands and scripts to analyze your transactions.

584 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transactions in Designs with Questa Verification IP

The syntax for specifying a full path (using the Verilog path delimiter) to an attribute is:

<stream>.<substream>[<substream...].<attribute>

Procedure
1. Set the names of streams created using TCL. For example:
set streamName “top.stream1”

ModelSim generates the names of substreams. The name is the first character of the
parent stream's name followed by a number. Substream numbering starts at zero.
set subStream “s0”

2. Set the attribute name you want to access, such as:

set attributeName “myInteger”

Results
Once you have set the stream, substream, and attribute names, you can access the variable value
at any specified time. The following examine command shows how to use the attribute in the
above example:
exa –t 30 $streamName.$subStream.$attributeName

You can place commands such as these into a Tcl script and use it to parse the WLF database.
Related Topics
Names of Streams and Substreams

Transactions in Designs with Questa

Verification IP
The SystemVerilog and System C transactions discussed are distinct from the Verification IP
transactions.
For details on viewing Questa Verification IP component transactions, see “Questa Verification
IP Transaction Viewing in the GUI”.

Transaction Recording Flow

You must record SystemVerilog or SystemC transactions before you can view them in
ModelSim.
The basic steps for recording transactions are summarized in Figure 11-10.

ModelSim® SE User's Manual, v10.7 585

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Transaction Recording Flow

Figure 11-10. Recording Transactions

The SystemC tasks and Verilog API calls used in these steps are listed in Table 11-1.

586 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction Recording Flow

Table 11-1. System Tasks and API for Recording Transactions

Action SystemC - Verilog/VHDL -
System Task Used ModelSim API Used
Initializing extensions — Required in scv_startup() N/A
SystemC only.
See Initializing SCV and Creating WLF
Database Object
Creating database tied to WLF — scv_tr_db() N/A
Required for SystemC only. scv_tr_wlf_init()
See Initializing SCV and Creating WLF
Database Object
Provide extensions — scv_tr_stream() N/A
Required for SystemC only.1
See Transaction Generators
Define transaction streams — Required. scv_tr_generator() create_transaction_stream
See Define a transaction stream with
$create_transaction_stream() as shown in
the following code:
Define transaction kinds — See SCV documentation N/A
Required for SystemC only.
See Define a transaction kind.
Start the transaction — Required. ::begin_transaction() begin_transaction
See Start a transaction with
$begin_transaction and provide:
Record attributes — Optional. ::record_atrribute() add_attribute
See Record an attribute with the
$add_attribute system task and provide:
End the transaction — Required. ::end_transaction() end_transaction
See End a transaction with
$end_transaction and provide the handle
of the transaction:
Free the transaction handle — Required Freed automatically when free_transaction
for Verilog and VHDL. transaction goes out of
See Free the transaction handle scope

Specify relationships between ::add_relation() add_relation

transactions — Optional. or
See Specify a relationship between begin_transaction
transactions by providing:

ModelSim® SE User's Manual, v10.7 587

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Transaction Recording Flow

Table 11-1. System Tasks and API for Recording Transactions (cont.)
Action SystemC - Verilog/VHDL -
System Task Used ModelSim API Used
Specify begin and/or end times of ::begin_transaction() and begin_transaction
transactions — Optional. ::end_transaction() and
See Specify transaction start and end end_transaction
times
Control database logging — Optional. log / nolog and log / nolog
See Stream Logging ::set_recording()

Simulate the design — Required in order vsim <top> vsim <top>

to view transactions.
1. Required only for SCV user-defined types used as attributes.

588 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction Recording Guidelines

Transaction Recording Guidelines

Rules and guidelines apply to all transaction recording, regardless of the language in which the
transaction is recorded.
Restriction
The checkpoint/restore commands are not supported for transactions.

For language-specific instructions and deviations from these general truths, see: Recording
Transactions in Verilog and VHDL

For SystemC Verification (SCV) specific limitations and implementation details, see: SCV
Limitations

These guidelines give you an overview of how to record transactions for viewing in ModelSim:

Names of Streams and Substreams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Stream Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Transaction UIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Attribute Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Multiple Uses of the Same Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Anonymous Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Relationship in Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
The Life Cycle of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Transaction Handles and Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Names of Streams and Substreams

You must provide names for streams so they can be referenced for debug.
Tip
A space in any name (whether a database, stream, transaction, or attribute) requires the
name be enclosed by escaped or extended identifiers.

Anonymous streams are not allowed. Stream names may be any legal C, Verilog or VHDL
identifier. If the name includes white-space or is not a legal C identifier, it must be an escaped or
extended identifier or you will get a warning for a non-standard name at run time.

Full or Relative Pathnames

When creating a transaction stream, you can specify a full path to the region in which you want
the transaction stream to appear. Assuming that the specified path leads to an existing region in
the design hierarchy, that request is honored. No regions are created in the process.

ModelSim® SE User's Manual, v10.7 589

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Stream Logging

You can also specify a relative path, using the simulator to search upward from the calling
region in the hierarchy. The region where a transaction stream appears is determined by where
you place the call to create the stream ($create_transaction_stream, create_transaction_stream,
or scv_tr_stream). For most designs, the transaction stream where you expect it to be in the
Wave window. However, for some SystemVerilog and OVM class-based designs, the
transaction stream placement may not be where you expect it. In these cases, use full or partial
path specifications.

Substream Names
The simulator names substreams automatically. The name of any substream is the first character
of the parent’s name followed by a simple index number. The first substream has the index zero.

Caution
If the parent stream has a non-standard name, such as one that starts with a numeral or a
space, you may have difficulty with debug.

Related Topics
Transaction Recording Guidelines
Stream Logging
Transaction UIDs
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Stream Logging
When your design creates a stream, logging is enabled for that stream providing that logging is
enabled at the simulation time when the design calls ::begin_transaction(). The effective start
time of the transaction (the time passed by the design as a parameter to ::begin transaction())
does not affect the logging of the stream.
For example, a stream could have logging disabled between T1 and T2 and still record a
transaction in that period using retroactive logging after time T2. A transaction is always
entirely logged or entirely ignored. You can disable the logging on transaction streams with the
nolog command.

590 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction UIDs

There is no way in the simulator to distinguish a stream whose logging has been disabled from
one that is merely inactive.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Transaction UIDs
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Transaction UIDs
Each transaction created during simulation is assigned a 64-bit serial number. This serial
number, along with the logical name of the dataset in which the transaction exists, comprises the
transaction’s unique identifier (UID). Within the simulation run, this number is unique.
The tr uid and tr color commands use the UID to specify a specific transaction within a
particular dataset. UIDs also allow for any transaction to refer to any other transaction.

Examples:

tr color -nametext “light blue” {sim 10023}

tr color -namebg red {myData 209832}

The first example represents a transaction in the current simulation, since “sim” is always the
name of the current simulation dataset. The second example is a transaction from a WLF file
opened with the logical name “myData”.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes

ModelSim® SE User's Manual, v10.7 591

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Attribute Type

Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Attribute Type
On any single transaction stream, ModelSim associates an attribute name with a data type.
Tip
In most cases, ModelSim issues an error if you attempt to overload an attribute name. The
only exception is that the same attribute name on two different sub-streams of a stream may
be overloaded.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Transaction UIDs
Multiple Uses of the Same Attribute
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Multiple Uses of the Same Attribute

Your design can set the same attribute (same type) many times during a single transaction.
However, ModelSim records only the most recently set value at the end of the transaction.
Once any attribute is used, it is considered an attribute of the parent stream from that time
onward. Thus, it shows up as a parameter on all subsequent transactions, even if it is unused.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Transaction UIDs

592 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Anonymous Attributes

Attribute Type
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Anonymous Attributes
ModelSim requires every transaction attribute to have a name. It is possible, however, to omit
the name in the SystemC Verification (SCV) and Verilog/VHDL APIs for transaction
recording. The simulator resolves the problem by inventing a name for the attribute.
• SCV — an attribute is anonymous if the name is the empty string or the name is a NULL
pointer. The simulator uses the data type to choose a new name as follows:
o If the type is a struct or class, the simulator constructs an attribute for each field or
member, using the field or member name as the name of each attribute.
o If the type is anything other than a string or class, the simulator uses the type name
(such as, short or float) as the name for the attribute.
• Verilog/VHDL — an attribute is anonymous if the name parameter is ignored or is an
empty string. The simulator chooses a name as follows:
o If the value of the attribute is passed through a variable, the simulator uses the name
of the variable as the name for the attribute.
o If the value of the attribute is passed as a literal or the return value from a function,
the simulator uses the type name of the value as the name for the attribute.
In any language, if the simulator that finds an attribute already exists with the same name and
type as the one it is creating, it will re-use that attribute.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Transaction UIDs
Attribute Type
Multiple Uses of the Same Attribute
Relationship in Transactions
The Life Cycle of a Transaction

ModelSim® SE User's Manual, v10.7 593

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Relationship in Transactions

Transaction Handles and Memory Leaks

Relationship in Transactions
In ModelSim, a relationship is a pointer from one instance in the design to another.
A relationship consists of a source transaction, a target transaction, and a name for the
relationship. It can read as “<source> has the <name> relationship to <target>”. The name you
assign to the relationship is arbitrary: choose a name that is meaningful. ModelSim interprets no
meaning from the pointer.

When ModelSim simulates the design, it records the relationship — both from the source to the
target and the target to the source — in the database so it is available for transaction debug and
analysis.

Verilog example:

...
$add_relation(hSrc, hTgt, "child");

Here, the relationship is created for hSrc such that hSrc claims the child relationship to hTgt.
When this relationship is recorded, a counter relationship is automatically recorded on hTgt to
indicate that hSrc is claiming the child relationship with hTgt.

For more information on how to record a relationship, see “Specify relationships.” (SystemC)
and “Specify a relationship between transactions by providing:” (Verilog/VHDL). For
instructions on viewing related transactions, see “Selecting Transactions or Streams in the
Wave Window”.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

The Life Cycle of a Transaction

Any transaction has a life cycle that can be summarized in four distinct phases.

594 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
The Life Cycle of a Transaction

• Creation — This is the moment in simulation when a design calls $begin_transaction()

or an equivalent method.
• Start time — Usually, the start time is determined by the call to $begin_transaction(). An
exception occurs in the case of retroactive recording, when the start time is set earlier
than the creation time.
• End time — Typically determined by a call to $end_transaction(), though you can adjust
it.
• End-of-life — The moment in simulation when the design releases its handle to the
transaction, or the transaction has been deleted (Verilog/VHDL only). No more
additions or changes can be made to the transaction past this point.
This life cycle has the following implications:

• Attributes and relations can be added during the entire life cycle, not just between the
start and end times for the transaction, so long as you have a valid handle to the
transaction. A valid handle is one whose returned value is non-zero. See “Valid Verilog
Handles” for information about how to detect errors.
• You can enable or disable logging of transactions anytime during the life cycle,
regardless of start and end times.
• A transaction stays in memory until its handle is released. Transaction handles should be
freed as soon as possible, to minimize use of memory buffering and the retroactive WLF
channels. Verilog and VHDL designs must use the free_transaction() task explicitly for
every transaction.

Retroactive Recording / Start and End Times

The only time you must specify start and end times for a transaction is when you are recording a
transaction retroactively. For all other transaction types, the simulator can determine the start
and end times. It is illegal to start or end a transaction in the future or before time 0. If either is
specified, the simulator uses the current simulation time and issues a non-fatal error message.

Start and End Times for Phase Transactions

The start and end times for phase transactions must be entirely within the timespan of the parent
transaction. Start and end times of phases can match the start or end times of parent.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Transaction UIDs

ModelSim® SE User's Manual, v10.7 595

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Transaction Handles and Memory Leaks

Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes
Relationship in Transactions
Transaction Handles and Memory Leaks

Transaction Handles and Memory Leaks

Global or static transaction handles remain in memory during a simulation, resulting in loss of
memory.
When the design calls begin_transaction(), the transaction handle is stored in memory and
remains in memory until it is freed. In Verilog and VHDL, you must free the transaction handle
explicitly using $free_transaction() or free_transaction(), respectively. In SystemC, the handle
is freed for you when the handle goes out of scope. However, global or static transactions
remain in memory for the entire simulation.

Though this memory loss may be more accurately described as “usage” rather than a “leak”, it is
wasteful to use memory for transactions no longer in use. You should write your code in such a
way as to free transaction handles once they are not needed.

Related Topics
Transaction Recording Guidelines
Names of Streams and Substreams
Stream Logging
Transaction UIDs
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction

596 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction Recording Procedures

Transaction Recording Procedures

The procedures for recording transactions depend on the language you are using.
The recording procedures for Verilog and VHDL are much simpler than those for SystemC, so
they are presented first to simplify learning about the recording process.

Recording Transactions in Verilog and VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

Verilog Recorded Transaction Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Valid Verilog Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Recording Transactions in SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Initializing SCV and Creating WLF Database Object. . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Transaction Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Recording SCV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
SCV API Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
SCV Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Recording Transactions in Verilog and VHDL

Because there is currently no standard for transaction recording in Verilog or VHDL, ModelSim
includes a set of system tasks to perform transaction recording into a WLF file.
Note
"Verilog" refers both to Verilog and SystemVerilog unless otherwise noted.

See Verilog and VHDL API System Task Reference for specific tasks used to record the
transactions. The API is the same for Verilog and SystemVerilog.

The recording APIs for Verilog and VHDL differ from the SystemC Verification (SCV) API.
Specifically, in Verilog and VHDL:

• There is no database object as there is in SCV; the database is always WLF format (a
.wlf file).
• There is no concept of begin and end attributes All attributes are recorded with the
system task $add_attribute() or add_attribute.
• Your design code must free the transaction handle once the transaction is complete and
all use of the handle for relations or attribute recording is complete. (In most cases,
SystemC designs ignore this step since SCV frees the handle automatically.)
For a full example of recorded Verilog transactions with comments, see Verilog Recorded
Transaction Code Example.

ModelSim® SE User's Manual, v10.7 597

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Recording Transactions in Verilog and VHDL

Prerequisites
• Understand the rules governing transaction recording. Refer to Transaction Recording
Guidelines for details.
• For VHDL, the design must include the transaction recording package supplied with
ModelSim. You can find this in the modelsim_lib library.
library modelsim_lib;
use modelsim_lib.transactions.all;

Note
This procedure is based on the Verilog API. The VHDL API is very similar.

Procedure
1. Define a transaction stream with $create_transaction_stream() as shown in the following
code:
module top;
integer hStream

initial begin
hStream = $create_transaction_stream("stream", "transaction");
.
.
end
.
.
endmodule

This example code declares the stream stream in the current module. The stream is part
of the WLF database and the stream will appear as an object in the GUI. The stream will
be logged.
In some OVM or other class-based designs, you may want to specify stream a full path
to the location where you wish the stream to appear. See “Full or Relative Pathnames”
for more information.
2. Start a transaction with $begin_transaction and provide:
• a valid handle to a transaction stream
• a variable to hold the handle of the transaction
integer hTrans;
.
.
hTrans = $begin_transaction(hstream, "READ");

This example code begins a transaction named "READ" on the stream already created.
The $begin_transaction system function accepts other parameters to specify: the start
time for the transaction, and any relationship information, including its designation as a

598 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Recording Transactions in Verilog and VHDL

phase transaction (see “Phase / Child Transactions”). See Verilog and VHDL API
System Task Reference for syntax details.
The return value is the handle for the transaction. It is needed to end the transaction or
record attribute.
3. Record an attribute with the $add_attribute system task and provide:
• the handle of the transaction being recorded
• the name for the attribute
• a variable that holds the attribute value
integer address;
.
.
$add_attribute(hTrans, address, "addr");

Note that nothing prevents the design from setting the same attribute many times during
the transaction. However, ModelSim records only the last value of the attribute prior to
the end of the transaction. Once the design uses an attribute, it becomes a permanent
attribute of the parent stream from that time onward. Thus, it shows up as an element of
all subsequent transactions, even if it is unused.
4. End a transaction with $end_transaction and provide the handle of the transaction:
$end_transaction(hTrans);

This ends the specified transaction, though it does not invalidate the transaction handle.
The handle is still valid for calls to record attributes and to define relations between
transactions. As with $begin_transaction(), there are optional parameters for this system
task. See Verilog and VHDL API System Task Reference for details.
5. Specify a relationship between transactions by providing:
• two valid transaction handles: one for the source, one for the target
• a <name> for the relation (one signifying the relationship of the <source> to the
<target>). ModelSim captures the name and uses it to record to pointers, one from
the source instance to the target instance, and one from the target to the source. In the
examples below, the name chosen to represent the relationship is “successor”.
• Specify relation from an existing transaction to another existing transaction:
Submit a call to $add_relation(), with the source, target and name:
integer hSrc;
integer hTgt;
.
.
$add_relation(hSrc, hTgt, "successor");

ModelSim® SE User's Manual, v10.7 599

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Recording Transactions in Verilog and VHDL

This method is valid any time the design has two valid transaction handles.
See “Relationship in Transactions” and “Selecting Transactions or Streams in the
Wave Window” for more information.
6. Specify transaction start and end times
To specify a start and/or end time for any transaction, pass the start and end times as
parameters to $begin_transaction() and $end_transaction(). The time must be the current
simulation time or earlier. See “Transaction Recording Guidelines” for information on
valid start and end times.
7. Free the transaction handle

Tip
To avoid memory leakage: You must explicitly free all transaction handles in your
design. This is a requirement for Verilog, SystemVerilog and VHDL) recording. See
“Transaction Handles and Memory Leaks”.

a. Ensure that the transaction is complete and all use of the handle for recording
attributes and relations has been completed.
b. Submit a call to $free_transaction, providing the handle of the transaction being
freed.
$free_transaction(hTrans);

where hTrans is the name of the transaction handle to be freed.

8. Delete a transaction
To delete a transaction, pass a valid transaction handle as the parameter to
$delete_transaction(). This removes the specified transaction from the transaction
database before it is written to the WLF file. If the transaction was visible in the Wave
window (or elsewhere), it vanishes as if it never existed.
$delete_transaction(hTrans);

where hTrans is the handle of the transaction being deleted.

Related Topics
Recording Transactions in SystemC
Verilog and VHDL API System Task Reference
Verilog Recorded Transaction Code Example
Valid Verilog Handles

600 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Verilog Recorded Transaction Code Example

Verilog Recorded Transaction Code Example

This API code example of a recorded transaction is distributed with ModelSim, and can be
found in the following location of your installation directory:
install_dir>/examples/systemverilog/transactions/simple.
module top;
integer stream, tr;

initial begin
stream = $create_transaction_stream("Stream");
#10;
tr = $begin_transaction(stream, "Tran1");
$add_attribute(tr, 10, "beg");
$add_attribute(tr, 12, "special");
$add_attribute(tr, 14, "end");
#4;
$end_transaction(tr);
$free_transaction(tr);
end

endmodule

Related Topics
Recording Transactions in Verilog and VHDL
Verilog and VHDL API System Task Reference
Valid Verilog Handles

Valid Verilog Handles

If there is an error on a call to create_transaction_stream() or begin_transaction(), the handle
returned will have the value zero.
Related Topics
Recording Transactions in Verilog and VHDL
Verilog and VHDL API System Task Reference
Verilog Recorded Transaction Code Example

Recording Transactions in SystemC

Use the SystemC Verification (SCV) library’s transaction recording API routines to define
transactions, to start them, to end them, to create relationships between them, and to attach
additional information (attributes) to them.
These routines are described in the “SystemC Verification Standard Specification, Version
1.0x”: please refer to it for SCV specific details.

ModelSim® SE User's Manual, v10.7 601

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Initializing SCV and Creating WLF Database Object

The SCV API is more involved than the Verilog or VHDL recording APIs. Specific differences
for the SCV API are as follow:

• In SCV, you must create a database object that is tied to a WLF file.
• The concept of begin and end attributes is unique to SCV. In Verilog and VHDL, all
attributes are recorded with a single system task: add_attribute().
• Transaction handles are freed automatically in SCV.
For a full example of recorded SCV transactions with comments, see “SCV API Code
Example”.

Prerequisites
• Understand the material in the section entitled “Transaction Recording Guidelines” to
understand the basic rules and guidelines for recording transactions.
• Be aware of the limitations for recording transactions in SCV. See “SCV Limitations”.
Procedure
1. Initialize SCV and the MTI extensions for transaction recording and debug.
a. Create a database tied to WLF.
b. Provide SCV extensions, for user-defined types used with attributes.
2. Create transaction generators.
3. Write the transactions.
Related Topics
Initializing SCV and Creating WLF Database Object
Transaction Generators
Verilog Recorded Transaction Code Example
Recording SCV Transactions

Initializing SCV and Creating WLF Database Object

Before transactions can be recorded, the design must initialize the SCV library once, as part of
its own initialization.
Procedure
1. Enter scv_startup() in the design code — this initializes the SCV library.
2. Enter scv_tr_wlf_init() in the design code — this creates the database tied to WLF,
allowing transactions to then be written to specific database objects in the code.

602 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Transaction Generators

3. Enter database object(s) — you can create many objects, or create one and specify it as
the default object. All database objects are contained the same WLF file.
Examples
Here is a code example of a one-time initialization routine that sets up SCV, ties all databases to
WLF, and then creates one database as the default.

static scv_tr_db * init_recording() {

scv_tr_db *txdb;

/* Initialize SCV: */
scv_startup();

/* Tie databases to WLF: */

scv_tr_wlf_init();

/* Create the new DB and make it the default: */

txdb = new scv_tr_db("txdb");

if (txdb != NULL)
scv_tr_db::set_default_db(txdb);

return txdb;
}

Note
ModelSim ignores the following:

• name argument to scv_tr_db() — All databases are tied to the WLF file once the user
calls scv_tr_wlf_init().
• sc_time_unit argument to scv_tr_db() when the database is a WLF database — The time
unit of the database is specified by the overall simulation time unit.

Related Topics
Transaction Generators
Recording SCV Transactions
Recording Transactions in SystemC

Transaction Generators
Using Standard C and SystemC types for attributes enable transaction generators without
additional preparation with SystemC Verification (SCV).
C/C++ and SystemC type support is limited as described in Type Support for SystemC. If your
design includes user-defined types — such as classes, structures, or enumerations — you must

ModelSim® SE User's Manual, v10.7 603

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Recording SCV Transactions

provide SCV extensions so that SCV and the ModelSim simulator can extract the necessary
type and composition information to record the type.

For specific details on providing SCV extensions, refer to the SystemC Verification Standard
Specification, Version 1.0e.

Related Topics
Initializing SCV and Creating WLF Database Object
Recording SCV Transactions
SCV API Code Example
Recording Transactions in SystemC
SCV Limitations

Recording SCV Transactions

The steps for recording SystemC Verification (SCV) transactions require you to define a
transaction stream, start a transaction, record special attributes, specify transaction start and end
times, and end the transaction.
Tip
A space in any name (whether a database, stream, transaction, or attribute) requires the
name be an escaped or extended identifier.

Procedure
1. Define a transaction stream
Before you can record a transaction, you must define the stream onto which the
transaction will be written. In SCV, streams are tied to a specific database so that all
transactions on them are written into that database only. Usually, the code declares the
stream as a member of the module that will use it. Then, it must call the constructor,
passing the stream's name and database as parameters. For example:
SC_MODULE(busModel)
{
| public:
scv_tr_db *txdb;
scv_tr_stream busStream;
SC_CTOR(busModel) :
txdb(init_recording()),
busStream( "busModel", "**TRANSACTOR**")
{
}
}

604 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Recording SCV Transactions

This example code declares the database and stream objects. In the module constructor,
it initializes the database by calling the setup routine (defined in Initializing SCV and
Creating WLF Database Object). It initializes the stream object with its display name
and a string indicating the stream kind. The database is presumed to be the default,
though the example could have been explicit and passed "txdb" as a third parameter.
The name of the stream must be passed as a parameter. ModelSim treats it as a path
name. This defines where the stream will appear in the design during debug. Each
stream lives in a design region: either the instance in which it was declared or an
instance specified in the constructor parameters.
If the string is a simple name such as "busRead", ModelSim assumes the stream is to be
created in the current scope, usually the instance of the module. If the string is a partial
path such as "dut/bus/busRead", ModelSim will try to find parent region "dut/bus" as the
home for the stream. If the string is a full path, such as "/top/dut/bus/busRead",
ModelSim tries to find the exact region "/top/dut/bus". For full and partial paths, the
region specified must exist or you will receive a runtime error.
If you specify a stream that already exists, returns a handle to the same stream even
though the design will have two different scv_tr_stream objects.
For more specific details on writing a transaction, refer to the “SystemC Verification
Standard Specification, Version 1.0e”.
2. Define a transaction kind.

Note
This step is optional.

In SCV, each transaction is defined by a generator object, which is a template for a

transaction. The generator:
• Specifies the name of the transaction. Anonymous transactions are not allowed.
• Specifies optional begin and end attributes. Begin and end attributes are part of the
generator for that kind. They are treated as part of each instance of that transaction.
First, the code must declare each generator, usually in the module in which it will be
used. Any begin and end attribute types must be provided as template parameters. Then,

ModelSim® SE User's Manual, v10.7 605

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Recording SCV Transactions

construct the generator—usually in the constructor initialization list of the parent

module. For example:
SC_MODULE(busModel)
{
public:
scv_tr_db *txdb;
scv_tr_stream busStream;
scv_tr_generator<busAddrAttr, busDataAttr> busRead;
SC_CTOR(busModel) :
txdb(init_recording()),
busStream( "busModel", "**TRANSACTOR**"),
busRead("busRead", busStream)
{
}
}

The third and fourth arguments to scv_tr_generator::scv_tr_generator() are the names

for the begin and end attributes, which SCV allows to be NULL by default. (Any
attributes you create with an empty string or NULL pointer for the name are called
anonymous attributes. For more information on how these are treated by ModelSim, see
“Anonymous Attributes”.)
The example above adds the declaration of the generator "busRead" and shows how the
constructor is provided with both the name (also "busRead") and the stream on which
the generator will be used. The begin and end attributes are left anonymous.
3. Start a transaction.
a. Prepare the value for the begin attribute.
b. Call scv_tr_generator::begin_transaction() with the appropriate parameters as
defined in the SCV API.
c. Optional — You can apply additional parameters to specify relationships, or to
specify a begin time other than the current simulation time. For more information,
see Record phase transactions. and Specify transaction start and end times..
Example:
scv_tr_handle txh;busAddrAttr busAddr;busAddr._addr = 0x00FC01;txh =
busRead.begin_transaction(busAddr);

In this example, only the begin attribute "busAddr" is passed to ::begin_transaction().

Other parameters may be used to specify relationships or specify a begin time other than
the current simulation time. (See “Relationship in Transactions” and “Retroactive
Recording / Start and End Times”.)
4. Record special attributes

606 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
Recording SCV Transactions

Special attributes are not part of the original transaction generator. Record special
attributes as follows:
a. Define the attribute type.
b. Modify a specific transaction instance through the transaction handle using the
scv_tr_handle::record_attribute() routine.
Example:
if (status != BUS_OK) {
errorAttr err;
err.code = status;
txh.record_attribute(err);
}

Nothing prevents a design from setting the same special attribute many times during the
transaction. However, the ModelSim simulator records only the last value of the
attribute prior to the end of the transaction.
For greater detail on recording special attributes, refer to the SystemC Verification
Standard Specification, Version 1.0e.
5. Record phase transactions.
Phase transactions are unique to ModelSim. If recorded, they appear as transactions
within their parent transaction. The SCV specification does not describe this kind of
transaction, but ModelSim can record it. Any transaction may have phases, including
another phase transaction. To record phase transactions:
a. Specify mti_phase as the relation name in a call to ::begin_transaction().
You can also specify your own relation name for phases by modifying the value of
the variable ScvPhaseRelationName in the modelsim.ini from “mti_phase” to
something else, such as “child”. This variable applies to recording only; once a
phase is recorded in a WLF file, it is drawn as a phase, regardless of the setting of
this variable.
b. Provide an appropriate parent transaction handle in a call to ::begin_transaction().
6. Specify transaction start and end times.
To specify a start and/or end time for any transaction, pass the start and end times as
parameters to ::begin_transaction() and ::end_transaction(). The time must be the
current simulation time or earlier. See “Retroactive Recording / Start and End Times”
and “Start and End Times for Phase Transactions”.
7. End a transaction.
To end transactions in your SystemC code:
a. Set the value for the end attribute.

ModelSim® SE User's Manual, v10.7 607

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Recording SCV Transactions

b. Call scv_tr_generator::end_transaction(), specifying any end attributes or other

appropriate parameters as defined in the SCV API.
c. Optional — You can specify an end time other than the current simulation time. For
more information, see Specify transaction start and end times..
8. Free a transaction handle.
Transaction handles are freed automatically in SCV when the transaction handle goes
out of scope or when the transaction handle is reassigned. Global or static transactions
remain in memory for the duration of the simulation. See “Transaction Handles and
Memory Leaks” for details.
9. Specify relationships.
Provide:
• two valid transaction handles: one for the source, one for the target
• the <name> of the relation (that is, the relationship of the <source> to the <target>)
• Specify relation within an existing transaction using scv_tr_handle::add_relation()
methods. For example:
scv_tr_handle prev_txh;
scv_tr_handle txh;
busAddrAttr busAddr;
busAddr._addr = 0x00FC01;
txh = busRead.begin_transaction(busAddr);
txh.add_relation("successor", prev_txh);

• Specify relation for a new transaction by creating a relationship to a target

transaction when it begins the source transaction. For example:
scv_tr_handle prev_txh;
scv_tr_handle txh;
busAddrAttr busAddr;
busAddr._addr = 0x00FC01;
txh = busRead.begin_transaction(busAddr, "successor", prev_txh);

In both these examples, the design specifies that the current transaction is a “successor”
to the previous transaction.
Related Topics
Initializing SCV and Creating WLF Database Object
SCV API Code Example
Recording Transactions in SystemC

608 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
SCV API Code Example

SCV API Code Example

This SCV API code example is distributed with ModelSim and can be found in the following
location of your installation directory: install_dir/examples/systemc/transactions/simple
#include <systemc.h>
#include <scv.h>

typedef scv_tr_generator<int, int> generator;

SC_MODULE(tx)
{
public:
scv_tr_db *txdb; /* a handle to a transaction database */
scv_tr_stream *stream; /* a handle to a transaction stream */
generator *gen; /* a handle to a transaction generator */

SC_CTOR(tx)
{
SC_THREAD(initialize);
SC_THREAD(thread);
}

/* initialize transaction recording, create one new transaction */

/* database and one new transaction stream */
void initialize(void) {
scv_startup();
scv_tr_wlf_init();
txdb = new scv_tr_db("txdb");
stream = new scv_tr_stream("Stream", "** TRANSACTOR **", txdb);
}

/* create one new transaction */

void thread(void) {
scv_tr_handle trh;

gen = new generator("Generator", *stream, "begin", "end");

wait(10, SC_NS); /* Idle period */

trh = gen->begin_transaction(10); /* Start a transaction */
wait(2, SC_NS);
trh.record_attribute("special", 12); /* Add an attribute */
wait(2, SC_NS);
gen->end_transaction(trh, 14); /* End a transaction */
wait(2, SC_NS); /* Idle period */
}
};

ModelSim® SE User's Manual, v10.7 609

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
SCV Limitations

SC_MODULE(top)
{
public:
tx *a;
SC_CTOR(top)
{
a = new tx("tx");
}
};

SC_MODULE_EXPORT(top);

Related Topics
Initializing SCV and Creating WLF Database Object
Transaction Generators
Recording SCV Transactions
SCV Limitations
Recording Transactions in SystemC

SCV Limitations
You can record transactions in only one WLF file at a time.
The SCV API routines allow you to create and use multiple databases, however — if the chosen
database is WLF — all databases are aliased to the same WLF file. Once created, you may load
multiple WLF files that contain transactions into ModelSim for viewing and debugging.

Type Support for SystemC

The following types are not supported for SystemC transactions:

• bit-field and T* (pointer) native C/C++ types

• SystemC fixed point types (sc_fix, sc_fix_fast, sc_fixed, sc_fixed_fast, sc_ufix,
sc_ufix_fast, sc_ufixed, sc_ufixed_fast) are not supported.

CLI Debugging Command Reference

A number of CLI commands are available for debugging your transactions.

610 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
CLI Debugging Command Reference

The commands are:

add list down radix
add wave examine right
context find search
dataset clear left show
dataset save log / nolog up
dataset snapshot precision write list
delete property list write wave
describe property wave

ModelSim® SE User's Manual, v10.7 611

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Verilog and VHDL API System Task Reference

Verilog and VHDL API System Task Reference

System tasks are necessary for writing transactions for Verilog and VHDL API.
ModelSim supports the following API system tasks in Verilog and VHDL:

add_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
add_color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
add_relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
begin_transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
create_transaction_stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
delete_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
end_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
free_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

612 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
add_attribute

add_attribute
The add_attribute system task adds an attribute to a transaction.
Usage
Verilog
$add_attribute(transaction, value, attribute_name)
VHDL
add_attribute(transaction, value, attribute_name)
Arguments

Name Type Description

transaction Verilog: integer Required. Handle for the transaction to which you
VHDL: TrHandle are adding the attribute.

value object Required.

Verilog — object that is the value to be used for the
attribute.
VHDL — constant, variable, signal or generic that
is the value to be used for the attribute. Valid types:
integer, real, bit, boolean, bit_vector, std_logic,
std_logic_vector.
attribute_name string Optional for Verilog.
Required for VHDL.
The name of the attribute to be added to the
transaction.
Default: The name of the variable used for the value
parameter if it can be determined, “anonymous”
otherwise.

Return Values
Nothing

Related Topics
Recording Transactions in Verilog and VHDL
Attribute Type
Multiple Uses of the Same Attribute
Anonymous Attributes

ModelSim® SE User's Manual, v10.7 613

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
add_color

add_color
The add_color system task is used to specify color on a per-transaction basis. By using
information available to the design, this task sets the color from within the design to highlight
different kinds of commands and error conditions.
Usage
Verilog
$add_color(transaction, color)
VHDL
add_color(transaction, color)
Arguments

Name Type Description

transaction Verilog:integer Required. Handle of the transaction to be colored.
VHDL:
TrTransaction
color string Required. Specifies the desired color for transaction
which appears at debug time. Must be a known color
name (for example, red) or an RGB value in the form
“#RRGGBB”.

Return Values
Nothing

Related Topics
Customizing Color

614 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
add_relation

add_relation
The add_relation system task adds a relation from the source transaction to the target
transaction.
Usage
Verilog
$add_relation(source_transaction, target_transaction, relationship_name)
VHDL
add_relation(source_transaction, target_transaction, relationship_name)
Arguments

Name Type Description

source_transaction Verilog: integer Required. Handle to the source transaction for
VHDL: TrHandle which the relationship is to be established.

target_transaction Verilog: integer Required. Handle to the target transactions for

VHDL: TrHandle which the relationship is to be established.

relationship_name string Required. The name of the relationship.

Return Values
Nothing

Related Topics
Recording Transactions in Verilog and VHDL
Relationship in Transactions

ModelSim® SE User's Manual, v10.7 615

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
begin_transaction

begin_transaction
The begin_transaction system task begins a transaction on the specified stream.
Note
Save the transaction handle for use in other transaction API calls. Use $begin_transaction()
or begin_transaction() to start all transactions. The optional fourth parameter enables you to
specify a parent transaction, making the new transaction a phase transaction of the parent.

Usage
Verilog
$begin_transaction(stream, transaction_name, begin_time, parent_transaction)
VHDL
begin_transaction(stream, transaction_name, begin_time, parent_transaction)
Arguments

Name Type Description

stream Verilog:integer Required. Handle to the previously created
VHDL: TrHandle stream.

transaction_name string Required. Name of the transaction to begin.

Name must be a legal C identifier. White spaces
must be used with escaped or extended
identifiers.1See Names of Streams and
Substreams for further details on legal names.
begin_time time Optional.
The absolute simulation time that the
transaction will begin.
Default: The current simulation time.
parent_transaction Verilog:integer Optional.
VHDL: TrHandle Handle to an existing transaction that is the
parent to the new one. The new transaction will
be a phase transaction of the parent.
Default: NULL for Verilog, 0 for VHDL.
1. If you are using closed kit OVM components, and your <transaction_name> contains a non-extended or
escaped white space, you may receive an OVM warning message to the effect that your name is not a legal
c identifier name, and that the name has been changed to a legal name. For example: # OVM_WARNING
@ xxxx: reporter [ILLEGALNAME] 'transaction name' is not a legal c identifier name, changed to
'transaction_name'. Streams must be named as a legal c identifier.

616 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
begin_transaction

Return Values

Name Type Description

transaction Verilog: integer The handle to the newly started transaction.
VHDL: TrHandle

Description
A handle returned by $begin_transaction() or begin_transaction() will be non-zero unless there
is an error. The error is reported to the transcript.

Related Topics
Recording Transactions in Verilog and VHDL
The Life Cycle of a Transaction
Valid Verilog Handles

ModelSim® SE User's Manual, v10.7 617

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
create_transaction_stream

create_transaction_stream
The create_transaction_stream system task creates a transaction stream that you can use to
record transactions.
Note
Save the stream handle for use in other transaction API calls.

Usage
Verilog
$create_transaction_stream(stream_name, stream_kind)
VHDL
create_transaction_stream(stream_name, stream_kind)
Arguments

Name Type Description

stream_name string Required. The name of the stream to be created.
For OVM designs, the string specified must adhere to
the following format:
{"..",get_full_name(),".","<your_name>"}
The stream name should not match that of any object in
the parent region for the stream.
stream_kind string Optional.
The kind of stream to be created.
Default is “Stream”.
The kind can be any string and it is not interpreted. It is
stored in the WLF file.

Return Values

Name Type Description

stream Verilog:integer Handle to the created stream.
VHDL: TrHandle

Description
A handle returned by $create_transaction_stream() or create_transaction_stream() will be non-
zero unless there is an error. The error is reported to the transcript.

618 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
create_transaction_stream

Related Topics
Recording Transactions in Verilog and VHDL
About Transaction Streams
Names of Streams and Substreams
Stream Logging
Valid Verilog Handles

ModelSim® SE User's Manual, v10.7 619

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
delete_transaction

delete_transaction
The delete_transaction system task removes a transaction from the transaction database. The
transaction is not recorded in the WLF file.
Usage
Verilog
$delete_transaction(transaction)
VHDL
delete_transaction(transaction)
Arguments

Name Type Description

transaction Verilog:integer Required. Handle for the transaction which you
VHDL: TrHandle are deleting.

Return Values
Nothing

Related Topics
Recording Transactions in Verilog and VHDL
Valid Verilog Handles

620 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording and Viewing Transactions
end_transaction

end_transaction
The end_transaction system task ends the specified transaction.
Note
Ending the transaction simply sets the end-time for the transaction and is performed only
once. However, if free is not specified, the transaction handle is still valid for use in
recording relations and attributes until a call to $free_transaction() or free_transaction() occurs.

Usage
Verilog
$end_transaction(transaction, end_time, free)
VHDL
end_transaction(transaction, end_time, free)
Arguments

Name Type Description

transaction Verilog:integer Required. Handle to the name of the transaction
VHDL: TrHandle being ended.

end_time time Optional. The absolute simulation time that the

transaction will end.
Default: The current simulation time.
free Verilog: integer Optional. If this argument is non-zero (Verilog) or
VHDL: boolean true (VHDL), the memory allotted for this
transaction will be freed. This is for convenience, and
is equivalent to a call to $free_transaction() or
free_transaction() for this transaction.
Use only when no more attributes will be recorded
for this transaction and no relations will be made for
this transaction.
Default: zero (Verilog) or false (VHDL) — do not
free memory.

Return Values
Nothing

Related Topics
Recording Transactions in Verilog and VHDL
The Life Cycle of a Transaction

ModelSim® SE User's Manual, v10.7 621

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
free_transaction

free_transaction
The free_transaction system task frees a transaction and allows the memory allotted for this
transaction to be freed. The handle will no longer be valid. Attributes can no longer be recorded
for the transaction. Relations can no longer be made with the transaction.
Tip
You must free all transaction handles in your design. This is a requirement specific to
Verilog and VHDL recording. If you do not free a handle, a memory leak occurs in the
simulation.

Usage
Verilog
$free_transaction(transaction)
VHDL
free_transaction(transaction)
Arguments

Name Type Description

transaction Verilog:integer Handle to the transaction to be freed.
VHDL: TrHandle

Return Values
Nothing

Related Topics
The Life Cycle of a Transaction

622 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 12
Verifying Designs with
Questa Verification IP Library Components

This chapter provides a brief introduction to Questa Verification IP transactions in ModelSim,

and discusses additional features of the ModelSim GUI available when simulating a model that
includes Questa Verification IP(s).
Note
The functionality described in this chapter requires an additional license feature for
ModelSim SE. Refer to “License Feature Names” in the Installation and Licensing Guide
for more information, or contact your Mentor Graphics sales representative.

What is Questa Verification IP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

What is a Questa Verification IP Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Questa Verification IP Transaction Viewing in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . 626
Questa Verification IP Transaction Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

What is Questa Verification IP?

A Questa Verification IP is a model used to verify a protocol or interface. These models bridge
the gap between RTL, TLM, and system-level verification by using a hierarchy of transactions
to create a link between different TLM and RTL abstraction levels. Questa Verification IPs
include stimulus generation, reference checking and coverage measurements and are available
for popular protocols and standard interfaces as part of the Questa Verification IP Library.
For more detailed information on Questa Verification IPs and the Questa Verification IP
Library, including which library components are available, as well as how to load and run a
model using a Questa Verification IP, refer to the “Questa Verification IP Library Data Book”,
available from Support Center.

What is a Questa Verification IP Transaction?

A Questa Verification IP transaction is unique in that it represents communication at multiple
levels of abstraction.

ModelSim® SE User's Manual, v10.7 623

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
What is a Questa Verification IP Transaction?

Tip
: Transactions in a Questa Verification IP are quite distinct from SystemC or SystemVerilog
transactions in the ModelSim tool. In this chapter, any occurrence of the word “transaction”
refers to Questa Verification IP transactions exclusively, unless otherwise specified.

To illustrate, consider a hypothetical Questa Verification IP transaction shown in Figure 12-1.

This transaction contains a single “Transfer” transaction representing a read or a write.
However, the transaction also references lower level transactions, which separately represent
the address and data transfers. It is also referenced by a higher level transaction, “Burst
Transfer.” Note that “Burst Transfer” can consist of multiple “Transfer” transactions. Signals
are always represented at the lowest level of abstraction.

Figure 12-1. Questa Verification IP Transaction at Different Levels of

Abstraction

624 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
What is a Questa Verification IP Transaction?

Questa Verification IP Transaction Relationships

Where more than one level of abstraction exists, a “relationship” exists between the different
levels.

In the example shown in Figure 12-1, a “Transfer” transaction is related to the “Address” and
“Data” transactions that communicate the address and data information for that transfer. These
transactions in turn are related to the individual signals which communicate the equivalent
information across the bus. Questa Verification IPs maintain these relationships, allowing for
simulation and debugging across the different levels of abstraction.

The term “parent” describes a related transaction at a higher level of abstraction, and “child”
describes a related transaction or signal at a lower level of abstraction. Each transaction may
have many related child or parent transactions. In Figure 12-1, the “Transfer” transaction has
two children: a “Address” transaction and a “Data” transaction. It also has one parent: “Burst
Transfer” transaction. Each Burst Transfer transaction can have multiple “Transfer”
transactions as children.

Related Topics
Questa Verification IP Arrays in the Wave Window
Questa Verification IP Objects in the GUI
Color and Questa Verification IP Arrays in Wave Window
Arrays in Questa Verification IP

ModelSim® SE User's Manual, v10.7 625

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Viewing in the GUI

Questa Verification IP Transaction Viewing in

the GUI
Transactions can be viewed in several GUI windows.
• Wave window - must be logged during a simulation run (see Viewing Questa
Verification IP Transactions in the Wave Window)
• Objects window - visible when you select an instance of the interface in Questa
Verification IP in the Structure (sim) window (see Viewing Questa Verification IP
Transactions in Objects Window)
• List window - must be logged during a simulation run (see Viewing Questa Verification
IP Transactions in List Window)
Questa Verification IP Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Arrays in Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Viewing Questa Verification IP Transactions in the Wave Window . . . . . . . . . . . . . . . 629
What the Colors Mean in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Appearance of Concurrent Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . 632
Questa Verification IP Arrays in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Color and Questa Verification IP Arrays in Wave Window . . . . . . . . . . . . . . . . . . . . . . 634
Viewing Questa Verification IP Transactions in Objects Window . . . . . . . . . . . . . . . . . 634
Viewing Questa Verification IP Transactions in List Window . . . . . . . . . . . . . . . . . . . . 636

Questa Verification IP Objects in the GUI

The display of Questa Verification IP transactions in ModelSim differs from “normal”
(SystemC or SystemVerilog) transactions. Designs containing Questa Verification IPs can
display transactions of many different object kinds.
As a Questa Verification IP user — someone viewing and analyzing the results from the
simulation of an OVM/UVM design — you are most interested in only three kinds of objects:
MVC_Transaction, MVC_Message and MVC_Stripe. All other objects, listed in the shaded
cells in Table 12-1, represent internal logic and are most relevant to a Questa Verification IP
developer (someone designing a Questa Verification IP library).

The MVC_Message and MVC_Transaction objects represent higher level transactions (see
Figure 12-1 for an example) that can be related to other MVC_Stripe, MVC_Message and
MVC_Transaction objects. MVC_Stripe objects are always the lowest level transaction, having
a direct relationship to a set of signals.

626 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Objects in the GUI

Questa Verification IP objects can be viewed in the Wave window, where they are drawn as
transaction streams or signals. Table 12-1 includes a description of the various objects and how
they appear.
Table 12-1. Questa Verification IP Objects
Object Kind and Icon Definition Appearance in GUI
MVC_Transaction A type of transaction representing multi- As transaction streams.
directional communication between one or Can have sub-streams
more devices across an interface or bus. for to show concurrent
example, a combined request and response. (overlapping or
pipelined) transactions.
MVC_Message A type of transaction representing one-way or As transaction streams.
broadcast communication from one device to Can have sub-streams
one or more devices on an interface or bus. for to show concurrent
example, a request. (overlapping or
pipelined) transactions.
MVC_Stripe A type of transaction representing a single As transaction streams.
clock cycle of activity on one or more signals
or wires originating from a single device.
Unlike MVC_Message or MVC_Transaction,
it must always have a duration.
MVC_ExternalMethod A type of method or task within the Questa As transaction streams.
Verification IP that represents a call to one of
the transactions from outside the Questa
Verification IP.
MVC_Activity A method or task within the Questa As transaction streams.
Verification IP.
MVC_TimelessActivity A method or task within the Questa VIP that As transaction streams.
completes in zero time, zero deltas.
MVC_Function A function within the Questa VIP. Completes As transaction streams.
in zero time, zero deltas.
MVC_MapFunction An object within the Questa VIP. Like a As transaction streams.
function, but with two sets of parameters and
forward and reverse algorithms specified.
MVC_Label A tag on a code statement within the Questa As transaction streams.
VIP. Can be used to monitor execution of that
statement.

Related Topics
Questa Verification IP Transaction Viewing in the GUI
Arrays in Questa Verification IP

ModelSim® SE User's Manual, v10.7 627

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Arrays in Questa Verification IP

Arrays in Questa Verification IP

Questa Verification IP objects can be declared as arrays in specific protocols. Questa
Verification IP arrays are created by the developer, solely for the sake of convenience, and do
not have any effect on the behavior of the objects themselves. In other words, an element of an
array is not aware of, nor is it affected by, any other element of the same array.
Arrays of Questa Verification IP objects appear much like other arrays in the GUI. When the
array is made from a stream-like object (such as an MVC_Stripe) each leaf element of the array
is a fully unique and independent stream. As such, each element can have different attributes
and can have any number of active sub-streams at any time during simulation.

Questa Verification IP arrays can have multiple dimensions. For example, one component
might contain a two-by-two array of MVC_Message objects. This results in a single object in
the GUI. Consider the following array in the objects window (as shown in Figure 12-2).
Selecting the array’s expand button reveals the two rows of the array. The “Kind” field for the
array displays the Questa Verification IP kind (“MVC_Message”) and the size of the array
(“[2][2]”).

Figure 12-2. Arrays in Objects Window

The level below the array (txStreamArray) is that of the two sub-arrays (0 and 1). These are the
rows of the parent array, each of which has the correct name for an array element, and its kind
field indicates the size of the sub-array. Expanding the sub-arrays reveals the leaf streams of the
array, whose “Kind” fields do not contain any index values. Expand buttons on “leaf” streams
indicate that they have sub-streams or attributes.

Related Topics
Questa Verification IP Objects in the GUI
Questa Verification IP Arrays in the Wave Window
Color and Questa Verification IP Arrays in Wave Window

628 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Viewing Questa Verification IP Transactions in the Wave Window

Viewing Questa Verification IP Transactions in the

Wave Window
The advantage of viewing Questa Verification IP transactions in the Wave window is that it
allows you to easily view the relationships between transactions and the signals/wires that
comprise them.
Prerequisites
• Before you can view Questa Verification IP objects in the ModelSim GUI, you must
have loaded the design containing the library protocols. For information on how to hook
up the protocols to your design, refer to the “Questa Verification IP Library Data Book”
available from Support Center.
• Before you can view transaction objects in the Wave window, log the Questa
Verification IP objects during a simulation run.
• General viewing instructions and conventions applicable to all transactions
(SystemVerilog or SystemC as well as Questa Verification IP) can be found in the
section “Viewing Transactions in the Wave Window”.
Procedure
1. Ensure the model containing the Questa Verification IP protocol is loaded. For example:
vsim top

2. Enable logging for the desired object(s). Objects must be explicitly logged for
transaction viewing. Logging the object(s) results in the objects being recorded in the
.wlf file, allowing them to be viewed post-simulation. To log Questa Verification IP
objects, you can:
• Add transactions to the Wave window by dragging and dropping them into the
window. Alternatively, you can use a add wave CLI command, such as:
add wave /top/interface/read_id

• Use the log command, such as:

log /top/interface/read_id

• By default, Questa Verification IP transactions are ignored with normal wildcard

usage. To enable wildcard matching for all transactions, use the -mvcall switch, such
as:
add wave -mvcall -r /*
log -mvcall -r /*

ModelSim® SE User's Manual, v10.7 629

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Viewing Questa Verification IP Transactions in the Wave Window

• To log all OVM/UVM sequence Questa Verification IP transactions (for example,

only the transactions in the Questa Verification IP protocol stack with sequence
items) use the -mvcovm switch:
add wave -mvcovm -r /*
log -mvcovm -r /*

3. Run simulation on a design containing transactions. For example:

run -all

4. Within the Wave window, navigate to the portion of the design containing the Questa
Verification IP component or protocol.
a. Additional Steps for the viewing of completed transactions
5. Additional Steps for the viewing of completed transactions
By default, only recognized transactions that have become used as legal protocol are
logged, which may prevent the transaction instances of interest from being logged soon
enough to observe an issue. To enable the logging of transaction instances that have
been recognized as completed (which may later become used or deleted), please follow
these additional steps:
a. Add the required transaction to the Wave window.
b. Right-click the transaction name.
You can select any number of transaction streams to enable the logging of completed
transaction instances for those additional transaction streams.
c. Select “Transaction Properties” from the pop-up menu.
d. Select the “Questa VIP Logging” tab.
e. Click the “Deletion Logging Enabled” box to display deleted transaction instances.
f. Click the “State Logging Enabled” box to log the State History of transaction
instances.
g. Click OK.
h. Run the simulation - all completed transactions now appear on the Wave window.
Results
Transactions within Questa Verification IP components appear in the Wave window, as shown
in Table 12-3. For information on the colors of transactions, see “What the Colors Mean in the
Wave Window”.

630 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
What the Colors Mean in the Wave Window

Figure 12-3. Questa Verification IP Transactions in Wave Window

What the Colors Mean in the Wave Window

When viewing transactions within a Questa Verification IP, the color of the transaction object
indicates what caused it to exist.
The possible colors and their meaning are shown in Table 12-2. These colors are used as the fill
color for a transaction, or to highlight a signal.
Table 12-2. Questa Verification IP Colors and Causation
Color Status Causal relationships to other transaction types
Sent Represents unidirectional communication. Created by
the Questa Verification IP as a result of a request or
call to start this MVC_Message or MVC_Stripe. Can
generate lower level activity (that is, cause lower
level transactions or signal activity).

ModelSim® SE User's Manual, v10.7 631

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Appearance of Concurrent Transactions in the Wave Window

Table 12-2. Questa Verification IP Colors and Causation (cont.)

Color Status Causal relationships to other transaction types
Activated Represents bidirectional communication. Created by
the Questa Verification IP as a result of a request or
call to start this MVC_Transaction. Can generate and
recognize lower level activity (that is, allow and pick-
up attribute values from lower level transactions or
signal activity).
Recognized Created by the Questa Verification IP due to activity
at a lower level of abstraction. Can recognize lower
level activity.
Generated Created by the Questa Verification IP as a result of
activity at a higher level of abstraction. Can generate
lower level activity.
Genact Created by the Questa Verification IP as a result of a
higher level MVC_Transaction. Can generate and
recognize lower level activity.
Error Represents an error condition for that Questa
Verification IP object.

For example, in Figure 12-3, the color shown in the transaction objects allows us to determine
that a read transaction was started by a TLM master. This resulted in the Questa Verification IP
generating a setup_phase transaction and a number of xxx_cycle messages, which in turn
resulted in some pin level activity. This caused an RTL slave to issue a response which was
recognized by the Questa Verification IP up into a response_phase message (through the
xxx_cycle messages), and finally back into the read transaction.

This basic color scheme is modified slightly for arrays of Questa Verification IP objects. See
“Color and Questa Verification IP Arrays in Wave Window” for more information.

Appearance of Concurrent Transactions in the

Wave Window
Multiple transactions recorded on a single stream at one time are known as concurrent
transactions. They appear as overlapping in the Wave window.
An example of the overlapping of concurrent transactions is shown in Figure 12-4.

632 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Arrays in the Wave Window

Figure 12-4. Concurrent Transactions Overlapping in Wave Window

Related Topics
About Transaction Streams
Questa Verification IP Transaction Debug
What is a Questa Verification IP Transaction?

Questa Verification IP Arrays in the Wave Window

Questa Verification IP protocols may create arrays of streams with one or more dimensions. In
the wave window, these behave much like other array objects. Expanding the parent reveals the
next level of detail and each sub-level name is the appropriate index value.
Figure 12-5 shows the expansion of a two-by-two array of message streams. It reveals that each
level of the array expands to reveal the details below, as with other arrays. The expansion of the
leaf Stream[1][1] reveals the attributes of that stream element. See “Color and Questa
Verification IP Arrays in Wave Window” for information on the effect that arrays have on the
Questa Verification IP object color scheme.

Figure 12-5. Questa Verification IP Array (2X2) in Wave Window

ModelSim® SE User's Manual, v10.7 633

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Color and Questa Verification IP Arrays in Wave Window

Color and Questa Verification IP Arrays in Wave

Window
Questa Verification IP stream arrays slightly modify the generic color scheme. This section
explains how they are different.
Examine Figure 12-6. Errors occur on the last three instances on stream txStream[1][0], which
are drawn in red, as expected. This color extends upward to the parent array txStream[1] and its
parent, txStream. This enables errors to be spotted easily when the array has not been expanded.

Figure 12-6. Color of Arrays

You can see that all of the other instances on the four “leaf” streams are either activated (purple)
or generated (green) (see Table 12-2 for color descriptions).

Now, these colors are NOT reflected up to the parent arrays: the parent arrays are black. This is
due to the fact that it is typical to have paired elements in an array to separate outgoing and
incoming traffic, and it is not feasible to mix the colors symbolizing this pairing in any
straightforward way. Thus, arrays are always drawn in black, unless an error occurs in one or
more element.

Related Topics
What the Colors Mean in the Wave Window
Questa Verification IP Transaction Debug

Viewing Questa Verification IP Transactions in

Objects Window
Use the Objects window to browse the available objects in order to log them or add them to the
Wave window.

634 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Viewing Questa Verification IP Transactions in Objects Window

Prerequisites
Before you can view Questa Verification IP objects in the ModelSim GUI, you must have
loaded the design containing the library protocols. For information on how to hook up the
protocols to your design, refer to the “Questa Verification IP Library Data Book” available from
Support Center.

Procedure
1. Ensure the model containing the Questa Verification IP protocol is loaded. For example:
vsim top

2. With the Objects window open (View > Objects), select the top level SystemVerilog
interface in the Questa Verification IP.
Results
The objects in that interface appear in the Objects window, similar to those in Figure 12-7.
Figure 12-7. Questa Verification IP Objects in Objects Window

ModelSim® SE User's Manual, v10.7 635

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Viewing Questa Verification IP Transactions in List Window

Related Topics
Viewing Questa Verification IP Transactions in the Wave Window
Questa Verification IP Transaction Debug
Viewing Questa Verification IP Transactions in List Window

Viewing Questa Verification IP Transactions in List

Window
Use the List window to view the values of all selected design elements at each time or delta
advance. The list window allows for the easy creation of tabular reports for transactions.
Prerequisites
Before you can view Questa Verification IP objects in the ModelSim GUI, you must have
loaded the design containing the library protocols. For information on how to hook up the
protocols to your design, refer to the “Questa Verification IP Library Data Book” available from
Support Center.

Procedure
1. Ensure the model containing the Questa Verification IP protocol is loaded. For example:
vsim top

2. With the List window open (View > List), select the top level SystemVerilog interface
in the Questa Verification IP.
Results
The objects in that interface appear in the List window, similar to those in Figure 12-8.
Figure 12-8. Questa Verification IP Objects in List Window

636 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Viewing Questa Verification IP Transactions in List Window

When transactions are present in the list window, rows are written any time a transaction’s state
changes:
• when a transaction starts or ends
• when any attribute changes state
In Figure 12-8 above, there is an internal attribute (not shown) changing state and causing extra
rows to be drawn.
Questa Verification IP arrays display the value of every element.
Related Topics
Viewing Questa Verification IP Transactions in the Wave Window
Questa Verification IP Transaction Debug
Viewing Questa Verification IP Transactions in Objects Window

ModelSim® SE User's Manual, v10.7 637

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Debug

Questa Verification IP Transaction Debug

Debugging of Verification IP transactions can be Questa Verification IP objects appear as
transactions or signals in the Wave window, depending on the type of the object being
displayed.
For a list of object types, see Table 12-1 on page 627. The colors of transactions that appear in
the Wave window are defined in Table 12-2 on page 631.

Debugging Using Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

Questa Verification IP Transaction Details in Transaction View Window . . . . . . . . . . 641
Updating Contents of the Transaction Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Debugging Using Relationships

Relationships for Questa Verification IP transaction objects can be viewed by selecting them in
the usual way, by clicking on an object in the Wave window. As well as highlighting related
transactions, selecting a single instance of a Questa Verification IP object also highlights any
related signal activity. Signals are highlighted for only the period of time that they are taking
part in the selected transaction. You can also select a signal to highlight the transactions that are
using that signal at that specific time.

638 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Debugging Using Relationships

Figure 12-9. Viewing Questa Verification IP Relationships

This simple way of viewing relationships between the different transaction abstraction levels
and the signals allows very rapid movement between levels of abstraction when debugging. For
example, on an interface that allows multiple outstanding requests, you could select the data
signal at a certain point in time, and immediately see the transaction that the data is part of. This
provides you with information such as the address, requesting master, burst type, and so forth,
without needing to carefully trace back along the signals.

Note
IMPORTANT — For the highlighting of Transaction/Wire relationships to function
properly, all Questa Verification IP transactions in the protocol hierarchy (from the top level
transactions down to the stripes) must be logged to WLF (as described in the section Viewing
Questa Verification IP Transactions in the Wave Window).

Transaction viewing and navigation for Questa Verification IP transactions are the same as for
any transaction in ModelSim.

ModelSim® SE User's Manual, v10.7 639

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Debugging Using Relationships

Related Topics
Viewing Transactions in the Wave Window
Selecting Transactions or Streams in the Wave Window
What the Colors Mean in the Wave Window

640 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Details in Transaction View Window

Questa Verification IP Transaction Details in

Transaction View Window
The Transaction window displays information about a selected Questa Verification IP
transaction instance. The window has an upper pane, called the main pane, and a lower pane
with up to three tabs: the Data tab, the Relations tab, and the State History tab (if State History
Logging is enabled).
The Transaction View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
The Transaction Stream Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

ModelSim® SE User's Manual, v10.7 641

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Details in Transaction View Window

The Transaction View Window

To access:
• Double-click a Questa Verification IP transaction instance in the Wave window, or
• Select a transaction instance in the Wave window, and right-click > Transaction View
Use the Transaction View window to look at the details of a transaction.
Description
The Transaction View window opens with the Data tab open in the lower pane, as shown in
Figure 12-10.

Figure 12-10. Transaction Window - Data Tab

Objects
• GUI elements
o Main Pane — The main pane displays the Questa Verification IP instance content,
consisting of items and values displayed in two columns. The items are:
• Type — The type of Questa Verification IP transaction instance.
• Name — The name of the transaction instance.
• TQ id— A serial number for instances on the same stream. (This is not the same
as the UID, which is a unique ID assigned by the ModelSim simulator).
• Main State — Identifies how the transaction instance came into existence.
• Sub State — Identifies the phase of life the instance has reached.

642 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Details in Transaction View Window

• Start Time — Start time of the transaction instance.

• End Time — End time of the transaction instance.
o Data Tab — The “Data” tab contains all Questa Verification IP parameter attributes
and their values. These are presented in a tree format (in the same style as in the
Objects window).
o Relations Tab —The “Relations” tab contains a list of related instances to the
selected instance. These are categorized by relationship types of ‘Enabling parents’
and ‘Enabled children’, and are presented in a tree format. Each instance includes its
general data (type, name, TQ_id, and so on — see parameters listed in “Main Pane”
for details).
Double-clicking a ‘parent’ or ‘child’ relation opens a new Transaction View window
to display its Data and Relations, and so on.
o State History Tab — The State History tab for a transaction instance appears when
the “State History Logging” is enabled for the transaction stream (see additional
steps of the Viewing Questa Verification IP Transactions in the Wave Window). The
State History of a transaction instance records the internal states of the Questa
Verification IP for that instance. This history can be useful for debugging a Questa
Sim 50000 series error, but requires some knowledge of the internal concepts and
terminology for a Questa Verification IP. See Questa Verification IP Errors for more
details.

Note
The “State History” for a transaction stream should only be enabled to assist in
the debug of QuestaSim 50000 series errors due to the additional consumption of
simulation resources when enabled.

Related Topics
Viewing Transactions in the Wave Window
Selecting Transactions or Streams in the Wave Window
The Transaction Stream Window

ModelSim® SE User's Manual, v10.7 643

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Questa Verification IP Transaction Details in Transaction View Window

The Transaction Stream Window

To access:
• Select a Questa Verification IP transaction stream name in the Wave window, and right-
click > View > Transactions…
Use the Transaction Stream window to look at the details of an individual transaction stream.
Description
The Transaction Stream window opens with the Instances tab open in the lower pane.

Objects
• GUI elements
o Main Pane — The main pane displays the Questa Verification IP transaction stream
content, consisting of items and values displayed in two columns. The items are:
• Name — The name of the transaction stream.
• Count — The number of transaction instances in the stream.
o Instances Tab — The lower pane contains a list of instances, and their parameter
values that have occurred for the transaction stream. The parameter values displayed
for the transaction stream are:
• Start Time - Start time of the transaction instance.
• End Time - End time of the transaction instance.
• Tag - The name of the transaction stream instance.
• TQ_id - A serial number for instances on the same stream. (This is not the same
as the UID, which is a unique ID assigned by the ModelSim simulator).
• Main State - Identifies how the transaction instance came into existence.
• Sub State - Identifies the phase of life the instance has reached.
• Trace_state - The greatest severity trace message reported for the instance from
“none”, “continue”, note”, “warning”, “error” and “halt”.
• Trace_num - QuestaSim 60000 series error message number reported for a
Questa Verification IP protocol. For more information, see “Accessing 60000
Series Error Documentation”.
• Attribute data for all the transaction instances from the stream. You can save this
attribute data to a file named <stream_name>.csv by selecting File > Save.
Related Topics
Viewing Transactions in the Wave Window

644 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verifying Designs with Questa Verification IP Library Components
Updating Contents of the Transaction Window

Selecting Transactions or Streams in the Wave Window

The Transaction View Window

Updating Contents of the Transaction Window

You can update contents of the Transaction window, including transaction name in the label of
the window, with data from a new instance.
Procedure
1. Select the Questa Verification IP transaction instance/stream in Wave window.
2. Drag and drop the instance into either the upper pane or lower pane of an open
Transaction window.
Results
Figure 12-11 shows details for instance /high_level_unit/dan/xtor/t_top_A2B, and lists the
relations of that instance.
Figure 12-11. Transaction Window - Relations Tab

ModelSim® SE User's Manual, v10.7 645

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verifying Designs with Questa Verification IP Library Components
Updating Contents of the Transaction Window

Related Topics
Viewing Transactions in the Wave Window
Selecting Transactions or Streams in the Wave Window
Questa Verification IP Objects in the GUI

646 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 13
Recording Simulation Results With Datasets

This chapter describes how to save the results of a ModelSim simulation and use them in your
simulation flow. In general, any recorded simulation data that has been loaded into ModelSim is
called a dataset.
One common example of a dataset is a wave log format (WLF) file. In particular, you can save
any ModelSim simulation to a wave log format (WLF) file for future viewing or comparison to
a current simulation. You can also view a wave log format file during the currently running
simulation.

A WLF file is a recording of a simulation run that is written as an archive file in binary format
and used to drive the debug windows at a later time. The files contain data from logged objects
(such as signals and variables) and the design hierarchy in which the logged objects are found.
You can record the entire design or choose specific objects.

A WLF file provides you with precise in-simulation and post-simulation debugging capability.
You can reload any number of WLF files for viewing or comparing to the active simulation.

You can also create virtual signals that are simple logical combinations or functions of signals
from different datasets. Each dataset has a logical name to indicate the dataset to which a
command applies. This logical name is displayed as a prefix. The current, active simulation is
prefixed by “sim:” WLF datasets are prefixed by the name of the WLF file by default.

Figure 13-1 shows two datasets in the Wave window. The current simulation is shown in the top
pane along the left side and is indicated by the “sim” prefix. A dataset from a previous
simulation is shown in the bottom pane and is indicated by the “gold” prefix.

ModelSim® SE User's Manual, v10.7 647

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets

Figure 13-1. Displaying Two Datasets in the Wave Window

The simulator resolution (see Simulator Resolution Limit (Verilog) or Simulator Resolution
Limit for VHDL) must be the same for all datasets you are comparing, including the current
simulation. If you have a WLF file that is in a different resolution, you can use the wlfman
command to change it.

Saving a Simulation to a WLF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

Dataset Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Managing Multiple Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Collapsing Time and Delta Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Virtual Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662

648 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Saving a Simulation to a WLF File

Saving a Simulation to a WLF File

If you add objects to the debugging windows in the graphic interface, or log objects with the log
command, the results of each simulation run are automatically saved to a WLF file called
vsim.wlf in the current directory.
You can also log variables and values to a WLF file with the $wlfdumpvars() Verilog system
task.

Note
You can disable the creation of a WLF file with the vsim +questa_mvc_core+wlf_disable
command.

If you then run a new simulation in the same directory, the vsim.wlf file is overwritten with the
new results.

If you want to save the WLF file and not have it be overwritten, select the Structure tab and then
select File > Save. Or, you can use the -wlf <filename> argument to the vsim command or the
dataset save command.

Also, datasets can be saved at intervals, each with unique filenames, with the dataset snapshot
command. See “Saving at Intervals with Dataset Snapshot” for GUI instructions.

Note
If you do not use either the dataset save or dataset snapshot command, you must end a
simulation session with a quit or quit -sim command in order to produce a valid WLF file.
If you do not end the simulation in this manner, the WLF file will not close properly, and
ModelSim may issue the error message “bad magic number” when you try to open an
incomplete dataset in subsequent sessions. If you end up with a damaged WLF file, you can try
to repair it using the wlfrecover command.

Saving at Intervals with Dataset Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

Saving Memories to the WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
WLF File Parameter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Limiting the WLF File Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Opening Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654

Saving at Intervals with Dataset Snapshot

Dataset Snapshot lets you periodically copy data from the current simulation WLF file to
another file. This is useful for taking periodic “snapshots” of your simulation or for clearing the
current simulation WLF file based on size or elapsed time.

ModelSim® SE User's Manual, v10.7 649

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Saving at Intervals with Dataset Snapshot

Procedure
1. Log objects of interest with the log command.
2. Select the Wave window to make it active.
3. Select Tools > Dataset Snapshot to open the Dataset Snapshot dialog box
(Figure 13-2).
4. Select Enabled for the Dataset Snapshot State.
5. Set the simulation time or the wlf file size.
6. Choose whether the snapshot will contain only data since previous snapshot or all
previous data.
7. Designate the snapshot directory and file.
8. Choose whether to replace the existing snapshot file or use an incrementing suffix if a
file by the same name exists.
9. Click the OK button to create the dataset snapshot.

650 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Saving Memories to the WLF

Figure 13-2. Dataset Snapshot Dialog Box

You can customize the datasets either to contain all previous data, or only the data since
the previous snapshot. You can also set the dataset to overwrite previous snapshot files,
or increment the names of the files with a suffix.

Saving Memories to the WLF

By default, memories are not saved in the WLF file when you issue a “log -r /*” command.
Procedure
1. To get memories into the WLF file you will need to explicitly log them. For example:
log /top/dut/i0/mem

ModelSim® SE User's Manual, v10.7 651

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
WLF File Parameter Overview

2. It you want to use wildcards, then you will need to remove memories from the
WildcardFilter list. To see what is currently in the WildcardFilter list, use the following
command:
set WildcardFilter

If “Memories” is in the list, reissue the set WildcardFilter command with all items in the
list except “Memories.” For details, refer to Using the WildcardFilter Preference
Variable in the Command Reference Manual.

Note
For post-process debug, you can add the memories into the Wave or List windows
but the Memory List window is not available.

WLF File Parameter Overview

There are a number of WLF file parameters that you can control via the modelsim.ini file or a
simulator argument.
This section summarizes the various parameters.
Table 13-1. WLF File Parameters
Feature modelsim.ini modelsim.ini vsim argument
Default
WLF Cache Size WLFCacheSize = <n> 0 (no reader cache)
WLF Collapse WLFCollapseModel = 0|1|2 1 (-wlfcollapsedelta) -nowlfcollapse
Mode -wlfcollapsedelta
-wlfcollapsetime
WLF Compression WLFCompress = 0|1 1 (-wlfcompress) -wlfcompress
-nowlfcompress
WLF Delete on Quit WLFDeleteOnQuit = 0|1 0 (-wlfdeleteonquit) -wlfdeleteonquit
-nowlfdeleteonquit
WLF File Lock WLFFileLock = 0|1 0 (-nowlflock) -wlflock
-nowlflock
WLF File Name WLFFilename=<filename> vsim.wlf -wlf <filename>
WLF Index WLFIndex 0|1 1 (-wlfindex)
WLF Optimization1 WLFOptimize = 0|1 1 (-wlfopt) -wlfopt
-nowlfopt
WLF Sim Cache WLFSimCacheSize = <n> 0 (no reader cache)
Size
WLF Size Limit WLFSizeLimit = <n> no limit -wlfslim <n>

652 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
WLF File Parameter Overview

Table 13-1. WLF File Parameters (cont.)

Feature modelsim.ini modelsim.ini vsim argument
Default
WLF Time Limit WLFTimeLimit = <t> no limit -wlftlim <t>
1. These parameters can also be set using the dataset config command.

• WLF Cache Size— Specify the size in megabytes of the WLF reader cache. WLF reader
cache size is zero by default. This feature caches blocks of the WLF file to reduce
redundant file I/O. If the cache is made smaller or disabled, least recently used data will
be freed to reduce the cache to the specified size.
• WLF Collapse Mode—WLF event collapsing has three settings: disabled, delta, time:
o When disabled, all events and event order are preserved.
o Delta mode records an object's value at the end of a simulation delta (iteration) only.
Default.
o Time mode records an object's value at the end of a simulation time step only.
• WLF Compression— Compress the data in the WLF file.
• WLF Delete on Quit— Delete the WLF file automatically when the simulation exits.
Valid for current simulation dataset (vsim.wlf) only.
• WLF File Lock — Control overwrite permission for the WLF file.
• WLF Filename— Specify the name of the WLF file.
• WLF Indexing— Write additional data to the WLF file to enable fast seeking to specific
times. Indexing makes viewing wave data faster, however performance during
optimization will be slower because indexing and optimization require significant
memory and CPU resources. Disabling indexing makes viewing wave data slow unless
the display is near the start of the WLF file. Disabling indexing also disables
optimization of the WLF file but may provide a significant performance boost when
archiving WLF files. Indexing and optimization information can be added back to the
file using wlfman optimize. Defaults to on.
• WLF Optimization— Write additional data to the WLF file to improve draw
performance at large zoom ranges. Optimization results in approximately 15% larger
WLF files.
• WLFSimCacheSize— Specify the size in megabytes of the WLF reader cache for the
current simulation dataset only. This makes it easier to set different sizes for the WLF
reader cache used during simulation and those used during post-simulation debug. If
WLFSimCacheSize is not specified, the WLFCacheSize settings will be used.
• WLF Size Limit— Limit the size of a WLF file to <n> megabytes by truncating from
the front of the file as necessary.

ModelSim® SE User's Manual, v10.7 653

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Limiting the WLF File Size

• WLF Time Limit — Limit the size of a WLF file to <t> time by truncating from the
front of the file as necessary.

Limiting the WLF File Size

You can easily limit the WLF file size by setting a simulation control variable or with a vsim
command switch.

Opening Datasets
ModelSim allows you to open existing datasets.
Procedure
To open a dataset, do one of the following:

• Select File > Open to open the Open File dialog box and set the “Files of type” field
to Log Files (*.wlf). Then select the .wlf file you want and click the Open button.
• Select File > Datasets to open the Dataset Browser; then click the Open button to
open the Open Dataset dialog box (Figure 13-3).
Figure 13-3. Open Dataset Dialog Box

• Use the dataset open command to open either a saved dataset or to view a running
simulation dataset: vsim.wlf. Running simulation datasets are automatically updated.

654 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Opening Datasets

The Open Dataset dialog box includes the following options:

o Dataset Pathname — Identifies the path and filename of the WLF file you want
to open.
o Logical Name for Dataset — This is the name by which the dataset will be
referred. By default this is the name of the WLF file.

ModelSim® SE User's Manual, v10.7 655

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Dataset Structure

Dataset Structure
Each dataset you open creates a structure tab in the Main window. The tab is labeled with the
name of the dataset and displays a hierarchy of the design units in that dataset.
The graphic below shows three structure tabs: one for the active simulation (sim) and one each
for two datasets (test and gold).

Figure 13-4. Structure Tabs

If you have too many tabs to display in the available space, you can scroll the tabs left or right
by clicking the arrow icons at the bottom right-hand corner of the window.

Structure Window Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

Structure Window Columns

Structural information about datasets is presented in the Structure window.
Table 13-2 lists the columns displayed in each Structure window, by default.
Table 13-2. Structure Tab Columns
Column name Description
Instance the name of the instance
Design unit the name of the design unit

656 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Structure Window Columns

Table 13-2. Structure Tab Columns (cont.)

Column name Description
Design unit type the type (for example, Module, Entity, and so
forth) of the design unit
Visibility the current visibility of the object as it relates to
design optimization; see Design Object Visibility
for Designs with PLI for more information
Aside from the columns listed above, there are numerous columns related to code coverage that
can be displayed in structure tabs.

You can hide or show columns by right-clicking a column name and selecting the name on the
list.

ModelSim® SE User's Manual, v10.7 657

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Managing Multiple Datasets

Managing Multiple Datasets

ModelSim allows you to manage multiple datasets using menu selections from the graphic
interface or from the command line.
Managing Multiple Datasets in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Managing Multiple Datasets from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Restricting the Dataset Prefix Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Managing Multiple Datasets in the GUI

When you have one or more datasets open, you can manage them using the Dataset Browser.
Procedure
1. Open the Dataset Browser by selecting File > Datasets.
Figure 13-5. The Dataset Browser

2. From the Dataset Browser you can open a selected dataset, save it, reload it, close it,
make it the active dataset, or rename it.

Managing Multiple Datasets from the Command

Line
You can open multiple datasets when the simulator is invoked by specifying more than one
vsim -view <filename> option. By default the dataset prefix will be the filename of the WLF
file.

658 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Managing Multiple Datasets from the Command Line

Procedure
1. You can specify a different dataset name as an optional qualifier to the vsim -view
switch on the command line using the following syntax:
-view <dataset>=<filename>

For example:
vsim -view foo=vsim.wlf

ModelSim designates one of the datasets to be the active dataset, and refers all names
without dataset prefixes to that dataset. The active dataset is displayed in the context
path at the bottom of the Main window. When you select a design unit in a dataset’s
Structure window, that dataset becomes active automatically. Alternatively, you can use
the Dataset Browser or the environment command to change the active dataset.
2. Design regions and signal names can be fully specified over multiple WLF files by using
the dataset name as a prefix in the path. For example:
sim:/top/alu/out
view:/top/alu/out
golden:.top.alu.out

Dataset prefixes are not required unless more than one dataset is open, and you want to
refer to something outside the active dataset. When more than one dataset is open,
ModelSim will automatically prefix names in the Wave and List windows with the
dataset name. You can change this default by selecting:
• List Window active: List > List Preferences; Window Properties tab > Dataset Prefix
pane
• Wave Window active: Wave > Wave Preferences; Display tab > Dataset Prefix
Display pane
3. ModelSim also remembers a “current context” within each open dataset. You can toggle
between the current context of each dataset using the environment command, specifying
the dataset without a path. For example:
env foo:

sets the active dataset to foo and the current context to the context last specified for foo.
The context is then applied to any unlocked windows.
The current context of the current dataset (usually referred to as just “current context”) is
used for finding objects specified without a path.
4. You can lock the Objects window to a specific context of a dataset. Being locked to a
dataset means that the pane updates only when the content of that dataset changes. If
locked to both a dataset and a context (such as test: /top/foo), the pane will update only
when that specific context changes. You specify the dataset to which the pane is locked
by selecting File > Environment.

ModelSim® SE User's Manual, v10.7 659

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Restricting the Dataset Prefix Display

Restricting the Dataset Prefix Display

You can turn dataset prefix viewing on or off by setting the value of a preference variable called
DisplayDatasetPrefix. Setting the variable value to 1 displays the prefix, setting it to 0 does not.
It is set to 1 by default.
Procedure
1. To change the value of this variable, do the following:
2. Choose Tools > Edit Preferences... from the main menu.
3. In the Preferences dialog box, click the By Name tab.
4. Scroll to find the Preference Item labeled Main and click [+] to expand the listing of
preference variables.
5. Select the DisplayDatasetPrefix variable then click the Change Value... button.
6. In the Change Preference Value dialog box, type a value of 0 or 1, where
• 0 = turns off prefix display
• 1 = turns on prefix display (default)
7. Click OK; click OK.
8. Additionally, you can prevent display of the dataset prefix by using the environment
-nodataset command to view a dataset. To enable display of the prefix, use the
environment -dataset command (note that you do not need to specify this command
argument if the DisplayDatasetPrefix variable is set to 1). These arguments of the
environment command override the value of the DisplayDatasetPrefix variable.

Collapsing Time and Delta Steps

By default ModelSim collapses delta steps. This means each logged signal that has events
during a simulation delta has its final value recorded to the WLF file when the delta has expired.
The event order in the WLF file matches the order of the first events of each signal.
You can configure how ModelSim collapses time and delta steps using arguments to the vsim
command or by setting the WLFCollapseMode variable in the modelsim.ini file. The table
below summarizes the arguments and how they affect event recording.
Table 13-3. vsim Arguments for Collapsing Time and Delta Steps
vsim argument effect modelsim.ini setting
-nowlfcollapse All events for each logged signal are WLFCollapseMode = 0
recorded to the WLF file in the exact order
they occur in the simulation.

660 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Collapsing Time and Delta Steps

Table 13-3. vsim Arguments for Collapsing Time and Delta Steps (cont.)
vsim argument effect modelsim.ini setting
-wlfcollapsedelta Each logged signal which has events during WLFCollapseMode = 1
a simulation delta has its final value recorded
to the WLF file when the delta has expired.
Default.
-wlfcollapsetime Same as delta collapsing but at the timestep WLFCollapseMode = 2
granularity.
When a run completes that includes single stepping or hitting a breakpoint, all events are
flushed to the WLF file regardless of the time collapse mode. It’s possible that single stepping
through part of a simulation may yield a slightly different WLF file than just running over that
piece of code. If particular detail is required in debugging, you should disable time collapsing.

ModelSim® SE User's Manual, v10.7 661

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Virtual Objects

Virtual Objects
Virtual objects are signal-like or region-like objects created in the GUI that do not exist in the
ModelSim simulation kernel.
Virtual objects are indicated by an orange diamond as illustrated by Bus1 in Figure 13-6:

Figure 13-6. Virtual Objects Indicated by Orange Diamond

Virtual Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662

Virtual Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Virtual Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Virtual Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

Virtual Signals
Virtual signals are aliases for combinations or subelements of signals written to the WLF file by
the simulation kernel. They can be displayed in the Objects, List, Watch, and Wave windows,
accessed by the examine command, and set using the force command.
You can create virtual signals using the Wave or List > Combine Signals menu selections or
by using the virtual signal command. Once created, virtual signals can be dragged and dropped
from the Objects pane to the Wave, Watch, and List windows. In addition, you can create virtual
signals for the Wave window using the Virtual Signal Builder (refer to Using the Virtual Signal
Builder).

Virtual signals are automatically attached to the design region in the hierarchy that corresponds
to the nearest common ancestor of all the elements of the virtual signal. The virtual signal
command has an -install <region> option to specify where the virtual signal should be installed.
This can be used to install the virtual signal in a user-defined region in order to reconstruct the

662 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Recording Simulation Results With Datasets
Virtual Functions

original RTL hierarchy when simulating and driving a post-synthesis, gate-level

implementation.

A virtual signal can be used to reconstruct RTL-level design buses that were broken down
during synthesis. The virtual hide command can be used to hide the display of the broken-down
bits if you do not want them cluttering up the Objects window.

If the virtual signal has elements from more than one WLF file, it will be automatically installed
in the virtual region virtuals:/Signals.

Virtual signals are not hierarchical – if two virtual signals are concatenated to become a third
virtual signal, the resulting virtual signal will be a concatenation of all the scalar elements of the
first two virtual signals.

The definitions of virtuals can be saved to a DO file using the virtual save command. By default,
when quitting, ModelSim will append any newly-created virtuals (that have not been saved) to
the virtuals.do file in the local directory.

If you have virtual signals displayed in the Wave or List window when you save the Wave or
List format, you will need to execute the virtuals.do file (or some other equivalent) to restore the
virtual signal definitions before you re-load the Wave or List format during a later run. There is
one exception: “implicit virtuals” are automatically saved with the Wave or List format.

Implicit and Explicit Virtuals

An implicit virtual is a virtual signal that was automatically created by ModelSim without your
knowledge and without you providing a name for it. An example would be if you expand a bus
in the Wave window, then drag one bit out of the bus to display it separately. That action creates
a one-bit virtual signal whose definition is stored in a special location, and is not visible in the
Objects pane or to the normal virtual commands.

All other virtual signals are considered “explicit virtuals”.

Virtual Functions
Virtual functions behave in the GUI like signals but are not aliases of combinations or elements
of signals logged by the kernel. They consist of logical operations on logged signals and can be
dependent on simulation time.
Virtual functions can be displayed in the Objects, Wave, and List windows and accessed by the
examine command, but cannot be set by the force command.

Examples of virtual functions include the following:

• a function defined as the inverse of a given signal

• a function defined as the exclusive-OR of two signals

ModelSim® SE User's Manual, v10.7 663

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording Simulation Results With Datasets
Virtual Regions

• a function defined as a repetitive clock

• a function defined as “the rising edge of CLK delayed by 1.34 ns”
You can also use virtual functions to convert signal types and map signal values.

The result type of a virtual function can be any of the types supported in the GUI expression
syntax: integer, real, boolean, std_logic, std_logic_vector, and arrays and records of these types.
Verilog types are converted to VHDL 9-state std_logic equivalents and Verilog net strengths are
ignored.

To create a virtual function, use the virtual function command.

Virtual functions are also implicitly created by ModelSim when referencing bit-selects or part-
selects of Verilog registers in the GUI, or when expanding Verilog registers in the Objects,
Wave, or List window. This is necessary because referencing Verilog register elements requires
an intermediate step of shifting and masking of the Verilog “vreg” data structure.

Virtual Regions
User-defined design hierarchy regions can be defined and attached to any existing design region
or to the virtuals context tree. They can be used to reconstruct the RTL hierarchy in a gate-level
design and to locate virtual signals. Thus, virtual signals and virtual regions can be used in a
gate-level design to allow you to use the RTL test bench.
To create and attach a virtual region, use the virtual region command.

Virtual Types
User-defined enumerated types can be defined in order to display signal bit sequences as
meaningful alphanumeric names. The virtual type is then used in a type conversion expression
to convert a signal to values of the new type. When the converted signal is displayed in any of
the windows, the value will be displayed as the enumeration string corresponding to the value of
the original signal.
To create a virtual type, use the virtual type command.

664 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 14
Waveform Analysis

The Wave window is the most commonly used tool for analyzing and debugging your design
after simulation. It displays all signals in your design as waveforms and signal values and
provides a suite of graphical tools for debugging.
Wave Window Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Objects You Can View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Adding Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Inserting Signals in a Specific Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Working with Cursors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Adding Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Editing Cursor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Expanded Time in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Expanded Time Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 682
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . 685
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanding and Collapsing Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Zooming the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Zooming with the Menu, Toolbar and Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Saving Zoom Range and Scroll Position with Bookmarks. . . . . . . . . . . . . . . . . . . . . . . . . 691
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Searching in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Searching for Values or Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Filtering the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Formatting the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Setting Wave Window Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

ModelSim® SE User's Manual, v10.7 665

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis

Formatting Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704

Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Wave Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Creating a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Deleting or Ungrouping a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Adding Items to an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Removing Items from an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Composite Signals or Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Creating Composite Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Saving the Window Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Exporting Waveforms from the Wave window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Exporting the Wave Window as a Bitmap Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Saving Waveform Sections for Later Viewing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Viewing SystemVerilog Class Objects and Class Path Expressions . . . . . . . . . . . . . . . . 722
Viewing System Verilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Combining Objects into Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Extracting a Bus Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Using the Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Miscellaneous Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Examining Waveform Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Creating and Managing Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Waveform Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Mixed-Language Waveform Compare Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Setting Up a Comparison with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Adding Signals, Regions, and Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754

666 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Wave Window Overview

Viewing Differences in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756

Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Viewing Differences in Textual Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Saving and Reloading Comparison Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Comparing Hierarchical and Flattened Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

Wave Window Overview

The Wave window opens in the Main window. Like all other windows, it may be undocked
from the Main window by clicking the Undock button in the window header. When the Wave
window is docked in the Main window, all menus and icons that were in the undocked Wave
window move into the Main window menu bar and toolbar tabs.
Figure 14-1. The Wave Window

For more information about the graphic features of the Wave window, refer to Wave Window in
the GUI Reference Manual.

Objects You Can View

The list below identifies the types of objects that you can view in the Wave window. Each
object type is indicated by its own color-coded shape (such as a diamond or a triangle).

ModelSim® SE User's Manual, v10.7 667

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Objects You Can View

• VHDL objects (dark blue diamond) —

signals, aliases, process variables, shared variables
• Verilog and SystemVerilog objects (light blue diamond) —
nets, registers, variables, named events, interfaces, classes
• SystemC objects (green diamond) —
primitive channels, ports
• Virtual objects (orange diamond) —
virtual signals, buses, functions
Refer to Virtual Objects for more information.
• Comparisons (yellow triangle) —
comparison regions, comparison signals
Refer to Waveform Compare for more information.
• Assertions ( triangle: light-blue for SystemVerilog, magenta for PSL) —
PSL and SystemVerilog assertions
• UPF Objects (blue diamond with a yellow waveform icon) —
A VHDL, Verilog, or SystemVerilog object that is defined as part of a UPF (unified
power format) domain
Refer to “Displaying UPF Objects in the GUI” in the Power Aware Simulation User’s
Manual for more information.
• Cover Directives (chevron: light-blue for SystemVerilog, magenta for PSL) —
PSL and SystemVerilog cover directives
Related Topics
Using the WildcardFilter Preference Variable

668 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Adding Objects to the Wave Window

Adding Objects to the Wave Window

You can add objects to the Wave window with mouse actions, menu selections, commands, and
with a window format file.

Table 14-1. Add Objects to the Wave Window

To Add Using ... Do the Following:
Mouse Actions • Drag and drop objects into the Wave window from the Structure,
Processes, Memory, List, Objects, Source, or Locals windows.
When objects are dragged into the Wave window, the add wave
command is echoed in the Transcript window. Depending on what
you select, all objects or any portion of the design can be added.
• Place the cursor over an individual object or selected objects in the
Objects or Locals windows, then click the middle mouse button to
place the object(s) in the Wave window.
Menu Selections • Add > window — Add objects to the Wave window or Log file.
• Add Selected to Window Button — Add objects to the Wave,
Dataflow, Schematic, List, or Watch windows. Refer to Add
Selected to Window Button in the GUI Reference Manual for more
information.
You can also add objects using right-click popup menus. For example,
if you want to add all signals in a design to the Wave window you can
do one of the following:
• Right-click a design unit in a Structure (sim) window and select
Add > To Wave > All Items in Design from the popup context
menu.
• Right-click anywhere in the Objects window and select Add > To
Wave > Signals in Design from the popup context menu.
• Right-click a Verilog virtual interface waveform and select Add
Wave > <interface_name/*> from the popup menu.
Commands Use the add wave command to add objects from the command line.
For example:
VSIM> add wave /proc/a

Adds signal /proc/a to the Wave window.

VSIM> add wave -r /*

Adds all objects in the design to the Wave window.

Refer to “Using the WildcardFilter Preference Variable” in the

Command Reference Manual for information on controlling the
information that is added to the Wave window when using wild cards.
A Window Format Select File > Load and specify a previously saved format file. Refer to
File Saving the Window Format for details on how to create a format file.

ModelSim® SE User's Manual, v10.7 669

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Inserting Signals in a Specific Location

Inserting Signals in a Specific Location

New signals are inserted above the Insertion Point Bar located at the bottom of the Pathname
Pane. You can change the location of the Insertion Point Bar by using the Insertion Point
Column of the Pathname Pane.
Restrictions and Limitations
By default, new signals are added above the Insertion Point Bar. You can change the default
location for insertion by setting the PrefWave(InsertMode) preference variable to one of the
following:

• insert — (default) Places new object(s) above the Insertion Pointer Bar.
• append — Places new object(s) below the Insertion Pointer Bar.
• top — Places new object(s) at the top of the Wave window.
• end — Places new object(s) at the bottom of the Wave window.
Prerequisites
There must be at least one signal in the Wave window.

Procedure
1. Click the vertical white bar on the left-hand side of the active Wave window to select
where signals should be added. (Figure 14-2)
2. Your cursor will change to a double-tail arrow and a green bar will appear. Clicking the
vertical white bar next to a signal places the Insertion Point Bar below the indicated
signal. Alternatively, you can Ctrl+click the white bar to place the Insertion Point Bar
below the indicated signal.
Figure 14-2. Insertion Point Bar

3. Select an instance in the Structure (sim) window or an object in the Objects window.
4. Use the hot key Ctrl+w to add all signals of the instance or the specific object to the
Wave window in the location of the Insertion Point Bar.

670 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Inserting Signals in a Specific Location

Related Topics
Insertion Point Bar and Pathname Pane.

ModelSim® SE User's Manual, v10.7 671

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Working with Cursors

Working with Cursors

Cursors mark simulation time in the Wave window. When ModelSim first draws the Wave
window, it places one cursor at time zero. Clicking anywhere in the waveform display brings
the nearest cursor to the mouse location. You can use cursors to find transitions, a rising or
falling edge, and to measure time intervals.
The Cursor and Timeline Toolbox on the left side of the cursor pane gives you quick access to
cursor and timeline settings.

Table 14-2 summarizes common cursor actions you can perform with the icons in the toolbox,
or with menu selections.
Table 14-2. Actions for Cursors
Icon Action Menu path or command Menu path or command
(Wave window docked) (Wave window undocked)
Toggle leaf names Wave > Wave Preferences > Tools > Window Preferences
<-> full names Display Tab > Display Tab
Edit grid and Wave > Wave Preferences > Tools > Window Preferences
timeline properties Grid and Timeline Tab > Grid and Timeline Tab
Add cursor Add > To Wave > Cursor Add > Cursor
Edit cursor Wave > Edit Cursor Edit > Edit Cursor
Delete cursor Wave > Delete Cursor Edit > Delete Cursor
Lock cursor Wave > Edit Cursor Edit > Edit Cursor
NA Select a cursor Wave > Cursors View > Cursors
NA Zoom In on Active Wave > Zoom > Zoom View > Zoom > Zoom Cursor
Cursor Cursor
NA Zoom between Debug Toolbar Tab only (refer Debug Toolbar Tab only.
Cursors to the GUI Reference Manual)
NA Two Cursor Mode Wave > Mouse Mode > Two Wave > Mouse Mode > Two
Cursor Mode Cursor Mode

The Toggle leaf names <-> full names icon allows you to switch from displaying full
pathnames (the default) to displaying leaf or short names in the Pathnames Pane. You can also
control the number of path elements in the Wave Window Preferences dialog. Refer to Hiding/
Showing Path Hierarchy.

672 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Working with Cursors

The Edit grid and timeline properties icon opens the Wave Window Properties dialog box to
the Grid & Timeline tab (Figure 14-3).

Figure 14-3. Grid and Timeline Properties

• The Grid Configuration selections allow you to set grid offset, minimum grid spacing,
and grid period. You can also reset these grid configuration settings to their default
values.
• The Timeline Configuration selections give you change the time scale. You can display
simulation time on a timeline or a clock cycle count. If you select Display simulation
time in timeline area, use the Time Units dropdown list to select one of the following as
the timeline unit:
fs, ps, ns, us, ms, sec, min, hr

ModelSim® SE User's Manual, v10.7 673

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Adding Cursors

Note
The time unit displayed in the Wave window (default: ns) does not reflect the
simulation time that is currently defined.

The current configuration is saved with the wave format file so you can restore it later.
• The Show frequency in cursor delta box causes the timeline to display the difference
(delta) between adjacent cursors as frequency. By default, the timeline displays the delta
between adjacent cursors as time.
Adding Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Editing Cursor Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

Adding Cursors
To add cursors when the Wave window is active you can do one of the following.
Procedure
1. Click the Insert Cursor icon.
2. Choose Add > To Wave > Cursor from the menu bar.
3. Press the “A” key while the mouse pointer is located in the cursor pane.
4. Right click in the cursor pane and select New Cursor @ <time> ns to place a new
cursor at a specific time.

Editing Cursor Properties

After adding a cursor, you can alter its properties by using the Cursor Properties dialog box.
Procedure
1. Right-click the cursor you want to edit and select Cursor Properties. (You can also use
the Edit this cursor icon in the cursor toolbox)

674 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Jump to a Signal Transition

2. From the Cursor Properties dialog box, alter any of the following properties:
• Cursor Name — the name that appears in the Wave window.
• Cursor Time — the time location of the cursor.
• Cursor Color — the color of the cursor.
• Locked Cursor Color — the color of the cursor when it is locked to a specific time
location.
• Lock cursor to specified time — disables relocation of the cursor.

Jump to a Signal Transition

You can move the active (selected) cursor to the next or previous transition on the selected
signal using these two toolbar icons located in the Debug Toolbar Tab. Refer to the following
table.

Table 14-3. Find Previous and Next Transition Icons

Find Previous Transition locate
the previous signal value change
for the selected signal
Find Next Transition locate the
next signal value change for the
selected signal

These actions will not work on locked cursors.

Related Topics
Debug Toolbar Tab.

Measuring Time with Cursors in the Wave Window

ModelSim uses cursors to measure time in the Wave window. Cursors extend a vertical line
over the waveform display and identify a specific simulation time.
When the Wave window is first drawn it contains two cursors — the Now cursor, and Cursor 1
(Figure 14-4).

Figure 14-4. Original Names of Wave Window Cursors

ModelSim® SE User's Manual, v10.7 675

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Syncing All Active Cursors

The Now cursor is always locked to the current simulation time and it is not manifested as a
graphical object (vertical cursor bar) in the Wave window.

Cursor 1 is located at time zero. Clicking anywhere in the waveform display moves the Cursor
1 vertical cursor bar to the mouse location and makes this cursor the selected cursor. The
selected cursor is drawn as a bold solid line; all other cursors are drawn with thin lines.

Syncing All Active Cursors

You can synchronize the active cursors within all open Wave windows and the Wave viewers in
the Dataflow and Schematic windows.
Procedure
1. Right-click the time value of the active cursor in any window and select Sync All Active
Cursors from the popup menu (Figure 14-5).
Figure 14-5. Sync All Active Cursors

2. When all active cursors are synced, moving a cursor in one window will automatically
move the active cursors in all opened Wave windows to the same time location. This
option is also available by selecting Wave > Cursors > Sync All Active Cursors in the
menu bar when a Wave window is active.

Linking Cursors
Cursors within the Wave window can be linked together, allowing you to move two or more
cursors together across the simulation timeline. You simply click one of the linked cursors and
drag it left or right on the timeline. The other linked cursors will move by the same amount of
time.
Procedure
1. You can link all displayed cursors by right-clicking the time value of any cursor in the
timeline, as shown in Figure 14-6, and selecting Cursor Linking > Link All.

676 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Understanding Cursor Behavior

Figure 14-6. Cursor Linking Menu

2. You can link and unlink selected cursors by selecting the time value of any cursor and
selecting Cursor Linking > Configure to open the Configure Cursor Links dialog
(Figure 14-7).
Figure 14-7. Configure Cursor Links Dialog

Understanding Cursor Behavior

The following list describes how cursors behave when you click in various panes of the Wave
window unless you are in Two Cursor Mode:
• If you click in the waveform pane, the closest unlocked cursor to the mouse position is
selected and then moved to the mouse position.
• Clicking in a horizontal track in the cursor pane selects that cursor and moves it to the
mouse position.
• Cursors snap to the nearest waveform edge to the left if you click or drag a cursor along
the selected waveform to within ten pixels of a waveform edge. You can set the snap
distance in the Display tab of the Window Preferences dialog. Select Tools > Options >
Wave Preferences when the Wave window is docked in the Main window MDI frame.

ModelSim® SE User's Manual, v10.7 677

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Shortcuts for Working with Cursors

Select Tools > Window Preferences when the Wave window is a stand-alone, undocked
window.
• You can position a cursor without snapping by dragging a cursor in the cursor pane
below the waveforms.

Shortcuts for Working with Cursors

There are a number of useful keyboard and mouse shortcuts related to the actions listed above:
• Select a cursor by clicking the cursor name.
• Jump to a hidden cursor (one that is out of view) by double-clicking the cursor name.
• Name a cursor by right-clicking the cursor name and entering a new value. Press
<Enter> on your keyboard after you have typed the new name.
• Move a locked cursor by holding down the <shift> key and then clicking-and-dragging
the cursor.
• Move a cursor to a particular time by right-clicking the cursor value and typing the value
to which you want to scroll. Press <Enter> on your keyboard after you have typed the
new value.

678 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Two Cursor Mode

Two Cursor Mode

Two Cursor Mode places two active cursors in the Wave window. Where default Wave window
cursor behavior is for the closest cursor to snap to the location of the mouse when the left mouse
button is pressed, in Two Cursor Mode the left mouse button controls movement of the first
cursor and the middle mouse button controls the second cursor regardless of the proximity of
the pointer to the closest cursor. Additional cursors may be added but are locked upon insertion.
Enable Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Additional Mouse Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

Enable Two Cursor Mode

You can enable Two Cursor Mode by selecting Wave > Mouse Mode > Two Cursor Mode, or
by selecting the Two Cursor Mode button in the Debug Toolbar Tab.

You can return to standard Wave Window behavior by selecting Wave > Mouse Mode > and
choosing one of the other menu picks or by selecting a different button in the Debug Toolbar
Tab.

Additional Mouse Actions

Both cursors snap to the position of the mouse pointer when the mouse button controlling the
cursor is released. Holding down a button and dragging changes the action from cursor
placement to zooming in or out in the waveform pane:

Table 14-4. Two Cursor Zoom

Mouse Action
Down-Right or Down-Left Zoom Area (In)
Up- Right Zoom Out
Up-Left Zoom to Fit

The zoom amount is displayed at the mouse cursor. A zoom operation must be more than 10
pixels to activate.

To zoom with the scroll-wheel of your mouse, hold down the Ctrl key at the same time to scroll
in and out. The waveform pane will zoom in and out, centering on your mouse cursor.

ModelSim® SE User's Manual, v10.7 679

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Expanded Time in the Wave Window

Expanded Time in the Wave Window

When analyzing a design using ModelSim, you can see a value for each object at any time step
in the simulation. If logged in the .wlf file, the values at any time step prior to and including the
current simulation time are displayed in the Wave window or by using the examine command.
Some objects can change values more than once in a given time step. These intermediate values
are of interest when debugging glitches on clocked objects or race conditions. With a few
exceptions (viewing delta time steps with the examine command), the values prior to the final
value in a given time step cannot be observed.

The expanded time function makes these intermediate values visible in the Wave window.
Expanded time shows the actual order in which objects change values and shows all transitions
of each object within a given time step.

Expanded Time Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . 682
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . 685
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanding and Collapsing Simulation Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

Expanded Time Terminology

The following list provides definitions of the basic terms used when discussing expanded time
in the Wave window.
• Simulation Time — the basic time step of the simulation. The final value of each object
at each simulation time is what is displayed by default in the Wave window.
• Delta Time — the time intervals or steps taken to evaluate the design without advancing
simulation time. Object values at each delta time step are viewed by using the -delta
argument of the examine command. Refer to Delta Delays for more information.
• Event Time — the time intervals that show each object value change as a separate event
and that shows the relative order in which these changes occur
During a simulation, events on different objects in a design occur in a particular order or
sequence. Typically, this order is not important and only the final value of each object
for each simulation time step is important. However, in situations like debugging
glitches on clocked objects or race conditions, the order of events is important. Unlike
simulation time steps and delta time steps, only one object can have a single value

680 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Recording Expanded Time Information

change at any one event time. Object values and the exact order which they change can
be saved in the .wlf file.
• Expanded Time — the Wave window feature that expands single simulation time steps
to make them wider, allowing you to see object values at the end of each delta cycle or at
each event time within the simulation time.
• Expand — causes the normal simulation time view in the Wave window to show
additional detailed information about when events occurred during a simulation.
• Collapse — hides the additional detailed information in the Wave window about when
events occurred during a simulation.

Recording Expanded Time Information

You can use the vsim command, or the WLFCollpseMode variable in the modelsim.ini file, to
control recording of expanded time information in the .wlf file.
Unlike delta times (which are explicitly saved in the .wlf file), event time information exists
implicitly in the .wlf file. That is, the order in which events occur in the simulation is the same
order in which they are logged to the .wlf file, but explicit event time values are not logged.
Table 14-5. Recording Delta and Event Time Information
vsim command argument modelsim.ini setting effect
-nowlfcollapse WLFCollapseMode = 0 Saves multiple value changes of an
object during a single time step or
single delta cycle, All events for each
logged signal are recorded to the .wlf
file in the exact order they occur in
the simulation.
-wlfcollapsedelta WLFCollapseMode = 1 Each logged signal that has events
(Default) during a simulation delta has its final
value recorded in the .wlf file when
the delta has expired.
-wlfcollapsetime WLFCollapseMode = 2 Similar to delta collapsing but at the
simulation time step granularity.

You can choose not to record event time or delta time information to the .wlf file by using the
-wlfcollapsetime argument with vsim, or by setting WLFCollapseMode to 2. This will prevent
detailed debugging but may reduce the size of the .wlf file and speed up the simulation.

ModelSim® SE User's Manual, v10.7 681

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing Expanded Time Information in the Wave Window

Viewing Expanded Time Information in the Wave

Window
Expanded time information is displayed in the Debug Toolbar Tab, the right portion of the
Messages bar, the Waveform pane, the time axis portion of the Cursor pane, and the Waveform
pane horizontal scroll bar as described below.
• Expanded Time Buttons— The Expanded Time buttons are displayed in the Debug
Toolbar Tab in both the undocked Wave window the Main window when the Wave
window is docked. It contains three exclusive toggle buttons for selecting the Expanded
Time mode (refer to Toolbar Selections for Expanded Time Modes) and four buttons for
expanding and collapsing simulation time.
• Messages Bar — The right portion of the Messages Bar is scaled horizontally to align
properly with the Waveform pane and the time axis portion of the Cursor pane.
• Waveform Pane Horizontal Scroll Bar — The position and size of the thumb in the
Waveform pane horizontal scroll bar is adjusted to correctly reflect the current state of
the Waveform pane and the time axis portion of the Cursor pane.
• Waveform Pane and the Time Axis Portion of the Cursor Pane — By default, the
Expanded Time is off and simulation time is collapsed for the entire time range in the
Waveform pane. When the Delta Time mode is selected, simulation time remains
collapsed for the entire time range in the Waveform pane. A red dot is displayed in the
middle of all waveforms at any simulation time where multiple value changes were
logged for that object.
Figure 14-8 illustrates the appearance of the Waveform pane when viewing collapsed event
time or delta time. It shows a simulation with three signals, s1, s2, and s3. The red dots indicate
multiple transitions for s1 and s2 at simulation time 3ns.

Figure 14-8. Waveform Pane with Collapsed Event and Delta Time

Figure 14-9 shows the Waveform pane and the timescale from the Cursors pane after expanding
simulation time at time 3ns. The background color is blue for expanded sections in Delta Time
mode and green for expanded sections in Event Time mode.

682 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Viewing Expanded Time Information in the Wave Window

Figure 14-9. Waveform Pane with Expanded Time at a Specific Time

In Delta Time mode, more than one object may have an event at the same delta time step. The
labels on the time axis in the expanded section indicate the delta time steps within the given
simulation time.

In Event Time mode, only one object may have an event at a given event time. The exception to
this is for objects that are treated atomically in the simulator and logged atomically.

The individual bits of a SystemC vector, for example, could change at the same event time.

Labels on the time axis in the expanded section indicate the order of events from all of the
objects added to the Wave window. If an object that had an event at a particular time but it is not
in the viewable area of the Waveform panes, then there will appear to be no events at that time.

Depending on which objects have been added to the Wave window, a specific event may
happen at a different event time. For example, if s3 shown in Figure 14-9, had not been added to
the Wave window, the result would be as shown in Figure 14-10.

Figure 14-10. Waveform Pane with Event Not Logged

Now the first event on s2 occurs at event time 3ns + 2 instead of event time 3ns + 3. If s3 had
been added to the Wave window (whether shown in the viewable part of the window or not) but
was not visible, the event on s2 would still be at 3ns + 3, with no event visible at 3ns + 2.

ModelSim® SE User's Manual, v10.7 683

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing Expanded Time Information in the Wave Window

Figure 14-11 shows an example of expanded time over the range from 3ns to 5ns. The expanded
time range displays delta times as indicated by the blue background color. (If Event Time mode
is selected, a green background is displayed.)

Figure 14-11. Waveform Pane with Expanded Time Over a Time Range

When scrolling horizontally, expanded sections remain expanded until you collapse them, even
when scrolled out of the visible area. The left or right edges of the Waveform pane are viewed
in either expanded or collapsed sections.

Expanded event order or delta time sections appear in all panes when multiple Waveform panes
exist for a Wave window. When multiple Wave windows are used, sections of expanded event
or delta time are specific to the Wave window where they were created.

For expanded event order time sections when multiple datasets are loaded, the event order time
of an event will indicate the order of that event relative to all other events for objects added to
that Wave window for that object’s dataset only. That means, for example, that signal sim:s1
and gold:s2 could both have events at time 1ns+3.

Note
The order of events for a given design will differ for optimized versus unoptimized
simulations, and between different versions of ModelSim. The order of events will be
consistent between the Wave window and the List window for a given simulation of a particular
design, but the event numbering may differ. Refer to Expanded Time Viewing in the List
Window in the GUI Reference Manual.

You can display any number of disjoint expanded times or expanded ranges of times.

Related Topics
Debug Toolbar Tab.

684 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Customizing the Expanded Time Wave Window Display

Customizing the Expanded Time Wave Window

Display
As noted above, the Wave window background color is blue instead of black for expanded
sections in Delta Time mode and green for expanded sections in Event Time mode.
The background colors for sections of expanded event time are changed as follows:

Procedure
1. Select Tools > Edit Preferences from the menus. This opens the Preferences dialog.
2. Select the By Name tab.
3. Scroll down to the Wave selection and click the plus sign (+) for Wave.
4. Change the values of the Wave Window variables waveDeltaBackground and
waveEventBackground.

ModelSim® SE User's Manual, v10.7 685

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Expanded Time Display Modes

Expanded Time Display Modes

There are three Wave window expanded time display modes: Event Time mode, Delta Time
mode, and Expanded Time off. These display modes are initiated by menu selections, toolbar
selections, or via the command line.
Menu Selections for Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Toolbar Selections for Expanded Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Command Selection of Expanded Time Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687

Menu Selections for Expanded Time Display Modes

The following table shows the menu selections for initiating expanded time display modes.

Table 14-6. Menu Selections for Expanded Time Display Modes

action menu selection with Wave window docked or undocked
select Delta Time mode docked: Wave > Expanded Time > Delta Time Mode
undocked: View > Expanded Time > Delta Time Mode
select Event Time mode docked: Wave > Expanded Time > Event Time Mode
undocked: View > Expanded Time > Event Time Mode
disable Expanded Time docked: Wave > Expanded Time > Expanded Time Off
undocked: View > Expanded Time > Expanded Time Off

Select Delta Time Mode or Event Time Mode from the appropriate menu according to
Table 14-6 to have expanded simulation time in the Wave window show delta time steps or
event time steps respectively. Select Expanded Time Off for standard behavior (which is the
default).

Toolbar Selections for Expanded Time Modes

There are three exclusive toggle buttons in the Debug Toolbar Tab for selecting the time mode
used to display expanded simulation time in the Wave window.
• The "Expanded Time Deltas Mode" button displays delta time steps.
• The "Expanded Time Events Mode" button displays event time steps.
• The "Expanded Time Off" button turns off the expanded time display in the Wave
window.
Clicking any one of these buttons on toggles the other buttons off. This serves as an immediate
visual indication about which of the three modes is currently being used. Choosing one of these

686 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Switching Between Time Modes

modes from the menu bar or command line also results in the appropriate resetting of these three
buttons. The "Expanded Time Off" button is selected by default.

In addition, the Debug Toolbar Tab (described in the GUI Reference Manual) includes four
buttons for expanding and collapsing simulation time.

• The “Expand All Time” button expands simulation time over the entire simulation time
range, from time 0 to the current simulation time.
• The “Expand Time At Active Cursor” button expands simulation time at the simulation
time of the active cursor.
• The “Collapse All Time” button collapses simulation time over entire simulation time
range.
• The “Collapse Time At Active Cursor” button collapses simulation time at the
simulation time of the active cursor.
Related Topics
Debug Toolbar Tab.

Command Selection of Expanded Time Mode

The command syntax for selecting the time mode used to display objects in the Wave window
is:
wave expand mode [-window <win>] none | deltas | events

Use the wave expand mode command to select which mode is used to display expanded time in
the wave window. This command also results in the appropriate resetting of the three toolbar
buttons.

Switching Between Time Modes

If one or more simulation time steps have already been expanded to view event time or delta
time, then toggling the Time mode by any means will cause all of those time steps to be
redisplayed in the newly selected mode.

Expanding and Collapsing Simulation Time

Simulation time may be expanded to view delta time steps or event time steps at a single
simulation time or over a range of simulation times. Simulation time may be collapsed to hide
delta time steps or event time steps at a single simulation time or over a range of simulation
times. You can expand or collapse the simulation time with menu selections, toolbar selections,
via commands, or with the mouse cursor.

ModelSim® SE User's Manual, v10.7 687

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Expanded Time with examine and Other Commands

Procedure
Use the following procedure:

To expand or collapse Do the following:

simulation time with…
Menu Selections Select Wave > Expanded Time when the Wave window is
docked, and View > Expanded Time when the Wave window
is undocked. You can expand/collapse over the full simulation
time range, over a specified time range, or at the time of the
active cursor,.
Toolbar Selections The Debug Toolbar Tab (described in the GUI Reference
Manual) includes four buttons for expanding and collapsing
simulation time in the Wave window: Expand Full, Expand
Cursor, Collapse Full, and Collapse Cursor.
Commands There are six commands for expanding and collapsing
simulation time in the Wave window.
• wave expand all
• wave expand range
• wave expand cursor
• wave collapse all
• wave collapse range
• wave collapse cursor
These commands have the same behavior as the corresponding
menu and toolbar selections. If valid times are not specified,
for wave expand range or wave collapse range, no action is
taken. These commands affect all Waveform panes in the
Wave window to which the command applies.

Expanded Time with examine and Other

Commands
The Wave window can expand time to show delta delays. You can use the examine, searchlog,
and seetime commands to manipulate expanded time data.
• examine — The -event <event> option to the examine command behaves in the same
manner as the -delta <delta> option. When the -event option is used, the event time
given will refer to the event time relative to events for all signals in the objects dataset at
the specified time. This may be misleading as it may not correspond to event times
displayed in the List or Wave windows.
• searchlog — The -event <event> option to the searchlog command behaves in the same
manner as the -delta <delta> option.

688 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Expanded Time with examine and Other Commands

• seetime — The -event <event> option to the seetime command behaves in the same
manner as the -delta <delta> option.

ModelSim® SE User's Manual, v10.7 689

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Zooming the Wave Window Display

Zooming the Wave Window Display

Zooming lets you change the simulation range in the waveform pane. You can zoom using the
context menu, toolbar buttons, mouse, keyboard, or commands. You can also save a specific
zoom range and scroll position with Wave window bookmarks.
Zooming with the Menu, Toolbar and Mouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Saving Zoom Range and Scroll Position with Bookmarks . . . . . . . . . . . . . . . . . . . . . . . 691
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Zooming with the Menu, Toolbar and Mouse

You can access Zoom commands in any of the following ways:
• From the Wave > Zoom menu selections in the Main window when the Wave window
is docked
• From the View menu in the Wave window when the Wave window is undocked
• Right-clicking in the waveform pane of the Wave window
These zoom buttons are available on the Debug Toolbar Tab (described in more detail in the
GUI Reference Manual):

Zoom In 2x zoom in by a factor of two from the current

view

Zoom In on Active Cursor centers the active cursor in the

waveform display and zooms in
Zoom between Cursors
zoom window in or out to show the range between the last
two active cursors

Zoom Mode
change mouse pointer to zoom mode; see below
Zoom Out 2x
zoom out by a factor of two from current view
Zoom Full
zoom out to view the full range of the simulation from time
0 to the current time

690 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Saving Zoom Range and Scroll Position with Bookmarks

To zoom with the mouse, first enter zoom mode by selecting View > Zoom > Mouse Mode >
Zoom Mode. The left mouse button then offers 3 zoom options by clicking and dragging in
different directions:

• Down-Right or Down-Left: Zoom Area (In)

• Up-Right: Zoom Out
• Up-Left: Zoom Fit
Also note the following about zooming with the mouse:

• The zoom amount is displayed at the mouse cursor. A zoom operation must be more
than 10 pixels to activate.
• You can enter zoom mode temporarily by holding the <Ctrl> key down while in select
mode.
• With the mouse in the Select Mode, the middle mouse button will perform the above
zoom operations.
To zoom with the scroll-wheel of your mouse, hold down the Ctrl key at the same time to scroll
in and out. The waveform pane will zoom in and out, centering on your mouse cursor.

Saving Zoom Range and Scroll Position with

Bookmarks
Bookmarks save a particular zoom range and scroll position. This lets you return easily to a
specific view later. You save the bookmark with a name and then access the named bookmark
from the Bookmark menu. Bookmarks are saved in the Wave format file and are restored when
the format file is read.
To add a bookmark, follow these steps:

Procedure
1. Zoom the Wave window as you see fit using one of the techniques discussed in Zooming
the Wave Window Display.
2. If the Wave window is docked, select Add > to Wave > Bookmark. If the Wave
window is undocked, select Add > Bookmark.

ModelSim® SE User's Manual, v10.7 691

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Editing Bookmarks

Figure 14-12. New Bookmark Dialog

3. Give the bookmark a name and click OK.

4. The table below summarizes actions you can take with bookmarks.

Table 14-7. Actions for Bookmarks

Action Menu commands Menu commands Command
(Wave window (Wave window
docked) undocked)
Add bookmark Add > To Wave > Add > Bookmark bookmark add wave
Bookmark
View bookmark Wave > Bookmarks > View > Bookmarks > bookmark goto wave
<bookmark_name> <bookmark_name>
Delete Wave > Bookmarks > View > Bookmarks > bookmark delete wave
bookmark Bookmarks > <select Bookmarks > <select
bookmark then Delete> bookmark then Delete>

Editing Bookmarks
Once a bookmark exists, you can change its properties by selecting Wave > Bookmarks >
Bookmarks if the Wave window is docked; or by selecting Tools > Bookmarks if the Wave
window is undocked.

692 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Searching in the Wave Window

Searching in the Wave Window

The Wave window provides two methods for locating objects:
1. Finding signal names:
o Select Edit > Find.
o Click the Find toolbar button (binoculars icon) in the Home Toolbar Tab (described
in the GUI Reference Manual) when the Wave window is active
o Use the find command.
The first two of these options will open a Find mode toolbar at the bottom of the Wave
window. By default, the “Search For” option is set to “Name.” For more information,
refer to Find and Filter Functions in the GUI Reference Manual.
2. Search for values or transitions:
o Select Edit > Signal Search
o Click the Find toolbar button (binoculars icon) and select Search For > Value from
the Find toolbar that appears at the bottom of the Wave window.
o Use the search command.
Wave window searches can be stopped by clicking the “Stop Drawing” or “Break” toolbar
buttons.

Searching for Values or Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Searching for Values or Transitions

The search command lets you search for transitions or values on selected signals. When you
select Edit > Signal Search, the Wave Signal Search dialog appears.

ModelSim® SE User's Manual, v10.7 693

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Searching for Values or Transitions

Figure 14-13. Wave Signal Search Dialog Box

One option of note is Search for Expression. The expression can involve more than one signal
but is limited to signals currently in the window. Expressions can include constants, variables,
and DO files. Refer to Expression Syntax in the Command Reference Manual for more
information.

Any search terms or settings you enter are saved from one search to the next in the current
simulation. To clear the search settings during debugging click the Reset To Initial Settings
button. The search terms and settings are cleared when you close ModelSim.

Note
If your signal values are displayed in binary radix, refer to Searching for Binary Signal
Values in the GUI in the Command Reference Manual for details on how signal values are
mapped between a binary radix and std_logic.

694 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Search with the Expression Builder

Search with the Expression Builder

The Expression Builder is a feature of the Wave Signal Search dialog box. You can use it to
create a search expression that follows the GUI_expression_format, save an expression to a Tcl
variable and use it in the Expression Builder to perform a search, and search for when a signal
reaches a particular value.
Using the Expression Builder for Expression Searches . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Saving an Expression to a Tcl Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Searching for a Particular Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Evaluating Only on Clock Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Using the Expression Builder for Expression Searches

You can create a search expression that follows the GUI_expression_format.
Procedure
1. Choose Wave > Signal Search... from the main menu. This displays the Wave Signal
Search dialog box.
2. Select Search for Expression.
3. Click the Builder button. This displays the Expression Builder dialog box shown in
Figure 14-14
Figure 14-14. Expression Builder Dialog Box

4. You click the buttons in the Expression Builder dialog box to create a GUI expression.
Each button generates a corresponding element of expression syntax and is displayed in
the Expression field.

ModelSim® SE User's Manual, v10.7 695

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Search with the Expression Builder

5. In addition, you can use the Selected Signal button to create an expression from signals
you select from the associated Wave window. For example, instead of typing in a signal
name, you can select signals in a Wave window and then click Selected Signal in the
Expression Builder. This displays the Select Signal for Expression dialog box shown in
Figure 14-15.
Figure 14-15. Selecting Signals for Expression Builder

6. Note that the buttons in this dialog box allow you to determine the display of signals you
want to put into an expression:
• List only Select Signals — list only those signals that are currently selected in the
parent window.
• List All Signals — list all signals currently available in the parent window.
7. Once you have selected the signals you want displayed in the Expression Builder, click
OK.
8. Other buttons add operators of various kinds, or you can type them in. (Refer to
Expression Syntax in the Command Reference Manual for more information.)
Related Topics
GUI_expression_format.

696 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Search with the Expression Builder

Saving an Expression to a Tcl Variable

Clicking the Save button in the Expression Builder will save the expression to a Tcl variable.
Once saved, this variable can be used in place of the expression. For example, say you save an
expression to the variable "foo." Here are some operations you could do with the saved variable:
• Read the value of foo with the set command:
set foo

• Put $foo in the Expression: entry box for the Search for Expression selection.
• Issue a searchlog command using foo:
searchlog -expr $foo 0

Searching for a Particular Value

You can use the Expression Builder to search for when a signal reaches a particular value.
Procedure
1. Select a signal of interest in the Wave window.
2. Choose Wave > Signal Search from the main menu to open the Wave Signal Search
dialog box.
3. Select Search for Expression radio button.
4. Click the Builder button to open the Expression Builder.
5. Click the Selected Signal button to open the Select Signal for Expression dialog box.
6. Click the List only Selected Signals radio button.
7. Highlight the desired signal and click the OK button. This closes the Select Signal for
Expression dialog box and places the selected signal in the Expression field of the
Expression Builder.
8. Click the == button.
9. Click the value buttons or type a value.
10. Click OK to close the Expression Builder.
11. Click the Search Forward or the Search Reverse button to perform the search.

Evaluating Only on Clock Edges

You can use the Expression Builder to evaluate search expressions only on clock edges.

ModelSim® SE User's Manual, v10.7 697

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Filtering the Wave Window Display

Procedure
1. Select the clock signal in the Wave window.
2. Choose Wave > Signal Search from the main menu to open the Wave Signal Search
dialog box.
3. Select Search for Expression radio button.
4. Click the Builder button to open the Expression Builder.
5. Click the Selected Signal button to open the Select Signal for Expression dialog box.
6. Click the List All Signals radio button.
7. Highlight the desired signal you want to search and click the OK button. This closes the
Select Signal for Expression dialog box and places the selected signal in the
Expression field of the Expression Builder.
8. Click 'rising. You can also select the falling edge or both edges. Or, click the &&
button to AND this condition with the rest of the expression.
9. Click the Search Forward or the Search Reverse button to perform the search.

Filtering the Wave Window Display

The Wave window includes a filtering function that allows you to filter the display to show only
the desired signals and waveforms.
Procedure
1. To activate the filtering function:
2. Select Edit > Find in the menu bar (with the Wave window active) or click the Find
icon in the Home Toolbar Tab (described in the GUI Reference Manual). This
opens a “Find” toolbar at the bottom of the Wave window.
3. Click the binoculars icon in the Find field to open a popup menu and select Contains.
This enables the filtering function.
Related Topics
Find and Filter Functions

698 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Formatting the Wave Window

Formatting the Wave Window

The primary tool for formatting the Wave Window to fit your environment is the Wave Window
Preferences dialog box.
Setting Wave Window Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Formatting Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

ModelSim® SE User's Manual, v10.7 699

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Setting Wave Window Display Preferences

Setting Wave Window Display Preferences

You can set Wave window display preferences by selecting Wave > Wave Preferences (when
the window is docked) or Tools > Window Preferences (when the window is undocked).
These menu selections open the Wave Window Preferences dialog (Figure 14-16).

Figure 14-16. Display Tab of the Wave Window Preferences Dialog Box

Hiding/Showing Path Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

Double-Click Behavior in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Setting the Timeline to Count Clock Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

Hiding/Showing Path Hierarchy

You can set how many elements of the object path display by changing the Display Signal Path
value in the Wave Window Preferences dialog.

700 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Setting Wave Window Display Preferences

Zero specifies the full path, 1 specifies the leaf name, and any other positive number specifies
the number of path elements to be displayed (Figure 14-16).

Double-Click Behavior in the Wave Window

You can set the default behavior for double-clicking a waveform in the Wave window.
Procedure
1. In the Wave Window Preferences dialog box, select the Display tab.
2. In the Enable/Disable section, click the button after “Double-click will:” and choose
one of the following actions from the popup menu:
• Do Nothing — Double-clicking on a waveform does nothing.
• Show Drivers in Schematic — Double-clicking a waveform traces the event for the
specified signal and time back to the process causing the event. The results of the
trace are placed in a Schematic Window that includes a waveform viewer below.
Refer to Tracing to the Immediate Driving Process for more information about
tracing immediate drivers and events.
• Show Drivers in Dataflow — Double-clicking a waveform traces the event for the
specified signal and time back to the process causing the event. The results of the
trace are placed in a Dataflow Window that includes a waveform viewer below.
• Find Immediate Driver — Double-clicking a waveform traces to the immediate
driver for that signal.
• Find Active Driver — Double-clicking a waveform traces the event for the
specified signal and time back to the process causing the event. The source file
containing the line of code is opened and the driving signal code is highlighted.
• Find Root Cause — Double-clicking a waveform traces the event for the specified
signal and time back to the root cause of the event.
• Find All Drivers — Double-clicking a waveform traces to all drivers for the event.
Related Topics
Trace to the First Sequential Process

Setting the Timeline to Count Clock Cycles

You can set the timeline of the Wave window to count clock cycles rather than elapsed time.
Procedure
1. If the Wave window is docked, open the Wave Window Preferences dialog by
selecting Wave > Wave Preferences from the Main window menus.

ModelSim® SE User's Manual, v10.7 701

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Setting Wave Window Display Preferences

If the Wave window is undocked, select Tools > Window Preferences from the Wave
window menus. This opens the Wave Window Preferences dialog box.
2. In the dialog, select the Grid & Timeline tab.
3. Enter the period of your clock in the Grid Period field and select “Display grid period
count (cycle count)” (Figure 14-17).
Figure 14-17. Grid and Timeline Tab of Wave Window Preferences Dialog Box

Results
The timeline will now show the number of clock cycles, as shown in Figure 14-18.

702 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Setting Wave Window Display Preferences

Figure 14-18. Clock Cycles in Timeline of Wave Window

ModelSim® SE User's Manual, v10.7 703

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Formatting Objects in the Wave Window

Formatting Objects in the Wave Window

You can adjust various object properties to create the view you find most useful.
Select one or more objects in the Wave window pathnames pane and then select Wave >
Format from the menu bar (Figure 14-19).

Figure 14-19. Wave Format Menu Selections

Or, you can right-click the selected object(s) and select Format from the popup menu.

If you right-click the and selected object(s) and select Properties from the popup menu, you
can use the Format tab of the Wave Properties dialog to format selected objects (Figure 14-20).

Figure 14-20. Format Tab of Wave Properties Dialog

Changing Radix (base) for the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705

704 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Formatting Objects in the Wave Window

Changing Radix (base) for the Wave Window

One common adjustment is changing the radix (base) of selected objects in the Wave window.
When you right-click a selected object, or objects, and select Properties from the popup menu,
the Wave Properties dialog appears.
You can change the radix of the selected object(s) in the View tab (Figure 14-21).

Figure 14-21. Changing Signal Radix

The default radix is hexadecimal, which means the value pane lists the hexadecimal values of
the object. For the other radices - binary, octal, decimal, unsigned, hexadecimal, or ASCII - the
object value is converted to an appropriate representation in that radix.

Note
When the symbolic radix is chosen for SystemVerilog reg and integer types, the values are
treated as binary. When the symbolic radix is chosen for SystemVerilog bit and int types,
the values are considered to be decimal.

Aside from the Wave Properties dialog, there are three other ways to change the radix:

• Change the default radix for all objects in the current simulation using Simulate >
Runtime Options (Main window menu).
• Change the default radix for the current simulation using the radix command.
• Change the default radix permanently by editing the DefaultRadix variable in the
modelsim.ini file.
Setting the Global Signal Radix for Selected Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

ModelSim® SE User's Manual, v10.7 705

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Formatting Objects in the Wave Window

Setting the Global Signal Radix for Selected Objects

The Global Signal Radix feature allows you to change the radix for a selected object or objects
in the Wave window and in every other window where the object appears.
Procedure
1. Select an object or objects in the Wave window.
2. Right-click to open a popup menu.
3. Select Radix > Global Signal Radix from the popup menu. This opens the Global
Signal Radix dialog, where you can set the radix for the Wave window and other
windows where the selected object(s) appears.
Figure 14-22. Global Signal Radix Dialog in Wave Window

Sfixed and Ufixed indicate “signed fixed” and “unsigned fixed,” respectively. To
display an object as Sfixed or Ufixed the object must be an array of std_ulogic elements
between 2 and 64 bits long with a descending range. The binary point for the value is
implicitly located between the 0th and -1st elements of the array. The index range for the
type need not include 0 or -1, for example (-4 downto -8) in which case the value will be

706 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Dividing the Wave Window

extended for conversion, as appropriate. If the type does not meet these criteria the value
will be displayed as decimal or unsigned, respectively.

Dividing the Wave Window

Dividers serve as a visual aid for debugging, allowing you to separate signals and waveforms
for easier viewing. In the graphic below, a bus is separated from the two signals above it with a
divider called "Bus."
Figure 14-23. Separate Signals with Wave Window Dividers

The following procedure shows how to insert a divider.

Procedure
1. Select the signal above which you want to place the divider.
2. If the Wave pane is docked, select Add > To Wave > Divider from the Main window
menu bar. If the Wave window stands alone, undocked from the Main window, select
Add > Divider from the Wave window menu bar.
3. Specify the divider name in the Wave Divider Properties dialog. The default name is
New Divider. Unnamed dividers are permitted. Simply delete "New Divider" in the
Divider Name field to create an unnamed divider.
4. Specify the divider height (default height is 17 pixels) and then click OK.
5. You can also insert dividers with the -divider argument to the add wave command.

ModelSim® SE User's Manual, v10.7 707

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Splitting Wave Window Panes

Splitting Wave Window Panes

The pathnames, values, and waveform panes of the Wave window display can be split to
accommodate signals from one or more datasets.
Procedure
1. To split the window, select Add > Window Pane.
2. In the illustration below, the top split shows the current active simulation with the prefix
"sim," and the bottom split shows a second dataset with the prefix "gold."
3. The active split is denoted with a solid white bar to the left of the signal names. The
active split becomes the target for objects added to the Wave window.
Figure 14-24. Splitting Wave Window Panes

Related Topics
Recording Simulation Results With Datasets

708 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Wave Groups

Wave Groups
You can create a wave group to collect arbitrary groups of items in the Wave window. Wave
groups have the following characteristics:
• A wave group may contain 0, 1, or many items.
• You can add or remove items from groups either by using a command or by dragging
and dropping.
• You can drag a group around the Wave window or to another Wave window.
• You can nest multiple wave groups, either from the command line or by dragging and
dropping. Nested groups are saved or restored from a wave.do format file, restart and
checkpoint/restore.
• You can create a group that contains the input signals to the process that drives a
specified signal.
Creating a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Deleting or Ungrouping a Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Adding Items to an Existing Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Removing Items from an Existing Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

ModelSim® SE User's Manual, v10.7 709

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Creating a Wave Group

Creating a Wave Group

There are three ways to create a wave group.
Grouping Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Adding a Group of Contributing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Grouping Signals with the add wave Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Grouping Signals with a Keyboard Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

Grouping Signals through Menu Selection

If you have already added some signals to the Wave window, you can create a group of signals
using the following procedure.
Procedure
1. Select a set of signals in the Wave window.
2. Select the Wave > Group menu item.
The Wave Group Create dialog appears.
3. Complete the Wave Group Create dialog box:
• Group Name — specify a name for the group. This name is used in the wave
window.
• Group Height — specify an integer, in pixels, for the height of the space used for
the group label.
4. Ok
Results
The selected signals become a group denoted by a red diamond in the Wave window pathnames
pane (Figure 14-25), with the name specified in the dialog box.

710 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Creating a Wave Group

Figure 14-25. Wave Groups Denoted by Red Diamond

Adding a Group of Contributing Signals

You can select a signal and create a group that contains the input signals to the process that
drives the selected signal.
Procedure
1. Select a signal for which you want to view the contributing signals.

2. Click the Add Contributing Signals button in the Wave toolbar.

Results
A group with the name Contributors:<signal_name> is placed below the selected signal in the
Wave window pathnames pane (Figure 14-26).

ModelSim® SE User's Manual, v10.7 711

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Creating a Wave Group

Figure 14-26. Contributing Signals Group

Grouping Signals with the add wave Command

Add grouped signals to the Wave window from the command line use the following procedure.
Procedure
1. Determine the names of the signals you want to add and the name you want to assign to
the group.
2. From the command line, use the add wave and the -group argument.
Examples
• Create a group named mygroup containing three items:
add wave -group mygroup sig1 sig2 sig3

• Create an empty group named mygroup:

add wave -group mygroup

Grouping Signals with a Keyboard Shortcut

If you have already added some signals to the Wave window, you can create a group of signals
using the following procedure.
Procedure
1. Select the signals you want to group.
2. Ctrl-g

712 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Deleting or Ungrouping a Wave Group

Results
The selected signals become a group with a name that references the dataset and common
region, for example: sim:/top/p.
If you use Ctrl-g to group any other signals, they will be placed into any existing group for their
region, rather than creating a new group of only those signals.

Deleting or Ungrouping a Wave Group

If a wave group is selected and cut or deleted the entire group and all its contents will be
removed from the Wave window.
Likewise, the delete wave command will remove the entire group if the group name is specified.

If a wave group is selected and the Wave > Ungroup menu item is selected the group will be
removed and all of its contents will remain in the Wave window in existing order.

Adding Items to an Existing Wave Group

There are three ways to add items to an existing wave group.
1. Using the drag and drop capability to move items outside of the group or from other
windows into the group. The insertion indicator will show the position the item will be
dropped into the group. If the cursor is moved over the lower portion of the group item
name a box will be drawn around the group name indicating the item will be dropped
into the last position in the group.
2. After selecting an insertion point within a group, place the cursor over the object to be
inserted into the group, then click the middle mouse button.
3. After selecting an insertion point within a group, select multiple objects to be inserted
into the group, then click the Add Selected to Window button in the Standard
Toolbar.
4. The cut/copy/paste functions may be used to paste items into a group.
5. Use the add wave -group command.
The following example adds two more signals to an existing group called mygroup.
add wave -group mygroup sig4 sig5

Removing Items from an Existing Wave Group

You can use any of the following methods to remove an item from a wave group.
1. Use the drag and drop capability to move an item outside of the group.

ModelSim® SE User's Manual, v10.7 713

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Miscellaneous Wave Group Features

2. Use menu or icon selections to cut or delete an item or items from the group.
3. Use the delete wave command to specify a signal to be removed from the group.

Note
The delete wave command removes all occurrences of a specified name from the
Wave window, not just an occurrence within a group.

Miscellaneous Wave Group Features

Dragging a wave group from the Wave window to the List window will result in all of the items
within the group being added to the List window.
Dragging a group from the Wave window to the Transcript window will result in a list of all of
the items within the group being added to the existing command line, if any.

714 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Composite Signals or Buses

Composite Signals or Buses

You can create a composite signal or bus from arbitrary groups of items in the Wave window.
Composite signals have the following characteristics:
• Composite signals may contain 0, 1, or many items.
• You can drag a group around the Wave window or to another Wave window.
Creating Composite Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Creating Composite Signals through Menu

Selection
If you have already added some signals to the Wave window, you can create a composite signal
or bus using the following procedure.
Procedure
1. Select signals to combine:
• Shift-click signal pathnames to select a contiguous set of signals, records, and/or
buses.
• Control-click individual signal, record, and/or bus pathnames.
2. Select Wave > Combine Signals
3. Complete the Combine Selected Signals dialog box.
• Name — Specify the name of the new combined signal or bus.
• Order to combine selected items — Specify the order of the signals within the new
combined signal.
• Top down— (default) Signals ordered from the top as selected in the Wave window.
• Bottom Up — Signals ordered from the bottom as selected in the Wave window.
• Order of Result Indexes — Specify the order of the indexes in the combined signal.
• Ascending — Bits indexed [0 : n] starting with the top signal in the bus.
• Descending — (default) Bits indexed [n : 0] starting with the top signal in the bus.
• Remove selected signals after combining — Saves the selected signals in the
combined signal only.
• Reverse bit order of bus items in result — Reverses the bit order of buses that are
included in the new combined signal.

ModelSim® SE User's Manual, v10.7 715

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Saving the Window Format

• Flatten Arrays — (default) Moves elements of arrays to be elements of the new

combined signal. If arrays are not flattened the array itself will be an element of the
new combined signal.
• Flatten Records — Moves fields of selected records and signals to be elements of
the new combined signal. If records are not flattened the record itself will be an
element of the new combined signal.
Related Topics
Virtual Signals
Virtual Objects
Using the Virtual Signal Builder
Concatenation of Signals or Subelements

Saving the Window Format

By default, all Wave window information is lost once you close the window. If you want to
restore the window to a previously configured layout, you must save a window format file with
the following procedure.
Procedure
1. Add the objects you want to the Wave window.
2. Edit and format the objects to create the view you want.
3. Save the format to a file by selecting File > Save. This opens the Save Format dialog
box (Figure 14-27), where you can save waveform formats in a .do file.
Figure 14-27. Save Format Dialog

4. To use the format file, start with a blank Wave window and run the DO file in one of two
ways:
• Invoke the do command from the command line:
VSIM> do <my_format_file>

716 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Saving the Window Format

• Select File > Load.

Note
Window format files are design-specific. Use them only with the design you
were simulating when they were created.

5. In addition, you can use the write format restart command to create a single .do file that
will recreate all debug windows and breakpoints (see Saving and Restoring Breakpoints)
when invoked with the do command in subsequent simulation runs. The syntax is:
write format restart <filename>

6. If the ShutdownFile modelsim.ini variable is set to this .do filename, it will call the write
format restart command upon exit.

ModelSim® SE User's Manual, v10.7 717

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Exporting Waveforms from the Wave window

Exporting Waveforms from the Wave window

This section describes ways to save or print information from the Wave window.
Exporting the Wave Window as a Bitmap Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Saving Waveform Sections for Later Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Exporting the Wave Window as a Bitmap Image

You can export the current view of the Wave window to a Bitmap (.bmp) image with the
following procedure.
Procedure
1. Select File > Export > Image from the Main menus
2. Complete the Save Image dialog box.
Results
The saved bitmap image only contains the current view; it does not contain any signals not
visible in the current scroll region.
Note that you should not select a new window in the GUI until the export has completed,
otherwise your image will contain information about the newly selected window.

Printing the Wave Window to a Postscript File

You can export the contents of the Wave window to a Postscript (.ps) or Extended Postscript
file with the following procedure.
Procedure
1. Select File > Print Postscript from the Main menus.
2. Complete the Write Postscript dialog box.
The Write Postscript dialog box allows you to control the amount of information
exported.
• Signal Selection — allows you to select which signals are exported
• Time Range — allows you to select the time range for the given signals.
Note that the output is a simplified black and white representation of the wave window.
You can also perform this action with the write wave command.

718 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Printing the Wave Window on the Windows Platform

Printing the Wave Window on the Windows

Platform
You can print the contents of the Wave window to a networked printer with the following
procedure.
Procedure
1. Select File > Print from the Main menus.
2. Complete the Print dialog box.
The Print dialog box allows you to control the amount of information exported.
• Signal Selection — allows you to select which signals are exported
• Time Range — allows you to select the time range for the given signals.
Note that the output is a simplified black and white representation of the wave window.

ModelSim® SE User's Manual, v10.7 719

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Saving Waveform Sections for Later Viewing

Saving Waveform Sections for Later Viewing

You can choose one or more objects or signals in the waveform pane and save a section of the
generated waveforms to a separate WLF file for later viewing. Saving selected portions of the
waveform pane allows you to create a smaller dataset file.
Saving Waveforms Between Two Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Viewing Saved Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Working With Multiple Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722

Saving Waveforms Between Two Cursors

You can save a waveform section between two cursors.
Procedure
1. Place the first cursor (Cursor 1 in Figure 14-28) at one end of the portion of simulation
time you want to save.
2. Click the Insert Cursor icon to insert a second cursor (Cursor 2).

3. Move Cursor 2 to the other end of the portion of time you want to save. Cursor 2 is now
the active cursor, indicated by a bold yellow line and a highlighted name.
4. Right-click the time indicator of the inactive cursor (Cursor 1) to open a drop menu.
Figure 14-28. Waveform Save Between Cursors

720 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Saving Waveform Sections for Later Viewing

5. Select Filter Waveform to open the Wave Filter dialog box. (Figure 14-29)
Figure 14-29. Wave Filter Dialog

6. Select Selected Signals in Wave Window to save the selected objects or signals. You
can also choose to save all waveforms displayed in the Wave window between the
specified start and end time or all of the logged signals.
7. Enter a name for the file using the .wlf extension. Do not use vsim.wlf since it is the
default name for the simulation dataset and will be overwritten when you end your
simulation.

Viewing Saved Waveforms

Call up and view saved waveform sections with the following procedure.
Procedure
1. Open the saved .wlf file by selecting File > Open to open the Open File dialog and set
the “Files of type” field to Log Files (*.wlf). Then select the .wlf file you want and click
the Open button. Refer to Opening Datasets for more information.
2. Select the top instance in the Structure window
3. Select Add > To Wave > All Items in Region and Below.
4. Scroll to the simulation time that was saved. (Figure 14-30)

ModelSim® SE User's Manual, v10.7 721

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing SystemVerilog Class Objects and Class Path Expressions

Figure 14-30. Wave Filter Dataset

Working With Multiple Cursors

You can save a portion of your waveforms in a simulation that has multiple cursors set. The new
dataset will start and end at the times indicated by the two cursors chosen, even if the time span
includes another cursor.

Viewing SystemVerilog Class Objects and

Class Path Expressions
The suggested workflow for viewing SystemVerilog class objects in the Wave window is as
follows.
Prerequisites
• Specify the -classdebug argument to vsim (refer to Enabling Class Debug for more
information).
• Log the class objects you are interested in viewing (refer to Logging Class Types and
Class Instances for more information).
• Run the simulation until the specific class object(s) come into existence either by
running a [run 0] command at time 0 to complete design elaboration, or by running the
simulation until the class objects exist.
Procedure
1. Select a design unit or testbench SV class object in the Structure Window that contains
the class objects you want to see (Figure 14-31). The object will be identified as a SV
class object in the Design Unit column. All currently existing class instances associated
with that design unit or testbench item are displayed in the Class Instances window.

722 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Viewing SystemVerilog Class Objects and Class Path Expressions

(Open the Class Instances window by selecting View > Class Browser > Class
Instances from the menus or use the view class instances command.)
2. Place the class objects in the Wave window once they exist by doing one of the
following:
• Drag a class instance from the Class Instances window or the Objects window and
drop it into the Wave window.
• Select multiple objects in the Class Instances window, click and hold the Add
Selected to Window button in the Standard toolbar, then select the position of the
placement; the top of the Wave window, the end of the Wave window, or above the
anchor location The group of class instances are arranged with the most recently
created instance at the top. You can change the order of the class instances to show
the first instance at the top of the window by selecting View > Sort > Ascending.
Figure 14-31. Adding Class Objects in the Wave Window

3. You can hover the mouse over any class waveform to display information about the
class variable (Figure 14-32).

ModelSim® SE User's Manual, v10.7 723

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing SystemVerilog Class Objects and Class Path Expressions

Figure 14-32. Class Information Popup in the Wave Window

Related Topics
Working with Class Path Expressions
Logging Class Types and Class Instances
Viewing Class Instances in the Wave Window

724 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Viewing System Verilog Interfaces

Viewing System Verilog Interfaces

You can log and display scalar and array virtual interface values in the Wave and List windows.
In order to ensure that necessary visibility is maintained, run vopt with the appropriate options.
Refer to Preservation of Object Visibility for Debugging for more information.

Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

ModelSim® SE User's Manual, v10.7 725

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Working with Virtual Interfaces

Working with Virtual Interfaces

You can perform the following actions with virtual interfaces:
• Log the virtual interface with the log command. For example:
log /test2/virt

• Add a virtual interface to the List window with the add list command.
• Add a virtual interface to the Wave window with the add wave command. For example:
add wave /test2/virt

Adding Virtual Interface References to the Wave Window . . . . . . . . . . . . . . . . . . . . . . 726

Adding Virtual Interface References to the Wave Window

You can add the real interfaces that are referenced by a virtual interface.
Procedure
1. Right-click the portion of the virtual interface waveform you are interested in.
2. Select Add wave <virtual_interface>/*.
Results
The real interface objects are added to the Wave window and logged from the time they are
added.
Examples
Figure 14-33 shows the virtual interface /test2/virt logged in the Wave window with the real
interface /test2/bi1/* added at 75 ns. The nets, array and so forth in the interface /test2/bi2/* are
about to be added.

726 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Working with Virtual Interfaces

Figure 14-33. Virtual Interface Objects Added to Wave Window

ModelSim® SE User's Manual, v10.7 727

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Combining Objects into Buses

Combining Objects into Buses

You can combine signals in the Wave window into buses. A bus is a collection of signals
concatenated in a specific order to create a new virtual signal with a specific value.
A virtual compare signal (the result of a comparison simulation) is not supported for
combination with any other signal.

To combine signals into a bus, use one of the following methods:

• Select two or more signals in the Wave window and then choose Tools > Combine
Signals from the menu bar. A virtual signal that is the result of a comparison simulation
is not supported for combining with any other signal.
• Use the virtual signal command at the Main window command prompt.
In the illustration below, four signals have been combined to form a new bus called "Bus1."
Note that the component signals are listed in the order in which they were selected in the Wave
window. Also note that the value of the bus is made up of the values of its component signals,
arranged in a specific order.

Figure 14-34. Signals Combined to Create Virtual Bus

Extracting a Bus Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728

Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Extracting a Bus Slice

You can create a new bus containing a slice of a selected bus using the following procedure.
This action uses the virtual signal command.

728 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Wave Extract/Pad Bus Dialog Box

Procedure
1. In the Wave window, locate the bus and select the range of signals that you want to
extract.
2. Select Wave > Extract/Pad Slice (Hotkey: Ctrl+e) to display the Wave Extract/Pad Bus
Dialog Box.
Figure 14-35. Wave Extract/Pad Bus Dialog Box

By default, the dialog box is prepopulated with information based on your selection and
will create a new bus based on this information.
This dialog box also provides you options to pad the selected slice into a larger bus.
3. Click OK to create a group of the extracted signals based on your changes, if any, to the
dialog box.
The new bus, by default, is added to the bottom of the Wave window. Alternatively, you
can follow the directions in Inserting Signals in a Specific Location.

Wave Extract/Pad Bus Dialog Box

Use the Wave > Extract/Pad Slice menu selection to open the Wave Extract/Pad Bus dialog
box.
The features of the Wave Extract/Pad Bus dialog box (Figure 14-35) are as follows:

• Source — The name of the bus from which you selected the signals.

ModelSim® SE User's Manual, v10.7 729

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Splitting a Bus into Several Smaller Buses

• Result Name — A generated name based on the source name and the selected signals.
You can change this to a different value.
• Slice Range — The range of selected signals.
• Padding — These options allow you to create signal padding around your extraction.
o Left Pad / Value — An integer that represents the number of signals you want to
pad to the left of your extracted signals, followed by the value of those signals.
o Right Pad / Value — An integer that represents the number of signals you want to
pad to the right of your extracted signals, followed by the value of those signals.
• Transcript Commands — During creation of the bus, the virtual signal command to
create the extraction is written to the Transcript window.

Splitting a Bus into Several Smaller Buses

You can split a bus into several equal-sized buses using the following procedure. This action
uses the virtual signal command.
Procedure
1. In the Wave window, select the top level of the bus you want to split.
2. Select Wave > Split Bus (Hotkey: Ctrl+p) to display the Wave Split Bus dialog box.
3. Edit the settings of the Wave Split dialog box
• Source — (cannot edit) Shows the name of the selected signal and its range.
• Prefix — Specify the prefix to be used for the new buses.
The resulting name is of the form: <prefix><n>, where n increments for each group.
• Split Width — Specify the width of the new buses, which must divide equally into
the bus width.

730 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Using the Virtual Signal Builder

Using the Virtual Signal Builder

You can create, modify, and combine virtual signals and virtual functions and add them to the
Wave window with the Virtual Signal Builder dialog box.Virtual signals are also added to the
Objects window and can be dragged to the List, and Watch windows once they have been added
to the Wave window.
The Virtual Signal Builder dialog box is accessed by selecting Wave > Virtual Builder when
the Wave window is docked or selecting Tools > Virtual Builder when the Wave window is
undocked. (Figure 14-36)

Figure 14-36. Virtual Signal Builder

• The Name field allows you to enter the name of the new virtual signal or select an
existing virtual signal from the drop down list. Use alpha, numeric, and underscore
characters only, unless you are using VHDL extended identifier notation.
• The Editor field is a regular text box. You can enter text directly, copy and paste, or drag
a signal from the Objects, Locals, Source , or Wave window and drop it in the Editor
field.
• The Operators field allows you to select from a list of operators. Double-click an
operator to add it to the Editor field.
• The Help button provides information about the Name, Clear, and Add Text buttons,
and the Operators field (Figure 14-37).

ModelSim® SE User's Manual, v10.7 731

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Creating a Virtual Signal

Figure 14-37. Virtual Signal Builder Help

• The Clear button deletes the contents of the Editor field.

• The Add button places the virtual signal in the Wave window in the default location.
Refer to Inserting Signals in a Specific Location for more information.
• The Test button tests the syntax of your virtual signal.
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732

Creating a Virtual Signal

Use the following procedure to create a virtual signal with the Virtual Signal Builder.
Prerequisites
• An active simulation or open dataset.
• An active Wave window with objects loaded in the Pathname pane
Procedure
1. Select Wave >Virtual Builder from the main menu to open the Virtual Signal Builder
dialog box.
2. Drag one or more objects from the Wave or Object window into the Editor field.
3. Modify the object by double-clicking on items in the Operators field or by entering text
directly.

732 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Creating a Virtual Signal

Tip
Select the Help button then place your cursor in the Operator field to view syntax
usage for some of the available operators. Refer to Figure 14-36

4. Enter a string in the Name field. Use alpha, numeric, and underscore characters only,
unless you are using VHDL extended identifier notation.
5. Select the Test button to verify the expression syntax is parsed correctly.
6. Select Add to place the new virtual signal in the Wave window at the default insertion
point. Refer to Inserting Signals in a Specific Location for more information.
Figure 14-38. Creating a Virtual Signal.

Results
The virtual signal is added to the Wave window and the Objects window. An orange diamond
marks the location of the virtual signal in the wave window. (Figure 14-39)

ModelSim® SE User's Manual, v10.7 733

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Creating a Virtual Signal

Figure 14-39. Virtual Signal in the Wave Window

Related Topics
Virtual Objects
Virtual Signals
GUI_expression_format. Se also the virtual signal
virtual function

734 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Miscellaneous Tasks

Miscellaneous Tasks
The Wave window allows you to perform a wide variety of tasks, from examining waveform
values, to displaying signal drivers and readers, to sorting objects.
Examining Waveform Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736

Examining Waveform Values

You can use your mouse to display a dialog that shows the value of a waveform at a particular
time.
You can do this two ways:

• Rest your mouse pointer on a waveform. After a short delay, a dialog will pop-up that
displays the value for the time at which your mouse pointer is positioned. If you would
prefer that this popup not display, it can be toggled off in the display properties. See
Setting Wave Window Display Preferences.
• Right-click a waveform and select Examine. A dialog displays the value for the time at
which you clicked your mouse.

Displaying Drivers of the Selected Waveform

You can display the drivers of a signal selected in the Wave window in the Dataflowor the
Schematic window.
Procedure
1. You can display the signal in one of three ways:

• Select a waveform and click the Show Drivers button on the toolbar.
• Right-click a waveform and select Show Drivers from the shortcut menu
• Double-click a waveform edge (you can enable/disable this option in the display
properties dialog; see Setting Wave Window Display Preferences)
2. This operation opens the Dataflow or Schematic window and displays the drivers of the
signal selected in the Wave window. A Wave pane also opens in the Dataflow or
Schematic window to show the selected signal with a cursor at the selected time. The
Dataflow or Schematic window shows the signal(s) values at the Wave pane cursor
position.

ModelSim® SE User's Manual, v10.7 735

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Sorting a Group of Objects in the Wave Window

Related Topics
Double-Click Behavior in the Wave Window

Sorting a Group of Objects in the Wave Window

You can easily sort objects in the Wave window.
Procedure
Select View > Sort to sort the objects in the pathname and values panes.

736 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Creating and Managing Breakpoints

Creating and Managing Breakpoints

ModelSim supports both signal (that is, when conditions) and file-line breakpoints. Breakpoints
can be set from multiple locations in the GUI or from the command line.
Note
When running in full optimization mode, breakpoints may not be set. Run the design in non-
optimized mode (or set +acc arguments) to enable you to set breakpoints in the design. See
Preservation of Object Visibility for Debugging and Design Object Visibility for Designs with
PLI.

Breakpoints within SystemC portions of the design can only be set using File-Line Breakpoints.

Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738

File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743

ModelSim® SE User's Manual, v10.7 737

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Signal Breakpoints

Signal Breakpoints
Signal breakpoints (“when” conditions) instruct ModelSim to perform actions when the
specified conditions are met. For example, you can break on a signal value or at a specific
simulator time. When a breakpoint is hit, a message in the Main window transcript identifies the
signal that caused the breakpoint.
Setting Signal Breakpoints with the when Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Setting Signal Breakpoints with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Modifying Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

Setting Signal Breakpoints with the when Command

ModelSim allows you to set a breakpoint with a simple command line instruction.
Procedure
Use the when command to set a signal breakpoint from the VSIM> prompt.

Examples
The command:

when {errorFlag = '1' OR $now = 2 ms} {stop}

adds 2 ms to the simulation time at which the “when” statement is first evaluated, then stops.
The white space between the value and time unit is required for the time unit to be understood
by the simulator.

Related Topics
when

Setting Signal Breakpoints with the GUI

Signal breakpoints are most easily set in the Objects and Wave windows.
Procedure
Right-click a signal and select Insert Breakpoint from the context menu.

Results
A breakpoint is set on that signal and will be listed in the Modify Breakpoints dialog accessible
by selecting Tools > Breakpoints from the Main menu bar.

738 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Signal Breakpoints

Modifying Signal Breakpoints

You can easily modify the signal breakpoints you have created.
Procedure
1. Select Tools > Breakpoints from the Main menus.
2. This will open the Modify Breakpoints dialog (Figure 14-40), which displays a list of all
breakpoints in the design.
Figure 14-40. Modifying the Breakpoints Dialog

3. When you select a signal breakpoint from the list and click the Modify button, the Signal
Breakpoint dialog (Figure 14-41) opens, allowing you to modify the breakpoint.

ModelSim® SE User's Manual, v10.7 739

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Signal Breakpoints

Figure 14-41. Signal Breakpoint Dialog

740 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
File-Line Breakpoints

File-Line Breakpoints
File-line breakpoints are set on executable lines in your source files. When the line is hit, the
simulator stops and the Source window opens to show the line with the breakpoint. You can
change this behavior by editing the PrefSource(OpenOnBreak) variable.
Since C Debug is invoked when you set a breakpoint within a SystemC module, your C Debug
settings must be in place prior to setting a breakpoint. See Setting Up C Debug for more
information. Once invoked, C Debug can be exited using the C Debug menu.

Setting File-Line Breakpoints Using the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . 741

Setting File-Line Breakpoints Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Modifying a File-Line Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

Setting File-Line Breakpoints Using the bp Command

ModelSim allows you to set a file-line breakpoint with a simple command line instruction.
Procedure
Use the bp command to set a file-line breakpoint from the VSIM> prompt.

Examples
The command

bp top.vhd 147

sets a breakpoint in the source file top.vhd at line 147.

Related Topics
Simulator GUI Preferences

Setting File-Line Breakpoints Using the GUI

File-line breakpoints are most easily set using your mouse in the Source window.
Procedure
1. Position your mouse cursor in the line number column next to a red line number (which
indicates an executable line) and click the left mouse button. A red ball denoting a
breakpoint will appear (Figure 14-42).

ModelSim® SE User's Manual, v10.7 741

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
File-Line Breakpoints

Figure 14-42. Breakpoints in the Source Window

2. The breakpoints are toggles. Click the left mouse button on the red breakpoint marker to
disable the breakpoint. A disabled breakpoint will appear as a black ball. Click the
marker again to enable it.
3. Right-click the breakpoint marker to open a context menu that allows you to Enable/
Disable, Remove, or Edit the breakpoint. create the colored diamond; click again to
disable or enable the breakpoint.
Related Topics
Source Window

Modifying a File-Line Breakpoint

You can easily modify a file-line breakpoints.
Procedure
1. Select Tools > Breakpoints from the Main menus. This will open the Modify
Breakpoints dialog (Figure 14-40), which displays a list of all breakpoints in the design.
2. When you select a file-line breakpoint from the list and click the Modify button, the File
Breakpoint dialog (Figure 14-43) opens, allowing you to modify the breakpoint.

742 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Saving and Restoring Breakpoints

Figure 14-43. File Breakpoint Dialog Box

Saving and Restoring Breakpoints

Command line instructions allow you to save and restore breakpoints.
Procedure
1. Use the write format restart command to create a .do file that will recreate all debug
windows, all file/line breakpoints, and all signal breakpoints created with the when
command. The syntax is:
write format restart <filename>

2. If the ShutdownFile modelsim.ini variable is set to this .do filename, it will call the write
format restart command upon exit.
Results
The file created is primarily a list of add list, or add wave, and configure commands, though a
few other commands are included. This file may be invoked with the do command to recreate
the window format on a subsequent simulation run.

ModelSim® SE User's Manual, v10.7 743

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Waveform Compare

Waveform Compare
The ModelSim Waveform Compare feature allows you to compare simulation runs. Differences
encountered in the comparison are summarized and listed in the Main window transcript and are
shown in the Wave and List windows.
In addition, you can write a list of the differences to a file using the compare info command.

The basic steps for running a comparison are as follows:

1. Run one simulation and save the dataset. For more information on saving datasets, see
Saving a Simulation to a WLF File.
2. Run a second simulation.
3. Setup and run a comparison.
4. Analyze the differences in the Wave or List window.
Mixed-Language Waveform Compare Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Setting Up a Comparison with the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Adding Signals, Regions, and Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Viewing Differences in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Viewing Differences in Textual Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Saving and Reloading Comparison Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Comparing Hierarchical and Flattened Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

Mixed-Language Waveform Compare Support

Mixed-language compares are supported as listed in the following table:

Table 14-8. Mixed-Language Waveform Compares

Language Compares
C/C++ types bool, char, unsigned char
short, unsigned short
int, unsigned int
long, unsigned long

744 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Mixed-Language Waveform Compare Support

Table 14-8. Mixed-Language Waveform Compares (cont.)

Language Compares
SystemC types sc_bit, sc_bv, sc_logic, sc_lv
sc_int, sc_uint
sc_bigint, sc_biguint
sc_signed, sc_unsigned
Verilog types net, reg
The number of elements must match for vectors; specific indexes are ignored.

ModelSim® SE User's Manual, v10.7 745

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Three Options for Setting up a Comparison

Three Options for Setting up a Comparison

There are three options for setting up a comparison:
• Comparison Wizard – A series of dialogs that take you through the process
• Comparison commands – Use a series of compare commands
• GUI – Use various dialogs to “manually” configure the comparison
Using the Comparison Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Comparison Graphic Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Comparison Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Using the Comparison Wizard

The simplest method for setting up a comparison is using the Comparison Wizard. The wizard
is a series of dialogs that walks you through the process.
Procedure
To start the Wizard, select Tools > Waveform Compare > Comparison Wizard from either
the Wave or Main window.

The graphic below shows the first dialog in the Wizard. As you can see from this
example, the dialogs include instructions on the left-hand side.
Figure 14-44. Waveform Comparison Wizard

746 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Setting Up a Comparison with the GUI

Comparison Graphic Interface

You can also set up a comparison via the GUI without using the Wizard.
The steps of this process are described further in Setting Up a Comparison with the GUI.

Comparison Commands
There are numerous commands that give you complete control over a comparison. These
commands can be entered in the Transcript window or run via a DO file. The commands are
detailed in the Reference Manual, but the following example shows the basic sequence:
compare start gold vsim
compare add /*
compare run

This example command sequence assumes that the gold.wlf reference dataset is loaded with the
current simulation, the vsim.wlf dataset. The compare start command instructs ModelSim to
compare the reference gold.wlf dataset against the current simulation. The compare add /*
command instructs ModelSim to compare all signals in the gold.wlf reference dataset against all
signals in the vsim.wlf dataset. The compare run command runs the comparison.

Comparing Signals with Different Names

You can use the compare add command to specify a comparison between two signals with
different names.

Setting Up a Comparison with the GUI

Use the following procedure to setup a comparison with the GUI.
Prerequisites
Waveform Compare is initiated from either the Main or Wave window by selecting Tools
>Waveform Compare > Start Comparison.

Procedure
1. Initiate the comparison by specifying the reference and test datasets. See Starting a
Waveform Comparison for details.
2. Add objects to the comparison. See Adding Signals, Regions, and Clocks for details.
3. Specify the comparison method. See Specifying the Comparison Method for details.
4. Configure comparison options. See Setting Compare Options for details.
5. Run the comparison by selecting Tools > Waveform Compare > Run Comparison.
6. View the results.

ModelSim® SE User's Manual, v10.7 747

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Setting Up a Comparison with the GUI

Related Topics
Viewing Differences in the Wave Window
Viewing Differences in the List Window
Viewing Differences in Textual Format

748 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Starting a Waveform Comparison

Starting a Waveform Comparison

The Start Comparison dialog box allows you define the Reference and Test datasets. Select
Tools >Waveform Compare > Start Comparison to open the dialog box.
Figure 14-45. Start Comparison Dialog

Reference Dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

Test Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

Reference Dataset
The Reference Dataset is the .wlf file to which the test dataset will be compared. It can be a
saved dataset, the current simulation dataset, or any part of the current simulation dataset.

Test Dataset
The Test Dataset is the .wlf file that will be compared against the Reference Dataset. Like the
Reference Dataset, it can be a saved dataset, the current simulation dataset, or any part of the
current simulation dataset.
Once you click OK in the Start Comparison dialog box, ModelSim adds a Compare tab to the
Main window.

ModelSim® SE User's Manual, v10.7 749

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Starting a Waveform Comparison

Figure 14-46. Compare Tab in the Workspace Pane

After adding the signals, regions, and/or clocks you want to use in the comparison (see Adding
Signals, Regions, and Clocks), you will be able to drag compare objects from this tab into the
Wave and List windows.

750 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Adding Signals, Regions, and Clocks

Adding Signals, Regions, and Clocks

To designate the signals, regions, or clocks to be used in the comparison, click Tools >
Waveform Compare > Add.
Adding Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Adding Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Adding Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752

Adding Signals
Add signals for a waveform comparison using the Structure Browser as follows.
Procedure
1. Select Tools > Waveform Compare > Add > Compare by Signal in the Wave window to
open the structure_browser window.
2. Highlight the signals to be used in the comparison.
3. Click the OK button.
Figure 14-47. Structure Browser

Adding Regions
Rather than comparing individual signals, you can also compare entire regions of your design.
Procedure
1. Select Tools > Waveform Compare > Add > Compare by Region to open the Add
Comparison by Region dialog.

ModelSim® SE User's Manual, v10.7 751

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Adding Signals, Regions, and Clocks

2. Enter the desired region into the Reference Region field or click the Browse button to
search for and select the desired region.
3. Click the “Specify a different name for Test Region” if you want to give the Test Region
a different name.
4. Select from the “Compare Signals of Type” options.
5. Click the OK button.
Figure 14-48. Add Comparison by Region Dialog

Adding Clocks
You add clocks when you want to perform a clocked comparison.
Related Topics
Specifying the Comparison Method

752 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Specifying the Comparison Method

Specifying the Comparison Method

The Waveform Compare feature provides two comparison methods:
• Continuous comparison — Test signals are compared to reference signals at each
transition of the reference. Timing differences between the test and reference signals are
shown with rectangular red markers in the Wave window and yellow markers in the List
window.
• Clocked comparisons — Signals are compared only at or just after an edge on some
signal. In this mode, you define one or more clocks. The test signal is compared to a
reference signal and both are sampled relative to the defined clock. The clock can be
defined as the rising or falling edge (or either edge) of a particular signal plus a user-
specified delay. The design need not have any events occurring at the specified clock
time. Differences between test signals and the clock are highlighted with red diamonds
in the Wave window.
To specify the comparison method, select Tools > Waveform Compare > Options and select
the Comparison Method tab.

Figure 14-49. Comparison Methods Tab

Continuous Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754

Continuous Comparison
Continuous comparisons are the default. You have the option of specifying leading and trailing
tolerances and a when expression that must evaluate to true or 1 at the signal edge for the
comparison to become effective.

ModelSim® SE User's Manual, v10.7 753

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Setting Compare Options

Clocked Comparison
To specify a clocked comparison you must define a clock in the Add Clock dialog. You can
access this dialog via the Clocks button in the Comparison Method tab or by selecting Tools >
Waveform Compare > Add > Clocks.
Figure 14-50. Adding a Clock for a Clocked Comparison

Setting Compare Options

There are a few global options that you can set for a comparison.
Procedure
1. Select Tools > Waveform Compare > Options to open the Comparison Options dialog
box (Figure 14-51).
2. The General Options tab in this dialog allow you to set the maximum number of
differences allowed before the comparison terminates, specify signal value matching
rules, and save or reset the defaults.

754 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Setting Compare Options

Figure 14-51. Waveform Comparison Options

ModelSim® SE User's Manual, v10.7 755

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing Differences in the Wave Window

Viewing Differences in the Wave Window

The Wave window provides a graphic display of comparison results. Pathnames of all test
signals included in the comparison are denoted by yellow triangles. Test signals that contain
timing differences when compared with the reference signals are denoted by a red X over the
yellow triangle.
Figure 14-52. Viewing Waveform Differences in the Wave Window

The names of the comparison objects take the form:

<path>/\refSignalName<>testSignalName\

If you compare two signals from different regions, the signal names include the uncommon part
of the path.

Timing differences are also indicated by red bars in the vertical and horizontal scroll bars of the
waveform display, and by red difference markers on the waveforms themselves. Rectangular
difference markers denote continuous differences. Diamond difference markers denote clocked
differences. Placing your mouse cursor over any difference marker will initiate a popup display
that provides timing details for that difference.

If the total number of differences between test and reference signals exceeds the maximum
difference limit, a yellow marker appears in the horizontal scroll bar, showing where waveform
comparison was terminated and no data was collected. You can set the difference limit in the

756 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Viewing Differences in the Wave Window

Waveform Comparison Options dialog box or with the compare options or compare start
commands.

The values column of the Wave window displays the words "match","diff", or “No Data” for
every test signal, depending on the location of the selected cursor. "Match" indicates that the
value of the test signal matches the value of the reference signal at the time of the selected
cursor. "Diff" indicates a difference between the test and reference signal values at the selected
cursor. “No Data” indicates that the cursor is placed in an area where comparison of test and
reference signals stopped.

In comparisons of signals with multiple bits, you can display them in "buswise" or "bitwise"
format. Buswise format lists the busses under the compare object whereas bitwise format lists
each individual bit under the compare object. To select one format or the other, click your right
mouse button on the plus sign (’+’) next to a compare object.

Annotating Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

Compare Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

Annotating Differences
You can tag differences with textual notes that are included in the difference details popup and
comparison reports.
Procedure
Use either of the following methods to turn on annotations:

• Click a difference with the right mouse button, and select Annotate Diff.
• Use the compare annotate command.

Compare Icons
The Wave window includes six comparison icons that let you quickly jump between
differences. From left to right, the icons do the following: find first difference, find previous
annotated difference, find previous difference, find next difference, find next annotated
difference, find last difference.

Use these icons to move the selected cursor.

These icons allow you to cycle through differences on all signals. To view differences for just
the selected signal, press <tab> and <shift - tab> on your keyboard.

ModelSim® SE User's Manual, v10.7 757

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Viewing Differences in the List Window

Note
If you have differences on individual bits of a bus, the compare icons will stop on those
differences but <tab> and <shift - tab> will not.

The compare icons cycle through comparison objects in all open Wave windows. If you have
two Wave windows displayed, each containing different comparison objects, the compare icons
will cycle through the differences displayed in both windows.

Viewing Differences in the List Window

Compare objects can be displayed in the List window too. Differences are highlighted with a
yellow background. Tabbing on selected columns moves the selection to the next difference
(actually difference edge). Shift-tabbing moves the selection backwards.
Figure 14-53. Waveform Differences in the List Window

Right-clicking on a yellow-highlighted difference gives you three options: Diff Info, Annotate
Diff, and Ignore/Noignore diff. With these options you can elect to display difference
information, you can ignore selected differences or turn off ignore, and you can annotate
individual differences.

Viewing Differences in Textual Format

You can also view text output of the differences either in the Transcript pane of the Main
window or in a saved file.

758 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Saving and Reloading Comparison Results

Procedure
1. To view differences in the transcript, select Tools > Waveform Compare >
Differences > Show.
2. To save differences to a text file, select Tools > Waveform Compare > Differences >
Write Report.

Saving and Reloading Comparison Results

To save comparison results for future use, you must save both the comparison setup rules and
the comparison differences.
Procedure
1. To save the rules, select Tools > Waveform Compare > Rules > Save. This file will
contain all rules for reproducing the comparison. The default file name is "compare.rul."
2. To save the differences, select Tools > Waveform Compare > Differences > Save. The
default file name is "compare.dif."
3. To reload the comparison results at a later time, select Tools > Waveform Compare >
Reload and specify the rules and difference files.
Figure 14-54. Reloading and Redisplaying Compare Differences

Comparing Hierarchical and Flattened Designs

If you are comparing a hierarchical RTL design simulation against a flattened synthesized
design simulation, you may have different hierarchies, different signal names, and the buses
may be broken down into one-bit signals in the gate-level design. All of these differences can be
handled by ModelSim’s Waveform Compare feature.
• If the test design is hierarchical but the hierarchy is different from the hierarchy of the
reference design, you can use the compare add command to specify which region path in
the test design corresponds to that in the reference design.

ModelSim® SE User's Manual, v10.7 759

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Comparing Hierarchical and Flattened Designs

• If the test design is flattened and test signal names are different from reference signal
names, the compare add command allows you to specify which signal in the test design
will be compared to which signal in the reference design.
• If, in addition, buses have been dismantled, or "bit-blasted", you can use the -rebuild
option of the compare add command to automatically rebuild the bus in the test design.
This will allow you to look at the differences as one bus versus another.
If signals in the RTL test design are different in type from the synthesized signals in the
reference design – registers versus nets, for example – the Waveform Compare feature will
automatically do the type conversion for you. If the type differences are too extreme (say
integer versus real), Waveform Compare will let you know.

760 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 15
Schematic Window

The Schematic window provides an implementation view of your design, allowing you to see
design structure, connectivity, and hierarchy without consulting the RTL. It allows you to
explore the “physical” connectivity of your design; to trace events that propagate through the
design; and to identify the cause of unexpected outputs.
Figure 15-1. Schematic Window

The Schematic window displays both synthesizable and non-synthesizable parts of your design.
For the synthesizable parts, the Schematic window will:

• Show connectivity between components and separate data paths from control paths
• Identify clock and event triggers
• Separate combinational (Mux, Gates, Tristates) and sequential logic (Flops)
• Infer RAM/ROM blocks
In addition, integrated features like Causality Traceback and fan-in/fan-out trace help you
explore and debug the synthesizable parts of your design.

Non-synthesizable constructs are enclosed in black boxes in the Schematic window display, and
connectivity with surrounding context is maintained.

ModelSim® SE User's Manual, v10.7 761

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window

Schematic Window Usage Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

Live Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Two Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Features of the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Common Tasks for Schematic Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Adding Objects to the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Display a Structural Overview in the Full View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Exploring the Schematic Connectivity of the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . 777
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . 787
Finding Objects by Name in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Annotating with Sticky Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Automatically Tracing All Paths Between Two Nets in the Schematic Window . . . . . . . 791
Symbol Mapping in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Schematic Window Graphic Interface FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
What Can I View in the Schematic Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 797
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
How do I Configure Schematic Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

762 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Schematic Window Usage Flows

Schematic Window Usage Flows

The Schematic window can be used to debug the design during simulation, or to perform post-
simulation debugging.
To enable the full debug capabilities of the Schematic window, you must create a debug
database at design load time, before elaboration. The database specifies the combinatorial and
sequential elements of your design. Then, the data generated during a simulation run is logged
into the database for immediate debugging or post-sim debugging.

Live Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764

Live Simulation Schematic Debug Flow

Set up your simulation to perform schematic debug tasks during a live simulation.
Procedure
1. Create a library for your work.
vlib <library_name>

2. Compile your design.

vlog/vcom <design_name>

3. Optimize your design.

vopt +acc <design_name> -o <optimized_design_name> -debugdb

The +acc argument enables full visibility into the design for debugging purposes.
The -o argument is required for naming the optimized design object.
The -debugdb argument collects combinatorial and sequential logic data into the work
library.

Note
The +acc argument supports selective visibility into your design in order to reduce
the size of the debugging database. For example, if your testbench has an instance
called “instDut” of the design under test, you can use vopt -debugdb +acc+'/instDut' to
generate a debug database for only that instance.

4. Load the design.

vsim -debugdb[=<dbname>] <optimized_design_name>

The -debugdb argument creates a debug database, <dbname>, in the current working
directory. If you do not assign a database name with [=<dbname>], the default file name
vsim.dbg. This database contains annotated schematic connectivity information.

ModelSim® SE User's Manual, v10.7 763

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Post Simulation Schematic Debug Flow

5. Log simulation data.

log -r /*

It is advisable to log the entire design. This will provide the historic values of the events
of interest plus its drivers. To reduce overhead, you may choose to log only the regions
of interest.
You may use the log command to simply save the simulation data to the .wlf file; or, use
the add wave command to log the simulation data to the .wlf file and display simulation
results as waveforms in the Wave window.
6. Run the simulation.
7. Debug your design using the Schematic window.
8. Exit the simulation.

Note
The Schematic window will not function without an extended dataflow license. If
you attempt to create the debug database (vsim -debugdb) without this license, the
following error message will appear:

Error: (vsim-3304) You are not authorized to use -debugdb,

no extended dataflow license exists.

Post Simulation Schematic Debug Flow

Set up your environment to perform schematic debug tasks after a simulation has been
completed.
The post-simulation debug flow for Schematic analysis is most commonly used when you are
performing simulations of large designs in a simulation “farm,” in which simulation results are
gathered over extended periods and saved for analysis at a later date.

Prerequisites
• Set up your simulation, similarly to the process defined in the section “Live Simulation
Schematic Debug Flow”.
Procedure
1. Start ModelSim by doing either of the following:
• (Linux) Type vsim in a Linux shell, at the prompt.
• (Windows) Double-click a ModelSim icon.
2. Select File > Change Directory and change to the directory where the post-simulation
debug database resides.

764 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Post Simulation Schematic Debug Flow

3. Recall the post-simulation debug database with the following command:

vsim -view <db_pathname.wlf>

ModelSim opens the .wlf dataset and its associated debug database (.dbg file with the
same basename), if it can be found. If ModelSim cannot find db_pathname.dbg, it will
attempt to open vsim.dbg.

ModelSim® SE User's Manual, v10.7 765

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Two Schematic Views

Two Schematic Views

The Schematic window provides two views of the design — a Full View, which is a structural
overview of the design hierarchy; and an Incremental View, which uses Click-and-Sprout
actions to incrementally add to the selected net's fanout. All top level menus, pop-up menus, and
preferences are the same for both modes.
• The Full View provides the connectivity information between various components of a
module/architecture. The initial layout of the Full View is process-based, that is, the
initial granularity is process level. Once the initial view is available, you can unfold any
process to see the logic inside the process and can fold it back whenever you want. The
Follow mode (Figure 15-2) allows the Full View to synchronize with the Incremental
View.
• The Incremental View displays the logical gate equivalent of the RTL portion of the
design, making it easier to understand the intent of the design. It allows you to start by
displaying only a net or block, and then double-click the net to sprout drivers and
readers. It is ideal for design debugging, allowing you to explore design connectivity by
tracing signal readers/drivers to determine where and why signals change values at
various times.
The “View” mode indicator is displayed in the top left corner of the window (Figure 15-2). You
can toggle back and forth between views by simply clicking this “View” indicator.

Figure 15-2. Schematic View Indicator

The logic of connectivity inside a process in the Full view is exactly same as in the Incremental
view. All processes that have any logic inside them are marked as blue boxes with a dotted
boundary, while un-synthesizable/black box processes (like initial blocks) are shown as boxes
with a solid boundary. If a process has less than 4 gates inside, the logic inside that box is shown
in the initial layout itself and the process boundary in such cases is removed.

If a module/process is identified as having the potential to take a large amount of processing

time you will receive a popup warning, and you will have the choice to stop the processing.

You can only add instances to the Full view with the right- click popup menu in the Structure
(sim) window, with a command issued at the command line interface (such as: add schematic
-full <design unit>), or by simply dragging and dropping into the Schematic window.

766 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Features of the Incremental View

In the Full view mode, you may select any net and add it to the Incremental view using the
right-click menu, and add the net to the current window or to a new window (Figure 15-3).

Figure 15-3. Schematic Add to Menu

On module port signals, the direction of cursor arrow will be changed to either a left arrow, a
right arrow, or a double sided arrow to indicate the port direction as input, output, or inout.
Clicking on those ports sprouts the connected hierarchy.

Features of the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Features of the Incremental View

The Schematic window provides the following features for getting design information from the
Incremental view.
• The Incremental view displays design primitives – logic gates, buffers, fifos, muxs, and
so on – as commonly recognized symbols for easy identification.
• Colors help you identify different design elements. For example, light gray boxes denote
VHDL architectures and Verilog modules. Blue boxes denote processes (Figure 15-4).
Solid blue boxes with dashed white borders denote folded instances (see Folding and
Unfolding Instances in the Incremental View).

ModelSim® SE User's Manual, v10.7 767

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Features of the Incremental View

Figure 15-4. Colors Help Identify Architectures, Modules, and Processes

• You may customize the Incremental view with the Schematic > Show menu selection,
or by right-clicking the Incremental view and selecting Show to open the display options
(Figure 15-5). By default, all displayed signal values are for the current active time, as
displayed in the Current Time label.
Figure 15-5. Show Incremental View Annotation

768 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Features of the Incremental View

• Hovering the mouse cursor over a design object opens a tooltip (text popup box) that
displays design object information for the specific object type. For example, the tooltip
for a module displays the module name, design unit type, and design unit path as shown
in Figure 15-6.
Figure 15-6. Hover Mouse for Tooltip

The tooltip for a signal net displays the net name and its value at the current time.
• Double-click any object in the Incremental view to view its source code in a Code
Preview window. The code for the selected object is highlighted (Figure 15-7).
Figure 15-7. Code Preview Window

The Code Preview window includes a four-button toolbar that provides the options shown in
Table 15-1

ModelSim® SE User's Manual, v10.7 769

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Features of the Incremental View

Table 15-1. Code Preview Toolbar Buttons

View in Source Editor — Opens the code in an annotated
source code window where the code can be edited.
Recenter on Target Line — Recenters the highlighted
code so it appears in the center of the Code Preview.
Copy Selection — Copies the selected code so it can be
pasted into another point in the code, or to a text editor.
Find — Opens a Find toolbar at the bottom of the Code
Preview window, allowing you to search for a signal, net,
register or instance by name. See Finding Objects by Name
in the Schematic Window.

770 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Common Tasks for Schematic Debugging

Common Tasks for Schematic Debugging

Common tasks for current and post-simulation debugging using the Schematic window include
adding objects to the Incremental View, exploring the schematic connectivity of the design,
folding and unfolding instances, using abstract blocks, tracing events, and finding objects.
Adding Objects to the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Display a Structural Overview in the Full View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Exploring the Schematic Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . 777
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . 787
Finding Objects by Name in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Annotating with Sticky Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Automatically Tracing All Paths Between Two Nets in the Schematic Window. . . . . . 791

Adding Objects to the Incremental View

You can add objects to the Incremental View by starting with only a net or block, and then
double-clicking the net to sprout drivers and readers. This is an ideal method for design
debugging, allowing you to explore design connectivity by tracing signal readers/drivers.
Procedure
You can use any of the following methods to add objects to the Schematic window’s
Incremental View.

• Drag and drop objects from other windows. Both nets and instances may be dragged
and dropped. Dragging an instance will result in the addition of all nets connected to
that instance.
• Use the Add > To Schematic menu options:
o Selected Signals— Display selected signals
o Signals in Region— Display all signals from the current region.
o Signals in Design— Clear the window and display all signals from the entire
design.

ModelSim® SE User's Manual, v10.7 771

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Display a Structural Overview in the Full View

• Select the object(s) you want placed in the Schematic Window, then click-and-hold
the Add Selected to Window Button in the Standard toolbar and select Add to
Schematic.

• Use the add schematic command.

Results
When you view regions or entire nets, the window initially displays only the drivers of the
added objects. You can easily view readers as well by selecting an object, right-clicking the
object, then selecting Expand Net To > Readers from the popup menu.

Display a Structural Overview in the Full View

You can display a structural overview of your entire design, or a region of the design in the
Schematic window’s Full View.
Procedure
1. Click the Follow box in the Schematic View indicator (Figure 15-8).
Figure 15-8. The Follow Box in the Full View

When the Follow box is checked, any design unit you select in the Structure window is
displayed in the Full View.
2. If you then select a specific signal in the Objects windows, the selected signal is
highlighted in the Full View.
In other words, the Full View follows the selections you make in other windows that are
dynamically connected to the Schematic window. It allows you to quickly find specific
signals within the overall design schematic.

772 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Exploring the Schematic Connectivity of the Design

Exploring the Schematic Connectivity of the Design

A primary use of the Incremental view is to explore the “physical” connectivity of your design.
Investigating Connectivity Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Limiting the Schematic Display of Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Controlling the Schematic Display of Redundant Buffers and Inverters. . . . . . . . . . . . 775
Tracking Your Path Through the Design with Highlighting. . . . . . . . . . . . . . . . . . . . . . 776

Investigating Connectivity Elements

When you hover the mouse over any signal it changes from a solid to a dashed line, giving you
a quick visual indicator of where you are in your design and how design elements are
connected. You can explore connectivity further by expanding the view from process to
process, allowing you to see the drivers and readers of a particular signal, net, or register.
You can expand the view of your design using menu selections or your mouse.

Procedure
1. Hover your mouse over a signal pin. The mouse cursor will change to a right-pointing or
left-pointing arrow.
2. If the arrow points to the right, you can double-click the pin to expand the net’s fanout to
its readers. If the arrow points left, you can double-click the pin to expand the net’s
fanout to its drivers (Figure 15-9).
Figure 15-9. Left-Pointing Mouse Arrow Indicates Drivers

You can change the default click-and-sprout expansion mode from a double-click of the
left mouse button to a single click by pressing the C shortcut key. (See How do I Use
Keyboard Shortcuts?)
A double-headed arrow that points in both directions indicates an inout signal pin, with
drivers and readers (Figure 15-10).

ModelSim® SE User's Manual, v10.7 773

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Exploring the Schematic Connectivity of the Design

Figure 15-10. Double-Headed Arrow Indicates Inout with Drivers and Readers

3. To expand with the mouse, simply double-click a signal pin. Depending on the specific
pin you double-click, the view will expand to show the driving process and
interconnecting nets, the reading process and interconnecting nets, or both.
4. Alternatively, you can select a signal, register, or net, and use one of the toolbar buttons
in the first column of Table 15-2; or, right-click the selected item and make the menu
selection described in the second column of Table 15-2.

Table 15-2. Icon and Menu Selections for Exploring Design Connectivity
Expand net to all drivers Expand Net To > Drivers
display driver(s) of the selected signal, net, or
register
Expand net to all drivers and readers Expand Net To > Drivers &
display driver(s) and reader(s) of the selected signal, Readers
net, or register
Expand net to all readers Expand Net To > Readers
display reader(s) of the selected signal, net, or
register

As you expand the view, the layout of the design may adjust to show the connectivity
more clearly. For example, the location of an input signal may shift from the bottom to
the top of a process.
5. Use the Regenerate button in the Schematic Toolbar (refer to Schematic Toolbar in the
GUI Reference Manual) to automatically clear and redraw either the Incremental or the
Full view in order to better display schematic information. For example, if you turn on
signal values, some values for the pins of adjacent processes may overlap, and clicking
the Regenerate button automatically redraws the schematic so values do not overlap.

774 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Exploring the Schematic Connectivity of the Design

Limiting the Schematic Display of Readers

Some nets (such as a clock) in a design can have many readers. This can cause the display to
draw numerous processes that you do not want to see when expanding the selected signal, net,
or register. Use this procedure to limit the display of readers.
Procedure
1. Select Tools > Edit Preferences to open the Preferences dialog box.
2. Select the By Name tab.
3. Click the ‘+’ sign next to the Schematic preference item.
4. Scroll to the outputquerylimit and click (LMB) to select it.
5. Click the Change Value button to open the Change Schematic Preference Value dialog
box.
Figure 15-11. Change Schematic Preference Value Dialog Box

6. Set the limit for the number of readers to be drawn and click the OK button.
7. The schematic display tests for the number of readers to be drawn and compares that
number to a limit that you set in Schematic Preferences. The default value of this limit is
100 (if you set outputquerylimit to 0, the test is not done). If this limit is exceeded, a
dialog box asks whether you want all readers to be drawn. If you choose No, then no
readers are displayed.

Note
This limit does not affect the display of drivers.

Controlling the Schematic Display of Redundant Buffers

and Inverters
The Schematic window automatically traces a signal through buffers and inverters. This can
cause chains of redundant buffers or inverters to be displayed in the Schematic window. You
can collapse these chains of buffers or inverters to make the design displayed in the Schematic
window more compact.

ModelSim® SE User's Manual, v10.7 775

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Exploring the Schematic Connectivity of the Design

Procedure
To change the display of redundant buffers and inverters in either the Incremental or Full views,
select Schematic > Preferences to open the Schematic Options dialog. The default setting is to
display both redundant buffers and redundant inverters (Figure 15-12).

Figure 15-12. Redundant Buffers and Inverters

Tracking Your Path Through the Design with Highlighting

Schematic highlighting allows you to trace a path through the design.
Procedure
1. Highlight any selected trace with any color of your choice by right-clicking Schematic
window and selecting Highlight > Add from the popup menu (Figure 15-13).
Figure 15-13. Highlight Selected Trace with Custom Color

You can then choose from one of five pre-defined colors, or Customize to choose from
the palette in the Preferences dialog box.
2. Clear highlighting using the Schematic > Highlight > Remove menu selection or by
clicking the Remove All Highlights icon in the toolbar. If you click and hold the

776 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Folding and Unfolding Instances in the Incremental View

Remove All Highlights icon a dropdown menu appears, allowing you to remove the
selected highlights

Folding and Unfolding Instances in the Incremental

View
The Fold/Unfold feature reduces schematic clutter and allows you to focus on the surrounding
logic of interest. Contents of complex instances are folded (hidden) inside a box to maximize
screen space and improve the readability of the schematic.
Folded instances are indicated by dark blue squares with dashed light gray borders. When you
hover the mouse cursor over a folded instance, the tooltip (text box popup) will show that it is
**FOLDED** (Figure 15-14).

Figure 15-14. Folded Instances

Procedure
1. To unfold an instance and display its contents, do either of the following:
• Double-click the folded instance.
• Click the folded instance to select it, then right-click and select Fold/Unfold from
the popup menu.
2. To fold and instance, do either of the following:
• Ctrl + double-click the instance.
• Click the instance to select it, then right-click and select Fold/Unfold from the
popup menu.

ModelSim® SE User's Manual, v10.7 777

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Using Abstract Blocks

Results
If you have not traced any signals into a folded instance (for example, if you simply dragged an
instance into the incremental view) and then you unfold it, this action will only make the
instance box transparent — you will not see the contents (Figure 15-15).
Figure 15-15. Unfolded Instance Not Showing Contents

However, you can double-click any input/output pin to trace the drivers/readers and cause the
connected gates and internal instances to appear (Figure 15-16).
Figure 15-16. Unfolded Instance with All Contents Displayed

Using Abstract Blocks

Abstract blocks are implicitly created (tool-generated) hierarchies rendered in the Schematic
window to encapsulate standard constructs like for-loop, for-generate, and so on. Like folded
instances, they reduce clutter in the Schematic and make it more comprehensible and user-
friendly.
All Abstract blocks have a name starting with "AB_" followed by some unique number. The
number is internally tool generated and is unique for all abstract blocks.

778 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Using Abstract Blocks

Figure 15-17. Abstract Blocks Identified with Unique Number

Procedure
1. Abstract blocks can be unfolded to access detailed information and, if needed, refolded.
To unfold, simply double click an abstract block; or, right-click it and select Fold/
Unfold from the popup menu. To fold, press the Ctrl key and double-click the block; or,
right-click the block and select Fold/Unfold from the popup menu.
2. In the folded state, a keyword is written inside the abstract block — like FOR, GEN,
VW or MC — to indicate the type of abstract block it is. All the control signals are
routed through the bottom of abstract block, while input and output are routed through
left and right sides respectively.
3. To further prioritize Schematic comprehension, heuristics are used for identifying and
creating Abstract blocks — for example: iteration-count of for-loops, and count in
contiguous mux-chains.
4. Abstract blocks are displayed in both the Incremental and Full view mode. In the Full
view, some unfolded abstract blocks may contain other folded abstract blocks. These
abstract blocks can be unfolded as well to show further details of the design.
Examples
Abstract blocks are created under the following conditions:

• For-loop statements — If a for-loop is synthesizable and has an iteration count greater

than 8, a separate abstract block is created for every output signal assigned inside the
for-loop-statement.
• For-generate statements — If a for-generate statement is synthesizable, a single
abstract block is created for the whole for-generate statement.

ModelSim® SE User's Manual, v10.7 779

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Exploring Designs with the Embedded Wave Viewer

Note
A single abstract-block is created for a for-generate statement (even if it contains
nested if-generate or for-generate statement) to keep abstract-block count to
appropriate level.

• Vector-Write statements — A statement like "q[index] = d2 or d3;" in which the

value of index is not known at the time of elaboration, and the size of the "q" selection-
array is smaller than the specified size threshold (usually 1024), is taken as vector-write
statement.
Synthesis of this construct spawns too many conditional logic and gates, thus cluttering
the Schematic. Therefore, all such identified constructs/statements are encapsulated
inside an appropriate abstract block.
• Contiguous Mux-chain/ladder patterns — Generally, an if-else-if ladder (broadly
nested conditional-statements) is synthesized into a mux-chain or mux-ladder. If the
nesting level gets more than 8 the whole mux-chain is encapsulated inside a single
abstract block to keep clutter to a minimum.

Exploring Designs with the Embedded Wave Viewer

Another way of exploring your design is to use the embedded wave viewer for the Incremental
view.
This viewer closely resembles, in appearance and operation, the Wave window (see Waveform
Analysis for more information).

Procedure
1. To open the wave viewer, use the Schematic > Show Wave menu selection when the
Incremental view is active, or simply click the Show Wave toolbar button.

2. When wave viewer is first displayed, the visible zoom range is set to match that of the
last active Wave window, if one exists. Additionally, the wave viewer's moveable cursor
(Cursor 1) is automatically positioned to the location of the active cursor in the last
active Wave window.
3. When you select an instance or process in the schematic, all signals attached to that
instance or process are added to the wave viewer. In Figure 15-18, the #ALWAYS#35
process is selected and the wave viewer displays 3 inputs, 1 output, and an inout bus.
See Tracing Events in the Incremental View for another example of using the embedded
wave viewer.
4. With the embedded wave viewer open in the Incremental view you can run the design
for a period of time, then use time cursors to investigate value changes. As you place and
move cursors in the wave viewer (see Measuring Time with Cursors in the Wave
Window), the signal values update in the schematic view (Figure 15-18).

780 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Tracing Events in the Incremental View

5. Notice that the title of the Schematic window changes to reflect which portion of the
window is active. When the schematic is active, the title of the window is “Schematic
(schematic).” When the embedded wave view is active, the title of the window is
“Schematic (wave).” Menu and toolbar selections will change depending on which
portion of the window is active.
Figure 15-18. Wave Viewer Displays Inputs and Outputs of Selected Process

Tracing Events in the Incremental View

Event Traceback features allow you to trace root causes of various results, typically unknown
values, in your design.
You can use the Event Traceback feature to:

• trace an event to the first sequential process that caused the event – Show Cause
• trace an event to its immediate driving process – Show Driver
• trace an event to its root cause – Show Root Cause

ModelSim® SE User's Manual, v10.7 781

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Tracing Events in the Incremental View

• trace to the cause of an unknown value – Show ‘X’ Cause (ChaseX)

• show all possible drivers of the selected net in the Source window – Show All Possible
Drivers
• view path times bar in the Schematic Path Details window - View Path Times
• trace to a driving event
• start a trace from the end time
• start a trace from the begin time
These options are available when you right-click anywhere in the Incremental View and select
Event Traceback from the popup menu (Figure 15-19).

Figure 15-19. Event Traceback Options

The event trace begins at the current “active time,” which is set a number of different ways:

• with the selected cursor in the Wave window

• with the selected cursor in the Schematic window’s embedded Wave viewer
• or with the CurrentTime label in the Source or Schematic windows.
Figure 15-20 shows the Current Time label in the upper right corner of the Incremental view.
(This label is displayed by default. If you want to turn it off, select Schematic > Preferences to
open the Incremental Schematic Options dialog box and uncheck the “Current Time Label”
box.)

782 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Tracing Events in the Incremental View

Figure 15-20. CurrentTime Label in Incremental View

The CurrentTime label includes a minimize/maximize button that allows you to hide or display
the label.

When a signal or net is selected, you can jump to the previous or next transition of that signal,
with respect to the current time, by clicking the Find Previous/Next Transition buttons.

To change the Current Time, simply click the label and type in the time you want to examine in
the Enter Value dialog box (Figure 15-21). The dialog box includes a check box that allows you
to switch to Now time (the time the simulation ended) or Current time (if “Now” is displayed in
the Current Time label.

Figure 15-21. Enter Current Time Value

Refer to “Current Time Label” in the GUI Reference Manual for details.

The recommended work flow for initiating an event trace from the Incremental view is as
follows:

Procedure
1. Add a process or signal of interest into the Incremental view (if adding a signal, include
its driving process).

ModelSim® SE User's Manual, v10.7 783

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Tracing Events in the Incremental View

2. Open the embedded wave viewer by clicking the Show Wave toolbar button.

3. In the Incremental view, click the process of interest so that all signals attached to the
selected process will appear in the embedded wave viewer.
4. In the wave viewer, select a signal and place a cursor at an event of interest. In
Figure 15-22, signal q of the fifo module ff3 is selected and a cursor is placed on the
transition at 670 ns.
Figure 15-22. Signals for Selected Process in Embedded Wave Viewer

5. Right-click and select Event Traceback, then one of the three traceback options, from
the popup menu.
Results
A Source window opens with the cause of the event highlighted and driver information
displayed in the Show Driver Control Bar at the top of the Source window. There are four
buttons in the Show Drivers Control Bar: 1) the History button, 2) the List Menu button, 3) the
Previous button, and 4) the Next button (Figure 15-23).

784 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Tracing Events in the Incremental View

Figure 15-23. Show Drivers Control Bar Buttons

In Figure 15-23, the Show Drivers Control Bar displays “1/12 Drivers” to indicate that the first
of twelve drivers is selected. When you click the List Menu button, a menu drops down showing
all drivers with a checkmark beside the selected driver, which is highlighted in the Source
window (Figure 15-24).
Figure 15-24. Multiple Drivers in the Show Drivers Control Bar

You can jump directly to the source code of any other driver in the list by simply clicking it. Or,
use the Previous and Next buttons to navigate through the list of drivers.
The History button allows you to review past Show Drivers operations (Figure 15-25). Click an
item in the list to return to a previous operation.

ModelSim® SE User's Manual, v10.7 785

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Tracing Events in the Incremental View

Figure 15-25. History Button Displays Past Operations

For more information about using the Show Drivers Control Bar see Multiple Drivers.
You can also display information about the sequential process(es) that caused the selected event
by opening the Active Driver Path Details window (Figure 15-26).
Figure 15-26. Active Driver Path Details for the q Signal

If you want to see the path details in the Schematic window, click the Schematic Window
button at the bottom of the Active Driver Path Details Window.
Figure 15-27. Click Schematic Window Button to View Path Details

This will open a Schematic window with the title Schematic (Path Details). In Figure 15-28,
the q signal event at 670 ns is traced to its root cause. All signals in the path to the root cause are
displayed in the wave viewer, and the path through the schematic is highlighted in red. The

786 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Tracing the Schematic Source of an Unknown State (StX)

wave viewer also displays two new cursors, labeled Trace Begin and Trace End to designate
where the event trace started and ended.
Figure 15-28. Path to Root Cause

For more details about event tracing see Using Causality Traceback.

Tracing the Schematic Source of an Unknown State

(StX)
You can use the Causality Traceback feature of the Schematic window to trace an unknown
state (StX) back to its source.
Unknown values are indicated by red lines in the Wave window (Figure 15-29) and in the Wave
Viewer pane of the Schematic window.

ModelSim® SE User's Manual, v10.7 787

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Tracing the Schematic Source of an Unknown State (StX)

Figure 15-29. Unknown States Shown as Red Lines in Wave Window

Procedure
1. Optimize your design with +acc (for debugging visibility) and with -debugdb (to save
combinatorial and sequential logic events to the working library).
2. Load your design with vsim -debugdb to create a database (vsim.dbg) from the
combinatorial and sequential logic event data.
3. Log all signals in the design or any signals that may possibly contribute to the unknown
value (log -r /* will log all signals in the design).
4. Add signals to the Wave window or wave viewer pane, and run your design the desired
length of time.
5. Put a Wave window cursor on the time at which the signal value is unknown (StX). In
Figure 15-29, Cursor 1 at time 2305 shows an unknown state on signal t_out.
6. Add the signal of interest to the Schematic window. You can drag and drop it from the
Objects window, use the Add Selected to Window toolbar button, or the Add > to
Schematic > Selected Signals menu selection,
7. In the Schematic window, make sure the signal of interest is selected.
8. Click and hold the Event Traceback menu button to open the menu (Figure 15-30), then
select Show ‘X’ Cause (ChaseX).

788 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Finding Objects by Name in the Schematic Window

Figure 15-30. Event Traceback Menu

Related Topics
Using Causality Traceback

Finding Objects by Name in the Schematic Window

The Schematic Window includes an easy-to-use toolbar that allows you to find objects by name.
Procedure
Select Edit > Find from the menu bar, or click the Find icon in the toolbar, to search for signal,
net, or register names or an instance of a component.

Results
The Find toolbar opens at the bottom of the Schematic window (Figure 15-31).
Figure 15-31. Find Toolbar for Schematic Window

With the Find toolbar you can limit the search by type to instances or signal nets. You may do
hierarchical searching from the design root (when you check “Search from Top”) or from the
current context. The Zoom to selection zooms in to the item you enter in the Find field. The
Match case selection enforces case-sensitive matching of your entry. And you can select Exact
(whole word) to find an item that exactly matches the entry you type in the Find field.
The Find All Matches in Current Schematic button allows you to find and highlight all
occurrences of the item in the Find field. If the Zoom to box is checked, the view changes so all
selected items are viewable. If Zoom to is not checked, then no change is made to the zoom or
scroll state.

ModelSim® SE User's Manual, v10.7 789

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Saving and Restoring the Schematic

Saving and Restoring the Schematic

You can save the currently loaded design view in either the Full or the Incremental view to a file
or to a disk. This can be reloaded at any future time to start debugging from that view.
Procedure
1. To save the schematic:
• Right click the Schematic window (either view) and click Save in the popup menu.
This will open a Save File dialog box.
• In the Save File dialog, type in a name for the new file, which will be saved with the
.sch file extension.
2. To restore the schematic:
• Right click the schematic window and select Restore from the popup menu.
• Select either Current Window or New Window. If you select Current Window, the
saved schematic overwrites any information there. If you select New Window, the
saved schematic is displayed in a new window.

Annotating with Sticky Notes

You can annotate any selected design component with a sticky note.
Procedure
1. Select a design component to highlight it.
2. Right-click anywhere in the Schematic window and select Sticky Note > Add from the
popup menu. This opens a Sticky Note dialog.
3. Type a short note into the Note field and click the OK button. The note will be attached
as shown in Figure 15-32.

790 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Displaying Power Aware Information

Figure 15-32. Adding a Sticky Note

The Sticky Note option in the right-click menu provides four actions:
• Add — Create a note to annotate a component.
• Remove — Remove a sticky note from the selected component.
• Hide/Unhide — Hide or display an existing sticky note for the selected component.
• Hide/Unhide All — Hide or display all sticky notes.
Double-clicking on an existing sticky note will open an edit box, where you can edit and
update the note.
Sticky notes also get saved in the save/restore functionality. (See Saving and Restoring
the Schematic.)

Displaying Power Aware Information

If a design has power domain information and is simulated with the necessary power option, the
Schematic window will display different power domains in different colors – that is, all design
units belonging to one power domain will be shown in one color.
For details, refer to “Power Aware Schematic Display” in the Power Aware Simulation User’s
Manual.

Automatically Tracing All Paths Between Two Nets

in the Schematic Window
This behavior is referred to as point-to-point tracing. It allows you to visualize all paths
connecting two different nets in your schematic.

ModelSim® SE User's Manual, v10.7 791

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Automatically Tracing All Paths Between Two Nets in the Schematic Window

Prerequisites
• This feature is available during a live simulation, not when performing post-simulation
debugging.
Procedure
1. Select Source — Click the net to be your source
2. Select Destination — Shift-click the net to be your destination
3. Run point-to-point tracing — Right-click the Schematic window and select Point to
Point.
Results
After beginning the point-to-point tracing, the Schematic window highlights your design as
shown in Figure 15-33:
• All objects become gray
• The source net becomes yellow
• The destination net becomes red
• All intermediate processes and nets become orange.
Figure 15-33. Schematic: Point-to-Point Tracing

Examples
• Change the limit of highlighted processes — There is a limit of 400 processes that will
be highlighted.

792 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Symbol Mapping in the Schematic Window

a. Tools > Edit Preferences

b. By Name tab
c. Schematic > p2plimit option
• Remove the point-to-point tracing
a. Right-click the Schematic window
b. Erase Highlights
• Perform point-to-point tracing from the command line
a. Determine the names of the nets
b. Use the add schematic command with the -connect argument, for example:
add data -connect /test_ringbuf/pseudo /test_ringbuf/ring_inst/
txd

where /test_ringbuf/pseudo is the source net and /test_ringbuf/ring_inst/txd is the

destination net.

Symbol Mapping in the Schematic Window

The Schematic window has built-in mappings for all Verilog primitive gates (for example,
AND, OR, and so forth). You can also map VHDL entities and Verilog/SystemVerilog modules
that represent a cell definition, or processes, to built-in gate symbols.
The mappings are saved in a file where the default filename is schematic.bsm (.bsm stands for
"Built-in Symbol Map") The Schematic window looks in the current working directory and
inside each library referenced by the design for the file. It will read all files found. You can also
manually load a .bsm file by selecting Schematic > Schematic Preferences > Load Built in
Symbol Map.

The schematic.bsm file contains comments and name pairs, one comment or name per line. Use
the following Backus-Naur Format naming syntax:

<bsm_line> ::= <comment> | <statement>

<comment> ::= "#" <text> <EOL>
<statement> ::= <name_pattern> <gate>
<name_pattern> ::= [<library_name> "."]
<du_name> ["("<specialization> ")"][","<process_name>]
<gate> ::=
"BUF"|"BUFIF0"|"BUFIF1"|"INV"|"INVIF0"|"INVIF1"|"AND"|"NAND"|"NOR" |
"OR"|"XNOR"|"XOR"|"PULLDOWN"|"PULLUP"|"NMOS"|"PMOS"|"CMOS"|
"TRAN"| "TRANIF0"|"TRANIF1"

ModelSim® SE User's Manual, v10.7 793

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Symbol Mapping in the Schematic Window

For example:

org(only),p1 OR
andg(only),p1 AND
mylib,andg.p1 AND
norg,p2 NOR

Entities and modules representing cells are mapped the same way:

AND1 AND
# A 2-input and gate
AND2 AND
mylib,andg.p1 AND
xnor(test) XNOR

Note that for primitive gate symbols, pin mapping is automatic.

Note
Note that for primitive gate symbols, pin mapping is automatic. When you map a module/
entity, it must be defined as a cell via `celldefine in Verilog.

The default filename is schematic.bsm (.bsm stands for "Built-in Symbol Map"). The Schematic
window looks in the current working directory and inside each library referenced by the design
for the file schematic.bsm. It will read all files found. You can also manually load a .bsm file by
selecting Schematic > Symbol Library > Load Built in Symbol Map.

Note
The Schematic window will search for mapping files named dataflow.bsm first, then
schematic.bsm in order to maintain backwards compatibility with designs simulated with
older versions of ModelSim.

User-Defined Symbols
You can also define your own symbols using an ASCII symbol library file format for defining
symbol shapes. This capability is delivered via Concept Engineering’s NlviewTM widget
Symlib format. The symbol definitions are saved in the schematic.sym file.

The formal BNF format for the schematic.sym file format is:

<sym_line> ::= <comment> | <statement>

<comment> ::= "#" <text> <EOL>
<statement> ::= "symbol" <name_pattern> "*" "DEF" <definition>
<name_pattern> ::= [<library_name> "."] <du_name> ["("
<specialization> ")"] [","<process_name>]
<gate> ::= "port" | "portBus" | "permute" | "attrdsp" | "pinattrdsp"
| "arc" | "path" | "fpath" | "text" | "place" | "boxcolor"

794 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Symbol Mapping in the Schematic Window

Note
The port names in the definition must match the port names in the entity or module
definition or mapping will not occur.

The Schematic window will search the current working directory, and inside each library
referenced by the design, for the file schematic.sym. Any and all files found will be given to the
Nlview widget to use for symbol lookups. Again, as with the built-in symbols, the DU name and
optional process name is used for the symbol lookup. Here's an example of a symbol for a full
adder:

symbol adder(structural) * DEF \

port a in -loc -12 -15 0 -15 \
pinattrdsp @name -cl 2 -15 8 \
port b in -loc -12 15 0 15 \
pinattrdsp @name -cl 2 15 8 \
port cin in -loc 20 -40 20 -28 \
pinattrdsp @name -uc 19 -26 8 \
port cout out -loc 20 40 20 28 \
pinattrdsp @name -lc 19 26 8 \
port sum out -loc 63 0 51 0 \
pinattrdsp @name -cr 49 0 8 \
path 10 0 0 7 \
path 0 7 0 35 \
path 0 35 51 17 \
path 51 17 51 -17 \
path 51 -17 0 -35 \
path 0 -35 0 -7 \
path 0 -7 10 0

Port mapping is done by name for these symbols, so the port names in the symbol definition
must match the port names of the Entity|Module|Process (in the case of the process, it is the
signal names that the process reads/writes).

When you create or modify a symlib file, you must generate a file index. This index is how the
Nlview widget finds and extracts symbols from the file. To generate the index, select
Schematic > Schematic Preferences > Create Symlib Index (Schematic window) and specify
the symlib file. The file will be rewritten with a correct, up-to-date index. If you save the file as
schematic.sym the Schematic window will automatically load the file. You can also manually
load a .sym file by selecting Schematic > Schematic Preferences > Load Symlib Library.

ModelSim® SE User's Manual, v10.7 795

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
Symbol Mapping in the Schematic Window

Note
When you map a process to a gate symbol, it is best to name the process statement within
your HDL source code, and use that name in the .bsm or .sym file. If you reference a default
name that contains line numbers, you will need to edit the .bsm and/or .sym file every time you
add or subtract lines in your HDL source.

The Schematic window will search for mapping files named dataflow.sym first, then
schematic.sym in order to maintain backwards compatibility with designs simulated with older
versions of ModelSim.

796 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
Schematic Window Graphic Interface FAQ

Schematic Window Graphic Interface FAQ

This section answers several common questions about using the Schematic window’s graphic
user interface.
What Can I View in the Schematic Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . 797
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
How do I Configure Schematic Window Options?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

What Can I View in the Schematic Window?

The Schematic window displays:
• processes
• signals, nets, and registers
• interconnects
The window has built-in mappings for all Verilog primitive gates (that is,AND, OR, and so
forth). For components other than Verilog primitives, you can define a mapping between
processes and built-in symbols. See Symbol Mapping in the Schematic Window for details.

You cannot view SystemC objects in the Schematic window; however, you can view HDL
regions from mixed designs that include SystemC.

How is the Schematic Window Linked to Other

Windows?
The Schematic window is dynamically linked to other debugging windows and panes.
The Schematic window links to the windows listed in Table 15-3. Refer to the GUI Reference
Manual for further information on these windows.
Table 15-3. Schematic Window Links to Other Windows and Panes
Window Link
Structure Window select a signal or process in the Schematic window, and the
structure tab updates if that object is in a different design unit
Processes Window select a process in either window, and that process is
highlighted in the other

ModelSim® SE User's Manual, v10.7 797

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
How Can I Print and Save the Schematic Display?

Table 15-3. Schematic Window Links to Other Windows and Panes (cont.)
Window Link
Objects Window select a design object in either window, and that object is
highlighted in the other
Wave Window trace through the design in the Schematic window, and the
associated signals are added to the Wave window along with
Trace Begin and Trace End cursors
move a cursor in the Wave window, and the values update in
the Schematic window
Source Window double-click an object in the Schematic window to open a
Code Preview; use Event Traceback in the Schematic window
to go directly to the source code for the cause of the event

How Can I Print and Save the Schematic Display?

You can print the Schematic window display from a saved .eps file in UNIX, or by simple menu
selections in Windows. The Schematic Page Setup dialog boxallows you to configure the
display for printing.
You can also export the Schematic display as a bitmap image (.bmp file) by selecting File >
Export > Image from the Main menu. This is useful for emailing or embedding into
documents.

Saving a .eps File and Printing the Schematic Display from UNIX
With the Schematic window active, select File > Print Postscript to setup and print the
Schematic display in UNIX, or save the waveform as an .eps file on any platform
(Figure 15-34).

Figure 15-34. The Print Postscript Dialog

798 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
How do I Configure Schematic Window Options?

Printing from the Schematic Display on Windows Platforms

With the Schematic window active, select File > Print to print the Schematic display or to save
the display to a file.

Configuring Page Setup

With the Schematic window active, select File > Page setup to open the Schematic Page Setup
dialog box (Figure 15-35). You can also open this dialog box by clicking the Setup button in the
Print Postscript dialog box (Figure 15-34). This dialog box allows you to configure page view,
highlight, color mode, orientation, and paper options.

Figure 15-35. The Schematic Page Setup Dialog

How do I Configure Schematic Window Options?

The Schematic > Preferences menu selection allows you to configure several options that
determine how the Incremental and Full views behave. Options are the same for both views.
Any changes made to the schematic display options are saved for future simulation and
debugging sessions.
Incremental view options are shown in Figure 15-36. For a description of what each option
does, click the “Show Help Text Pane” button (the ‘i’ button) in the bottom left corner of the
dialog, or refer to Incremental Schematic Options in the GUI Reference Manual.

ModelSim® SE User's Manual, v10.7 799

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
How do I Configure Schematic Window Options?

Figure 15-36. Configuring Incremental View Options

You may also right-click in either the Incremental or Full view to select Show from the popup
menu, which gives you the display selections shown in Figure 15-37.

800 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
How do I Zoom and Pan the Display?

Figure 15-37. Display Options in Right-Click Menu

Net Names and Signal Values can be toggled on and off with the N and V keys on your
keyboard, respectively. (See How do I Use Keyboard Shortcuts?) By default, displayed signal
values are for the current active time.

How do I Zoom and Pan the Display?

The Schematic window offers tools for zooming and panning the display.
These zoom buttons are available from the Zoom toolbar:
Zoom In
zoom in by a factor of two from the current view
Zoom Out
zoom out by a factor of two from current view
Zoom Full
zoom out to view the entire schematic

To zoom with the mouse, you can either use the middle mouse button or enter Zoom Mode by
selecting Schematic > Zoom and then use the left mouse button.

ModelSim® SE User's Manual, v10.7 801

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
How do I Use Keyboard Shortcuts?

Zooming with the Mouse

Four zoom options are possible by pressing and holding the middle mouse button and dragging
in different directions. If you change the mouse mode to “Zoom Mode” (Schematic > Mouse
Mode > Zoom Mode), these click-and-drag options are done with the left mouse button:

• Down-Right — Zoom Area (In)

• Up-Right — Zoom Out (zoom amount is displayed at the mouse cursor)
• Down-Left — Zoom Selected
• Up-Left — Zoom Full
Panning with the Mouse
You can pan with the mouse in two ways:

• Enter Pan Mode by selecting Schematic > Mouse Mode > Pan and then drag with the
left mouse button to move the design
• Hold down the <Ctrl> key and drag with the middle mouse button to move the design.

How do I Use Keyboard Shortcuts?

This section provides a complete list of keyboard shortcuts you can use with the Schematic
window.

Table 15-4. Keyboard Shortcuts

Key stroke Action
Up arrow Scroll up
Down arrow Scroll down
Left Arrow Scroll left
Right arrow Scroll right
Ctrl + arrow key Scroll by larger amount
Shift + arrow key Scroll to edge of display
i Zoom in
o Zoom out
f Zoom full
h Zoom into highlighted selection
s Zoom selected
1-5 Toggle highlight number

802 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Schematic Window
How do I Use Keyboard Shortcuts?

Table 15-4. Keyboard Shortcuts (cont.)

Key stroke Action
u Remove all highlights
g Toggle gray mode - remove all color except highlights
n Toggle names on or off
v Toggle signal values on or off
r Regenerate display
? Toggle keyboard shortcut table on or off
When the Schematic window is selected, you can display a list of keyboard shortcuts by
pressing the ‘?’ key on your keyboard.

Figure 15-38. Keyboard Shortcut Table in the Schematic Window

Toggle the list closed by pressing the ‘?’ key again or simply click the list.

ModelSim® SE User's Manual, v10.7 803

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Schematic Window
How do I Use Keyboard Shortcuts?

804 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 16
Debugging with the Dataflow Window

This chapter discusses how to use the Dataflow window for tracing signal values, browsing the
physical connectivity of your design, and performing post-simulation debugging operations.
Dataflow Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Dataflow Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Common Tasks for Dataflow Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Dataflow Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Dataflow Window Graphic Interface Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830

Dataflow Window Overview

The Dataflow window allows you to explore the “physical” connectivity of your design; to trace
events that propagate through the design; and to identify the cause of unexpected outputs.
Note
ModelSim versions operating without a dataflow license feature have limited Dataflow
functionality. Without the license feature, the window displays the message “Extended
mode disabled” and will show only one process and its attached signals or one signal and its
attached processes.

ModelSim® SE User's Manual, v10.7 805

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Dataflow Window Overview

Figure 16-1. The Dataflow Window

806 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Dataflow Usage Flow

Dataflow Usage Flow

The Dataflow window can be used to debug the design currently being simulated, or to perform
post-simulation debugging of a design. For post-simulation debugging, a database is created at
design load time, immediately after elaboration, and used later.
Note
The -postsimdataflow option must be used with the vsim command for the Dataflow
window to be available for post simulation debug operations.

Live Simulation Debug Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807

Post-Simulation Debug Flow Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809

Live Simulation Debug Flow

The usage flow for debugging the live simulation is as follows.
Procedure
1. Compile the design using the vlog and/or vcom commands.
2. Optimize the design with the vopt command.
vopt +acc <design_name> -o <optimized_design_name>

The +acc argument provides visibility into the design.

3. Load the design with the vsim command:
vsim <optimized_design_name>

4. Run the simulation.

5. Debug your design.
6. Figure 16-2 illustrates the current and post-sim usage flows for Dataflow debugging.

ModelSim® SE User's Manual, v10.7 807

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Live Simulation Debug Flow

Figure 16-2. Dataflow Debugging Usage Flow

808 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Post-Simulation Debug Flow Details

Post-Simulation Debug Flow Details

The post-sim debug flow for Dataflow analysis is most commonly used when performing
simulations of large designs in simulation farms, where simulation results are gathered over
extended periods and saved for analysis at a later date. In general, the process consists of two
steps: creating the database and then using it.
Create the Post-Sim Debug Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Use the Post-Simulation Debug Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810

Create the Post-Sim Debug Database

Use the following procedure to create a post-simulation debug database.
Procedure
1. Compile the design using the vlog and/or vcom commands.
2. Optimize the design with the vopt command.
vopt +acc <design_name> -o <optimized_design_name> -debugdb

The +acc argument provides visibility into the design while the -debugdb argument
collects combinatorial and sequential data.
3. Load the design with the following commands:
vsim -postsimdataflow -debugdb=<db_pathname> -wlf <db_pathname>
<optimized_design_name>
add log -r /*

By default, the Dataflow window is not available for post simulation debug operations.
You must use the -postsimdataflow argument with the vsim command to make the
Dataflow window available during post-sim debug.
Specify the post-simulation database file name with the -debugdb=<db_pathname>
argument to the vsim command. If a database pathname is not specified, ModelSim
creates a database with the file name vsim.dbg in the current working directory. This
database contains dataflow connectivity information.
Specify the dataset that will contain the database with -wlf <db_pathname>. If a dataset
name is not specified, the default name will be vsim.wlf.
The debug database and the dataset that contains it should have the same base name
(db_pathname).
The add log -r /* command instructs ModelSim to save all signal values generated when
the simulation is run.
4. Run the simulation.
5. Quit the simulation.

ModelSim® SE User's Manual, v10.7 809

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Post-Simulation Debug Flow Details

6. You only need to use the -debugdb=<db_pathname> argument for the vsim command
once after any structural changes to a design. After that, you can reuse the vsim.dbg file
along with updated waveform files (vsim.wlf) to perform post simulation debug.
7. A structural change is any change that adds or removes nets or instances in the design, or
changes any port/net associations. This also includes processes and primitive instances.
Changes to behavioral code are not considered structural changes. ModelSim does not
automatically detect structural changes. This must be done by the user.

Use the Post-Simulation Debug Database

You can use the saved dataset to view objects and trace connectivity. Use the following
procedure to open a saved dataset.
Procedure
1. Start ModelSim by typing vsim at a UNIX shell prompt; or double-click a ModelSim
icon in Windows.
2. Select File > Change Directory and change to the directory where the post-simulation
debug database resides.
3. Recall the post-simulation debug database with the following:
dataset open <db_pathname.wlf>

ModelSim opens the .wlf dataset and its associated debug database (.dbg file with the
same basename), if it can be found. If ModelSim cannot find db_pathname.dbg, it will
attempt to open vsim.dbg.

810 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Common Tasks for Dataflow Debugging

Common Tasks for Dataflow Debugging

Common tasks for current and post-simulation debugging using the Dataflow window include
adding objects to the window, exploring the connectivity of the design, tracing events, finding
objects, and tracing paths between nets.
Add Objects to the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Exploring the Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Explore Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Tracing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Tracing the Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Finding Objects by Name in the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Automatically Tracing All Paths Between Two Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823

Add Objects to the Dataflow Window

You can use any of the following methods to add objects to the Dataflow window:
• Drag and drop objects from other windows.
• Use the Add > To Dataflow menu options.
• Select the objects you want placed in the Dataflow Window, then click-and-hold the
AddSelected to Window Button in the Standard toolbar and select Add to Dataflow.
Refer to Add Selected to Window Button in the GUI Reference Manual for more
information.
• Use the add dataflow command.
The Add > To Dataflow menu offers four commands that will add objects to the window:

• View region — clear the window and display all signals from the current region
• Add region — display all signals from the current region without first clearing the
window
• View all nets — clear the window and display all signals from the entire design
• Add ports — add port symbols to the port signals in the current region
When you view regions or entire nets, the window initially displays only the drivers of the
added objects. You can view readers as well by right-clicking a selected object, then selecting
Expand net to readers from the right-click popup menu.

The Dataflow window provides automatic indication of input signals that are included in the
process sensitivity list. In Figure 16-3, the dot next to the state of the input clk signal for the
#ALWAYS#155 process. This dot indicates that the clk signal is in the sensitivity list for the

ModelSim® SE User's Manual, v10.7 811

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Add Objects to the Dataflow Window

process and will trigger process execution. Inputs without dots are read by the process but will
not trigger process execution, and are not in the sensitivity list (will not change the output by
themselves).

Figure 16-3. Dot Indicates Input in Process Sensitivity List

The Dataflow window displays values at the current “active time,” which is set a number of
different ways:

• with the selected cursor in the Wave window,

• with the selected cursor in the Dataflow window’s embedded Wave viewer,
• with the Current Time label in the Source or Dataflow windows.
Figure 16-4 shows the CurrentTime label in the upper right corner of the Dataflow window.
(This label is turned on by default. If you want to turn it off, select Dataflow > Preferences to
open the Dataflow Options Dialog and check the “Current Time label” box.) Refer to Current
Time Label in the GUI Reference Manual for more information.

812 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Add Objects to the Dataflow Window

Figure 16-4. CurrentTime Label in Dataflow Window

ModelSim® SE User's Manual, v10.7 813

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Exploring the Connectivity of the Design

Exploring the Connectivity of the Design

A primary use of the Dataflow window is exploring the “physical” connectivity of your design.
One way of doing this is by expanding the view from process to process. This allows you to see
the drivers/readers of a particular signal, net, or register.
You can expand the view of your design using menu commands or your mouse. To expand with
the mouse, simply double click a signal, register, or process. Depending on the specific object
you click, the view will expand to show the driving process and interconnect, the reading
process and interconnect, or both.

Alternatively, you can select a signal, register, or net, and use one of the toolbar buttons or drop
down menu commands described in Table 16-1.
Table 16-1. Icon and Menu Selections for Exploring Design Connectivity
Expand net to all drivers Right-click in the Dataflow
display driver(s) of the selected signal, net, or window > Expand Net to Drivers
register
Expand net to all drivers and readers Right-click in the Dataflow
display driver(s) and reader(s) of the selected window > Expand Net
signal, net, or register
Expand net to all readers Right-click in the Dataflow
display reader(s) of the selected signal, net, or window > Expand Net to Readers
register

As you expand the view, the layout of the design may adjust to show the connectivity more
clearly. For example, the location of an input signal may shift from the bottom to the top of a
process.

Analyzing a Scalar Connected to a Wide Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814

Control the Display of Readers and Nets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Controlling the Display of Redundant Buffers and Inverters . . . . . . . . . . . . . . . . . . . . . 817
Track Your Path Through the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817

Analyzing a Scalar Connected to a Wide Bus

During design analysis you may need to trace a signal to a reader or driver through a wide bus.
To prevent the Dataflow window from displaying all of the readers or drivers of the bus follow
this procedure:
1. You must be in a live simulation; you can not perform this action post-simulation.
2. Select a scalar net in the Dataflow window (you must select a scalar)
3. Right-click and select one of the Expand > Expand Bit ... options.

814 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Exploring the Connectivity of the Design

After internally analyzing your selection, the dataflow will then show the connected
net(s) for the scalar you selected without showing all the other parts of the bus. This
saves in processing time and produces a more compact image in the Dataflow window
as opposed to using the Expand > Expand Net ... options, which will show all readers
or drivers that are connected to any portion of the bus.

ModelSim® SE User's Manual, v10.7 815

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Exploring the Connectivity of the Design

Control the Display of Readers and Nets

Some nets (such as a clock) in a design can have many readers. This can cause the display to
draw numerous processes that you may not want to see when expanding the selected signal, net,
or register. By default, nets with undisplayed readers or drivers are represented by a dashed line.
If all the readers and drivers for a net are shown, the new will appear as a solid line. To draw the
undisplayed readers or drivers, double-click the dashed line.
Limiting the Display of Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Limit the Display of Readers and Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816

Limiting the Display of Readers

The Dataflow Window limits the number of readers that are added to the display when you click
the Expand Net to Readers button. By default, the limit is 10 readers, but you can change this
limit with the “sproutlimit” Dataflow preference as follows:
Procedure
1. Open the Preferences dialog box by selecting Tools > Edit Preferences.
2. Click the By Name tab.
3. Click the ‘+’ sign next to “Dataflow” to see the list of Dataflow preference items.
4. Select “sproutlimit” from the list and click the Change Value button.
5. Change the value and click the OK button to close the Change Dataflow Preference
Value dialog box.
6. Click OK to close the Preferences dialog box and apply the changes.
7. The sprout limit is designed to improve performance with high fanout nets such as clock
signals. Each subsequent click of the Expand Net to Readers button adds the sprout limit
of readers until all readers are displayed.

Note
This limit does not affect the display of drivers.

Limit the Display of Readers and Drivers

To restrict the expansion of readers and/or drivers to the hierarchical boundary of a selected
signal select Dataflow > Dataflow Options to open the Dataflow Options dialog box then check
Stop on port in the Miscellaneous field.

816 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Exploring the Connectivity of the Design

Controlling the Display of Redundant Buffers and

Inverters
The Dataflow window automatically traces a signal through buffers and inverters. This can
cause chains of redundant buffers or inverters to be displayed in the Dataflow window. You can
collapse these chains of buffers or inverters to make the design displayed in the Dataflow
window more compact.
To change the display of redundant buffers and inverters: select Dataflow > Dataflow
Preferences > Options to open the Dataflow Options dialog. The default setting is to display
both redundant buffers and redundant inverters. (Figure 16-5)

Figure 16-5. Controlling Display of Redundant Buffers and Inverters

Track Your Path Through the Design

You can quickly traverse through many components in your design. To help mark your path, the
objects that you have expanded are highlighted in green.
Figure 16-6. Green Highlighting Shows Your Path Through the Design

You can clear this highlighting using the Dataflow > Remove Highlight menu selection or by
clicking the Remove All Highlights icon in the toolbar. If you click and hold the Remove All

ModelSim® SE User's Manual, v10.7 817

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Explore Designs with the Embedded Wave Viewer

Highlights icon a drop down menu appears, allowing you to remove only selected
highlights.

You can also highlight the selected trace with any color of your choice by right-clicking
Dataflow window and selecting Highlight Selection from the popup menu (Figure 16-7).

Figure 16-7. Highlight Selected Trace with Custom Color

You can then choose from one of five pre-defined colors, or Customize to choose from the
palette in the Preferences dialog box.

Explore Designs with the Embedded Wave Viewer

Another way of exploring your design is to use the Dataflow window’s embedded wave viewer.
This viewer closely resembles, in appearance and operation, the stand-alone Wave window.
The wave viewer is opened using the Dataflow > Show Wave menu selection or by clicking the
Show Wave icon.

When wave viewer is first displayed, the visible zoom range is set to match that of the last
active Wave window, if one exists. Additionally, the wave viewer's movable cursor (Cursor 1)

818 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Explore Designs with the Embedded Wave Viewer

is automatically positioned to the location of the active cursor in the last active Wave window.
The Current Time label in the upper right of the Dataflow window automatically displays the
time of the currently active cursor. Refer to Current Time Label in the GUI Reference Manual
for information about working with the Current Time label.

One common scenario is to place signals in the wave viewer and the Dataflow panes, run the
design for some amount of time, and then use time cursors to investigate value changes. In other
words, as you place and move cursors in the wave viewer pane (see Measuring Time with
Cursors in the Wave Window for details), the signal values update in the Dataflow window.

Figure 16-8. Wave Viewer Displays Inputs and Outputs of Selected Process

Another scenario is to select a process in the Dataflow pane, which automatically adds to the
wave viewer pane all signals attached to the process.

ModelSim® SE User's Manual, v10.7 819

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Tracing Events

Related Topics
Waveform Analysis
Tracing Events

Tracing Events
You can use the Dataflow window to trace an event to the cause of an unexpected output. This
feature uses the Dataflow window’s embedded wave viewer. First, you identify an output of
interest in the dataflow pane, then use time cursors in the wave viewer pane to identify events
that contribute to the output.
Procedure
1. Log all signals before starting the simulation (add log -r /*).
2. After running a simulation for some period of time, open the Dataflow window and the
wave viewer pane.
3. Add a process or signal of interest into the dataflow pane (if adding a signal, find its
driving process). Select the process and all signals attached to the selected process will
appear in the wave viewer pane.
4. Place a time cursor on an edge of interest; the edge should be on a signal that is an
output of the process.
5. Right-click and select Trace Next Event.

A second cursor is added at the most recent input event.

6. Keep selecting Trace Next Event until you have reached an input event of interest.
Note that the signals with the events are selected in the wave viewer pane.
7. Right-click and select Trace Event Set.

The Dataflow display “jumps” to the source of the selected input event(s). The operation
follows all signals selected in the wave viewer pane. You can change which signals are
followed by changing the selection.
8. To continue tracing, go back to step 5 and repeat.
9. If you want to start over at the originally selected output, right-click and select Trace
Event Reset.
Related Topics
Explore Designs with the Embedded Wave Viewer

820 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Tracing the Source of an Unknown State (StX)

Tracing the Source of an Unknown State (StX)

Another useful Dataflow window debugging tool is the ability to trace an unknown state (StX)
back to its source. Unknown values are indicated by red lines in the Wave window (Figure 6-9)
and in the wave viewer pane of the Dataflow window.
Figure 16-9. Unknown States Shown as Red Lines in Wave Window

Procedure
1. Load your design.
2. Log all signals in the design or any signals that may possibly contribute to the unknown
value (log -r /* will log all signals in the design).
3. Add signals to the Wave window or wave viewer pane, and run your design the desired
length of time.
4. Put a Wave window cursor on the time at which the signal value is unknown (StX). In
Figure 16-9, Cursor 1 at time 2305 shows an unknown state on signal t_out.
5. Add the signal of interest to the Dataflow window by doing one of the following:
• Select the signal in the Wave Window, select Add Selected to Window in the
Standard toolbar > Add to Dataflow.
• right-click the signal in the Objects window and select Add > To Dataflow >
Selected Signals from the popup menu,
• select the signal in the Objects window and select Add > To Dataflow > Selected
Items from the menu bar.
6. In the Dataflow window, make sure the signal of interest is selected.

ModelSim® SE User's Manual, v10.7 821

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Finding Objects by Name in the Dataflow Window

7. Trace to the source of the unknown by doing one of the following:

• If the Dataflow window is docked, make one of the following menu selections:
Tools > Trace > TraceX,
Tools > Trace > TraceX Delay,
Tools > Trace > ChaseX, or
Tools > Trace > ChaseX Delay.
• If the Dataflow window is undocked, make one of the following menu selections:
Trace > TraceX,
Trace > TraceX Delay,
Trace > ChaseX, or
Trace > ChaseX Delay.
These commands behave as follows:
o TraceX / TraceX Delay— TraceX steps back to the last driver of an X value.
TraceX Delay works similarly but it steps back in time to the last driver of an X
value. TraceX should be used for RTL designs; TraceX Delay should be used
for gate-level netlists with back annotated delays.
o ChaseX / ChaseX Delay — ChaseX jumps through a design from output to
input, following X values. ChaseX Delay acts the same as ChaseX but also
moves backwards in time to the point where the output value transitions to X.
ChaseX should be used for RTL designs; ChaseX Delay should be used for
gate-level netlists with back annotated delays.

Finding Objects by Name in the Dataflow Window

Select Edit > Find from the menu bar, or click the Find icon in the toolbar, to search for signal,
net, or register names or an instance of a component. This opens the search toolbar at the bottom
of the Dataflow window.

With the search toolbar you can limit the search by type to instances or signals. You select
Exact to find an item that exactly matches the entry you have typed in the Find field. The
Match case selection will enforce case-sensitive matching of your entry. And the Zoom to
selection will zoom in to the item in the Find field.

The Find All button allows you to find and highlight all occurrences of the item in the Find
field. If Zoom to is checked, the view will change such that all selected items are viewable. If
Zoom to is not selected, then no change is made to zoom or scroll state.

822 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Automatically Tracing All Paths Between Two Nets

Automatically Tracing All Paths Between Two Nets

This behavior is referred to as point-to-point tracing. It allows you to visualize all paths
connecting two different nets in your dataflow.
Prerequisites
• This feature is available during a live simulation, not when performing post-simulation
debugging.
Procedure
Use one of the following procedures to trace or modify the paths between two nets:

If you want to... Do the following:

Trace a path between two 1. Select Source — Click the net to be your source
nets 2. Select Destination — Shift-click the net to be your
destination
3. Run point-to-point tracing — Right-click the Dataflow
window and select Point to Point.
Perform point-to-point 1. Determine the names of the nets
tracing from the command 2. Use the add dataflow command with the -connect switch.
line
for example:
add data -connect /test_ringbuf/pseudo/test_ringbuf/
ring_inst/txd

where /test_ringbuf/pseudo is the source net and /test_ringbuf/

ring_inst/txd is the destination net.
Change the limit of 1. Tools > Edit Preferences
highlighted processes — 2. By Name tab
There is a limit of 400 3. Dataflow > p2plimit option
processes that will be
highlighted
Remove the point-to-point 1. Right-click the Dataflow window
tracing 2. Erase Highlights

Results
After beginning the point-to-point tracing, the Dataflow window highlights your design as
shown in Figure 16-10:
• All objects become gray
• The source net becomes yellow

ModelSim® SE User's Manual, v10.7 823

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Automatically Tracing All Paths Between Two Nets

• The destination net becomes red

• All intermediate processes and nets become orange.
Figure 16-10. Dataflow: Point-to-Point Tracing

824 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Dataflow Concepts

Dataflow Concepts
This section provides an introduction to the following important Dataflow concepts:
Symbol Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
User-Defined Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Current vs. Post-Simulation Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829

ModelSim® SE User's Manual, v10.7 825

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Symbol Mapping

Symbol Mapping
The Dataflow window has built-in mappings for all Verilog primitive gates (for example, AND,
OR, and so forth). You can also map VHDL entities and Verilog/SystemVerilog modules that
represent a cell definition, or processes, to built-in gate symbols.
Syntax
<bsm_line> ::= <comment> | <statement>
Arguments
• The following arguments are available:
o <comment> ::= "#" <text> <EOL>
o <statement> ::= <name_pattern> <gate>
o <name_pattern> ::= [<library_name> "."] <du_name> ["(" <specialization> ")"]
[","<process_name>]
o <gate> ::=
"BUF"|"BUFIF0"|"BUFIF1"|"INV"|"INVIF0"|"INVIF1"|"AND"|"NAND"|
"NOR"|"OR"|"XNOR"|"XOR"|"PULLDOWN"|"PULLUP"|"NMOS"|"PMOS"|"CM
OS"|"TRAN"| "TRANIF0"|"TRANIF1"
Description
The mappings are saved in a file where the default filename is dataflow.bsm (.bsm stands for
“Built-in Symbol Map”) The Dataflow window looks in the current working directory and
inside each library referenced by the design for the file. It will read all files found. You can also
manually load a .bsm file by selecting Dataflow > Dataflow Preferences > Load Built in
Symbol Map.

The dataflow.bsm file contains comments and name pairs, one comment or name per line. Use
the following Backus-Naur Format naming syntax:

Examples
• Example 1
org(only),p1 OR
andg(only),p1 AND
mylib,andg.p1 AND
norg,p2 NOR

• Entities and modules representing cells are mapped the same way:
AND1 AND
# A 2-input and gate
AND2 AND
mylib,andg.p1 AND
xnor(test) XNOR

826 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Symbol Mapping

Note
For primitive gate symbols, pin mapping is automatic.

ModelSim® SE User's Manual, v10.7 827

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
User-Defined Symbols

User-Defined Symbols
The formal BNF format for the dataflow.sym file format is:
You can also define your own symbols using an ASCII symbol library file format for defining
symbol shapes. This capability is delivered via Concept Engineering’s NlviewTM® widget
Symlib format. The symbol definitions are saved in the dataflow.sym file.
Syntax
<sym_line> ::= <comment> | <statement>
Arguments
• The following arguments are available:
<comment> ::= "#" <text> <EOL>
<statement> ::= "symbol" <name_pattern> "*" "DEF" <definition>
<name_pattern> ::= [<library_name> "."] <du_name> ["(" <specialization> ")"]
[","<process_name>]
<gate> ::= "port" | "portBus" | "permute" | "attrdsp" | "pinattrdsp" | "arc" | "path" | "fpath"
| "text" | "place" | "boxcolor"
Note
The port names in the definition must match the port names in the entity or module
definition or mapping will not occur.

The Dataflow window will search the current working directory, and inside each library
referenced by the design, for the file dataflow.sym. Any and all files found will be given to
the Nlview widget to use for symbol lookups. Again, as with the built-in symbols, the DU
name and optional process name is used for the symbol lookup. Here's an example of a
symbol for a full adder:
symbol adder(structural) * DEF \
port a in -loc -12 -15 0 -15 \
pinattrdsp @name -cl 2 -15 8 \
port b in -loc -12 15 0 15 \
pinattrdsp @name -cl 2 15 8 \
port cin in -loc 20 -40 20 -28 \
pinattrdsp @name -uc 19 -26 8 \
port cout out -loc 20 40 20 28 \
pinattrdsp @name -lc 19 26 8 \
port sum out -loc 63 0 51 0 \
pinattrdsp @name -cr 49 0 8 \
path 10 0 0 7 \
path 0 7 0 35 \
path 0 35 51 17 \
path 51 17 51 -17 \
path 51 -17 0 -35 \
path 0 -35 0 -7 \
path 0 -7 10 0

828 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
Current vs. Post-Simulation Command Output

Port mapping is done by name for these symbols, so the port names in the symbol definition
must match the port names of the Entity|Module|Process (in the case of the process, it is the
signal names that the process reads/writes).
When you create or modify a symlib file, you must generate a file index. This index is how
the Nlview widget finds and extracts symbols from the file. To generate the index, select
Dataflow > Dataflow Preferences > Create Symlib Index (Dataflow window) and specify
the symlib file. The file will be rewritten with a correct, up-to-date index. If you save the file
as dataflow.sym the Dataflow window will automatically load the file. You can also
manually load a .sym file by selecting Dataflow > Dataflow Preferences > Load Symlib
Library.
Note
When you map a process to a gate symbol, it is best to name the process statement
within your HDL source code, and use that name in the .bsm or .sym file. If you
reference a default name that contains line numbers, you will need to edit the .bsm and/
or .sym file every time you add or subtract lines in your HDL source.

Current vs. Post-Simulation Command Output

ModelSim includes driver and readers commands that can be invoked from the command line to
provide information about signals displayed in the Dataflow window. In live simulation mode,
the drivers and readers commands will provide both topological information and signal values.
In post-simulation mode, however, these commands will provide only topological information.
Driver and reader values are not saved in the post-simulation debug database.
Related Topics
drivers and readers commands. [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 829

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
Dataflow Window Graphic Interface Reference

Dataflow Window Graphic Interface Reference

This section answers several common questions about using the Dataflow window’s graphic
user interface.
What Can I View in the Dataflow Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
How is the Dataflow Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 830
How Can I Print and Save the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
How Do I Configure Window Options?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834

What Can I View in the Dataflow Window?

The Dataflow window displays processes, signals, nets, interconnects, and registers.
The window has built-in mappings for all Verilog primitive gates (for example, AND, OR, and
so forth). For components other than Verilog primitives, you can define a mapping between
processes and built-in symbols. See Symbol Mapping for details.

You cannot view SystemC objects in the Dataflow window; however, you can view HDL
regions from mixed designs that include SystemC.

How is the Dataflow Window Linked to Other

Windows?
The Dataflow window is dynamically linked to other debugging windows and panes as
described in the table below.
Refer to the GUI Reference Manual for more information on the windows named in the table.
Table 16-2. Dataflow Window Links to Other Windows and Panes
Window Link
Structure Window select a signal or process in the Dataflow window, and the
structure tab updates if that object is in a different design unit
Processes Window select a process in either window, and that process is
highlighted in the other
Objects Window select a design object in either window, and that object is
highlighted in the other
Wave Window trace through the design in the Dataflow window, and the
associated signals are added to the Wave window
move a cursor in the Wave window, and the values update in
the Dataflow window

830 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
How is the Dataflow Window Linked to Other Windows?

Table 16-2. Dataflow Window Links to Other Windows and Panes (cont.)
Window Link
Source Window select an object in the Dataflow window, and the Source
window updates if that object is in a different source file

ModelSim® SE User's Manual, v10.7 831

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
How Can I Print and Save the Display?

How Can I Print and Save the Display?

You can print the Dataflow window display from a saved .eps file in UNIX, or by simple menu
selections in Windows. The Page Setup dialog allows you to configure the display for printing.
Save a .eps File and Printing the Dataflow Display from UNIX . . . . . . . . . . . . . . . . . . . 832
Print from the Dataflow Display on Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . 832
Configure Page Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833

Save a .eps File and Printing the Dataflow Display from

UNIX
With the Dataflow window active, select File > Print Postscript to setup and print the
Dataflow display in UNIX, or save the waveform as an .eps file on any platform.
Figure 16-11. The Print Postscript Dialog

Print from the Dataflow Display on Windows Platforms

With the Dataflow window active, select File > Print to print the Dataflow display or to save
the display to a file.

832 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Debugging with the Dataflow Window
How Can I Print and Save the Display?

Figure 16-12. The Print Dialog

Configure Page Setup

With the Dataflow window active, select File > Page setup to open the Page Setup dialog. You
can also open this dialog by clicking the Setup button in the Print Postscript dialog. This dialog
allows you to configure page view, highlight, color mode, orientation, and paper options.
Figure 16-13. The Page Setup Dialog

ModelSim® SE User's Manual, v10.7 833

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Debugging with the Dataflow Window
How Do I Configure Window Options?

How Do I Configure Window Options?

You can configure several options that determine how the Dataflow window behaves. The
settings affect only the current session.
Select DataFlow > Dataflow Preferences > Options to open the Dataflow Options dialog box.

Figure 16-14. Dataflow Options Dialog

834 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 17
Source Window

This chapter discusses the uses of the Source Window for editing, debugging, causality tracing,
and code coverage.
Opening Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Navigating Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Data and Objects in the Source Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Object Values and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Search for Source Code Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Debugging and Textual Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Hyperlinked Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Code Coverage Data in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Coverage Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Source Window Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Setting and Removing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Source Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

ModelSim® SE User's Manual, v10.7 835

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Opening Source Files

Opening Source Files

You can open several file types in the Source window for editing and debugging.

Table 17-1. Open a Source File

To open from ... Do the following ...
Main Menu Bar 1. Select File > Open
2. Select the file from the Open File dialog box
Other windows Double-click objects in the Ranked, Call Tree, Design Unit,
Structure, Objects, and other windows. The underlying source file
for the object opens in the Source window, the indicator scrolls to
the line where the object is defined, and the line is book marked.
Window context menu Select View Source from context menus in the Message Viewer,
Files, Structure, and other windows.
Command line Enter the edit <filename> command to open an existing file.
Create new file 1. Select File > New > Source
2. Select one of the file types from the drop down list.

Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

Changing File Permissions

If a file is protected you must create a copy of the file or change file permissions in order to
make changes to your source documents. Protected files can be edited in the Source window but
the changes must be saved to a new file. To edit the original source document(s) you must
change the read/write file permissions outside of ModelSim.
By default, files open in read-only mode even if the original source document file permissions
allow you to edit the document. To change this behavior, set the PrefSource(ReadOnly)
preference variable to 0. Refer to Setting GUI Preferences in the GUI Reference Manual for
details on setting preference variables.

To change file permissions from the Source window:

Procedure
1. Right-click in the Source window
2. Select (un-check) Read Only.
3. Edit your file.
4. Save your file under a different name.

836 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Updates to Externally Edited Source Files

Updates to Externally Edited Source Files

The following preference variables control how ModelSim works with source files that have
been edited outside of the simulator’s Source window.
• PrefSource(CheckModifiedFiles) — Enables checking for source files for modification
by an external editor.
• PrefSource(AutoReloadModifiedFiles) — Enables automatic reload of files that were
modified by an external editor.
Refer to “Setting GUI Preferences” in the GUI Reference Manual for more information about
changing simulator preferences.

Navigating Through Your Design

When debugging your design from within the GUI, ModelSim keeps a log of all areas of the
design environment you have examined or opened, similar to the functionality in most web
browsers. This log allows you to easily navigate through your design hierarchy, returning to
previous views and contexts for debugging purposes.
Procedure
1. Select then right-click an instance name in a source document.
2. Select one of the following options:
• Open Instance — changes your context to the instance you have selected within the
source file. This is not available if you have not placed your cursor in, or highlighted
the name of, an instance within your source file.
If any ambiguities exist, most likely due to generate statements, this option opens a
dialog box allowing you to choose from all available instances.
• Ascend Env — changes your context to the next level up within the design. This is
not available if you are at the top-level of your design.

ModelSim® SE User's Manual, v10.7 837

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Navigating Through Your Design

• Back/Forward — allows you to change to previously selected contexts. Questa

saves up to 50 context locations. This is not available if you have not changed your
context. (Figure 17-1):
Figure 17-1. Setting Context from Source Files

Note
The Open Instance option is essentially executing an environment command to
change your context. Therefore any time you use this command manually at the
command prompt, that information is also saved for use with the Back/Forward
options.

838 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Data and Objects in the Source Window

Data and Objects in the Source Window

The Source window allows you to display the current value of objects, trace connectivity
information, and display coverage data during a simulation run.
Object Values and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Search for Source Code Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842

Object Values and Descriptions

You can obtain data on objects displayed in the Source window.
To determine the value and description of an object displayed in the Source window, do either
of the following:

• Select an object, then right-click and select Examine or Describe from the context
menu.
• Pause over an object with your mouse pointer to see an examine window popup.
(Figure 17-2)
Figure 17-2. Examine Window Pop Up

You can also invoke the examine and/or describe commands on the command line or in a DO
file.

ModelSim® SE User's Manual, v10.7 839

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Displaying Object Values with Source Annotation

Displaying Object Values with Source Annotation

Source annotation displays simulation values, including transitions, for each signal in your
source file. With source annotation you can interactively debug your design by analyzing your
source files in addition to using the Wave and Objects windows.
Procedure
Turn on source annotation by doing one of the following:

• Select Source > Show Source Annotation

• Right-click a source file and select Show Source Annotation.
Results
Figure 17-3 shows an example of source annotation, where the values are shown in bold red text
and placed under the signals.
Figure 17-3. Source Annotation Example

Note
Transitions are displayed only for those signals that you have logged. The Source window
displays the values for the simulation time shown in the time indicator in the top right corner
of the window. Refer to Setting Simulation Time in the Source Window for more information.

You can highlight a specific signal in the Wave window by double-clicking on an annotation
value in the source file.

840 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Setting Simulation Time in the Source Window

Setting Simulation Time in the Source Window

The Source window includes a time indicator in the top right corner that displays the current
simulation time, the time of the active cursor in the Wave window, or a user-designated time.
Figure 17-4. Current Time Label in Source Window

Procedure
You have several options for setting the time display in the Source window,

• Change time in the Current Time Label.

a. Click the time indicator to open the Enter Value dialog box (Figure 17-5).
b. Change the value to the starting time you want for the causality trace.
c. Click the OK button.
Figure 17-5. Enter an Event Time Value

ModelSim® SE User's Manual, v10.7 841

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Search for Source Code Objects

Search for Source Code Objects

The Source window includes a Find function that allows you to search for specific code. You
can search for one instance of a string, multiple instances, and the original declaration of a
specified object.
Searching for One Instance of a String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Searching for All Instances of a String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Searching for the Original Declaration of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843

Searching for One Instance of a String

You can search for one instance of a string. This search procedure starts from the current
location in the open source file and finds the next instance of the specified search string.
Procedure
1. Make the Source window the active window by clicking anywhere in the window
2. Select Edit > Find from the Main menu or press Ctrl-F. The Search bar is added to the
bottom of the Source Window.
3. Enter your search string, then press Enter
The cursor jumps to the first instance of the search string in the current document and
highlights it. Pressing the Enter key advances the search to the next instance of the string
and so on through the source document.

Searching for All Instances of a String

You can search for and bookmark every instance of a search string making it easier to track
specific objects throughout a source file.
Procedure
1. Enter the search term in the search field.
2. Select the Find Options drop menu and select Bookmark All Matches.

842 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Search for Source Code Objects

Figure 17-6. Bookmark All Instances of a Search

Searching for the Original Declaration of an Object

You can also search for the original declaration of an object, signal, parameter, and so on.
Procedure
1. Double click the object in many windows, including the Structure, Objects, and List
windows. The Source window opens the source document containing the original
declaration of the object and places a bookmark on that line of the document.
2. Double click a hyperlinked section of code in your source document. The source
document is either opened or made the active Source window document and the
declaration is highlighted briefly. Refer to Hyperlinked Text for more information about
enabling hyperlinked text.

ModelSim® SE User's Manual, v10.7 843

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Debugging and Textual Connectivity

Debugging and Textual Connectivity

The Source window provides you with several tools for analyzing and debugging your code.
You can jump to the declaration of an object with hyperlinked text from the Source and other
windows. You can also determine the cause of any signal event or possible drivers or readers for
a signal.
Hyperlinked Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849

Hyperlinked Text
The Source window supports hyperlinked navigation. When you double-click hyperlinked text
the selection jumps from the usage of an object to its declaration and highlights the declaration.
Hyperlinked text is indicated by a mouse cursor change from an arrow pointer icon to a pointing
finger icon:

Double-clicking hyperlinked text does one of the following:

• Jump from the usage of a signal, parameter, macro, or a variable to its declaration.
• Jump from a module declaration to its instantiation, and vice versa.
• Navigate back and forth between visited source files.
Hyperlinked text is off by default. To turn hyperlinked text on or off in the Source window:

1. Make sure the Source window is the active window.

2. Select Source > show Hyperlinks.
To change hyperlinks to display as underlined text set prefMain(HyperLinkingUnderline) to
1 (select Tools > Edit Preferences, By Name tab, and expand the Main Object).

Highlighted Text in the Source Window

The Source window can display text that is highlighted as a result of various conditions or
operations, such as the following.
• Double-clicking an error message in the transcript shown during compilation
• Using Event Traceback > Show Driver
• Coverage-related operations

844 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Highlighted Text in the Source Window

In these cases, the relevant text in the source code is shown with a persistent highlighting. To
remove this highlighted display, right-click the Source window and choose More > Clear
Highlights. You can also perform this action by selecting Source > More > Clear Highlights
from the Main menu.

Note
Clear Highlights does not affect text that you have selected with the mouse cursor.

To produce a compile error that displays highlighted text in the Source window, do the
following:

Procedure
1. Choose Compile > Compile Options
2. In the Compiler Options dialog box, click either the VHDL tab or the Verilog &
SystemVerilog tab.
3. Enable Show source lines with errors and click OK.
4. Open a design file and create a known compile error (such as changing the word “entity”
to “entry” or “module” to “nodule”).
5. Choose Compile > Compile and then complete the Compile Source Files dialog box to
finish compiling the file.
6. When the compile error appears in the Transcript window, double-click it.
7. The source window is opened (if needed), and the text containing the error is
highlighted.
8. To remove the highlighting, choose Source > More > Clear Highlights.
Results
The textual dataflow functions of the Source window only work for pure HDL. They will not
work for SystemC or for complex data types like SystemVerilog classes.
The Source window contains textual connectivity information for the time specified in the time
indicator (refer to Setting Simulation Time in the Source Window). You can explore the
connectivity of your design through the source code. This feature is especially useful when used
with source annotation turned on.
When you double-click an instance name in the Structure (sim) window, a Source window will
open at the appropriate instance. You can then access textual connectivity information in the
Source window by right-clicking any signal. This opens a popup menu that gives you the
choices shown in Figure 17-7.

ModelSim® SE User's Manual, v10.7 845

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Highlighted Text in the Source Window

Figure 17-7. Popup Menu Choices for Textual Dataflow Information

The Event Traceback > Show Driver selection causes the Source window to jump to the
source code defining the driver of the selected signal. If the Driver is in a different Source file,
that file will open in a new Source window and the driver code will be highlighted. You can also
jump to the driver of a signal by double-clicking the signal.
If there is more than one driver for the signal, the number of drivers will be shown in the Show
Drivers Control Bar at the top of the Source window.
There are four buttons in the Show Drivers Control Bar: 1) the History button, 2) the List Menu
button, 3) the Previous button, and 4) the Next button (Figure 17-8).
Figure 17-8. Show Drivers Control Bar Buttons

846 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Highlighted Text in the Source Window

In Figure 17-8, the Show Drivers Control Bar displays “1/12 Drivers” to indicate that the first of
twelve drivers is selected. When you click the List Menu button, a menu drops down showing
all drivers with a checkmark beside the selected driver, which is highlighted in the Source
window (Figure 17-9).
Figure 17-9. Multiple Drivers in the Show Drivers Control Bar

You can jump directly to the source code of any other driver in the list by simply clicking it. Or,
use the Previous and Next buttons to navigate through the list of drivers.
The History button allows you to review past Show Drivers operations (Figure 17-10). Click an
item in the list to return to a previous operation.
Figure 17-10. History Button Displays Past Operations

By default, the drivers shown in the List Menu only include the instance path and the source
text. But the List Menu contains three viewing options that allow you to: Include Process
Names, Include Line Numbers, and Include File Name. Clicking the option toggles it on or off.
Figure 17-11 is an example of the List Menu with all three viewing options displayed.

ModelSim® SE User's Manual, v10.7 847

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Highlighted Text in the Source Window

Figure 17-11. List Menu with All Three Viewing Options On

The driver List Menu in Figure 17-12 shows two drivers. Driver #1 is displayed in black and
driver #2 is in blue. The blue color of driver #2 indicates that the instance path (in this case,
/test1/u1) is different from the starting point (which is /test1/ref_req). When the driver is
displayed in black, it means it has not left the instance it started in.
Figure 17-12. Click Any Driver to Display It

The Show Readers selection opens the Source Readers window. If there is more than one
reader for the signal, all will be displayed (Figure 17-13).

848 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Drag Objects Into Other Windows

Figure 17-13. Source Readers Dialog Displays All Signal Readers

When the trace is complete, the Active Driver Path Details window displays all signals in the
causality path, the Objects window highlights all signals in the path, and the Source window
jumps to the assignment code that caused the event and highlights the code.

Drag Objects Into Other Windows

ModelSim allows you to drag and drop objects from the Source window to the Wave and List
windows. Double-click an object to highlight it, then drag the object to the Wave or List
window. To place a group of objects into the Wave and List windows, drag and drop any section
of highlighted code.

ModelSim® SE User's Manual, v10.7 849

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Code Coverage Data in the Source Window

Code Coverage Data in the Source Window

The Source window includes two columns for code coverage statistics – the Hits column and
the BC (Branch Coverage) column. These columns provide an immediate visual indication
about how your source code is executing. The code coverage indicators are check marks, Xs and
Es, the complete variety of which are described in Source Window Code Coverage Indicator
Icons.
Figure 17-14. Coverage in Source Window

To see more information about any coverage item, click the indicator icon, or in the Hits or BC
column for the line of interest. This brings up detailed coverage information for that line in the
Coverage Details window.

For example, when you select an expression in the Missed Expressions window, and you click
in the column of a line containing an expression, the associated truth tables appear in the
Coverage Details window. Each line in the truth table is one of the possible combinations for
the expression. The expression is considered to be covered (gets a green check mark) only if the
entire truth table is covered.

When you hover over statements, conditions or branches in the Source window, the Hits and BC
columns display the coverage numbers for that line of code. For example, in Figure 17-14, the
blue line shows that the expression (a && b) was hit 5 times and that the branch (if) was
evaluated as true once (1t) and false four times (4f). The value in the Hits column shows the

850 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Coverage Data Display

total coverage for all items (as shown in the Coverage Details window when you click the
specific line in the hits column).

Coverage data presented in the Source window is either calculated “by file” or “by instance”, as
indicated just after the source file name. If coverage numbers are mismatched between Missed
<coverage_type> window and the Source window, check to make sure that both are being
calculated the same — either “by file” or “by instance”.

To display only numbers in Hits and BC columns, select Tools > Code Coverage > Show
Coverage Numbers.

When the source window is active, you can skip to "missed lines" three ways:

• select Edit > Previous Coverage Miss and Edit > Next Coverage Miss from the menu bar
• click the Previous zero hits and Next zero hits icons on the toolbar
• press Shift-Tab (previous miss) or Tab (next miss)
Coverage Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851

Coverage Data Display

ModelSim provides several tools for controlling coverage data display in a Source window.
Choose Tools > Code Coverage from the main menu to display the following commands for
coverage data display:

• Hide/Show coverage data — Toggles the Hits column off and on.
• Hide/Show branch coverage — Toggles the BC column off and on.
• Hide/Show coverage numbers — Displays the number of executions in the Hits and
BC columns rather than check marks and Xs. When multiple statements occur on a
single line an ellipsis ("...") replaces the Hits number. In such cases, hover the cursor
over each statement to highlight it and display the number of executions for that
statement.
• Show coverage By Instance — Displays only the number of executions for the
currently selected instance in the Main window workspace.
Related Topics
Source Window Code Coverage Indicator Icons.

ModelSim® SE User's Manual, v10.7 851

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Breakpoints

Breakpoints
You can set a breakpoint on an executable file, file-line number, signal, signal value, or
condition in a source file. When the simulation hits a breakpoint, the simulator stops, the Source
window opens, and a blue arrow marks the line of code where the simulation stopped. You can
change this behavior by editing the PrefSource(OpenOnBreak) variable.
Note
When running in full optimization mode, breakpoints may not be set. Run the design in non-
optimized mode (or set +acc arguments) to enable you to set breakpoints in the design.
Refer to Preservation of Object Visibility for Debugging and Design Object Visibility for
Designs with PLI.

Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852

Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860

Setting Individual Breakpoints in a Source File

You can set individual file-line breakpoints in the Line number column of the Source Window.
Procedure
1. Click the line number column of the Source window next to a red line number and a red
ball denoting a breakpoint will appear (Figure 17-15).
2. The breakpoint markers (red ball) are toggles. Click once to create the breakpoint; click
again to disable or enable the breakpoint.

852 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Setting Breakpoints with the bp Command

Figure 17-15. Breakpoint in the Source Window

Related Topics
Setting GUI Preferences.

Setting Breakpoints with the bp Command

You can set a file-line breakpoints with the bp command to add a file-line breakpoint from the
VSIM> prompt.
Procedure
1. Enter a bp command at the command line. For example, entering
bp top.vhd 147

2. sets a breakpoint in the source file top.vhd at line 147.

Related Topics
bp

Setting SystemC Breakpoints

Your C Debug settings must be in place prior to setting a breakpoint since C Debug is invoked
when you set a breakpoint within a SystemC module. Once invoked, C Debug can be exited
using the C Debug menu.
Related Topics
Setting Up C Debug

ModelSim® SE User's Manual, v10.7 853

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Editing Breakpoints

Editing Breakpoints
There are several ways to edit a breakpoint in a source file.
• Select Tools > Breakpoints from the Main menu.
• Right-click a breakpoint in your source file and select Edit All Breakpoints from the
popup menu.
• Click the Edit Breakpoints toolbar button from the Simulate Toolbar.
Using the Modify Breakpoints Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Deleting Individual Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Deleting Groups of Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856

Using the Modify Breakpoints Dialog Box

The Modify Breakpoints dialog box provides a list of all breakpoints in the design organized by
ID number.
Procedure
1. Select a file-line breakpoint from the list in the Breakpoints field.
2. Click Modify, which opens the File Breakpoint dialog box, Figure 17-16.

854 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Editing Breakpoints

Figure 17-16. Editing Existing Breakpoints

3. Fill out any of the following fields to edit the selected breakpoint:
• Breakpoint Label — Designates a label for the breakpoint.
• Instance Name — The full pathname to an instance that sets a SystemC breakpoint
so it applies only to that specified instance.
• Breakpoint Condition — One or more conditions that determine whether the
breakpoint is observed. If the condition is true, the simulation stops at the
breakpoint. If false, the simulation bypasses the breakpoint. A condition cannot refer
to a VHDL variable (only a signal). Refer to Setting Conditional Breakpoints for
more information.

ModelSim® SE User's Manual, v10.7 855

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Saving and Restoring Source Breakpoints

• Breakpoint Command — A string, enclosed in braces ({}) that specifies one or

more commands to be executed at the breakpoint. Use a semicolon (;) to separate
multiple commands.

Tip
: These fields in the File Breakpoint dialog box use the same syntax and format
as the -inst switch, the -cond switch, and the command string of the bp
command. For more information on these command options, refer to the bp
command in the Reference Manual.

4. Click OK to close the File Breakpoints dialog box.

5. Click OK to close the Modify Breakpoints dialog box.

Deleting Individual Breakpoints

You can permanently delete individual file-line breakpoints using the breakpoint context menu.
Procedure
1. Right-click the red breakpoint marker in the file line column.
2. Select Remove Breakpoint from the context menu.

Deleting Groups of Breakpoints

You can delete groups of breakpoints with the Modify Breakpoints Dialog.
Procedure
1. Open the Modify Breakpoints dialog.
2. Select and highlight the breakpoints you want to delete.
3. Click the Delete button
4. OK.

Saving and Restoring Source Breakpoints

You can save your breakpoints in a separate breakpoints.do file or save the breakpoint settings
as part of a larger .do file that recreates all debug windows and includes breakpoints.
Procedure
1. To save your breakpoints in a .do file, select Tools > Breakpoints to open the Modify
Breakpoints dialog. Click Save. You will be prompted to save the file under the name:
breakpoints.do.

856 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Saving and Restoring Source Breakpoints

To restore the breakpoints, start the simulation then enter:

do breakpoints.do

2. To save your breakpoints together with debug window settings, enter

write format restart <filename>

The write format restart command creates a single .do file that saves all debug windows,
file/line breakpoints, and signal breakpoints created using the when command. The file
created is primarily a list of add list add wave, and configure commands, though a few
other commands are included. If the ShutdownFile modelsim.ini variable is set to this
.do filename, it will call the write format restart command upon exit.
To restore debugging windows and breakpoints enter:
do <filename>.do

Note
Editing your source file can cause changes in the numbering of the lines of code.
Breakpoints saved prior to editing your source file may need to be edited once they
are restored in order to place them on the appropriate code line.

Related Topics
do

ModelSim® SE User's Manual, v10.7 857

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Setting Conditional Breakpoints

Setting Conditional Breakpoints

In dynamic class-based code, an expression can be executed by more than one object or class
instance during the simulation of a design. You set a conditional breakpoint on the line in the
source file that defines the expression and specifies a condition of the expression or instance
you want to examine. You can write conditional breakpoints to evaluate an absolute expression
or a relative expression.
You can use the SystemVerilog keyword this when writing conditional breakpoints to refer to
properties, parameters or methods of an instance. The value of this changes every time the
expression is evaluated based on the properties of the current instance. Your context must be
within a local method of the same class when specifying the keyword this in the condition for a
breakpoint. Strings are not allowed.

The conditional breakpoint examples below refer to the following SystemVerilog source code
file source.sv:

Figure 17-17. Source Code for source.sv

858 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Setting Conditional Breakpoints

1 class Simple;
2 integer cnt;
3 integer id;
4 Simple next;
5
6 function new(int x);
7 id=x;
8 cnt=0
9 next=null
10 endfunction
11
12 task up;
13 cnt=cnt+1;
14 if (next) begin
15 next.up;
16 end
17 endtask
18 endclass
19
20 module test;
21 reg clk;
22 Simple a;
23 Simple b;
24
25 initial
26 begin
27 a = new(7);
28 b = new(5);
29 end
30
31 always @(posedge clk)
32 begin
33 a.up;
34 b.up;
35 a.up
36 end;
37 endmodule

Note
You must use the +acc switch when optimizing with vopt to preserve visibility of
SystemVerilog class objects.

Setting a Breakpoint For a Specific Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

Setting a Breakpoint For a Specified Value of Any Instance . . . . . . . . . . . . . . . . . . . . . 860

Setting a Breakpoint For a Specific Instance

You can set a breakpoint for a value of specific instance from the GUI or from the command
line.
Procedure
Enter the following on the command line

ModelSim® SE User's Manual, v10.7 859

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Run Until Here

bp simple.sv 13 -cond {this.id==7}

Results
The simulation breaks at line 13 of the simple.sv source file (Figure 17-17) the first time module
a hits the expression because the breakpoint is evaluating for an id of 7 (refer to line 27).

Setting a Breakpoint For a Specified Value of Any

Instance
You can set a breakpoint for a specific value of any instance from the GUI or from the
command line.
Procedure
From the command line enter:

bp simple.sv 13 -cond {this.cnt==8}

From the GUI:

a. Right-click line 13 of the simple.sv source file.
b. Select Edit Breakpoint 13 from the drop menu.
c. Enter
this.cnt==8

in the Breakpoint Condition field of the Modify Breakpoint dialog box. (Refer to
Figure 17-16) Note that the file name and line number are automatically entered.
Results
The simulation evaluates the expression at line 13 in the simple.sv source file (Figure 17-17),
continuing the simulation run if the breakpoint evaluates to false. When an instance evaluates to
true the simulation stops, the source is opened and highlights line 13 with a blue arrow. The first
time cnt=8 evaluates to true, the simulation breaks for an instance of module Simple b. When
you resume the simulation, the expression evaluates to cnt=8 again, but this time for an instance
of module Simple a.

Run Until Here

The Source window allows you to run the simulation to a specified line of code with the “Run
Until Here” feature. When you invoke Run Until Here, the simulation will run from the
current simulation time and stop on the specified line unless:
• The simulator encounters a breakpoint.
• Optionally, the Run Length preference variable causes the simulation run to stop.

860 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Run Until Here

• The simulation encounters a bug.

Note
Run Until Here will not execute if you are running a fully optimized design. You
must run the simulation in non-optimized mode or set +acc arguments to enable you
to execute Run Until Here. Refer to Preservation of Object Visibility for Debugging and
Design Object Visibility for Designs with PLI.

To specify Run Until Here, right-click the line where you want the simulation to stop and
select Run Until Here from the pop up context menu. The simulation starts running the
moment the right mouse button releases.

The simulator run length is set in the Simulation Toolbar and specifies the amount of time the
simulator will run before stopping. By default, Run Until Here will ignore the time interval
entered in the Run Length field of the Simulation Toolbar unless the
PrefSouce(RunUntilHereUseRL) preference variable is set to 1 (enabled). When
PrefSource(RunUntilHereUseRL) is enabled, the simulator will invoke Run Until Here and
stop when the amount of time entered in the Run Time field has been reached, a breakpoint is
hit, or the specified line of code is reached, whichever happens first.

For more information about setting preference variables, refer to Setting GUI Preferences in the
GUI Reference Manual.

ModelSim® SE User's Manual, v10.7 861

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Source Window
Source Window Bookmarks

Source Window Bookmarks

Source window bookmarks are graphical icons that give you reference points within your code.
The blue flags mark individual lines of code in a source file and can assist visual navigation
through a large source file by marking certain lines. Bookmarks can be added to currently open
source files only and are deleted once the file is closed.
Setting and Removing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

Setting and Removing Bookmarks

You can set bookmarks in the following ways.
Procedure
1. Set an individual bookmark.
a. Right-click in the Line number column on the line you want to bookmark then select
Add/Remove Bookmark.
2. Set multiple bookmarks based on a search term refer to Searching for All Instances of a
String.
3. To remove a bookmark:
• Right-click the line number with the bookmark you want to remove and select Add/
Remove Bookmark.
• Select the Clear Bookmarks button in the Source toolbar.

Source Window Preferences

You can customize a variety of settings for Source windows. You can change the appearance
and behavior of the window in several ways.
Related Topics
Customizing the Source Window and GUI Preferences.

862 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 18
Using Causality Traceback

The Causality Traceback feature helps you determine the cause of any signal event or all
possible drivers of a signal. It allows you to trace backward through simulation time to find both
event drivers and the logic behind the drivers. Causality Traceback uses the ModelSim
optimization utility to detect combinatorial and sequential logic events, and saves data about
those events to your working library in a .dbg file. The .dbg file is a connectivity and structure
database you can use for current simulation and post simulation analysis.
After a causality trace is complete, the design context automatically changes, and selects all
signals found in the trace. You can view details of the trace in the Wave, Source, Objects,
Schematic, Structure, and Active Driver Path Details windows. These windows automatically
update with the latest trace results when the trace is complete.

During a trace analysis, multiple input values may change at the same time. When this occurs,
“Multiple Drivers” are indicated momentarily in the Show Drivers control bar of the Source
window and the number of drivers is displayed.

Creating a Database for Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863

Initiating Causality Traceback from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . 866
Initiating Causality Traceback from the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Multiple Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Causality Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Causality Traceback Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888

Creating a Database for Causality Traceback

Before you can initiate a causality trace, you must create the connectivity and structure database
required for the trace.
Procedure
1. Recommended Procedure for Database Creation
The recommended procedure gives you complete control of the optimization process.
a. Create a library for your work.
vlib <library_name>

b. Compile your design into the library.

vcom and/or vlog

ModelSim® SE User's Manual, v10.7 863

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Creating a Database for Causality Traceback

c. Optimize your design and collect combinatorial and sequential logic data.
vopt +acc <filename> -o <optimized_filename> -debugdb

The +acc argument maintains visibility into your design for debugging, while the -
debugdb argument saves combinatorial and sequential logic events to the working
library. All +acc options execute, even when you include a -debugdb option.
d. Load your design (elaboration).
vsim -debugdb <optimized_filename>

The -debugdb argument instructs the simulator to look for combinatorial and
sequential logic event data in the working library, then creates the debug database
(vsim.dbg) from this information.
The default filename for the .dbg file is vsim.dbg. If you want to create a different
name, use the following command syntax:
vsim -debugdb=<custom_name>.dbg -wlf <custom_name>.wlf
<optimized_filename>

The <custom_name> must be the same for the .dbg file and the .wlf file.
e. Log simulation data.
log -r /* or add wave -r /*

It is advisable to log the entire design to provide historic values of the events of
interest, plus their drivers. However, to reduce overhead, you can log only the
regions of interest.
You can use the log command to save the simulation data to the .wlf file. Or, use the
add wave command to log the simulation data to the .wlf file and display simulation
results as waveforms in the Wave window.
f. Run the simulation.
g. Initiate a causality trace from the command line or from the GUI.
2. Abbreviated Procedure for Database Creation
You can abbreviate the database creation procedure with the steps that follow. However,
this abbreviated procedure does not give you the control over the optimization process
provided by the recommended procedure above.
a. Create a library for your work.
vlib <library_name>

b. Compile your design.

vcom and/or vlog

c. Load your design

864 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Creating a Database for Causality Traceback

vsim -voptargs=”+acc” -debugdb <design_name>

The -voptargs=”+acc” argument for the vsim command maintains visibility into
your design for debugging.
The -debugdb argument performs a pre-simulation analysis of the sequential and
combinatorial elements in your design and generates the required debug information
for schematic analysis.
d. Log your design
log -r /* or add wave -r /*

e. Run the simulation

f. Initiate a causality trace from the command line or from the GUI.

ModelSim® SE User's Manual, v10.7 865

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Initiating Causality Traceback from the Command Line

Initiating Causality Traceback from the

Command Line
You can initiate causality traceback from the command line with the find drivers command.
This command is used for current or post-simulation debugging.
Using the find drivers Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Command Line Options for Setting Report Destination . . . . . . . . . . . . . . . . . . . . . . . . . 866
Command Line Options for Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Performing Post-simulation Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868

Using the find drivers Command

The find drivers command traces backward in time to find the active driver(s), processes, or first
elements of the specified signal or signal event.
Note
All arguments for the find drivers command must precede the signal name.

Prerequisites
Create the connectivity and structure database as shown in Creating a Database for Causality
Traceback.

Procedure
Use the find drivers command to initiate a causality trace.

Note
You can interrupt the various “find drivers” operations by using the Escape key.

Related Topics
find drivers

Command Line Options for Setting Report

Destination
The command line arguments to the find drivers command enable you to set the destination for
reporting causality trace results.
Table 18-1 shows the command line arguments.

866 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Command Line Options for Text Report Formatting

Table 18-1. Setting Causality Traceback Report Destination

Command line Description
argument
-transcript Reports trace results to the Transcript window in tabular format
(unless the -compact argument is used). It is the default behavior if
the -schematic, -source, or -wave arguments are not used.
-source Opens the Source window with the source file that contains the line
of code found by the trace. Scrolls to that line, and highlights the
driving signal. This argument is not allowed if the -possible
argument is used.
-wave Adds all signals in the path found by the trace to a dedicated Wave
window. Cursors are added to show the beginning and ending
times of the trace. The dedicated Wave window is cleared of
signals before displaying the results of a new trace.
-schematic Adds all signals contained in the causality path found by the trace
to a dedicated Schematic window. Automaticaly selects the net
segments connecting the beginning and ending signals.

Command Line Options for Text Report Formatting

Command line arguments for the find drivers command are available for reporting causality
trace results into the Transcript window.
The default reporting format displays the path information, one signal per line, with each “field”
contained in a separate column (aligned vertically). Certain fields within the data (such as
parent scope and signal name) are automatically truncated to a specific number of characters
controlled by the -width argument. Use the -noclip argument to disable the character length
check.
Table 18-2. Text Report Formatting
Command line Description
argument
-compact <string> Displays causality trace results in compact format, using a specified
text string to separate the fields.
-tcl Displays trace results in a TCL list.
-width Specifies the maximum size of each column when data is returned
to the transcript in tabular form.
-noclip Allows columns to be arbitrarily long when returned to the
transcript.
-last Returns the results from the last completed trace to the transcript. 1

ModelSim® SE User's Manual, v10.7 867

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Performing Post-simulation Causality Traceback

1. The -last argument is useful for trying the various format options. It allows you to quickly see how each
format argument (-compact, -tcl, -width, and -noclip) affects the output.

Performing Post-simulation Causality Traceback

Perform post-simulation causality traceback after completing a simulation and logging the
waveform and debug information.
Prerequisites
• Run a simulation and save the logged information in a .wlf file.
Procedure
1. Change your directory to the location of the .wlf file
2. Use one of the following methods:
a. If your simulation used the default settings, where the WLF file is named vsim.wlf,
enter the command:
vsim -view vsim.wlf

The simulator automatically looks for and loads the similarly named vsim.dbg file.
b. If your simulation used a custom name for the WLF and DBG files, enter the
command
vsim -view <custom_name>.wlf

c. Usethe dataset open command if you are entering the command from within the
GUI.

868 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Initiating Causality Traceback from the GUI

Initiating Causality Traceback from the GUI

You can initiate causality traceback from several debugging windows (Wave, Source, Objects,
Schematic, Structure) using menu or toolbar button selections. In addition, you may designate
any arbitrary time as the start time for the trace.
The Event Traceback toolbar button provides access to these traces. When you press-and-
hold this button, a drop-down menu appears (Figure 18-1).

Figure 18-1. Event Traceback Toolbar Button Menu

Initiate a causality trace from any arbitrary time by selecting Show Cause from Time, Show
Driver from Time, or Show Root Cause from Time in the toolbar button menu above. You
can also use the time indicator in the Source window to set a starting time for the causality trace.

Note
Full causality traceback functionality requires optimization of your design with vopt or vsim
-voptargs. Refer to Creating a Database for Causality Traceback for more information.

Trace to the First Sequential Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870

Tracing to the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Tracing to the Root Cause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Tracing to the Root Cause of an ‘X’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Finding All Possible Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Tracing from a Specific Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880

ModelSim® SE User's Manual, v10.7 869

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Trace to the First Sequential Process

Trace to the First Sequential Process

You can initiate a causality trace to the first sequential process from the Wave, Objects,
Schematic, or Source windows.
Initiating the Trace from the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Initiating the Trace from the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Initiating the Trace from the Objects or Schematics Windows . . . . . . . . . . . . . . . . . . . 874

Initiating the Trace from the Wave Window

You can use Wave window menus and toolbar button selections to trace from a signal event to
the sequential process(es) that caused the event.
Prerequisites
Run the simulation.

Procedure
1. Select a signal of interest in the Wave window.
2. Perform either one of the following actions:
• Double-click (left mouse button) an event of interest in the waveform of the selected
signal.
• Click an event of interest in the waveform of the selected signal, then click the
Event Traceback toolbar button.

Either of these actions initiates a trace to find the sequential process(es) that caused the
selected event.
Results
When the causality trace ends, an annotated Source window opens with the causal process
highlighted (Figure 18-2). The Show Drivers Control Bar indicates how many drivers there are
for the event of interest. In this example, there is only one driver.

870 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Trace to the First Sequential Process

Figure 18-2. Cause is Highlighted in Source Window

Click the Control Bar to display a drop-down menu that shows the driver (Figure 18-3), or a list
of drivers if there are multiple drivers (see Multiple Drivers).
Figure 18-3. Click to Show Drivers Control Bar to See Driver(s)

You can also display information about the sequential process(es) that caused the selected event
by opening the Active Driver Path Details window. To open this window, click and hold the
Event Traceback toolbar button and select View Path Details from the drop-down menu
(Figure 18-1). The Active Driver Path Details window (Figure 18-4) displays the selected
signal name, the time of each process in the causality path to the first sequential process, and
details about the location of the causal process in the code.

ModelSim® SE User's Manual, v10.7 871

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Trace to the First Sequential Process

Figure 18-4. Active Driver Path Details Window

The Wave window automatically adds an active cursor named “Trace” at the time of the process
that caused the selected event. The time from the causal process to the selected event displays as
the relative time between the cursors (Figure 18-5).
Figure 18-5. Active Cursor Show Time of Causal Process

The causal process is highlighted in the Structure window (Figure 18-6).

872 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Trace to the First Sequential Process

Figure 18-6. Causal Process Highlighted in Structure Window

The causal signal is highlighted in the Objects window (Figure 18-7).

Figure 18-7. Causal Signal Highlighted in the Objects Window

The Transcript window displays the command line equivalent of the GUI actions:
find drivers -source -time {<time>} -cause <signal>

Initiating the Trace from the Source Window

The Source window includes a Current Time indicator in the top right corner that displays the
current simulation time, the time of the active cursor in the Wave window, or a user-designated
time. You can use this time indicator to designate a start time for a causality trace.
Figure 18-8. Time Indicator in Source Window

Prerequisites
Run the simulation.

ModelSim® SE User's Manual, v10.7 873

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Trace to the First Sequential Process

Procedure
1. Click the time indicator and select Set Current Time to open the Enter Value dialog
box (Figure 18-9).
2. Change the value to the starting time you want for the causality trace.
3. Click the OK button.
Figure 18-9. Enter an Event Time Value for Causality Tracing

4. In the Source window, double-click a signal of interest, or do the following:

a. Highlight a signal of interest in the Source window.
b. Right-click anywhere in the Source window to open a popup menu.
5. Select Event Traceback > Show Cause in the popup menu.
Results
When the trace is complete, the Source window jumps to the assignment code that caused the
event and highlights the code; and the Objects window highlights all signals in the path. You
can open the Active Driver Path Details window to display all signals in the causality path.

Initiating the Trace from the Objects or Schematics

Windows
The Objects and Schematic windows use either the time of the selected cursor in the Wave
window or the Time indicator in the Source window—whichever was set last—as the starting
time for the event trace.
Prerequisites
Run the simulation.

874 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Tracing to the Immediate Driving Process

Procedure
1. Select a signal.
2. Perform one of the following actions:
• Click the Event Traceback button in the Simulate Toolbar. Refer to Simulate
Toolbar in the GUI Reference Manual for more information.
• Right-click anywhere in either window and select Event Traceback > Show Cause
from the popup menu.
Results
When the trace is complete, you will see the following:
• The Active Driver Path Details window displays all signals in the causality path.
• The Objects window highlights all signals in the path.
• The Source window jumps to the assignment code that caused the event and highlights
the code.

Tracing to the Immediate Driving Process

You can trace to the immediate driving process(es) of any signal of interest in the Wave
Window.
Prerequisites
Run the simulation.

Procedure
1. Double-click the waveform trace of the signal of interest in Wave window.
This opens an annotated Source window with the driving process highlighted. The Show
Drivers Control Bar at the top of the Source window shows how many drivers there are
(Figure 18-10).

ModelSim® SE User's Manual, v10.7 875

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Tracing to the Immediate Driving Process

Figure 18-10. Source Window - Show Drivers Control Bar

The immediate driving process may be a combinatorial or sequential assignment.

Note
You can also trace to the immediate driving process(es) using the Event Traceback
toolbar button or by right-clicking the Wave window and using the popup menu.

2. After the simulation, click a signal of interest in the Wave window. Click the selected
signal’s waveform to place an active cursor at an event of interest.
3. Perform one of the following actions:
• Click and hold the Event Traceback toolbar button until a drop-down menu appears
(Figure 18-11), then select Show Driver from the drop-down menu.
Figure 18-11. Selecting Show Driver from Show Cause Drop-Down Menu

• Right-click anywhere in the waveform pane and select Event Traceback > Show
Driver from the popup menu (Figure 18-12). The time shown in parentheses is the
time at which the causality trace will start.
Figure 18-12. Right-click Menu – Show Driver

876 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Tracing to the Root Cause

Causality Traceback examines the .dbg database for the immediate driving
process(es) of the selected signal event, then opens a Source window with the code
of the driving process(es) highlighted (Figure 18-2).
4. Open the Active Driver Path Details window by clicking and holding the Event
Traceback toolbar button, then selecting View Path Details from the drop-down menu.
The Active Driver Path Details window shows the selected signal name, the start time of
the causality trace (At time), the time of the driving process, and details about the
driving process (Figure 18-13).
Figure 18-13. Details of the Immediate Driving Process

The Transcript window displays the command line equivalent of the GUI actions.
find drivers -source -time {<time>} <signal>

Tracing to the Root Cause

Causality Traceback allows you to trace an event back to the root cause of that event, crossing
multiple clock cycles and even multiple clock domains.
Prerequisites
Run the simulation.

Procedure
1. Select a signal of interest in the Wave window.
2. Click the selected signal’s waveform at any point to place a cursor there. The time of
this cursor is the start time of the causality trace.
3. Initiate a root cause trace using any of the following methods:
• Right-click anywhere in the waveform pane and select Event Traceback > Show
Root Cause from the popup menu.

ModelSim® SE User's Manual, v10.7 877

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Tracing to the Root Cause

• Click and hold the Event Traceback button until the drop-down menu appears, then
select Show Root Cause from the menu.
• If you have performed a trace to the first sequential process (Show Cause), or a trace
to the immediate process (Show Drivers), you can initiate a trace to the root cause
from the Active Driver Path Details window by clicking the Trace to Root Cause
button.

Results
The Active Driver Path Details window displays a list of all the signals linked from the root
cause to the event of interest, as shown in Figure 18-14.
Figure 18-14. Trace Event to Root Cause

The Source window jumps to the root cause source code and highlights the relevant line
(Figure 18-15).
Figure 18-15. Root Cause Highlighted in Source Window

878 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Tracing to the Root Cause of an ‘X’

The Transcript window displays the command line equivalent of the GUI actions:
find drivers -source -time {<time>} -root <signal>

The -root switch for the find drivers command initiates the trace to the root cause of the selected
event.

Tracing to the Root Cause of an ‘X’

Causality Traceback can be used to search for the source of an unknown 'X' signal value. This
analysis provides the automatic identification of the root cause of an ‘X’ over multiple cycles
and clock domains.
Prerequisites
Run the simulation.

Procedure
1. Select a signal of interest that has an unknown ‘X’ value.
2. Click and hold the Event Traceback button until the drop-down menu appears.
3. Click “Show ‘X’ Cause (ChaseX)” as in Figure 18-16.
Figure 18-16. Show X Cause

Or, you can use the -chasex switch with the find drivers command.

Finding All Possible Drivers

You can find and display all possible driving assignments of a selected signal.
Prerequisites
Run the simulation.

Procedure
1. Select a signal of interest in the Wave window or Source window.
2. Click and hold the Event Traceback button until the drop-down menu appears.

ModelSim® SE User's Manual, v10.7 879

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Tracing from a Specific Time

3. Select Show All Possible Drivers from the drop-down menu (Figure 18-17).
Figure 18-17. Show All Possible Drivers Menu Selection

This action displays all possible driving assignments of the selected signal
(Figure 18-18) in the Source window’s Show Drivers Control Bar, without regard to the
time of any particular signal event. Refer to Multiple Drivers for more information.
Figure 18-18. Possible Drivers in the Source Window

4. The Transcript window displays the command line equivalent of the GUI actions:
find drivers -possible <signal>

5. The -possible switch for the find drivers command initiates the search for all possible
driving assignments of the selected signal.

Tracing from a Specific Time

The Causality Traceback feature allows you to initiate a trace to the cause of a signal event from
any arbitrary time.

880 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Multiple Drivers

Prerequisites
Run the simulation.

Procedure
1. Click and hold the Show Cause button until the drop-down menu appears
(Figure 18-19).
Figure 18-19. Selecting a Specific Time for a Trace

You can specify an event time and trace to:

• the first sequential process (Show Cause from Time)
• the immediate driving process (Show Driver from Time)
• the root cause (Show Root Cause from Time)
When you make any one of these three selections, the Enter Value dialog box opens
(Figure 18-20).
Figure 18-20. Enter Value Dialog Box

2. Enter a starting time for the causality trace.

3. Click the OK button.

Multiple Drivers
Depending on the complexity of the design, some signal events may be driven by multiple
processes. When this occurs, the number of drivers is shown in the Show Drivers Control Bar at
the top of the Source window.
The Show Drivers Control Bar has four buttons: History, List Menu, Previous, and Next
(Figure 18-21).

ModelSim® SE User's Manual, v10.7 881

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Multiple Drivers

Figure 18-21. Show Drivers Control Bar Buttons

In Figure 18-21, the Show Drivers Control Bar displays “1/12 Drivers” to indicate that the first
of twelve drivers is selected. When you click the List Menu button, a menu drops down showing
all drivers, with a checkmark beside the selected driver, which is highlighted in the Source
window (Figure 18-22).

Figure 18-22. Multiple Drivers in the Show Drivers Control Bar

You can jump directly to the source code of any other driver in the list by clicking it. You can
also use the Previous and Next buttons to navigate through the list of drivers.

The History button allows you to review past Show Drivers operations (Figure 18-23). Click an
item in the list to return to a previous operation.

882 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Multiple Drivers

Figure 18-23. History Button Displays Past Operations

By default, the drivers in the List Menu only include the instance path and the source text. But
the List Menu contains three other viewing options: Include Process Names, Include Line
Numbers, and Include File Name. Clicking an option toggles it on or off. Figure 18-24 is an
example of the List Menu with all three viewing options displayed.

Figure 18-24. List Menu with All Three Viewing Options On

The driver List Menu in Figure 18-25 shows two drivers. Driver #1 is displayed in black and
driver #2 is in blue. The blue color of driver #2 indicates that the instance path (in this case, /
test1/u1) is different from the starting point (which is /test1/ref_req). Black indicates that the
driver has not left the instance it started in.

ModelSim® SE User's Manual, v10.7 883

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Causality Path Details

Figure 18-25. Click Any Driver to Display It

You can double-click any variable in the Source window to produce a list of drivers in the Show
Drivers Control Bar.

Causality Path Details

The Active Driver Path Details window provides two options for viewing causality path details:
the Schematic window and the Wave window.
Figure 18-26 shows two buttons in the Active Driver Path Details window – one for viewing
path details in a dedicated Schematic window and one for viewing details in a dedicated Wave
window.

Figure 18-26. View Path Details Buttons

When you click the Schematic Window button, a dedicated Schematic (Path Details) window
opens (Figure 18-27). It displays the causality path in the top half of the window (the schematic
in the Incremental view) and lists all causality path signals in the bottom half (the Wave viewer)
of the window. The causality path, from the beginning of the trace to the end, is highlighted in
red in the schematic.

When you perform another causality trace, all signals contained in the path found by the new
trace are added to the previous trace in the schematic.

884 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Causality Path Details

Figure 18-27. Causality Path Details in the Schematic Window

In the Wave viewer (Figure 18-27), a cursor named “Trace Begin” marks the beginning of the
causality trace; a “Trace End” cursor marks the end of the trace. In the Schematic view, the path
of the trace highlights in red.

When you select a signal in the Wave viewer portion of the Schematic window it highlights in
the schematic. You can click through the signals in the Wave view to explore the connectivity
of the causality path in the schematic view.

The times displayed in the Path Times bar, at the bottom left of the Schematic view, correspond
to the times found during the trace. The Path Times bar also includes a “Start” and an “ALL”
label. The times, Start, and ALL labels can be selected (clicked), and will perform the following
actions:

• Click a time to see the signals that were changing at the selected time highlighted in red.
Signals that changed at a prior traced time (if one exists) are highlighted in green.
• Click Start to see the signal used to run the trace highlighted in red.
• Click ALL to see all signals identified during the trace highlighted in red.

ModelSim® SE User's Manual, v10.7 885

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Causality Path Details

For example, Figure 18-28 shows what happens when time “810” is selected. Signals that were
changing at the selected time are red and those that changed a prior traced time are green.

Figure 18-28. Time 810 Selected in Path Times Bar

Notice that the selected time in the Path Times bar is underlined in red to emphasize that it is the
selected time. In addition, the Current Time label in the upper right hand corner displays the
selected time.

You can close the Path Times bar by clicking the X button in the bar. To reopen the bar, click
the right mouse button to open a popup menu and selectEvent Traceback > View Path Times.

Note
The Path Times bar is displayed only in the dedicated Schematic (Path Details) window that
results from a causality trace.

Returning to the Active Driver Path Details window (Figure 18-4), when you click the Wave
Window button a dedicated Wave window opens that includes “(Path Details)” as part of its
title (Figure 18-29). This Wave window lists each signal in the path of the causality trace and
includes “Trace Begin” and “Trace End” cursors. When you perform another trace, this
dedicated window is updated with signals in the path of the new trace, with updated “Trace
Begin” and “Trace End” cursors.

886 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Causality Path Details

Figure 18-29. Causality Path Details in the Wave Window

ModelSim® SE User's Manual, v10.7 887

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Causality Traceback Preferences

Causality Traceback Preferences

Access: Click and hold the Event Traceback button to activate the drop down menu, then select
Preferences.
You can set Causality Traceback preferences to fit your work environment.
Description
Figure 18-30. Causality Trace Options

Fields
• Wave Window Options
o The Wave Window options are on by default. A cursor, named “Trace” in the Wave
window, shows the location of the completed trace.

888 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Using Causality Traceback
Causality Traceback Preferences

o The action of double-clicking a signal in the Wave Window can be set to one of the
following choices:
• Do Nothing
• Show Drivers in Schematic
• Show Drivers in Dataflow
• Find Immediate Driver
• Find Active Driver
• Find Root Cause
• Find All Drivers
• Source Window Options
o The action of double-clicking a signal in the Source Window can be set to one of the
following actions:
• Find Immediate Driver
• Find Active Driver
• Find Root Cause
• Find All Drivers
• Schematic Window Options
o By default, new causality traces are added to existing traces in the Schematic
window. Click the check box to remove existing traces before showing new
causality path details.
• After a Trace Completes Options
o The “Open the Path Details window” option automatically opens the Active Path
Driver Details window when a trace completes if this option is checked. To open
the Active Path Driver Details window separately, click and hold on the Event
Traceback button and select View Path Details.
o By default, the Schematic, Source, and Dataflow windows sync to the current time
cursor in the Wave window to match the end time of a trace. You must select Wave
Window > Add cursor in the Causality Trace Options dialog box, showing the
location of a completed trace, for this to work.
• Other Options
o You can elect to highlight the active drivers of a signal from all possible drivers.
o You can elect to have Causality Traceback ask before doing a causality path trace if
the current time differs from the time of the last completed trace.

ModelSim® SE User's Manual, v10.7 889

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Using Causality Traceback
Causality Traceback Preferences

o You can choose to have a warning issued if the design was simulated without the
-debugdb option and a debugging database is not available. Refer to Creating a
Database for Causality Traceback for more information about the vsim -debugdb
option.
o You can choose the default window to show the results of a trace:
i. Source Window — (default) Opens with the causal process highlighted.
ii. Schematic Window — Opens with the causal path displayed and a Wave pane
showing the driving signal waveforms. Refer to Causality Path Details for more
information.
iii. Wave Window — opens a new Wave window populated with the driving
signal(s) and waveforms.

890 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 19
Code Coverage

Code coverage is the only verification metric generated automatically from design source in
RTL or gates. While a high level of code coverage is required by most verification plans, it does
not necessarily indicate correctness of your design. It only measures how often certain aspects
of the source are exercised while running a suite of tests.
Missing code coverage is usually an indication of one of two things: either unused code, or
holes in the tests. Because it is automatically generated, code coverage is a metric achieved with
relative ease, obtained early in the verification cycle. 100% code coverage can be achieved even
for designs containing impossible to achieve coverage (because of sections containing unused
code) by using a sophisticated exclusions mechanism (see “Coverage Exclusions”). Code
coverage statistics are collected and can be saved into the Unified Coverage DataBase for later
analysis.

This chapter includes the following topics related to code coverage.

Overview of Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893

Language and Datatype Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Usage Flow for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Specifying Coverage Types for Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Rules for Applying Coverage with cover and nocover. . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Enabling Simulation for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Code Coverage in the Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Displaying Coverage Summary in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . 907
Understanding Unexpected Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Statement Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Branch Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Condition and Expression Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
What Objects can be Excluded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943

ModelSim® SE User's Manual, v10.7 891

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage

Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943

Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude Individual Metrics with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Adaptive Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Toggle Exclusion Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Exclude Nodes from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
FSM Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Code Coverage Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Coverconstructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Code Coverage Mode Interaction with Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . 977
Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
The toggle report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Report Using the Coverage Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
XML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Notes on Coverage and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Interaction of Optimization and Coverage Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992

892 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Overview of Code Coverage Types

Overview of Code Coverage Types

ModelSim code coverage provides graphical and report file feedback on the following.
• Statement coverage — counts the execution of each statement on a line individually,
even if there are multiple statements in a line.
• Branch coverage — counts the execution of each conditional “if/then/else” and “case”
statement and indicates when a true or false condition has not executed.
• Condition coverage — analyzes the decision made in “if” and ternary statements and
can be considered as an extension to branch coverage.
• Expression coverage — analyzes the expressions on the right hand side of assignment
statements, and is similar to condition coverage.
• Toggle coverage — counts each time a logic node transitions from one state to another.
• FSM coverage — counts the states, transitions, and paths within a finite state machine.
• SystemVerilog class coverage — collects data for each elaborated class type and each
specialization of a parameterized class.
For details related to each of these types of coverage, see “Code Coverage Types”.

Language and Datatype Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893

Language and Datatype Support

ModelSim code coverage supports VHDL and Verilog/SystemVerilog language constructs.
Code coverage collects data separately for Verilog tasks and functions and VHDL subprograms,
collectively referred to as “subprograms.” Data for subprograms is stored in the UCDB as
separate regions, and is reported separately when either the coverage report or vcover report
commands are used. All subprograms - Verilog tasks and functions as well as VHDL
subprograms - are displayed in the Structure window of the GUI. (See Code Coverage in the
Graphic Interface.)

Code coverage does not work on SystemC design units.

Statement and Branch coverage have no limitations on support, however, sometimes

optimizations can make it appear that statements or branches are uncovered. See “Notes on
Coverage and Optimization” for more details.

For condition and expression coverage datatype support, see “Condition and Expression
Coverage”.

For FSM coverage datatype support, see “Finite State Machine Coverage”.

ModelSim® SE User's Manual, v10.7 893

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Language and Datatype Support

For toggle coverage datatype support, see “Toggle Coverage”.

894 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Usage Flow for Code Coverage Collection

Usage Flow for Code Coverage Collection

To collect coverage data for a design, you must actively select the type of code coverage you
want to collect, and then enable the coverage collection mechanism for the simulation run.
You can view coverage results during the current simulation run or save the coverage data to a
UCDB for post-process viewing and analysis. The data can be saved either on demand, or at the
end of simulation (see “Saving Code Coverage Data On Demand” and “Saving Code Coverage
at End of Simulation”).

Code coverage is not collected on any code that is run at elaboration time (loading the design).
An example of such code might be a constant function that calculates the array range of a vector
signal.

Tip
Design units compiled with -nodebug are ignored by coverage: they are treated as if they
are excluded. However, toggle coverage of ports compiled with -nodebug is supported if
and only if -nodebug is used without any options. For example, options like
“-nodebug=ports” will disable toggle coverage.

The basic flow for collecting code coverage in a ModelSim simulation is as follows:

1. Compile the design and specify the types of coverage to collect:

vlog top.v proc.v
vopt top -o opttop +cover

The vlog (or vcom, if design is VHDL) command compiles the specified files. The vopt
command performs global analysis and optimizations on the design. The -o specifies the
output name for the optimized version of the design. The +cover argument to the vopt
command designates all coverage types for collection.
You may wish to apply coverage arguments differently, depending on whether you want
to collect coverage for a specific source file, or just a module/sub-module, or the entire
design. See “Specifying Coverage Types for Collection” for coverage application
options.
2. Enable coverage collection during simulation:
vsim -coverage opttop

Coverage is enabled for the entire design using the optimized design opttop. See
“Enabling Simulation for Code Coverage Collection” for further details.
Specifying Coverage Types for Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Rules for Applying Coverage with cover and nocover . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Enabling Simulation for Code Coverage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898

ModelSim® SE User's Manual, v10.7 895

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Usage Flow for Code Coverage Collection

Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899

Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901

896 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Specifying Coverage Types for Collection

Specifying Coverage Types for Collection

When specifying the coverage types for collection, you are essentially instructing the code to
collect coverage statistics when coverage collection is enabled at run time. Since extra
instructions reduce simulation performance, you should only enable code for which you intend
to collect coverage statistics.
Union of Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897

Union of Coverage Types

For all coverage type arguments specified with “+cover=”, the arguments applied are a union of
all arguments for a given module or design unit. For example, if module A was compiled with
the argument +cover=xf (extended toggle and FSM) and the entire design (containing modules
A, B and C) was optimized with +cover=bce, the coverage results would be:
Module A - bcefx
Module B - bce
Module C - bce

This union of arguments does not apply to the optimization number specified with -coveropt <1-
5> to vcom, vlog, or vopt (see “CoverOpt” for details on -coveropt levels). In this case, any
optimization level applied to a design unit or module takes precedence over the globally
specified -coveropt level.

Related Topics
Code Coverage in the UCDB

Rules for Applying Coverage with cover and

nocover
The vcom/vlog/vopt +cover command arguments and the vopt +nocover command arguments
allow you to specify coverage to the entire design or to specific design units and instances.
Refer to the Reference Manual for the proper syntax.
In cases where multiple, potentially competing +cover/+nocover arguments are applied,
coverage results are determined by reading the options from left to right on the command line,
while options specified to vopt override options specified to vlog or vcom.

Related Topics
vcom [ModelSim SE Command Reference Manual]
vlog [ModelSim SE Command Reference Manual]
vopt [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 897

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Enabling Simulation for Code Coverage Collection

Enabling Simulation for Code Coverage Collection

Once the coverage types have been specified for coverage, you must enable the simulation for
code collection.
Prerequisites
You must specify the coverage types you want to collect (see “Specifying Coverage Types for
Collection”).

Procedure
1. CLI command: Use the -coverageargument with the vsim command. For example,
vsim -coverage work.top

2. GUI: Simulate > Start Simulation > Others > Enable Code Coverage check box.
Figure 19-1. Enabling Code Coverage in the Start Simulation Dialog

898 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Saving Code Coverage in the UCDB

Saving Code Coverage in the UCDB

When you run a design with coverage enabled you can save the code coverage that was
collected for later use, either on demand or at the end of simulation.
By default, even if coverage is enabled, the tool will not save the data unless you explicitly
specify that the data should be saved, or specify -coverstore to the vsim command (see
Coverage Auto-save Coverstore for details).

Often, users simulate designs multiple times, with the intention of capturing different coverage
data from each test for post-process viewing and analysis. When this is the case, the naming of
the tests becomes important.

By default, for non-UVM/OVM tests, the name ModelSim assigns to a test is the same as the
UCDB file base name. For UVM/OVM tests, the default name assigned to a test is the UVM or
OVM testname. In either case, if you fail to name the test you run explicitly, you can
unintentionally overwrite your data.

To explicitly name a test before saving the UCDB, use a command such as:
coverage save -testname <mytestname>

or during a save using a command such as:

coverage attribute -testname <mytestname>

The name you enter (<mytestname>), can only be comprised of alphanumeric characters and
the underscore character (_).

Saving Code Coverage Data On Demand

Options for saving coverage data dynamically (during simulation) or in Coverage View mode
are:

• GUI: Tools > Coverage Save

This brings up the Coverage Save dialog box, where you can specify coverage types to
save, select the hierarchy, and output UCDB filename.
• CLI command: coverage save
During simulation, the coverage save command saves data from the current simulation
into a UCDB file called myfile1.ucdb:
coverage save myfile1.ucdb

While viewing results in Coverage View mode, you can make changes to the data (using
the coverage attribute command, for example). You can then save the changed data to a
new file using the following command:
coverage save myfile2.ucdb

ModelSim® SE User's Manual, v10.7 899

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Saving Coverage Using the UVM Test Name

To save coverage results only for a specific design unit or instance in the design, use a
command such as:
coverage save -instance <path> ... <dbname>

The resulting UCDB, <dbname>.ucdb, contains only coverage results for that instance,
and by default, all of its children.
• SystemVerilog System Tasks and Functions (captures code coverage only):
$coverage_save (not recommended)
$coverage_save_mti (not recommended)

The non-standard SystemVerilog $coverage_save_mti system function saves code

coverage data only. It is not recommended for that reason. The $coverage_save system
function is defined in the IEEE Std 1800; current non-compliant behavior is deprecated
and therefore also not recommended. For more information, see “Simulator-Specific
System Tasks and Functions.”

Saving Code Coverage at End of Simulation

By default, coverage data is not automatically saved at the end of simulation. To enable the
auto-save of coverage data, set a legal filename for the data using any of the following methods:

• Set the modelsim.ini file variable: UCDBFilename=“<filename>”

By default, <filename> is an empty string ("").
• Specify at the Vsim> prompt: coverage save -onexit command
The coverage save command preserves instance-specific information. For example:
coverage save -onexit myoutput.ucdb

• Execute the SystemVerilog command:

$set_coverage_db_name(<filename>)

If more than one method is used for a given simulation, the last command encountered takes
precedence. For example, if you issue the command coverage save -onexit vsim.ucdb, but your
SystemVerilog code also contains a $set_coverage_db_name() task, with no name specified,
coverage data is not saved for the simulation.

Saving Coverage Using the UVM Test Name

By default, coverage data is saved to the default test name, which is derived from the basename
of the output filename specified in the coverage save command. You can create the coverage
database with a UVM/OVM testname using this method.

900 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Coverage Auto-save Coverstore

Procedure
1. Pass the UVM test name to the vsim command using +UVM_TESTNAME=<myuvm>,
where <myuvm> is the name of UVM test to be run.
Example:
% vsim +UVM_TESTNAME=c_test

2. Specify -uvmtestname with the coverage save command.

Example:
% coverage save -uvmtestname <other_args> b_test.ucdb

where b_test.ucdb is the output coverage UCDB.

3. The resulting coverage database is named b_test.ucdb and the TESTNAME field stored
within in will be called c_test.

Coverage Auto-save Coverstore

An option exists to provide improved merge performance while automatically saving coverage
data without specifying the coverage save command. This is accomplished through the use of a
form of coverage storage called a 'Coverstore'. A Coverstore is essentially a storage location
(directory) which holds both design and coverage results, and is accessed in a similar way to a
UCDB file.
The coverstore auto-save functionality provides an improved merge performance. This is due to
the fact that in the normal simulation flow (with a coverage save command) every leaf level
UCDB file holds the test record data, the design objects, and the results. However, when vsim is
run with -coverstore, the coverstore directory holds results from multiple tests that share the
same design objects and hierarchy.
Simulation can be set-up to write coverage data into the coverstore instead of using the coverage
save command to save a single UCDB once the simulation has finished. It is then possible to use
this coverstore as input to the merge process to produce a regular merge UCDB or an output
coverstore that contains a merged result. Command line commands such as vcover report/
attribute/stat/ranktest and vsim -viewcov can be used with coverstores and/or the name of a
coverstore plus a test index (i.e coverstore:test).

Use Flow for Automatically Saving Coverage Data

1. Invoke simulation (vsim) with -coverstore and -testname options, which automatically
saves the coverage data at the end of simulation:
vsim -coverstore <directory_path> -testname <name>

All directory paths in the -coverstore argument should be the same for all the simulation
runs in a regression, as should the design hierarchy.

ModelSim® SE User's Manual, v10.7 901

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Coverage Auto-save Coverstore

2. Merge all the coverage data accumulated in the coverstore using the path to the directory
as an input to the merge:
vcover merge -out <output_ucdb> <coverstore_directory_path>

The generated output file is a self-contained merged UCDB file.

3. Instead of generating a self-contained merged UCDB file, you can dump the raw merged
output in a designated coverstore area by specifying the output coverstore path using
-outputstore option:
vcover merge -outputstore <output_directory> <coverstore_directory_path>

The purpose of saving raw coverage merge output data from vcover merge is to take
advantage of fast merging in a hierarchical merge flow where an input to the current
merge operation is the output of a previous merge.
Such hierarchical flows are typically used to parallelize merging of coverage data
generated from a large number of tests in a regression. The parallel merge applications
take advantage of this mechanism when merging coverstores. The output coverstore
contains the same design shape as the input coverstore, with the individual tests replaced
by a merged data record index. For example:
vcover merge -outputstore merged1_out coverstore1
vcover merge -outputstore merged2_out coverstore2
...
vcover merge -out merged_final.ucdb merged1_out merged2_out ... mergedN_out

The last vcover merge command merges the coverage and design data that was output
from lower level merges. The performance gain is realized from the merging of that
data, rather than the self-contained UCDB files.
4. Optionally, you can choose to merge a user selected subset of tests in a coverstore into a
self-contained merged UCDB. Do this by specifying a comma separated list of test
names after the coverstore name, using the ':' as a separator. The command would be
similar to:
vcover merge -out <output_ucdb>
<coverstore_directory_path>[:<testname>[,<testname>]*]

The following are example commands valid for merging user selected tests from coverstore
area:

vcover merge -out out.ucdb mystore:test1,test3,test5

vcover merge -out out.ucdb mystore:test*
vcover merge -out out.ucdb mystore1:test1 mystore2:test2 mystore3:test*
Best Practices for Auto-save
You are best off using only self-contained UCDB files once a regression is complete, and the
resulting UCDB file has to be saved for future usage (trending, metrics generation, and so on).

902 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Coverage Auto-save Coverstore

Self-contained UCDB files can handle source-drift (for example, mismatching du signatures)
with some degree of grace. For example, union merge, or explicit master merge can handle
UCDBs generated off different versions of source code. The coverstore representation of a
UCDB does not handle these options, so the coverstore flow is best suited for usage in an
individual regression run, based on the same source code. Source-drift tends to happen over
time, as design and test changes accumulate, and different regressions are run based on different
versions of the TB and DUT.

Note that using a coverstore approach, the merge performs a perfect merge for static coverage
items (code coverage). A design level signature is used to verify whether the static coverage bin
counts present in a coverstore are in sync or not. If so, then there is no mismatch at all between
coverage items, and the merge is considered “perfect”. If there is a mismatch between any
coverage items, the merge will not proceed, which lets you know that the coverstore flow
cannot be used.

For functional coverage items, a union merge algorithm is used, as the functional coverage
content may vary within a regression run. A coverstore is able to cope with these variations
within functional coverage shapes or models, but code coverage shapes or models must match
exactly.

Single-bit vs. Multi-bit Counts

The -multicount option is available with the vsim command line. By default — in the
Coverstore auto-save mode only — coverage operates in a single-bit count mode for code
coverage types (statement, branch, condition, expression, fsm, toggle), and multi-bit count
mode for functional coverage types (covergroups, cover directives, assertions). This means bin
counts are stored in the Coverstore using 1-bit counters for code coverage types. In this default
mode, all non-zero bin counts are stored as 1. The calculated coverage percentages are not
affected by this reduction in counter bandwidth. The simulator still stores counts in multi-bit
counters. It is the Coverstore which takes these multi-bit counts and converts them into single-
bit counts.

However, you may be relying on the integer counts for other sorts of analysis. Particularly,
covergroup, toggle, and FSM transitions may require more than single-bit counts. In order to
enable full counting, the -multicount option can be used.

Example:

vsim -multicount=f-gt -coverstore store1 -testname test1 design1

In this example, single bit counting is in effect for all coverage kinds except assertions, cover
directives, fsms and toggles. See the vsim command -multicount argument for syntax details.

Related Topics
vsim -coverstore and -viewcov arguments [ModelSim SE Command Reference Manual]
vcover merge and other vcover commands [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 903

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage in the UCDB

Code Coverage in the UCDB

ModelSim stores saved coverage statistics in a Unified Coverage DataBase (UCDB) file, a
single persistent database that is the repository for all coverage data — both code coverage and
functional coverage.
Once the UCDB coverage data is saved, you can:

• Analyze coverage statistics in the GUI, either interactively with an active simulator, or
in a post-processing mode with vsim -viewcov (see “Usage Flow for Code Coverage
Collection”)
• Run and view reports on the collected code coverage data (see “Coverage Reports”)
• Exclude certain data from the coverage statistics (see “Methods for Excluding Objects”)
• View, merge, and rank sets of code coverage data without elaboration of the design or a
simulation license.
You can also merge test data with a verification plan.
Related Topics
Code Coverage Types
Coverage Exclusions
Coverage Reports
Coverage and Verification Management in the UCDB
Calculation of Total Coverage
Verification Management Users Manual

904 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Code Coverage in the Graphic Interface

Code Coverage in the Graphic Interface

When you simulate a design with code coverage enabled, coverage data is primarily displayed
in the Code Coverage Analysis, Instance Coverage, and Coverage Details windows.
In the Coverage Analysis window you can elect to display Statement, Branch, Expression,
Condition, FSM, or Toggle coverage by clicking the Analysis Type selector (Figure 19-2).

Figure 19-2. Selecting Code Coverage Analysis Type

The coverage data in the Code Coverage Analysis window is displayed “by instance” or “by
file” depending on whether the “sim” tab (Structure window) or “Files” tab is active.

Additional Code Coverage Data is displayed in the Object, Source, and Structure windows. To
view coverage data in the Objects window, right click anywhere in the column title bar and
select Show All Columns from the popup menu. When you double-click and item in the Code
Coverage Analysis window or the Objects window, it will open a Source window with the
selected item highlighted. For details, see Table 19-1.

All subprograms - Verilog tasks and functions as well as VHDL subprograms - are displayed in
the Structure window. Since VHDL allows multiple subprograms of the same name but
different arguments, in the same hierarchical scope, the argument signature (list of arguments
and their types) is displayed along with the subprogram name in order to differentiate
overloaded subprogram names. The signature appears in the “design unit” column instead of the
design unit name.

The Instance Coverage window also displays subprograms, as well as instances, and their
respective code coverage data.

You can also write coverage statistics in different text and HTML reports (see “Coverage
Reports”). You can save raw coverage data to a UCDB (see “Code Coverage in the UCDB”)
and recall, or merge it with coverage data from previous simulations.

ModelSim® SE User's Manual, v10.7 905

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage in the Graphic Interface

The table below summarizes the coverage windows.

Table 19-1. Code Coverage in Windows
Coverage window Description
Code Coverage Use this window to perform in-depth analysis of incomplete coverage
Analysis numbers.
Pulldown menu options for viewing missed coverage and details:
Statement Analysis, Branch Analysis, Condition Analysis, Expression
Analysis, Toggle Analysis, FSM Analysis.
Displays exclusions with or without comments, missed coverage
(anything with less than 100% coverage) for the selected design object
or file, as well as details for each object. When the Details window is
open, you can click each line to display details of object.
Refer to “Code Coverage Analysis Window” in the GUI Reference
Manual.
Details Displays details of missed statement, branch, condition, expression,
toggle, and FSM coverage, as well as exclusions and comments.
When you select items in Code Coverage Analysis windows, the
details populate in this window. Used to perform in-depth analysis of
incomplete coverage numbers. Refer to “Coverage Details Window”
in the GUI Reference Manual.
Instance Coverage Use this window as the primary navigation tool when exploring code
coverage numbers.
Displays coverage statistics for each instance. It recursively shows all
child instances under the currently selected region in the Structure
window. Use this window for analysis based on sorting by coverage
numbers. Refer to “Instance Coverage Window” in the GUI Reference
Manual.
Objects Can be used to view and analyze Toggle Coverage.
Displays toggle coverage statistics when you right-click any column
heading and select Show All Columns. Various columns show the
toggle numbers collected for each variable and signal shown in the
window. Refer to “Viewing Toggle Coverage Data in the Objects
Window”.
Source Most useful for statement and branch coverage analysis.
Displays source code for covered items. Refer to “Coverage Data in
the Source Window” in the GUI Reference Manual.

906 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Displaying Coverage Summary in the Structure Window

Table 19-1. Code Coverage in Windows (cont.)

Coverage window Description
Structure Use this window mainly as a design navigation aid.
(sim) Displays coverage data and graphs for each design object or file,
including coverage from child instances compiled with coverage
arguments. By default, the information is displayed recursively. You
can select to view coverage by local scopes only by deselecting Code
Coverage > Enable Recursive Coverage Sums. Columns are
available for all types of code coverage. See “Code Coverage in the
Structure Window” in the GUI Reference Manual and “Coverage
Aggregation in the Structure Window” in this manual.
Displaying Coverage Summary in the Structure Window. . . . . . . . . . . . . . . . . . . . . . . . 907
Understanding Unexpected Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908

Displaying Coverage Summary in the Structure

Window
You can display a summary of each coverage category in the Structure window. The summary
appears at the top of each coverage column.
Prerequisites
Enable code coverage data collection as described in Usage Flow for Code Coverage
Collection.

Procedure
1. Select the Structure window to make it active.
2. To enable the coverage summary, select:
Structure > Code Coverage > View Code Coverage Summary
Results
A Coverage Summary item appears at the top of the Structure (sim) window, as shown here:
Figure 19-3. Coverage Summary Item

Each coverage column contains a summary of that coverage category at the top of the column.

ModelSim® SE User's Manual, v10.7 907

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Understanding Unexpected Coverage Results

Figure 19-4. Summary Begins Each Coverage Column

Understanding Unexpected Coverage Results

When you encounter unexpected coverage results, it may be helpful to keep in mind the
following special circumstances related to collecting coverage statistics:
• Optimizations affect coverage results. See “Notes on Coverage and Optimization”.
• Poorly planned or executed merges can produce unexpected results. One example: if
you improperly apply the -strip and -install options of coverage edit).
• Package bodies, whether VHDL or SystemVerilog, are not instance-specific: ModelSim
sums the counts for all invocations no matter who the caller is.
• All standard and accelerated VHDL packages are ignored for coverage statistics
calculation.
• You may find that design units or instances excluded from code coverage will appear in
toggle coverage statistics reports. This happens when ports of the design unit or instance
are connected to nets that have toggle coverage turned on elsewhere in the design.
• Verilog cells (modules surrounded by `celldefine / `endcelldefine, and modules found
using vlog -y and -v search) do NOT have code coverage enabled by default. In addition,
coverage for cells that have been optimized will not appear in reports.
Related Topics
vlog [ModelSim SE Command Reference Manual]

908 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Code Coverage Types

Code Coverage Types

Code coverage types include statement, branch, condition, expression, toggle, FSM, and
SystemVerilog Class coverage.
Statement Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Branch Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941

Statement Coverage
Statement coverage is the most basic form of coverage supported by ModelSim. The metric for
statement coverage is the count of how many times a given statement is executed during
simulation.
Multiple statements may be present on a single line of HDL source code. Each such statement is
processed independently of other statements on the same line. Statement coverage counts are
prominently displayed in the Source window. They are present in most of the other coverage
windows as well.

Statement coverage statistics for“for” loops are presented using two separate entries relating to
one line of code: the first entry is the number of times the “for” statement was entered, while the
second is the number of times the loop was repeated. Consider the following statement
displayed in a coverage report:

31 1 ***0*** for i in SETS-1 downto 0 loop

31 2 ***0***

The statement on line 31 displays counts in two entries: the count “1” refers to how many times
the loop was entered, the count “2” refers to how many times the loop was repeated.

ModelSim® SE User's Manual, v10.7 909

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Branch Coverage

Branch Coverage
Branch coverage is related to branching constructs such as “if” and “case” statements. True
branch and “AllFalse” branch execution are measured.
In order to achieve 100% branch coverage, each branching statement in the source code must
have taken its true path, and every AllFalse branch must have been taken.

Branch Coverage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910

Case and Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
AllFalse Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Missing Branches in VHDL and Clock Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . 914

Branch Coverage Examples

You can analyze Verilog and SystemVerilog 'if … else if … [else]' chains with a code coverage
model.
The code block in Example 19-1 contains an if ... else if ...[else] chain.

Example 19-1. Code Block with if...else if...[else] Chain

module top;
integer i=10;
initial begin
#3 i = 18;
#3 i = 2;
#1 $finish();
end
always @ (i) begin
if (i == 16)
$display("sweet");
else if (i == 2)
$display("terrible");
else if (i == 10)
$display("double digits at last");
else if (i == 18)
$display("can vote");
else
$display("just another birthday"); end endmodule

910 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Branch Coverage

If you run this code to completion while collecting branch coverage statistics, then save the
results to a UCDB file named top.ucdb, the “vcover report top.ucdb -details” command
generates the following report:

Example 19-2. Coverage Report

Coverage Report by file with details

File: top.v
Branch Coverage:
Enabled Coverage Active Hits Misses % Covered
---------------- ------ ---- ------ ---------
Branches 5 3 2 60.0

==============================Branch Details=============================

Branch Coverage for file top.v --

------------------------------------IF Branch----------------------------
12 3 Count coming in to IF
12 1 ***0*** if (i == 16)
14 1 1 else if (i == 2)
16 1 1 else if (i == 10)
18 1 1 else if (i == 18)
20 1 ***0*** else
Branch totals: 3 hits of 5 branches = 60.0%

The 60% coverage number (in the % Covered column) is derived as follows: Five bins under the
initial 'if' of the code block in Example 19-1are inferred —1 ‘if’ branch, 3 'else if' branches, and
1 'else' branch — and three of these branches executed.

If the final 'else' were not present in the code block, the coverage score would remain the same;
but instead of listing an 'else' count, the report would list an 'All False Count' value of 0.

The second column in the Branch Details section of the report shows the number of items of that
coverage type on the line. There is only one coverage item of that type on each line of the
example report above, so the number is 1 in each line.

Merging If-Else-If Branch in Verilog

When you run the code in Example 19-1, the if-else pairs are merged into a single VHDL-like
if-elsif ladder to obtain the combined branch Coverage Report shown in Example 19-2. But
what happens with nested if-else branches?

ModelSim® SE User's Manual, v10.7 911

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Branch Coverage

The following code block shows an example of nested if-else branches:

if(clk)
----
else
if(set)
----
else
if(reset)
----

The simulation tool merges the nested if-else branches and reports them under a single VHDL-
like if-elsif-else structure in the following way:

-------------------------------IF Branch---------------------------------
14 ***0*** Count coming in to IF
14 1 ***0*** if(clk)
17 1 ***0*** if(set)
21 1 ***0*** if(reset)
***0*** All False Count

The tool does not merge an ‘if’ into an ‘elsif’ structure if you have segregated the ‘if’ from the
parent ‘else’ with a begin-end pair, as shown in the following code:

if (clk)
----
else
if(set)
----
else
begin
if(reset)
end

Since you have segregated ‘if(reset)’ from the parent ‘else’ via a begin-end pair, the simulation
tool does not merge ‘if(reset)’ with the parent if-elsif-else ladder. When you run the vcover
report command it generates the following two IF Branches:

-----------------------------IF Branch-----------------------------------
14 1 ***0*** Count coming in to 2"
14 1 ***0*** if(clk)
17 1 ***0*** if(set)
19 1 ***0*** else
Branch totals: 0 hits of 3 branches = 0.0%

-----------------------------IF Branch-----------------------------------
21 ***0*** Count coming in to IF
21 1 ***0*** if(reset)
***0*** All False Count

912 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Branch Coverage

To force the tool to merge such segregated IF branches, use the -covercebi argument with the
vlog and vopt commands. If you use the -covercebi argument for the code example above, the
vcover report command generates the following report:

-----------------------------IF Branch-----------------------------------
14 ***0*** Count coming in to IF
14 1 ***0*** if(clk)
17 1 ***0*** if(set)
21 1 ***0*** if(reset)
***0*** All False Count Count

Related Topics
Branch Coverage
Missing Branches in VHDL and Clock Optimizations
Case and Branches
AllFalse Branches

Case and Branches

For “case” statements, the case expression itself is not considered a branch. Rather, each case
item is considered a separate and independent branch. To achieve 100% branch coverage in a
“case” statement, each case item must have been executed during simulation.
In order to gain more coverage detail on the HDL expressions used in branching statements, the
Condition and Expression Coverage features may be used

Related Topics
Branch Coverage
Condition and Expression Coverage
Missing Branches in VHDL and Clock Optimizations
Branch Coverage Examples
AllFalse Branches

AllFalse Branches
For “if” statements without a corresponding “else”, an implicit branch known as the “AllFalse”
branch is measured. If the “if” condition is executed and found to be false, the “all false” branch
is considered to be hit.
By default, Allfalse branches are designated in the coverage report with “ECOP” if the branch
was not hit, “E-hit” if hit, indicating that it was excluded because of the “clock optimization”.
This optimization can be turned off using the -noclkoptbuiltins argument to the vsim command.

ModelSim® SE User's Manual, v10.7 913

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Branch Coverage

In the following VHDL example,

if (fsel = “10”) then

z <= a;
elsif (fsel = “11”) then
z <= b;
end if;

the AllFalse branch is hit when “fsel” is not equal to “10” or “11”. In the following Verilog
example:

if (fsel == INDF_ADDRESS) begin

fileaddr <= fsr[6:0];
FECend

the AllFalse branch is hit when “fsel” is not equal to INDF_ADDRESS.

You can exclude an AllFalse branch from participation in branch coverage using the -allfalse
argument to a pragma exclusion or by using the coverage exclude command.

Code coverage includes an all false bin for Verilog case statements that do not contain a
“default” clause. Coverage reports and the GUI will show the case all false data similar to the
way if statement all false data is shown. Case statement all false branches can be excluded also
in a similar manner. Also, if the CoverExcludeDefault variable in the modelsim.ini file is used
to exclude case statement default clauses, it will also exclude case statement all false branches.

Related Topics
coverage exclude [ModelSim SE Command Reference Manual]
Exclude Implicit (AllFalse) Branches
coverage on and coverage off Pragma Syntax
Exclude AllFalse Branches in Case Statements

Missing Branches in VHDL and Clock Optimizations

In cases where you have a VHDL process serving as an edge-triggered flip-flop, the default
ModelSim optimizations convert this process to an optimized process that is only activated on
the rising edge of the clock. Because this process is NEVER activated on the falling edge of the
clock, that branch is not executed and, thus, not counted for code coverage.
Due to this fact, the code coverage algorithm excludes the branch for code coverage. The
exclusion is reported in the Source window, with a special indicator showing that the branch is
excluded for clock optimization. In the coverage report, the exclusion is noted with the code
“ECOP”.

914 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Branch Coverage

You can turn off clock optimization in the VHDL code by compiling the design with the
CoverClkOptBuiltins modelsim.ini variable set to 0, or with the vcom/vlog -nocoverclkbuiltins
argument.

Related Topics
coverage exclude [ModelSim SE Command Reference Manual]
Exclude Implicit (AllFalse) Branches
coverage on and coverage off Pragma Syntax
Exclude AllFalse Branches in Case Statements

ModelSim® SE User's Manual, v10.7 915

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

Condition and Expression Coverage

Condition coverage analyzes the decision made in “if” and ternary statements and can be
considered an extension to branch coverage.
Expression coverage is similar to condition coverage: it analyzes the activity of expressions on
the right-hand side of assignment statements, and counts when these expressions are executed.
For expressions involving logical operators, a truth table is constructed and counts are tabulated
for conditions matching rows in the truth table.

The topics related to condition and expression coverage are numerous and detailed. See each of
the following sections for complete information on these coverage types.

Cond and Exp Coverage Collection Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916

Reporting Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
FEC Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
FEC Report Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
FEC and Short-circuiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Exclusions and FEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Legacy FEC Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
VHDL Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Verilog/SV Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 926

Cond and Exp Coverage Collection Metrics

By default, ModelSim enables only the collection of FEC-style metrics. However, you can
enable calculation and presentation of several condition and expression coverage metrics to suit
your purposes.
• Focused Expression Coverage (FEC) — A row-based coverage metric that
emphasizes the contribution of each expression input to the expression’s output value. In
effect, this type of coverage metric can help determine if there is a functional error in the
logic that is feeding the targeted input (FEC Target). This is a powerful metric that helps
minimize the risk that an expression is masking potential bugs in the logic feeding each
of its inputs.
See “FEC Report Examples” for further details on report output and analysis.

Tip
Expressions whose result is greater than one bit wide are not counted for coverage;
they are silently ignored. In other words, multi-bit signals are not supported for
expression coverage.

916 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

Related Topics
Condition and Expression Coverage
FEC and Short-circuiting
FEC Concepts
Reporting Condition and Expression Coverage

Reporting Condition and Expression Coverage

The guidelines and usage associated with condition and expression coverage reporting are based
on the individual metrics being applied.
FEC :

• By default, when coverage is enabled with the “+cover=ec” argument (where “=ec”
enables expression and condition coverage) to vcom/vlog/vopt only FEC coverage
statistics are collected and reported.
o You can turn on/off FEC collection using the -coverfec and -nocoverfec argument
to vcom/vlog/vopt.
• You can print condition and expression coverage truth tables in coverage reports as
follows:
o GUI: Select Coverage Reports > Condition Coverage or Expression Coverage
(refer to “Coverage Reports”)
o Command Line: with coverage report -details. Works when one or more of the rows
has a zero hit count. To force the table to be printed even when an expression is
100% covered, apply the -all switch to the coverage report command.
o Detailed analysis metrics are reported using a command such as:
coverage report -details

or
vcover report -details

• The expression appearing in the FEC report is a canonical representation of the lexical
expression that appears in the original source code. Effects of the optimizer are taken
into account, which means the canonical expression will match perfectly with the
subexpressions and terms used in the rest of the report.
• The default level of effort for FEC expressions/conditions determines the number of
expressions or conditions which are considered for coverage. You can customize the
effort level for FEC using the -feceffort argument to vlog/vcom/vopt, or the FecEffort
modelsim.ini file variable.

ModelSim® SE User's Manual, v10.7 917

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

Identifying Non-Testable Terms of Expressions

The Expression Coverage report identifies the non-testable terms of expressions by showing
“Not Testable” in their non-masking conditions and by marking such terms excluded. If any of
the implicant or alternate of a ternary expression is ‘X’ (or ‘Z’), the input terms used in the
condition of ternary expression are treated ‘not testable’. Also, when any input term in a logical
or bitwise expression is fixed to its masking state, the terms in the expression become ‘not
testable’. Since these terms do not contribute to the coverage of the expression, they are now
marked excluded from the report. This ensures correct calculation of coverage percentage and
also makes the report more intuitive.

Related Topics
Condition and Expression Coverage
FEC and Short-circuiting
FEC Report Examples
FEC Concepts

FEC Concepts
Focused expression coverage (FEC) measures coverage for each input of an expression. If all
inputs are fully covered, the expression has reached 100% coverage. In FEC, an input is
considered covered only when other inputs are in a state that allow the covered input to control
the output of the expression. Further, the output must be seen in both 0 and 1 states while the
target input is controlling it. If these conditions occur, the input is said to be fully covered. The
final FEC coverage number is the number of fully covered inputs divided by the total number of
inputs. FEC calculation is fully compliant with the more widely known MC/DC coverage
metric (Multiple Condition/Multiple Decision).
Every expression, regardless of how complex it may be, can eventually be broken down into N
smaller expressions consisting of only one operator each, where N is the number of operators in
the expression. This type of expression is referred to as a 'basic expression'.

Consider the following expression:

a && b && c && d

The && operator groups operands from left-to-right, therefore this expression can be
represented as:

a && (b && (c && d))

918 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

It can be broken down into 3 basic expressions, defined as:

a && EXPR1
b && EXPR2
c && EXPR3
where EXPR1 = ‘b && (c && d)’, EXPR2 = ‘c && d’, and EXPR3 = ‘d’

Once the basic expression has been identified, the evaluation operates only on the basic
expression, which means the actual complex expression is disregarded. When working on any
input in an expression, it is important to prevent it from masking the other input because of its
value. For example, to measure coverage of 'a' in 'a && b', it is important that the value of 'b' is
1. If 'b' is 0, the result of the expression gets fixed to 0 and the value of 'a' is no longer of any
significance (that is, 'b' masks 'a').

Also, because the expression is evaluated left-to-right in the presence of short-circuiting (see
FEC and Short-circuiting), it is meaningful to look only at the right side of the concerned input.
The assumption is that when evaluating the concerned input, the left side is already in a non-
masking state. For example, evaluating 'b' in 'a && b && c' means that 'a' was already evaluated
to '1'.

Note that non-masking conditions of a ternary expression show the state of the selected
expression to make reports more useful.

Table 19-2 lists operators with non-masking states of inputs. In this table, the coverage of 'A' is
being collected in the expression.
Table 19-2. Operators with Their Non-Masking States
Operator Expression Non Masking State
NOT NOT A N/A
OR A OR B B=0
B OR A B=0
NOR A NOR B B=0
B NOR A B=0
AND A AND B B=1
B AND A B=1
NAND A NAND B B=1
B NAND A B=1
XOR A XOR B B = 0, B = 1
B XOR A B = 0, B = 1
XNOR A XNOR B B = 0, B = 1
B XNOR A B = 0, B = 1

ModelSim® SE User's Manual, v10.7 919

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

Table 19-2. Operators with Their Non-Masking States (cont.)

TERNARY (COND)? A:B COND = 1, B is non-masking
(COND)? B:A COND = 0, B is non-masking
At the time of coverage collection, you need to make sure that the input being covered has taken
both '0' and '1' states when the other input of the expression is in a non-masking state. Note that
you are only looking at the value of the other input in the basic expression, and not inputs of the
expression. An input will be fully covered if it has taken both '0' and '1' value during simulation,
in a state where the other input in its basic expression has a non-masking value. In case of XOR,
the value of the other input must be the same when the two collections are done to ensure that
both these collections are done when the input is active in the same mode (inverting or non-
inverting). An expression would be considered fully covered when all the inputs of the
expression have been independently covered.

FEC Report Examples

You can examine examples of the default report tables that are generated for focused expression
coverage (FEC). Examples show both unimodal and bimodal expressions.
A unimodal expression is one that has all input terminals in only one mode (either inverting or
non-inverting), whereas a bimodal expression has at least one of its input terminals in both
inverting and non-inverting mode.

These modes of inversion are defined as follows:

• Inverting mode — When setting the value of an input terminal to '0' (or '1') with all other
terminals in their quiescent states in an FEC row, evaluates the expression to '1' (or '0'),
the input terminal is said to be operating in an inverting mode.
• Non-Inverting mode — When setting the value of an input terminal to '1' (or '0') with all
other terminals in their quiescent states in an FEC row, evaluates the expression to '1' (or
'0'), the input terminal is said to be operating in a non-inverting mode.
Example 19-3. FEC Coverage with a Unimodal Expression

Note
Instead of the lexical expression that appears in the original source code, the FEC reports
show the canonical representation.

920 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

Examine the following FEC report table for the expression (a & b & c), when it receives input
vectors {101, 011, 111}:

# ----------------Focused Expression View-----------------

# Line 82 Item 1 ((a & b) & c)
# Expression totals: 2 of 3 input terms covered = 66.6%
#
# Input Term Covered Reason for no coverage Hint
# ----------- -------- ----------------------- --------------
# a Y
# b Y
# c N '_0' not hit Hit '_0'
#
# Rows: Hits FEC Target Non-masking condition(s)
# --------- --------- -------------------- -------------------------
# Row 1: 1 a_0 (c && b)
# Row 2: 1 a_1 (c && b)
# Row 3: 1 b_0 (c && a)
# Row 4: 1 b_1 (c && a)
# Row 5: ***0*** c_0 (a & b)
# Row 6: 1 c_1 (a & b)

Each FEC report consists of two tables;

• The first table reports coverage on a per-input basis. For inputs that are not covered, the
report gives a brief reason for the lack of coverage. The “Hint” column provides
information on how to get the input covered. In the FEC report above, input 'c' was not
covered because the coverage bin '_0' associated with this input (that is, c_0) did not
receive any hits. The hint says that to get 'c' FEC covered, an input vector satisfying non-
masking condition for c_0 (that is, (a & b), while c == 0) must be applied to this
expression during simulation.
• The second table goes a step deeper and expands each input into its coverage bins. The
table lists the Rows, Hits, FEC Target and
• Non-masking condition(s).
In the FEC report above, consider the first row containing the FEC Target (or bin) of a_0, where
a is the input and _0 is the value of that input. The full tag of a_0 indicates that this row delivers
FEC testing when a's value is 0. This bin was incremented since an input vector (011) satisfying
its Non-masking condition (c && b) was seen. By definition a is 0 for every Non-masking
condition on the a_0 list. Similarly, the input vector (111) satisfying the Non-masking condition
for a_1 - row 2 in the table - was also observed. Again, by definition, the a_1 Non-masking
conditions are identical to the a_0 except with the 'a' bit equal to 1. This is always the case for
each pair of FEC rows (non-short circuit logic only).

In walking through the truth table, you can see how FEC ensures that each input a, b, and c has
been shown to independently affect the expression output. For example, for the conditions of
FEC to be satisfied, when an a_0 input vector flips to the corresponding a_1 vector—that is,
only bit 'a' changes to 1, with the other bits unchanged—the output value of the expression
MUST also change.

ModelSim® SE User's Manual, v10.7 921

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

If FEC coverage indicates any bins are missed (such as c_0 in Row 3 of Example 19-3) you
know that none of your tests ever produced a value of ‘1’ when other inputs are in a state that
allows it to control the output. You should then work on the design/stimulus to improve FEC
coverage. One method of raising FEC coverage numbers is to modify test stimulus such that
input vectors satisfying Non-masking conditions of zero-hit rows appear at the expression's
inputs.

Example 19-4. FEC Coverage with a Bimodal Expression

Examine the FEC report table for the expression ((~a & c) | (a & b & ~c & d) | (a & ~b & c & d))
when it receives input vectors {0100, 1001, 1111}.

As in the simple, unimodal case shown in Example 19-3, the first table reports coverage on a
per-input basis. In the FEC report above, input ‘b’ was not covered because both rows
corresponding to this input were hit for the same output value (that is, ‘b’ changed but the
output did not change).

The second table expands each input into its coverage bins. In the FEC report above, consider
the first row containing the FEC Target (or bin) of a_0, where ‘a’ is the input and ‘_0’ is the
value of this input. The hits have been divided based on the output of the expression when
applying the input pattern satisfying its Non-masking condition. This is done to ensure that
while qualifying an input terminal as FEC covered, it has been shown to independently control
the output while operating in one mode; that is, making sure that it receives '_0' and '_1' hits for
different output values.

The bin corresponding to 'a_0' was incremented for output value 1, as an input vector satisfying
the non-masking conditions was seen. Similarly, an input vector satisfying non-masking

922 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

condition for a_1 - row 2 in the table - was observed for output 0. Since input 'a' receives hits in
both the '_0' and '_1' rows for different output values, 'a' is considered 100% FEC covered.

Even though input 'b' receives hits in both '_0' and '_1' rows, it is not considered FEC covered.
This is because both the rows are hit for the same output value (that is, 0). In cases where an
input is not FEC covered, use the reason and hint to improve the test stimulus, or potentially
modify the design if a design issue is found.

Tip
After spending some time with FEC tables for bimodal expressions, you can see that inputs
that are FEC-covered have at least one non-zero value in both the "->0" and "->1" columns.
Any input with two '0's in a given column will be uncovered. It can be efficient to scan down the
->0 and ->1 columns looking for strings of '0's, then concentrate on those inputs and their
matching input patterns.

Related Topics
Condition and Expression Coverage
FEC and Short-circuiting
Reporting Condition and Expression Coverage
FEC Concepts

FEC and Short-circuiting

For some expressions, it is not required to evaluate all the inputs within the expression once the
output has been determined. When evaluation of some inputs is skipped, it is known as short-
circuiting.
FEC is supported in the presence of short-circuiting. Short circuit expressions can be treated in
the same manner as the conventional expressions described above, except for the fact that
quiescent states can now include don't cares as well. This may lead to asymmetry of input

ModelSim® SE User's Manual, v10.7 923

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

patterns for '_0' and '_1' rows. The following example shows a FEC report table for the
expression (a && b && c) when it receives input vectors {001, 100, 111}:

# ----------------Focused Expression View---------

# Line 82 Item 1 ((a && b) && c)
# Expression totals: 2 of 3 input terms covered = 66.6%
#
# Input Term Covered Reason for no coverage Hint
# ----------- -------- ----------------------- --------------
# a Y
# b Y
# c N '_0' not hit Hit '_0'
#
# Rows: Hits FEC Target Non-masking condition(s)
# --------- --------- -------------------- -------------------------
# Row 1: 1 a_0 -
# Row 2: 1 a_1 (c && b)
# Row 3: 1 b_0 a
# Row 4: 1 b_1 (c && a)
# Row 5: ***0*** c_0 (a && b)
# Row 6: 1 c_1 (a && b)

Note the non-masking condition for row 1 in the above example. Once input 'a' has been
evaluated to '0', the evaluation of the other inputs is not required. Note the asymmetry in non-
masking conditions for rows 'a_0' and 'a_1'. They no longer similar.

There is a further difference from non-short circuit coverage: Covering each expression input
may require a different level of effort. To be FEC covered, input 'c' requires considerably more
precise stimulus vectors than input 'a'.

Effect of Short-circuiting on Expression and Condition Coverage

By default, the simulator follows LRM rules for short-circuit evaluation for Verilog and VHDL
expressions. In brief, for Verilog, the &&, ||, and ternary operators short-circuit. And for VHDL,
expressions are short-circuited when their operands are of boolean or bit types, and the
expression is purely composed of logical operators.

For example, in the following expression, if A has a value of '0', the term B || C will never be
evaluated:

Z <= A && (B || C);

Short-circuit evaluation remains in effect per LRM rules when coverage is enabled.

You may want to analyze the coverage results when short-circuit evaluation is turned off, and
all terms in an expression are considered in an evaluation. To achieve this effect, use the
-nocovershort argument to vlog/vcom/vopt. Generally, expression and condition coverage
percentages are lower when short-circuit evaluation is active, since, on average, fewer inputs
are considered when evaluating expressions and conditions.

924 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

A brief short-circuit status is given in the Details window and the text coverage report for each
condition and expression.

Related Topics
Condition and Expression Coverage
Reporting Condition and Expression Coverage
FEC Report Examples
FEC Concepts

Exclusions and FEC

Exclusions are row based for both unimodal and bimodal expressions within the FEC report.
The second and more detailed table of the FEC report contains the rows that are excluded. The
first table's rows cannot be excluded. Since rows '_0' and '_1' are not linked to each other for
unimodal expressions, excluding one simply implies that only the other should be hit for that
input term to be considered fully covered. For bimodal expressions, excluding one row out of
the '_0' '_1' pair breaks the link between their outputs. If one row is excluded, the non-excluded
row becomes independent. This means that the corresponding input terminal will be considered
fully covered when the non-excluded row is hit for any output value.

Consider this snippet from the sample report in Example 19-3:

For this example, the input vectors applied to the expression were 0100, 1101 and 1000. Rows 2
and 7 of the FEC table could be excluded using a pragma exclusion such as:

//coverage off -item e 1 -fecexprrow 2 7

#1 tempreg2 <= ((~a & c) | (a & b & ~c & d) | (a & ~b & c & d));

Note that instead of excluding these rows using a pragma, row 2 and 7 of this expression could
have been excluded using the coverage exclude command. Assuming that the expression was
defined on line 28 in a file called adder64.v, the coverage exclude command would be:

coverage exclude -srcfile adder64.v -fecexprrow 28 2 7

ModelSim® SE User's Manual, v10.7 925

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Condition and Expression Coverage

In this example, excluding the row corresponding to 'a_1' (row 2) breaks its pair with 'a_0'.
Input terminal 'a' is now considered covered irrespective of whether 'a_0' is hit for output '0' or
'1'. Similarly, input terminal 'd' is considered fully covered when 'd_1' is hit.

Legacy FEC Reporting

ModelSim now implements an improved mode of processing called Rapid Expression Coverage
(REC), which is the default mode for FEC condition and expression coverage. This mode offers
better performance and can handle larger expressions than previous versions of coverage
processing. By default, the non-masking conditions in the FEC tables are printed, instead of the
matching input patterns.

VHDL Condition and Expression Type Support

Condition and expression coverage supports bit, boolean and std_logic types. Arbitrary types
are supported when they involve a relational operator with a boolean result.
These types of subexpressions are treated as an external expression that is first evaluated and
then used as a boolean input to the full condition. The subexpression can look like:

(var <relop> const)

or:

(var1 <relop> var2)

where var, var1 and var2 may be of any type; <relop> is a relational operator (for example, ==,
<, >, >=); and const is a constant of the appropriate type.

Expressions containing only one input variable are ignored, as are expressions containing
vectors. Logical operators (for example, and, or, xor) are supported for std_logic/std_ulogic, bit,
and boolean variable types.

When condition or expression coverage is enabled, all VHDL expression inputs are converted
to one of 4 states: 0, 1, X, or Z. In particular, a common scenario is for U to be converted to X,
which can sometimes visibly affect simulation results.

Related Topics
Condition and Expression Coverage

Verilog/SV Condition and Expression Type Support

For Verilog/SV condition and expression coverage, as in VHDL, arbitrary types are supported
when they involve a relational operator with a boolean result. Expressions containing only one

926 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Condition and Expression Coverage

input variable are ignored, as are expressions resulting in vector values. Logical operators (&&
|| ^, for example) are supported for one-bit net, logic, and reg types.
Related Topics
Condition and Expression Coverage

ModelSim® SE User's Manual, v10.7 927

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Toggle Coverage
Toggle coverage is the ability to count and collect changes of state on specified nodes,
including:
• Verilog and SystemVerilog signal types: wire, reg, bit, enum, real, shortreal, and integer
atoms (which includes shortint, int, longint, byte, real, integer, and time). SystemVerilog
integer atoms are treated as bit vectors of the appropriate number of bits, and counts are
kept for each bit. Aggregate types (arrays, structs, packed unions) are handled by
descending all the way to the leaf elements and collecting coverage on each leaf bit.
• VHDL signal types: boolean, bit, bit_vector, enum, integer, std_logic/std_ulogic, and
std_logic_vector/std_ulogic_vector. Aggregate types (arrays, records) are handled by
descending all the way to the leaf elements and collecting coverage on those bits.
There are two modes of toggle coverage operation - standard (or 2-state) and extended (or 3-
state). Extended coverage allows a more detailed view of test bench effectiveness and is
especially useful for examining the coverage of tri-state signals. It helps to ensure, for example,
that a bus has toggled from high 'Z' to a '1' or '0', and a '1' or '0' back to a high 'Z'. (See Standard
and Extended Toggle Coverage.)

When compiling or simulating, specify standard (2-state) toggle using the “t” code, and
extended (3-state) toggle using the “x” code. See “Specifying Toggle Coverage Statistics
Collection” for more information on this topic.

Toggle coverage can be excluded from statistics collection, though proper management of
exclusions is important. See “Toggle Exclusion Management” for information on this topic.

Toggle Coverage and Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928

VHDL Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Verilog/SV Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Toggle Ports Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Viewing Toggle Coverage Data in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . 931
Understanding Toggle Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Specifying Toggle Coverage Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Toggle Using the Main Window Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Limiting Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940

Toggle Coverage and Performance Considerations

Toggle coverage can be expensive in terms of performance since it applies to many objects in
simulations. It also turns off several important optimizations used by Questa. If Toggle
coverage is collected indiscriminately across an entire design, slowdowns of 10x or more may
be observed.

928 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

The “Toggle Ports Only” flow - viewing only the ports when collecting toggle coverage - helps
reduce this impact (see “Toggle Ports Only Flow”).

Other methodologies may help as well; for example, only collecting toggle coverage on a subset
of simulations, or on a subset of regions within a simulation.

In addition, the following vcom, vlog, and vsim options also can be used to control performance
and capacity when toggle coverage is in effect: -togglecountlimit, -togglewidthlimit,
-togglevlogint, -togglemaxintvalues, -togglevlogreal, -togglemaxrealvalues,
-togglefixedsizearray, and -togglemaxfixedsizearray.

In vopt, the following toggle related options are available: -togglecountlimit, -togglewidthlimit,
and -toggleportsonly.

Related Topics
Toggle Coverage

VHDL Toggle Coverage Type Support

Supported types for toggle coverage are: boolean, bit, enum, integer, std_logic/std_ulogic, and
arrays and records of these types, including multi-dimensional arrays and arrays-of-arrays.
VHDL multi-dimensional arrays and arrays-of-arrays are not treated as toggle nodes by default.
To treat them as toggle nodes, use the -togglefixedsizearray argument to the vsim command,
enable the ToggleFixedSizeArray variable in modelsim.ini. VHDL multi-dimensional arrays
and arrays-of-arrays are supported, providing that the leaf level elements consist of supported
data types. These arrays are broken into their leaf level elements, and toggle coverage for each
element is calculated individually.

For VHDL enums, counts are recorded for each enumeration value and a signal is considered
“toggled” if all the enumerations have non-zero counts.

For VHDL integers, a record is kept of each value the integer assumes and an associated count.
The maximum number of values recorded is determined by a limit variable that can be changed
on a per-signal basis. The default is 100 values. The limit variable can be turned off completely
with the -notoggleints option for the vsim command or setting ToggleNoIntegers in the
modelsim.ini file. The limit variable can be increased by setting the vsim command line option
-togglemaxintvalues, setting ToggleFixedSizeArray in the modelsim.ini file, or setting the Tcl
variable ToggleMaxIntValues. A VHDL integer is considered 100% toggled if at least two
different values were seen during simulation. If only one value was ever seen, it is considered
0% toggled.

For VHDL arrays, toggles are counted when the array has less than ToggleWidthLimit elements
(refer to “Limiting Toggle Coverage”). Toggle coverage works for VHDL arrays by descending
to the bit elements at the leaves of the array, and then collecting counts for each leaf bit.

ModelSim® SE User's Manual, v10.7 929

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Related Topics
Toggle Coverage

Verilog/SV Toggle Coverage Type Support

Supported types for toggle coverage are wire, reg, bit, logic, fixed-size multi-dimensional array
(both packed and unpacked), real, enum, integer atoms (that is, integer, time, byte, shortint, int,
and longint), packed unions, and structures (both packed and unpacked) with fields of types
supported for toggle coverage. For objects of non-scalar type, toggle counts are kept for each bit
of the object. Dynamic arrays, associative arrays, queues, unpacked unions, classes, class-like
objects such as mailbox and semaphore, and events do not participate in toggle coverage
collection.
SystemVerilog integer atom types are treated as toggle nodes unless the -notogglevlogints
argument is applied to the vsim command line, or the ToggleVlogIntegers variable is turned off
in modelsim.ini. The simulator breaks up integer atoms into individual bits and counts them as
toggle nodes.

SystemVerilog real types (real, shortreal) are not treated as toggle nodes by default. To treat
them as toggle nodes, use the vsim command’s -togglevlogreal argument or turn on the
ToggleVlogIntegers variable in modelsim.ini. When toggle collection is in effect for SV real
types, a record is kept of each value the real assumes and an associated count. The maximum
number of values recorded is determined by a limit variable. The default is 100 values. The limit
variable can be increased by setting the vsim command line option -togglemaxrealvalues, or
setting ToggleMaxRealValues in the modelsim.ini file. A SystemVerilog real is considered
100% toggled if at least two different values were seen during simulation. If only one value was
ever seen, it is considered 0% toggled.

SystemVerilog packed types include sophisticated data structures such as packed struct, packed
union, tagged packed union, multi-dimensional packed arrays, enumerated types, and
compositions of these types. By default, toggle coverage is reported for each dimension or
member of such types. However, you can control this by making use of the -togglepackedasvec
argument to the vsim command. This option causes coverage to be reported as if the object was
an equivalent one-dimensional packed array with the same overall number of bits. The
“TogglePackedAsVec” modelsim.ini variable provides a default value for -togglepackedasvec.

Objects of enumerated types are considered to be covered if all of the enumeration values occur
during simulation. However, the -togglevlogenumbits argument to the vsim command can be
used to cause the object to be treated as an equivalent packed array of bit or logic type. The
“ToggleVlogEnumBits” modelsim.ini variable provides a default value for
-togglevlogenumbits.

SystemVerilog unpacked array support is limited to fixed-size arrays. Refer to the

-togglefixedsizearray and -togglemaxfixedsizearray arguments to the vsim command. Other
kinds of unpacked arrays (dynamic arrays, associative arrays, and queues) are not supported for

930 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

toggle coverage. The -togglepackedasvec option only applies to the packed dimensions of
multi-dimensioned SystemVerilog arrays.

SystemVerilog unpacked structs are supported as long as all struct elements consist of
supported data types. Unpacked structs are broken into their fields and toggle coverage for each
field is calculated individually.

Related Topics
Toggle Coverage

Toggle Ports Only Flow

At times the amount of data collected during Toggle Coverage can be overwhelming. It is
possible to limit the amount of data by only collecting coverage on ports. Internal signals can be
left out of the UCDB, thus reducing both storage and processing requirements.
This approach is known as the “Toggle Ports Only” flow. It is enabled by using the
TogglePortsOnly modelsim.ini variable or the -toggleportsonly switch with the vlog, vcom,
vopt, or vsim commands. If you want to see coverage of all ports in the design, use the “vopt
+acc=p” command — but note that there could be a significant performance penalty due to the
fact that inlining is turned off. You can selectively enable toggle coverage on specific ports by
using the “vopt +acc=p+<selection>” command.

The coverage reports and GUI will only show numbers associated with togglenodes that are
ports in the design. Similarly, coverage aggregation calculations only involve ports. The Toggle
Ports Only flow correctly handles simulator port collapsing. Other approaches such as “toggle
add -ports …” and “coverage exclude …” do not work as smoothly or intuitively when port
collapsing is present.

Related Topics
Toggle Coverage

Viewing Toggle Coverage Data in the Objects Window

To view toggle coverage data in the Objects window right-click in the window to open a context
popup menu mouse-over the Toggle Coverage selection to open the sub-menu.

ModelSim® SE User's Manual, v10.7 931

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Figure 19-5. Toggle Coverage Menu

The sub-menu allows you to Add toggle coverage for the selected item(s) in the Objects
window; include Extended toggle coverage; Enable or Disable toggle coverage; or Reset.
Another sub-menu allows you to choose Selected Signals, Signals in Region, or Signals in
Design.

Toggle coverage data is displayed in the Objects window in multiple columns, as shown below.
Right-click the column title bar and select Show All Columns from the popup menu to make
sure all Toggle coverage columns are displayed. There is a column for each of the six transition
types. Click (left mouse button) any column name to sort data for that column. Refer to Objects
Window in the GUI Reference Manual for more details on each column.

Figure 19-6. Toggle Coverage Data in the Objects Window

932 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

Related Topics
Toggle Coverage

ModelSim® SE User's Manual, v10.7 933

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Understanding Toggle Counts

This section defines what is considered as a “toggle” during a simulation.
All toggle coverage ignores zero-delay glitches: they do not count. Also, initialization values
are not counted.

Standard and Extended Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934

Conversion of Extended Toggles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Coverage Computation for Toggles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
Toggle Nodes that Span Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
Extended Toggle Mode Across Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937

Standard and Extended Toggle Coverage

Standard (2-state) toggle coverage only counts 0L->1H and 1H->0L transitions.
Extended (3-state) toggle coverage counts these transitions plus four possible Z transitions (0L-
>Z, 1H->Z, Z->0L, Z->1H)

There are three different modes for extended toggle coverage. The modes range from optimistic
(mode 1) to pessimistic (mode 3). Select the mode that corresponds best to your coverage
methodology and goals.

Mode selection can be done on a per-design unit basis using vcom/vlog options, or on a more
global basis using vopt or vsim options.

• Mode 1: 0L->1H & 1H->0L & any one Z transition (to/from Z)

• Mode 2: 0L->1H & 1H->0L & one transition to Z & one transition from Z
• Mode 3: 0L->1H & 1H->0L & all four Z transitions.

Conversion of Extended Toggles

It is common in extended toggle coverage that not all togglenodes in a given scope are capable
of producing Z values. For this reason, all modes of extended toggle coverage calculation allow
100% coverage for lh and hl, as long as no Z edge occurs. An extended togglenode with no Z
edges observed in simulation is implicitly converted to a 2-state togglenode.
The togglenode therefore only has 0L->1H and 1H->0L counts. Such togglenodes will have
their mode of extended toggle coverage reported as '2-STATE' in coverage reports. If such a
togglenode is eventually merged (via vcover merge or similar) with a simulation that contains Z
edges, the merge is pessimistic: the merged result contains all the Z edges.

934 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

Coverage Computation for Toggles

Both regular and extended toggle coverage are calculated using the general coverage calculation
algorithm: cover = {# covered bins} / {# total bins}. In regular mode, each togglenode has 2
bins. In extended mode, there are a different number of bins based on the exact extended toggle
mode.
First, nothing changes with respect to 0L->1H and 1H->0L bins. These are 2 bins and are
always counted that way. However, the various Z bins are counted differently:

if (extended toggle mode is 1) then

# total bins = 3
if (lz or zl or hz or zh) then
# covered++
endif
else if (extended toggle mode is 2) then
# total bins = 4
if (lz or hz) then
# covered++
endif
if (zl or zh) then
# covered++
endif
else if (extended toggle mode is 3) then
# total bins = 6
each of zl, zh, lz, hz are counted individually for # covered
endif

The # total bins will affect the “Active” count in vcover stats and any reference to “toggle
nodes” in reports.

Toggle Nodes that Span Hierarchy

In hierarchical designs, many signals span multiple levels of hierarchy through port
connections. At each level of the design, such signals have different hierarchical names.
For example:

/top/clk
/top/dut/clk
/top/dut/deep/fsm/clk

may all be different names for the same signal. In ModelSim, we use the term “alias name” to
refer to the set of duplicate names. We use the term “canonical name” to refer to a unique name
that can be used to describe the overall signal. In almost all cases, the “canonical name” is the
top-most name of the signal in the hierarchy. Note that a canonical name is just another alias in
the overall set of aliases. In other words. the canonical name can be considered an alias name,
too.

ModelSim® SE User's Manual, v10.7 935

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

In the example above, /top/clk is the canonical name, and the other names are alias names.
When toggle coverage is enabled for such designs, one has to consider the issue of multiply
counting and reporting statistics on the signal's various alias names.

A couple of situations exist in which aliasing is not applicable. The following are some of the
more common cases, where a signal could be counted more than once:

1. Mixed language boundary — For example, in cases where a Verilog module instantiates
a VHDL entity (or vice-versa), separate counts are maintained for the Verilog signal and
the VHDL signal.
2. SystemVerilog variable ports (like a Verilog reg used as a port) — these are not treated
as connected nets, hence are not treated as aliases
3. VHDL conversion functions on port actuals
4. vsim -nocollapse option is used (only applies to VHDL designs)
ModelSim uses the following rules when processing hierarchical togglenodes:

1. When reporting toggle coverage in a single du or instance, no consideration is given to

alias names vs. canonical names. All toggle nodes declared in the du or instance are
shown and their toggle counts and percentages are displayed. Examples of this occur in
the Objects window, the Details window, the HTML report for a given du or instance,
and the output of the “coverage report -code t -details” command.
2. When reporting aggregated toggle results in a hierarchy, a given signal is only
considered once when determining toggle coverage numbers. If more than one name for
a given toggle node is present in the hierarchy, only one of the names for the toggle node
is used when recursively aggregating toggle coverage numbers (the canonical name is
used if it is present). Recursive aggregation of toggle coverage numbers occurs in
several places, including:
o The Structure window’s Toggle % column, when “Enable Recursive Coverage
Sums” is enabled, as it is by default
o The Structure window's “Total Coverage” column
o Total Coverage in the UCDB Browser
o The hierarchical numbers in HTML Report's
o The output of the “toggle report” command
By default, alias toggle nodes are removed from the GUI and from coverage reports, and they
are not saved to a UCDB from the simulation. The vsim -coveranalysis option allows you to
display those alias toggle nodes in coverage reports and in the GUI, and save them in the UCDB
files.

936 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

At times, the existence of alias names for high level toggle nodes can create confusion for users
when viewing toggle coverage numbers. For example, if you enable toggle reporting on one
specific instance using “toggle add -instance”, you might find that toggle coverage numbers
start appearing in other instances. Likewise, if you exclude a togglenode in one instance, you
might find that togglenodes (ports and internal signals) disappear in other instances. This
behavior occurs when nets span multiple instances and a set of alias names is present. The
behavior is normal and occurs by default: it does not compromise coverage numbers or
performance.

The best way to have full access to all alias names of hierarchical toggle nodes is to use the vopt
+acc=p switch and vsim -nocollapse. Without the use of these, many ports on hierarchical
signals are not visible to the coverage reporting system. The +acc=p switch can degrade
simulator performance significantly, so only use it when necessary for analysis. Use the
+acc=p+<selection> modifier whenever possible in order to prune down the affected area of the
design.

To see a complete list of all alias names on each hierarchical signal, you can use the -duplicates
switch with the toggle report command.

If you see that some toggle nodes (typically aliased ports) are missing in a coverage report, run
an exclusion report (coverage report with exclusions enabled) to see if those nodes might have
been excluded on a different alias, using a command such as:

coverage report -excluded -code t

If you are only interested in monitoring the coverage numbers of ports on selected blocks in
your design, you might also consider using the following command:

toggle report -select ports

Extended Toggle Mode Across Hierarchy

It is possible that a signal that spans multiple levels of hierarchy will have different toggle
modes applied to it.
Consider the following compile commands:

vlog +cover=x+/top
vlog +cover=t+/top/dut

In this scenario the compiler applies “extended toggle mode” to /top/clk, and regular toggle
mode to /top/dut/clk and lower aliases. In such cases, the mode that is applied to the canonical
name dominates the mode(s) applied to other aliases of the signal. So, /top/clk, /top/dut/clk, and
/top/dut/deep/fsm/clk would all be collected in extended toggle mode.

If there is more than one extended toggle mode applied to the same hierarchical signal at both
compile time and simulation time, the option with the highest priority overrides the setting.

ModelSim® SE User's Manual, v10.7 937

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Vsim time is lowest priority and vlog/vcom time is highest priority. For example, if a design is
compiled with -extendedtogglemode 1, but simulated with -extendedtogglemode 2, the
compiler option overrides the simulator option, so the -extendedtogglemode is applied to the
design as 1.

Related Topics
Toggle Coverage

938 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Coverage

Specifying Toggle Coverage Statistics Collection

You can specify that toggle coverage statistics be collected for a design.
Either standard toggle or extended toggle may be specified, using any of the following methods:

• Compile (vcom/vlog) using the argument +cover= with either ‘t’ or ‘x’. See “Specifying
Coverage Types for Collection” for more information.
• Entering the toggle add command at the command line.
• Select Tools > Toggle Coverage > Add or Tools > Toggle Coverage > Extended in
the Main window menu.
Using the Toggle Add Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939

Using the Toggle Add Command

The toggle add command allows you to initiate toggle coverage at any time from the command
line. Upon the next running of the simulation, toggle coverage data will be collected according
to the arguments employed (that is, the -full argument enables collection of extended toggle
coverage statistics).
Arguments specified with toggle add command override those set by the +cover=t(x) arguments
set at compile time (vlog/vcom). The toggle add command also allows you to change toggle
modes (from standard to extended or vice versa) during simulation. 0L->1H and 1H-> 0L
transition counts are maintained no matter how many times you switch modes. Z transitions,
however, are reset.

Note
If you do a toggle add command on a group of signals, then 'toggle add -full' on the same
signals will convert them to extended toggle coverage mode (all six transitions). (See
Standard and Extended Toggle Coverage.)Similarly, if you do a 'toggle add' command on
extended toggle coverage mode toggles (six transitions), then it will convert them into standard
coverage toggles (two transitions).

• When the toggle add command is given, the result '0' (number of toggles added) means
that any(all) existing extended toggle nodes were converted to standard toggles.
• When the 'toggle add -full' command is given, then result '0' (number of toggles added)
means that any(all) existing toggle nodes were converted to extended toggles.
• For SystemVerilog struct, conversion will apply to all fields of the structure and not to
any particular type of field.

ModelSim® SE User's Manual, v10.7 939

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Coverage

Toggle Using the Main Window Menu Selections

Enable toggle coverage by selecting Tools > Toggle Coverage > Add or Tools > Toggle
Coverage > Extended from the Main window menu. These selections allow you to enable
toggle coverage for Selected Signals, Signals in Region, or Signals in Design.
After making a selection, toggle coverage statistics will be captured the next time you run the
simulation.

Related Topics
Toggle Coverage

Limiting Toggle Coverage

You can limit the toggle coverage count for a toggle node.
The ToggleCountLimit modelsim.ini variable does just this. After the limit is reached, further
activity on the node will be ignored for toggle coverage. All possible transition edges must
reach this count for the limit to take effect.

For example, if you are collecting toggle data on 0->1 and 1->0 transitions, both transition
counts must reach the limit. If you are collecting “full” data on 6 edge transitions, all 6 must
reach the limit. The default setting for this variable is 1. If the limit is set to zero, then it is
treated as unlimited.

If you want different toggle count limits on different design units, use the -togglecountlimit
argument for vcom or vlog. The -countlimit argument for the toggle add command sets a count
limit on a specific node.

If you want to override the ToggleCountLimit variable everywhere, like for a batch run, use the
-togglecountlimit argument for vsim.

The ToggleWidthLimit modelsim.ini variable limits the maximum width of signals that are
automatically added to toggle coverage with the +cover=t argument to vcom or vlog. The
default limit is 128. A value of 0 is taken as “unlimited.” This limit is designed to filter out
memories from toggle coverage. The limit applies to Verilog registers and VHDL arrays. If the
register or array is larger than the limit, it is not added to toggle coverage.

You can change the default toggle width limit on a design unit basis with the -togglewidthlimit
argument for vcom, vlog, or vsim.

The -widthlimit argument for the toggle add command sets the width limit for signals on a
specific node.

Related Topics
Toggle Coverage

940 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Finite State Machine Coverage

Finite State Machine Coverage

Because of the complexity of state machines, FSM designs can contain a higher than average
level of defects. It is important, therefore, to analyze the coverage of FSMs in RTL before going
to the next stages of synthesis in the design cycle.
Related Topics
Finite State Machines

SystemVerilog Class Coverage

The code coverage feature of ModelSim explicitly understands the existence of SystemVerilog
classes, both parameterized and non-parameterized. Code coverage data is collected separately
for each elaborated class type and each specialization of a parameterized class. Data is not be
collected separately for each constructed dynamic class object, only the sum of all objects of a
given elaborated type. Data is be collected separately for each instance of a module when the
class is declared within the module.
Class property initializations are not considered for code coverage, only code within class
methods.

Code coverage is reported separately for classes when you use the coverage report command,
and coverage data for classes appears in the Structure and Source windows.

Code coverage data is also written to the UCDB file.

ModelSim® SE User's Manual, v10.7 941

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Coverage Exclusions

Coverage Exclusions
When code coverage is enabled for an entire design, or for the purposes of debugging a
particular segment of the design, you may want to exclude coverage for individual design units,
files, lines of code, objects, and so on. Coverage exclusions are used for this purpose.
Coverage objects can be excluded using the coverage exclude command, or with source code
pragmas. When exclusions are applied, they are saved into the UCDB along with all coverage
count data. This allows you to generate reports later in Coverage View mode which match the
most recent simulation state.

What Objects can be Excluded?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942

Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude Individual Metrics with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Adaptive Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Toggle Exclusion Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Exclude Nodes from Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
FSM Coverage Exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972

What Objects can be Excluded?

Exclusions can be instance or file specific.
The following objects can be excluded from coverage statistics collection.

• Any number of lines or files containing various constructs such as states, branches,
expressions and conditions.
• Condition and expression truth table rows.
• Toggles (see “Toggle Exclusion Management”).
• FSM transitions and states (see “FSM Coverage Exclusions”).
• Functional coverage (see “Excluding Functional Coverage from the GUI and Reports”)
• Assertions (see “Excluding Assertions and Cover Directives”)
You can also exclude nodes from toggle statistics collection using “coverage exclude -code t”,
“coverage exclude -togglenode”, or“toggle disable”.

942 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Excluded Objects in the GUI

Related Topics
coverage exclude [ModelSim SE Command Reference Manual]
toggle disable [ModelSim SE Command Reference Manual]

Excluded Objects in the GUI

Excluded coverage objects are designated in the GUI by a green ‘E’ in the appropriate coverage
column.
You may exclude lines or items from coverage by clicking the green ‘E’ icon in the header
toolbar of the Code Coverage Analysis Window. Refer to Code Coverage Analysis Window in
the GUI Reference Manual for more information.

Related Topics
Source Window Code Coverage Indicator Icons [ModelSim SE GUI Reference Manual]

Auto Exclusions
Exclusions are automatically applied to certain code constructs. One good example is assertion
code, which is normally not considered part of the “design”. It is not normally desired to have
assertions participate in code coverage.
Another case is FSM state exclusions. By default, when a state is excluded, all transitions to and
from that state are excluded. To explicitly control FSM auto exclusions set the vsim argument
-autoexclusionsdisable using a command such as:

vsim <your vsim args> –autoexclusionsdisable=fsm

To change the default behavior of the tool, set the variable AutoExclusionsDisable in the
modelsim.ini file.

Auto Exclusions in the Source Window

The Source window and coverage reports display the coverage data with special indications on
lines that contain auto exclusions.

Refer to “Coverage Data in the Source Window” in the GUI Reference Manual for a full list of
icons (such as EA), and to Table 19-3 for a list of codes (such as “EBCS”) that appear in the
coverage report and are associated with auto exclusions.
Table 19-3. Auto-Exclusion Reason Codes in Coverage Reports
Reason Description of Coverage Item’s Exclusion
Code
E Item is excluded, with no reason given

ModelSim® SE User's Manual, v10.7 943

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Auto Exclusions

Table 19-3. Auto-Exclusion Reason Codes in Coverage Reports (cont.)

Reason Description of Coverage Item’s Exclusion
Code
ERS RHS of statement is static
ECP Constant is propagated
ESP Signal is propagated
EBCS Branch condition is static
EES Expression is static
ECNT Constant is a register
ESIG if gen is inactive
ESFG for gen is inactive
EUR Item is unreferenced
ECOP Item excluded due to a clock optimization1
EA Item is an assertion statement
ECG Item is a covergroup
EEXP Expanded expression
ERED Reduced expression
EMRG Merged expression
ECTP Item is converted to a equivalent process
ETX Item is transformed for performance reasons
EGCA Conversion of gate to continuous assignment
ECOL Combined construct
EINL Item is inlined
EINT Item is internal
ERR Error
EOTH Other, non specified
1. All-false branches often are designated with ECOP. See
“AllFalse Branches” for more details.

Related Topics
AllFalse Branches
Coverage Data in the Source Window [ModelSim SE GUI Reference Manual]

944 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Methods for Excluding Objects

Methods for Excluding Objects

ModelSim includes the following mechanisms for excluding coverage from the UCDB.
• From within the GUI:
o File window: Right-click a file and select Code Coverage > Exclude Selected File
from the popup menu.
o Code Coverage Analysis window: Right-click an object
OR
Source window: Right-click a line in the Hits or BC column, to:
o Select any of the exclusion options listed in the menu to exclude — or unexclude —
by line, by line for an instance, by file, or exclude with a comment (comments are
not supported in live simulation mode).
In the case of a multi-line statement, branch, condition or expression, be sure to
right-click the last line of the item to correctly apply the exclusion. If an “if” tree has
an AllFalse branch, the exclusion must be applied to the first “if” statement. See
“AllFalse Branches” for further details.
o Exclude objects with a comment, or edit existing comments on exclusions — in
Coverage View mode only — using the comment related menu items. These menu
items are unavailable during live simulation. This method provides a convenient
mechanism for altering the display of coverage in the GUI or reports during post-
processing.
• Using the command line interface (CLI):
o The coverage exclude command excludes code coverage items. Examples:
coverage exclude -du <du_name>//excludes particular design unit
coverage exclude -du * //excludes entire design

See “Exclude Individual Metrics with CLI Commands”.

• Using source code pragmas to exclude individual code coverage (bces) metrics. See
“Exclude Individual Metrics with Pragmas”. The benefit of using pragmas to exclude
coverage is that they move along with the source code, and are not dependent on line
numbers which may shift as the code is edited.
• Using an exclusion filter file, used with a .do file when running simulation with -
coverage. See “Default Exclusion Filter File”.

ModelSim® SE User's Manual, v10.7 945

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with CLI Commands

Exclude Individual Metrics with CLI Commands

Specific metrics can be excluded using the coverage exclude command with specific arguments,
and are available to exclude individual metrics.
Exclude True or False Branch of if Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude Implicit (AllFalse) Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Exclude AllFalse Branches in Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Exclude Any/All Coverage Data in a Single File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948

Exclude True or False Branch of if Statements

You can exclude either the true or false branch of an ‘if’ statement by excluding the lines where
the branch occurs.
For example, consider the following:

if (a = '1') then -- line 30

Z <= Y;
else -- line 32
Z <= X;
end if;

To exclude the true branch in this example, you enter the command:

coverage exclude -code b -srcfile a.vhd -linerange 30

To exclude the false branch:

coverage exclude -code b -srcfile a.vhd -linerange 32

Excluding line 30 excludes the true branch, while excluding line 32 excludes the false branch. A
special case applies when there is no “else”, or an “elsif” is used instead. In that case, an
“AllFalse” branch is created, whose exclusion must be set explicitly.

Related Topics
Exclude Implicit (AllFalse) Branches

Exclude Implicit (AllFalse) Branches

You can also explicitly exclude branches which are implicit at the end of an if/ elsif/elsif tree.
Note that this only applies if there is no trailing “else” at the end of the tree.

946 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with CLI Commands

For example:

if (a = '1') then -- line 30

Z <= Y;
elsif (b = '1') then -- line 32
Z <= X;
end if;

In the event that either a or b remains at '1' throughout the simulation, you will end up with less
than 100% coverage, since the “AllFalse” branch of this construct was never exercised. (for
example, the case of a = '0' and b = '0').

To explicitly exclude that implicit “AllFalse” branch, you must apply the -allfalse option to a
coverage exclude command on line 30:

coverage exclude -code b -srcfile a.vhd -linerange 30 -allfalse

If -code b is not used, all code coverage types on that line would be excluded, too.

In this example, if you do not use the -allfalse switch the “AllFalse” branch will not be
excluded. Only the True branch will be excluded.

If you specify the following command, where the -linerange switch covers all branches of the IF
statement:

coverage exclude -code b -srcfile a.vhd -linerange 30-32

The allfalse branch will be excluded automatically.

You should note that if the line range that is mentioned in an exclusion command includes a
complete IF statement, then, the “AllFalse” branch of this IF statement will be excluded
automatically even if the “-allfalse” switch is not used. However, IF the linerange partially
covers an IF statement, then;

• Without using “-allfalse”, the AllFalse branch will not be excluded but other branches
will be excluded.
• With “-allfalse”, only the AllFalse branch will be excluded and nothing else even if the
linerange covers other True or False branches.

Exclude AllFalse Branches in Case Statements

The coverage exclude command supports exclusion of the all false branch in “case” statements.
The all false branch is bound to the item number of the case head itself exactly as the all false
branch for “if” statements.
You can exclude such a branch using the -allfalse switch as in the following examples:

coverage exclude -scope <inst_name> -line <ln> -code b -allfalse

ModelSim® SE User's Manual, v10.7 947

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with CLI Commands

coverage exclude -src <file_name> -line <ln> -item b <in> -allfalse

See the coverage exclude command

Exclude Any/All Coverage Data in a Single File

In cases where you would like to exclude all types of coverage data in a given source file, use
the coverage exclude command.
The coverage exclude command can be used to exclude any / all of the following types of
coverage:

• Lines within a source file

• Rows within a condition or expression truth table
• Instances or design units
• Transitions or states within a Finite State Machine
Example 19-5. Creating Coverage Exclusions with a .do File

Suppose you are doing a simulation of a design and you want to exclude selected lines from
each file in the design and all mode INOUT toggle nodes. You can put all exclusions in a .do
file and name it, say, exclusions.do. The contents of the exclusions.do file might look like this:

coverage exclude -srcfile xyz.vhd -linerange 12 55 67-90

coverage exclude -srcfile abc.vhd -linerange 3-6 9-14 77
coverage exclude -srcfile pqr.vhd
coverage exclude -du * -togglenode * -inout

This excludes lines 12, 55, and 67 to 90 (inclusive) of file xyz.vhd; lines 3 to 6, 9 to 14, and 77
of abc.vhd; all lines from pqr.vhd, and all INOUT toggle nodes in the design.

After compiling using +cover switch, you can load and run the simulation with the following
commands:

vsim -coverage <design_name> -do exclusions.do

run -all

In order to view details about the exclusions applied, such as which exclusion commands failed,
enable the transcript mechanism prior to running vsim by entering the following line at the top
of the your .do file (exclusions.do).

Default Exclusion Filter File

A default exclusion filter file exists to aid in applying default exclusions to your simulation.

948 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with CLI Commands

Tcl preference variable PrefCoverage(pref_InitFilterFrom) specifies a default exclusion filter

file to read when a design is loaded with the -coverage switch. By default this variable is not
set. Refer to “Simulator GUI Preferences” in the GUI Reference Manual for details on setting
and changing this variable. You can use this setting to automatically load an exclusions.do file
at startup, thus avoiding the command “-do exclusions.do” in the example above.

Related Topics
Exclude Individual Metrics with CLI Commands

ModelSim® SE User's Manual, v10.7 949

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with Pragmas

Exclude Individual Metrics with Pragmas

ModelSim supports the use of source code pragmas to selectively turn coverage off and on for
individual code coverage metrics. Pragmas allow you to turn statement, branch, condition,
expression, toggle and FSM coverage on and off independently.
The sections relating to exclusions with pragmas are:

Supported Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950

Verilog vs. VHDL Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
coverage on and coverage off Pragma Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Pragma Usage and Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956

Supported Pragmas
The pragmas supported are as follows.
coverage on See "coverage on and coverage off Pragma Syntax"
coverage off
coverage never
coverage fixed_value
coverage fsm_off
coverage toggle_ignore
pragma synthesis_off
pragma synthesis_on
pragma translate_off
pragma translate_on
vcs coverage on
vcs coverage off
vnavigatoroff
vnavigatoron

• The “coverage on”, “coverage off”, and “coverage never” pragmas are currently
supported for use with branch, condition, expression, statement, toggle, and FSM
coverage exclusively. They have no effect on Functional coverage.
• For toggle coverage, signal is excluded from coverage if its declaration appears within
the confines of the “coverage off” section of code (see “Exclude Nodes from Toggle
Coverage”).
• For FSM coverage, FSM is excluded from coverage when the declaration of a ‘current
state’ variable appears within the confines of the “coverage off” region of code. The
individual transitions of the FSM are not affected by the exclusion (see “FSM Pragma
Exclusions” for FSM coverage pragma syntax and information).

950 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with Pragmas

Note
Multiple coverage items on a single line of code are numbered, from left to right in
ascending order. If a branch statement occurred on the same line as another type of
coverage object (such as an assignment) in the source code, the item number displayed
for the additional coverage object may change from one report to the next, depending on
whether branch coverage was enabled.

Related Topics
Verilog vs. VHDL Pragmas
coverage on and coverage off Pragma Syntax
Pragma Usage and Nesting
FSM Pragma Exclusions

Verilog vs. VHDL Pragmas

The difference between Verilog and VHDL pragmas is as follows.
• Verilog: Pragmas are enforced at the level of the file. If a pragma is placed in the middle
of a design unit, its influence extends beyond the end of the design unit to the end of the
file.
• VHDL: Pragmas are enforced at the level of the design unit. For example, if you place
“-- coverage off” inside an architecture body, all the following statements in that
architecture are excluded from coverage; however, statements in all subsequent design
units are included in statement coverage (until the next “-- coverage off”). If you place a
pragma outside a design unit scope, it is active until the end of the next design unit.
Usage of each type of pragma differs in the following ways:

• Each pragma is preceded in the code line by either a “//” (Verilog) or “--” (VHDL). For
example:
// coverage never (Verilog)
-- coverage never (VHDL)

• Bracket the line(s) you want to exclude with these pragmas. For example:
-- coverage off b
...
...
-- coverage on b

• The “pragma” keyword can also be replaced with either “synopsys”, “mentor”, or
“synthesis”.

ModelSim® SE User's Manual, v10.7 951

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with Pragmas

• Pragmas can often nest in source code, often without the developer’s awareness. This
can result in coverage being turned on or off at unexpected intervals. For more
information, see “Pragma Usage and Nesting”.

Tip
Important: The 'coverage on' pragma, as well as other synonymous pragmas (such
as synthesis_on, and so on), do not support nested behavior. They turn on coverage,
irrespective of any number of 'coverage off' pragmas encountered earlier in the file.

• The “coverage off” and “coverage on” pragmas turn on and off coverage for specified
items. If no coverage items are specified, all items are affected.
• The “coverage on|off” pragma applies to branches, conditions, expressions, statements,
toggles and FSMs.
For information on toggle exclusions, see “Toggle Exclusion Management”.
The “fsm_off” pragma selectively turns coverage off and on for FSM state variables and
their associated transitions:
// coverage fsm_off <fsm_name> (Verilog)
-- coverage fsm_off <fsm_name> (VHDL)

For more detailed information, see “FSM Pragma Exclusions”.

• The “coverage never” pragma turns off coverage completely. It takes effect at compile
time, and thus can never provide coverage statistics for specified areas of the design
unless the “coverage never” pragma is removed and the design recompiled. In contrast,
“coverage off” and “coverage on” pragmas are simply report-time options, and thus the
coverage statistics for the specified items can be toggled on and off via the GUI or the
coverage exclude command.
• The “coverage fixed_value” pragma is better described as an “inclusion” pragma, which
allows you to fix the values of the input terminal of an expression or condition that has
been added. The resulting FEC table only contains those rows whose input terminals
have hit the specified input values.
The pragma must be placed within the declarative region of the module or architecture,
after the declaration of the signal which the input_terminal constitutes, within the same
scope.
Syntax is (// for Verilog, -- for VHDL):
//coverage fixed_value “<input_terminal>” (<fixed_value>)
--coverage fixed_value “<input_terminal>” (<fixed_value>)

where:
<input_terminal> is any condition or expression in the scope in which the pragma is
added, and in the same form as it appears in the coverage report.

952 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with Pragmas

<fixed_value> is ‘0’, ‘1’, or ‘Z’, which can be expressed as a boolean, integer, bit, or
std_logic literal expression, or as any constant signal or an expression, whose evaluated
value comes out as constant (0 or 1). The value must be enclosed in parentheses '( )'.
Examples:
//coverage fixed_value “a” (3’h0)

// coverage fixed_value "3'{a,b,c} > 1" (0)

-- coverage fixed_value "a" (const1 && const2)

where, const1 and const2 are two constants.

Related Topics
Exclude Individual Metrics with Pragmas
coverage on and coverage off Pragma Syntax
Pragma Usage and Nesting

ModelSim® SE User's Manual, v10.7 953

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with Pragmas

coverage on and coverage off Pragma Syntax

Two forms of the coverage on|off pragma are available.
One form is used for general exclusions of specific coverage types, or for all types if none are
specified.
Another form, called fine-grained exclusion, is used to exercise very precise control over
exclusions in complex code constructs.
Syntax
General exclusions:
coverage {on | off} [bcesft]

Syntax for fine-grained exclusions:

coverage {on | off}
[-item {b c e s} {[<int> | <int>-<int>]+]}
[-allfalse]
[-feccondrow [<int>|<int>-<int>]+]
[-fecexprrow [<int>|<int>-<int>]+]

Arguments
• [bcesft]
Selectively turns on/off branch (“b”), condition (“c”), expression (“e”), statement (“s”),
FSM state variables and associated transitions (“f”), and/or toggle (“t”) coverage. If no
coverage type is specified, all are affected.
• -allfalse
Affects only the “all false” branch from the branch coverage of a specified “if” statement.
This argument is only valid for use with “coverage {on|off} -item b <item#>”.
The term “AllFalse” is being used as a name for an implicit branch at the end of an “if” or
“if-else” decision tree. The AllFalse branch is considered to be hit when none of the
conditions in the decision tree are true. An AllFalse branch does not exist for any decision
tree which ends with a bare “else”. For further details on “all false” and how it applies to the
code, see “Branch Coverage”.
• -feccondrow
Affects only the specified rows from the FEC table of the specified condition.
• -fecexprrow
Affects only the specified rows from the FEC table of the specified expression.
Valid for use with coverage on | off “-item e <item#>”.
• -item
Selectively turns on/off branch (“b”), condition (“c”), expression (“e”), and/or statement
(“s”) coverage(s) for only the line of code immediately following the pragma. Requires both

954 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with Pragmas

a specification for type of coverage and an integer specifying the item numbers (<int>) for
the line immediately following pragma. Coverage items are numbered in ascending order,
from left to right, beginning with 1. Item numbers can be specified as an integer or a series
of integers (item 1 or items 2-4). Multiple items may be specified separated by whitespace.
Description
• The effect of any “coverage on|off” fine-grained pragma exclusion is limited to the next
valid line of source code after excluding all blank lines and comments.
• The -item argument to “coverage on/off” selectively turns on/off coverage for
statements, branches, conditions and/or expressions for the next line of code.
• You do not need to add a matching "coverage off" directive when using fine-grained
exclusions (that is,any pragma specified with a -item option).
• You can combine two or more coverage items in one coverage pragma if the item
numbers are the same. For example,
(// coverage off -item bs 2)

turns off coverage for statement #2 and branch #2 of the next line.
• To exclude/include different item numbers for different coverage items, use two
different pragmas.
// coverage on -item b 2

// coverage on -item c 3-5

turns on coverage for branch #2 and condition #3,4,5 of the next line.
• You can use multiple item numbers and ranges in one pragma.
// coverage on -item s 1 3-5 7-9 11

• For Branches, enabling/disabling coverage for the (case) branch automatically enables/
disables coverage for all its branches even if they are not on the same line of the (case)
branch. You can override the coverage of a certain branch by an additional pragma that
changes coverage of this branch.
• For Conditions, you can selectively turn coverage on/off for certain FEC condition rows
using the -feccondrow. For example,
// coverage off -item c 1 -feccondrow 1 3-5

excludes condition rows (1, 3, 4, 5) of the first condition item from coverage.
• For Expressions, the same functionality can be achieved using -fecexprrow options.
// coverage off -item e 1 -fecexprrow 1-4 6

excludes FEC expression rows (1, 2, 3, 4, 6) of the first expression item from coverage.

ModelSim® SE User's Manual, v10.7 955

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with Pragmas

You can use the same fine grained pragma syntax even when an expression is split into
multiple lines, as follows:
// coverage off -item e 1 -fecexprrow 4
dopb_out_col = dopb_out_col
& ala2a3a4a5
& bignames1
& bignames2;

Examples
• Exclude all the following conditions, and expressions, statement, branches, until a
“// coverage on” pragma is reached, or the end of the design unit is reached.
// coverage off

• Exclude 1st row from the FEC table of the first condition on the next line
-- coverage off -item c 1 -feccondrow 1

• Exclude the 2nd branch and 2nd statement from the next line
-- coverage off -item bs 2

• Exclude 3rd, 5th and 6th statements from statement coverage

// coverage off -item s 3 5-6

• Include coverage for 2nd and 3rd branches, and condition #4 of the next line
// coverage on -item b 2-3

// coverage on -item c 4

• Exclude only the AllFalse branch from the 4th branch on the next line
-- coverage off -item b 4 -allfalse

Related Topics
Verilog vs. VHDL Pragmas
Exclude Individual Metrics with Pragmas
Pragma Usage and Nesting

Pragma Usage and Nesting

During the course of development, the use of pragmas within long source files or included files
can lead to situations in which pragmas are nested. Synthesis pragmas have an effect on
coverage, as well, which further complicates the issue.
Both of these situations can lead to unintended or confusing coverage behavior. The coverage
behavior that ModelSim exhibits as it encounters nested pragmas is described in the following

956 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Individual Metrics with Pragmas

scenarios. In all cases, notes are generated by ModelSim to inform you of when coverage has
been enabled in the sourced code. These notes can be disabled using the vsim argument “-
suppress 2071”.

Consider how code coverage is enabled in the following examples of nested pragmas.

Example 19-6. When Code Coverage Is Turned On

1 //coverage off --> LINE 1

2 /* Coverage is turned OFF in this region */
3 //coverage off
4 /* Coverage is still turned OFF in this region */
5 //coverage on
6 /* Third pragma, Coverage turned ON after this region */
7 //coverage on --> LINE 7
8 /* Fourth pragma, Coverage is already turned ON in this region */

One might logically assume that coverage collection would be enabled by the fourth pragma.
However, it is the third pragma (on line 5) which enables the code coverage collection for the
remainder of the code. This is due to the fact that ModelSim does not support nested pragmas as
one might expect.

A note appears in the Transcript window stating the line responsible for enabling the coverage:

# ** Note: src/test.v(5) : enabling code coverage.

No warning or note appears for the fourth pragma, since the coverage has already been enabled.

Example 19-7. Nesting and Code Coverage Types

1 //coverage off --> LINE 1

2 /* Coverage is turned OFF in this region */
3 //coverage off
4 /* Coverage is still turned OFF in this region */
5 //coverage on bce
6 /* Third pragma, Coverage turned ON after this region */
7 //coverage on --> LINE 7
8 /* Fourth pragma, Coverage is already turned ON in this region */

Case 2a — Code compiled with ‘+cover’:

If the code is compiled with all coverage enabled, the pragma on line 5 enables only branch,
condition and expression; coverage for all types is enabled at line 7. The following notes are
issued:

** Note: src/test.v(5) : enabling branch , condition and expression

coverage.

ModelSim® SE User's Manual, v10.7 957

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Individual Metrics with Pragmas

** Note: src/test.v(7) : enabling code coverage.

Case 2b — Code compiled with ‘+cover=bcs’:

If, however, the code compiled enables only branch, condition and statement coverage, then line
5 (//coverage on bce) enables only branch and condition coverage until line 7, where all
coverage is enabled. The following notes are issued:

** Note: src/test.v(5) : enabling branch and condition coverage.

** Note: src/test.v(7) : enabling code coverage.

The rules governing how coverage is enabled/disabled with pragmas apply to any pragmas
which are synonymous with 'coverage on' and 'coverage off', including:

// [pragma | synopsys | mentor | synthesis | vcs] translate_on

// [pragma | synopsys | mentor | synthesis | vcs] translate_off
// [pragma | synopsys | mentor | synthesis | vcs] synthesis_on
// [pragma | synopsys | mentor | synthesis | vcs] synthesis_off
// [pragma | synopsys | mentor | synthesis | vcs] override_off
// [pragma | synopsys | mentor | synthesis | vcs] override_on

These pragmas, however, do not operate on individual coverage types (b,c,e,s,t, or f). They
enable/disable all types of code coverage as a whole.

958 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Adaptive Exclusion

Adaptive Exclusion
Adaptive Exclusion enables you to generate an exclusion DO file that you can use to apply
coverage exclusions even after changes in your design.
The Adaptive Exclusion DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Generating an Adaptive Exclusion DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960

The Adaptive Exclusion DO File

The adaptive exclusion DO file is robust enough to mark intended exclusions despite design
changes that alter file line number information.
Coverage exclusions enable you to exclude individual design units, files, lines of code, objects,
and so on, from coverage statistics. Usually employed by giving a DO file—specifying
everything to be excluded from coverage in a particular run—coverage exclusions contain
specific file line number information to identify objects to be excluded.

When running multiple simulations runs, the exclusion DO file excludes all intended objects
from coverage as long as the original design/RTL is not changed. Only an original version of
the DO file excludes the intended objects every time.

However, when you want to change the source code and rerun the simulation, your changes may
alter the file line number information and render the original version of the exclusion DO file
useless. Manual editing of the exclusion DO file, in order to incorporate all line number changes
in large designs, poses a real challenge and results in unnecessary effort.

Adaptive Exclusion mitigates the time and effort of manually editing the exclusion DO file. By
using the -adaptive argument with the vopt command you generate a gold exclusion DO file that
you can use to apply exclusions to multiple simulation runs, even after changes in the design.

The flow diagram below illustrates the steps in generating and then applying an adaptive
exclusion file.

ModelSim® SE User's Manual, v10.7 959

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Adaptive Exclusion

Figure 19-7. Adaptive Exclusion Flow Diagram

Generating an Adaptive Exclusion DO File

To be able generate an adaptive exclusion file you must first use the -adaptive argument with
the vopt command. Then, you generate and save the adaptive exclusion DO file by using the
-adaptive argument with the coverage report -excluded command. No separate option needs to
be appended to the vsim command other than the -coverage argument required for code
coverage.
Procedure
1. Enter the vopt command with the -adaptive argument.
vopt -o <opt_design> top +cover -adaptive

Note
The +cover argument must be given with the -adaptive argument.

2. Enter the vsim command with the -coverage option.

vsim -coverage <opt_design>

3. Generate an adaptive exclusion report as a DO file.

coverage report -excluded -adaptive -file exclusion.do

Examples
LIVE SIM FLOW
First Run
1. Compile the design.

960 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Adaptive Exclusion

vlog design.v

2. Optimize the design with the -adaptive argument.

vopt -o opt top +cover -adaptive

3. Load the design with the -coverage argument.

vsim -c -coverage opt

4. Apply intended coverage exclusions in the first run.

coverage exclude <exclusion>

5. Generate an adaptive exclusion report as a DO file.

coverage report -excluded -adaptive -file exclusion.do
Adaptive Run
1. Compile modified design file to be adapted.
vlog design.v

2. Optimize the design with the -adaptive argument.

vopt -o opt top +cover -adaptive

3. Load the design with the -coverage argument.

vsim -c -coverage opt

4. Apply the adaptive exclusion DO file.

do exclusion.do

5. View the coverage report to see that successful adaption has occurred.
coverage report -excluded
POST SIM FLOW
First Run
1. Compile.
vlog design.v

2. Optimize with -adaptive.

vopt -o opt top +cover -adaptive

3. Load with -coverage.

vsim -c -coverage opt

4. Save coverage UCDB.

coverage save u1.ucdb

5. Load the coverage UCDB.

vsim -viewcov u1.ucdb

ModelSim® SE User's Manual, v10.7 961

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Adaptive Exclusion

6. Apply intended coverage exclusions.

coverage exclude <exclusion>

7. Generate an adaptive exclusion report as a DO file.

coverage report -excluded -adaptive -file exclusion.do
Adaptive Run
1. Compile modified design files to be adapted.
vlog design.v

2. Optimize with -adaptive.

vopt -o opt top +cover -adaptive

3. Load design with -coverage.

vsim -c -coverage opt

4. Apply the adaptive exclusion DO file.

do exclusion.do

5. View the coverage report to verify that successful adaptation has occurred.
coverage report -excluded

962 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Exclusion Management

Toggle Exclusion Management

Toggle coverage as it relates to exclusions are more complex to configure than other coverage
types because of the historical fact that the “toggle” command existed before code coverage was
introduced in ModelSim. Thus, there are multiple ways of achieving the same effects.
Two Methods for Excluding Toggles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963

Two Methods for Excluding Toggles

ModelSim offers two independent flows for excluding toggle coverage:
• Manual flow —
Using this flow, you manually add/enable/disable toggles with the following commands:
o toggle add — tells the simulator to cover a set of toggles. This automatically enables
the added toggles. It requires that nets and/or variables be visible to the simulator (in
other words, it will not work in a completely optimized simulation.)
o toggle disable — disables previously added or enabled toggles.
o toggle enable — enables previously disabled toggles.
• Compiler/Simulator flow —
Using this flow, you set up ModelSim to recognize toggles in the design during
compilation, and enable the collection/exclusion of toggle data during simulation using
the following commands:
o vcom/vlog +cover=t — prepares to add all toggles found in the compiled design
units, except pragma-excluded toggles. See “Exclude Nodes from Toggle
Coverage”.

Tip
Since pragma-excluded toggles are parsed in the source compilation, they are
only relevant to the compiler/simulator flow with +cover=t and -coverage. The
pragma exclusion has no effect on toggle add, disable, or enable.

o vsim -coverage — required in order to add all the toggles previously found by the
compiler.
o vcover report -excluded — prints an exclusions report detailing all toggles specific
toggles that were recognized in the design during compilation. The generated report
is actually an executable .do file that you can run at a later time.
o coverage exclude [disable|enable] -pragma — dynamically enables or disables
reporting on toggle nodes that were previously excluded by the compiler.
In this method, both “vcom/vlog +cover=t” and “vsim -coverage” are required in order
to add toggles for coverage.

ModelSim® SE User's Manual, v10.7 963

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Exclusion Management

These two flows of managing toggle coverage and exclusions are quite distinct. You can apply
toggle exclusions by executing an exclusions report as a .do file (TCL format), as mentioned
above. However, this .do file only consistently reproduces the same set of enabled toggles in the
compiler/simulator flow. This is because the exclude commands in the exclusions report depend
on having a given set of toggles currently enabled. In other words, if you introduce any toggle
add/enable/disable commands before applying a set of toggle exclusions from a saved .do file,
the resulting set of toggle exclusions will not be identical to your original set. The toggle
exclusions can only be applied with respect to currently enabled toggles; that is, not to a
pristine, “toggle-free” environment.

This is important, because nothing in ModelSim prevents you from mixing commands from the
manual and compiler/simulator flows, however you should only do so with a solid
understanding of how they interact.

964 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Nodes from Toggle Coverage

Exclude Nodes from Toggle Coverage

The toggle disable command is intended to be used as follows:
1. Enable toggle statistics collection for all signals using the +cover=t or +cover=x
argument to vcom or vlog, or use the toggle add command at run time.
2. Exclude certain signals by disabling them with the “toggle disable” command.
3. Exclude individual transitions of a toggle node with the coverage exclude -togglenode
command. The command syntax is:
coverage exclude -togglenode <node_path_list> [-du <path_list> |
-scope <path_list>] -trans <transition_list>

For example:
coverage exclude -togglenode mybit myreg -trans 01 0z

excludes transitions 0->1 and 0->Z from toggle nodes mybit and myreg.
Transition names are not case sensitive and can be any of the following six transitions:
01 10 0Z 1Z Z0 Z1
You can re-enable toggle statistics collection on nodes whose toggle coverage has previously
been disabled via the toggle disable command using the toggle enable command.

Toggle Pragma Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965

Exclude Bus Bits from Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Re-enable Toggles Excluded with Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Exclude enum Signals from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967

Toggle Pragma Exclusion

You can also exclude toggle nodes using any of the following three pragmas:
1. “coverage off [t]” — excludes any signal placed after “coverage off” and before
“coverage on” in the code. For example, in the following Verilog code:
//coverage off t
reg mysignal;
//coverage on

the signal mysignal appears as “pragma excluded” in toggle coverage reports. See
“coverage on and coverage off Pragma Syntax” for further details.
2. “coverage toggle_ignore” — excludes toggles, including specific bus bits.
Verilog command syntax:
//coverage toggle_ignore <simple_signal_name> [<list>]

ModelSim® SE User's Manual, v10.7 965

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Exclude Nodes from Toggle Coverage

VHDL command syntax:

-- coverage toggle_ignore <simple_signal_name> [<list>]

where <list> is a space-separated list of bit indices or ranges. A range is two integers
separated by ':' or '-'. If <list> is not specified, the entire signal is excluded.
The following additional rules apply to the use of these pragmas:
o The pragma must be placed within the declarative region of the module or
architecture in which <simple_signal_name> is declared.
o Glob-style wildcards are supported. For example, to exclude reg_123, reg_234,
reg_345 from toggle coverage, you can simply enter:
//coverage toggle_ignore “reg*”

Or, to exclude all toggles from coverage for a specific module, you can enter the
following within that module:
//coverage toggle_ignore “*”

To exclude a specific index of a register, such as reg_123[2], reg_234[2],

reg_345[2]:
//coverage toggle_ignore "reg*" "2"

o If using a range, the range must be in the same ascending or descending order as the
signal declaration.
3. “coverage never”
The behavior of the “// coverage toggle_ignore” matches that of the “// coverage on/off”
pragma — that is, toggle nodes will be pragma excluded and can only be included in
coverage by clearing the pragma exclusion at the vsim command line.
However, with the “// coverage never” pragma, toggle node data structures will not be
created and the nodes cannot be included later.
The precedence order of these three pragma exclusions will be:
“coverage never” > “coverage toggle_ignore” > “coverage on/off”

Simultaneous Behavior of Pragmas

Both “// coverage on/off” and “// coverage toggle_ignore” will work for toggle coverage. If
pragmas “// coverage on/off” and “// coverage toggle_ignore” are used simultaneously then “//

966 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Exclude Nodes from Toggle Coverage

coverage toggle_ignore” pragma will override “// coverage on/off” pragma. For example, in the
following code:

module top;
reg temp;
// coverage off
reg temp1;
//coverage on
// coverage toggle_ignore temp
endmodule

both temp and temp1 will be ignored.

In the following code:

module top;
// coverage toggle_ignore temp1
reg temp;
// coverage on
reg temp1;
endmodule

temp is ignored. This is consistent with the behavior of “// coverage toggle_ignore” because
default behavior is coverage ON.

Exclude Bus Bits from Toggle Coverage

You can use the “<list>” specifier in the “coverage toggle_ignore” pragma to exclude bus bits.
You can also use the “toggle add -exclude <list>” command.

Re-enable Toggles Excluded with Pragmas

Toggles that have been previously excluded using pragmas can be re-enabled (in the compiler/
simulator flow) using either the “coverage exclude -code t -pragma -clear” or “coverage exclude
-pragma -clear -togglenode” commands. If the compiled database includes a set of pragma-
excluded toggle nodes, these CLI commands override any pragma exclusions and include the
specified toggles in coverage statistics.

Exclude enum Signals from Toggle Coverage

ModelSim® SE User's Manual, v10.7 967

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
FSM Coverage Exclusions

FSM Coverage Exclusions

In ModelSim, any transition or state of an FSM can be excluded from the coverage reports using
the coverage exclude command at the command line or by pragma.
See the coverage exclude command for syntax details.

Exclude FSM with coverage exclude Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968

FSM Pragma Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969

Exclude FSM with coverage exclude Command

The coverage exclude command is used to exclude the specified transitions from coverage
reports.
Consider the following coverage report:

# FSM Coverage for du fsm_top--

#
# FSM_ID: state# Current State Object : state
# ----------------------
# State Value MapInfo :
# ---------------------
# State Name Value
# ---------- -----
# idle 0
# rd_wd_1 8
# wt_blk_1 3
# wt_wd_1 1
# ctrl 10
# wt_wd_2 2
# wt_blk_2 4
# wt_blk_3 5
# Covered Transitions :
# ---------------------
# Trans_ID Transition Hit_count
# -------- ---------- ---------
# 0 idle -> idle 9
# 2 idle -> wt_wd_1 4
# 3 idle -> wt_blk_1 2
# 4 idle -> rd_wd_1 6
# 5 rd_wd_1 -> rd_wd_2 6
# 7 wt_blk_1 -> wt_blk_2 2
# 9 wt_wd_1 -> wt_wd_2 4

The following are some examples of commands used to exclude data from the coverage report:

coverage exclude -du fsm_top -fstate <state> S1

excludes FSM state S1 from coverage in the design unit fsm_top. <state> is the current state
variable. By default, when a state is excluded, all transitions to and from that state are excluded
(see “Auto Exclusions”).

968 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
FSM Coverage Exclusions

coverage exclude -du fsm_top -ftrans state

excludes all transitions from the FSM whose FSM_ID is state in the design unit fsm_top.

coverage exclude -du fsm_top -ftrans state {idle -> wt_wd_1} {idle -> rd_wd_1}

excludes specified transitions (2 and 3) from the FSM whose FSM_ID is state, in the design unit
fsm_top. If whitespace is present in the transition, it should be surrounded by curly braces.

coverage exclude -scope /fsm_top/a1 -ftrans state

excludes all the transitions from the /fsm_top/a1 instance, in the FSM whose FSM_ID is state,
in instance /fsm_top/a1.

coverage exclude -scope /fsm_top/a1 -ftrans state {idle -> rd_wd_1} {idle -> rd_wd_1}

excludes specified transitions (numbers 3 and 4) from the FSM whose FSM_ID is state, in
instance /fsm_top/a1.

Using -clear with coverage exclude

When the -clear option is used with coverage exclude, it re-enables the reporting of those
transitions which have been excluded. The transitions are specified in the same manner as that
for the coverage exclude command. For example:

coverage exclude -clear -du fsm_test -ftrans <state_var> {idle -> rd_wd_1} {idle ->
rd_wd_1}

re-enables the reporting of the specified transitions.

Related Topics
coverage exclude [ModelSim SE Command Reference Manual]

FSM Pragma Exclusions

You can use coverage pragmas to selectively turn coverage off and on for FSM state variables
and their associated transitions.
Three pragmas are available:

1. “coverage off [f]” — excludes any FSM states and associated transitions that appear
after “coverage off” and before “coverage on” in the code. Current state variables
declared between “// coverage off” and “// coverage on” pragmas are excluded from the

ModelSim® SE User's Manual, v10.7 969

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
FSM Coverage Exclusions

FSM coverage; however, the FSM is recognized. This is consistent with the behavior of
the “// coverage fsm_off ” pragma. For example:
module mid(clock);
input clock;
// coverage off
reg [1:0] cst;
localparam s0 = 2'b00, s1 = 2'b01;
// coverage on
always @(posedge clock)
begin
case (cst)
s0: cst = s1;
s1: cst = s0;
endcase
end
endmodule

The FSM is recognized but is excluded from coverage. See “coverage on and coverage
off Pragma Syntax” for further details.
2. “coverage fsm_off” —
In Verilog, the pragma is:
// coverage fsm_off {<state_var_name>
| -fstate <state_var_name> [<state_list>]
| -ftrans <state_var_name> [<transition_list>]
| -fsamestate <state_var_name> [<state_list>]

In VHDL, the pragma is:

-- coverage fsm_off {<state_var_name>
| -fstate <state_var_name> [<state_list>]
| -ftrans <state_var_name> [<transition_list>]
| -fsamestate <state_var_name> [<state_list>]

where, a transition in <transition_list> is of the form: state1->state2.

Entire FSM(s) with current state variable <state_var_name> are excluded from coverage
if '-fstate', -fsamestate' and '-ftrans' options in the pragma are not used. The pragma
should come after the object declaration; otherwise, it will have no effect.
The following examples demonstrate the use of pragmas for excluding individual states,
individual transitions, or(and) the entire FSM:
a. To exclude the entire FSM with the state_variable cst:
//coverage fsm_off cst

b. To exclude the entire FSM that has state_variable cst and excludes those states and
transitions which constitute s1 and s2 of another FSM (cst2):
// coverage fsm_off cst -fstate cst2 s1 s2

970 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
FSM Coverage Exclusions

c. To exclude only the s1->s0 transition of the FSM cst.:

//coverage fsm_off -ftrans cst s1->s0

d. To exclude state s1 and all related transitions of s1, and excludes s2->s0 and s3->s1
transitions of the other FSM (cst2):
//coverage fsm_off -fstate cst1 s1 -ftrans cst2 s2->s0 s3->s1

e. To exclude same state transitions of s1 and s2 for FSM cst:

//coverage fsm_off -fsamestate cst s1 s2

which excludes s1->s1 and s2->s2 transitions.

f. To exclude all same state transitions of FSM cst:
//coverage fsm_off -fsamestate cst

The state and transition name (strings) are the same as those recognized by the FSM and
as reported in the vsim FSM coverage report.
Warnings are printed only if code coverage is turned on with the +cover=f argument
during compile (with vcom or vlog). If an FSM coverage pragma is specified and
coverage is turned on, the Warning may look like the following:
** Warning: [13] fsm_safe1.vhd(18): Turning off FSM coverage for
"state".

If an FSM coverage pragma is specified before the object declaration, the Warning may
appear as follows:
** Warning: [13] fsm_safe1.vhd(17): Can't find decl "state" for
turning
off FSM coverage.

3. “coverage never” —
The behavior of "// coverage fsm_off" matches that of "// coverage on/off" pragma —
the FSM will be pragma excluded, and can only be included in coverage by clearing the
pragma exclusion at the vsim command line.
The order of precedence for these three pragma exclusions is:

// coverage never > // coverage fsm_off > // coverage on/off"

ModelSim® SE User's Manual, v10.7 971

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Saving and Recalling Exclusions

Simultaneous Behavior of Pragmas

If “// coverage on-off” and “// coverage fsm_off” are used simultaneously then “// coverage
fsm_off” pragma will override the “// coverage on/off” pragma. For example:

module top(clock);
input clock;
// coverage on
reg [1:0] cst;
// coverage fsm_off cst
localparam s0 = 2'b00, s1 = 2'b01;
always @(posedge clock)
begin
case (cst)
s0: cst = s1;
s1: cst = s0;
endcase
end
endmodule

Even though coverage was ON while 'cst' was encountered, the 'fsm_off' pragma will override it
to turn off coverage for FSM (cst).

Related Topics
FSM Coverage Exclusions

Saving and Recalling Exclusions

You may specify files and line numbers or condition and expression FEC truth table rows (see
below for details) that you wish to exclude from coverage statistics. You can then create a .do
file that contains these exclusions using the Tcl command of vsim, coverage report, as follows:
coverage report -excluded -file <filename>.do

You can load this .do file during a future analysis with the vsim command as follows:

vsim -coverage <design_name> -do exclusions.do

For example, the contents of the exclusions.do file might look like the following:

coverage exclude -srcfile xyz.vhd -linerange 12 55 67-90

coverage exclude -srcfile abc.vhd -linerange 3-6 9-14 77
coverage exclude -srcfile pqr.vhd

This excludes lines 12, 55, and 67 to 90 (inclusive) of file xyz.vhd; lines 3 to 6, 9 to 14, and 77
of abc.vhd; and all lines from pqr.vhd.

This exclude.do file can then be used as follows:

To avoid running the “-do exclude.do” explicitly, you can set the default exclusion filter to run
the exclusion.do file automatically upon invocation.

972 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Saving and Recalling Exclusions

Tip
: To view exclusion failures, edit the .do file and add “transcript on” at the beginning of the
file. You can then check the generated transcript after executing the .do file to see which
exclusions have failed.

Example 19-8. Excluding, Merging and Reporting on Several Runs

Suppose you are doing a number of simulations, i, numbered from 1 to n.

1. Use vlib to create a working library.

2. Use vcom and/or vlog to compile.
3. Use vsim to load and run the design:
vsim -c <design_i> -do "log -r /*;
coverage save -onexit <results_i>;
run -all; do <exclude_file_i.do>; quit -f"

Note, you can have different exclude files <exclude_file_i> for each run i, numbered
from 1 to n.
4. Use vcover merge to merge the coverage data:
vcover merge <merged_results_file> <results_1> <results_2> ... <results_n>

5. Use vcover report to generate your report:

vcover report [switches_you_want] -output <report_file> <merged_results_file>

Exclusions are invoked during vsim, in step 3.

All the various results files <results_i> contain the exclusion information inserted at step 3.

The exclusion information for the merged results file is derived by ORing the exclusion flags
from each vsim run. So, for example, if runs 1 and 2 exclude xyz.vhd line 12, but the other runs
do not exclude that line, the exclusion flag for xyz.vhd line 12 is set in the merged results, since
at least one of the runs excluded that line. Then the final vcover report will not show coverage
results for file xyz.vhd line 12.

Let's suppose your <exclude_file_i> are all the same, and called exclude.do.

The contents of exclude.do file could be:

coverage exclude -srcfile xyz.vhd -linerange 12 55 67-90

coverage exclude -srcfile abc.vhd -linerange 3-6 9-14 77
coverage exclude -srcfile pqr.vhd -linerange all

This will exclude lines 12, 55, and 67 to 90 (inclusive) of file xyz.vhd; lines 3 to 6, 9 to 14, and
77 of abc.vhd; and all lines from pqr.vhd.

ModelSim® SE User's Manual, v10.7 973

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage Modes

Code Coverage Modes

Questa SIM provides an exhaustive default coverage collection for RTL constructs. The
covermode option lets you control coverage collection of your constructs to meet coverage
closure goals.
A coverconstruct corresponds to a particular HDL code construct that may be instrumented for
coverage collection. A covermode corresponds to a set of coverconstructs for coverage
collection. The user interface consists of the vopt command-line option for setting covermodes
and the covermode variable in the vopt section of the modelsim.ini file.

Coverconstructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Code Coverage Mode Interaction with Coverage Arguments. . . . . . . . . . . . . . . . . . . . . 977

Coverconstructs
The covermode option provides user-controlled coverconstructs. The coverconstruct syntax is
provided along with examples and a description of the mnemonically named constructs.
A coverconstruct corresponds to a particular HDL code construct that may be instrumented for
coverage collection. Many coverconstructs are permanently enabled and cannot be controlled.
The user-controlled coverconstructs available with the covermode option have a trade-off: you
can collect coverage on these constructs or avoid them and benefit from higher performance and
less data to analyze.

Some examples of coverconstructs are “condition coverage inside a task or function” and
“expression on the right hand side of a variable declaration assignment.” Coverconstructs are
named by mnemonic abbreviations (see Table 19-4). These two example constructs are
abbreviated “citf” and “evda,” respectively.

The following is the vopt command-line option for setting a coverconstruct:

vopt -coverconstruct [comma-separated list of mnemonics]

Example:

vopt -coverconstruct noca,citf

The same can be done using the coverconstruct variable in the [vopt] sections of the
modelsim.ini file:

coverconstruct [list of mnemonics]

974 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Coverconstructs

Table 19-4. Coverconstruct Mnemonics

HDL Construct/Item Mnemonic -covermode -covermode -covermode -covermode -covermode
full default set1 set2 fast

Condition/Branch [no]citf citf citf nocitf citf nocitf

Coverage inside Task/
Function/Procedure
Continuous and [no]ca ca ca noca noca noca
concurrent
assignments and
Statement coverage
Loop indexes of for/ [no]li li li li noli noli
while loop1
FSMs spread across [no]fsmtf fsmtf fsmtf nofsmtf nofsmtf nofsmtf
tasks/procedures
Quad state (2-bit) [no]fsmqs fsmqs fsmqs nofsmqs fsmqs nofsmqs
FSMs2
Condition coverage for [no]ctes ctes ctes noctes noctes noctes
Task Enable statement
Condition coverage for [no]cicl cicl cicl nocicl nocicl nocicl
instance connection
list
Condition coverage for [no]cprc cprc cprc nocprc
PLI routines calls
FSM coverage for [no]fsmup fsmup fsmup nofsmup nofsmup nofsmup
unpacked dimension in
CST/NST
Condition/Branch [no]cifl cifl cifl nocifl cifl nocifl
coverage for code
inside for loops
Protected module or [no]cpm cpm cpm nocpm nocpm nocpm
hierarchy below it
Coverage for SV [no]cpkg cpkg cpkg nocpkg nocpkg nocpkg
packages and classes
Branch and cond [no]csva csva csva nocsva nocsva nocsva
coverage inside
assertions
Coverage for allfalse [no]cafif cafif cafif cafif cafif nocafif
branch for if

ModelSim® SE User's Manual, v10.7 975

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Coverconstructs

Table 19-4. Coverconstruct Mnemonics (cont.)

HDL Construct/Item Mnemonic -covermode -covermode -covermode -covermode -covermode
full default set1 set2 fast

Coverage for allfalse [no]cafcas cafcase cafcase cafcase cafcase nocafcas

branch of a case e e
statement
Coverage for default [no]cdcase cdcase cdcase cdcase cdcase nocdcase
branch of a case
statement3
Coverage for modules [no]bind bind bind bind bind nobind
instantiated using bind
command
Toggle coverage for [no]tcint tcint notcint notcint notcint notcint
integer atomic types4
Toggle coverage for [no]tce tce tce tce notce notce
enum types4
Toggle coverage for [no]tcua tcua notcua notcua notcua notcua
unpacked array types5
Toggle coverage for [no]tcpmd tcpmda tcpmda tcpmda notcpmda notcpmd
packed multi-d array a a
types4
Toggle coverage for [no]tcuu tcuu notcuu notcuu notcuu notcuu
unpacked union types4

Toggle coverage for [no]tcpu tcpu tcpu tcpu notcpu notcpu

packed union types4
Toggle coverage for
packed struct types6
Toggle coverage
forunpacked struct
withpacked field types
Toggle coverage
forunpacked struct
withunpacked field
types7
1. Even if the variable is used in other contexts.
2. Use the -fsmsingle option to enable single-bit FSM recognition.
3. nocdcase excludes the default branch and the content inside the default branch. -coverexcludedefault is
deprecated.
4. Total width controlled by -togglewidthlimit.

976 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Covermodes

5. Unpacked arrays of mixed packed/unpacked dim, singled, multi-d. Deprecate: -togglefixedsizearray,

togglemaxfixedsizearray. Total width controlled by -togglewidthlimit.
6. Default ON in all modes. Total width controlled by -togglewidthlimit.
7. Enable each field individually based on above mnemonics. Total width controlled by-togglewidthlimit.

Covermodes
A covermode corresponds to a set of coverconstructs considered for coverage collection.
The default covermode set (the current behavior) is -covermode default. Other covermodes
differ from the default covermode and are essentially a synonym for sets of enabled
coverconstructs. You can think of -covermode as a shortcut for a specific list of -coverconstruct
mnemonics.

The following is the vopt command-line option setting the covermode:

vopt -covermode <mode>

where mode = full, default, set1, set2, fast

The same can be done using the Covermode variable in the [vopt] section of the modelsim.ini
file:

Covermode=set1

The command-line options override companion variables in the modelsim.ini file.

Code Coverage Mode Interaction with Coverage

Arguments
There are several code coverage options that interact with each other. This section describes
each covermode and its corresponding coverconstructs and provides examples.
The following are code coverage options:

• +cover[=bcefst]
• +nocover
• -covermode [mode]
• -coverconstruct [list of constructs]
• -coveropt [1|2|3|4|5]

Interaction of Coverage Options

• +cover and +nocover — These coverage code options are processed first and enable a
default set of coverconstructs in selected design regions. The +cover option can be given

ModelSim® SE User's Manual, v10.7 977

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage Mode Interaction with Coverage Arguments

to either the compiler (vlog/vcom) or the optimizer (vopt). The +nocover option can
only be given to vopt.
Option processing is performed left-to-right. vlog and vcom are considered to be left of
vopt, and earlier vlog/vcom commands are considered to be left of later commands. If
conflicting options are given, the right-most option takes precedence. So if you use vopt
+nocover+foo +cover+foo, the +cover+foo option takes precedence over the
+nocover+foo option.
Refer to “Priorities for Resolving Conflicting Control Arguments” for a list of priorities
for resolving conflicts from using multiple arguments.
• -covermode and -coverconstruct — After +cover and +nocover are resolved in vopt,
then -covermode and -coverconstruct are taken into account. These options can only be
given to the optimizer (vopt). The -covermode and -coverconstruct options are
processed left to right on the command line. If conflicting options are given (for
example, -csa and -nocsa), the right-most option takes precedence.
• -covermode — The -covermode option specifies a set of -coverconstructs as a kind of
shortcut; it is treated with the same priority as -coverconstruct. Thus, if “vopt -
covermode default -coverconstruct nocsa,li” is given, the nocsa specification takes
precedence over the csa specification, which is included in the -covermode default.
Continuous assignments are not covered.
• Coveropt decides the optimization level of the tool in a coverage enabled run. These
optimizations also have the potential to affect the coverage bins. At times, a high
coveropt level can remove certain instances of a coverconstruct regardless of applied
rest (cover, coverconstructs, or covermode) of the settings. In such cases, those instances
of the coverconstruct are not considered for coverage collection.

Note
If +cover is not active in a design region where -coverconstruct is active, the -coverconstruct
option has no effect. Coverage needs to be fundamentally enabled to control precise
constructs with -coverconstruct.

Coverage Arguments
The table provides descriptions of covermode arguments and corresponding coverconstructs.
Argument Description
-covermode full (Most exhaustive coverage collection) Has the richest set of HDL
constructs and contains all the constructs (except for negation items)
mentioned the mnemonic table.
-covermode default (Default) Has a rich set of cover constructs enabled. All the
covermodes have relative positioning with this default covermode.

978 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Code Coverage Mode Interaction with Coverage Arguments

Argument Description
-covermode set1 This covermode does not consider the following constructs for
coverage collection:
• Continuous/Concurrent Assignments
• Condition coverage inside Task/Function/Procedures
• Task FSMs and two-state FSMs
• Condition coverage:
• In terminal connection lists in task-enabling statements
• In instance connection lists
• In “for” loops
• FSM coverage for unpacked dimension in current state variable
and next state variables
• Branch coverage for “if” and “case” statements and ternary
operator(?:) if they are in user-defined tasks or functions or in
code that executes as a result of a “for” loop.
• Coverage for partially/fully protected modules and their children
for any coverage metric. If a module has some part of the code
protected in it, then do not monitor the module or its self-instance
and the full hierarchy below it, for coverage.
• Toggle for integer atomic types (for example, int, integer, short).
• Coverage for SystemVerilog packages and classes.
• Branch and cond coverage inside assertions.
Hence -covermode set1 is equivalent to following -coverconstruct
option: -coverconstruct noca, nocitf, nofsmtf, nofsmds, noctes,
nocicl, nocprc, nocfl, nofsmup, nocifl, nocpm, notcint, nocpkg,
nocsva
-covermode set2 If an FSM definition spans through a task/procedure or the FSM has
less than three states, some users do not want to bother with
coverage. Covermode 3 removes such FSMs from coverage
collection. This covermode does not consider the following
constructs for coverage collection: Task FSMs and two-state FSMs.
Hence ‘-covermode set2’ is equivalent to the following
-coverconstruct option:
-coverconstruct nofsmtf, nofsmd

Examples of Coverage Options

vopt +cover=t -coverconstruct li

This example enables toggle coverage according to the default -covermode default; in addition
to all toggle nodes present in -covermode full, loop index toggle variables are also collected.

vopt +cover=t -coverconstruct fsmtf+noca

ModelSim® SE User's Manual, v10.7 979

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage Mode Interaction with Coverage Arguments

This example enables toggle coverage according to the default -covermode default. The
-coverconstruct option has no effect, because FSM coverage is not enabled and neither is
expression coverage. (Expression coverage handles continuous assignments.)

vopt +cover -covermode set1 -coverconstruct fsmqs,li,citf

This example enables all code coverage metrics in -covermode set1 and, in addition, the
following are enabled: quad-state FSMs, togglenodes used as loop indexes, and condition
coverage inside tasks and functions.

vopt +cover -coverconstruct fsmqs -covermode set1

This example enables all code coverage metrics in -covermode set1. Quad-state is not
recognized because the implicit nofsmqs inside -covermode set1 overrides the -coverconstruct
option that appeared earlier on the command line.

980 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Coverage Reports

Coverage Reports
Create a coverage report from the command line or with menu selections in the GUI.
Coverage reports can be created with:

• the Coverage Text Report dialog

• the Coverage HTML Report dialog
• the coverage report command — use when a simulation is loaded; creates an organized
list of report data, including toggle data
• the toggle report command — produces an unordered list of unique toggles
• the vcover report command — produces textual output of coverage data from UCDB
generated by a previous code or functional coverage run
HTML reports are also available by applying the -html argument to the coverage report and
vcover report commands. See “Generating HTML Coverage Reports” for more information.

The Coverage Text Report dialog enables you to display coverage reports immediately in the
default Notepad text viewer/editor included with the product, in the Source viewer, or in an
editor of your choice that you set with the EDITOR environment variable. See Setting
Environment Variables.

Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981

Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
The toggle report Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Report Using the Coverage Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
XML Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989

Report Contents
By default, the coverage report contains a summary of coverage information for the indicated
design unit, file, or instance. A summary of code coverage numbers is given for each coverage
type.

ModelSim® SE User's Manual, v10.7 981

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Report Contents

When you specify -details with the coverage report command, the summary information is
followed by coverage details which correspond to each active coverage type:

• For statements — a code listing is given along with counts and exclusion details. This is
similar to the Source window when in coverage mode.
• For branches — a code listing is given and it appears, similar to that shown in the Source
window.
• For conditions and expressions — detailed row-by-row FEC tables are printed, along
with hit counts for each row. See “Reporting Condition and Expression Coverage” for
more information.
• For toggles — a listing of missed togglenodes is printed.
• For FSMs — a listing of missed states and transitions is printed.
• Auto-Exclusions — a list of exclusions along with a code defining the reason they are
excluded. These codes are listed in Table 19-3.
Related Topics
Reporting Condition and Expression Coverage
Auto Exclusions

982 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Code Coverage Profiles

Code Coverage Profiles

A code coverage “profile” is a sequence of coverage items (statements, branches, conditions
and expressions) associated with their respective file/line/item numbers. This sequence can
change if a condition becomes constant and branches and statements are removed, or if a
particular statement right-hand-side becomes a constant and the statement is optimized away.
When the sequence is changed, a new profile is said to exist.
When an instance of a module is “inlined”, the code for that module is copied into the “parent”
module for that instance. Then, further optimizations might be performed on that code,
depending on any parameters or constant inputs to the module. This frequently results in
statements being optimized away, conditions becoming constants, branches being optimized
away, and so forth. So, the code coverage “profile”, or sequence of code coverage items
changes. When there are several instances of a module that are likewise inlined, some with
different parameters and constant inputs, the result is that the family of instances may result in
many different code coverage “profiles”.

The solution for resolving different profiles of coverage lies in reporting coverage by-instance.
When you report the data by-instance, you can see exactly which statements are there (no longer
optimized away) and what their coverage counts are. Whereas, if you report the data by-du or
by-file, ModelSim attempts to merge these different profiles, which may result in apparently
contradictory counts. (Branch counts do not match the corresponding statement counts, and so
forth.) That is why it is recommended to perform reporting on a by-instance basis.

Branch Coverage and Numbering of Items in Coverage Report . . . . . . . . . . . . . . . . . . 983

Branch Coverage and Numbering of Items in Coverage

Report
Multiple coverage items on a single line within a report are numbered, from left to right in
ascending order. If a branch statement occurred on the same line as another type of coverage
object (such as an assignment) in the source code, the item number for the other type of
coverage object displayed in a coverage report may change from one report to the next,
depending on whether branch coverage was enabled.

Using the coverage report Command

The coverage report command produces textual output of coverage statistics or exclusions of
the current simulation.

ModelSim® SE User's Manual, v10.7 983

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Using the coverage report Command

Example 19-9. Reporting Coverage Data from the Command Line

Here is a sample command sequence that outputs a textual code coverage report and saves the
coverage data:

vlog ../rtl/host/top.v
vlog ../rtl/host/a.v
vlog ../rtl/host/b.v
vlog ../rtl/host/c.v
vopt +cover=bcefsx top -o top_opt
vsim -c -coverage top_opt
run 1 ms
coverage report -file d:\\sample\\coverage_rep.txt
coverage save d:\\sample\\coverage.ucdb

The vlog command compiles Verilog and SystemVerilog design units. The +cover=bcefs[t|x]
argument applied to either vopt (for Three-Step Flow) or vlog (for Two-Step Flow) prepares the
design and specifies the types of coverage statistics to collect:

• b = branch coverage
• c = condition coverage
• e = expression coverage
• f = finite state machine coverage
• t = toggle coverage (two-state)
• s = statement coverage
• x = toggle coverage (four-state)
The -coverage option for the vsim command enables code coverage statistics collection during
simulation.

The -file option for the coverage report command specifies a filename for the coverage report:
coverage_rep.txt. And thecoverage save command saves the coverage data to d:\sample\
coverage.ucdb.

Related Topics
coverage report [ModelSim SE Command Reference Manual]

984 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
The toggle report Command

The toggle report Command

The toggle report command displays a list of all nodes that have not transitioned to both 0 and 1
at least once, and the counts for how many times each node toggled for each state transition
type. Also displayed is a summary of the number of nodes checked, the number that toggled, the
number that did not toggle, and a percentage that toggled.
Using toggle report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Port Collapsing and Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Ordering of Toggle Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987

Using toggle report

The toggle report command is intended to be used as follows.
Procedure
1. Enable statistics collection with the +cover=t argument with either the vlog or vcom
commands.
Use the +cover=t argument with the vopt command for the three-step vopt flow.
2. Run the simulation with the run command.
3. Produce the report with the toggle report command.
By default, the report only shows toggle nodes that did not toggle. In order to show all
toggle nodes, including those that have already toggled, use “toggle report -all”.

ModelSim® SE User's Manual, v10.7 985

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
The toggle report Command

Figure 19-8. Sample Toggle Report

4. You can produce this same information using the coverage report command.
Related Topics
toggle report [ModelSim SE Command Reference Manual]
Port Collapsing and Toggle Coverage
coverage report [ModelSim SE Command Reference Manual]

Port Collapsing and Toggle Coverage

The simulator collapses certain ports that are connected to the same signal in order to improve
performance. Collapsed signals will not appear in the toggle coverage report.
If you want to ensure that all signals in the design appear in your toggle report, use the -
duplicates switch with the toggle report command.

Also, you should selectively apply vopt +acc=p to avoid optimizing signals away from the
design and the toggle report. Also, make sure to selectively apply the vsim -nocollapse.

Related Topics
toggle report [ModelSim SE Command Reference Manual]

986 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Report Using the Coverage Report Dialog

The toggle report Command

coverage report [ModelSim SE Command Reference Manual]
Toggle Nodes that Span Hierarchy

Ordering of Toggle Nodes

The ordering of nodes in the report may vary depending on how you specify the signal list.
If you use a wildcard in the signal argument (for example, toggle report -all -r /*), the nodes are
listed in the order signals are found when searching down the context tree using the wildcard.
Multiple elements of the same net will be listed multiple times. If you do not use a wildcard, the
nodes are listed in the order in which they were originally added to toggle coverage, and
elements are not duplicated.

Related Topics
toggle report [ModelSim SE Command Reference Manual]

Report Using the Coverage Report Dialog

To create a coverage report using the ModelSim GUI, access the Coverage Report dialogs by
right-clicking any object in the Files or Structure (sim) windows and selecting Code Coverage
> Code Coverage Reports; or, select Tools > Coverage Report > Text or HTML or
Exclusions.
Related Topics
The Generation of Coverage Reports

Setting a Default Coverage Reporting Mode

You can specify a default coverage mode that persists from one ModelSim session to the next.
You can set the default coverage reporting mode through the preference variable
PrefCoverage(DefaultCoverageMode). The modes available allow you to specify that lists and
data given in each report are listed by: file, design unit, or instance. By default, the report is
listed by file.

You may also specify a default coverage mode for the current invocation of ModelSim by using
the -setdefault [byfile | byinstance | bydu] argument for either the coverage report or the vcover
report command.

Related Topics
Simulator GUI Preferences [ModelSim SE GUI Reference Manual]

ModelSim® SE User's Manual, v10.7 987

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
XML Output

coverage report [ModelSim SE Command Reference Manual]

vcover report [ModelSim SE Command Reference Manual]

XML Output
You can output coverage reports in XML format.
XML output is produced by checking Write XML Format in the Coverage Report dialog or by
using the -xml argument to the coverage report command.

The following example is an abbreviated “By Instance” report that includes line details:

<?xml version="1.0" ?>

- <coverage_report>
- <code_coverage_report lines="1" byInstance="1">
- <instanceData path="/concat_tester/CHIPBOND/control_inst" du="micro"
sec="rtl">
- <sourceTable files="1">
<fileMap fn="0" path="src/Micro.vhd" />
</sourceTable>
<statements active="65" hits="64" percent="98.5" />
<stmt fn="0" ln="83" st="1" hits="2430" />
<stmt fn="0" ln="84" st="1" hits="30" />
<stmt fn="0" ln="85" st="1" hits="15" />
<stmt fn="0" ln="86" st="1" hits="14" />
<stmt fn="0" ln="87" st="1" hits="15" />
...
...

“fn” stands for filename, “ln” stands for line number, and “st” stands for statement.

There is also an XSL stylesheet named covreport.xsl located in <install_dir>/examples/

tutorials/vhdl/coverage, or <install_dir>/examples/tutorials/verilog/coverage.
Use it as a foundation for building your own customized report translators.

Related Topics
coverage report [ModelSim SE Command Reference Manual]

HTML Output
You can output coverage reports in HTML format by checking Write HTML Format in the
Coverage Report dialog or by using the -html argument to the coverage report command.
For more information on HTML output reports, see “Generating HTML Coverage Reports”.

Related Topics
coverage report [ModelSim SE Command Reference Manual]

988 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Coverage Reporting on a Specific Test

Coverage Reporting on a Specific Test

You can output coverage reports for specific tests in all formats, except XML.
Coverage on a specific test can be reported using the -testextract argument to either vcover
report or the coverage report command, or to the -html argument for either of those commands.

Related Topics
Generating HTML Coverage Reports

ModelSim® SE User's Manual, v10.7 989

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Notes on Coverage and Optimization

Notes on Coverage and Optimization

The optimization process removes constructs in your design that are not functionally essential,
such as code in a procedure that is never called. These constructs can include statements,
expressions, conditions, branches, and toggles. This results in a trade-off between aggressive
optimization levels and the ease with which the coverage results can be understood.
While aggressive levels of optimization make the simulation run fast, your results may at times
give you the mistaken impression that your design is not fully covered. This is due to the fact
that native code is not generated for all HDL source code in your design. Those fragments of
HDL code that do not result in native code generation are never instrumented for coverage,
either. And thus, those fragments of code do not participate in coverage gathering,
measurement, or reporting activities.

When observing the Source window, you can tell which statements do not participate in
coverage activities by looking at the Statement and Branch Count columns on the left of the
window. If those columns are completely blank (no numbers or ‘X’ symbols at all), then the
associated statements have been optimized out of the simulation database, and they will not
participate in coverage activities.

Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 990

Interaction of Optimization and Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992

Customizing Optimization Level for Coverage Runs

It is conceivable that you will achieve 100% coverage in an optimized design, even if certain
statements or constructs have been optimized away. This is due to the fact that at the lowest
level, all coverage calculations are of the form “Total Hits / Total Possible Hits = % Coverage”.
Constructs that have been optimized out of the design do not count as Possible Hits. Also,
because the statements never execute, they never contribute to Total Hits. Thus, statements that
are optimized out of the design do not participate in coverage results in any way. (This is similar
to how statements that you explicitly exclude from coverage do not contribute to coverage
results.)

By default, ModelSim enables a reasonable level of optimizations while still maintaining the
logic necessary for the collection of coverage statistics (for details, see CoverOpt modelsim.ini
file variable). If you achieve 100% coverage with the default optimization level, the results are
as viable as achieving 100% coverage with no optimizations enabled at all.

990 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Interaction of Optimization and Coverage Arguments

You can customize the default optimization levels used when coverage is enabled for the
simulation as follows:

• To change optimizations applied to all runs —

Change the value (1 - 5) of CoverOpt modelsim.ini variable from the default level. Refer
to CoverOpt for information on the available optimization levels.
• To change optimizations applied to a specific run —
Set the -coveropt argument to vlog, vcom, or vopt. For example:
vopt +cover=cbesxf -coveropt 2

Refer to CoverOpt for information on the available optimization levels.

Related Topics
CoverOpt
vlog [ModelSim SE Command Reference Manual]
vcom [ModelSim SE Command Reference Manual]
Optimizing Designs with vopt

Interaction of Optimization and Coverage

Arguments
The CoverOpt modelsim.ini variable corresponds to the number options of the vlog/vcom
-coveropt command line option. The valid settings are 1 through 5. The lower the number, the
fewer optimizations are enabled. Fewer optimizations translate into greater design visibility, yet
slower performance.
In ModelSim, the default level of optimization in vopt is -O4.

CoverOpt works as follows: After all other optimization-control options have been processed,
the specified level of CoverOpt optimizations is applied. All CoverOpt can do is turn OFF
certain optimizations known to be harmful or confusing to coverage. CoverOpt never turns on
an optimization that was not enabled already.

Some optimizations are always turned off when code coverage is in effect.

Some +acc flags are always turned on when code coverage is in effect (such as when line
numbering is correctly preserved).

The CoverOpt setting gives you a level of control over how much optimization is applied to
your design when specifying coverage types for collection.

ModelSim® SE User's Manual, v10.7 991

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Code Coverage and Verification IP

Related Topics
CoverOpt
The -O Optimization Control Arguments

Code Coverage and Verification IP

ModelSim performance is affected by code coverage for designs using various IP.
As a result, code coverage is disabled for the following:

• Source files, design units, and classes whose names begin with the following prefixes:
• SystemVerilog header files:
urm.svh
base.svh
base_compatibility.svh
compatibility.svh
methodology.svh
methodology_noparam.svh

• Code that is included from the following SystemC header files:

std_ovl_defines.h
std_ovl_cover.h
std_ovl_task.h
std_ovl_init.h.

992 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 20
Finite State Machines

A Finite State Machine (FSM) reflects the changes a state-based design has gone through from
the start of simulation to the present. Transitions indicate state changes and are described by the
conditions required to enable them. Because of the complexity of FSMs, designs containing
them can contain a high number of defects. It is important, therefore, to analyze the FSMs in
RTL before going to the next stages of synthesis in the design cycle.
FSM Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
FSM Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
FSM Multi-State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Collecting FSM Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Reporting Coverage Metrics for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Viewing FSM Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
FSM Coverage Metrics Available in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
Advanced Command Arguments for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Recognized FSM Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
FSM Recognition Info Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
FSM Coverage Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004

FSM Recognition
ModelSim recognizes VHDL and Verilog FSMs.

FSM Coverage
ModelSim recognizes FSMs in your design during the compilation stages prior to simulation.
The simulation stage collects coverage metrics about which states and transitions were used
while simulating the test bench with the DUT.
The following metrics are collected for FSMs:

• State Coverage Metric — determines how many FSM states have been reached during
simulation.
• Transition Coverage Metric — determines how many transitions have been exercised
in the simulation of the state machine.

ModelSim® SE User's Manual, v10.7 993

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Multi-State Transitions

• Multi-state transition coverage — tracks the various possible sequences of transitions

that have been exercised in the simulation of the state machine. This is also referred to as
Sequence coverage.
Related Topics
Collecting FSM Coverage Metrics
FSM Coverage Metrics Available in the GUI
Code Coverage
Coverage Aggregation in the Structure Window

FSM Multi-State Transitions

A multi-state transition is also known as a state sequence.

Collecting FSM Coverage Metrics

You can enable the recognition and collection of coverage metrics for FSMs in your design
through the use of command arguments in your simulation flow.
Procedure
1. Evaluate the commands and switches in Table 20-1 to determine which are required for
your flow.

Table 20-1. Commands Used for FSM Coverage Collection

Task Command/Switch Required
Enable the collection of FSM coverage vcom or vlog with Yes2
metrics for individual design units. +cover=f1
Enable the collection of FSM coverage vopt with +cover=f1 Yes2
metrics for the complete design.
Produce a detailed report in the vcom, vlog, or vopt No
transcript for each recognized FSM. with -fsmverbose
Enable the reporting and collection of vcom, vlog, or vopt No
coverage metrics for FSM Multi-State with -fsmmultitrans
Transitions
Collect coverage metrics for the design vsim with -coverage Yes
under simulation.
1. You can also user +cover with no arguments, which enables collection of all coverage
metrics.
2. You must specify +cover=f at some point in the procedure with vcom or vlog or vopt.

994 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
Reporting Coverage Metrics for FSMs

2. Compile your design units with vcom or vlog.

Include any switches from Table 20-1 in addition to any other command arguments
required for your design and environment.
3. Optimize your design with vopt.
Include any switches from Table 20-1 in addition to any other command arguments
required for your design and environment.
4. Load your simulation using the -coverage switch with the vsim command. The
-coverage switch is required.
5. Run your simulation with the run command.
Results
Related Topics
FSM Recognition
FSM Coverage
Code Coverage
Code Coverage in the Graphic Interface
FSM Coverage Exclusions

Reporting Coverage Metrics for FSMs

You can use the GUI or coverage report command to create a text report of coverage metrics for
FSMs in your design.
Prerequisites
• Run a simulation to collect coverage metrics for FSMs.
• (Optional) Exclude transitions or states from coverage collection. This will allow you to
reach 100% FSM coverage. Refer to the section “FSM Coverage Exclusions” for more
information.
Procedure
1. Select Tools > Coverage Report > Text.
Displays the Coverage Text Report dialog box.
2. From the “Report on” drop down menu, select one of the following:
• All files — reports data for FSMs for all design units defined in each file. (-byfile
switch with coverage report)

ModelSim® SE User's Manual, v10.7 995

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
Viewing FSM Information in the GUI

• All instances — reports data for all FSMs in each instance, merged together.
(-byinst with coverage report)
• All design unit — reports data for all FSMs in all instances of each design unit,
merged together. (-bydu with coverage report)
3. In the Coverage Type pane, ensure that Fsms is selected. (-code f with coverage report)
4. Alter any of the other options as needed.
5. Click OK
Results
• Writes the report (report.txt) to the current working directory.
• Opens a notepad window containing the report.txt file.

Note
The “open in” field of the Coverage Text Report dialog box enables you to view
your results in Notepad, in the Source viewer, or in an editor you define with the
EDITOR environment variable. See Setting Environment Variables.

Related Topics
coverage report [ModelSim SE Command Reference Manual]
FSM Coverage
FSM Coverage Metrics Available in the GUI
Code Coverage
The Generation of Coverage Reports
Coverage Reports

Viewing FSM Information in the GUI

You can enable the creation of debug information for FSMs in your design through the use of
command arguments in your simulation flow.
Prerequisites
• Invoke ModelSim in GUI mode.

996 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
Viewing FSM Information in the GUI

Procedure
1. Evaluate the commands and switches in Table 20-2 to determine which are required for
your flow.

Table 20-2. Commands Used to Capture FSM Debug Information

Task Command/Switch Required
Retain visibility of and capture vopt with +acc=f1 Yes
debugging information about FSMs
for the complete design.
Enable visualization of FSMs in the vsim with -fsmdebug Yes
GUI.
1. You can also specify +acc with no arguments, which retains visibility for most
design elements.

2. Compile your design units with vcom or vlog.

Include any switches from Table 20-1 in addition to other switches required for your
design and environment.
3. Optimize your design with vopt.
Include any switches from Table 20-1 in addition to other switches required for your
design and environment.
4. Load your simulation with vsim with the -fsmdebug option.
5. Select View > FSM List
Displays the FSM List Window, which lists all recognized finite state machines.
6. Double-click an FSM in the FSM List window.
Displays the FSM in an FSM Viewer Window.
7. Add an FSM to the Wave window:
a. Right-click an FSM from the FSM List window
b. Select Add to Wave > Selected FSM
The FSM is automatically displayed in the Wave window as a group of signals with
the label: FSM (<current_state>). You can change the name of the group through
the FSM Display Options dialog (FSM List > Options)
The FSM Viewer and the Wave window are dynamically linked, allowing you to
analyze states and their transitions, based on your cursor position.
8. Run your simulation with the run command.
9. Rearrange the GUI so can see both the FSM Viewer and Wave windows simultaneously.

ModelSim® SE User's Manual, v10.7 997

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Coverage Metrics Available in the GUI

10. Link the FSM Viewer window to the cursor of the Wave window:
a. Select FSM View > Track Wave Cursor
b. View how states change by moving the cursor in the wave window, either by
dragging the cursor left and right or by using the Find Previous/Next Transition
buttons in the Wave Cursor toolbar.
Green indicates current state and yellow the previous state for the cursor location.
Related Topics
FSM Recognition

FSM Coverage Metrics Available in the GUI

The GUI presents coverage metrics in several windows within the GUI. This section provides
an overview of where you can find this information.
• Missed FSMs window — lists states and transitions that have not been fully covered
during simulation.
Transitions are listed under states, and source line numbers for each transition are listed
under their respective transitions.
You must select a design unit from the Structure window that contains a state machine
before anything will appear in this window
The icon that appears next to the state variable name is also a button , which opens
the FSM in the FSM Viewer Window. (Refer to the GUI Reference Manual for more
information on the FSM Viewer Window.)
The Missed FSMs window is linked to several windows:
o When you double-click a state or transition, the FSM will open in an FSM Viewer
window.
o When you select a state or transition, it will be highlighted in the Coverage Details
window.
o When you select the source line number for the transition, a Source window will
open and display the line number you have selected.
• Coverage Details window — provides detailed coverage information about any FSM
item selected in the Missed FSMs window.
• Columned windows — provide FSM coverage metrics in the Structure, Files, Objects
and Instance Coverage windows, as indicated in Table 20-3.

998 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
Advanced Command Arguments for FSMs

Table 20-3. FSM Coverage Columns

Column Structure Files Objects Instance Information
Window Window Window Coverage
Window
State % X X X state hits divided by states
State Graph X X X displays a green bar when
90% or greater, otherwise the
bar is red
States Hit X X X X
States X X X
Missed
States X X X
Transition % X X X transition hits divided by
transitions
Transition X X X displays a green bar when
Graph 90% or greater, otherwise the
bar is red
Transitions X X X
Hit
Transitions X X X
Missed
Transitions X X

Related Topics
FSM Coverage
Code Coverage
Code Coverage in the Graphic Interface

Advanced Command Arguments for FSMs

Multiple command arguments are available for FSM management.
Table 20-4 lists ModelSim command arguments related to FSM recognition and their
consolidated syntax literals.

ModelSim® SE User's Manual, v10.7 999

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
Advanced Command Arguments for FSMs

Table 20-4. Additional FSM-Related Arguments

Command Argument Description Literal
vcom vlog -fsmimplicittrans Controls recognition of implied same-state i
vopt transitions.
-fsmresettrans Controls recognition of implicit r
-nofsmresettrans asynchronous reset transitions.

-fsmsingle Controls recognition of FSMs having a s

-nofsmsingle single-bit current-state variable.

-fsmxassign Controls recognition of FSMs containing an x

-nofsmxassign X assignment.

-fsmmultitrans Controls detection and reporting of multi- m

state transitions.

Consolidated FSM Recognition Arguments

You can use any combination of the FSM arguments.

These arguments (see Table 20-4) can be used in a consolidated form:

-fsm=[imrsx]

Any of the FSM arguments can be negated by prefixing its literal with “-”, for example:

-fsm=-r-xs

This example would disable recognition of implicit asynchronous reset transitions and FSMs
containing an X assignment, and enable recognition of FSMs having single-bit current-state
variable.

Related Topics
Collecting FSM Coverage Metrics
Viewing FSM Information in the GUI

1000 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
Recognized FSM Note

Recognized FSM Note

Output from: vlog/vcom/vopt
Note ID: vlog-143, vcom-143, vopt-143
The vcom/vlog/vopt commands write a note to the transcript whenever they recognize an FSM.
Format
** Note: (<command>-143) Recognized <n> FSM in module "<module>".

Parameters
Table 20-5 defines the replaceable values from the Recognized FSM note.
Table 20-5. Recognized FSM Note Parameters
Keyword Description
<command> Specifies the command (vlog, vcom, vopt) that issued the
Note.
<n> Specifies the number of FSMs recognized in the module.
<module> Specifies the name of the module.

Examples
# ** Note: (vlog-143) Recognized 1 FSM in module "decode_top".
# ** Note: (vlog-143) Recognized 1 FSM in module "psi_coder".

ModelSim® SE User's Manual, v10.7 1001

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Recognition Info Note

FSM Recognition Info Note

Output from: vlog/vcom/vopt with the -fsmverbose switch
Note ID: vlog-1947, vcom-1947, vopt-1947
The vcom/vlog/vopt commands write a note to the transcript for every recognized FSM when
you use the -fsmverbose switch.
Format
** Note: (vlog-1947) FSM RECOGNITION INFO
...
...

See Example section for more detail.

Parameters
The following table defines the information in the FSM Recognition Info note.
Table 20-6. FSM Recognition Info Note Parameters
Keyword Description
FSM recognized in Specifies the module containing the FSM.
Current State Variable Specifies the name, file, and line number of the current
state variable.
Next State Variable Specifies the name, file, and line number of the next state
variable.
Clock Specifies the name of the clock controlling the FSM
Reset States Specifies the reset states of the FSM
State Set Specifies the complete list of state names in the FSM.
Transition table Lists all possible state transitions and any related line
numbers.
Multi-state Transition table1 Lists all possible multi-state transitions.
INFO Provides additional information about the FSM, such as:
• identifying unreachable states.
• identifying which states have no transitions, other than
to a reset state.
• identifying RTL code that will never be executed.
1. This section appears only when you specify -fsmmultitrans

1002 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
FSM Recognition Info Note

Examples
# ** Note: (vlog-1947) FSM RECOGNITION INFO
:# Fsm recognized in : decode_top
:# Current State Variable : present_state : ./rice_src/sysv/decode_top.sv(19)
:# Next State Variable : next_state : ./rice_src/sysv/decode_top.sv(19)
# Clock : pins.clk
# Reset States are: { S0 , XXX }
# State Set is : { S0 , S1 , XXX }
# Transition table is
# -------------------------------------------
# S0 => S1 Line : (32 => 34)
# S0 => S0 Line : (24 => 24)
# S0 => XXX Line : (30 => 30)
# S1 => S0 Line : (36 => 38) (24 => 24)
# S1 => XXX Line : (30 => 30)
# XXX => S0 Line : (24 => 24) (42 => 42)
# XXX => XXX Line : (30 => 30)
# -------------------------------------------
# Multi-state transition table is
# -------------------------------------------
# S0 => S1 => S0 (Loop)
# S0 => S1 => XXX
# S0 => S1 => XXX => S0 (Loop)
# S0 => XXX => S0 (Loop)
# S1 => S0 => S1 (Loop)
# S1 => S0 => XXX
# S1 => XXX => S0
# S1 => XXX => S0 => S1 (Loop)
# XXX => S0 => S1
# XXX => S0 => S1 => XXX (Loop)
# XXX => S0 => XXX (Loop)
# -------------------------------------------

ModelSim® SE User's Manual, v10.7 1003

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Coverage Text Report

FSM Coverage Text Report

To generate report: Tools > Coverage Report > Text or
coverage report -code f -details
FSM coverage reports are useful for examining your FSM coverage.
This report contains available coverage metrics for the FSMs in your design.

Format
# Coverage Report by file with details
:#
:# File: <file.vhdl>
# FSM Coverage:
# Enabled Coverage Active Hits % Covered
# ---------------- ------ ---- ---------
# States 3 3 100.0
# Transitions 13 10 76.9
...
...

See Example section for more detailed example of file.

Parameters
• The FSM Coverage Report contains the following sections:
o Header — specifies whether the report was generated by file (-byfile), instance
(-byinstance), or design unit (-bydu).
o FSM Coverage — coverage metrics for States and Transitions
o FSM_ID — the name of the current state variable.
o State Value MapInfo — a mapping of the state names to internal values.
o Covered States — coverage metrics for each state
o Covered Transitions — coverage metrics for each transition, including multi-state
transitions if you use the -fsmmultitrans switch.
o Uncovered Transitions — a list of all transitions that have no coverage metrics.
o Summary — the same information as the FSM Coverage table at the top of the
report.
Examples
This examples shows an FSM coverage report, where the metrics are reported by file.

1004 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
FSM Coverage Text Report

# Coverage Report by file with details

#
# File: test.vhdl
# FSM Coverage:
# Enabled Coverage Active Hits % Covered
# ---------------- ------ ---- ---------
# States 3 3 100.0
# Transitions 13 10 76.9
#
# ================================FSM Details================================
#
# FSM Coverage for file test.vhdl --
#
# FSM_ID: cst
# Current State Object : cst
# ----------------------
# State Value MapInfo :
# ---------------------
# State Name Value
# ---------- -----
# s0 0
# s1 1
# s2 2
# Covered States :
# ----------------
# State Hit_count
# ----- ---------
# s0 20
# s1 16
# s2 16
# Covered Transitions :
# ---------------------
# Trans_ID Transition Hit_count
# -------- ---------- ---------
# 0 s0 -> s1 16
# 1 s0 -> s0 2
# 2 s1 -> s2 16
# 4 s2 -> s0 16
# 5 s0->s1->s2 16
# 7 s1->s2->s0 16
# 9 s2->s0->s1 14
# 10 s0->s1->s2->s0 16
# 11 s1->s2->s0->s1 14
# 12 s2->s0->s1->s2 14
# Uncovered Transitions :
# -----------------------
# Trans_ID Transition
# -------- ----------
# 3 s1 -> s0
# 6 s0->s1->s0
# 8 s1->s0->s1
#
#
# Summary Active Hits % Covered
# ------- ------ ---- ---------
# States 3 3 100.0
# Transitions 13 10 76.9

ModelSim® SE User's Manual, v10.7 1005

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Coverage Text Report

1006 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 21
Verification with Assertions and Cover
Directives

This chapter discusses methods for using VHDL, PSL, and SystemVerilog assertions and cover
directives for design verification with ModelSim. It is organized into four sections.
• Overview of Assertions and Cover Directives
• Using PSL Assertions and Cover Directives
• Using SVA Assertions and Cover Directives
• Using -assertdebug to Debug with Assertions and Cover Directives
ModelSim implements assertion verification capabilities via assert, cover, and assume
directives. In the discussions that follow, the term “assertion” is used to indicate both assertion
properties and verification directives unless otherwise noted.

ModelSim supports the simple subset of PSL constructs and semantics as described in the IEEE
Std 1850-2005, IEEE Standard for Property Specific Language (PSL). Also, the following
formal types are supported: bit, bitvector, boolean, numeric, string, and hdltype.

ModelSim supports the Questa Verification IP verification components.

Note
The functionality described in this chapter requires an additional license feature for
ModelSim SE. Refer to “License Feature Names” in the Installation and Licensing Guide
for more information, or contact your Mentor Graphics sales representative.

Refer to <install_dir>/docs/technotes/sysvlog.note for a list of supported SystemVerilog

features.

We strongly encourage you to obtain and refer to a copy of the IEEE Std 1850-2005 for PSL as
well as the IEEE Std 1800-2009 for SystemVerilog.

Overview of Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008

Using PSL Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Using SVA Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Using -assertdebug to Debug with Assertions and Cover Directives . . . . . . . . . . . . . . . 1067

ModelSim® SE User's Manual, v10.7 1007

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Overview of Assertions and Cover Directives

Overview of Assertions and Cover Directives

The use of assertions and cover directives falls into the category of “white box” testing – they
specify and validate the expected behavior of a design. Assertions and cover directives are
written directly into the design in order to observe the values of signals and states, possibly over
a span of time. This allows the verification tool to observe (and log) when particular events
occur or assumptions are violated.
In SystemVerilog, two types of assertions are defined – immediate and concurrent. ModelSim
supports both assertion types.

• Immediate assertions evaluate immediately and may be inserted in any procedural

code. They can be specified anywhere a procedural statement can be specified and are
executed like a statement in a procedural block.
• Concurrent assertions describe behavior that spans time and, therefore, can be used for
checking temporal properties. Unlike immediate assertions, the evaluation model is
based on a clock — that is, a concurrent assertion is evaluated only at the occurrence of
a clock tick.
Cover directives, like concurrent assertions, are temporal - they are evaluated on specified clock
edges over a span of time.

The crucial difference between an assertion and a cover directive is that the assertion declares
that something must always hold. What is of interest is the assertion failure, which is a design
bug (or perhaps an assertion bug.) A cover directive declares that something should occur
sometimes. What is of interest is the cover success, which is a measure of coverage.
Furthermore, it is interesting to count how many times the cover success occurred. A cover
directive in PSL or a cover statement in SystemVerilog is a form of functional coverage: user-
defined coverage.

For more on functional coverage in general, see “Verification with Functional Coverage”.

For information on how assertion and cover directives and participate in the total coverage
aggregation, see “Coverage Aggregation in the Structure Window”.

Assertion Coding Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009

Processing Assume Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Configuring Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Simulating Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Analyzing Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031

1008 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Assertion Coding Guidelines

Assertion Coding Guidelines

Writing assertions, like writing RTL code, requires knowledge of which constructs are more
efficient than others in terms of how they affect simulation performance. This section provides a
few key guidelines that will help you improve simulation throughput, as well as a few key
things you should avoid.
We assume a basic understanding of assertion terminology, sequence operators, and syntax. The
coding examples in the guidelines below are written in SystemVerilog but the concepts apply
equally to PSL.

1. Keep directives simple. Create named assertions that you then reference from the assert
directive (for example, assert check1).
2. Keep properties and sequences simple too. Build complex assertions out of simple, short
assertions/sequences.
3. Whenever possible, reference a single clock. Properties referencing multiple clocks
require far more simulation time than properties referencing a single clock.
4. Do not use implication with never directives. You will rarely get what you want if you
use implication with a never.
5. Create named sequences so you can reuse them in multiple assertions.
6. Be aware of “unexpected matches.” For example, the following PSL assertion:
assert always a->next(b->next(c));

will match all of the following conditions (as well as others):

Figure 21-1. Assertion Matches

7. Avoid long or infinite time ranges. For example, if there is an effective timeout in a
sequence, make the time range for the timeout as short as possible given the overall
functional/timing requirements of the design. Using an infinite time range in an
assertion means that it is never able to fail.

ModelSim® SE User's Manual, v10.7 1009

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Assertion Coding Guidelines

Take the example of a simple handshake protocol which requires an acknowledgment

for every ready indication:
property handshake_check;
always @(posedge clk) rdy |-> ##[1:$] acpt ##1 !acpt;
endproperty
assert property(handshake_check);

A much more simulation-efficient way of expressing the concept of eventually in an

assertion is to use the goto operator as follows:
property handshake_check;
always @(posedge clk) rdy |-> acpt[->1] ##1 !acpt;
endproperty
assert property(handshake_check);

Within a sequence, the use of large or unbounded time range can severely impact
simulation performance. The reason for this is that a separate thread is spawned for each
possibility in the legal range. For example, the sequence,
(a ##1 b[*1 to 8000] ##5 c ##1 d)

can result in 8000 separate threads of the form:

(a ##1 b[*1] ##5 c ##1 d);
(a ##1 b[*2] ##5 c ##1 d);
...
(a ##1 b[*8000] ##5 c ##1 d);

8. Use system functions like $rose and $fell to avoid inadvertently spawning a new thread
or several new threads each cycle. In the line below,
(!a[*0:$] ##1 a) |-> b;

a thread will be started at every clock edge to check if a is not true. A better way to write
this is:
$rose(a) |-> b;

9. Use a qualifying condition when repetitively checking ([->n]) for multiple occurrences
of a condition in the antecedent expression of an assertion. Often, writing assertions
involves the need to check for multiple occurrences of an expression to trigger when
additional expressions are evaluated. In the examples below, the intent is to check for 48
occurrences (non-consecutive) of signal a; and on the 48th time signal a is true, signal b
is also required to be true.
a[->48] |-> b;

When re-written in its equivalent form below, the above property is extremely expensive
in terms of spawning new threads. Since a brand new thread is started each and every
cycle signal a is not true, threads grow at an nearly an exponential rate. And previously
started threads, in turn, spawn new threads each subsequent cycle due the unbounded
time range when signal a is false.

1010 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Assertion Coding Guidelines

(!a[*0:$] ##1 a)[*48] |-> b;

10. In general, be very careful when using the non-consecutive ([=n]) operator, but
especially on the left-hand side of an implication. Consider the property:
property p3;
@(posedge clk) a ##1 d[=2] ##1 c |-> ##1 e;
endproperty
assert property (p3);

It is easy to incorrectly interpret this property as a followed by 2 non-consecutive

occurrences of d followed at least 1 cycle later by c; which is then followed one cycle by
e, at which time the property should pass. However, as written, the property allows for
both c and e to assert after the second occurrence of d but not pass until the third
occurrence of d which could be sometime after e. This is completely unexpected
behavior, causing many to assume an assertion bug has been found. However the
behavior is correct because d[=2] is equivalent to (d[*1:$] ##1 d)[*2] ##1 d[*1:$]. It is
the last d[*1:$] which keeps a thread from the left-hand side (LHS) of the implication
alive until the third occurrence of d. In order for a property with implication to pass, all
threads started from both the LHS and right-hand side (RHS) of the implication must
complete. In this example the threads from the LHS do not complete until signal d
occurs a third time, even if all threads from the RHS have already completed. To avoid
this behavior the d[=2] can be replaced by d[->2] to get the intended behavior.
11. Specify behaviors accurately. Take the SVA sequence below:
sequence easy;
always @(posedge clk) a ##1 b ##1 c;
endsequence

This sequence named easy appears to be straight-forward, and it is. It states that a is
followed by b which is followed by c (all with delay of a single cycle/clock). However,
if the correct behavior requires a and b signals to either remain asserted or to de-assert in
the next cycle, then this simple sequence will not check for the expected behavior. The
following modifications will:
a ##1 a & b ##1 a & b & c;

Or, depending on expected behavior:

a ##1 !a & b ##1 !a & ! b & c;

Another example: If a sequence is needed that says a happens at a clock edge followed
by b in 4 to 8 clock cycles followed by c, it can be written as:
sequence s1;
always @(posedge clk) a ##[4:8]b ##1 c;
endsequence

This accurately represents the above requirement. In most cases, however, the
requirement is: when a asserts, it is to be followed by b asserting in 4 to 8 clock cycles;

ModelSim® SE User's Manual, v10.7 1011

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Assertion Coding Guidelines

and the first time b asserts within the [4:8] cycle range it should be followed by c. This is
represented by:
sequence s2;
always @(posedge clk) a ##1 !b[*3:7] ##1 b ##1 c;
endsequence

The difference between sequences s1 and s2 is that in s2, c has to follow the first
occurrence of b in [*4:8] range whereas in seq1, c can follow any occurrence of b in
[*4:8]. In most cases the requirement is that of s2.
12. This is an example of a badly written cover sequence:
cover sequence (@(posedge clk)
dll_state == DL_INACTIVE [*1:$] ##1 dll_state == DL_INIT [*1:$]
##1 dll_state == DL_ACTIVE);

A thread will be started at every clock edge as long as the dll_state is DL_INACTIVE
which really makes no sense. A better way to write this is to use the cover property
statement:
cover property (@(posedge clk)
$changed(dll_state) |->
$past(dll_state == DL_INACTIVE) ##0 dll_state == DL_INIT
[*1:$] ##1 dll_state == DL_ACTIVE;

13. Be careful what you do in an assertion pass statement. SV assertions have an action
block which contains an assertion pass statement as well as an assertion failure
statement. If an assertion has a pass statement, then the pass statement gets executed on
both real and vacuous passes. Unless you care about vacuous passes you should use the
assert control task $assertvacuousoff to turn off executing of pass action blocks for
vacuous passes.
14. Take into account reset conditions. You do not want to see false failures due to an
assertion failing because either the design is not yet initialized or that a reset occurs
during operation.
15. For local var usage please refer to: www.mentor.com/resources/techpubs/upload/
mentorpaper_35466.pdf
Using Assert Directive Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
SystemVerilog Bind Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013

Using Assert Directive Names

PSL 1.1 provides for named directives via the use of a label. You are not allowed to have a label
that duplicates another symbol in the same scope. In other words, you cannot explicitly label a
PSL directive with a name that already exists (as, say, a signal).

1012 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Processing Assume Directives

In the absence of a label, ModelSim generates assert directive names for reporting information
about assertions. For example:

property p0 is always a -> b;

assert p0;

The name generated for this assert directive will be assert__p0. Generically, the syntax of the
generated name is:

assert__<property name>.

However, if you write the same directive in this manner:

assert always a -> b;

there is no property name, so ModelSim will generate a name like assert__0 (that is, a number
appended to “assert__”).

SystemVerilog Bind Construct

The SystemVerilog bind construct allows you to bind a Verilog design unit to another Verilog
design unit, to a VHDL design unit, or to a SystemC module. This is especially useful for
binding SystemVerilog assertions to your VHDL, Verilog, SystemC and mixed designs during
verification.
Related Topics
The SystemVerilog bind Construct in Mixed-Language Designs

Processing Assume Directives

Designers use assume directives to constrain static verification. Because they are intended for
formal tools, assume directives have no meaning in simulation. However, by default, ModelSim
simulates assume directives as if they are assert directives and displays them in the Assertions
window.
You can configure how ModelSim processes assume directives using the -assume and
-noassume switches for the vsim command or the SimulateAssumeDirectives var
SimulateAssumeDirectives variable in the modelsim.ini file.

ModelSim® SE User's Manual, v10.7 1013

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

Configuring Assertions
The various tasks required to configure assertions may be invoked via the command line or the
GUI.
The GUI interface for configuring assertions is the Configure Assertions dialog, accessed via
the Assertions > Configure menu selection when the Assertions window is active
(Figure 21-2).

Figure 21-2. Configure Assertions Dialog

1014 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Configuring Assertions

Enabling Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015

Enabling Memory and Performance Profiling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Configuring Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Setting Break Severity for Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Enabling/Disabling Assertion Failure and Pass Logging . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Setting Assertion Failure Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Setting Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Changing the Default Configuration of Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . 1021
Other Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023

Enabling Assertions
You can enable assertions with a command or with a GUI selection.
Procedure
Do any of the following:

• Selecting “On” in the Enable section of the Configure Assertions dialog box
(Figure 21-2) to enable all assertions.
• Use the assertion enable command. The assertion enable command allows you to
turn on or off assertions of a specific language (SystemVerilog, PSL, VHDL) or type
(concurrent or immediate).
The default value of the AssertionEnable variable in the modelsim.ini file is on (‘1’),
enabling all VHDL, PSL, and SystemVerilog assertions. You can override this
variable by specifying:
assertion enable -off

• You may also enable assertions by right-clicking an assertion in the Assertions

window and selecting Enable from the popup menu (Figure 21-3). The selection
acts as a toggle.
Figure 21-3. Assertion Enable Menu Selection

ModelSim® SE User's Manual, v10.7 1015

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

This is the equivalent of selecting Assertions > Enable from the menus when the
Assertions window is active.

Enabling Memory and Performance Profiling Data

You can enable the collection of fine grained memory usage data for assertions and cover
directives. This feature can be used to quickly identify assertions and cover directives that
consume the most memory and also are performance intensive. It helps identify assertions and
cover directives that should be reviewed and rewritten in order to reduce the number of threads
for better performance.
Procedure
1. Do either of the following:
• Use the assertion profile on command. This command may be given at any time
during simulation.
The -threadthreshold argument for the assertion profile command can be used to
identify assertion/cover directive threads that are exploding in memory. The correct
syntax for the assertion profile command is:
assertion profile [-threadthreshold <number_of_threads>] on|off

The assertion profile command is independent of the -assertdebug argument for

the vsim command (which stores assertion pass/fail data in the .wlf file), so it can be
used even if vsim was not invoked with -assertdebug.
• You can also enable profiling in the Capacity window by right-clicking Assertions,
Cover Directives, or Covergroups and selecting Profile On from the popup menu
(Figure 21-4).
Figure 21-4. Selecting Profile On from Capacity Pane

2. Select View > Coverage > Assertions and View > Coverage > Cover Directives to
display memory and performance profile data in the Assertions and Cover Directives
windows.

1016 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Configuring Assertions

Three columns in the Assertions and Cover Directives windows display this fine grained
profile information: Current Memory, Peak Memory, and Cumulative (number of
threads).
Assertions that create the most threads take the most time to simulate. Therefore, this
information is not only useful for memory profiling but also helps in performance
profiling as well. The cumulative number of threads can help in scenarios where an
assertion creates many short lived threads.
Examples
Threads
In the following assertion,

assert property (@(posedge clk) a |=> b);

if 'a' is true throughout the simulation, the assertion will create a thread at every clock edge and
the thread will remain alive for exactly one clock cycle. This assertion may not be one of the
primary consumers of memory space but it will produce a high cumulative thread count.

Thresholds
The simulator will generate a message at every clock edge if the number of threads created by
an assertion or cover directive is more than the threshold. For example,

assert profile -threadthreshold 100

will write the following message to the Transcript window as the simulation runs when the
threshold of 100 threads is crossed:

# ** Note: Assertion thread threshold reached. Thread count = 110, Memory

= 4.8KB

# Time: 215 ns Scope: test.assert01 File: ./src/profile01.sv Line: 9

Note that this message is printed at every clock edge when the thread threshold is crossed. So if
the threshold is too low, it will cause deluge of messages in the Transcript.

Configuring Message Logging

You control message logging for SystemVerilog assertions via severity tasks ($fatal, $error,
$info, $warning) in an action block. You can determine which messages actually print in
ModelSim by changing variables in the modelsim.ini file or via the Runtime Options dialog.
Procedure
1. To set permanent defaults for message logging, edit the IgnoreSVAError,
IgnoreSVAFatal, IgnoreSVAInfo, and IgnoreSVAWarning variables in the modelsim.ini
file.

ModelSim® SE User's Manual, v10.7 1017

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

2. To edit the message logging for the current simulation run only, select Simulate >
Runtime Options and click the Message Severity tab in the Runtime Options dialog.
Check the appropriate box(es) under Verilog (Figure 21-5) and click OK.
Figure 21-5. Selecting Message Logging

Setting Break Severity for Assertions

By default, a severity level of Failure causes a simulation break. You can change this default
action permanently by editing a modelsim.ini variable, or you can edit the severity for the
current simulation only.
Procedure
1. To change this default permanently, edit the BreakOnAssertion variable in the
modelsim.ini file.
2. To edit the severity for the current simulation run only, select Simulate > Runtime
Options and click the Message Severity tab. Check the appropriate severity level
(Figure 21-6) and click OK.
Figure 21-6. Setting Immediate Assertion Break Severity

Enabling/Disabling Assertion Failure and Pass Logging

You enable or disable assertion failure and pass logging with commands, by editing the
appropriate modelsim.ini variables, or by using the GUI.
Procedure
Do any one of the following to enable or disable assertion failure and pass logging.

1018 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Configuring Assertions

• You can enable or disable failure and pass logging using the assertion fail or the
assertion pass commands, respectively.
• You can change the permanent defaults by setting the AssertionFailLog and
AssertionPassLog variables in the modelsim.ini file.
• To enable or disable an assertion’s failure or pass logging from the GUI, right-click
an assertion in the Assertions window and select Failure Log or Pass Log from the
popup menu (Figure 21-3). The selection acts as a toggle.
You can also select Assertions > Configure from the menu bar (or, right-click an
assertion and select Configure). This opens the Configure assertions dialog, where
you can enable/disable failure or pass logging.
Figure 21-7. Enabling/Disabling Failure or Pass Logging

Note
Assertion pass logging can be enabled only if the AssertionDebug variable in the
modelsim.ini file is on (set to 1), or if the -assertdebug argument is used with
the vsim command.

Setting Assertion Failure Limits

The assertion failure limit determines how many times ModelSim processes an assertion before
disabling it for the duration of the simulation. By default, the failure limit is set to “unlimited.”
In other words, assertions will not be disabled during the simulation. You can change the
permanent default by editing a modelsim.ini variable or by using the assertion fail command.
You may also set the assertion failure limit for the current simulation using the GUI.
Procedure
1. Change the default assertion failure limit with any one of the following:
• Set the AssertionLimit variable in the modelsim.ini file.
• Use the assertion fail command.
2. To set the assertion failure limit of the current simulation with the GUI, do either of the
following:
• Make the Assertions window active and select Assertions > Configure from the
menu bar.

ModelSim® SE User's Manual, v10.7 1019

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

• Right-click an assertion in the Assertions window and selecting Configure.

Either of these actions opens the Configure assertions dialog box where you can
change the limit for all assertions or for the selected assertion in the Limit section of the
dialog box (Figure 21-8).
Figure 21-8. Setting Assertion Failure Limits

The assertion count is not verified until the end of the current time stamp. If multiple
threads are active for a given property and if all of them fail at the same time, then all
fail messages are reported. You may see more fail messages than the limit you set.
ModelSim continues to respond to assertions if their limit has not been reached. The
limit applies to the entire simulation session and not to any single simulation run
command.
Examples
The following use of the assertion fail command

assertion fail -r / -limit 4 mydesign

sets the failure response limit to 4 for all assertions in mydesign. Each assertion failure will be
responded to a maximum of 4 times during the current simulation. The “-r /” argument indicates
that the assertion command should start at the root of mydesign and find all assertions.

Setting Assertion Actions

You can set the action that will take place during simulation when an assertion passes or fails,
when an assertion evaluation starts, and when an assertion antecedent is matched.
ModelSim can take any one of four actions:

• Continue — (default) No action taken. This is the default value if you do not specify this
switch.
• Break — Halt simulation and return to the ModelSim prompt.
• Exit — Halt simulation and exit ModelSim.
• TCL — Execute designated tcl subroutine.
You can set the assertion action with the assertion action command or in the GUI.

1020 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Configuring Assertions

Procedure
1. To set the action with the assertion action command, use the following syntax:
assertion action -exec [continue | break | exit | tcl_subroutine]

2. To set the action in the GUI, select Assertions > Configure from the menus when the
Assertions window is active, or right-click an assertion in the Assertions window and
select Configure. This will open the Configure Assertions dialog, where you can set the
assertion actions.
Figure 21-9. Set Assertion Actions

Changing the Default Configuration of Cover Directives

After compiling the design, you may want to edit the default configuration for individual cover
directives. Follow these steps to edit the default values.
Procedure
1. Select View > Coverage > Cover Directives to see your directives in the Cover
Directives window.
2. Make the Coverage Directives window active and select one or more cover directives.

ModelSim® SE User's Manual, v10.7 1021

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

3. Select Cover Directives > Configure in the menu bar, or right-click the selected cover
directive and select Configure Directive from the popup menu. This opens the
“Configure selected cover directives” dialog box (Figure 21-10).
Figure 21-10. Configure Selected Cover Directives Dialog

This dialog box allows you to enable/disable directive counting and logging, include/
exclude cover directives from coverage statistics calculations, set a weight for
directives, and specify a minimum number of times a directive should fire. You can also
set the action for coverage directive passes, starts, and antecedent matches.
You can choose from four different actions for cover directive passes, starts, and
antecedent matches:
• Continue — No action is taken.
• Break — Halt simulation and return to the Questa prompt.
• Exit — Halt simulation and exit Questa.
• TCL — Execute designated tcl subroutine.

1022 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Configuring Assertions

Other Configuration Considerations

When configuring cover directives, you may assign weights and set a minimum threshold of
coverage.
To improve runtime efficiency you can also limit the number of times your cover directives are
executed.

Weighting Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023

Choosing AtLeast Counts for Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Limiting Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024

Weighting Cover Directives

You can assign weights to cover directives. Weighting affects the aggregated coverage statistics
in the currently selected design region. A directive with a weight of 2 has twice the effect of a
directive with a weight of 1. Conversely, assigning a directive a weight of 0 would omit the
directive from the statistics calculation.
Weighting is a decision you make as to which cover points are more important than others
within the context of the design and the objectives of the test bench. You can change weighting
based on the simulation run so specific runs could be setup with different test bench objectives.
In this way, weighting is a good way of filtering how close the test bench is to achieving its
objectives.

For example, the likelihood that each type of bus transaction could be interrupted in a general
test is very low as interrupted transactions are normally rare. But you might want to ensure the
design handles the interrupt of all types of transactions and recovers properly from them. To
accomplish this, you can construct a test bench so the stimulus is constrained to ensure that all
types of transactions are generated and that the probability of transactions being interrupted is
relatively high. For that test bench, the weighting of the interrupted transaction cover points
would probably be higher than the weightings of uninterrupted transactions (or other coverage
criteria).

Related Topics
Coverage Aggregation in the Structure Window

Choosing AtLeast Counts for Cover Directives

The AtLeast count is a minimum threshold of coverage that gives you some confidence that the
run was meaningful. You do not need to set this threshold on every directive, but you should
understand which minimal thresholds make for a useful simulation run based on your design
and the objectives of the verification session.

ModelSim® SE User's Manual, v10.7 1023

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Configuring Assertions

For example, say your test bench requires a certain level of PCI traffic during the simulation. 30
PCI STOP transactions might be a proxy measure of sufficient PCI traffic, so you would set an
AtLeast count of 30 on the “PCI STOP” cover directive. Another example might be that a FIFO
full should have been achieved at least once as that would indicate that enough activity occurred
during the simulation to reach a key threshold. So, your “FIFO full” directive would get an
AtLeast count of 1.

Limiting Cover Directives

Cover directives that are evaluated frequently during simulation can adversely affect runtime
efficiency.
To improve runtime efficiency you can disable cover directives after a number of counts with
the Set Limit count to option in the Configure selected cover directives dialog box
(Figure 21-10), or with the -limit <count> argument for the fcover configure command.

For example,

fcover configure -limit 5 /top/refresh_during_rw

limits the evaluation of the refresh_during_rw cover directive to a count of 5 then disables it.
Once a cover directive is disabled, the assertion engine (which implements cover directives) no
longer makes a kernel call associated with that directive, thus improving simulation runtime
efficiency.

1024 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Simulating Assertions

Simulating Assertions
If any assertions were compiled, the vsim command automatically invokes the assertion engine.
If you do not want to simulate compiled assertions, use the -nopsl argument to ignore PSL
assertions or the -nosva to ignore SystemVerilog assertions. You can perform the same action
in the GUI by selecting Disable PSL and Disable SVA in the Others tab of the Start Simulation
dialog box when you load the design with the Simulate > Start Simulation menu selections.
If you want to have access to the details of assertion failures in the Assertion Debug pane of the
Wave window, use the -assertdebug argument with vsim. Alternatively, if you load the design
by choosing Simulate > Start Simulation from the main menu, you can also enable access by
selecting Enable assertion debug in the Others tab of the Start Simulation dialog box.

Note
The -assertdebug argument for vsim requires that you specify one of the following:

• vopt +acc=a
• vopt -assertdebug
• vsim -voptargs="+acc"

To invoke assertion thread viewing of specific assertions, use the -enable argument with the atv
log command after loading the design with vsim, and before the simulation is run.

Maintaining Assertion Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025

Maintaining Assertion Counts

The -assertcounts argument for vsim allows you to generate assertion counts without the
performance impact of using -assertdebug.
Note
The vsim -assertcounts argument was formerly named vsim -assertcover. The -assertcover
argument is still supported, but its use is deprecated (you should use vsim -assertcounts
instead).

The specific actions counted depends on whether the simulation is run with the -assertcounts or
the -assertdebug argument for vsim or without either option.

For example, consider the following SystemVerilog assertion:

assert property (@(posedge clk) disable iff (ignore) (b0 |=> b1 ##1 b2 ##1 b3));

ModelSim® SE User's Manual, v10.7 1025

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Simulating Assertions

The following sections describe what happens to the assertion counts for this assertion when
you run the simulation with the following vsim argument specifications:

• Without either -assertcounts or -assertdebug

• With -assertcounts
• With -assertdebug

Get Assertion Counts without Using -assertcounts or -assertdebug

When you run the simulation without specifying vsim -assertcounts or -assertdebug, the
Assertions window will show only Failure Count and Pass Count. Note that Pass Count in this
case only shows pass status (0: never passed; 1: passed any number of times).

The failure count for the assertion given above is 4, as shown in Figure 21-11.

Figure 21-11. Failure Counts in the Assertions Window

If the design has been compiled with the +acc=a option, you can view the assertion waveform in
the Wave window, as shown in Figure 21-12. The assertion failures are indicated in the Wave
window by red triangles.

Figure 21-12. Assertion Failures Indicated by Red Triangles

1026 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Simulating Assertions

Get Assertion Counts Using -assertcounts

Using vsim -assertcounts generates assertion counts on a fully optimized design without using
the +acc=a argument during compile, and without incurring the impact on performance that
occurs when you specify vsim -assertdebug.

When the simulation is run with the -assertcounts argument on the assertion property above, the
assertion in the Assertions Window contains a different column for each assertion count, as
shown in Figure 21-13.

Figure 21-13. Assertion Counts in the Assertions Window

• Attempt Count - 15 — The number of times the assertion was attempted, which
basically corresponds to the number of clock edges for the assertion.
• Failure Count - 4— The number of start attempts that resulted in failure.
• Vacuous Count - 3— The number of start attempts when the assertion passed vacuously.
• Pass Count - 1— The number of start attempts when the assertion passed.
• Disable Count - 4 — The number of start attempts that were disabled due to the disable
condition being TRUE.
• Active Count - 3— The number of start attempts that are currently active.
For these counts, note that:

Attempt = Failure + Vacuous + Pass + Disable + Active

To enable assertion coverage with the GUI:

1. Select Simulate > Start Simulation to open the Start Simulation dialog.
2. Open the Others tab.
3. In the Assertions section, select Enable assertion cover (Figure 21-14).

ModelSim® SE User's Manual, v10.7 1027

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Simulating Assertions

Figure 21-14. Enable Assertion Coverage

These assertion counts can also be enabled with the AssertionCover modelsim.ini variable.

Assertion Counts with -assertdebug

When simulation is run with -assertdebug, the assertion property is displayed in the Wave
window as shown in Figure 21-15.

Figure 21-15. Assertion Indicators When -assertdebug is Used

In addition to the red triangles used to denote assertion failures, the Wave window includes the
following assertion indicators when -assertdebug is used:

• blue square = start of assertion thread

• green triangle = assertion pass
• yellow triangle = antecedent match

1028 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Simulating Assertions

In addition, the Wave window includes the assertion’s ActiveCount, which is the number of
active assertion threads at the current time.

The Assertions Window contains a different column for each assertion count, as shown in
(Figure 21-13).

Figure 21-16. Counts Columns in Assertions Window

• Attempt Count - 15 — The number of times the assertion was attempted, which
basically corresponds to the number of clock edges for the assertion.
• Failure Count - 4 — The number of start attempts that resulted in failure. In this case, the
attempts that started at 750, 850, 950 and 1050 ns resulted in failures
• Vacuous Count - 3 — The number of start attempts when the assertion passed
vacuously. In this case, the start attempts whenever 'b0' was FALSE - at 50, 550, 650 ns.
• Pass Count - 1 — The number of start attempts when the assertion passed. In this case,
for the attempt that started at 1150 ns.
• Disable Count - 4 — The number of start attempts that were disabled due to the disable
condition being TRUE. In this case the attempts that started at 150, 250, 350 and 450 ns.
• Active Count - 3 — The number of start attempts that are currently active. In this case,
the attempts that started at 1250, 1350 and 1450 ns have not yet completed.
• Peak Active Count - 4 — This represent the maximum number of start attempts active at
any time.
For these counts, note that:

Attempt = Failure + Vacuous + Pass + Disable + Active

ModelSim® SE User's Manual, v10.7 1029

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Simulating Assertions

Note
Assertion Success is a term used to describe coverage statistics for assertions. Assertion
Successes are those assertions that have never failed and whose pass count does not equal
(or is greater than) zero.

1030 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Analyzing Assertions and Cover Directives

The following tasks can be used for analyzing assertions and cover directives:
Viewing Assertions in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Viewing Cover Directives in the Cover Directives Window . . . . . . . . . . . . . . . . . . . . . . 1032
Viewing Memory Profile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Viewing Assertions and Cover Directives in the Wave Window. . . . . . . . . . . . . . . . . . . 1034
Utilizing GUI Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Comparing Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Saving Metrics to the UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Excluding Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Creating Assertion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044

Viewing Assertions in the Assertions Window

The Assertions window displays simulation data about assertions.
Procedure
1. To open the Assertions window, select View > Coverage > Assertions from the menus.
2. Figure 21-17 shows SystemVerilog assertions in the Assertions window. SV assertions
are indicated by a light blue triangle. PSL assertions (not shown) are indicated by a
purple triangle.
Figure 21-17. SystemVerilog Assertions in the Assertions Window

3. The Assertions window lists all embedded and external assert directives that were
successfully compiled and simulated during the current session. The plus sign (’+’) to
the left of the Name field lets you expand the assertion hierarchy to show its elements
(properties, sequences, clocks, and HDL signals).

ModelSim® SE User's Manual, v10.7 1031

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

4. The Assertions window includes several columns for displaying information about
assertions. Refer to “Assertions Window” in the GUI Reference Manual for a
description of each field.
5. When assertions fire with failure messages, the Assertions window displays the name
and failure count in red, both during simulation and in post-simulation mode
(Figure 21-18).
Figure 21-18. Assertion Failures Appear in Red

6. You can use the assertion count command to return the sum of the assertion failure
counts for a specified set of assertion directive instances. This command returns a “No
matches” warning if the given path does not contain any assertions.
Related Topics
Assertions Window Display Options
Filtering Data in the Assertions and Cover Directives Window

Viewing Cover Directives in the Cover Directives Window

The Cover Directives window displays information about cover directives.
Procedure
1. To open the Cover Directives window, select View > Coverage > Cover Directives.
2. Figure 21-19 shows PSL cover directives in the Cover Directives window. PSL cover
directives are indicated by a purple chevron. SystemVerilog cover directives (not
shown) are indicated by a light blue chevron.

1032 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Figure 21-19. PSL Cover Directives in the Cover Directives Window

3. The Cover Directives window displays accumulated cover directive statistics at the
current simulation time, including percentages and a graph for each directive and
instance. The plus sign (’+’) to the left of the Name field lets you expand the directive
hierarchy to show its elements (properties, sequences, clocks, and HDL signals). Refer
to “Cover Directives Window” in the GUI Reference Manual for a description of each
column.
Related Topics
Display Options for Cover Directives
Filtering Data in the Assertions and Cover Directives Window

Viewing Memory Profile Data

The assertion profile command generates a fine grained profile of memory usage for assertions
and cover directives. The results are displayed in the Memory, Peak Memory, Peak Memory
Time, and Cumulative Threads columns of the Assertions and Cover Directives windows.
• The Memory column tracks the current memory used by the assertion or cover
directive.
• The Peak Memory column tracks the peak memory used by the assertion or cover
directive.
• The Peak Memory Time column indicates the simulation run time at which the peak
memory usage occurred.
• The Cumulative Threads column counts the cumulative thread count for the assertion.
While the Cumulative Threads count is not specifically about memory, it is designed to
highlight those assertions and cover directives that are starting too many attempts, such as the
following assertion:

assert property ((@posedge clk) a |=> b);

ModelSim® SE User's Manual, v10.7 1033

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

If ‘a’ is true throughout the simulation, then the above assertion will start a brand new attempt at
every clock. An attempt, once started, will only be alive until the next clock. So this assertion
will not appear abnormally high in the Memory and Peak Memory columns, but it will have a
high count in the Cumulative Threads column.

Viewing Assertions and Cover Directives in the Wave

Window
You can view assertions and cover directives in the Wave window just like any other signal in
your design.
Procedure
1. Use one of the following methods to add directives to the Wave window:
• To add all assertions in your design to the Wave window,
o Select a single object in the Assertions window, then select Add > To Wave >
Objects in Design from the main menus.
o Select all objects in the Assertions window, then select Add > To Wave >
Selected Objects from the main menus
o Right-click the selected assertions, then select Add Wave > Objects in Design
from the popup menu.
o Select all objects in the window, then click the Add Selected To Window button
in the Standard Toolbar . Refer to Standard Toolbar in the GUI Reference
Manual.
• To add all cover directives in your design to the Wave window:
o Select a single directive in the Cover Directives window, then select Add > To
Wave > Functional Coverage in Design from the main menus.
o Select all directives in the Cover Directives window, then select Add > To
Wave > Selected Functional Coverage from the main menus.
o Right-click the selected cover directives, then select Add Wave > Functional
Coverage in Design in Design from the popup menu.
o Select all directives in the window, then click the Add Selected To Window
button in the .

• To place a single assertion or cover directive in the Wave window:

o Drag the object from the its window and drop it into the Wave window, or
simply drop it onto the Wave tab if it is showing.
o Select the object, then click the Add Selected To Window button in the .

1034 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

o Select the object then select Add > To Wave > Selected Objects from the menu
bar.
• Right-click any selected assertion and select Add Wave > Selected Objects from
the popup menu; or right-click any selected cover directive and select Add Wave >
Selected Functional Coverage from the popup menu.
2. ModelSim represents assertions and cover directives as signals or waveforms in the
Wave window. The Wave window in Figure 21-20 shows several SystemVerilog
assertions and a single cover directive. SystemVerilog assertions are represented by
light blue triangles in the pathnames column. SystemVerilog cover directives are
represented by light blue chevrons.
Figure 21-20. SystemVerilog Assert and Cover Directives in the Wave Window

3. The Wave window in Figure 21-21 shows several PSL assertions and cover directives.
PSL assertions are represented by magenta triangles. PSL cover directives are
represented by magenta chevrons.

ModelSim® SE User's Manual, v10.7 1035

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Figure 21-21. PSL Assert and Cover Directives in the Wave Window

4. The name of each assertion and cover directive comes from the assertion code. The plus
sign (’+’) to the left of the name indicates that an assertion or cover directive is a
composite trace and can be expanded to show its elements (properties, sequences,
clocks, and HDL signals). Note that signals are flattened out; hierarchy is not preserved.
5. The value in the value pane is determined by the active cursor in the waveform pane.
The value will be one of ACTIVE, INACTIVE, PASS, FAIL, or ANTCDENT.
6. The waveform for an assertion or cover directive represents both continuous and
instantaneous information.
• Continuous information is either active or inactive. The directive is active anytime it
matches the first element in the directive. When active, the trace is green; when
inactive it is blue.
• Instantaneous information is represented as a start, pass, or fail event. A start event is
shown as a blue square. A green triangle represents a pass. And a red triangle
indicates a fail.
7. A yellow triangle represents an antecedent match (Figure 21-22). The yellow triangle is
displayed only if the directive is browseable and assertion debug is on (vsim -
assertdebug). The yellow triangle is shown for each thread of the assertion under
ActiveCount in the assertion (see Using the Assertion Active Thread Monitor). The
signal values of the assertion also reflect the antecedent match (ANTCDENT).

1036 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Figure 21-22. Antecedent Matches Indicated by Yellow Triangle

8. Table 21-1 summarizes the graphic elements for assertions and cover directives used in
the Wave and ATV windows (see Viewing Assertion Threads in the ATV Window):

Table 21-1. Graphic Elements for Assertions and Cover Directives

Graphic element Meaning
blue line assertion or cover directive is inactive
green line assertion or cover directive is active
blue square assertion or cover directive starts
green triangle assertion or cover directive passed
red triangle assertion or cover directive failed
yellow triangle antecedent match occurred in assertion

Related Topics
Displaying Cover Directives in Count Mode

ModelSim® SE User's Manual, v10.7 1037

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Utilizing GUI Display Options

ModelSim provides a number of GUI display options for viewing assertions and cover
directives data.
Assertions Window Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Display Options for Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Filtering Data in the Assertions and Cover Directives Window . . . . . . . . . . . . . . . . . . . 1039
Displaying Cover Directives in Count Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039

Assertions Window Display Options

The Assertions window can display assertion directives in hierarchical (tree) mode or in the
flattened form.
Figure 21-23. Hierarchy Display Mode

The hierarchical display mode can be enabled or disabled by doing any one of the following:

• When the Assertions window is docked, select Assertions > Display Options >
Hierarchy Mode from the Main menus.
• Right-click in the Assertions window and select Display Options > Hierarchy Mode
from the popup menu.
The Display Options menu also includes the following options:

• The Recursive Mode option displays all assertions at and below the selected hierarchy
instance, the selection being taken from a Structure window (that is, the sim tab).
Otherwise only items actually in that particular scope are shown.
• The Show All Contexts option displays all instances in the design. It does not following
the current context selection in a structure pane. The Show All Context display mode

1038 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

implies the recursive display mode as well, so the Recursive Mode selection is
automatically grayed out.
• The Show Concurrent Asserts option displays only concurrent assertions.
• The Show Immediate Asserts option displays only immediate assertions.

Display Options for Cover Directives

Display options allow you to display cover directives in a Recursive Mode or in a Show All
Contexts mode.
For details, refer to Changing the Cover Directives Window Display Options in the GUI
Reference Manual.

Filtering Data in the Assertions and Cover Directives Window

You can filter the Assertions and Cover Directives data displayed by selecting Assertions >
Filter > Setup or Cover Directives > Filter > Setup, depending on which window is active.
Related Topics
Filtering Functional Coverage Data

Displaying Cover Directives in Count Mode

You can change the coverage directive waveform in the Wave window so it displays in count
mode format, which shows the instantaneous waveform value as a decimal integer.
Procedure
1. To change to count-mode format, right-click a coverage waveform name and select
Cover Directive View > Count Mode.
Figure 21-24. Viewing Cover Directive Waveforms in Count Mode

ModelSim® SE User's Manual, v10.7 1039

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

2. Count mode can be useful for evaluating the effectiveness of stimulus over time. If all
cover directive counts are static for a long period of time, it may be that the stimulus is
acting in a wasteful manner and can be improved.

1040 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Comparing Assertions
ModelSim’s compare feature allows you to compare assertions (which includes any assertion-
like object such as concurrent and immediate assertions, cover directives, and endpoints.) There
is no cross-compare with assertion types outside the set listed, and assertion compare is further
limited to like types only. That is, both the reference and test items must be of the same type.
Comparing assertion signals differs from comparing normal HDL signals/ports because
assertion signals have two attributes:

• The current assertion state (ACTIVE | INACTIVE)

• The current assertion event (START | PASS | FAIL | EVAL)
Assertions expand to show child signals but these child signals do not participate in the compare
evaluation. Child signals are, however, visible in the compare waveforms when the you expand
compare assertions.

Setting Up the Assertions Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041

Two Types of Assertion Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Child Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042

Setting Up the Assertions Compare

You can set up and run an assertion compare using the compare commands or the menu-based
Waveform Comparison Wizard.
For example, a comparison using compare commands may look like the following:

add wave /top/assert_sig

run 1000 ns
dataset open vwim_test.wlf
compare start sim vsim_test
compare add sim:/top/assert_sig vsim_test:/top/assert_sig
compare run

All existing compare commands are supported for comparing assertion signals. Refer to the
Command Reference for syntax and command descriptions.

The Waveform Comparison Wizard will guide you through the selection of a reference dataset
and a test dataset. Assertions within those datasets are compared along with other signals. You
can start the Wizard is by selecting Tools > Waveform Compare > Comparison Wizard.

The Compare Signal

When two assertion signals are compared — for example, vsim_pass:/top/my_assertion_sig and
vsim_fail:/top/my_assertion_sig — a third virtual signal is created:

compare:/top/\my_assertion_sig<>my_assertion_sig\

ModelSim® SE User's Manual, v10.7 1041

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

The compare signal created is composed of the reference signal and the test signal. Differences
between the reference and text assertion signals are highlighted in red in the compare signal
when it is displayed in the Wave Window. Assertion differences cannot be viewed in the ATV
window.

Two Types of Assertion Differences

There are two types of assertion differences — instantaneous differences and range differences.
• Instantaneous difference — When the assertion event (START | PASS | FAIL | EVAL)
is different but the state of the assertion (ACTIVE | INACTIVE) is the same.
For example, considering two datasets vsim_top and vsim_ntop with an assertion signal
my_assertion_sig.
vsim_top:/top/my_assertion_sig is PASS_INACTIVE at 20 ns
vsim_ntop:/top/my_assertion_sig is FAIL_INACTIVE at 20ns
This is an instantaneous difference the difference will marked at time 20 ns and the
width of the difference marker will be equal to the width of the PASS/FAIL symbol.
• Range difference — When there is a state change (ACTIVE->INACTIVE) or vice-
versa, between the reference and test assertion, irrespective of the event on the
assertions.

Child Signals
An assertion object is composed of child signals. It is the evaluation of these child signals that
determine the assertion event (START/PASS/FAIL). If you choose to expand the assertion, the
difference marker is propagated to the child signals as well, but this may not necessarily mean a
change in value on the child signal at that specific time — the difference could have occurred
earlier.
If the reference signal has child signals but the test signal does not, or vice-versa, waveform
compare will still work because compare cares only about the absolute event on the assertion. If
there is a difference, it will be marked.

Saving Metrics to the UCDB

You can save assertion and cover directive metrics to the Unified Coverage Database (UCDB)
with the coverage save command.
Note
For easiest viewing and tracking of assertions and cover directives in the GUI and coverage
reports, it is recommended that you name all assertions and directives in the source files.

1042 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

When coverage save is used without switches and arguments, all assertion and cover directive
metrics are saved to the UCDB. For details, see Saving Assertion and Cover Directive Metrics.

Related Topics
Assertion/Cover Directive Naming Conventions

Excluding Assertions and Cover Directives

If the -code argument is not specified with the coverage exclude command, all assertions and
cover directives, as well as all code coverage types, will be excluded from the coverage
database.
To exclude assertions and cover directives from a loaded coverage database (.ucdb), use the
coverage exclude command options, as follows:

coverage exclude -assertpath <path_to_assert>

coverage exclude -dirpath <path_to_directive>

The coverage exclude -assertpath and -dirpath options are only operational in the Coverage
View mode. During active simulation, these command options have no effect. See coverage
exclude for full syntax details.

ModelSim® SE User's Manual, v10.7 1043

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Creating Assertion Reports

You can create reports on assertions and cover directives using dialogs accessible through the
GUI or via commands entered at the command line prompt. SVA immediate and concurrent
assertions, VHDL immediate assertions, and PSL assertions are all included in the assertion
report. The Assertion Type column in Assertions window distinguishes the immediate and
concurrent assertions.
Using the Assertions Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Specifying an Alternative Output File for Assertion Messages . . . . . . . . . . . . . . . . . . . . 1045

Using the Assertions Report Dialog

Use the Assertions report dialog to save an ASCII file of assertion coverage results.
Procedure
1. Right-click anywhere in the Assertions window and select Report from the popup
context menu. This opens the Assertions report dialog box (Figure 21-25).
2. Select the options you want to report.
3. Click the OK button.
Figure 21-25. Assertions Report Dialog

1044 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Analyzing Assertions and Cover Directives

Specifying an Alternative Output File for Assertion Messages

You can specify an alternative output file for recording assertion messages by invoking vsim
with the -assertfile <filename> switch. By default assertion messages are output to the file
specified by the TranscriptFile variable in the modelsim.ini file.
You can set a permanent default for the alternative output file using the AssertFile variable in
the modelsim.ini file.

Note
The output file defined by the -assertfile <filename> argument will also contain VHDL
assert messages.

Limitations
In some circumstances, processing cover directive will produce too many matches, causing the
cover count to be too high. The problem occurs with coverage of sequences like {{a;b} | {c;d}}
or {a[*1 to 2]; b[*1 to 2]}. In this instance, the same sequence for the same input at the same
start time may succeed simultaneously in multiple ways. The first sequence may succeed with a
and c followed on the next cycle by b and d; this satisfies both the simultaneous {a;b} and {c;d}
sequences. Logically, the evaluation should increment the count once and only once for a single
directive with a given set of inputs from a given start time, but the ModelSim implementation
will increment the count twice.

ModelSim® SE User's Manual, v10.7 1045

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Using PSL Assertions and Cover Directives

Using PSL Assertions and Cover Directives

The use of PSL assertions differs from the use SystemVerilog assertions because PSL assertions
can be embedded in your code or supplied in an external file, while SystemVerilog assertions
are always embedded in your code.
If PSL assertions are embedded, vlog/vcom will compile them automatically. If the assertions
are in a separate file, you must use the -pslfile argument with either the vlog or vcom command.

The usage flow for PSL assertions and cover directives is shown in Figure 21-26.

Figure 21-26. Usage Flow for PSL Assertions

When using optimization (vopt +acc), you may still specify assertions at compile time, but you
may also specify an external PSL file when you optimize your design with the vopt command.
Use the -pslfile_vl argument for PSL files that apply to Verilog modules and the -pslfile_vh
argument for PSL files that apply to VHDL modules.

1046 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Using PSL Directives in Procedural Blocks

There are several advantages to loading PSL files along with vopt:

• Rather than specifying a PSL file for every invocation of the compilers, you can put all
assertions in one file and specify that to vopt.
• Vunits can be bound to design unit instances only when provided to vopt using -
pslfile_vl/-pslfile_vh.
The vopt command maintains assertions that were compiled with vcom or vlog whether they
are embedded or external vunits.

Using PSL Directives in Procedural Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047

Common PSL Assertions Coding Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
Compiling and Simulating PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
PSL Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062

Using PSL Directives in Procedural Blocks

PSL directives (assert, cover, and so on) are supported in procedural blocks (always and
initial). These directives are treated as if they were written outside and no inferences are made
from the procedural blocks.

ModelSim® SE User's Manual, v10.7 1047

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Common PSL Assertions Coding Tasks

Common tasks associated with coding PSL assertions include embedding them in your code,
writing them to an external file, putting HDL code inside PSL statements, and others.
Embedding Assertions in Your Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
HDL Code Inside PSL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
Writing PSL Assertions in an External File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Sharing a Single .psl File Between VHDL and Verilog Models. . . . . . . . . . . . . . . . . . . . 1054
Inserting VHDL library and use Clauses in External PSL Assertion Files . . . . . . . . . . 1054
PSL Clocked and Unclocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Using PSL ended() in HDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057

Embedding Assertions in Your Code

One way of looking at assertions is as design documentation. In other words, anywhere you
would normally write a comment to capture pre-conditions, constraints or other assumptions as
well as to document the proper functionality of a module, process, or subprogram, use
assertions to capture the information instead.

PSL Syntax
PSL assertions are embedded using metacomments prefixed with 'psl'. For example:

-- psl sequence s0 is {b0; b1; b2};

The PSL statement can be multi-line. For example:

-- psl sequence s0 is
-- {b0; b1; b2};

Note that the second line did not require a 'psl' prefix. Once in PSL context, the parser will
remain there until a PSL statement is terminated with a semicolon (';').

Restrictions for PSL Embedded Assertions

Embedded assertions have the following restriction as to where they can be embedded:

• Assertions can be embedded anywhere inside a Verilog module, interface, program,

package, or compilation unit. They cannot be inside initial blocks, always blocks, tasks,
functions, or clocking blocks. They also cannot be embedded in UDPs.
• Assertions can be embedded only in declarative and statement regions of a VHDL entity
or architecture body and in VHDL packages. They cannot be embedded in VHDL
procedures and functions.

1048 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

• In a VHDL statement region, assertions can appear at places where concurrent

statements may appear. If they appear in a sequential statement, ModelSim will generate
an error.
• There is no support for a default clock in VHDL or Verilog packages.
• There is no support for directives in VHDL or Verilog packages.
• Endpoints must be parameterized and must have @clock specifications in VHDL or
Verilog packages.

Note
The endpoint construct is not part of the IEEE Std 1850-2005. However, it was
present in the original Accellera PSL standard upon which ModelSim’s PSL support
was based. Support of the endpoint construct will be maintained in ModelSim.

Examples
Example 11-1 shows how embedded assertions should appear in your code.

ModelSim® SE User's Manual, v10.7 1049

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Example 21-1. Embedding Assertions in Your Code

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use WORK.constants.all;
entity dram_control is
generic ( BUG : Boolean := TRUE );
port ( clk : IN std_logic;
reset_n : IN std_logic;
as_n : IN std_logic;
addr_in : IN std_logic_vector(AIN-1 downto 0);
addr_out: OUT std_logic_vector(AOUT-1 downto 0);
rw : IN std_logic; -- 1 to read; 0 to write
we_n : OUT std_logic;
ras_n : OUT std_logic;
cas_n : OUT std_logic;
ack : OUT std_logic );
end entity dram_control;

architecture RTL of dram_control is

type memory_state is (IDLE, MEM_ACCESS, SWITCH, RAS_CAS, OP_ACK, REF1,

REF2);
signal mem_state : memory_state := IDLE;

signal col_out : std_logic; -- Output column address

-- = 1 for column address
-- = 0 for row address

signal count : natural range 0 to 2; -- Cycle counter

signal ref_count : natural range 0 to REF_CNT; -- Refresh counter
signal refresh : std_logic; -- Refresh request

--psl default clock is rising_edge(clk);

-- Check the write cycle
-- psl property check_write is always {fell(as_n) and not rw} |=> {
-- [*0 to 5];
-- (ras_n = '0' and cas_n = '1' and (addr_out = addr_in(7 downto 4)));
-- (ras_n = '0' and cas_n = '1' and (addr_out = addr_in(3 downto
0)))[*2];
-- (ras_n = '0' and cas_n = '0')[*2];
-- ack};

--psl assert check_write;

begin
.

HDL Code Inside PSL Statements

Verilog and VHDL statements may be placed in either embedded PSL meta-comments or in
external vunits. When they are embedded in your code, you must use PSL block meta-comment
tags.

1050 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

For example, suppose you have a module called test with the following embedded PSL:

/* psl begin
default clock = (posedge clk);
A_E:assert always {b0} |=> b1;
always @(posedge clk)
$display($time, " TEST : posedge clk.");
end
*/

In addition, you have a vunit binding to test as follows:

vunit v2(test)
{
default clock = (posedge clk);
A_V:assert always {b0} |=> b1;
always @(posedge clk)
$display($time, " VUNIT : posedge clk.");}

The compiler(vlog/vcom) -nopsl argument disables any embedded PSL parsing. This will
prevent parsing of any code within the PSL metacomment including any HDL code in the
metacomment. It has no effect on the vunit parsing in any way. If you provide a vunit file using
the -pslfile argument then the entire vunit will be parsed and code will be generated for it.

If you simulate with the vsim -nopsl switch, evaluation of all PSL assume/assert/cover
directives and endpoints will be disabled. It will not, however, affect any HDL code which was
present in a PSL metacomment or in a vunit.

Four possible simulation scenarios (using the Verilog example files located at <install_dir>/
examples/psl/verilog/nopsl_switch) are as follows:

1. The -nopsl is not used during compile or simulation.

vlog doctest.v -pslfile doctest.psl
vsim -c test -do "run -all"

This will display the TEST and VUNIT messages and evaluate assertions A_V and
A_E.
2. The -nopsl argument is only used during simulation.
vlog doctest.v -pslfile doctest.psl
vsim -c test -do "run -all" -nopsl

This will display both the TEST and VUNIT messages.

3. The -nopsl argument is used only during compile.
vlog doctest.v -pslfile doctest.psl -nopsl
vsim -c test -do "run -all"

This will display only the VUNIT messages and evaluate assertion A_V.

ModelSim® SE User's Manual, v10.7 1051

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

4. The -nopsl argument is used during compile and simulation.

vlog doctest.v -pslfile doctest.psl -nopsl
vsim -c test -do "run -all" -nopsl

This will display only the VUNIT messages.

Writing PSL Assertions in an External File

PSL assertions in an external file are grouped into vunits.

Syntax
vunit name [(<HDL_design_unit>)]
{
default clock = <clock_decl>;
<assertions>;
...
}
name

The name of the vunit.

<HDL_design_unit>

The module or entity/architecture to which the vunit is bound.

Can also be a design unit instance if you are running the simulation without optimization (see
Using PSL Assertions and Cover Directives).

Optional.

If the design unit is unspecified the vunit does not bind to anything.

Unbound vunits may be "inherited" from other vunits using the PSL keyword inherit. This
option is available only if you are running the simulation with optimization. (See Using PSL
Assertions and Cover Directives).

<clock_decl>

The default clock declaration for the vunit.

<assertions>

Any number of verification directives or PSL statements.

Restrictions
The following restrictions exist when providing PSL assertions in a separate file.

1052 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

• Vunits can be bound only to a module, entity, or architecture.

Unless you are running the simulation without optimization (see Using PSL Assertions
and Cover Directives).
• The PSL file and its corresponding HDL file must be compiled together if you are
running the debug flow.
Examples
Example 11-2 shows how three assertions are written in one vunit using Verilog syntax.

Example 21-2. Writing Assertions in an External File

vunit check_dram_controller(dram_control)
{
default clock = rose(clk);

// declare refresh sequence

sequence refresh_sequence = {
!cas_n && ras_n && we_n; [*1];
(!cas_n && !ras_n && we_n)[*2];
cas_n && ras_n};

sequence signal_refresh = {[*24]; rose(refresh)};

property refresh_rate = always {rose(reset_n) || rose(refresh)} |=>

{signal_refresh};

assert refresh_rate;

property check_refresh = always ({rose(refresh)} |->

{(mem_state != IDLE)[*0:14]; (mem_state == IDLE); refresh_sequence}
abort fell(reset_n));

assert check_refresh;

// Check the write cycle

property check_write = always {fell(as_n) && !rw} |=> {
[*0:5];
(!ras_n && cas_n && (addr_out == addr_in[7:4]));
(!ras_n && cas_n && (addr_out == addr_in[3:0]))[*2];
(!ras_n && !cas_n)[*2];
ack};

assert check_write;

// check the read cycle

property check_read = always {fell(as_n) && rw} |=> {
[*0:5];
(!ras_n && cas_n && (addr_out == addr_in[7:4]));
(!ras_n && cas_n && (addr_out == addr_in[3:0]))[*2];
(!ras_n && !cas_n)[*3];
ack};

assert check_read;
}

ModelSim® SE User's Manual, v10.7 1053

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Sharing a Single .psl File Between VHDL and Verilog

Models
The ’ifdef VHDL_DEF and ’ifdef VLOG_DEF macros allow you to share a single .psl file
between VHDL and Verilog versions of a model. Use these macros inside the .psl file to bracket
vunits written in both VHDL and Verilog.
Internally ModelSim adds a `define VHDL_DEF or VLOG_DEF depending on how you read in
the .psl file — with vcom or with vlog. For example, if you read in the following file using vlog
-pslfile, ModelSim will ignore the first vunit and parse the second:

Internally ModelSim adds a `define VHDL_DEF or VLOG_DEF depending on how you read in
the .psl file — with vcom, vlog, or the -pslfile_vh/-pslfile_vl switches for vopt. For example, if
you read in the following file using vlog -pslfile or vopt -pslfile_vl, ModelSim will ignore the
first vunit and parse the second:

`ifdef VHDL_DEF
vunit v1 ( top(a) )
{
default clock is rose(clk);
property vh_clk is always (a and b);
assert vh_clk;
}
`endif

`ifdef VLOG_DEF
vunit v1 ( top )
{
default clock = rose(clk);
property vl_clk = always (a && b);
assert vl_clk;
}
`endif

Inserting VHDL library and use Clauses in External PSL

Assertion Files
You can insert VHDL library and use clauses directly in external PSL assertion files. This lets
you access packages such as Signal Spy even if the design unit (to which the vunit is attached)
does not reference the package.

1054 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Here is an example that shows the use of Signal Spy:

library modelsim_lib;
use modelsim_lib.util.all;

vunit top_vunit(test) {
signal vunit_local_sigA : bit := '0';
signal vunit_loc_sigB : bit := '0';

initial_proc: process
begin
--spy on a signal in a package
init_signal_driver("/pack/global_signal", "vunit_local_sigA");
--spy on a internal signal
init_signal_driver("/test/aa/internal_signal_AA",
"vunit_loc_sigB");
wait;
end process initial_proc;

assert (vunit_local_sigA -> vunit_loc_sigB);

}

Here are two points to keep in mind about library and use clauses in PSL files:

• If you already have the use clause applied to an entity, then you do not need to specify it
for the vunit. The vunit gets the entity's complete visibility.
• If you have two vunits in a file and the use clause at the top, the use clause will apply
only to the top vunit. If you want the use clause to apply to both vunits, you have to
specify it twice. This follows the rules for use clauses as they apply to VHDL entities.

ModelSim® SE User's Manual, v10.7 1055

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

PSL Clocked and Unclocked Properties

PSL assertions in ModelSim may be clocked or unclocked.
PSL Unclocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Default Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
PSL Partially Clocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
PSL Multi-Clocked Properties and the Default Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057

PSL Unclocked Properties

ModelSim supports unclocked properties of the following form:
• assert always <expr>
• assert never <expr>
• cover <expr>
If these directives appear before any default clocking statements, and they are not individually
clocked, then they are treated as unclocked. The <expr> is a simple boolean expression.

Default Clock
Any PSL assertion that is not individually clocked and appears below a default clock statement
will be clocked by the default clock.
For example:

default clock is rose(clk);

assert always sigb@rose(clk1)
assert always siga;

The first assertion is sensitive to clk1. The second assertion is sensitive to clk (the default clock).

PSL Partially Clocked Properties

The default clock also applies to partially clocked properties.
For example:

default clock is rose(clk);

assert always (b0 |-> (b1@rose(clk1)))

In this case, only the RHS of the implication(|->) expression is clocked. The outermost property
is unclocked, so default clock applies to this assertion.

1056 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Also, the complete assertion property, because it is not a simple expression, must be clocked.
For example, if you have the following assertion:

assert always (b0 |-> (b1@rose(clk1)))

and no default clock preceding it, then since part of the property is unclocked, ModelSim will
produce an error.

PSL Multi-Clocked Properties and the Default Clock

You need to be very careful when writing multi-clocked properties that also have a default
clock, or you may produce unexpected results.
For example, say you want to write a property that means the following: if signal a is true at
rose(clk1), then at the next rising edge of clk2, signal b should be true.

Write the property like this:

assert always (a -> b@rose(clk2)) @rose(clk1);

In this property, the @ operator has more precedence than the always operator, so the property
is interpreted like this:

assert always ((a -> b@rose(clk2)) @rose(clk1));

Note that the always operator is unclocked but the property under always is clocked. This is
acceptable because ModelSim detects that the property is to be checked at every rose(clk1).
Other Restrictions

The following are additional restrictions on clock declarations:

• There is no support for a default clock in VHDL packages.

Using PSL ended() in HDL Code

The PSL ended() construct is a built-in function whose value is set to TRUE for the simulation
time unit whenever its sequence is matched. HDL code can read the value of this builtin.
Note
The endpoint construct is not part of the IEEE Std1850-2005. However, it was present in the
original Accellera PSL standard upon which ModelSim’s PSL support was based. Support
of the endpoint construct will be maintained in ModelSim.

ModelSim® SE User's Manual, v10.7 1057

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Example 21-3 and Example 21-4 are two complete examples that demonstrate the use of
ended() in Verilog and VHDL code, respectively.

Example 21-3. Using PSL ended() in Verilog

module test;

reg clk;
initial clk = 0;
always #50 clk <= ~clk;

reg b1, b2;

// psl sequence s0(boolean b_f) = {b1[*2]; [*0:2]; b_f};

initial
begin
b1 <= 0; b2 <= 0;
#100; b1 <= 0; b2 <= 0; //100
#100; b1 <= 0; b2 <= 0; //200
#100; b1 <= 0; b2 <= 0; //300
#100; b1 <= 1; b2 <= 0; //400
#100; b1 <= 1; b2 <= 1; //500
#100; b1 <= 1; b2 <= 1; //600
#100; b1 <= 0; b2 <= 0; //700
#100; b1 <= 0; b2 <= 1; //800
#100; b1 <= 0; b2 <= 0; //900
#100; b1 <= 0; b2 <= 0; //1000
#100;
$finish;
end

always @(posedge clk)

begin
if (ended(s0(b2)) == 1)
$display($time, " Ended is true.");
end

always @(ended(s0(b2), posedge clk))

$display($time, " Ended triggered.");

endmodule

1058 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

Example 21-4. Using ended() in VHDL

use STD.textio.all;

entity test is
end test;

architecture a of test is
signal clk_0 : bit := '0';
signal clk_1 : bit := '0';
signal b1 : bit := '0';
signal b2 : bit := '0';
begin

clk_0 <= not clk_0 after 50 ns;

clk_1 <= not clk_1 after 75 ns;

-- psl begin
-- sequence s0(Boolean b_f) is {b1[*2]; [*0 to 2]; b_f};
-- sequence se0(Boolean clk_f) is {s0(b2)}@rose(clk_f);
-- end

endp_0 : process(clk_0)
variable test_val_0 : BOOLEAN;
variable vline : line;
begin
test_val_0 := ended(se0(clk_0));
write(vline, now);
write(vline, string'(": test_val_0 = "));
write(vline, test_val_0);
writeline(OUTPUT, vline);
end process;

endp_1 : process(clk_1)
variable test_val_1 : bit;
variable vline : line;
begin
if (ended(se0(clk_1)) = true) then
test_val_1 := '1';
else
test_val_1 := '0';
end if;
write(vline, now);
write(vline, string'(": test_val_1 = "));
write(vline, test_val_1);
writeline(OUTPUT, vline);
end process;

process
begin
wait for 400 ns; b1 <= '1'; b2 <= '0'; --400
wait for 100 ns; b1 <= '1'; b2 <= '1'; --500
wait for 200 ns; b1 <= '0'; b2 <= '0'; --700
wait for 100 ns; b1 <= '0'; b2 <= '1'; --800
wait for 100 ns; b1 <= '0'; b2 <= '0'; --900
wait for 300 ns; b1 <= '1'; b2 <= '1'; --1210
wait for 100 ns; b1 <= '1'; b2 <= '0'; --1300

ModelSim® SE User's Manual, v10.7 1059

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Common PSL Assertions Coding Tasks

wait for 300 ns; b1 <= '0'; b2 <= '1'; --1600

wait for 300 ns; b1 <= '1'; b2 <= '0'; --1900
wait for 200 ns; b1 <= '1'; b2 <= '1'; --2100
wait for 100 ns; b1 <= '0'; b2 <= '1'; --2200
wait for 100 ns; b1 <= '0'; b2 <= '0'; --2300
wait; -- infinite wait
end process;

end a;

Note
In VHDL, unused endpoints (defined but not used in the design) are optimized away during
compilation.

1060 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Compiling and Simulating PSL Assertions

Compiling and Simulating PSL Assertions

Common tasks for compiling and simulating PSL assertions in your design include compiling
embedded PSL assertions as well as external assertions files, applying the assertions during
elaboration and optimizations, simulating, and then making any needed changes.
Compiling Embedded PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Compiling an External PSL Assertions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Applying PSL Assertions During Elaboration/Optimization . . . . . . . . . . . . . . . . . . . . . 1061
Making Changes to PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062

Compiling Embedded PSL Assertions

Embedded PSL assertions are compiled automatically by default. If you have embedded PSL
assertions that you do not want to compile, use the -nopsl argument with the vlog or vcom
commands.

Compiling an External PSL Assertions File

To compile assertions in an external file, invoke the compiler with the -pslfile argument and
specify the assertions file name.
For example, in the following command:

vlog tadder.v adder.v -pslfile adder.psl

the adder.psl file is compiled by means of the -pslfile switch.

The design and its associated assertions file must be compiled in the same invocation.

Applying PSL Assertions During Elaboration/

Optimization
You can also specify an external PSL vunit file with the -pslfile_vh or -pslfile_vl switches for
the vopt command.
For example:

vopt testbench -o mydesign -pslfile_vl tb.psl

See Using PSL Assertions and Cover Directives for more information.

ModelSim® SE User's Manual, v10.7 1061

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
PSL Limitations

Making Changes to PSL Assertions

If you make any changes to embedded assertions, you need to re-compile the design unit. If you
make changes to an external PSL assertions file, you need to compile both the external PSL file
and the design unit file to which the vunit binds in the same vlog/vcom invocation.

PSL Limitations
ModelSim supports the simple subset of PSL constructs and semantics as described in the IEEE
Std 1850-2005, except the following:
• next(), nondet, and nondet_vector() built-in functions
• Union expressions
• OBE properties
• assume_guarantee, restrict, restrict_guarantee, fairness and strong fairness directives
• Integer Range and Structure
The current release also has the following limitations.

• Vunits can be bound to design unit instances only when provided to vopt using -
pslfile_vl/-pslfile_vh.
• Level-sensitive clock expressions are not allowed.
• There is no support for integer, structures, and union in the modeling layer.
• There is no support for post-simulation run of assertions (that is, users cannot run the
assertion engine in post-simulation mode).

1062 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Using SVA Assertions and Cover Directives

Using SVA Assertions and Cover Directives

The following important concepts are important for understanding how to use SVA assertions
and cover directives.
Assertions and Action Blocks in SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Deferred Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
SystemVerilog Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
SVA Usage Flow for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064

Assertions and Action Blocks in SVA

Action blocks may contain immediate assertion statements.
Immediate assertions are used to enforce a property as a checker. When the property for the
assert directive is evaluated to be true, the pass statements of the action block are executed.
Otherwise, the fail statements of the action block are executed. For example,

property abc(a,b,c);
disable iff (a==2) @ (posedge clk) not (b ##1 c);
endproperty
env_prop: assert property (abc(rst,in1,in2)) pass_statement;

else fail_statement;

When no action is needed, a null statement is specified. If no statement is specified for else, then
$error is used as the statement when the assertion fails.

For SystemVerilog and VHDL immediate assertions, passes and failures cannot be enabled or
disabled independently. So if AssertionEnable or assertion enable are used, both passes and
failures are enabled for immediate assertions.

Deferred Assertions and Cover Directives

ModelSim supports deferred assertions, a special kind of immediate assertions, as well as
deferred immediate assume and cover directives.
Deferred assume directives are simulated like assert directives unless the -noassume argument
is specified with the vsim command. (See Processing Assume Directives.) Deferred assertions
and cover directives are displayed in the Assertions window and can be added to the Wave
window just like simple immediate assertions. They are stored in the UCDB with other
assertions and cover directives and can be reported with the coverage report command.

ModelSim® SE User's Manual, v10.7 1063

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
SystemVerilog Cover Directives

SystemVerilog Cover Directives

SystemVerilog assertion coverage is performed with either or both of the following two cover
directives.
cover property ( property_spec ) statement_or_null
cover sequence (
[clocking_event]
[disable iff (expression_or_dist)]
sequence expr) statement_or_null

The "statement_or_null" syntax indicates an optional statement to be executed every time the
property succeeds or the sequence is matched.

SVA Usage Flow for Assertions and Cover

Directives
ModelSim compiles SystemVerilog assertions along with other SystemVerilog code when
either the source file ends in .sv or when you specify the -sv argument with the vlog command.
Figure 21-27 shows the use of SystemVerilog assertions in the debug flow.

1064 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
SVA Usage Flow for Assertions and Cover Directives

Figure 21-27. Usage Flow for SystemVerilog Assertions

The vopt command performs global optimizations on designs after they have been compiled
with vcom or vlog and produces an optimized version of your design in the working directory.
You must provide a name for this optimized version using the -o switch. You can then invoke
vsim directly on that new design unit name.

In the course of optimizing a design, the vopt utility will remove objects deemed unnecessary
for simulation — line numbers are removed, processes are merged, nets and registers may be
removed, and so on. For debugging, you preserve object visibility into your assertions by using
the +acc=a argument with the vopt command. The +acc=a argument specifies which objects
are to remain accessible for the simulation. In this case the “a” stands for assertions. (See
Preservation of Object Visibility for Debugging.)

When you invoke vsim on the design, the simulator automatically loads any assertions that are
present. The -assertdebug argument makes detailed assertion and cover directive information

ModelSim® SE User's Manual, v10.7 1065

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
SVA Usage Flow for Assertions and Cover Directives

available for viewing in the debugging windows of the GUI (see the next section, Viewing
Debugging Information).

When you invoke vsim on the optimized version of the design, the simulator automatically
loads any assertions that are present. The -assertdebug argument makes detailed assertion and
cover directive information available for viewing in the debugging windows of the GUI (see the
next section, Viewing Debugging Information).

If you use the -assertcounts argument or the -assertdebug argument with the vsim command,
the coverage save command will save the detailed assertion and cover directives information in
the .ucdb file (see Saving Assertion and Cover Directive Metrics). You can retrieve and display
this information in the debugging windows by using the vsim-viewcov <filename>.ucdb
command.

Note
You must use either vopt +acc=a or vsim -voptargs="+acc" with vsim -assertdebug. The
-assertcounts argument does not have this requirement.

If you use the +acc=a argument with the vopt command and specify the -assertdebug
argument with the vsim command, the coverage save command will save the detailed assertion
and cover directives information in the .ucdb file (see Saving Assertion and Cover Directive
Metrics). This information can be called up and viewed in the debugging windows with the
vsim-viewcov <filename>.ucdb command.

1066 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Using -assertdebug to Debug with Assertions and Cover Directives

Using -assertdebug to Debug with Assertions

and Cover Directives
Using the optional -assertdebug argument with the vsim command instructs ModelSim to
examine all assertions and display assertion details in the Assertions window.
Viewing Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Enabling ATV Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Enabling and Disabling ATV Recording During Simulation . . . . . . . . . . . . . . . . . . . . . 1069
Saving Assertion and Cover Directive Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window . . . . 1072
Using the Assertion Active Thread Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Viewing Assertion Threads in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Navigating Inside an ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Actions in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083

Viewing Debugging Information

The Assertions window displays information about assertion failures, passes, starts, and
antecedents.
Procedure
1. To enable assertion debugging with the GUI, select Simulate > Start Simulation to
open the Start Simulation dialog.
2. Open the Others tab.
3. In the Assertions section, select Enable assertion debug (Figure 21-28).
Figure 21-28. Enable Assertion Debug

ModelSim® SE User's Manual, v10.7 1067

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Enabling ATV Recording

Results
With assertion debugging enabled, assertion fail messages will be displayed in the transcript
and will include the expression that caused the assertion failure. Assertion failures are also
listed in the Message Viewer window (View > Message Viewer) under “Error.”
Local variable values corresponding to failed assertion threads are printed to the Transcript
along with assertion error messages when vsim is run with -assertdebug. This can be turned on/
off (default on) with AssertionFailLocalVarLog modelsim.ini variable or by using the CLI
assertion fail -lvlog command. For example:
# ** Error: Assertion error.
# Time: 450 ns Started: 250 ns Scope: test File: src/lvlog1.sv Line: 19 Expr: x==1
# Local vars : x = 0, s11 = '{x:'{10, 0, 0, 0, 0, 0, 0, 0, 0, 0}, y:1}
Note
There is a performance penalty when assertion debugging and assertion thread viewing are
enabled. You should use these features only when you need to debug failures.

Related Topics
Analyzing Assertions and Cover Directives

Enabling ATV Recording

For analyzing assertion problems, the Assertion Thread Viewer can be configured to record
detailed data of assertion states during simulation. This allows you to analyze temporal
expressions to determine when and where they are not holding.
Note
This is a memory and cpu-intensive process, so it is best to enable it selectively on an
instance by instance basis.

If you want access to the Assertion Thread Viewer (ATV), you must activate ATV recording
before the simulation is run with these two steps:

Procedure
1. The -assertdebug argument must be enabled with the vsim command, or “Enable
assertion debug” must be selected in the Others tab of the Start Simulation dialog.
2. ATV recording must be enabled with the atv log command.
An assertion path is specified with atv log -enable <path>... prior to running the
simulation so thread data can be collected over the course of the entire simulation. More
than one assertion path may be included in each atv log command.

1068 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Enabling and Disabling ATV Recording During Simulation

3. You can also enable ATV recording with the GUI by doing one of the following when
the Assertions window is active and one or more assertions is highlighted:
• Select Assertions > Enable ATV from the menus.
• Right-click (RMB) any highlighted assertion or assertions and select Enable ATV
from the popup menu (Figure 21-29).
Figure 21-29. Enable ATV Menu Selection

4. When the GUI is used to enable ATV recording, the appropriate command will be
echoed to the transcript (for enabling ATV in .do files).
Examples
A correct procedure would be the following:

vopt +acc=a top -o dbgver

vsim -assertdebug top dbgver
atv log -enable /top/assert_0 /top/assert_1 /top/assert_2

In this example, top is the top-level module in the design.

• The +acc=a argument is used with the vopt command to preserve assertion visibility for
debugging; and the -o argument is used to name the optimized version of the design
(dbgver).
• The -assertdebug argument is used with vsim to enable assertion debugging.
• The -assertdebug argument is used with vsim to enable assertion debugging on the
optimized version of the design.
• The atv log command line enables ATV recording for three assertions - assert_0,
assert_1, and assert_2 - in the top module.

Enabling and Disabling ATV Recording During

Simulation
Optionally, ATV recording may be enabled or disabled during a simulation when the simulator
has stopped. To enable, use the atv log -enable command as follows.

ModelSim® SE User's Manual, v10.7 1069

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Saving Assertion and Cover Directive Metrics

Procedure
1. To enable ATV recording, enter the following command:
atv log -enable <path>...\

2. To disable, use atv log -disable:

atv log -disable <path>...

3. When you enable ATV recording during simulation, only threads that start after the
current time will be visible.
4. You can disable ATV Recording with the GUI by unchecking the Enable ATV selection
with Assertions > Enable ATV, or right-clicking an assertion and unchecking Enable
ATV (as in Figure 21-29).
Examples
To only monitor assertion thread /top/assert_1 between time T and time T+N, the code should
be something like this:

run Tns
atv log -enable /top/assert_1
run Nns
atv log -disable /top/assert_1
run 1000ns

Saving Assertion and Cover Directive Metrics

You can save assertion and cover directive metrics to the Unified Coverage Database (UCDB).
Note
For easiest viewing and tracking of assertions and cover directives in the GUI and coverage
reports, it is recommended that you name all assertions and directives in the source files.

To make all assertion and cover directive metrics available for saving into a .ucdb file you must
do all of the following steps.

Procedure
1. Compile your design,
2. Use +acc=a with the vopt command
3. Use -assertdebug with the vsim command
4. Use the coverage save command
5. If the coverage save command is used without arguments, all assertion and cover
directive metrics are saved to the UCDB. If other coverage types (branch, statement,

1070 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Saving Assertion and Cover Directive Metrics

condition, and so on) are specified with the coverage save command, then the -assert
argument must be used to save assertions, like this:
coverage save -code bcest -assert

6. or the -directive argument must be used to save cover directives. like this:
coverage save -code bcest -directive

7. You can specify that only assertions and cover directives be saved with:
coverage save -assert -directive

8. If the -assertdebug argument is not used with vsim, the coverage save command will
only save the fail metrics for assertions and cover directives. When -assertdebug is
used, additional metrics saved for assertion directives include:

PassEnable
PassLog
PassCount
VacuousPassCount
DisabledCount
AttemptedCount
ActiveThreadCount
PeakActiveThreadCount

9. The -assertdebug argument determines how assertion coverage numbers are calculated
in the UCDB. When the -assertdebug argument is used, an assertion is considered
covered if the PassCount is > 0. If the -assertdebug argument is not used, an assertion is
considered covered if the FailCount = 0.
10. You can also use the GUI to save assertion and cover directive metrics.
• Select Tools > Coverage Save from the Main window
This opens the Coverage Save dialog, where you can select the type of coverage you
want to save, level of hierarchy to save, and output UCDB file name.
• Select Simulate > Start Simulation from the Main window
This opens the Start Simulation dialog. In the Others tab, check the “Enable code
coverage” box and the “Enable assertion debug” box.
11. Once the data is saved, assertion and cover directive coverage can be analyzed using:
• the Assertions window (refer to Viewing Assertions in the Assertions Window),
• the Cover Directives window (refer to Viewing Cover Directives in the Cover
Directives Window),

ModelSim® SE User's Manual, v10.7 1071

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window

• the Wave window (refer to Viewing Assertions and Cover Directives in the Wave
Window),
• columns in the Structure Window (Cover and Assertion hits and misses) (refer to
Structure Window in the GUI Reference Manual),
• the Instance Coverage window (refer to Instance Coverage Window in the GUI
Reference Manual),
• columns in the Verification Management Browser window (refer to Coverage and
Verification Management in the UCDB),
• and the coverage report and vcover report commands.
12. These methods are all available in live simulation mode as well as the Coverage View
(post-processing) mode.
Related Topics
Assertion/Cover Directive Naming Conventions

Analyzing Assertion Failures in the Assertion

Debug Pane of the Wave Window
If you used the -assertdebug argument with the vsim command when you invoked the
simulator, you can view the details of assertion failures in the Assertion Debug pane of the
Wave window. The steps to view assertion failures are as follows.
Procedure
1. To open the Assertion Debug pane in an undocked Wave window, select View >
Assertion Debug. To view the debug pane when the Wave window is docked in the
Main window, make the Wave window active then select Wave > Assertion Debug.
2. Click a red triangle on an assert directive waveform (the red triangle indicates a failed
assert directive) to display debug information about the failed assertion.

1072 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Using the Assertion Active Thread Monitor

Figure 21-30. Assertion Debug Pane in Wave Window

The Signals of Interest column displays the signals responsible for the assertion failure.
You can analyze these signals further in the Dataflow window by right-clicking a signal
and selecting Show Signal Drivers.
ModelSim supports the PSL forall keyword, which replicates designated assertions
multiple times and reports PASS or FAIL on assert directives that contain replicators.
The Replicator Parameters column displays the value of the replicator parameter for
which the assertion failed.

Using the Assertion Active Thread Monitor

If you used the -assertdebug argument with the vsim command when you invoked the
simulator, the Assertion Active Thread Monitor will display an ActiveCount object in the Wave
window for each assertion and cover directive. This object tracks the number of currently active
assertion or cover directive threads for the given instance. Expanding it will show individual
threads (based on start time) starting and stopping.

ModelSim® SE User's Manual, v10.7 1073

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Viewing Assertion Threads in the ATV Window

Figure 21-31. The ActiveCount Object in the Wave Window - SystemVerilog

The Assertion Active Thread Monitor is controlled by the BreakOnAssertion .ini variable,
whose default value is 1 (enabled). The number of rows the Assertion Active Thread Monitor
displays is limited, and is controlled by the AssertionActiveThreadMonitorLimit .ini variable.

Note
A large number of active thread rows will result in large .wlf files and increased memory
usage. The default for AssertionActiveThreadMonitorLimit is 5.

As with the main assertion Wave display, assertion start (blue square), pass (green triangle), fail
(red triangle), and antecedent match (yellow triangle) symbols appear in the active thread
monitor display. Right-clicking on one of these symbols reveals a View ATV menu selection
which will show assertion evaluation attempt start times. Selecting a start time will open an
assertion thread view. See Viewing Assertion Threads in the ATV Window.

Viewing Assertion Threads in the ATV Window

Assertion thread viewing is enabled for all assertions specified with the atv log command,
before the simulation is run. After running a simulation, an ATV window can be opened a
number of different ways.
Procedure
Do any of the following to open the ATV window and view assertion threads.

1074 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Viewing Assertion Threads in the ATV Window

• From the command line — The add atv command opens an ATV window for the
specified assert or cover directive (designated by its pathname), at the specified
evaluation attempt start time. For example:
• add atv /top/assert_1 450 ns
• From the Assertion Active Thread Monitor in the Wave window — Right-click any
assertion start (blue square), pass (green triangle), and fail (red triangle) symbol to
open a popup menu. Select View ATV, then an assertion evaluation attempt start
time. See Using the Assertion Active Thread Monitor.
• From the menu bar — Select (highlight) an assertion in the Assertions window then
select Assertions > Add ATV from the menus. This will bring up the View Thread
dialog, which allows you to select an assertion evaluation attempt start time. Note
that a given assertion instance typically has many evaluation attempt start times.
Any one of these times may be selected from the dialog box (Figure 21-32).
Selecting (or typing) an entry will bring up the ATV view for that particular instance
and starting time.
Figure 21-32. Selecting Assertion Thread Start Time

Note
If the Start Time and Logged Start Times fields are empty, either ATV recording
has not been enabled or no evaluation attempts have occurred.

• From the Assertions window — Right-click (RMB) any assertion and select View
ATV from the popup menu. Making this selection brings up the View Thread dialog
box (Figure 21-32), where you can select an evaluation attempt start time.
The View Thread dialogue allows you to filter the displayed list of logged thread
starting times by failed, passed, and still-active attempts.
• From the Wave window — If the assertion is logged, there will be symbols on the
assertion signal consisting of start objects (blue squares), pass objects (green
triangles) and fail objects (red triangles). Right-clicking near one of these objects

ModelSim® SE User's Manual, v10.7 1075

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Viewing Assertion Threads in the ATV Window

will open a pop-up menu with a View ATV selection and a sub-menu of evaluation
attempt start times (Figure 21-33). Select a start time to bring up the ATV view for
the selected assertion or cover directive.

Note
If the sub-menu of evaluation attempt start times is empty, ATV recording has
not been enabled.

Figure 21-33. Opening ATV from the Wave Window

• From the Message Viewer window — Right-click an assertion error message to

open a pop-up menu with a View ATV selection. Selecting this will bring up an
ATV window for the evaluation attempt start time associated with that particular
assertion error (Figure 21-34).

Note
If the sub-menu of evaluation attempt start times is empty, ATV recording has
not been enabled.

1076 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Viewing Assertion Threads in the ATV Window

Figure 21-34. Opening ATV from the Message Viewer Window

ModelSim® SE User's Manual, v10.7 1077

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Navigating Inside an ATV Window

Navigating Inside an ATV Window

The ATV window normally consists of four panes.
Figure 21-35. ATV Panes - SystemVerilog

Expression Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079

Thread Viewer Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Local Variables Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Design Objects Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081

1078 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Navigating Inside an ATV Window

Expression Pane
The Expression pane is a hierarchical representation of the assertion. From bottom to top, each
term in the assertion statement is represented following the left to right order of the original
expression. From left to right, the hierarchy of expression statements is represented with the
highest order terms on the left and the child terms on the right. Each term that has children can
be expanded or collapsed in the viewer by clicking on the ‘+’ and ‘–’ symbols. To expand or
collapse all terms, right-click anywhere in the Expression Pane and select Expand All Terms
or Collapse All Terms.
Failed boolean expressions are highlighted in red(Figure 21-36).

Figure 21-36. Failed Expressions Highlighted Red

By default, assertion expressions are displayed in the Expressions Pane in descending order.
You can change to ascending order by right-clicking in the Expressions Pane and selecting
Ascending Order from the popup menu.

Thread Viewer Pane

The thread viewer pane is on the right, and shows the progress of the assertion threads over time
for a given thread instance and starting time. Sub-threads that fork off of the main thread are
shown, as well as boolean checks, waits, and thread terminations.
Time is displayed along the X axis. The black columns show an instant in time — that is,
@100ns, @200ns, @300ns, and so on — during which some part of the assertion expression is
being evaluated. Every clock initiates an attempt to evaluate an assertion. From the simulation's
point of view, simulation time is not advancing in the black areas during the evaluation;
simulation time only advances in the dark grey areas.

Assertion statement progress is shown on the Y axis. The Y axis coordinates map directly to the
expression terms shown in the thread expression pane. So, as a thread is seen jumping to a
particular Y level, this shows that a particular term is being evaluated.

ModelSim® SE User's Manual, v10.7 1079

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Navigating Inside an ATV Window

Understanding Time in the Thread Viewer Pane

It is vitally important to understand that time in the ATV window is not represented in a linear
fashion like time in a Wave window. In the ATV window within a given time column (black),
all the assertion activity seen has happened at exactly the same instant in the simulator.
However, it is displayed in a manner that spaces out events so that individual thread progress
can be seen and understood. Consequently, no correlation between events on differing threads
can be implied unless two threads fork or join.

Local Variables Pane

To display the Local Variables Pane in the ATV window do one of the following.
• Click the Show Local Var Pane icon in the ATV Toolbar. Refer to ATV Toolbar in
the GUI Reference Manual for more information.
• When the ATV window is docked in the Main window, select ATV > Show Local
Vars.
• When the ATV window is undocked, select View > Show Local Vars.
A solid blue square indicates a local variable.

Local variable assignments are stripped out of the assertion statement at the top of the Thread
Viewer Pane for readability, but they do appear in the Expression Pane as “(LV assign).” You
can hover the cursor over any local variable icon (blue square) in the Thread Viewer pane to see
the actual assignment; or turn on local variables annotation (see Annotating Local Variables).

When a thread is highlighted (see Highlighting a Thread) and it contains local variables, the
values for the local variables on that highlighted thread will appear in the Local Variables Pane
(Figure 21-37).

1080 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Navigating Inside an ATV Window

Figure 21-37. Values of Local Variables

Like other windows in the GUI, the display radix for the values in the Local Variables Pane are
controlled by the radix command.

Design Objects Pane

To display the Design Objects pane in the ATV window do one of the following.
• Click the Show Design Objects icon in the ATV Toolbar. Refer to ATV Toolbar in the
GUI Reference Manual for more information.
• When the ATV window is docked in the Main window, select ATV > Show Design
Objects.
• When the ATV window is undocked, select View > Show Design Objects.
The Design Objects pane contains information similar to the Wave window when used to
display transactions. The left half contains the names of the design objects from the expression.
The right half contains areas for each column aligned to the corresponding column in the Thread
Viewer pane. Each area contains a list of textual representations of the values of the design
objects in the expression at that time.

The values shown in the Design Objects pane are the values used when the assertion expression
is evaluated. For PSL assertions, the values are at the time that the clock transitions. For
SystemVerilog assertions, the values at the beginning of the simulation time step before any

ModelSim® SE User's Manual, v10.7 1081

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Navigating Inside an ATV Window

signals have transitioned In either case, these values may be different than the values for these
objects at the end of that simulation time step.

1082 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Actions in the ATV Window

Actions in the ATV Window

Actions you can do to change what is seen in the ATV window include:
Find Sub-Expression That Caused Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Viewing Multiple Clock Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
Expanding and Contracting Expression Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Highlighting a Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Hovering the Mouse for Thread and Directive Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
Annotating Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088

Find Sub-Expression That Caused Failure

The ATV window allows you to find which sub-expression caused an HDL expression to fail.
For example, consider the assertion:

assert property (@(posedge clk) (b0 |=> ((b1 && b2) || b3)));

Even though ((b1 && b2) || b3)) is a boolean expression, the ATV window will show which
sub-expression – b1/b2/b3 – failed. In the Assertions window we right-click the assertion and
select View ATV from the popup menu. This opens the View Thread dialog, where we will
elect to Start at 150 ns (Figure 21-38).

Figure 21-38. View Thread at 150 ns

This opens the ATV window for the assertion, as shown in Figure 21-39.

ModelSim® SE User's Manual, v10.7 1083

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Actions in the ATV Window

Figure 21-39. ATV Window Shows Where Boolean Sub-Expression Failed

The red dots show where the boolean sub-expression failed.

Viewing Multiple Clock Expressions

The Expressions Pane displays all clock expressions in the assertion expression hierarchy.
Each clock is given a different color in the Thread Viewer Pane (Figure 21-40). All clock
symbols in the Thread Viewer Pane align with the appropriate clock expression in the
Expression Pane.

1084 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Actions in the ATV Window

Figure 21-40. ATV Window Displays All Clock Expressions

Expanding and Contracting Expression Hierarchy

You can expand and contract the expression hierarchy in the expression pane by clicking a plus
sign, ‘+’, to expand and a minus sign, ‘–’, to contract. When doing this, the threads in the thread
viewer pane will also expand and contract to exactly follow the expression pane.

Highlighting a Thread
You can highlight any thread in the Thread Viewer Pane to differentiate it from the other
threads by simply clicking on it with the left mouse button. Highlighting appears as a bold
purple line. Depending on where the thread is clicked, any sub-threads that are forked and occur
to the right of the click-point will also be highlighted. Going left, parent thread events which
lead up to the current thread and selection point will also be highlighted. Any parent thread
forks, other than the one which leads to the selected thread, will not be highlighted.

ModelSim® SE User's Manual, v10.7 1085

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Actions in the ATV Window

Highlighting for Root Thread Analysis

Highlighting provides a quick visual aid to root thread analysis of assertion failures. Red icons
in the Thread Viewer Pane indicate failures. Clicking any red icon, like the Directive Failed
icon (solid red triangle) in Figure 21-41, will highlight the path from the start thread to the failed
thread.

Figure 21-41. Root Thread Analysis of a Directive Failure

In Figure 21-42, a Thread Failed icon (hollow red triangle) is clicked, showing the path from the
start thread to the failure. In this case, the thread failure is redundant because other threads of
the assert directive are still running.

1086 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Assertions and Cover Directives
Actions in the ATV Window

Figure 21-42. Root Thread Analysis

Hovering the Mouse for Thread and Directive Status

Hovering the mouse over any GUI elements of the ATV Window reveals information about
assertion thread or directive status.
In Figure 21-43, the cursor hovers over a hollow green circle and the status indicates “Passed
but directive waiting on other running threads.”

Figure 21-43. ATV Mouse Hover Information

Hovering over a SystemVerilog local variable assignment symbol (a large blue square) reveals
the values assigned to the particular local variables at that point (Figure 21-43).

ModelSim® SE User's Manual, v10.7 1087

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Assertions and Cover Directives
Actions in the ATV Window

Figure 21-44. ATV Mouse Hover Information - SystemVerilog

Annotating Local Variables

The ATV window allows you to annotate local variables in the highlighted thread of the Thread
Viewer Pane using one of the following methods.
• Click the Annotate Local Vars icon in the ATV Toolbar. Refer to ATV Toolbar in
the GUI Reference Manual for more information.
• When the ATV window is docked in the Main window, select ATV > Annotate Local
Vars from the Main menu bar.
• When the ATV window is undocked, select View > Annotate Local Vars from the
menu bar.
• Right-click anywhere in the Thread Viewer Pane and select Annotate Local Vars from
the popup menu.
When Annotate Local Vars is selected, annotation appears in the Thread Viewer Pane only on
the highlighted thread, as shown in Figure 21-45.

Figure 21-45. Local Variables Annotation in Thread Viewer Pane

1088 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 22
Verification with Functional Coverage

Functional coverage is user-defined coverage – in contrast with code coverage, which is

automatically inferred from the source. At the most abstract level, functional coverage specifies
some values to observe at certain times in a design or test bench, and counts how many times
those values occur.
It should be noted, however, that complete functional coverage (100% coverage) does not
necessarily indicate design correctness, or even that all bugs have been observed. Rather,
functional coverage is a confidence metric. It is an implementation of a test bench – a way for
the simulator to track that certain values and events occurred as expected while running the test
bench. If the test bench is comprehensive and the coverage model (set of functional coverage
metrics) correctly implements the test bench, and the design produces correct results with 100%
functional coverage, then there is a high degree of confidence that all important bugs have been
found.

SystemVerilog implements functional coverage with covergroups and cover directives (for
more information on cover directives, refer to “Verification with Assertions and Cover
Directives”). Because cover directives are usually temporal and can inspect multiple signals and
states in the same evaluation, they are usually inserted by designers in the design source as
"white box" testing – that is, they specify and validate the expected behavior of a design. This
allows the verification tool to observe (and log) when particular events occur or assumptions are
violated.

Because covergroups operate upon integral values and have limited temporal features, they are
most often inserted in the test bench itself as "black box" testing. That is, the values monitored
by covergroups are most often high-level test bench or design features, like transaction types,
modes, addresses, opcodes, and so on.

Note
The functionality described in this chapter requires an additional license feature for
ModelSim SE. Refer to "License Feature Names" in the Installation and Licensing Guide
for more information, or contact your Mentor Graphics sales representative.

Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090

Functional Coverage Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Functional Coverage Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Functional Coverage Statistics in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Reporting on Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Assertion/Cover Directive Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120

ModelSim® SE User's Manual, v10.7 1089

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Functional Coverage Flow

Covergroup Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121

Saving Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124

Functional Coverage Flow

The following diagram shows the SystemVerilog functional coverage flow in ModelSim.
Figure 22-1. SystemVerilog Functional Coverage Flow

ModelSim compiles SystemVerilog functional coverage constructs along with other

SystemVerilog code when either the source file ends in .sv or you specify the -sv argument to
vlog command.

When you invoke vsim on the top-level of the design, the simulator automatically handles any
functional coverage constructs that are present. Next, you run the simulation. You may
optionally view coverage interactively in the GUI with commands such as ‘coverage report’,
and/or save off coverage to the Unified Coverage DataBase (UCDB) with the ‘coverage save’
command. The UCDB can then be used for reporting, merging, ranking, or other types of
verification analysis.

1090 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Functional Coverage Control Options

Functional Coverage Control Options

SystemVerilog offers a rich set of facilities for configuring covergroups, coverpoints, and
crosses through the option and type_option structures. The settings can be used to control
various aspects of SV simulation, using guidelines which apply to each of the settings.
Guidelines for Functional Coverage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Controlling Functional Coverage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091

Guidelines for Functional Coverage Control

To set values for the variables in the sections listed above — from the ModelSim command line
interface or a .do file — use the change command.
For example:

change covervar.type_option.weight 20

If set at the covergroup syntactic level, this command specifies the weight of this covergroup for
computing the overall cumulative (or type) coverage of the saved database. If set at the
coverpoint (or cross) syntactic level, it specifies the weight of a coverpoint (or cross) for
computing the cumulative (or type) coverage of the enclosing covergroup.

Note that a type_option is not accessible with the type name and "::" in the command line
interface. Instead, refer to the type_option through an instantiated covergroup variable, as
shown in the example above.

Controlling Functional Coverage Collection

ModelSim supports several methods for enabling/disabling the collection of functional
coverage. During live simulation, you can turn off the collection of coverage statistics for
covergroups, coverpoints, and crosses from within the source code:
• Using the SystemVerilog extension option.no_collect of type “bit”. The default value of
option.no_collect is 0, which enables the collection of coverage. Setting the value to 1
disables the coverage collection (see Figure 22-2).
• Simulating with vsim -cvgzwnocollect enabled, when option.weight is set to 0 within
the source code (see also the SVCovergroupZWNoCollect modelsim.ini variable). This
has the effect of disabling coverage collection for all zero weighted items.
• Simulating with vsim -nocvg disables covergroup object construction and removes the
ability to run built-in covergroup methods during simulation. As a result, a
svverification license is not required when -nocvg is used in the simulation.
To print a report of functional coverage items which have been actively selected for non-
collection, use -nocollect with the coverage/vcover report commands.

ModelSim® SE User's Manual, v10.7 1091

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Controlling Functional Coverage Collection

Figure 22-2. Turning off Collection for a Coverpoint Using option.no_collect

covergroup cvg (bit val);

coverpoint data {
option.no_collect = val;
...
}
endgroup

Controlling Presence and Visibility of Aggregated Bins

By default, covergroup instances (and the bins therein) are shown, irrespective of their
option.per_instance value. However, aggregated bins under the type coverage are only available
when the type_option.merge_instances=1. Three possibilities exist for how merge_instances be
set in a given covergroup type:

• set to 0 in the SV code — aggregated bins do not exist for this algorithm choice
• set to 1 in the SV code — aggregated bins do exist
• not set — in this case, the Questa default is determined according to the dictates
outlined in the section “SystemVerilog 2009 type_option.merge_instances”. If the tool
chooses to set it to 0, you will not have any aggregated bins, or you can use vsim -
cvgmergeinstances at runtime to override the default tool setting.
The equivalent modelsim.ini variable is SVCovergroupMergeInstancesDefault (0|1). For more
information and some examples of SV code containing these options, see IEEE Std 1800-2009
Option Behavior.

Controlling Optimization with a UCDB File

You may load a functional coverage database (UCDB file) into simulation and use it to control
optimization by using the -cvgprecollect switch with the vsim command.

When a coverpoint/cross/covergroup instance is pre-covered in the input UCDB — namely the

coverage score is 100% — the presence of the -cvgprecollect switch instructs the simulator to
disable the matching instance in the new simulation. When the optimization is enabled for the
instance, the instance is removed from the simulation. No coverage data collected or saved into
UCDB.

This decision is irreversible.

There are certain cases in which the optimization can not be performed. For example, if a
coverpoint participates in a cross, such coverpoint can not be disabled since the sampling of the
cross may require the sampling of the coverpoint. When such optimization can not be done on a
particular coverpoint/cross/covergroup instance, the instance will be handled in the same way as
in a normal simulation.

1092 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Controlling Functional Coverage Collection

Related Topics
change [ModelSim SE Command Reference Manual]
vsim [ModelSim SE Command Reference Manual]
Loading a Functional Coverage Database into Simulation

ModelSim® SE User's Manual, v10.7 1093

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Functional Coverage Computation

Functional Coverage Computation

SystemVerilog provides the following built-ins, available for use with ModelSim.
Predefined Coverage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Predefined Coverage System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
SystemVerilog Functional Coverage Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
IEEE Std 1800-2009 Option Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Type-Based Coverage With Constructor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101

Predefined Coverage Methods

The SystemVerilog LRM defines two built-in methods (get_coverage() and
get_inst_coverage()), applied at the covergroup, coverpoint, and cross scope. All of these built-
ins return a coverage metric as a floating point number that represents achieved coverage as a
percentage (where 100.0 is the maximum possible coverage). Refer to IEEE Std 1800-2009
LRM, Section 19.8 for details on these methods.
For a description of per-type coverage aggregation computation and information on how
functional coverage participates in the total coverage aggregation, see “Coverage Aggregation
in the Structure Window”.

Predefined Coverage System Function

The SystemVerilog LRM defines the $get_coverage() built-in system function as "the overall
coverage of all coverage group types." Additionally, type_option.weight at the covergroup
scope is used to weight an individual covergroup type's contribution to the “overall cumulative
(or type) coverage.” Keeping in mind that different module instances create different
covergroup types, as described in the previous section, the $get_coverage() system task returns
a weighted average as follows:
Numerator = sum over all covergroup types of ( type::get_coverage() value *
type::type_option.weight )

Denominator = sum over all covergroup types of ( type::type_option.weight )

For details on this function, you can refer to IEEE Std 1800-2009 LRM, Section 19.9.

SystemVerilog Functional Coverage Terminology

The LRM refers to “cumulative” coverage and “type” coverage as the same thing; we use the
term “type-based” coverage. The LRM sometimes uses “coverage” and “instance coverage”
interchangeably; we use “instance-based coverage.”

1094 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

IEEE Std 1800-2009 Option Behavior

The coverage system default behavior for SystemVerilog covergroups (ModelSim version 6.6
and higher) is compliant with the latest IEEE Std1800-2009 clarifications and changes.
Note
The command line options discussed in this section have no influence on coverpoint or cross
options, and thus those options are not discussed here. See the LRM for complete details.

The changes as they relate to covergroup calculation and reporting — and instructions for
reverting the settings — are summarized in Table 22-1:
Table 22-1. Questa SIM and SystemVerilog IEEE 1800-2009 Options
1800-2009 Option Default in Questa To revert to pre-6.6
behavior, use:
option.per_instance 0 - instance data is reported To remove instances having
per_instance=0, use coverage
report/
vcover report
-hidecvginstspi0
In the GUI: Covergroups
window > Hide Covergroup
Instances
type_option.merge_instances Refer to SystemVerilog 2009 set to 1, or use
type_option.merge_instances vsim -cvgmergeinstances
option.get_inst_coverage 0 - only valid when set to 1
merge_instances is set (1).
Both get_inst_coverage and
get_coverage return the same
merged coverage result

Example of Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095

SystemVerilog 2009 option.per_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
SystemVerilog 2009 type_option.merge_instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
SystemVerilog 2009 option.get_inst_coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Legacy Behavior and Option Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099

Example of Option Settings

The example code shown below demonstrate how options are set.

ModelSim® SE User's Manual, v10.7 1095

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

covergroup cgtype (int lhs, rhs);

type_option.merge_instances = 1;
option.per_instance = 1;
option.get_inst_coverage = 1;
coverpoint vbl {
bins b[] = { lhs, rhs };
}
endgroup

The default in the 2009 standard, if you were to explicitly set it in the code, would be:

covergroup cgtype (int lhs, rhs);

type_option.merge_instances = 0;
option.per_instance = 0;
option.get_inst_coverage = 0;
coverpoint vbl {
bins b[] = { lhs, rhs };
}
endgroup

A report could be generated with the following report command:

coverage report -details

The report generated for default option settings would look like this:

# COVERGROUP COVERAGE:
# -----------------------------------------------------------------------
# Covergroup Metric Goal/ Status
# At Least
# -----------------------------------------------------------------------
# TYPE /top/cgtype 50.0% 100 Uncovered
# Coverpoint cgtype::vbl 50.0% 100 Uncovered
# Covergroup instance \/top/ci 50.0% 100 Uncovered
# Coverpoint vbl 50.0% 100 Uncovered
# covered/total bins: 1 2
# missing/total bins: 1 2
# bin b['b000000] 1 1 Covered
# bin b['b000011] 0 1 ZERO
#
# TOTAL COVERGROUP COVERAGE: 50.0% COVERGROUP TYPES: 1 #

In this case, the coverage of the covergroup type is the average of the two covergroup instances.
Since each of the two instances has 50% coverage, the type-based coverage is also 50%. The
type-based coverage is computed as a weighted average based on the option.weight of each
covergroup instance.

SystemVerilog 2009 option.per_instance

The option.per_instance covergroup option has a clarified meaning in IEEE Std 1800-2009.
Coverage database behavior is explicitly allowed to be vendor-specific, so the ModelSim
simulator always saves the instance in the database and reports the instances. Without that
information, post-process merging would be crippled with a strict interpretation of the LRM.

1096 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

By default, the following coverage report is produced with instances visible. For example:

# coverage report -details

# COVERGROUP COVERAGE:
# -----------------------------------------------------------------------
# Covergroup Metric Goal/ Status
# At Least
# -----------------------------------------------------------------------
# TYPE /rwb/color_cg 33.3% 100 Uncovered
# Coverpoint color_cg::c1 33.3% 100 Uncovered
# Covergroup instance \/rwb/cg_inst 33.3% 100 Uncovered
# Coverpoint c1 33.3% 100 Uncovered
# covered/total bins: 1 3
# missing/total bins: 2 3
# bin auto[red] 1 1 Covered
# bin auto[white] 0 1 ZERO
# bin auto[blue] 0 1 ZERO
#
# TOTAL COVERGROUP COVERAGE: 33.3% COVERGROUP TYPES: 1
#

It results in a detailed display of data in the GUI and reports, including the instances. If you
want to hide the instances, use the -hidecvginstspi0 argument to the coverage/vcover report
command.

SystemVerilog 2009 type_option.merge_instances

The merge_instances option was introduced in IEEE Std 1800-2009. The merge_instances
value determines the algorithm for computing the coverage score for a covergroup type and is
defined in the LRM.
The setting of merge_instances value in ModelSim is determined by a set of factors whose
precedence, from highest to lowest, is the following:

1. Explicit user type_option.merge_instance setting in SystemVerilog source code.

2. Options on the vsim command line:
a. vsim -cvgmergeinstances sets the type_option.merge_instances to 1.
b. vsim -nocvgmergeinstances sets the type_option.merge_instances to 0.
3. Current setting of the modelsim.ini variable SVCovergroupMergeInstancesDefault.
4. Effective value that the tool automatically selects for each covergroup type. In this case,
type_option.merge_instances appears in the GUI and coverage reports either as
“auto(1)” or “auto(0)” depending on whether the effective value was determined to be a
1 or a 0. ModelSim chooses "auto(1)" as a capacity optimization in certain cases where
large numbers of covergroup objects may be generated.
See “SystemVerilog 2009 option.per_instance” and “Legacy Behavior and Option
Recommendations” for related details.

ModelSim® SE User's Manual, v10.7 1097

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

Note
When type_option.merge_instances is set to 0, since the type-based coverage is calculated
from covergroup instances rather than child coverpoints and crosses, the
type_option.weight specified in coverpoints and crosses has no effect on the type-based
coverage of the covergroup.

When type_option.merge_instances is set to 1, since the type-based coverage is calculated from

child coverpoints and crosses rather than the covergroup instances, the option.weight specified
in coverpoints and crosses has no effect on the type-based coverage of the covergroup.

SystemVerilog 2009 option.get_inst_coverage

The ModelSim simulator’s interpretation of option.per_instance was as an enabler for instance-
based coverage as well as whether instances appeared in the report and database. This has been
clarified in SystemVerilog 2009. By "enabler" we mean essentially whether the
get_inst_coverage() method can provide instance based coverage, which can be different than
the type (cumulative) coverage from the get_coverage() method. This enabling functionality is
now set with option.get_inst_coverage, which applies only when type_option.merge_instances
is equal to 1 (by default it is set to 0).
Table 22-2 offers a summary of the behavior of get_inst_coverage() and get_coverage() as they
relate to type_option.merge_instances and option.per_instance:
Table 22-2. Option Settings and Coverage Results
type_option.merge option.get_inst get_inst_coverage() get_coverage()
_instances _coverage
0 either 0 or 1 individual instance average of all instances
1 0 merge of all instances merge of all instances
1 1 individual instance merge of all instances

In this table, the default settings for the options are indicated with bold values.

Again, the option.get_inst_coverage is only applicable when you set

type_option.merge_instances to 1; when it is, the default behavior of the get_inst_coverage()
method is such that the per-instance data is not tracked, and thus it is not available from
get_inst_coverage(). If desired, the tracking of per-instance data can be turned on by setting the
option.get_inst_coverage to 1.

Example 22-1. Different Results with get_inst_coverage and get_coverage

In this example, using both 'merge_instances' and 'get_inst_coverage' you can get different
results for the two methods: get_inst_coverage and get_coverage.

1098 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

module get_inst_example;
typedef enum {red, white, blue} color;
color c1;
covergroup color_cg;
type_option.merge_instances = 1;
option.get_inst_coverage = 1;
coverpoint c1;
endgroup : color_cg
color_cg cg_inst_1 = new();
color_cg cg_inst_2 = new();
initial
begin
c1 = red;
cg_inst_1.sample();
$display("Sampled 'red' in cg_inst_1 and results are...");
$display("cg_inst_1.get_inst_coverage() == %f",
cg_inst_1.get_inst_coverage());
$display("cg_inst_1.get_coverage() == %f", cg_inst_1.get_coverage());
$display("");
$display("cg_inst_2.get_inst_coverage() == %f",
cg_inst_2.get_inst_coverage());
$display("cg_inst_2.get_coverage() == %f", cg_inst_2.get_coverage());
end
endmodule : get_inst_example

The results displayed would be as follows:

# Sampled 'red' in cg_inst_1 and results are...

# cg_inst_1.get_inst_coverage() == 33.333333
# cg_inst_1.get_coverage() == 33.333333
#
# cg_inst_2.get_inst_coverage() == 0.000000
# cg_inst_2.get_coverage() == 33.333333
#

Legacy Behavior and Option Recommendations

Several changes have occurred over the past several releases of Questa.
The changes are:

• 6.6 — Default settings for options were changed to be IEEE 1800-2009 compliant
• 6.4 — type_option.merge_instances and option.get_inst_coverage were added
It is possible that tests or scripts you have developed may depend on some legacy behavior. To
ease the transition, use the information contained in Table 22-1 on Questa SIM and
SystemVerilog IEEE 1800-2009 Options.

Related Topics
change [ModelSim SE Command Reference Manual]
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1099

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
IEEE Std 1800-2009 Option Behavior

Functional Coverage Computation

1100 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

Type-Based Coverage With Constructor

Parameters
The behavior of type-based coverage with respect to parameterized covergroups was not well-
defined in the IEEE Std 1800-2005 LRM, though it is in the 2009 version. This section
describes the default behavior of the ModelSim tool, with a note at the end about how to achieve
this in fully-compliant IEEE Std 1800-2009.
Default Type-Based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Projected Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104

Default Type-Based Coverage

Type-based coverage is easy to understand for the case where all instances have the same
number of bins, and the same values map to the same bins. However, SystemVerilog
covergroups may be parameterized when they are constructed, creating implications for type-
based coverage. Type-based coverage may be calculated for covergroups that have different
numbers of bins because they were constructed differently.
Consider Example 22-2:

Example 22-2. Type-based Coverage

module top;
int vbl;
covergroup cgtype (int lhs, rhs);
option.per_instance = 1;
type_option.merge_instances = 1;
coverpoint vbl {
bins b[] = { lhs, rhs };
}
endgroup
cgtype cgvar1_2 = new(1,2);
cgtype cgvar1_3 = new(1,3);
initial
begin
vbl = 1;
cgvar1_2.sample();
vbl = 3;
cgvar1_3.sample();
$display("cgvar1_2.get_inst_coverage() == %f",
cgvar1_2.get_inst_coverage());
$display("cgvar1_3.get_inst_coverage() == %f",
cgvar1_3.get_inst_coverage());
$display("cgvar1_2.get_coverage() == %f", cgvar1_2.get_coverage());
$display("cgvar1_3.get_coverage() == %f", cgvar1_3.get_coverage());
end
endmodule

ModelSim® SE User's Manual, v10.7 1101

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

Here is the report that is generated using “vcover report -details”:

# COVERGROUP COVERAGE:
# -----------------------------------------------------------------------
# Covergroup Metric Goal/ Status
# At Least
# -----------------------------------------------------------------------
# TYPE /top/cgtype 66.7% 100 Uncovered
# Coverpoint cgtype::vbl 66.7% 100 Uncovered
# bin b[1] 1 1 Covered
# bin b[3] 1 1 Covered
# bin b[2] 0 1 ZERO
# Covergroup instance \/top/cgvar1_2 50.0% 100 Uncovered
# Coverpoint vbl 50.0% 100 Uncovered
# bin b[1] 1 1 Covered
# bin b[2] 0 1 ZERO
# Covergroup instance \/top/cgvar1_3 50.0% 100 Uncovered
# Coverpoint vbl 50.0% 100 Uncovered
# bin b[1] 0 1 ZERO
# bin b[3] 1 1 Covered
#
# TOTAL COVERGROUP COVERAGE: 66.7% COVERGROUP TYPES: 1

The instance coverage is clear – each covergroup instance has 50% coverage because each has
two bins and only one of those is covered.

The type-based coverage is a little more complicated. The type-based coverage is 66.7%, or two
out of three bins covered. The reason is that the type has three bins. Since
type_option.merge_instances is in effect, the total number of bins is the union of bins of all
instances. The cgvar1_2 instance has the set of bins { b[1], b[2] }. The cgvar1_3 instance has
the set of bins { b[1], b[3] }. The union of these two sets of bins is { b[1], b[2], b[3] }. Of this
set of bins, the set { b[1], b[3] } is actually covered. So type-based coverage is 2 / 3 =
66.666666%.

Bin Unions by Name

In Example 22-2, we do not count bin b[1] twice because it is the same in both covergroup
instances. So how are bins determined to be the same?

ModelSim’s approach is to consider bins to be the same if they have the same name. This relies
on a naming convention that is not completely specified by the IEEE Std 1800-2009 LRM. For
more details on the naming convention used, see “Canonical String Representation for
Coverpoint Bin Value”.

Consider that there are three ways of specifying a bin:

1 bins a = { 1, 2, 3 }; // bin a
2 bins b[] = { 1, 2, 3 }; // bins b[1], b[2], b[3]
3 bins c[2] = { 1, 2, 3 }; // bins c[0] <- 1; c[1] <- 2,3

1102 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

The first two examples clearly declare bins a, b[1], b[2], and b[3]. But what of the bins
specified with identifier “c?” ModelSim specifies bins c[0] and c[1]. This is consistent with the
constructs in the LRM where bins with an explicit size constant (as is the case for identifier "c")
are taken very literally in order. For example, "bins c[2] = { 1, 1 };" is perfectly legal. In this
case, c[0] is incremented when the value 1 is sampled, and so is c[1].

Now, reconsider Example 22-2 with an explicit size constant in the bin declaration, as shown in
Example 22-3:

Example 22-3. Bin Unions

module top;
int vbl;
covergroup cgtype (int lhs, rhs);
option.per_instance = 1;
type_option.merge_instances = 1;
coverpoint vbl {
bins b[2] = { lhs, rhs }; // now with explicit size constant!
}
endgroup
cgtype cgvar1_2 = new(1,2);
cgtype cgvar1_3 = new(1,3);
initial
begin
vbl = 1;
cgvar1_2.sample();
vbl = 3;
cgvar1_3.sample();
$display("cgvar1_2.get_inst_coverage() == %f",
cgvar1_2.get_inst_coverage());
$display("cgvar1_3.get_inst_coverage() == %f",
cgvar1_3.get_inst_coverage());
$display("cgvar1_2.get_coverage() == %f", cgvar1_2.get_coverage());
$display("cgvar1_3.get_coverage() == %f", cgvar1_3.get_coverage());
end
endmodule

ModelSim® SE User's Manual, v10.7 1103

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

Here is vcover report output for this example:

# COVERGROUP COVERAGE:
# -----------------------------------------------------------------------
# Covergroup Metric Goal/ Status
# At Least
# -----------------------------------------------------------------------
# TYPE /top/cgtype 100.0% 100 Covered
# Coverpoint cgtype::vbl 100.0% 100 Covered
# bin b[0] 1 1 Covered
# bin b[1] 1 1 Covered
# Covergroup instance \/top/cgvar1_2 50.0% 100 Uncovered
# Coverpoint vbl 50.0% 100 Uncovered
# bin b[0] 1 1 Covered
# bin b[1] 0 1 ZERO
# Covergroup instance \/top/cgvar1_3 50.0% 100 Uncovered
# Coverpoint vbl 50.0% 100 Uncovered
# bin b[0] 0 1 ZERO
# bin b[1] 1 1 Covered
#
# TOTAL COVERGROUP COVERAGE: 100.0% COVERGROUP TYPES: 1

In this case, the union of the bins in the type is { b[0], b[1] }. While it is true that in cgvar1_2,
b[1] maps from value 2, and in cgvar1_3, b[1] maps from value 3, that does not matter for the
type coverage. These are the same bin as far as the type-based coverage is concerned.

So in this case, cgvar1_2 covers bin b[0] (mapped from vbl==1) and cgvar1_3 covers bin b[1]
(mapped from vbl==3). So the instance-based coverage is 50% for each instance, and the type-
based coverage is 100% because both bins are covered for the union of bins in the type.

Projected Covergroups
Users write covergroups in template classes, and each parameterized class instance of a
template class creates separate covergroup type scopes. That causes low coverage of those
covergroup type scopes due to the fact that parameterized class instances are specifically
optimized though their covergroups are still general. As such, it is not possible to cover all the
parts of a general covergroup residing under a specifically parameterized class.
To improve the coverage of those covergroup type scopes, you can use a new covergroup option
— parameter_projection_name — to project covergroup instances from their actual covergroup
type scopes into a virtually created covergroup type scope. This allows covergroup instances
covering similar regions in different parameterized classes to associate together to form a new
covergroup type scope, thereby yielding a higher coverage number for that new covergroup.
Specifically, his projection functions by collecting some of the covergroup instances of those
different covergroup type scopes based on a key to construct a virtual covergroup type scope,
and then use the coverage of that virtual covergroup type scope instead of the original
covergroup type scopes.

1104 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

parameter_projection_name Covergroup Option

The covergroup option parameter_projection_name has been implemented for specifying a
virtual scope name for the covergroup instance being projected. You make use of this option by
specifying it in the source code.

The option parameter_projection_name is the key for doing the projection of covergroup
instances. The projection essentially collects together the covergroup instances from different
covergroup types in different parameterized class objects of a same template class to form a new
covergroup type scope under the template class. The name of this new covergroup type scope is
the value specified for option.parameter_projection_name. The value of this parameter setting
must be specified within the covergroup declaration, and cannot be changed later. If the
option.parameter_projection_name is not specified for a covergroup instance, then that
covergroup instance is not projected.

The following code shows an example of how to specify the parameter_projection_name for a
covergroup instance.

class myclass # (int SIZE = 1);

bit [SIZE:0] x;

covergroup cvg (string proj_name);

option.parameter_projection_name = proj_name;
coverpoint x;
endgroup

function new;
cvg = new ("valid");
endfunction

endclass

Appearance and Coverage in Text and HTML Report

The coverage of virtually created covergroup type scopes under template class objects are used
in coverage calculation. If a real covergroup type scope under a parameterized class scope
becomes empty due to the movement of all the instances of that covergroup type, then that
covergroup type scope is ignored from coverage calculation and not shown anywhere in report.

Appearance in Covergroups Window

Like the coverage report, the Covergroups window displays the projected view. It displays the
artificially created scopes using the color of virtual objects. If a real covergroup type scope
under a parameterized class scope becomes empty due to the movement of its covergroup
instances, that covergroup type scope is not displayed in the GUI.

The diff Utility

The diff operation work on actual data, and does not use the projected view. The diff operation
reports differences based on the real data stored in UCDB file, it does not report difference of
projected views.

ModelSim® SE User's Manual, v10.7 1105

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Type-Based Coverage With Constructor Parameters

Projected Covergroups and Ranktest Operation

The coverage and vcover ranktest operations rank tests based on the coverage numbers, so it
works on projected views. That means projection operation is done before computing coverage
numbers which are used in comparing tests for ranking.

Projected Covergroups and coverage exclude

The scope paths used in a coverage exclude command uses the path to a projected covergroup
location instead of the actual covergroup item location. The projected view is presented to the
user, so the user should use the paths in the projected view to apply or clear a coverage
exclusion. The coverage exclude report should also use the paths of the projected view.

1106 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Functional Coverage Statistics in the GUI

Functional Coverage Statistics in the GUI

SystemVerilog coverage statistics are displayed in the Covergroups Structure (sim) windows.
Note
Covergroups are created dynamically during simulation. This means they will not display in
the GUI until you run the simulation.

Viewing Functional Coverage Statistics in the Covergroups Window . . . . . . . . . . . . . . 1107

Functional Coverage Aggregation in Structure Window . . . . . . . . . . . . . . . . . . . . . . . . 1109

Viewing Functional Coverage Statistics in the

Covergroups Window
You can view functional coverage statistics in the Covergroups window by performing the
following steps.
Procedure
1. Select View > Coverage > Covergroups from the Main window menu bar.
2. Run the simulation. (Covergroups are not displayed in the Covergroups window until
you run the simulation.)
Figure 22-3. Functional Coverage Statistics in Covergroups Window

3. The Covergroups window displays the Coverage of each covergroup, coverpoint, cross,
and bin. Covergroup coverage is a weighted average of the coverage of the constituent
coverpoints and crosses.
4. See “Functional Coverage Computation” for additional details.

ModelSim® SE User's Manual, v10.7 1107

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Viewing Functional Coverage Statistics in the Covergroups Window

5. For a description of the columns that can be displayed, see “Covergroups Window”.

1108 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Functional Coverage Aggregation in Structure Window

Functional Coverage Aggregation in Structure

Window
Access: View > Structure
Certain columns of data appear in this window that are specifically related to functional
coverage statistics within the Structure window are calculated.
Objects
• Column titles.
o Covergroups % — this column shows a weighted average of all covergroup type-
based coverage and cover directive coverage in the sub-tree. Covergroup coverage is
calculated using the get_coverage() method and type_option.weight weighting.
o Cover directives % — this column shows a weighted average using the weights
you set (see “Weighting Cover Directives”). By default, a cover directive is
weighted equally with a covergroup type.
o Assertion % — this column shows a calculation using the total number of assertions
and the number of assertions which are covered. The number of covered assertions is
all the assertions which have never failed and where pass counts (if available) that
are greater than 0. If pass counts are not available, then the number of covered
assertions is the same as the number of assertions that have never failed.
For a description of the coverage summary aggregation for Total Coverage column, see
“Coverage Aggregation in the Structure Window”.

ModelSim® SE User's Manual, v10.7 1109

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Reporting on Functional Coverage

Reporting on Functional Coverage

You can create functional coverage reports using dialogs accessible through the GUI or via
commands entered at the command line prompt.
Creating Text Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Creating HTML Reports Via the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Covergroup Bin Reporting and Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Filtering Functional Coverage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
Reporting Via the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Excluding Functional Coverage from the GUI and Reports . . . . . . . . . . . . . . . . . . . . . . 1117

Creating Text Reports Via the GUI

You can save a functional coverage text report using any of the following methods.
• With the Cover Directives window active, select Cover Directives > Report from the
Main menu.
• Right-click anywhere in the Cover Directives window and select Report from the popup
menu.
• With the Covergroups window active, select Covergroups > Report from the Main
menu.
• Right-click anywhere in the Covergroups window and select Report from the popup
menu.
Any of these actions will open the Functional Coverage Report dialog.

You can create an ASCII file with the functional coverage statistics by selecting Tools >
Coverage Report > Text. This brings up the Coverage Text Report dialog (Figure 22-4).

1110 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Creating Text Reports Via the GUI

Figure 22-4. Creating Functional Coverage Text Reports

Use the Coverage Text Report dialog to create functional coverage reports on specific instances
or on all coverage items. Options allow you to report only on covergroup coverage or on
directive coverage. If covergroup coverage is selected, a functional coverage report will be
created using covergroup type objects.

ModelSim® SE User's Manual, v10.7 1111

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Creating HTML Reports Via the GUI

Here are a couple of points to keep in mind about coverage reporting:

• Filtering does not affect the calculation of aggregated statistics. It merely affects the data
displayed in the report.
• A report response of "No match" indicates that the report was empty.
• The report will be sorted such that all bins with 0 counts show up as the first rows. Then,
within that first section of 0-count rows, the covergroups would be the secondary sort.
Thus, all 0's in covergroup A would appear next to each other, and so on for covergroup
B, and others.

Creating HTML Reports Via the GUI

You can create an HTML report of the functional coverage statistics that will appear in your
browser by selecting Tools > Coverage Report > HTML, which opens the Coverage HTML
Report dialog.
See “Generating HTML Coverage Reports” for further details.

Covergroup Bin Reporting and Timestamps

The -cvgbintstamp option for the vsim command enables ModelSim to record the simulation
time step (timestamp) whenever a covergroup bin is covered during a simulation run.
The timestamp values for covered covergroup bins are then displayed in any coverage reports
you generate (see “Reporting on Functional Coverage”). The report contains a column
displaying the timestamp of each covergroup bin. When reporting only covergroups, the
coverage report contains two columns — one for the timestamp value and the other for the test
name.

• Timestamp values are saved in the ucdb file along with coverage information when you
save coverage. Timestamp values and test names are saved with each covergroup bin.
• For reports from a simulation run (that is, not from a ucdb file), the test name column
contains the string "Current Test" instead of a test name.
• Merging UCDB files —
If you merge two ucdb files that contain timestamp values, the output (merged) ucdb file
maintains the earliest timestamp value of the ucdb files, even if the merged cover items
have different at_least values. The merged ucdb file also maintains the test name for the
test that has the smallest timestamp value.
As a result of this fact, if you merge two different UCDB files where a timestamp value
for a covergroup bin is the same in both files, that timestamp value is only assigned to
one of the tests. You will lose the information that the second test also covered the bin at
that timestamp.

1112 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Filtering Functional Coverage Data

• Editing UCDB files —

o It is not possible to make a later change to the coveritem goal recorded in the
database after it has been saved — for example by modifying the UCDB using the
coverage edit command — and automatically infer a different timestamp (see
"Timestamps and UCDB Modification or Merging").
o If a test record is removed from the UCDB, the timestamp value can be hidden from
the GUI, text report and HTML report, since the timestamp value references the test
where the bin was covered.
To avoid the computational overhead associated with the display of covergroup bin timestamps
in HTML reports, apply the -notimestamps argument to the coverage report (or vcover report)
-html command.

Related Topics
vsim [ModelSim SE Command Reference Manual]
coverage edit [ModelSim SE Command Reference Manual]
Reporting on Functional Coverage
Viewing Functional Coverage Statistics in the Covergroups Window

Filtering Functional Coverage Data

You can filter functional coverage data displayed in the GUI — including the Assertions, Cover
Directives and Covergroups windows.
Procedure
1. Activate the desired window and use the context sensitive menu pulldown and select
Filter setup (Covergroups > Filter > Setup, or Cover Directives > Filter > Setup, or
Assertions > Filter > Setup). This opens the Filter Setup dialog (Figure 22-5).

ModelSim® SE User's Manual, v10.7 1113

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Filtering Functional Coverage Data

Figure 22-5. Filter Setup Dialog

2. To create a new filter, click the Create button to open the Create Filter dialog
(Figure 22-6).
Figure 22-6. Create Filter Dialog

The Edit Filter dialog – which you open by clicking the Edit button in the Filter Setup
dialog - contains all of the same functions as the Create Filter dialog.

1114 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Reporting Via the Command Line

3. Click the Add button to add criteria, attributes, operators, and values to the filter in the
Add/Modify Select Criteria dialog (Figure 22-7).
Figure 22-7. Add-Modify Select Criteria Dialog

The Criterion field includes a dropdown list that corresponds to the columns in the
Assertions/Cover Directives/Covergroups window, allowing you to filter the display
according to values in a specific column or columns.
4. You can copy the criteria from an existing filter into another by clicking the Copy button
in the Filter Setup dialog, which opens the Copy Filter dialog. Or, can rename a filter by
clicking the Rename button and opening the Rename Filter dialog.
Figure 22-8. Copy and Rename Filter Dialogs

The filter you just created appears in the Filters list within the Filter Setup dialog box
(Figure 22-5).
5. Either select Apply to filter the displayed data immediately, or select Done to exit the
dialog box.

Reporting Via the Command Line

Two commands produce textual reports of functional coverage statistics.
• coverage report
• vcover report
The vcover report command allows you to produce textual reports from saved functional
coverage statistics when a simulation is not loaded.

The following is sample report output from saved data using the vcover report command.

ModelSim® SE User's Manual, v10.7 1115

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Reporting Via the Command Line

Example 22-4. Sample Output From vcover report Command

# -----------------------------------------------------------------------
# Covergroup Metric Goal/ Status
# At Least
# -----------------------------------------------------------------------
# TYPE sm_cvg 72.5% 90 Uncovered
# Coverpoint sm_cvg::int_state 50.0% 90 Uncovered
# bin idle_bin 38 500 Uncovered
# bin load_bins 5112 500 Covered
# bin send_bins 20800 500 Covered
# bin others 0 500 ZERO
# Coverpoint sm_cvg::in_hs 100.0% 90 Covered
# bin auto[0] 21448 1 Covered
# bin auto[1] 4502 1 Covered
# Coverpoint sm_cvg::out_hs 100.0% 90 Covered
# bin auto[0] 21449 1 Covered
# bin auto[1] 4501 1 Covered
# Cross sm_cvg::in_hsXint_state 62.5% 90 Uncovered
# bin <auto[0],idle_bin> 15 1 Covered
# bin <auto[1],idle_bin> 23 1 Covered
# bin <auto[0],load_bins> 633 1 Covered
# bin <auto[1],load_bins> 4479 1 Covered
# bin <auto[0],send_bins> 20800 1 Covered
# bin <auto[1],send_bins> 0 1 ZERO
# bin <auto[0],others> 0 1 ZERO
# bin <auto[1],others> 0 1 ZERO
# -----------------------------------------------------------------------
# Name Design Design Lang File(Line) Count Status
# Unit UnitType
# -----------------------------------------------------------------------
#cover_intl_sm interleaver Verilog SVA interleaver.v(140) 375 Covered

By default, the report includes coverage statistics for both covergroups and cover directives.
You can specify the -covergroup or -directive options for either the coverage report or vcover
report command to report only covergroup coverage or only cover directive coverage,
respectively.

1116 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Excluding Functional Coverage from the GUI and Reports

Excluding Functional Coverage from the GUI and

Reports
While post-processing a UCDB(Coverage View), or during live simulation, you can exclude
functional coverage from view in the GUI or reports.
To exclude functional coverage from view, use the following coverage exclude arguments:

coverage exclude -cvgpath <path_to_covergroup>

coverage exclude -assertpath <path_to_assertion>
coverage exclude -dirpath <path_to_assertion>

or

coverage exclude -code [ a | d]...

where a=assertion and d=cover directive.

Sample Commands for Excluding Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 1117

Transitive Cross Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Hiding Covergroup Instances from GUI and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119

Sample Commands for Excluding Functional Coverage

You can easily exclude functional coverage items from reports or from displaying in the GUI
with the coverage exclude command.
• To exclude a covergroup type (from the GUI or a report):
coverage exclude -cvgpath /top/mach/machcover

• To exclude a coverpoint/covercross under a covergroup type:

coverage exclude -cvgpath /top/mach/machcover/st

• To exclude a cover bin under covergroup type:

coverage exclude -cvgpath {/top/mach/machcover/st/auto[st2]}

Note the braces {}, which prevent Tcl from evaluating [st2].
• To exclude a covergroup instance:
coverage exclude -cvgpath {/top/mach/machcover/\/top/mach/cov }

Note the space at the end of the instance specification. It is intended.

ModelSim® SE User's Manual, v10.7 1117

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Excluding Functional Coverage from the GUI and Reports

• To exclude a coverpoint/covercross under covergroup instance:

coverage exclude -cvgpath {/top/mach/machcover/\/top/mach/cov /
reset}

• To remove the exclusion on the above coverpoint/covercross:

coverage exclude -clear -cvgpath {/top/mach/machcover/\/top/mach/
cov \ /reset}

• To exclude a cover bin under covergroup instance:

coverage exclude -cvgpath {/top/mach/machcover/\/top/mach/cov \ /
reset/resetseq[st2=>st2=>st0]}

Related Topics
coverage exclude [ModelSim SE Command Reference Manual]

Transitive Cross Exclusion

When you exclude a coverpoint or cross bin, all associated cross bins from all crosses where the
coverpoint participates directly or hierarchically (cross of crosses) will also be excluded if the -
transitive argument is used in the coverage exclude command.
When you want to propagate the exclusion of a bin to all the associated bins in connected
crosses, use the -transitive argument with the coverage exclude command.

coverage exclude -cvgpath <path> -transitive

The transitive exclusion applies to all associated bins in the crosses where the coverpoint or
cross participates, and propagates that hierarchically into crosses where those crosses
participate. This propagation goes recursively all the way for crosses of crosses.

If a whole coverpoint or cross is excluded, then each cross where the excluding coverpoint or
cross participates will also be excluded transitively. That means the transitive exclusion will
also work in the same way for coverpoint and cross exclusions. For example:

vsim> coverage exclude -cvgpath /top/cvg/i1/y -transitive

vsim> coverage report -excluded
# coverage exclude -cvgpath \
# /top/cvg/i1/y \
# /top/cvg/i1/x_y \
# /top/cvg/i1/y_z \
# /top/cvg/i1/x_y_z \
# /top/cvg/i1/x_yy_z

With the coverage exclude command, bin /top/cvg/i1/y is excluded transitively. The coverage
report of exclusions then shows the exclusion of all bins associated with /top/cvg/i1/y.

1118 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Excluding Functional Coverage from the GUI and Reports

Transitive exclusion works for cross userbins and autobins as well. If you exclude a cross
userbin or autobin then the associated cross bins in the cross which is associated to the first
cross (cross of crosses) will also be excluded.

vsim> coverage exclude -cvgpath /top/cvg/i1/x_y/<b2,c1> -transitive

vsim> coverage report -excluded
# coverage exclude -cvgpath \
# /top/cvg/i1/x_y/<b2,c1> \
# /top/cvg/i1/x_yy_z/<<b2,c1>,cx1> \
# /top/cvg/i1/x_yy_z/<<b2,c1>,<c2,d1>> \
# /top/cvg/i1/x_yy_z/<<b2,c1>,<c2,d2>> \
# /top/cvg/i1/x_yy_z/<<b2,c1>,<c3,d1>> \
# /top/cvg/i1/x_yy_z/<<b2,c1>,<c3,d2>> \

A cross userbin may include a range of cross products, where some are associated with an
excluding coverpoint or cross bin and others are not. In that case the userbin will not be
excluded transitively as that contains some cross products which are not related to the excluding
coverpoint or cross bin. For simplicity, if all the cross products of an userbin are associated with
an excluding coverpoint or cross bin then the userbin could be excluded transitively. Otherwise,
you need to exclude that userbin explicitly if required.

For example, say a cross 'cx' has three coverpoints cvp1, cvp2, cvp3; each of which has two
coverpoint bins: (a1, a2), (b1, b2), and (c1, c2) respectively. A user cross bin 'x1' has selected
two cross products " <a1,b1,c1>, <a2,b2,c2>". When you exclude bin a1, that logically excludes
the first cross product.transitively. But the bin 'x1' will not be excluded as the cross product
<a2,b2,c2> is still active; and doing so may cover up a hole for that active cross product. Now,
if the bin a2 is also excluded then logically both the cross products are excluded transitively.
Hence, the userbin x1 is logically excluded but is not done as a limitation as the tool does not
keep track of exclusions for each cross product due to performance and capacity reasons. So
you need to exclude the userbin x1 explicitly in this case.

Cross autobins do not have this limitation as each autobin is for a single cross product. So all the
cross autobins related to an excluding coverpoint or cross bin will be excluded.

When a crossbin is excluded transitively as an effect of excluding a coverpoint or cross bin,

there is no way to differentiate that exclusion from a regular exclusion. So clearing a coverpoint
or cross bin exclusion will not be able to clear the exclusions from transitively excluded cross
bins. Trying to do so may end up clearing regular exclusions, which is not appropriate. So the -
transitive option is not supported with the -clear option.

Hiding Covergroup Instances from GUI and Reports

In post-processing (Coverage View) a UCDB, as well as in live simulation, you can remove the
covergroup instances from the GUI and/or reports.
• To remove all covergroup instances from view in the GUI and reports:
GUI: Covergroups > Hide Covergroup Instances > All

ModelSim® SE User's Manual, v10.7 1119

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Assertion/Cover Directive Naming Conventions

Command Line: coverage report or vcover report -hidecvginsts

• To remove only covergroup instances which have option.per_instance=0:
GUI: Covergroups > Hide Covergroup Instances > Not Having per_instance
Command Line: coverage report or vcover report -hidecvginstspi0

Assertion/Cover Directive Naming

Conventions
Assertion and cover directive names are important for identification in ModelSim reports and
coverage windows, as well as for restoring in simulation with $load_coverage_db(). ModelSim
assigns names to any unnamed assertion and cover directives, but these assigned names can and
do change as changes are made to the source files in which they are located.
You can avoid this situation by explicitly naming assertions and cover directives in the
SystemVerilog source files. Consider the following properties:

my_assert: assert property (@(posedge clk) a ##1 b);

my_cover: cover property (@(posedge clk) a ##1 b);

The assertion name my_assert and cover directive name my_cover allow you to easily identify
those particular properties throughout all windows and cover reports.

Related Topics
Loading a Functional Coverage Database into Simulation

1120 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Covergroup Naming Conventions

Covergroup Naming Conventions

Covergroup instance names are important for identification in ModelSim reports and coverage
windows, as well as for restoring in simulation with $load_coverage_db(). Covergroup instance
names are stored in the option.name field of the built-in covergroup structure. You may assign
these names in SystemVerilog, in which case names should be unique. This is not an absolute
requirement, though it is recommended.
You can assign names in one of three ways:

• by directly assigning to covergroupvariable.option.name

• assigning to option.name within the covergroup declaration based upon a covergroup
argument
• using the covergroup method set_inst_name().
If you do not assign a name, the system assigns a unique name to each covergroup instance
based upon the hierarchical path of the variable to which the covergroup instance was assigned
with the "new" constructor. This generated name uses Verilog escaped identifier syntax because
this instance name becomes part of UCDB hierarchy when a UCDB is saved. For example:

module top;
covergroup ct; option.per_instance = 1; ... endgroup
ct cv = new;

In this case, the instance name will be "\/top/cv". Note the extra space at the end to terminate the
extended identifier. The report will identify the instance as "\/top/cv". The covergroup type
name will be "/top/ct" and in UCDB hierarchy the covergroup instance will appear as "/top/ct/\/
top/cv ".

If a duplicate covergroup instance name is specified in the source code, the simulator by default
issues a warning and then automatically generates a unique name to resolve the conflict. When
the vsim option -pedanticerrors is used, the duplicate name triggers a fatal error.

Covergroup in a Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121

Canonical String Representation for Coverpoint Bin Value . . . . . . . . . . . . . . . . . . . . . . 1122

Covergroup in a Class
There are a couple of unexpected cases in covergroup naming conventions that occur with the
embedded covergroup (the covergroup in a class):
• SystemVerilog 2009 requires that the embedded covergroup create an anonymous type,
while the declaration name is considered a covergroup variable. The UCDB does not use
the anonymous type name; it uses the variable name or declaration name. This has the
consequence that the simulator's context tree (seen in the Structure window) is different
from the context tree created in Coverage View mode. The coverage reports and user

ModelSim® SE User's Manual, v10.7 1121

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Canonical String Representation for Coverpoint Bin Value

interface will be consistent between interactive simulation and Coverage View mode,
but the hierarchy will not be.
Example:
module top;
class c;
int i;
covergroup ct;
coverpoint i { bins b[] = { [0:9] }; }
endgroup

In this case, the simulator hierarchy browser will show “/top/c/#ct#” as the covergroup
type. The Coverage View mode hierarchy browser will show /top/c/ct.
• Parameterized classes — There is no prescribed naming scheme for specializations of
parameterized classes. ModelSim names these as the class name suffixed by "__" and a
unique integer. These names appear in the path naming the covergroup type. For
example:
module top;
class child #(type T = bit, int size = 1 );
T [size-1:0] l1;
covergroup cg;
...
endclass
child #(logic, 3) child_inst1 = new;
child #(bit, 4) child_inst2 = new;

In this case, the hierarchy browser will show “/top/child/child__1” as the scope for the
first class specialization, and /top/child/child__2 as the scope for the second. In complex
cases, it may not be obvious which index-suffixed name corresponds to which
specialization.
Related Topics
Loading a Functional Coverage Database into Simulation
Covergroup Naming Conventions
Canonical String Representation for Coverpoint Bin Value

Canonical String Representation for Coverpoint Bin

Value
Coverpoint bin names are components of the coverage database primary key used to identify
covergroup bins. Unambiguous identification of database items is important both for simulation
coverage analysis and downstream verification management such as database merging and
cross-tool methodologies.

1122 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Canonical String Representation for Coverpoint Bin Value

To ensure unique identification, ModelSim uses the following three forms of a naming
algorithm to produce canonical string representations of coverpoint bin values:

• Decimal radix form — Uses regular decimal notation. Negative bin values have a
leading minus sign '-'. No leading zeros and no radix prefix is added.
For example, consider the bin value 3'b110. If the coverpoint type is unsigned, the
canonical string of this form is 6. If signed, the canonical string is -2.
• 4-state binary radix form — Uses regular binary notation. The binary form uses a two
character 'b prefix to distinguish itself from the decimal form, followed by a string of 4-
state binary digits. There is exactly one binary digit per bit. Leading zeros are always
maintained. The only valid characters after the 'b prefix are "01xz".
For example, consider the bin value 7'b00x11z0. The canonical string of this form is
'b00x11z0.
• Enumerated constant form — Uses enumerated constants as declared in HDL source
code. 4-state values with 'x' and 'z' are legal enum values.
For example, consider the following HDL enumerated type declaration:
enum logic[7:0] { red = 1, green = 8'h02, blue = 8'b0001x0x } ;

The canonical string of this form is one of the enumeration constants (red, green, blue).
Which of the above forms of canonical naming is applied to the coverpoint bin is determined by
the coverpoint expression type and the bin value itself, using the rules listed in Table 22-3:
Table 22-3. Which Form of Canonical Naming is Used
Coverpoint expression type Form of Canonical String Representation
2-state Decimal radix form
4-state Decimal radix form, except when there are
unknown bits (x or z), in which case it is binary
radix1
SV enumerated type Enumerated constant form.
1. It is possible that a coverpoint will have a mix of decimal and binary representations for
different bins for 4-state coverpoint expression types.

Related Topics
Covergroup Naming Conventions
Covergroup in a Class

ModelSim® SE User's Manual, v10.7 1123

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Saving Functional Coverage Data

Saving Functional Coverage Data

By default, no coverage information is saved into a Unified Coverage DataBase (UCDB) for
later post-processing applications — regardless of whether coverage statistics were collected for
a simulation — unless you explicitly save it, or if you use vsim -coverstore to save a coverstore.
For instructions on how to automatically save coverage from a simulation, see Coverage Auto-
save Coverstore.

Saving For All Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124

Saving For The Current Simulation Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Loading a Functional Coverage Database into Simulation . . . . . . . . . . . . . . . . . . . . . . . 1126
Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127

Saving For All Simulations

You can save functional coverage data (both covergroup coverage and cover directive
coverage) into the UCDB for all simulations.
Procedure
Uncomment the UCDBFilename variable in the modelsim.ini file. The default filename is
vsim.ucdb.

You can also change the default name of the database by editing that variable.

Saving For The Current Simulation Only

You can save functional coverage data into the UCDB for only the current simulation.
Procedure
You can use the coverage save command at the command line or GUI menu selections.

• Command Line — enter the coverage save -onexit command at the command line
as follows:
coverage save -onexit [UCDBFilename <name>]

• GUI — select Tools > Coverage Save from the Main window
This opens the Coverage save dialog, where you can select the type of coverage you
want to save, level of hierarchy to save, and output UCDB file name.
Once set using one of the above methods, the coverage data is saved at the end-of-
simulation, which can occur as a result of:
• an assertion failure

1124 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Saving For The Current Simulation Only

• execution of explicit $finish in Verilog

• execution of an implicit $finish
• execution of $stop
• execution of sc_stop()
• a fatal error

ModelSim® SE User's Manual, v10.7 1125

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Loading a Functional Coverage Database into Simulation

Loading a Functional Coverage Database into

Simulation
To load a functional coverage database into simulation, use the $load_coverage_db(), a standard
SystemVerilog built-in system task, which loads covergroup data once it has been saved. It
loads the data from a specified UCDB file into the current simulation. In cases where there are
differences in design hierarchy or covergroups between the loaded design and the saved UCDB
file, the $load_coverage_db system task loads as much data as possible.
The $load_coverage_db() task loads the coverage data into the simulator using the following
guidelines:

• Existing data values (bin counts, option, and type_option values) are replaced by the
corresponding values from the database file when a data object is identified.
• A covergroup TYPE is identified first by its hierarchical path in the design. Then, a
covergroup instance -- only those covergroups with option.per_instance set to 1 -- is
identified by its option.name in the list of instances of a covergroup TYPE. All
coverpoints, crosses, and bins will be identified subsequently by exactly matching their
names. A bin count is then loaded, but only if a bin is identified properly.
• If a covergroup, coverpoint, cross, or bin is present in the loaded design but absent from
the database file, then it is ignored (remains unchanged), and a non-fatal error message
is issued.
• Similarly, if a covergroup, coverpoint, cross, or bin is not identified in the design (in
other words, it exists in the database file, but is absent from the loaded design), it is
ignored and a non-fatal error message is issued.

Tip
You can suppress non-fatal error messages issued during object identification
failures using the -suppress <msgid> argument to vsim, or the "suppress = <msgid>"
directive in the modelsim.ini file.

• Bin identification tries to match bin RHS values, regardless of whether the
option.per_instance is set. Any mismatch results in a failure to load that bin and a non-
fatal error message to that effect. The bin RHS values are ignored for automatically
created cross bins, which are not identified by names; rather, they are identified by a pair
of index values stored in UCDB files. If the index values are out of bound, a non-fatal
error message is issued stating that the bin is not found: Otherwise, the bin is loaded.

Tip
Avoid loading incorrect automatically created cross bins:
If the index pair points to a different automatically generated cross bin in the
simulation, you can inadvertently load the incorrect cross bins without any notification.

Loading Behavior Related to option.per_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127

1126 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Functional Coverage
Merging Databases

Loading Behavior Related to option.per_instance

When you load a coverage database in simulation, using $load_coverage_db, ModelSim
requires that you set option.per_instance equal to 1 in all instances. Use the
SVCovergroupPerInstanceDefault, in the modelsim.ini file, to set option.per_instance for all
covergroup instances in the design.
In all of the following cases, the covergroup information will be ignored (remains unchanged)
in the loaded database and a error message is issued:

• only some instances of a covergroup have option.per_instance equal to 1

In this case, the task reports this as an error, and that covergroup fails to be loaded. To
avoid this, you must set option.per_instance equal to 1 in either all, or, none of the
instances of any covergroup.
• the covergroup TYPE does not have any instances in the loaded design
If option.per_instance is set, then the instance object is loaded, even if that instance object is no
longer referenceable (in other words, the instance variable is re-assigned to another handle
without destroying the previous object).

Related Topics
SVCovergroupPerInstanceDefault
SystemVerilog 2009 option.per_instance

Merging Databases
When merging coverage databases offline using vcover merge, the following parameters must
be the same for a given scope:
• coverage weighting
• covergroup type name
• covergroup variable name
• coverpoint name
• bin name
If coverage data exists in the source database file but does not match the data in the target
database, then it will be created in the target database.

Related Topics
vcover merge command [ModelSim SE Command Reference Manual]
Merging Coverage Data

ModelSim® SE User's Manual, v10.7 1127

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Functional Coverage
Merging Databases

1128 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 23
Verification with Constrained
Random Stimulus

SystemVerilog supports automated test bench development with random constraints, giving you
the ability to automatically generate test benches for functional verification. SystemVerilog
provides an object-oriented method for specifying constraints on random test bench values.
ModelSim then processes these constraints using a constraint solver, which generates random
values that meet those constraints.
Note
The functionality described in this chapter requires an additional license feature for
ModelSim SE. Refer to “License Feature Names” in the Installation and Licensing Guide
for more information, or contact your Mentor Graphics sales representative.

Verification Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129

Building Constrained Random Test Benches on SystemVerilog Classes . . . . . . . . . . . . 1131
Seeding the Random Number Generator (RNG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140

Verification Concepts
In many modern electronic designs, exhaustive testing is impossible because the space of all
possible inputs is too large. A simulator could not possibly reproduce all possible input vectors
in any reasonable simulation time. Moreover, exhaustive testing may not be desirable because
the set of interesting design states is much smaller than the set of possible inputs.
Ideally, it would be best to create targeted input vectors to test particular design states.
However, this is often difficult because of the knowledge or time required to create all
necessary inputs. Using constrained random stimulus allows a verification engineer to avoid the
repetitive work that the simulator can perform automatically. In addition, it is possible that you
obtain data on obscure corner cases that occur as consequences of the “random” input.

Functional coverage is required to evaluate which design states occurred (see Verification with
Functional Coverage). Without functional coverage, there is no way of knowing what of interest
actually occurred during a random test bench. It is also desirable to record the random seed with
the coverage results, which the Questa UCDB takes into account.

Finally, note that fully random verification is a rarity. While some verification teams have used
it exclusively, in most cases, random verification and targeted test vectors coexist because there
is usually some design behavior that is, after all, easy to verify with targeted test benches.

ModelSim® SE User's Manual, v10.7 1129

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Verification Concepts

ModelSim provides the following constraint solvers (commonly referred to as “engines”),

which you can choose to apply to a given verification run:

• BDD — Binary Decision Diagram. This solver interprets a constraint expression as a

circuit representation and develops a truth table format of this expression, choosing
random values for the variables based on these truth tables. While it is efficient in
evaluating bit-wise operators, it proves to be much less efficient in solving complex
constraint expressions where the solution space increases exponentially—thereby
resulting in a large solution space. The nature of BDD implementation usually results in
either enormous performance issues or inability to solve the expressions, which include:
o Multiplication, Division, and Modulo
o Array of objects
o Large number of random variables with complex operators
• ACT — Arithmetic Constraint Technology. This solver represents constraint
expressions and random variables as a graph. The constraint solver tries to find a
solution that satisfies the graph by exploring the space of possible solutions and building
up what is known as a “search tree.” The solver explores nodes (variable and constraint
expression values) in the graph and rules out possible assignments that cannot be part of
a solution.

1130 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Building Constrained Random Test Benches on SystemVerilog Classes

Building Constrained Random Test Benches

on SystemVerilog Classes
The SystemVerilog class data abstraction is ideally suited for building random stimulus.
• Classes are dynamically created, deleted, assigned and handled objects.
• Classes inherit properties and methods from other classes.
• Subclasses can redefine the parent’s methods explicitly.
These capabilities allow customization and randomization without breaking or rewriting known
good functionality in the parent class.

Random tests are built onto the SystemVerilog class system by assigning special modifiers to
class variables. The rand and randc modifiers can be used to designate a class variable as a
random variable. Class variables designated with rand modifiers are standard random variables
with values uniformly distributed over their range. Class variables designated with the randc
modifiers are random-cyclic variables that cycle through all the values randomly in their
declared range.

Values generated for random variables are controlled using constraints, as shown in
Example 23-1.

Example 23-1. The rand Variable

class Bus;
rand bit [15:0] addr;
rand bit [31:0] data;
constraint word_align {addr[1:0] == 2’b0;}
endclass

This shows a simplified bus with the addr and data random variables, which represent the
address and data values on the bus. The word_align constraint shows that only the addr random
variable is constrained, the data variable is not constrained. The data variable will be assigned
any value in its declared range.

ModelSim support of randc includes the following SystemVerilog types: integral, multi-
dimension arrays, dynamic arrays, queues, and parameterized types. randc is not supported for
associative arrays.

Generating New Random Values with randomize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132

Attributes Of Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Inheriting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Examining Solver Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138
Setting Compatibility with a Previous Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139

ModelSim® SE User's Manual, v10.7 1131

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Generating New Random Values with randomize()

Generating New Random Values with randomize()

To generate new random values, you use the randomize() virtual method.
Example 23-2 shows how to use this method to generate random values for the bus example in
Example 23-1.

Example 23-2. Generating New Random Values With randomize()

Bus busA = new;

repeat (50)
if ( busA.randomize() == 1 )
$display("addr = %h data = %h",busA.addr,busA.data);
else
$display("Randomization FAILED");
end

Every class has a built-in randomize() virtual method, declared as:

virtual function int randomize();

Calling randomize() selects new values for all random variables in an object such that all
constraints are satisfied. In Example 23-2, the busA object is created and then randomized 50
times. The result of each randomization is checked for success. If randomization is successful,
the new random values for addr and data are displayed. If randomization fails, the
“Randomization FAILED” error message is displayed and the simulation halts.

Note
If ModelSim cannot acquire the proper license to execute the call to randomize(), it will
display a fatal error message.

1132 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Attributes Of Randomization

Attributes Of Randomization
The modelsim.ini file contains numerous variables whose settings control solver behavior for
randomization. You can also use attributes that correspond to these variables when calling
randomize() to apply their control only to that call. Using an attribute allows you to override the
variable setting on a per-randomize basis.
Table 23-1 lists the attributes available for use with randomize(), along with the corresponding
modelsim.ini variable.
Table 23-1. Attributes Usable with randomize()
Attribute Variable in modelsim.ini Description
solveactmaxtests SolveACTMaxTests Maximum number of tests
that the ACT solver may
evaluate before abandoning
a solver attempt.
solvearrayresizemax SolveArrayResizeMax Maximum size randomize()
will allow a dynamic array
to be resized.
solvegraphmaxeval SolveGraphMaxEval Maximum number of
evaluations performed on
the solution graph
generated during
randomize().
solvegraphmaxsize SolveGraphMaxSize Maximum size of the
solution graph that may be
generated during a
SystemVerilog call to
randomize().

Syntax and Usage

Attributes for randomize() follow the definitions provided in the Verilog standard, IEEE Std
1364-2005 and IEEE Std 1364-2001.
To apply an attribute to a randomize() call, you include both as part an assert statement,
according to Verilog syntax conventions. You can specify multiple attributes in a single
randomize() call.

Examples:

assert(randomize (* solvearrayresizemax = 100 *) (a, b) with { a > b; });

assert(randomize (* solvearrayresizemax = 100 *) (* solveactmaxtests =

50000 *) (a, b) with { a > b; });

ModelSim® SE User's Manual, v10.7 1133

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Attributes Of Randomization

Size Constraints for Random Dynamic Arrays with

randomize()
SystemVerilog size constraints for random dynamic arrays are supported by randomize(). A
dynamic array with a size constraint may be resized by a call to randomize().
You can specify the maximum size randomize() will allow a dynamic array to be resized with
the SolveArrayResizeMax variable under the [vsim] section of the modelsim.ini file (see
modelsim.ini Variables in the appendix.). This variable specifies the maximum size
randomize() will allow a dynamic array to be resized.

If randomize() attempts to resize a dynamic array to a value greater than specified by

SolveArrayResizeMax, an error will be displayed, randomize() will fail, and the simulation will
halt. The default value for SolveArrayResizeMax is 2000. A value of 0 indicates no limit.

Debugging randomize() Failures

Conflicting constraints, such as x > 5 and x < 3, will cause the randomize() function to fail.
Procedure
You can use any one of the following three methods to debug randomize() failures caused by
conflicting constraints:

• Set the SolveFailDebug simulator control variable to 1 in the modelsim.ini file.

ModelSim will display the hierarchical path to the associated constraint name
(except for implicit or in-line constraints) and will generate a simplified testcase.
• Use the -solvefaildebug argument with the vsim command to report any conflicting
constraints with the simulation is run.
• Use the solvefaildebug SystemVerilog attribute in your source code. This attribute
can be specified with no value (implicitly set to 1), 0, or 1. This attribute overrides
the value of the SolveFailDebug modelsim.ini variable for the associated
SystemVerilog randomize() call, as well as the vsim -solvefaildebug command.
Examples
status = randomize (* solvefaildebug *) (a, b) with { a > b; a < b; };
status = randomize (* solvefaildebug=1 *) (a, b) with { a > b; a < b; };
status = randomize (* solvefaildebug=0 *) (a, b) with { a > b; a < b; };

• Use -solvefailtestcase[=<filename>] with the vsim command to enable generation of a

simplified testcase. The testcase output will be directed to the specified filename. If no
filename is specified, the testcase will be output to the Transcript. Testcases for 'no-
solution' failures will only be produced if -solvefaildebug is enabled.

1134 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Attributes Of Randomization

The following example demonstrates the difference between using -solvefaildebug=1 and -
solvefaildebug=2. Given the design:

debug.sv
module top;class TFoo;
rand bit other_mode;
rand bit m_en_ctx_reuse;
rand reg [3:0] bypass_en;
reg [3:0] bypass_en_prev; constraint c1 {
if (!m_en_ctx_reuse) {
bypass_en > 10;
}
if (other_mode) {
!m_en_ctx_reuse;
}
bypass_en < 10;
}
endclassTFoo f = new;
int status;initial
begin
status = f.randomize() with {
other_mode;
};
$display(status);
endendmodule

When -solvefaildebug=1 is used:

• $ vsim -solfefaildebug=1 -c top

VSIM 1> run -all # debug.sv(27): randomize() failed due to conflicts
between the
# following constraints:
# debug.sv(13): c1 { (bypass_en > 10); }
# debug.sv(18): c1 { (bypass_en < 10); }
# Given:
# logic [3:0] bypass_en

When -solvefaildebug=2 is used:

• $vsim -solvefaildebug=2 -c top

VSIM 1> run -all # debug.sv(27): randomize() failed due to
conflicts between the
# following constraints:
# debug.sv(13): c1 { if ((!m_en_ctx_reuse)) {(bypass_en > 10);} }
# debug.sv(16): c1 { if (other_mode) {(!m_en_ctx_reuse);} }
# debug.sv(18): c1 { (bypass_en < 10); }
# debug.sv(28): other_mode; # Where:
# other_mode = 1'h1
# m_en_ctx_reuse = 1'h0 # Given:
# logic [3:0] bypass_en

ModelSim® SE User's Manual, v10.7 1135

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Attributes Of Randomization

While evaluating constraints, you may encounter calculation overflow or underflow errors that
are not critical. If you want the solver to ignore these errors while evaluating constraints, you
can do so in either of the following ways:

• Use the solveignoreoverflow SystemVerilog attribute for the randomize() function in

your source code. This ignores the error on a per-randomize basis.
• Set the SolveIgnoreOverflow simulator control variable to 1 in the modelsim.ini file.

Specifying a Solver Engine with solveengine Attribute

You can use the solveengine attribute of randomize() to select the best constraint solver
“engine” for a particular randomization.
Procedure
Use either of the following methods:

• Use the solveengine attribute of randomize() to perform the same function as the
vsim -solveengine command.
• Use the SolveEngine variable (defined in modelsim.ini), but on a per-randomize
basis.
Examples
The following example shows how to use the solveengine attribute to choose the Arithmetic
Constraint Technology (ACT) solver for a randomize call:

module top;

class TFoo;
rand bit[7:0] a, b, c;
endclass

TFoo f = new;
int status;

initial
begin
status = randomize (* solveengine="act" *) (f);
$display(status);
status = f.randomize (* solveengine="act" *) ();
$display(status);
end

endmodule

1136 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Inheriting Constraints

Tuning the ACT Solver Engine with solveactretrycount

Attribute
You can use the solveactretrycount attribute of randomize() to choose a value for the number of
attempts the ACT solver will make to solve a randomization before quitting.
Procedure
Use either of the following methods:

• Use the solveactretrycount attribute of randomize() to choose a value.

• Use the SolveACTRetryCount variable (defined in modelsim.ini), but on a per-
randomize basis.
Examples
The following example uses the solveactretrycount attribute to choose a nonzero value for the
ACT retry count for a particular randomize call:

module top;

class TFoo;
rand bit[7:0] a, b, c;
endclass

TFoo f = new;
int status;

initial
begin
status = randomize (* solveactretrycount=1 *) (f);
$display(status);
status = f.randomize (* solveactretrycount=2 *) ();
$display(status);
end

endmodule

Inheriting Constraints
SystemVerilog constraints restrict the range of random variables and allow you to specify
relationships between those variables.
Constraints follow the same rules of inheritance as class variables so they can be inherited from
the parent class to any subclass. In this example,

ModelSim® SE User's Manual, v10.7 1137

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Examining Solver Failures

typedef enum { low, high, other } AddrType;

class MyBus extends Bus;
rand AddrType type;
constraint addr_rang {
( type == low ) -> addr inside { [ 0 : 15] };
( type == high ) -> addr inside { [128 : 255] };
}endclass

the MyBus class inherits all random values and constraints of the Bus class. A random variable
called type has been added to control the address range with the addr_rang constraint. The
value of type is used by the addr_rang constraint to select one of the three range constraints.

As you can see here, inheritance can be used to build layered constraints, giving you the ability
to develop generalized models that can be constrained to perform application-specific tasks.

Enabling/Disabling Constraints and Random Variables

The SystemVerilog constraint_mode() method enables or disables named constraint blocks in
objects. This gives you the ability to design constraint hierarchies where the lowest level
constraints can represent physical limits grouped by common properties into named constraint
blocks. These blocks can then be independently enabled or disabled. (See the IEEE Std 1800-
2009 for more information on constraint blocks.)

In the same way, rand_mode() is used to enable or disable random variables. When random
variables are disabled they behave just like nonrandom variables.

Examining Solver Failures

You may encounter situations in which the solver fails to randomize or solve the specified
constraints.
In general, solver failures fall into the following categories:

• The set of constraints cannot be solved. This is most often due to an error in specifying
constraint variables. For example:
a > b; b > c; a < c;

o If you have not specified vsim -solvefaildebug, the solver returns a status of 0 and
does not modify any random variables.
o If you have specified vsim -solvefaildebug, the solver does the following:
i. Prints the message
** Note: tb.sv(19): randomize() failed;

which indicates the file line number of the failing call to randomize().

1138 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Setting Compatibility with a Previous Release

ii. Generates a Verilog testcase that includes the constraints that cannot be solved,
which you can use to further investigate the constrain conflict.
iii. The solver then attempts to find the minimum set of constraints that produce the
conflict. In this example, all three of the constraints are required to cause the
conflict.
Note that this is a conflict in the Verilog code—the set of constraints is not solvable and
the problem is independent of solver setting. Changing the solver engine or using other
vopt switches will not correct the problem. You must fix the conflict in constraint
specification in the Verilog source code (in this example, delete: a < c;).
• The solver encounters an internal limitation.
The solver will report a message similar to the following:
file.sv(line#): randomize() failed; solution graph size exceeds
limit (SolveGraphMaxSize=value)

file.sv(line#): randomize() failed; solution graph evaluations

exceeds limit (SolveGraphMaxEval=value)

file.sv(line#): randomize() failed; ACT test count exceeds limit

(SolveACTMaxTests=value)

This type of error message indicates that the solver could not solve the constraints due to
some kind of limitation.
o If the failure is due to the values for the GraphMaxSize or GraphMaxEval variables,
increasing those values in the modelsim.ini file may help. Another correction that is
more likely to help is to change to an ACT solver engine.
o If the error is due to the value of the SolveACTMaxTests variable, increasing this
value in the modelsim.ini file may help. Another correction that is more likely to
help is to change to a BDD solver engine.
Following the error report, if you have specified vsim -solvefaildebug, the solver also
dumps a testcase containing the constraints that were run.

Setting Compatibility with a Previous Release

You can specify random sequence generation compatibility with a prior ModelSim letter release
(for the SystemVerilog solver).
Procedure
1. Use either of the following methods:
• Set the SolveRev variable in the modelsim.ini file to a previous release.
• Use the -solverev argument with the vsim command to set a previous release.

ModelSim® SE User's Manual, v10.7 1139

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Seeding the Random Number Generator (RNG)

2. The release number you designate must consist of release number and letter, such as
6.6a, but only prior letter releases within same number release are allowed. For example,
if you are using version 6.6c, you can specify 6.6b, 6.6a, or 6.6, but cannot specify 6.5f.

Note
These instructions do not apply to the SystemC/SCV solver.

Seeding the Random Number Generator (RNG)

In SystemVerilog, each thread has its own RNG state. The seed of each child thread is
initialized from the parent RNG. ModelSim gives you the ability to seed the root RNG with
either a specific integer or a random number.
Procedure
1. To seed the root RNG, use the -sv_seed argument for the vsim command.

Tip
: If you want to change the randomization seed after elaboration, you can do so by
using vsim -load_elab and vsim -elab. You can elaborate the design once using the -
elab argument and then use the -load_elab argument with different seed values specified
with -sv_seed for subsequent simulation runs.

If you do not use vsim -sv_seed, the value of the Sv_Seed variable in the modelsim.ini
file is used as the value for the initial seed. If Sv_Seed does not have a value, the initial
seed value defaults to 0.
2. You can obtain the initial value of the random seed with either of the following methods:
• Use the $get_initial_random_seed system function.
• Enter the following command in a Tcl shell window:
echo $Sv_Seed

This displays the random seed value in the shell window.

Examples
• Seed the root RNG with an integer value of 99:
vsim -sv_seed 99

• Seed the root RNG with a random number selected by ModelSim:

vsim -sv_seed random

1140 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 24
Coverage and Verification Management in
the UCDB

ModelSim provides you with tools for managing your verification environment through
coverage and use of the unified coverage database.
The features available for managing verification are:

• the merging and aggregation of coverage data

• ranking of tests
• ranking of tests within a testplan
• analysis of coverage in light of late-stage ECOs
• test and command re-runs
• various analyses of coverage data
• generation of easy-to-read HTML coverage reports
Additional Verification Management tools and capabilities (such as importing a verification
plan to track your verification requirements, the Verification Tracker window, Results Analysis,
and Trending) are available through the use of the “qvman” license feature. See the Questa SIM
Verification Management User’s Manual for further information.

Coverage and Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143

A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
Calculation of Total Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Where to Find Coverage Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage and Simulator Use Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Coverage View Mode and the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Running Tests and Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Collecting and Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Name Selection for Test UCDB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155

ModelSim® SE User's Manual, v10.7 1141

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB

Understanding Stored Test Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158

Test Attribute Records in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Predefined Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Managing Test Data in UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
Viewing and Analyzing Verification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Storing User Attributes in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Customizing the Column Views in Verification Windows . . . . . . . . . . . . . . . . . . . . . . . . 1185
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Analysis for Late-stage ECO Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207

1142 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage and Verification Overview

Coverage and Verification Overview

Verification Management within ModelSim is a set of functionality which allows you to
manage your test environment.
A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144

A Flow for Verification of Coverage

The flow described below represents a typical design verification process as it can be applied in
the ModelSim environment.
Figure 24-1. Verification of a Design

Every project starts with a design specification. The specification contains elaborate details on
the design construction and its intent.

ModelSim® SE User's Manual, v10.7 1143

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
What is the Unified Coverage Database?

A verification team uses the design specification to create a verification plan. The verification
plan contains a list of all questions that need to be answered by the verification process (the
golden reference). The verification plan also serves as a functional spec for the test bench.

Once the test bench is built and the designers succeed in implementing the design, you simulate
the design to answer the question: “Does it work?”. If the answer is no, the verification engineer
gives the design back to designers to debug the design. If yes, it is time to ask the next question:
“Are we done yet?”. Answering this question involves investigating how much of the design
has been exercised by looking at the coverage data and comparing it against the verification
plan.

What is the Unified Coverage Database?

The Unified Coverage DataBase (UCDB) is a single persistent form for various kinds of
verification data, notably: coverage data of all kinds, and some other information useful for
analyzing verification results.
The types of coverage data collected in the database include:

• Code coverage: branch, condition, expression, statement, and toggle

• Finite State Machine (FSM) coverage
• SystemVerilog covergroup coverage
• Questa Formal analysis results for OVL, QVL, and SVA/PSL properties
• Verification Plan data
• Links between the Verification Plan and coverage data
• SystemVerilog and PSL assertion coverage
• Assertion data (including immediate and concurrent assertions, and pass, non-vacuous
pass, fail, attempt and other counts)
• User-defined data
• Test data
The UCDB is used natively by ModelSim for all coverage data, deprecating previous separate
file formats for code coverage and functional coverage.

When created from ModelSim, the UCDB is a single “snapshot” of data in the kernel. Thus, it
represents all coverage and assertion objects in the design and test bench, along with enough
hierarchical environment to indicate where these objects reside. This data is sufficient to
generate complete coverage reports and can also be combined with data acquired outside
ModelSim, for example, Questa Formal created functional coverage and other user-defined
data.

1144 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
What is the Unified Coverage Database?

For more information about the coverage data contained in the UCDB, see “Understanding
Stored Test Data in the UCDB”.

Weighted Coverage
Weighting is a decision the verification engineer makes as to which coverage types are more
important than others within the context of the design and the objectives of the test bench.

Weightings might change based on the simulation run as specific runs could be set up with
different test bench objectives. The weightings would then be a good way of filtering how close
the test bench came to achieving its objectives.

For example, the likelihood that each type of bus transaction could be interrupted in a general
test is very low as interrupted transactions are normally rare. You would probably want to
ensure that the design handles the interrupt of all types of transactions and recovers properly
from them. Therefore, you might construct a test bench such that the stimulus is constrained to
ensure that all types of transactions are generated and that the probability of transactions being
interrupted is relatively high. For that test bench, the weighting of the interrupted transaction
cover points would probably be higher than the weightings of uninterrupted transactions (or
other coverage criteria).

ModelSim® SE User's Manual, v10.7 1145

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Calculation of Total Coverage

Calculation of Total Coverage

The calculation of Total Coverage which appears in various windows and reports depends on
several factors, discussed in the following sections.
Where to Find Coverage Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150

Where to Find Coverage Totals

A summary of all coverage types in one aggregated total is available in many places throughout
the GUI and CLI.
Specifically, total coverage figures are shown in the:

• Structure (sim) window: Total Coverage column

• Verification Tracker window: Coverage column
• Verification Browser window: Total Coverage column
• HTML coverage report: Design Coverage Summary section
• command output in the Transcript window for coverage analyze, coverage report,
vcover report, and vcover ranktest.
• Ranking summary from vcover ranktest
The coverage aggregation depends on whether the scope of interest is a design unit or an
instance:

• Design Units — aggregated coverage for a specific design unit is the weighted average
of all kinds of coverage found within it. For coverage summary statistics viewable in the
above listed locations, the coverage number is pre-aggregated into the design unit. This
pre-aggregation behaves like a merge operation, where the coverage of the design unit is
the union of coverage in all the instances of that design unit. This pre-aggregation occurs
for all code coverage types, functional coverage (both covergroups and cover
directives), and assertions which have succeeded or have been formally proven to
succeed. The coverage weight command allows these to be weighted independently, but
globally, in the aggregation computation. This is equivalent to averaging together the
numbers reported by specifying -bydu to the coverage report command for that
particular design unit and is weighted by the coverage weights shown by specifying -
bydu with the coverage weight command.

1146 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage Binning and Calculation

• Instances — aggregated coverage for an instance is computed from the weighted

average of all different types of coverage found within the entire subtree rooted at that
instance (recursive view, the default) or within the particular instance (local view). View
coverage locally in the Structure window by deselecting Code Coverage > Enable
Recursive Coverage Sums.
In the Verification Tracker window, testplan sections are treated similarly to instances in
the Structure window. Refer to “Coverage Calculation in the Tracker Window”for
specific information.
Aggregation totals include the following coverage:

• All code coverage types — statements, branches, conditions, expressions, FSM, and
toggles
• Covergroups, coverpoints, and cover directives — The crux of SystemVerilog
functional coverage reporting is that coverage for a bin is binary. A bin is either covered
or not covered, while coverage statistics are aggregated within a coverpoint and within
covergroups as a percentage of desired coverage. Coverage statistics may be aggregated
among all instances of a covergroup or per instance.
• assertions which have succeeded or have been formally proven to succeed. A successful
assertion is one that has never failed and whose pass count does not equal (or is greater
than) zero. Use vsim -assertcounts or vsim -assertdebug to enable pass counts.

Note
The -assertdebug argument requires that you use vopt +acc=a or vsim -
voptargs="+acc". The -assertcounts argument does not have this requirement.

The Ranking summary from the vcover ranktest command includes contributing and
noncontributing tests. For example:

Ranking summary:
Total coverage = 90.34%
Total CPU time = 52.06
Total SIM time = 66021930.00 ns
# contributing tests = 9
Test order: <ordered list of contributing ucdb files>
# non-contributing tests = 1
Non-contributing tests: <list of non-contributing ucdb files>

Coverage Binning and Calculation

The calculation of coverage in terms of how the items are binned is expressed in this section.
The general algorithm for coverage aggregation can be expressed in the following formula:

ModelSim® SE User's Manual, v10.7 1147

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Binning and Calculation

where:

cov(t) = #covered bins / #bins1

t = the set of all coverage types

The coverage types (t) are as shown in Table 24-1. Each type of coverage has its own definition
of how bins are created and how many bins exist.

Aggregation is performed across different scopes depending on the UI command issued (that is,
you can aggregate across a single design unit, or you can aggregate across the entire design, or
various ranges between those extremes). The region in which coverage is calculated is known as
the “scope of aggregation”. For each coverage type, cov(t) is calculated across the complete set
of bins visible in the scope of aggregation.

Individual weights can be assigned for all coverage types in table below, using the coverage
weight command. Additional methods for assigning weights are detailed for each type.
Table 24-1. Coverage Calculation for Each Coverage Type
Coverage Binning and Calculation Methods for cov(t) Weighting1
Type
Assertion There is one bin per assertion, which defines the Each assertion is weighted
pass status of the assertion. If neither equally — individual weight
-assertcover nor -assertdebug are used with vsim, assertions through the
the bin consists of only one bit that is set to 1 if ModelSim user interface2
the assertion passes, and 0 if it does not (that is,
if the assertion status is fail, vacuous, disable or
active). If either -assertcover or -assertdebug are
used with vsim, the Pass Count is a 32-bit value
that stores the actual count of assertion passes.
Branch All True branches and “AllFalse” branches in the Weighted equally
scope of aggregation form the complete set of
bins. Calculation follows the general algorithm.
Condition All FEC table rows in the scope of aggregation Weighted equally
form the complete set of bins. Rows that contain
X and Z values are excluded. FEC numbers are
calculated separately, then the weighted average
is calculated for Condition coverage.
Covergroup Performed as if $get_coverage() was called on Controlled by
the scope of aggregation. $get_coverage() is type_option.weight
described in SV1800-2009, Clause 19.11,
Coverage Computation.

1. In the case of conditions/expressions, this # is of terms rather than bins.

1148 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage Binning and Calculation

Table 24-1. Coverage Calculation for Each Coverage Type (cont.)

Coverage Binning and Calculation Methods for cov(t) Weighting1
Type
Cover There is one bin per cover directive. The bin Weighted equally, unless -
Directive count is incremented when the cover directive weight is used with the
passes. fcover configure command
Expression All FEC table rows in the scope of aggregation Weighted equally
form the complete set of bins. Rows that contain
X and Z values are excluded. FEC numbers are
calculated separately, then the weighted average
is calculated for Expression coverage.
FSM The complete set of states in the scope of Weighted equally
aggregation forms the state bins, similar for
transitions. State coverage and Transition
coverage are calculated separately according to
the general formula. Then the weighted average
is calculated for FSM coverage.
Statement There is one bin per statement. The bin count is Weighted equally
incremented when the statement executes.
Toggle Binning varies based on the type of togglenode. Toggle nodes are effectively
Enum, integer, and real types are binned weighted according to how
specially. Extended toggle mode binning is many bins exist for the type
different than regular toggle mode binning. See of togglenode
Toggle Coverage and Understanding Toggle
Countsfor further description. The complete set
of all toggle bins in the scope of aggregation is
used when calculating cov(t).
1. Individual weights assignment supported for all types using coverage weight command.
2. Assertions can also be weighted through the UCDB or UCIS API.

Note
Weights in the coverage weight command for assertion counts (other than non-vacuous
passes) are not used for any purpose.

The weights, listed by the different kinds of coverage, are shown by entering:

coverage weight -byinstance

You can find out exactly what the coverage was for each coverage type using either of the
following commands:

coverage analyze -path <instance> -summary

coverage analyze -du <du_name> -summary

ModelSim® SE User's Manual, v10.7 1149

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Aggregation in the Structure Window

The information returned by these commands, along with Table 24-1, can help you understand
the Total Coverage number. See coverage analyze for further details.

Coverage Aggregation in the Structure Window

Aggregated coverage data is displayed in Total Coverage column of the Structure (sim)
window.

Coverage Calculation in the Browser Window

The Browser window's Total Coverage column is calculated similarly to the Total Coverage
column in the Structure window.
However, in the Browser window, all design roots are taken into account in the calculation. This
includes packages, top level modules, and other top level design units. Furthermore, the
Browser's calculation is always done recursively, which means that all hierarchy underneath all
design roots is taken into account.

Coverage Calculation in the Tracker Window

In the Tracker window's Coverage column, two distinct cases of coverage calculations are
presented: one occurs when the section is a leaf testplan section, another when the section is a
non-leaf testplan section.
• A leaf testplan section is a section which only has individual coverage links. The
numbers from those links are combined using the usual per-type global weighting.
• A non-leaf testplan section is a section which has one or more child testplan sections.
The calculation for a non-leaf testplan section is always performed recursively.
Weighting is performed across all immediate child testplan sections as usual, according
to the weight assigned to each section. In addition, if there are any coverage links in a
non-leaf testplan section, those are combined together and treated as a single child
testplan section with a weight of 1.
Related Topics
Coverage Calculation in Testplans [Questa Verification Management User's Manual]

1150 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage and Simulator Use Modes

Coverage and Simulator Use Modes

Most commands related to coverage are used in one of three simulation use modes that
correspond to the type of coverage analysis required.

Table 24-2. Coverage Modes

Mode Type of Commands to Use
Coverage
Analysis
Simulation Mode Interactive coverage, toggle, and vcover commands
simulation (such as clear, merge, report, save, tag,
unlinked...)
Coverage View Post-process coverage open <file>.ucdborvsim -
Mode viewcov <file>.ucdb
Opens <file>.ucdb in the GUI.
All coverage-related commands are
available
Batch Mode Batch simulation vcover commands (such as merge,
report, stats, testnames...)

Each of these modes of analysis act upon a single, universal database that stores your coverage
data, the Unified Coverage Database.

Coverage View Mode and the UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151

Coverage View Mode and the UCDB

Raw UCDB coverage data can be saved, merged with coverage statistics from the current
simulation or from previously saved coverage data, and viewed at a later date using Coverage
View mode.
Coverage View mode allows all ModelSim coverage data saved in the UCDB format – code
coverage, covergroup coverage, directive coverage, and assertion data – to be called up and
displayed in the same coverage GUIs used for simulation. The coverage view invocation of the
tool is separate from that of the simulation. You can view coverage data in the Coverage View
mode using the coverage open command or vsim -viewcov.

ModelSim® SE User's Manual, v10.7 1151

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Running Tests and Collecting Data

Running Tests and Collecting Data

Elemental to managing your verification is the collection of data from tests run, and an
understanding of the data that has been collected. The following sections outline the details of
data collection and the UCDB database itself.
Collecting and Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Name Selection for Test UCDB Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155

Collecting and Saving Coverage Data

When you run tests, the coverage data which you instruct the simulator to save is placed in the
Unified Coverage DataBase (UCDB).
The UCDB is a single persistent form for various kinds of verification data, notably: coverage
data of all kinds, and various other information that can be useful for analyzing verification
results. For more information on the UCDB, see “What is the Unified Coverage Database?”.

To save coverage:

• Automatically save coverage data into a coverstore using the vsim -coverstore
argument. See “Coverage Auto-save Coverstore” for more information.
• Select the type of code coverage to be collected (vopt/vlog +cover). See “Specifying
Coverage Types for Collection”.
• Enable the coverage collection mechanism for the simulation run. See “Enabling
Simulation for Code Coverage Collection”.
• Optionally, you can name the test UCDB files. If not explicitly named, the name will be
taken according from the UCDB file. See “Name Selection for Test UCDB Files”.

Tip
If you are saving test data for later test-associated merging and ranking, it is
important that the name for each test be unique. Otherwise, you will not be able to
distinguish between tests when they are reported in per-test analysis.

• Run the simulation.

Name Selection for Test UCDB Files

The naming of test UCDBs can be either implicit (default), or explicit (set by you).
The following rules apply.

1152 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Saving Coverage Data

1. The implicit, default test name is based on the UCDB filename specified in the coverage
save command.
2. Explicitly setting the name always takes priority, such as:
coverage attribute -test mytestname

or
coverage save -testname <name> <name>.ucdb

3. If running a UVM (or OVM) test, you can specify that the OVM/UVM testname be used
for the coverage UCDB using commands similar to the following:
a. Define the testname within UVM using a plusarg to the vsim command, such as:
vsim +UVM_TESTNAME=mytest
b. Use the coverage save -uvmtestname switch to define the test name defined in the
UVM (mytest), such as:
coverage save -uvmtestname <other args> <file_name>
For more detailed information on this recommended method for setting OVM/UVM test
names, as well as other methods, see the Verification Academy website
(www.verificationacademy.com) or the OVM and UVM Cookbooks, available on the
same website.
4. To name tests according to a seed using “coverage save -seed [value]”: the default
UCDB name is used with the specified “_<seed value>” appended to it. If no value is
specified, 0 is used.

Saving Coverage Data

Optionally, you can save the coverage data to a UCDB for post-process viewing and analysis.
The coverage data you have collected can be saved either on demand, or at the end of
simulation.

Saving Data On Demand

You can save UCDB data on demand.

Options for saving coverage data dynamically (during simulation) or in Coverage View mode
are:

• GUI: Tools > Coverage Save

This brings up the Coverage Save dialog box, where you can specify coverage types to
save, select the hierarchy, and output UCDB filename.
• coverage save CLI command

ModelSim® SE User's Manual, v10.7 1153

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Saving Coverage Data

During simulation, the following command saves data from the current simulation into a
UCDB file called myfile1.ucdb:
coverage save myfile1.ucdb

While viewing results in the Coverage View mode, you can make changes to the data
(using the coverage attribute command, for example). You can then save the changed
data to a new file using the following command:
coverage save myfile2.ucdb

• $coverage_save or $coverage_save_mti system tasks (not recommended)

The non-standard SystemVerilog $coverage_save_mti system task saves code coverage
data only. It is not recommended for that reason. The $coverage_save system function is
defined in the IEEE Std 1800; current non-compliant behavior is deprecated and also,
therefore, not recommended. For more information, see “Simulator-Specific System
Tasks and Functions.”
Saving Data at End of Simulation
By default, coverage data is not automatically saved at the end of simulation. To enable the
auto-save of coverage data, set a legal filename for the data using any of the following methods:

• GUI: Tools > Coverage Save. Enable the “Save on exit” radio button.
This brings up the Coverage Save dialog box, where you can also specify coverage types
to save, select the hierarchy, and select the output UCDB filename.
• UCDBFilename=“<filename>”, set in modelsim.ini
By default, <filename> is an empty string ("").
• coverage save -onexit command, specified at the Vsim> prompt
The coverage save command preserves instance-specific information. For example:
coverage save -onexit myoutput.ucdb

• $set_coverage_db_name(<filename>), executed in the SystemVerilog code

If more than one method is used for a given simulation, the last command encountered takes
precedence. For example, if you issue the command coverage save -onexit vsim.ucdb before
simulation, but your SystemVerilog code also contains a $set_coverage_db_name() task, with
no name specified, coverage data is not saved for the simulation.

Related Topics
Running Tests and Collecting Data
Merging Coverage Data
Ranking Coverage Test Data

1154 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Rerunning Tests and Executing Commands

Rerunning Tests and Executing Commands

You can rerun tests and execute sets of commands from the command execution functionality of
the Verification Browser.
Restrictions and Limitations
The requirement discussed in this section applies only if:

• you are running multiple simulations using the same UCDB filename and you have used
the same UCDB name in different directories (fred/cov.ucdb, george/cov.ucdb, and so
forth), or
• you are loading multiple UCDBs from the same basic test (that is, fred.ucdb is the basic
test and you want to create multiple runs of that test).
If either of these cases is true, your initial simulation run (the one you intend to re-run) must
include a command to set the TESTNAME attribute. Failure to set the TESTNAME attribute in
these cases may result in otherwise unique tests being identified as duplicates (and therefore not
executed) by the re-run algorithm and in the merge/rank output files. See the Tip below for
further information.

To explicitly set the TESTNAME attribute in simulation, include a command such as:

coverage attribute -name TESTNAME -value <unique_test1>

See coverage attribute for command syntax.

Tip
When you rerun a test, the simulator uses an attribute called TESTNAME, saved in each test
record, to build a list of unique files selected for re-run of that test. By default, the
TESTNAME is the pathless basename of the UCDB file. See “Multiple Test Data Records with
Same Name” for further details on ensuring unique test data records for subsequent runs.

Procedure
1. Enter the re-run setup:
a. Select one or more UCDB files.
b. Right-click and select Command Execution > Setup.
This displays the Command Setup dialog box, shown in Figure 24-2.

ModelSim® SE User's Manual, v10.7 1155

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Rerunning Tests and Executing Commands

Figure 24-2. Command Setup Dialog Box

The Command Execution Setup dialog box allows you to select and view user-
defined command setups, save new setups, and remove run setups previously saved.
You can either select an existing test to re-run, or enter the following commands to
run individually:
o Pre-command — a script you may need to run once at startup, prior to the run

1156 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Rerunning Tests and Executing Commands

o Execute Command — commands to execute: This field is pre-populated with

the command(s) necessary to rerun the test(s) selected when you opened the
dialog.
o Post-command — a script you may need to run at the end (for example, a
cleanup script)
You can also select a radio button to apply the original seed (defined by the last run
wherein the vsim -sv_seed random argument was used) to the current execution.
c. Click OK to apply the setup as edited.
2. Rerun the test: Right-click in the Browser window, and select:
• Command Execution > Execute on All to rerun all tests listed in the browser, or
• Command Execution > Execute on Selected to run only those tests associated with
the currently selected UCDB files.
Related Topics
Running Tests and Collecting Data
Ranking Coverage Test Data
Merging Coverage Data

ModelSim® SE User's Manual, v10.7 1157

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Understanding Stored Test Data in the UCDB

Understanding Stored Test Data in the UCDB

When you save a set of coverage data into the UCDB, that data is written into individual test
data records, one for each test that is run.
When you perform a merge on multiple UCDBs, the process concatenates all test data records
with unique test names into the merged UCDB file.

If you merge two tests that have identical names but different data contents, a warning is issued.
For information on making test names unique, see “Multiple Test Data Records with Same
Name”.

A merged file contains one test data record for each of the different tests that were merged into
the file. For example, if you merged three UCDBs saved from simulation (vsim), you get three
test attribute records. If you merge that file with another one saved from vsim, you get 3 + 1 = 4
test data records, and so on.

Test Attribute Records in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158

Predefined Attribute Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159

Test Attribute Records in the UCDB

The test record contains “layers” of information. Each test record contains test record attributes
(fields) which, in turn, contain two sub-sets of attributes. Specifically, these are:
• predefined attributes — These contain information about the test, such as the tool
specific arguments and switches, the date and time that the simulation was run, the
amount of CPU time taken, the name of user that ran the test, and so on.These
predefined attributes define the columns that appear by default in the Browser window
and the Tracker window when you view a UCDB. See Table 24-3 for a list of predefined
attributes which appear as columns.
• user-defined attributes (as name/value pairs) — The values of these attributes define
the columns that you can select to appear in the Browser window, and that appear by
default in the Tracker window. See “Storing User Attributes in the UCDB” for
instructions on creating user-defined attributes.
Test attribute records are stored in the UCDB when you save your coverage information. One
test attribute record exists for each simulation (test). Each test attribute record contains name-
value pairs — which are attributes themselves — representing information about that particular
test. Many of these attributes within the test attribute record are predefined, however, you can
also create your own using the coverage attribute command.

1158 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Predefined Attribute Data

Several methods are available which allow you to interface with the test record and its
attributes. These include:

• the UCDB API (Application Programming Interface). See the UCDB API User’s
Manual for further details.
• the UCIS database API (Application Programming Interface). See the Accellera Systems
Initiative Unified Coverage Interoperability Standard (UCIS), a user’s reference
document, for further details.
• the CLI (Command Line Interface) See the Reference Manual for command syntax.
• directly within SystemVerilog using the DPI (Direct Programming Interface). See the
appendix entitled “Verilog Interfaces to C”.
Using one of these methods it is possible to set values to the default fields or add any number of
user defined fields to carry other interesting information about the verification run.

Predefined Attribute Data

Each field in the UCDB test data record contains an attribute with a default value based on your
simulation.
You can override specific values for this predefined data.

• In simulation mode, override the values using the “coverage attribute” command
• Before saving the UCDB file, use the “coverage save” command.
Table 24-3 lists fields in the test attribute record (in the UCDB) that are predefined for users.

Caution
On Overloading Predefined Attributes:
Some risk is inherent in overloading a predefined attribute (such as TESTSTATUS). If you
change the setting of a predefined attribute to outside the set of expected values, unintended
behavior may result.

Table 24-3. Predefined Fields in UCDB Test Attribute Record

Field / Override with Setting/Description
Attribute Name “coverage attribute”
CLI Command
TESTNAME -name <testname> Name of the coverage test. This is also the name
-value <string> of the test record. If not set through CLI, the
default name is the base name of the file when
the database is saved.

ModelSim® SE User's Manual, v10.7 1159

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Predefined Attribute Data

Table 24-3. Predefined Fields in UCDB Test Attribute Record (cont.)

Field / Override with Setting/Description
Attribute Name “coverage attribute”
CLI Command
SIMTIME Simulation time at completion of the test.
(In ModelSim, the $Now TCL variable contains
the current simulation time in a string of the
form: simtime simtime_units.)
TIMEUNIT Units for simulation time: “fs”, “ps”, “ns”, “us”,
“ms”, “sec”, “min”, “hr”.
CPUTIME CPU time for completion of the test.
(In ModelSim, the simstats command returns
the CPU time.)
DATE Timestamp is at the start of simulation.
If created by ModelSim, this is a string of the
format:
yyyymmddhhmmss
for example:
20060105160030
which represents 4:00:30 PM January 5, 2006
VSIMARGS -name VSIMARGS Simulator command line arguments.
-value <string>
USERNAME -name USERNAME User ID of the user who ran the test.
-value <string>
TESTSTATUS -name TESTSTATUS Status of the test, where the values1are either an
-value <int> integer (transcript) or an enumerated value
(GUI):
0 (OK) - this is the default setting
1 (WARNING) - severity level
2 (ERROR) - severity level
3 (FATAL) - severity level
4 (MISSING) - as a result of a merge operation,
indicates a directed test missing in UCDB that
is referenced in the testplan
5 (MERGE_ERROR) - indicates an error
during the merge process
ORIGFILENAME Name of the test file.

1160 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Predefined Attribute Data

Table 24-3. Predefined Fields in UCDB Test Attribute Record (cont.)

Field / Override with Setting/Description
Attribute Name “coverage attribute”
CLI Command
SEED -seed <int> Randomization seed for the test. (Same as the
seed value provided by the “-sv_seed” vsim
option.)
COMPULSORY -compulsory <0|1> Whether (1) or not (0) this test should be
considered compulsory (always included in
ranked lists)
RUNCWD Current working directory for the test.
HOSTNAME Computer identification
HOSTOS Operating System
WLFNAME Associated WLF file for the test.
LOGNAME Associated transcript or log file for the test.
TESTCOMMENT -comment String (description) saved by the user associated
with the test.
This field will only appear when explicitly
specified.
TESTCMD -command Test script arguments. Used to capture “knob
settings” for parameterizable tests, as well as
the name of the test script. This field will only
appear when explicitly specified.
1. The listed TESTSTATUS values (integer) are reserved within ModelSim to indicate severity levels and
other messages. If creating a new status indicator, it is strongly suggested that you use integers 6 and above.

Related Topics
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]
Importing an XML Verification Plan [Questa Verification Management User's Manual]
coverage analyze [ModelSim SE Command Reference Manual]
xml2ucdb.ini Configuration File [Questa Verification Management User's Manual]
Storing User Attributes in the UCDB

ModelSim® SE User's Manual, v10.7 1161

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Managing Test Data in UCDBs

Managing Test Data in UCDBs

Once you have run tests and collected coverage, the real task of analyzing the coverage can
begin. Managing the coverage data which has been collected and stored in one or more UCDBs
is critical to the task.
For example, you might have a coverage on a design which includes both the test bench and the
DUT (design under test). But, you would like to separate out coverage of the TB from that of the
DUT to examine them separately.

Another example scenario would be if you have run 100 test runs, all using different stimulus.
Next, you would want to analyze the data in those UCDBs to determine the coverage
redundancy, and eliminate extraneous tests. You can merge and rank the data for just this
purpose.

You can also merge a verification plan (or “testplan”) with the actual coverage test data
contained in the UCDB(s). If you are merging a verification plan with UCDB test data, you
must have an imported testplan in UCDB format.

You can also edit a UCDB, modifying its contents, using the coverage edit command. See
“Modifying UCDBs”.

Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162

Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179

Merging Coverage Data

When you have multiple sets of coverage data, from multiple tests of the same design, you can
combine the results into a single UCDB by merging the UCDB files.
The merge utility supports:

• instance-specific toggles
• summing the instances of each design unit
• source code annotation

1162 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Merging Coverage Data

• printing of condition and expression truth tables

• cumulative / concurrent merges
• a “master” merge, whereby you can identify a UCDB to use as the superset of test data
to merge with other tests.
The coverage data contained in the merged UCDB is a union of the items in the UCDBs being
merged. For more information, see “About the Merge Algorithm”.

A file locking feature of the merge allows for cumulative merging on a farm — “vcover merge
out1 out1 in” — such that the out1 file is not corrupted with multiple concurrent merges. It
recovers from crashing merges, crashing hosts, and allows time-out of merges, as well as
backups of the previous output.

You can merge test data using the:

• GUI: Verification Browser window

• Command Line: See the vcover merge command for syntax
Procedure
1. Select the .ucdb file(s) to merge.
2. Right-click over the filenames and select Merge.
This displays the Merge Files dialog box, as shown in Figure 24-3. The various options
within the dialog box correspond to the arguments available with the vcover merge
command.

ModelSim® SE User's Manual, v10.7 1163

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Merging Coverage Data

Figure 24-3. File Merge Dialog

3. Fill in the fields in the Merge Files dialog box, as required. A few of the more important,
less intuitive fields are highlighted here. For full details related to these fields, see
vcover merge.
• Set the Hierarchy Prefix: Strip Level / Add Prefix to add or remove levels of
hierarchy from the specified instance or design unit.
• For Exclusion Flags, select AND when you want to exclude statements in the output
file only if they are already excluded in all input files. When OR is selected (default)
the output merge file excludes a statement if the statement is already excluded in any
of the input files.
• Totals merge is the default Merge Level. A test-associated merge is required for any
test analysis features such as “coverage analysis”, the Tracker window’s Test
Analysis, and such. To understand the difference between the two merges, refer to
“Test-Associated Merge versus Totals Merge Algorithm”.
For a description of what is not supported with the Totals merge, see “Limitations of
Merge for Coverage Analysis”.
4. Click OK.
This creates the merged file and loads the merged file into the Verification Browser
window.

1164 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Higher Performance Merge

Results
If the merge was successful, a transcript message such as the following appears:
# Merge in Process......
#
# Merging file C:/QuestaSim_<ver>/examples/ucdb/testplan/DataTest.ucdb
# Merging file C:/QuestaSim_<ver>/examples/ucdb/testplan/FifoTest.ucdb
# Merging file C:/QuestaSim_<ver>/examples/ucdb/testplan/IntialTest.ucdb
# Merging file C:/QuestaSim_<ver>/examples/ucdb/testplan/ModeTwoTest.ucdb
# Writing merged result to merge.ucdb

Related Topics
Merging with the vcover merge Command
Ranking Coverage Test Data
Warnings During Merge

Higher Performance Merge

An alternative merge use model is provided which reduces data storage and provides better
merge performance. It is called a Coverstore merge.
The use model which is defined in Merging Coverage Data remains unchanged, and acts as the
default merge.

This alternative, coverstore flow is comprised of the following:

• Invoke vsim with -coverstore option to specify a directory path where the simulator will
dump coverage data at the end of the simulation. The user does not need to save the
coverage data explicitly. All the simulation runs in a regression should use the same
coverstore directory path and their design hierarchy needs to be the same for this new
use model.
• Invoke vsim with -testname option along with the -coverstore option to specify the name
of the running test.
• After the coverage data is accumulated in the coverstore area from all the simulation
runs, merge the coverage data and create a self-contained UCDB file for further
analysis. You simply need to specify the coverstore directory path as an input to the
vcover merge. No other option is required.
• You can also dump the output of a merge to a coverstore directory instead of creating the
output UCDB file by using the -outputstore option to specify the output directory path.
This is useful when the user merges the outputs of lower level merges in a hierarchical
merge.
• The coverage data by default is stored using single-bit counters for code coverage items
(statements, branches, conditions, expressions, fsms, toggles), and multi-bit counters for

ModelSim® SE User's Manual, v10.7 1165

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Higher Performance Merge

functional coverage items (covergroups, cover directives, assertions). That means we

store 1 for a code coverage bin whose count is greater than 0. The user can specify
which coverage types to be stored using single-bit counters and which coverage types to
be stored using multi-bit counters. The -multicount[=-a|b|c|-d|e|f|-g|s|t] option is added
for that. The '-' is preceded to functional coverage types whose defaults are multi-bit, so
the user can turn those coverage types to single-bit by using it. For example, -
multicount=f-gt will turn the fsm and toggle coverage types to multi-bit and covergroup
coverage type to single bit, keeping the other coverage types as unchanged.

1166 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Merging with the vcover merge Command

Merging with the vcover merge Command

The vcover merge command allows you to merge multiple coverage data files offline, without
first loading a design.
This vcover merge command is a standard ModelSim utility that can be invoked from the shell
command line. For example:

vcover merge output inputA.ucdb inputB.ucdb

merges coverage statistics in UCDB files inputA.ucdb and inputB.ucdb and writes them to a
new UCDB file called output.

Matching the Paths of Corresponding Coverage Items . . . . . . . . . . . . . . . . . . . . . . . . . . 1167

Merging Using a Master UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167

Matching the Paths of Corresponding Coverage Items

When merging two UCDBs, corresponding coverage items must have the identical path.
Otherwise, they will be merged as separate coverage items. Therefore, before merging some
UCDBs, paths might need to be altered.
You can use the coverage edit command to modify the paths.

Procedure
1. Load the UCDB into vsim in “viewcov” mode, using a command such as:
vsim -viewcov <UCDB file>

2. Use the “coverage edit” command line tool to change the design path(s):
coverage edit -movedesign <source path> <dest path>

3. Write out the modified UCDB:

coverage save <new UCDB file>

Related Topics
vcover merge [ModelSim SE Command Reference Manual]
Merging Using a Master UCDB
Warnings During Merge

Merging Using a Master UCDB

As a design changes over a period of time, you may want to merge UCDB files generated earlier
with newer UCDBs generated from the same design.

ModelSim® SE User's Manual, v10.7 1167

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Merging with the vcover merge Command

Consider the case where you made changes in the DUT or in the testbench, such as changing a
regular covergroup bin to an ignore_bin, or adding or deleting various scopes and bins. The best
way to manage those changes would be to merge them into the new UCDB using a “master”
UCDB. The “master” UCDB is the file that reflects the latest state of your design and contains
all the items you want to see. Essentially, the master merge provides a method to ignore
anything that is not present in the master UCDB file, while merging master UCDB data with
other regular UCDB files. You can use the “vcover merge -master” command to filterout stale
data. For example:

vcover merge out.ucdb in1.ucdb in2.ucdb -master master.ucdb

The master merge does the following:

• Merges the content of the master UCDB, which results in adding up bin counts from the
master UCDB in the final merged file (output.ucdb).
• Merges any scope of a coveritem from the other input files, if and only if the
corresponding scope or coveritem is found in the master database.
• Merges any attribute, tag, and comment from the other input files if and only if the
corresponding item is found in the master database. However, this restriction does not
apply to test data records and other data which are generated at run time. The following
is a list of items which are merged from non-master UCDB files even when those items
are not present in the master UCDB file:
o Test data records
o Memory statistics
o Covergroup bin first hit timestamp data
o Any count, such as a branch scope's count coming in
o Information on whether a covergroup is sampled or not
Related Topics
vcover merge [ModelSim SE Command Reference Manual]
Modifying UCDBs
Ranking Coverage Test Data
Warnings During Merge
Merging and Source Code Mismatches

1168 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Warnings During Merge

Warnings During Merge

Several types of warnings can occur during a merge operation.
Information Not Perfectly Preserved During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Multiple Test Data Records with Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Merging and Source Code Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170

Information Not Perfectly Preserved During Merge

In some cases, the tool issues a warning message (#6846), which indicates that a resulting
merged file cannot completely represent the information contained in the individual UCDBs.
This warning is issued, if:

• if “at_least” is greater than 1 for covergroup bins or cover directives

• weights are different for the same object in different files
• different sets of scopes, contexts, or objects in different files
For complete details including when it is safe to ignore warning 6846, and example scenarios
which cause it to appear, see “Limitations of Merge for Coverage Analysis”.

Multiple Test Data Records with Same Name

ModelSim requires that test data records created within a merged UCDB are unique. In a
situation such as the merging of UCDB files that exist in different directories, but which have
test records whose names are identical, you can get a warning message (#6854).
The warning appears similar to the following:

** Warning: (vcover-6854) Multiple test data records with the same name
encountered during the merge of file 'xyz.ucdb'
These test data records contain conflicting data....

When Is It Safe to Ignore Warning 6854?

Certain ModelSim features rely on uniquely identifying test runs. If you encounter warning
#6854, these features will not work reliably.

On the other hand, if you are NOT using the following features, you can safely ignore the
warning:

• coverage analyze -coverage option (reports which test had most, least, and so on,
coverage)
• vcover ranktest with -plan or -path (test ranking on testplan or design hierarchy)

ModelSim® SE User's Manual, v10.7 1169

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Warnings During Merge

• Tracker GUI's Test Analysis sub-menus which correspond to the coverage analyze or
vcover ranktest arguments listed above
• coverage analyze -testextract: reporting coverage based on test subsets
• Tracker GUI's “Specify Tests” tab on the Edit Filter dialogue (accessed from menu
Filter > Setup > Edit selection, which corresponds to “coverage analyze -testextract”.
• vcover ranktest in test-associated merging mode, or the corresponding option selected
from the Rank menu of the Test Browser GUI

Making Test Data Records Unique

If you plan to use the test-associated features listed just previously, the solution for this situation
is to establish unique names for the test data records by:

• Adding a unique test name for each run prior to saving the UCDB. You would do this by
entering the following command for each test:
coverage attribute -name TESTNAME -value test_1

• Alternatively, you could open the already created UCDBs in Coverage View mode and
assign different TESTNAME attributes for each, by entering the following commands at
the command prompt:
coverage attribute -ucdb -name TESTNAME -value run_1
coverage save run_1.ucdb
coverage attribute -ucdb -name TESTNAME -value run_2
coverage save run_2.ucdb;

Merging and Source Code Mismatches

By default, ModelSim performs checks on source code stability when merging code coverage.
Code coverage results are merged based on line numbers, and merged results can be
significantly wrong if line numbers have changed between versions of the source.
For example, when a UCDB is generated with one version of file t.v, and then another UCDB is
generated with another version of file t.v, it does not make sense to merge the source-based
coverage metrics in those two UCDBs. The difference between files in this case is substantive
and legitimate, and it is the checking known as design unit signature (dusig) checking which
catches this case. When a merge such as this is attempted, warning #6820 is issued, stating that
the merge of the instance in which those lines occur is being skipped.

Note
While a particular instance or du is skipped, note that all other coverage metrics are merged
from that particular test UCDB.

1170 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Warnings During Merge

Causes of Source Code Differences

The dusig check detects substantive, legitimate differences between source code files, as well as
a few cases of non-substantive differences. It is important to understand the cause of the
differences in order to assess their relevance and importance.

Causes of legitimate differences between the design source in two different UCDBs:

• Differing versions of UCDB files, as mentioned above.

• Any line number changes, even from inserting a comment. As an alternative in cases
such as these, you might investigate the use of a “master” merge UCDB.
• The use of `ifdef to conditionally define code.
Causes of potentially insignificant differences:

• File location — this is an insignificant difference and any resulting mismatch can be
safely ignored.
• A difference in the UCDB release version for certain specific VHDL designs —
However legitimate the cause, these difference may not be substantive. In cases where
they are not, you might decide to bypass or work around this check.
Potential solutions for the above causes are evident, depending on the cause identified.
Determine if the differences are legitimate: If so, work to bring the code in the individual files
into alignment. If not legitimate, you can choose to ignore or work around the mismatches.

Bypassing DU Signature Checking

It is sometimes desirable to bypass the ModelSim DU signature check. Do this only in cases
where you are certain the differences are insignificant or irrelevant, as very confusing coverage
results may result if -mergedesigndiffs is applied inappropriately, due to changes in line
numbering which can occur between versions of the source.

To bypass this check and receive only a warning message, use the -mergedesigndiffs argument
to the vcover merge command, such as:

vcover merge ucdb_out ucdb1 ucdb2 -mergedesigndiffs

Caution
DO NOT use -mergedesigndiffs lightly, without validating that the differences in source
code are ok. See “Causes of Source Code Differences” for more information.

Related Topics
Merging Using a Master UCDB
vcover merge [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1171

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Modifying UCDBs

About the Merge Algorithm

Merge Usage Scenarios
Modifying UCDBs
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]

Modifying UCDBs
It is possible, and can sometimes be useful to edit the contents of a UCDB.
Specifically, you can use the coverage edit command to:

• remove coverage data from a UCDB

• move coverage data
• strip and/or add levels of hierarchy from coverage data
• rename testplan sections, tests, design units, libraries, or scopes of the design
For example, if you want to remove coverage data — on a per instance basis — from an existing
UCDB within the Coverage View mode, you can create one copy of a UCDB which contains
only coverage from the device under test (DUT), and another containing only coverage from the
test bench (TB). Consider Example 24-1, which illustrates this case. The full example,
including all necessary files, can be found in <install_dir>/examples/ucdb/coverageedit.

Example 24-1. Dividing a UCDB by Module/DU

// Delete everything but /top/dut* (that is, keep DUT)

coverage open original.ucdb
coverage edit -keeponly -path /top/dut*
coverage report -byinst
coverage save dut.ucdb

// Delete nothing but /top/dut* (that is, keep TB)

coverage open original.ucdb
coverage edit -delete -path /top/dut*
coverage report -byinst
coverage save tb.ucdb

1172 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
About the Merge Algorithm

Figure 24-4. original.ucdb, dut.ucdb and tb.ucdb

Timestamps and UCDB Modification or Merging

When covergroup bin coverage collection is enabled with timestamping, the simulator records a
timestamp at the point during simulation where the recorded count for a covergroup bin
(coveritem) meets its at_least (goal).

You can enable timestamping using the vsim -cvgbintstamp argument. Timestamps are not
recorded for each count increment for the coveritem.

As a consequence of the timestamping, it is not possible to make a later change to the coveritem
goal recorded in the database (that is, after its been saved) — for example by modifying the
UCDB using the coverage edit command — and automatically inferring a different timestamp.
You would have to rerun the simulation for the new timestamp to appear.

A similar confusion can arise with timestamps during merges. When coveritems with multiple
timestamps are merged, the earliest timestamp is retained, even if the merged coveritems have
different at_least (goal) values.

Related Topics
vsim -cvgbintstamp [ModelSim SE Command Reference Manual]
Covergroup Bin Reporting and Timestamps
coverage goal [ModelSim SE Command Reference Manual]
Parameter for Mapping by Column Sequence [Questa Verification Management User's Manual]
Overriding at_least Values in Test Plan [Questa Verification Management User's Manual]

About the Merge Algorithm

Several issues related to the merge algorithm are important to note.

ModelSim® SE User's Manual, v10.7 1173

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
About the Merge Algorithm

General UCDB issues include:

• When you perform a merge on multiple UCDBs, all test data records with unique
testnames are concatenated into the merged UCDB file. If you merge two tests that have
identical names but different data contents, a warning is issued.
• A merged file contains one test data record for each of the different tests that were
merged into the file. For example, if you merged three UCDBs saved from simulation
(vsim), you get three test attribute records. If you merge that file with another one saved
from vsim, you get 3 + 1 = 4 test data records, and so on. See “Understanding Stored
Test Data in the UCDB” for more information on the content of test data records.
• The merge algorithm that ModelSim uses is a union merge. Line numbers from the files
are merged together, so that if different UCDBs have different sets of coverage source
lines, the resulting merged database contains a union of the set of source lines in the
inputs.
• The algorithm merges toggles and FSMs, which have no source information, as follows:
o Toggles are merged with a union operation: objects with the same name are always
merged together, regardless of how many exist in each UCDB input file.
o FSMs are merged together by the order in which they appear in a given module
instance or design unit.
Assertion and functional coverage objects in the UCDB are always merged as a union
algorithm: merging objects of the same name together, but the result contains the union set of
differently named objects from all inputs. Covergroup instances — those for which
option.per_instance = 1 — are merged together based on the “option.name” string for each
instance. Instances with the same name are considered the same, and bins are merged together
as a union, regardless of parameterization. There are some exceptions for other kinds of data
(besides coverage counts):

• Exclusions flags are configurable: with the -and switch to vcover merge, they are
ANDed together; otherwise they are ORed together.
• Coverage “at_least” values are taken as the maximum of all inputs.
• Covergroup “goal” and “auto_bin_max” options are taken as the maximum of all inputs.
• Other covergroup options are taken as “first one wins” — that is, values from the first
input file are taken.
• User-defined attributes are a union (attributes with the same name are “first one wins”
— that is, the value in the first input file survives).
• Assertion limits are taken as the maximum of all inputs.
• The algorithm takes assertion and cover directive limits as the maximum of all inputs.
• User-defined flag values are ORed together.

1174 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Test-Associated Merge versus Totals Merge Algorithm

(This has implications if class specializations are used; see “Covergroup Naming Conventions”
for more information.)

Test-Associated Merge versus Totals Merge

Algorithm
You can choose one of two levels of information preserved in the merged database: the test
associated or totals algorithm.
You choose the algorithm by either using the -testassociated argument, or the -totals (default)
argument to thevcover merge command.

Only the -testassociated merge provides the tool with the level of data required for coverage
analyze, which you can use to analyze your results on a per-test basis and coverage ranktest (the
non-iterative default ranking method) to analyze contributing tests.

• -totals merge — This is the default merge, which merges (sums) the coverage of the
coverage scopes, design scopes, and testplan scopes. The counts are totaled (ORed
together, in the case of vector bin counts) and by default the final merge is a union of
objects from the input files.
Information about which test contributed what coverage into the merge is lost.
Information about the tests themselves are not lost — multiple test data records are
retained from all merge inputs. While this level of merge lists the tests run, it loses the
information as to which tests incremented specific bins.
• -testassociated merge — Includes all data in totals merge, but additionally stores
information on which tests hit which bins. While this level of merge allows you to tell if
a test hit a bin, it cannot tell you how many times the test hit the bin. The criteria which
must be met for a test to be considered as having covered a bin is as follows:
o For functional coverage, the bin hit count must be greater than or equal to the value
set for the at_least parameter of that object.
o For code coverage and assertion data, any non-zero count for a test causes the bin to
be marked as hit by the test.
In some cases, you may wish to preserve any information about which bins were incremented,
by how much, and by which specific tests. If this is the case, you should consider, in addition to
merging, retaining the individual UCDBs for later use.

Limitations of Merge for Coverage Analysis

Because a test-associated merge (vcover merge -testassociated) does not perfectly preserve
information, it can be misleading in some circumstances.

ModelSim® SE User's Manual, v10.7 1175

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Limitations of Merge for Coverage Analysis

These circumstances are detected during the merge, issuing a warning similar to the following:

Information has not been perfectly preserved during the merge of file
'test.ucdb'.
If you use 'coverage analyze -test', test filtering in the Tracker GUI, or
test ranking, results may be inaccurate based on this merge.
For more information issue the command 'verror 6846'.
For more details, rerun merge with the '-verbose' option set.

You only need to be concerned about this warning if you are using any of the following
verification management features:

• “coverage analyze -test” at the command line

• “coverage analyze -coverage” at the command line
• “vcover ranktest” (unless using vcover ranktest -iterative)
• Testplan analysis in the GUI, using either:
o Verification Tracker > Filter > Setup (or Apply)
o Verification Tracker > Test Analysis menu items
• Rules-based linking
If you do not plan to use any of the above mentioned features, you can safely ignore the 6846
error message. However, some features that rely on a certain level of preservation — test
ranking and Coverage View (vsim -viewcov) mode CLI features, for example — issue the
warning if a test-associated merge file is used in any of the following cases:

• For functional coverage: Coverage thresholds (at_least values) are different in separate
merge input files. See Example 24-2.
In these cases, it would be possible for a bin to be covered after the merge, but in none of
the inputs. In this case, test-associated analysis will be correct with respect to the
individual tests, but incorrect regarding merged coverage; ranking in particular will be
inaccurate because of the discrepancy in merged coverage.
• Weights (for example, covergroup weights) are different in separate merge input files.
In these cases, because coverage (for example, covergroup coverage) can depend on
weighting, it will be impossible to recreate the original coverage of some of the input
files. During the merge, the maximum weight is chosen; conflicting weights are not
preserved.
• Differing sets of coverage objects in merge input files.
This most commonly occurs due to parameterization. See Example 24-3.
For these cases, your best option may be to preserve the original UCDBs and analyze or rank
them individually.

1176 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Limitations of Merge for Coverage Analysis

Tip
In the case of different sets of coverage objects in different merge input files — test ranking
is actually more accurate with the test-associated merge, because ranking should reasonably
be done with respect to the union of all coverage.

Example 24-2. Coverage Threshold Difference

For example, suppose at_least == 3, and you have two test cases each with counts of 2 in a
cover directive.

The following command results in 100% coverage:

coverage analyze -total -path /path/to/cover

This is due to the fact that the merged result is 2 + 2 = 4 > 3.

The following command results in 0% coverage, as it should:

coverage analyze -total -path /path/to/cover -test test1

However, the following command results in an incorrect result of 0% coverage:

coverage analyze -total -path /path/to/cover -test test1 test2

The result for “-test test1 test2” (generating test-associated merge data) is not the same as
without -test (a totals merged data), because the test-associated database is missing the
covercount information that is contained in the totals database.

ModelSim® SE User's Manual, v10.7 1177

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Limitations of Merge for Coverage Analysis

Example 24-3. Coverage Object Differences with Parameters

Here's a typical example of code which, when merged with the “vcover merge -testassociated”
merge, provokes verror 6846. It contains a parameterized array:

module top;
parameter int size = 2;
bottom #(size) inst();
endmodule
module bottom;
parameter int size = 2;
reg[size-1:0] tog;
if (size==2) begin
initial begin
#1 tog[0] = 0;
#1 tog[0] = 1;
#1 tog[0] = 0;
end
end else begin
initial begin
#1 tog[1] = 0;
#1 tog[1] = 1;
end
end
endmodule

Imagine you compile this for toggle coverage, creating two different UCDB files with two
different array sizes, then merge them together, like so:

vlog +cover=t test.sv

vsim top -coverage -c -G/top/size=2 -do "run -all; coverage save test2.ucdb; quit"
vsim top -coverage -c -G/top/size=3 -do "run -all; coverage save test3.ucdb; quit"
vcover merge -testassociated test.ucdb test2.ucdb test3.ucdb

1178 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Merge Usage Scenarios

This provokes warning 6846. What is the potential problem? Look at the results of these two
different summary reports, the first issued during simulation on the active database, and the
second during post-processing on a saved UCDB:

> vcover stats test2.ucdb

SUMMARY FOR FILE "test2.ucdb":

Coverage Summary BY INSTANCES: Number of Instances 2
Enabled Coverage Active Hits Percent
---------------- ------ ---- ---------
Toggle Nodes 2 1 50.0

> vsim -viewcov test.ucdb -c -do "coverage analyze -test test2 -summary;
quit"

# Hierarchical Summary Report For Design Instances

# Filtered by Tests: test2
# SUMMARY FOR SCOPE "/top":
# Coverage Summary BY INSTANCES: Number of Instances 2
# Enabled Coverage Active Hits Percent
# ---------------- ------ ---- ---------
# Toggle Nodes 3 1 33.33

The difference between these two summary reports is that the “test-associated” merge loses
some data: in particular, it loses knowledge of what coverage objects were in what file. The
knowledge of what was covered is accurate (in this case), namely “tog[0]”, but as the merged
result has three toggles, that is used as the denominator of the coverage fraction.

Related Topics
Ranking Coverage Test Data
Merge Usage Scenarios
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]

Merge Usage Scenarios

The decision on how to merge a set of UCDB files depends upon where and how the you store
the data and databases being merged.
As a way of understanding your options, consider the basic merge scenarios, as follows:

• Scenario 1: Two UCDBs, same scope

You have data from two or more UCDB files, at the same level of hierarchy (scope) in
the design. Example commands:
vcover merge output.ucdb file1.ucdb file2.ucdb

• Scenario 2: Two UCDBs, different scopes

ModelSim® SE User's Manual, v10.7 1179

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Merge Usage Scenarios

You have data from two or more UCDB files, at different levels of hierarchy. For
example: /top/des instance in filea.ucdb, and top/i/des instance in fileb.ucdb.
o Option 1: Strip top levels of hierarchy from both and then merge the stripped files.
Example commands:
vcover merge -strip 1 filea_stripped.ucdb filea.ucdb
vcover merge -strip 2 fileb_stripped.ucdb fileb.ucdb
vcover merge output.ucdb filea_stripped.ucdb fileb_stripped.ucdb

o Option 2: Strip levels off instance in one UCDB file, and install to match the
hierarchy in the other. In this example, strip /top/ off the /top/des and then add the /
top/i hierarchy to it. Example commands:
vcover merge -strip 1 filea_stripped.ucdb filea.ucdb
vcover merge -install /top/i filea_installed.ucdb filea_stripped.ucdb
vcover merge output.ucdb filea_installed.ucdb fileb.ucdb

• Scenario 3: Single UCDB, two sets of data

You have two sets of data from a single UCDB file, at different levels of hierarchy.
Because they are instantiated at different levels within the same file, the tool cannot
merge both of them into the same database.
In this scenario, it is best to merge by design unit type using the vcover merge -du
command. For example, /top/designinst1 and /top/other/designinst2 are two separate
instantiations of the same design unit within a single UCDB file. An example command
for merging all instances in file3.ucdb would be:
o for Verilog with a module name of design
vcover merge -du design -recursive output.ucdb file3.ucdb

o for VHDL with an entity name of design and an architecture name of arch1
vcover merge -du design(arch1) -recursive output.ucdb file3.ucdb

• Scenario 4: Concurrent merge jobs

You can have concurrent merge jobs running on different machines which are
simultaneously writing to the same target merge file. A lock file is created which
prevents any conflicts. The utility can recover from crashing merges and crashing hosts.
It also allows a configurable time-out of merges, as well as backups of the previous
output. See the vcover merge command for syntax details.
Use the vcover merge command as follows:
vcover merge out.ucdb out.ucdb in.ucdb

Note
If this is the very first merge, the input file out.ucdb will not exist yet, so the
simulator issues a warning. In this case, specify the appropriate <input>.ucdb file.

This command takes the output UCDB and merges it with a second input UCDB.

1180 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Merge Usage Scenarios

vcover merge out.ucdb out.ucdb in2.ucdb -timeout 10 -backup

Then, another machine can take the output of the first merge command and the third
input UCDB, and so on.
Related Topics
Merging Coverage Data
About the Merge Algorithm
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]

ModelSim® SE User's Manual, v10.7 1181

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Viewing and Analyzing Verification Data

Viewing and Analyzing Verification Data

You can view and anlyze your verification data through the graphical user interface.
Storing User Attributes in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Customizing the Column Views in Verification Windows. . . . . . . . . . . . . . . . . . . . . . . . 1185
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Analysis for Late-stage ECO Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207

Storing User Attributes in the UCDB

It is possible to add your own attributes to a specified test record.
You can do this using coverage attribute, with a command such as:

coverage attribute -test testname -name Responsible -value Joe

This command adds the “Responsible” attribute to the list of attributes and the values displayed
when you create a coverage report on testname.UCDB. This shows up as a column when the
UCDB is viewed in the Tracker pane.

Viewing Test Data in the GUI

Setting Goal and Weight for a Simulation
You can configure the goal and weight of various coverage items from within the GUI by
selecting Tools > Coverage Configuration > Goal/Weight.

Setting Colors for Coverage Display

You can configure the colors for the threshold coverage numbers by selecting the Tools >
Coverage Configuration > Colorization menu option.

1182 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Viewing Test Data in the Browser Window

This opens the Colorization Threshold dialog box, which allows you to control the colorization
of coverage results displayed in the “Coverage” column, as well as set the low and high
threshold coverage values for highlighting coverage values:

• < low threshold — RED

• > high threshold — GREEN
• > low and < high — YELLOW

Viewing Test Data in the Browser Window

You can view both UCDB (.ucdb) and rank result (.rank) files in the Verification Browser
window.
Prerequisites
• You must be working from a directory containing .ucdb or .rank files.
Procedure
1. Open the Verification Management window:
View > Verification Management > Browser
2. Add files to the Browser using one of the following three methods:
• Right-click in the window and select Add File. Select the desired .ucdb files from
the list that appears in the Add File(s) dialog box.
• When the window is active, select Verification Browser > Add File from the menu
bar of the Main window. Select the desired .ucdb files from the list that appears in
the Add File(s) dialog box.
• At the vsim command prompt, execute the add testbrowser command, which
accepts UCDB and rank result files as arguments. For example,
add testbrowser test.ucdb

Results
The Verification Browser window appears, similar to Figure 24-5.

ModelSim® SE User's Manual, v10.7 1183

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Deleting UCDB Files from the Browser Window

Figure 24-5. Test Data in Verification Browser Window

The coverage numbers in the Browser window are based on the Total Coverage calculations
described in “Calculation of Total Coverage”, however all design roots are taken into account
and include all hierarchy underneath all design roots. See “Coverage Calculation in the Browser
Window”.

Deleting UCDB Files from the Browser Window

Remove UCDB files from the Verification Browser window.
Procedure
1. Highlight the test(s) in the Verification Browser window.
2. Press the Delete key.
Results
A popup appears for you to confirm if you want to delete the selected test(s) from the
Verification Browser window and/or from the directory itself.

Invoking Coverage View Mode

UCDB files from previously saved simulations are only viewable in Coverage View mode
(post-processing). You can invoke Coverage View mode on any of your .ucdb files in the Test
Browser or at the command line. This allows you to view saved and/or merged coverage results
from earlier simulations.

1184 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Customizing the Column Views in Verification Windows

Procedure
Use one of the following methods to invoke Coverage View mode.

If you want to ... Do the following ...

Use the GUI Double-click on a selected .ucdb
OR
Right-click to select the .ucdb file, and select Invoke
CoverageView Mode.
The tool then opens the selected .ucdb file and reformats the
Main window into the coverage layout. A new dataset is created.
This functionality does NOT work on .rank files.
Use the command line Entervsim with the -viewcov <ucdb_filename> argument.
interface Multiple -viewcov arguments are allowed. For example, the
Coverage View mode is invoked with:
vsim -viewcov myresult.ucdb

where myresult.ucdb is the coverage data saved in the UCDB

format. The design hierarchy and coverage data is imported
from a UCDB.

Related Topics
Coverage View Mode and the UCDB
Viewing Test Data in the Tracker Window [Questa Verification Management User's Manual]

Customizing the Column Views in Verification

Windows
You can customize the display of columns in the Verification Browser window or Tracker
window, and then save these views for later use.
Procedure
1. Select [Create/Edit/Remove ColumnLayout...] from the pulldown list.
This displays the Create/Edit/Remove Column Layout dialog box.
2. Enter a new name in the Layout Name text entry box.
3. (Optional) Add or modify pre-defined column arrangements from the Create/Edit/
Remove Column Layout dialog box by adding columns to or removing them from the
Visible Columns box as desired.
4. Click OK.

ModelSim® SE User's Manual, v10.7 1185

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Customizing the Column Views in Verification Windows

Results
After applying your selections, the rearranged columns and custom layouts are saved and
appear when you next open that column view in the Verification Browser or Tracker windows.
Related Topics
Test Attribute Records in the UCDB

1186 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Ranking Related Topics

Ranking Related Topics

The following information is critical to successful ranking and the role ranking plays in viewing
and analyzing verification data.
Ranking Coverage Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Group Ranking of Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188
Viewing Ranked Test Data in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Merged Results vs. Rank Report Coverage: Why They Can Differ . . . . . . . . . . . . . . . . 1190
Ranking Most Effective Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Test-Associated vs. Iterative Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190

Ranking Coverage Test Data

Ranking seeks to order tests with respect to their contribution to the coverage metric, such as
Total Coverage. The default ordering of the tests within the ranking report (.rank) is from most
(top) to least (bottom). All tests which do not contribute to increased coverage numbers are not
included in the ranked results.
You can rank your tests by any number of criteria using either the Verification Browser >
Rank menu selection, or the vcover ranktest command with various parameters and UCDB files
as input. The ranking result files are based on the selected .ucdb files. You can rank normal
UCDB files and coverstores, as well as merged UCDB files and merged coverstores.

Procedure
1. Select one or more .ucdb files.
2. Right-click and select Rank.
This displays the Rank Files Dialog Box. The various options within the dialog box
correspond to arguments available with the -du and -path arguments to vcover ranktest
command.
3. Fill in What to Rank, Rank By, and Stop Ranking When and Messages, as desired. (The
selection of Rank By > Fewest means to rank the files by the fewest number of tests.)
4. Select Advanced Options to open the dialog box to set your coverage metrics,
arguments file, and ranked results filenames.
5. Click OK.
This creates the .rank file and loads it into the Test Browser; it also outputs ranking data
to the transcript window.

ModelSim® SE User's Manual, v10.7 1187

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Ranking Related Topics

Results
If the rank was successful, a transcript message such as the following appears:
#
# Metric Bins Covered% Inc%
#
# Cover Groups/Points 5/18 0.0000 0.0000 |
# CoverDirectives 10 0.0000 0.0000 |
# Statements 2605 47.0633 47.0633 ********* |
# Branches 1978 29.6764 29.6764 ***** |
# Expressions 711 18.2841 18.2841 *** |
# Conditions 1315 15.9696 15.9696 *** |
# ToggleNodes 2214 1.1743 1.1743 |
# States 17 17.6471 17.6471 *** |
# Transitions 45 6.6667 6.6667 * |
# AssertPasses 12 0.0000 0.0000

Group Ranking of Coverage Tests

Ranktest now provides a way to selectively group tests based on attribute values, such that
ranktest will treat them as one combined object.
Group ranking is performed by issuing the vcover ranktest command with the -groupby
argument, which allows you to specify the attribute to be used to group tests.

vcover ranktest -groupby <attribute>

Three other arguments modify the -groupby argument as follows.

• -groupby <attribute> — Specifies the attribute within a UCDB test record that will be
used to group tests by.
o -groupfilter <regex> — Specifies a regular expression match to apply to the attribute
being grouped.
o -norun — Displays groups without ranking so you can see grouping before running
the ranking process.
o -r[ecursive] — Enables recursive ranking of items within a group selected by the use
of -groupby and -groupfilter so they will, in turn, be ranked against one another.

Grouping by Attribute
You can specify any attribute that exists within an input set of UCDBs, such that when ranking,
all tests sharing the same attribute value will be treated as one input. For example, assume the
following attributes in 10 different UCDB files (where TESTNAME is <testname>_<seed>):

TESTNAME = testA_1 TESTNAME = testB_1

TESTNAME = testA_2 TESTNAME = testB_2
TESTNAME = testA_3 TESTNAME = testB_3
TESTNAME = testA_4 TESTNAME = testB_4
TESTNAME = testA_5 TESTNAME = testB_5

1188 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Ranking Related Topics

You can merge the tests then group and rank them with the following commands:

vcover merge -out merge.ucdb <inputs>

vcover ranktest merge.ucdb -groupby TESTNAME -groupfilter (<.*)_*

The parenthesis of the filter expression are used to define the group (and subsequently the group
name). The result is a ranked output containing testA and testB.

Viewing Ranked Test Data in the Browser

The process of ranking the test coverage in a UCDB generates a .rank file which can be viewed
in the UCDB browser.
The rank process creates a ranked list of tests based on the input goals: each row in the Browser
displays the test and its cumulative contribution to coverage made by it as well as the tests listed
above it, in each column. For example, looking at the Statement coverage column in test row
three: the value shown represents the statement coverage achieved by the first three tests
combined.
Tip
Sometimes it is easy to look at the coverage numbers in a merged .ucdb and the ranking
report (the .rank file for that merged UCDB) and think that they should match. However,
they should not: they contain different coverage information altogether.

The coverage numbers listed in a merged UCDB are raw coverage numbers for that particular
test. Whereas, in the ranked report, the numbers within each column for a particular test are a
cumulative total of all the data in the columns from tests listed above it.

You can see that in Figure 24-6, the 80.89 number in the FifoTest.ucdb within the directed.rank
section represents the cumulative total Statement coverage for FifoTest as well as the three tests
listed above it; whereas the 73.76 number in the directed.ucdb represents only that single test’s
total contribution toward Statement coverage.

ModelSim® SE User's Manual, v10.7 1189

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Ranking Related Topics

Figure 24-6. Differing Merge and Rank Results

Merged Results vs. Rank Report Coverage: Why They

Can Differ
Merged results can and do differ from Rank report coverage results.
• Results can differ based upon the coverage calculation method used by the ranking
method, specified using the -algorithm argument to vcover ranktest.
• Assertions are not coverage numbers, and as such, they are not included in the ranked
results.2In Figure 24-6, notice that the Total Coverage for directed.ucdb is different than
that of directed.rank. This relates to the fact that failed assertions are present, and they
have an effect on the coverage numbers which is not represented by the ranking data.

Ranking Most Effective Tests

You can rank the most effective tests from the Tracker, Structure, Covergroups, or Instance
windows, by selecting the Test Analysis > Rank Most Effective Tests menu item.

Test-Associated vs. Iterative Ranking

Test-associated ranking performs a merge and proceeds to rank based upon a test-associated
merge result, whereas iterative ranking ranks individual non-merge tests by performing an

2. Assertions are not included in the ranked coverage because the numbers are not monotonically increasing.
In fact, they start at 100% and may decrease as tests are added.

1190 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Ranking Related Topics

iteration of merges on the file system. Therefore, if you have a merged test included in your
ranking, make sure that the merged file was produced using a test-associated merge (vcover
merge run with the -testassociated switch).
Note
Test-associated ranking, which is the default ranking method, depends on the existence of a
test-associated merged result from a previous run of vcover merge -testassociated. If you
attempt a test-associated ranking when no test-associated merge result exists, you will receive
an error.

The test-associated ranking method (default) is superior to the iterative method in two important
ways:

• significantly better performance

• ranking is performed with respect to the entire coverage space
However, there are some cases where the test-associated ranking does not always function
intuitively: Because it only records what test covered a particular bin, the test-associated
algorithm may underestimate coverage for test subsets where “at_least” values are greater than
1.

This is the same limitation as explained in “Limitations of Merge for Coverage Analysis”.

The iterative ranking option is available to work around cases of covergroups and cover
directives where at_least > 1, however it is considerably less efficient (slower). Iterative ranking
ranks each individual test by performing an iteration of merges on the file system.

Related Topics
About the Merge Algorithm
Test-Associated Merge versus Totals Merge Algorithm
Merge Usage Scenarios
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]

ModelSim® SE User's Manual, v10.7 1191

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Reporting

Coverage Reporting
You can generate ASCII text or HTML reports of coverage using menu selections in the GUI or
with command line commands.
The Generation of Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Generating ASCII Text Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Generating HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194

The Generation of Coverage Reports

You can use menu selections in the GUI or the coverage report command to create three types
of reports to display the coverage metrics in your design.
• ASCII Text Reports (see “Generating ASCII Text Reports”)
• HTML Reports (see “Generating HTML Coverage Reports”)
• Exclusion Reports (see “Generating Coverage Exclusion Reports”)
Before creating any coverage report, you must first:

• Run a simulation with the various coverage types enabled to collect coverage metrics.
• If opening from the Browser window, the UCDB must be opened in Coverage View
mode by right-clicking on the UCDB and selecting Invoking CoverageView Mode.
To access any of the Coverage Report dialog boxes, you can:

• Select Tools > Coverage Report > Text or HTML or Exclusions.

• Select a UCDB in the Browser window, then select Tools > Coverage Report > Text
or HTML or Exclusions.
These actions display the Coverage Text Report, Coverage HTML Report, or Coverage
Exclusions Report dialog boxes.

You can also display the Coverage Text Report dialog box by right-clicking any object in the
Files or Structure (sim) windows and select Code Coverage > Code Coverage Reports from
the context menu.

The Coverage Text Report dialog box enables you to display coverage reports immediately in
the default Notepad text viewer/editor included with the product, in the Source viewer, or in an
editor of your choice that you set with the EDITOR environment variable. See Setting
Environment Variables.

1192 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage Reporting

Generating ASCII Text Reports

Access: Tools > Coverage Report > Text
At the command line: use the coverage report command. Within the GUI: use the Coverage
Text Report dialog box.
Figure 24-7. Coverage Report Text Dialog

Procedure
1. From the Report on dropdown, select one of the following:
All files — reports data for all design units defined in each file. (-byfile switch with
coverage report).

ModelSim® SE User's Manual, v10.7 1193

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Reporting

All instances — reports data in each instance, merged together. (-byinst with coverage
report).
All design units — reports data in all instances of each design unit, merged together. (-
bydu with coverage report).
2. In the Coverage Type pane, ensure that the desired coverage types are selected.
3. Alter any of the other options as needed. All options in this dialog correspond to the
coverage report and vcover report options.
4. Click OK to create the coverage report.
Results
• The report (report.txt) is written to the current working directory.
• A a notepad window containing the report.txt file opens.
Related Topics
FSM Coverage
Code Coverage
Verification with Functional Coverage
The Generation of Coverage Reports

Generating HTML Coverage Reports

You can create on-screen, static or dynamic coverage reports in HTML that include functional
coverage consolidated views.
For best results, the report should be viewed with a browser that supports the following:

• JavaScript — Without this support, your browser will work, but the report is not as
aesthetically pleasing.
• cookies — For convenience of viewing coverage items in the HTML pages, you should
enable cookies.
• frames and Cascading Stylesheets (CSS) — Though support is recommended for
frames, reports can still be displayed on browsers without this support. The report writer
uses CSS to control the presentation, and will be best viewed with browsers that support
frames and CSS.
If you want to create a dynamic HTML report, you must use the “vcover report” command with
the -html and -dynamic arguments; and you must do the following:

• define the BROWSER environment variable, which points to the executable of a web
browser,

1194 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage Reporting

or
• include the -servermode argument with the vcover report -html command.
Once the server has been started with the -servermode -port <port_num> argument, you can
stop the server using -stopserver -port <port_num>. See vcover report -html for more
information.

Procedure
Generate a coverage report using one of the following methods:

If you want to ... Do the following

Generate a static HTML Use the -html argument with the coverage report or vcover
report from the command report commands.
line.
Generate a dynamic HTML Use the -html and the -dynamic arguments with the vcover
report from the command report command.
line.
Generate a static HTML 1. Select a single UCDB file from the Verification Management
report from the GUI. Browser.
2. From the main menu, select Verification Browser > HTML
Report.
The Coverage HTML Report from File dialog box appears,
which allows you to control the generation and subsequent
viewing of the report.
3. Set the color for both the high and low threshold to define the
number above which the coverage number displays in green,
and below which it is displayed in red.
4. Select No Frames to save on report generation time and disk
space for larger designs (refer to HTML Generation for
Large Designs).
5. Select the coverage details you want to see in your report.

ModelSim® SE User's Manual, v10.7 1195

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Reporting

Figure 24-8. Coverage HTML Report from File Dialog

Results
• The static report (index.html) is written to the specified directory (default is /
covhtmlreport).
You can view the HTML file in a web browser. For an example, see Figure 24-9.

1196 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Coverage Reporting

Figure 24-9. HTML Coverage Report

The web browser allows you to explore the hierarchy of the design, much like you might
browse a file system. Colorized copies of the design source code are generated and linked into
the report at the appropriate places.
The coverage numbers displayed in the sections of the HTML are calculated according to the
following algorithms:
Exclusion comments you add with the coverage exclude -comment command will appear as
tooltips when you mouse over hit count cells denoted with a plus ‘+’ sign. The plus sign is
added to the cell to indicate that it contains an exclusion comment. For example, Figure 24-10
displays the exclusion comment, “This assertion is excluded” when we mouse over the cell that
shows the failure count of the assert_location_full_on_write assertion.

ModelSim® SE User's Manual, v10.7 1197

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Coverage Reporting

Figure 24-10. Exclusion Comment Displays as Tooltip

Compared to other types of coverage reports, HTML report generation can cause machines to
be particularly sensitive to issues of disk space, memory usage and slowness. Many of the
HTML reporting options, both through the radio buttons in the Coverage HTML Report dialog
box and the coverage report -html options, are geared toward improving the speed and
performance of report generation. Additionally, you may want to target the reports by excluding
specific coverage types and/or reducing the scope of items in the report.
See coverage report -html for full details on these options.

1198 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
HTML Report Details

HTML Report Details

The following sections relate to HTML reporting, and provide information on how to perform
specific tasks for HTML reporting.
Enabling Test Lists, Source Code and Coverage Details . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Canonical Toggle Nodes in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
option or type_option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
Viewing Bins Hit by Certain Tests in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
HTML Generation for Large Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Generating Coverage Exclusion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1201

Enabling Test Lists, Source Code and Coverage Details

Context: Browser > HTML Report
HTML reports are generated by default not to include source code detail, coverage detail and
test lists.

Canonical Toggle Nodes in HTML Reports

Some toggle nodes in the report appear with a notation of “[canonical]”. This denotes that the
togglenode is an alias of a canonical node elsewhere in the design. Canonical means a common
name for the overall net. All aliases point to the canonical name, which is equivalent to all
aliases.

option or type_option Values

For all covergroups, coverpoints and crosses, the value of option/type_option is displayed in the
HTML report whenever it differs from the default value specified in the SystemVerilog LRM.

Viewing Bins Hit by Certain Tests in HTML Reports

Procedure
1. Generate the HTML Report on a merged UCDB, including the -testhitdata argument.
The UCDB must have been merged with the test-associated switch set (vcover merge -
testassociated). See Generating HTML Coverage Reports for details.
2. Click the Design scope or Testplan section whose bins-hit information you want to see
and click the scope or instance, descend down the hierarchy until a hypertext link is
visible for the item you are interested in viewing. Your report will be similar to that
shown in Figure 24-11.

ModelSim® SE User's Manual, v10.7 1199

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
HTML Report Details

Figure 24-11. Hyperlinked Bins in the Hits Column

3. Click the hypertexted Bin number in the Hits column of the report to bring up a table
which lists the tests which hit that bin. You can sort the list in three ways —
alphabetically a - z, z - a, or the order of tests as listed in the merged UCDB — by
toggling the left pointing triangle in the column name.
Figure 24-12. Test-Bins-Hit Table

HTML Generation for Large Designs

The No Frames radio button in the GUI corresponds to the -noframes argument that you can use
in conjunction with the -html argument of the coverage report command.
Selecting the No Frames functionality disables generation of a JavaScript-based tree.
Generating this tree decreases performance for designs with a large number of design scopes.
When you select No Frames or use the -noframes argument, the report displays as a single

1200 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
HTML Report Details

frame containing the top-level summary page. An HTML-only design scope index page is
available as a link from this top-level page.

Tip
For very large designs, avoid using the -details argument (which produces coverage detail
pages). This can save report generation time and disk space for generating HTML.

Related Topics
Code Coverage
The Generation of Coverage Reports
Coverage Reports

Generating Coverage Exclusion Reports

Access:
GUI: Tools > Coverage Report > Exclusions
Command Line: coverage report -excluded
Create a coverage exclusion report within the GUI as follows.
Figure 24-13. Coverage Exclusion Report Dialog

Procedure
1. Select Pragma and/or User Defined Exclusions to report.
2. Save the pathname.
3. Click OK.
Related Topics
Code Coverage
Coverage Exclusions
The Generation of Coverage Reports

ModelSim® SE User's Manual, v10.7 1201

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
HTML Report Details

Coverage Reports

1202 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Filtering Data

Filtering Data
There are several tasks related to the filtering of data from the UCDB.
Filtered Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Setting up or Modifying a Filter for UCDB Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Applying a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204
Filtering Results by User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205

Filtered Data in the UCDB

Use a filter to display only the desired coverage information in various Verification
Management and coverage windows.
The following data can be filtered:

• Filter UCDB data in the Verification Management Browser window

• Filter UCDB data in the Verification Management Tracker window
• Filter covergroup-related coverage data from Covergroup window
• Filter assertion-related data from Assertion window
• Filter cover directive data from Cover Directive window
For details on filtering assertion, cover directive, or covergroup data, see “Filtering Functional
Coverage Data”.

The filter operation is a “selection” filter. In other words, you are selecting criteria used for the
inclusion of the specified information, and filtering out everything else.

Setting up or Modifying a Filter for UCDB Data

You can set the display to view only certain items in a UCDB.
Procedure
1. From the context sensitive window menu, select Filter > Setup.
This opens the Filter Setup dialog box.
2. Select Create to create a new filter.
This opens the Create Filter dialog box.
3. Select Add to specify criteria.
This opens the Add/Modify/Select Criteria dialog box.

ModelSim® SE User's Manual, v10.7 1203

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Filtering Data

Figure 24-14. Filtering Displayed UCDB Data

4. Select Criterion and choose the type of coverage you wish to use as a filter.
a. Select Operator.
b. Enter the Value of the item to match.
c. Click OK.
The criterion you just entered appears in the Select Criteria list.
5. Enter a Filter Name and select OK to save that filter.
6. Either select Apply to filter the UCDB data, or select Done to exit the dialog box.
Related Topics
coverage analyze [ModelSim SE Command Reference Manual]

Applying a Filter
The filter can be applied using the same Filter Setup dialog.
Procedure
1. From the Filter Setup dialog, select the desired filter from the list and select Apply.
2. From the Verification Management Browser:
a. Right-click on the UCDB files you plan to filter.

1204 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Filtering Data

b. Choose Filter > Apply, and then select a filter from the list.
Results
UCDB files with matching criteria are included in the data displayed in the Browser.

Filtering Results by User Attributes

One powerful feature for tracing verification requirements is the ability to filter your coverage
results by attributes. You can add these attributes to a testplan for this purpose.
For example, if your original testplan included such data fields as the engineer responsible for
tests, or the priority level assigned a specific section of the plan, you can add these as attributes
to the imported and merged testplan UCDB and use them for filtering the coverage results.

Prerequisites
• The user attribute used to filter the data must already exist in the original plan, or you
must add the user attribute to the original plan before importing it (see “Storing User
Attributes in the UCDB”).
• The plan must be imported.
• The plan must be merged with test results.
Procedure
1. Select all tests to which you wish to apply selection criteria.
2. Right-click in the Tracker or Browser window and select Filter > Setup.
This opens the Filter Setup dialog box.
3. Select Create.
This opens the Create Filter dialog box to the Selection Criteria tab.
4. Select Add.
This opens the Add/Modify/Select Criteria dialog box.

ModelSim® SE User's Manual, v10.7 1205

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Filtering Data

Figure 24-15. Filtering on User Attributes

5. For Criterion, select Attributes from the pulldown list.

a. For Attribute Name, select the desired attribute name(s) from pull-down list. The list
contains all pre-defined attributes and any user attributes you added.
b. For Operator, select one of the options. Seecoverage analyze -select for definitions.
c. Enter the value of the item to match.
d. Click OK.
The criterion you just entered appears in the Selection Criteria list.
6. Select the Specify Tests tab to select specific tests. By default, all tests are subject to the
filter.
7. Enter a Filter Name and select OK to save the filter with the specified selection criteria.
The filter you just created appears in the Filters list within the Filter Setup dialog box.
8. Either select Apply to filter the UCDB data, or select Done to exit the dialog box.
Related Topics
Understanding Stored Test Data in the UCDB
coverage analyze [ModelSim SE Command Reference Manual]
Importing an XML Verification Plan [Questa Verification Management User's Manual]
Merging Verification Plan with Test Data [Questa Verification Management User's Manual]
xml2ucdb.ini Configuration File [Questa Verification Management User's Manual]

1206 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Coverage and Verification Management in the UCDB
Retrieving Test Attribute Record Content

Storing User Attributes in the UCDB

Retrieving Test Attribute Record Content

Two commands can be used to retrieve the content of test attributes: coverage attribute and
vcover attribute, depending on whether you are in live simulation or Coverage View mode.
Related Topics
Customizing the Column Views in Verification Windows
coverage attribute [ModelSim SE Command Reference Manual]
vcover attribute [ModelSim SE Command Reference Manual]

Analysis for Late-stage ECO Changes

Often ECOs (Engineering Change Orders) can occur late in the design cycle, when a design is
highly stable. Only small sections of the design are affected by changes. You can use various
Verification Management tools to analyze which tests most effectively cover those few areas
and re-run those specific tests to demonstrate satisfactory coverage numbers.
• Rank tests (see “Ranking Coverage Test Data”).
• Re-run tests (see “Rerunning Tests and Executing Commands”).

ModelSim® SE User's Manual, v10.7 1207

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Coverage and Verification Management in the UCDB
Analysis for Late-stage ECO Changes

1208 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 25
C Debug

C Debug allows you to interactively debug FLI/PLI/VPI/DPI/SystemC/C/C++ source code with

the open-source gdb debugger. Even though C Debug does not provide access to all gdb
features, you may wish to read gdb documentation for additional information. For debugging
memory errors in C source files, refer to the application note titled Using the Valgrind Tool with
ModelSim, available via Support Center.
Note
The functionality described in this chapter requires an additional license feature (cdebug).
Refer to “License Feature Names” in the Installation and Licensing Guide for more
information, or contact your Mentor Graphics sales representative.

Before you use C Debug, please note the following qualifications and requirements:

• C Debug is an interface to the open-source gdb debugger. ModelSim contains no

customized gdb source code, and C Debug does not remove any limitations or problems
of gdb.
• You should have some experience and competence with C or C++ coding, and C
debugging in general.
• Recommended usage is that you invoke C Debug once for a given simulation and then
quit both C Debug and ModelSim. Starting and stopping C Debug more than once
during a single simulation session may cause problems for gdb.
• Generally, you should not have an existing .gdbinit file. If you do, make certain you
have not done any of the following within it: defined your own commands or renamed
existing commands; used 'set annotate...', 'set height...', 'set width...', or 'set print...'; set
breakpoints or watchpoints.
• To use C Debug on Windows platforms, you must compile your source code with gcc/
g++. Refer to Running C Debug on Windows Platforms, below.
Supported Platforms and gdb Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Setting Up C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
Running C Debug from a DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Stepping in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Quitting C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214
Finding Function Entry Points with Auto Find bp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215

ModelSim® SE User's Manual, v10.7 1209

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Supported Platforms and gdb Versions

Identifying All Registered Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216

Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
Debugging Functions when Quitting Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
C Debug Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223

Supported Platforms and gdb Versions

ModelSim ships with the gdb 6.3, 6.6 and 7.3.1, and C Debug uses whichever version is
required to function with your platform's version of the simulator. Testing has shown these
versions to be the most reliable for SystemC applications. However, for FLI/PLI/VPI
applications, you can also use a current installation of gdb if you prefer.
C Debug has been tested on these platforms with these versions of gdb:
Platform Supported compilers Supported gdb version
Linux (both 32-bit and gcc-4.7.4 gdb-7.3.1
64-bit) gcc-4.5.0
gcc-4.3.3 gdb-6.6
Windows (32-bit) gcc-4.2.1 gdb-6.3

To invoke C Debug, you must have the following:

• A cdebug license feature.

• The correct gdb debugger version for your platform.

Running C Debug on Windows Platforms

To use C Debug on Windows, you must compile your C/C++ source code using the gcc/g++
compiler installed separately from ModelSim. Source compiled with Microsoft Visual C++ is
not debuggable using C Debug.

You should install the g++ compiler at the same directory level as your product install

Setting Up C Debug
Before viewing your SystemC/C/C++ source code, you must set up the C Debug path and
options.
Procedure
1. Compile and link your C code with the -g switch (to create debug symbols) and without
-O (or any other optimization switches you normally use). See SystemC Simulation for

1210 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Running C Debug from a DO File

information on compiling and linking SystemC code. Refer to the chapter Verilog
Interfaces to C for information on compiling and linking C code.
2. Specify the path to the gdb debugger by selecting Tools > C Debug > C Debug Setup
Figure 25-1. Specifying Path in C Debug setup Dialog

Select “default” to point at the supplied version of gdb or “custom” to point at a separate
installation.
3. Start the debugger by selecting Tools > C Debug > Start C Debug. ModelSim will start
the debugger automatically if you set a breakpoint in a SystemC file.
4. If you are not using gcc, or otherwise have not specified a source directory, specify a
source directory for your C code with the following command:
ModelSim> gdb dir <srcdirpath1>[:<srcdirpath2>[...]]

Running C Debug from a DO File

You can run C Debug from a DO file but there is a configuration issue of which you should be
aware. It takes C Debug a few moments to start-up.
If you try to execute a run command before C Debug is fully loaded, you may see an error like
the following:

# ** Error: Stopped in C debugger, unable to real_run mti_run 10us

# Error in macro ./do_file line 8
# Stopped in C debugger, unable to real_run mti_run 10us
# while executing
# "run 10us

In your DO file, add the command cdbg_wait_for_starting to alleviate this problem. For
example:

cdbg enable_auto_step on
cdbg set_debugger /modelsim/5.8c_32/common/linux
cdbg debug_on
cdbg_wait_for_starting
run 10us

ModelSim® SE User's Manual, v10.7 1211

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Setting Breakpoints

Setting Breakpoints
Breakpoints in C Debug work much like normal HDL breakpoints. You can create and edit
them with ModelSim commands (bp, bd, enablebp, and disablebp) or within a Source window
in the GUI.
Some differences do exist:

• The Modify Breakpoints dialog, accessed by selecting Tools > Breakpoints, in the
ModelSim GUI does not list C breakpoints.
• C breakpoint id numbers require a “c.” prefix when referenced in a command.
• When using the bp command to set a breakpoint in a C file, you must use the -c
argument.
• You can set a SystemC breakpoint so it applies only to the specified instance using the
-inst argument to the bp command.
• If you set a breakpoint inside an export function call that was initiated from an
SC_METHOD, you must use the -scdpidebug argument to the vsim command. This
will enable you to single-step through the code across the SystemC/SystemVerilog
boundary.
Here are some example commands:

bp -c *0x400188d4

Sets a C breakpoint at the hex address 400188d4. Note the ’*’ prefix for the hex address.

bp -c or_checktf

Sets a C breakpoint at the entry to function or_checktf.

bp -c or.c 91

Sets a C breakpoint at line 91 of or.c.

bp -c -cond "x < 5" foo.c 10

Sets a C breakpoint at line 10 of source file foo.c for the condition expression “x < 5”.

enablebp c.1

Enables C breakpoint number 1.

The graphic below shows a C file with one enabled breakpoint (indicated by a red ball on line
151) and one disabled breakpoint (indicated by a gray ball on line 154).

1212 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Stepping in C Debug

Figure 25-2. Setting Breakpoints in Source Code

Clicking the red ball with your right (third) mouse button pops up a menu with commands for
removing or enabling/disabling the breakpoints.

Figure 25-3. Right Click Pop-up Menu on Breakpoint

Note
The gdb debugger has a known bug that makes it impossible to set breakpoints reliably in
constructors or destructors. Do not set breakpoints in constructors of SystemC objects; it
may crash the debugger.

Stepping in C Debug
Stepping in C Debug works much like you would expect. You use the same buttons and
commands that you use when working with an HDL-only design.

Table 25-1. Simulation Stepping Options in C Debug

Button Menu equivalent Other equivalents
Step Into Tools > C Debug > use the step command at the
Run > Step CDBG> prompt
steps the current simulation to the next
statement; if the next statement is a see: step command
call to a C function that was compiled
with debug info, ModelSim will step
into the function

ModelSim® SE User's Manual, v10.7 1213

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Quitting C Debug

Table 25-1. Simulation Stepping Options in C Debug (cont.)

Button Menu equivalent Other equivalents
Step Over Tools > C Debug > use the step -over command
Run > Step -Over at the CDBG> prompt
statements are executed but treated as
simple statements instead of entered see: step command
and traced line-by-line; C functions
are not stepped into unless you have an
enabled breakpoint in the C file
Tools > C Debug > use the run -continue
Continue Run Run > Continue command at the CDBG>
continue the current simulation run prompt
until the end of the specified run see: run command
length or until it hits a breakpoint or
specified break event

Debugging Active or Suspended Threads

You can use C Debug to debug either an active or a suspended thread and then view its contents
(such as call stack, local variables, and source code).

You can debug a suspended thread in either of the following situations:

• While the simulation is running

• When the simulation is stopped at a breakpoint in an active SystemC/HDL thread
Known Problems With Stepping in C Debug
The following are known limitations which relate to problems with gdb:

• With some platform and compiler versions, step may actually behave like run
-continue when in a C file. This is a gdb limitation that results from not having any
debugging information when in an internal function to VSIM (that is, any FLI or VPI
function). In these situations, use step -over to move line-by-line.

Quitting C Debug
You can end SystemC debugging session from the GUI or from the command line.
• From the GUI:
Select Tools > C Debug > Quit C Debug.
• From the command line, enter the following in the Transcript window:
cgdb quit

1214 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Finding Function Entry Points with Auto Find bp

Note
Recommended usage is that you invoke C Debug once for a given simulation and
then quit both C Debug and ModelSim. Starting and stopping C Debug more than
once during a single simulation session may cause problems for gdb.

Finding Function Entry Points with Auto Find

bp
ModelSim can automatically locate and set breakpoints at all currently known function entry
points (that is, PLI/VPI/DPI system tasks and functions and callbacks and FLI subprograms and
callbacks and processes created with mti_CreateProcess). Select Tools > C Debug > Auto
find bp to invoke this feature.
The Auto find bp command provides a “snapshot” of your design when you invoke the
command. If additional callbacks get registered later in the simulation, ModelSim will not
identify these new function entry points unless you re-execute the Auto find bp command. If
you want functions to be identified regardless of when they are registered, use Identifying All
Registered Function Calls instead.

The Auto find bp command sets breakpoints in an enabled state and does not toggle that state to
account for step -over or run -continue commands. This may result in unexpected behavior.
For example, say you have invoked the Auto find bp command and you are currently stopped
on a line of code that calls a C function. If you execute a step -over or run -continue command,
ModelSim will stop on the breakpoint set in the called C file.

ModelSim® SE User's Manual, v10.7 1215

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Identifying All Registered Function Calls

Identifying All Registered Function Calls

Auto step mode automatically identifies and sets breakpoints at registered function calls (that is,
PLI/VPI system tasks and functions and callbacks and FLI subprograms and callbacks and
processes created with mti_CreateProcess).
Auto step mode is helpful when you are not entirely familiar with a design and its associated C
routines. As you step through the design, ModelSim steps into and displays the associated C file
when you hit a C function call in your HDL code. If you execute a step -over or run -continue
command, ModelSim does not step into the C code.

When you first enable Auto step mode, ModelSim scans your design and sets enabled
breakpoints at all currently known function entry points. As you step through the simulation,
Auto step continues looking for newly registered callbacks and sets enabled breakpoints at any
new entry points it identifies. Once you execute a step -over or run -continue command, Auto
step disables the breakpoints it set, and the simulation continues running. The next time you
execute a step command, the automatic breakpoints are re-enabled and Auto step sets
breakpoints on any new entry points it identifies.

Note that Auto step does not disable user-set breakpoints.

Enabling Auto Step Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216

Auto Find bp Versus Auto Step Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218

Enabling Auto Step Mode

The Auto step mode allows you to automatically set up breakpoints for debugging.
Procedure
1. Configure C Debug as described in Setting Up C Debug.
2. Select Tools > C Debug > Enable auto step.
3. Load and run your design.
Examples
The graphic below shows a simulation that has stopped at a user-set breakpoint on a PLI system
task.

1216 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Enabling Auto Step Mode

Figure 25-4. Simulation Stopped at Breakpoint on PLI Task

Because Auto step mode is enabled, ModelSim automatically sets a breakpoint in the
underlying xor_gate.c file. If you click the step button at this point, ModelSim will step into that
file.

ModelSim® SE User's Manual, v10.7 1217

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Auto Find bp Versus Auto Step Mode

Figure 25-5. Stepping into Next File

Auto Find bp Versus Auto Step Mode

The Auto find bp command also locates and sets breakpoints at function entry points.
Note the following differences between Auto find bp and Auto step mode:

• Auto find bp provides a “snapshot” of currently known function entry points at the time
you invoke the command. Auto step mode continues to locate and set automatic
breakpoints in newly registered function calls as the simulation continues. In other
words, Auto find bp is static while Auto step mode is dynamic.
• Auto find bp sets automatic breakpoints in an enabled state and does not change that
state to account for step-over or run-continue commands. Auto step mode enables and
disables automatic breakpoints depending on how you step through the design. In cases
where you invoke both features, Auto step mode takes precedence over Auto find bp. In
other words, even if Auto find bp has set enabled breakpoints, if you then invoke Auto
step mode, it will toggle those breakpoints to account for step-over and run-continue
commands.

1218 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Initialization Mode

Initialization Mode
Key tasks and concepts for the initialization mode.
Debugging Functions During Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
FLI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
PLI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
VPI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Completing Design Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222

Debugging Functions During Elaboration

Initialization mode allows you to examine and debug functions that are called during
elaboration (that is, while your design is in the process of loading). When you select this mode,
ModelSim sets special breakpoints for foreign architectures and PLI/VPI modules that allow
you to set breakpoints in the initialization functions. When the design finishes loading, the
special breakpoints are automatically deleted, and any breakpoints that you set are disabled
(unless you specify Keep user init bps in the C debug setup dialog).
Procedure
1. Start C Debug by selecting Tools > C Debug > Start C Debug before loading your
design.
2. Select Tools > C Debug > Init mode.
3. Load your design.
4. As the design loads, ModelSim prints to the Transcript the names and/or hex addresses
of called functions. For example the Transcript below shows a function pointer to a
foreign architecture:
Figure 25-6. Function Pointer to Foreign Architecture

ModelSim® SE User's Manual, v10.7 1219

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
FLI Functions in Initialization Mode

5. To set a breakpoint on that function, you would type:

bp -c *0x4001b571

6. or
bp -c and_gate_init

7. ModelSim in turn reports that it has set a breakpoint at line 37 of the and_gate.c file. As
you continue through the design load using run -continue, ModelSim hits that
breakpoint and displays the file and associated line in a Source window.
Figure 25-7. Highlighted Line in Associated File

FLI Functions in Initialization Mode

There are two kinds of FLI functions that you may encounter in initialization mode. The first is
a foreign architecture which was shown above. The second is a foreign function.
ModelSim produces a Transcript message like the following when it encounters a foreign
function during initialization:

# Shared object file './all.sl'

# Function name 'in_params'
# Function ptr '0x4001a950'. Foreign function.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()

1220 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
PLI Functions in Initialization Mode

You can set a breakpoint on the function using either the function name (for example, bp -c
in_params) or the function pointer (for example, bp -c *0x4001a950). Note, however, that
foreign functions are not called during initialization. You would hit the breakpoint only during
runtime and then only if you enabled the breakpoint after initialization was complete or had
specified Keep user init bps in the C debug setup dialog.

PLI Functions in Initialization Mode

There are two methods for registering callback functions in the PLI: 1) using a veriusertfs array
to define all usertf entries; and 2) adding an init_usertfs function to explicitly register each
usertfs entry. The messages ModelSim produces in initialization mode vary depending on
which method you use.
ModelSim produces a Transcript message like the following when it encounters a veriusertfs
array during initialization:

# vsim -pli ./veriuser.sl mux_tb

# Loading ./veriuser.sl
# Shared object file './veriuser.sl'
# veriusertfs array - registering calltf
# Function ptr '0x40019518'. $or_c.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()
cont
# Shared object file './veriuser.sl'
# veriusertfs array - registering checktf
# Function ptr '0x40019570'. $or_c.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()
cont
# Shared object file './veriuser.sl'
# veriusertfs array - registering sizetf
# Function ptr '0x0'. $or_c.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()
cont
# Shared object file './veriuser.sl'
# veriusertfs array - registering misctf
# Function ptr '0x0'. $or_c.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()

You can set breakpoints on non-null callbacks using the function pointer
(for example, bp -c *0x40019570). You cannot set breakpoints on null functions. The sizetf and
misctf entries in the example above are null (the function pointer is '0x0').

ModelSim reports the entries in multiples of four with at least one entry each for calltf, checktf,
sizetf, and misctf. Checktf and sizetf functions are called during initialization but calltf and
misctf are not called until runtime.

ModelSim® SE User's Manual, v10.7 1221

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
VPI Functions in Initialization Mode

The second registration method uses init_usertfs functions for each usertfs entry. ModelSim
produces a Transcript message like the following when it encounters an init_usertfs function
during initialization:

# Shared object file './veriuser.sl'

# Function name 'init_usertfs'
# Function ptr '0x40019bec'. Before first call of init_usertfs.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()

You can set a breakpoint on the function using either the function name
(for example, bp -c init_usertfs) or the function pointer (for example, bp -c *0x40019bec).
ModelSim will hit this breakpoint as you continue through initialization.

VPI Functions in Initialization Mode

VPI functions are registered via routines placed in a table named vlog_startup_routines.
ModelSim produces a Transcript message like the following when it encounters a
vlog_startup_routines table during initialization:

# Shared object file './vpi_test.sl'

# vlog_startup_routines array
# Function ptr '0x4001d310'. Before first call using function pointer.
# C breakpoint c.1
# 0x0814fc96 in mti_cdbg_shared_objects_loaded ()

You can set a breakpoint on the function using the function pointer
(for example, bp -c *0x4001d310). ModelSim will hit this breakpoint as you continue through
initialization.

Completing Design Load

If you are through looking at the initialization code you can select Tools > C Debug >
Complete load at any time, and ModelSim will continue loading the design without stopping.
The one exception to this is if you have set a breakpoint in a LoadDone callback and also
specified Keep user init bps in the C Debug setup dialog.

Debugging Functions when Quitting

Simulation
Stop on quit mode allows you to debug functions that are called when the simulator exits.

1222 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
C Debug Command Reference

Such functions include those referenced by one of the following:

• mti_AddQuitCB function in FLI code

• misctf function called by a quit or $finish in PLI code
• cbEndofSimulation function called by a quit or $finish in VPI code.
Procedure
1. Start C Debug by choosing Tools > C Debug > Start C Debug from the main menu.
2. Choose Select Tools > C Debug > C Debug Setup from the main menu.
3. Select Stop on quit in the C Debug setup dialog box (Figure 25-8).
4. Click OK.
Figure 25-8. Stop on quit Button in Dialog

5. With this mode enabled, if you have set a breakpoint in a quit callback function, C
Debug will stop at the breakpoint after you issue the quit command in ModelSim. This
allows you to step and examine the code in the quit callback function.
6. Invoke run -continue when you are done looking at the C code. When simulation
completes, ModelSim automatically quits C-debugger and the GUI (whether or not a C
breakpoint was hit and you return to the VSIM> prompt).

C Debug Command Reference

The following table provides a brief description of the commands that you can invoke when C
Debug is running. Follow the links to the Reference Manual for complete command syntax.

Table 25-2. Command Reference for C Debug

Command Description Corresponding menu
command
bd Deletes a previously set C Right-click breakpoint in Source
breakpoint window and choose Remove
Breakpoint.

ModelSim® SE User's Manual, v10.7 1223

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
C Debug Command Reference

Table 25-2. Command Reference for C Debug (cont.)

Command Description Corresponding menu
command
bp -c Sets a C breakpoint Click in the line number column
next to the desired line number
in the Source window.
change Changes the value of a C variable none
describe Prints the type information of a C Select the C variable name in the
variable Source window and choose
Tools > Describe, or right-click
and choose Describe.
disablebp Disables a previously set C Right-click breakpoint in Source
breakpoint window and choose Disable
Breakpoint.
enablebp Enables a previously disabled C Right-click breakpoint in Source
breakpoint window and select Enable
Breakpoint.
examine Prints the value of a C variable Select the C variable name in the
Source window and choose
Tools > Examine, or right-click
and choose Examine.
gdb dir Sets the source directory search none
path for the C debugger
pop Moves the specified number of none
call frames up the C callstack
push Moves the specified number of none
call frames down the C callstack
run -continue Continues running the simulation Click the run -continue button on
after stopping the Main or Source window
toolbar.
run -finish Continues running the simulation Tools > C Debug > Run >
until control returns to the calling Finish
function
show Displays the names and types of Tools > C Debug > Show
the local variables and arguments
of the current C function
step c step in the C debugger to the Click the step or step -over
next executable line of C code; button on the Main or Source
step goes into function calls, window toolbar.
whereas step -over does not

1224 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
C Debug Command Reference

Table 25-2. Command Reference for C Debug (cont.)

Command Description Corresponding menu
command
tb Displays a stack trace of the C Tools > C Debug > Traceback
call stack

Tip
You can direct other commands to the C debugger by adding a gdb prefix to the command.
For example, to see where you are in the C stack you can enter this command:

gdb where

ModelSim® SE User's Manual, v10.7 1225

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
C Debug Command Reference

1226 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 26
Profiling Performance and Memory Use

The ModelSim profiler combines a statistical sampling profiler with a memory allocation
profiler to provide instance specific execution and memory allocation data. It allows you to
quickly determine how your memory is being allocated and easily identify areas in your
simulation where performance can be improved. The profiler can be used at all levels of design
simulation—Functional, RTL, and Gate-Level—and has the potential to save hours of
regression test time. In addition, ASIC and FPGA design flows benefit from the use of this tool.
Note
The functionality described in this chapter requires an additional license. Refer to "License
Feature Names" in the Installation and Licensing Guide for more information, or contact
your Mentor Graphics sales representative.

Introducing Performance and Memory Profiling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228

Getting Started with the Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Interpreting Profiler Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1232
Viewing Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
Viewing Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Integration with Source Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Analyzing C Code Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Searching Profiler Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Reporting Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Capacity Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244

ModelSim® SE User's Manual, v10.7 1227

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Introducing Performance and Memory Profiling

Introducing Performance and Memory

Profiling
The profiler provides an interactive graphical representation of both memory and CPU usage on
a per instance basis. It shows you what part of your design is consuming resources (CPU cycles
or memory), allowing you to more quickly find problem areas in your code.
The profiler enables those familiar with the design and validation environment to find first-level
improvements in a matter of minutes. For example, the statistical sampling profiler might show
the following:

• non-accelerated VITAL library cells that are impacting simulation run time
• objects in the sensitivity list that are not required, resulting in a process that consumes
more simulation time than necessary
• a test bench process that is active even though it is not needed
• an inefficient C module
• random number processes that are consuming simulation resources in a test bench
running in non-random mode
With this information, you can make changes to the VHDL or Verilog source code that will
speed up the simulation.

The memory allocation profiler provides insight into how much memory different parts of the
design are consuming. The two major areas of concern are typically: 1) memory usage during
elaboration, and 2) during simulation. If memory is exhausted during elaboration, for example,
memory profiling may provide insights into what part(s) of the design are memory intensive.
Or, if your HDL or PLI/FLI code is allocating memory and not freeing it when appropriate, the
memory profiler will indicate excessive memory use in particular portions of the design.

Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228

Memory Allocation Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Profile Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229

Statistical Sampling Profiler

The profiler’s statistical sampling profiler samples the current simulation at a user-determined
rate (every <n> milliseconds of real or "wall-clock" time, not simulation time) and records what
is executing at each sample point. The advantage of statistical sampling is that an entire
simulation need not be run to get good information about what parts of your design are using the
most simulation time. A few thousand samples, for example, can be accumulated before
pausing the simulation to see where simulation time is being spent.

1228 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Memory Allocation Profiler

The statistical profiler reports only on the samples that it can attribute to user code. For
example, if you use the -nodebug argument to the vcom or vlog commands, the statistical
profiler cannot report sample results.

Memory Allocation Profiler

The profiler’s memory allocation profiler records every memory allocation and deallocation
that takes place in the context of elaborating and simulating the design.
It makes a record of the design element that is active at the time of allocation so memory
resources can be attributed to appropriate parts of the design. This provides insights into
memory usage that can help you re-code designs to, for example, minimize memory use, correct
memory leaks, and change optimization parameters used at compile time.

Profile Database
The profile save and profile open commands allow writing and reading of profile data to/from
a profile database file (.pdb extension suggested).
This allows you to capture profile data during a simulation session and store it for later review
or passing to others for analysis. When you read a profile database using the profile open
command, you can then use any of the profile windows or profile report commands to analyze
data. You can also use profile save -onexit <filename> to automatically save profile results, for
all runs in a session, to the named file at the end of the session.

ModelSim® SE User's Manual, v10.7 1229

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Getting Started with the Profiler

Getting Started with the Profiler

Memory allocation profiling and statistical sampling are enabled separately.
Note
Simultaneous use of the memory allocation and statistical sampling profilers is not allowed.
Analysis of memory allocation can skew the results of the statistical sampling profiler.

Handling Large Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230

Enabling the Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Collecting Memory Allocation and Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Turning Profiling Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Running the Profiler on Windows with FLI/PLI/VPI Code . . . . . . . . . . . . . . . . . . . . . . 1232

Handling Large Files

To allow memory allocation profiling of large designs, where the design itself plus the data
required to keep track of memory allocation exceeds the memory available on the machine, the
memory profiler allows you to route raw memory allocation data to an external file. This allows
you to save the memory profile with minimal memory impact on the simulator, regardless of the
size of your design.
You can save memory profile data from the simulation only by using either the
-m -file <filename> or the -m -fileonly <filename> argument with the “profile on” command.

The -m -file <filename> option saves memory profile data from simulation to the designated
external file and makes the data available for viewing and reporting during the current
simulation.

The -m -fileonly <filename> option saves memory profile data from simulation to only the
designated external file. No data is saved for viewing and reporting during the current
simulation, which reduces the overall amount of memory required by memory allocation
profiling.

After elaboration and/or simulation is complete, a separate session can be invoked and the
profile data can be read in with the profile reload command for analysis. It should be noted,
however, that this command will clear all performance and memory profiling data collected to
that point (implicit profile clear). Any currently loaded design will be unloaded (implicit quit -
sim), and run-time profiling will be turned off (implicit profile off -m -p). If a new design is
loaded after you have read the raw profile data, then all internal profile data is cleared (implicit
profile clear), but run-time profiling is not turned back on.

1230 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Enabling the Statistical Sampling Profiler

Enabling the Statistical Sampling Profiler

The statistical sampling profiler must be enabled prior to running the simulation.
Procedure
Prior to a simulation run, do any one of the following:

• Choose Tools > Profile > Performance

• Use the profile on command.
• Click the Performance Profiling icon .

Collecting Memory Allocation and Performance

Data
Both memory allocation profiling and statistical sampling occur during the execution of a
ModelSim run command. With profiling enabled, all subsequent run commands will collect
memory allocation data and performance statistics. Profiling results are cumulative—each run
command performed with profiling enabled will add new information to the data already
gathered. To clear this data, choose Tools > Profile > Clear Profile Data or use the profile
clear command.
With the profiler enabled and a run command initiated, the simulator will provide a "Profiling"
message in the transcript to indicate that profiling has started.

If the statistical sampling profiler and the memory allocation profiler are on, the status bar will
display the number of Profile Samples collected and the amount of memory allocated, as shown
below. Each profile sample will become a data point in the simulation’s performance profile.

Figure 26-1. Status Bar: Profile Samples

Turning Profiling Off

You can turn off profiling with any one of three methods.
Procedure
Perform any one of the following:

• Deselect the Performance and/or Memory options in the Tools > Profile menu.
• Deselect the Performance Profiling and Memory Profiling icons in the toolbar.
• Use the “profile off” command with the -p or -m arguments.

ModelSim® SE User's Manual, v10.7 1231

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Running the Profiler on Windows with FLI/PLI/VPI Code

Results
Any ModelSim run commands that follow will not be profiled.

Running the Profiler on Windows with FLI/PLI/VPI

Code
You can run the profiler on Windows with a design that contains FLI/PLI/VPI code.
Procedure
1. Add these two switches to the compiling/linking command:
/DEBUG /DEBUGTYPE:COFF

2. These switches add symbols to the .dll file that the profiler can use in its report.

Interpreting Profiler Data

The utility of the data supplied by the profiler depends in large part on how your code is written.
In cases where a single model or instance consumes a high percentage of simulation time or
requires a high percentage of memory, the statistical sampling profiler or the memory allocation
profiler quickly identifies that object, allowing you to implement a change that runs faster or
requires less memory.
More commonly, simulation time or memory allocation will be spread among a handful of
modules or entities – for example, 30% of simulation time split between models X, Y, and Z; or
20% of memory allocation going to models A, B, C and D. In such situations, careful
examination and improvement of each model may result in overall speed improvement or more
efficient memory allocation.

There are times, however, when the statistical sampling and memory allocation profilers tell
you nothing more than that simulation time or memory allocation is fairly equally distributed
throughout your design. In such situations, the profiler provides little helpful information and
improvement must come from a higher level examination of how the design can be changed or
optimized.

1232 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Viewing Profiler Results

Viewing Profiler Results

The profiler provides four views of the collected data: Ranked, Design Units, Call Tree and
Structural. All four views are enabled by selecting the corresponding View > Profiling > sub-
menu item.
Note
The Ranked, Design Units, Calltree, and Structural windows, by default, only show
performance and memory profile data equal to or greater than 1 percent. You can change
this with the Profile Cutoff tool in the profile toolbar group.

Ranked Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233

Design Units Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236

Ranked Window
The Ranked window displays the results of the statistical performance profiler and the memory
allocation profiler for each function or instance. By default, ranked profiler results are sorted by
values in the In% column, which shows the percentage of the total samples collected for each
function or instance.
Click the down-arrow to the left of the Name column to open a list of available columns and
allows you to select which columns are to be hidden or displayed (Figure 26-2).

Figure 26-2. Ranked Window

ModelSim® SE User's Manual, v10.7 1233

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Design Units Window

You can sort ranked results by any other column by clicking the column heading.

The use of colors in the display provides an immediate visual indication of where your design is
spending most of its simulation time. By default, red colored text indicates functions or
instances that are consuming 5% or more of simulation time.

The Ranked window does not provide hierarchical, function-call information.

Design Units Window

The Design Units window displays the profiler results, aggregated for the different design units.
This window provides information similar to the Structural window, but organized by design
unit, rather than hierarchically.
Figure 26-3. Design Units Window

Calltree Window
Data collection for the calltrees is off by default for memory profiling and on for performance
profiling. Collection can be turned on from the VSIM command prompt with profile option
collect_calltrees on and off with profile option collect_calltrees off.
By default, profiler results in the Calltree window are sorted according to the Under(%) column,
which shows the percentage of the total samples collected for each function or instance and all
supporting routines or instances. Sort results by any other column by clicking the column
heading. As in the Ranked window, red object names indicate functions or instances that, by
default, are consuming 5% or more of simulation time.

The Calltree window differs from the Ranked window in two important respects.

1234 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Calltree Window

• Entries in the Name column of the Calltree window are indented in hierarchical order to
indicate which functions or routines call which others.
• A %Parent column in the Calltree window allows you to see what percentage of a parent
routine’s simulation time is used in which subroutines.
The Calltree window presents data in a call-stack format that provides more context than does
the Ranked window about where simulation time is spent. For example, your models may
contain several instances of a utility function that computes the maximum of 3-delay values. A
Ranked window might reveal that the simulation spent 60% of its time in this utility function,
but would not tell you which routine or routines were making the most use of it. The Calltree
window will reveal which line is calling the function most frequently. Using this information,
you might decide that instead of calling the function every time to compute the maximum of the
3-delays, this spot in your VHDL code can be used to compute it just once. You can then store
the maximum delay value in a local variable.

The %Parent column in the Calltree window shows the percent of simulation time or allocated
memory a given function or instance is using of its parent’s total simulation time or available
memory. From this column, you can calculate the percentage of total simulation time or
memory taken up by any function. For example, if a particular parent entry used 10% of the
total simulation time or allocated memory, and it called a routine that used 80% of its simulation
time or memory, then the percentage of total simulation time spent in, or memory allocated to,
that routine would be 80% of 10%, or 8%.

In addition to these differences, the Ranked window displays any particular function only once,
regardless of where it was used. In the Calltree window, the function can appear multiple
times—each time in the context of where it was used.

Figure 26-4. Calltree Window

ModelSim® SE User's Manual, v10.7 1235

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Structural Window

Structural Window
The Structural profile window displays instance-specific performance and memory profile
information in a hierarchical structure format identical to the Structure window. It contains the
same information found in the Calltree window but adds an additional dimension with which to
categorize performance samples and memory allocation. It shows how call stacks are associated
with different instances in the design.
Figure 26-5. Structural Window

In the Calltree and Structural profile windows, you can expand and collapse the various levels
to hide data that is not useful to the current analysis and/or is cluttering the display. Click the '+'
box next to an object name to expand the hierarchy and show supporting functions and/or
instances beneath it. Click the '-' box to collapse all levels beneath the entry.

You can right-click any function or instance in the Calltree and Structural windows to obtain
popup menu selections for rooting the display to the currently selected item, to ascend the
displayed root by one level, or to expand and collapse the hierarchy (Figure 26-6).

Figure 26-6. Expand and Collapse Selections in Popup Menu

Toggling Display of Call Stack Entries

By default, call stack entries do not displayed in the Structural window. To display the Call
Stack window, choose the View > Call Stack menu item.

1236 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Viewing Profile Details

Viewing Profile Details

The Profiler increases visibility into simulation performance and memory usage with dynamic
links to the Source window and the Profile Details window. The Profile Details window is
enabled by selecting View > Profiling > Profile Details or by entering the view profiledetails
command at the VSIM prompt. You can also right-click any function or instance in the Ranked,
Calltree, or Structural windows to open a popup menu that includes options for viewing profile
details. The following options are available:
• View Source — opens the Source window to the location of the selected function.
• View Instantiation — opens the Source window to the location of the instantiation.
• Function Usage — opens the Profile Details window and displays all instances using
the selected function.
In the Profile Details window shown below, all the instances using function
Tcl_WaitForEvent are displayed. The statistical performance data shows how much
simulation time is used by Tcl_WaitForEvent in each instance.
Figure 26-7. Profile Details Window: Function Usage

• Instance Usage — opens the Profile Details window and displays all instances with the
same definition as the selected instance.
Figure 26-8. Profile Details Window: Instance Usage

• View Instantiation — opens the Source window to the point in the source code where
the selected instance is instantiated.
• Callers and Callees — opens the Profile Details window and displays the callers and
callees for the selected function. Items above the selected function are callers; items
below are callees.

ModelSim® SE User's Manual, v10.7 1237

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Integration with Source Windows

The selected function is distinguished with an arrow on the left and in 'hotForeground'
color as shown below.
Figure 26-9. Profile Details Window: Callers and Callees

• Display in Call Tree — expands the Calltree window and displays all occurrences of
the selected function and puts the selected function into a search buffer so you can easily
cycle across all occurrences of that function.
Note that profile-data collection for the calltree is off by default for memory profiling
and on for performance profiling. See Calltree Window for additional information on
collecting call-stack data.
• Display in Structural — expands the Structural window and displays all occurrences of
the selected function and puts the selected function into a search buffer so you can easily
cycle across all occurrences of that function.

Integration with Source Windows

The Ranked, Design Unit, Call Tree, and Structural windows are all dynamically linked to
Source window. You can double-click any function or instance in these windows to bring up
that object in a Source window with the selected line displayed.

1238 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Analyzing C Code Performance

Figure 26-10. Accessing Source from Profile Views

You can perform the same task by right-clicking any function or instance in any one of the four
Profile views and choosing View Source from the popup menu that opens.

When you right-click an instance in the Structural window, the View Instantiation selection
will become active in the popup menu. Choosing this option opens the instantiation in a Source
window and highlights it.

The right-click popup menu also allows you to change the root instance of the display, ascend to
the next highest root instance, or reset the root instance to the top level instance.

The selection of a context in the structure window will cause the root display to be set in the
Structural window.

Analyzing C Code Performance

You can include C code in your design via SystemC, the Verilog PLI/VPI, or the ModelSim
FLI. The profiler can be used to determine the impact of these C modules on simulator
performance. Compiling your C code with debug symbols enables the profiler to report
functions accurately.
Factors that can affect simulator performance when a design includes C code are as follows:

• PLI applications with large sensitivity lists

• Calling operating system functions from C code

ModelSim® SE User's Manual, v10.7 1239

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Searching Profiler Results

• Calling the simulator’s command interpreter from C code

• Inefficient C code
In addition, the Verilog PLI/VPI requires maintenance of the simulator’s internal data structures
as well as the PLI/VPI data structures for portability.

Searching Profiler Results

Each of the Profiler windows provides find and filter functions to assist you in isolating and
examining specific results.
Procedure
1. A “Find” toolbar will appear along the bottom edge of the active window when you do
any one of the following:
• Select Edit > Find in the menu bar.

• Click the Find icon in the Standard toolbar.

• Press Ctrl-F on your Windows keyboard.

2. Click the (X) icon at the left-end of the Find toolbar to close it.
Results
The Find or Filter entry fields pre-fill as you type, based on the context of the current window
selection. The find or filter action begins as you type.
Related Topics
Find and Filter Functions [ModelSim SE GUI Reference Manual]

Reporting Profiler Results

ModelSim allows you to easily create performance and memory profile reports using the Profile
Report dialog or the profile report command.
Procedure
Do either of the following to create a profile report:

• Use the profile report command at the command line.

• Choose Tools > Profile > Profile Report to open the Profile Report dialog
(Figure 26-11).
The Profile Report dialog box allows you to select the following performance profile
type for reporting: Calltree, Ranked, Structural, Callers and Callees, Function to

1240 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Reporting Profiler Results

Instance, and Instances using the same definition. When the Structural profile type is
selected, you can designate the root instance pathname, include function call
hierarchy, and specify the structure level to be reported.

Note
The Structural profile type reports samples of code that are not associated with
an instance of the design as NoContext, reports simulator time spent updating
and propagating values that do not retain their value as NetActivity, and reports
simulator time spent executing processes that do not retain their identity as
ProcessActivity. The simulator combines multiple assertions into a single process
when possible, making it impossible to attribute the sample to the actual process, so
the structural profile reports time spent executing processes specific to assertions as
AssertionActivity. When simulator time is spent executing processes specific to
coverage, but the specific coverage statement is not known, the samples are reported
as CoverageActivity. The structural profile reports samples of code that represent
time spent in the simulation kernel switching to the next timing region, or advancing
delta time, or in simulation time as AdvanceTime.

You can elect to report performance information only, memory information only, or
a both. By default, all data collected will be reported.
Both performance and memory data will be displayed with a default cutoff of 0% —
meaning, the report will contain any functions or instances that use simulation time
or memory — unless you specify a different cutoff percentage.
You may elect to write the report directly to the Transcript window or to a file. If the
"View file" box is selected, the profile report will be generated and immediately
displayed in Notepad when you click the OK.

ModelSim® SE User's Manual, v10.7 1241

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Reporting Profiler Results

Figure 26-11. Profile Report Dialog Box

Examples
The command:

profile report -calltree -file calltree.rpt -cutoff 2

will produce a Call Tree profile report in a text file called calltree.rpt, as shown in Figure 26-12.

1242 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Reporting Profiler Results

Figure 26-12. Profile Report Example

ModelSim® SE User's Manual, v10.7 1243

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Capacity Analysis

Capacity Analysis
ModelSim collects data on memory usage (capacity) while the simulation is running. You can
display this data in the Capacity window of the graphical user interface.
The following types of SystemVerilog constructs are supported for capacity analysis:

• Classes
• Queues, dynamic arrays, and associative arrays and strings (QDAS)
• Assertions and cover directives
• Covergroups
• Solver (calls to randomize() )
• Verilog memories
• Some static design objects
ModelSim updates memory usage data at the end of every time step of the simulation and
collects:

• the number of objects allocated

• the current memory allocated for the language construct grouping
• the peak memory allocated
• and the time at which peak memory occurred
You can display this data in column format in the Capacity window of the user interface (see
Opening the Capacity Window), as a graph or as signal waveforms in the Wave window, or as a
text-based report in the Transcript window (see Writing a Text-Based Report) which you can
also write to a text file.

Enabling or Disabling Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245

Levels of Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Consolidated Memory Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Opening the Capacity Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Displaying Capacity Data in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Writing a Text-Based Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Reporting Capacity Analysis Data From a UCDB File . . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Examining Memory Usage for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1254

1244 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Enabling or Disabling Capacity Analysis

Enabling or Disabling Capacity Analysis

When you invoke ModelSim, you can use the vsim command arguments to select one of the
following levels of capacity analysis before loading your design:
• Coarse-grain analysis — enabled by default (no additional vsim argument required)
• Fine-grain analysis — enabled by specifying the -capacity argument (other vsim
arguments may be used with -capacity)
• No analysis — enabled by specifying -nocapacity (other vsim arguments may be used
with -nocapacity)

Note
Coarse-level and fine-level analyses are described in Levels of Capacity Analysis.

In addition, you can use various other commands to enable collection of memory capacity data,
along with viewing and reporting that data. Table 26-1 summarizes the different ways to enable,
view, and report memory capacity data.

Refer to the ModelSim Reference Manual for more information on using the commands listed
in Table 26-1.
Table 26-1. Commands for Enabling and Viewing Capacity Analysis
Command Result Description
vsim <filename> Collects coarse-grain No need to explicitly
analysis data. specify a coarse-grain
analysis; enabled by default.
vsim -capacity <filename> Collects fine-grain analysis Overrides default coarse-
data. grain analysis.
vsim -nocapacity <filename> Disables capacity analysis. No capacity data is
collected.
view capacity Displays the Capacity Same as choosing View >
window containing capacity Capacity from main menu.
data.
write report Reports data on memory Use the -capacity switch
{[-capacity [-l | -s] [-line] | capacity in either the along with other switches
[-assertions] | -classes | -cvg | - Transcript window or to a for object types to display
solver | -qdas | -vmem]]} file. memory data.
coverage report -memory Reports coarse-grain data in Use with -cvg and -details
either the Transcript switches to obtain fine-
window or to a file. grain data for covergroups.

ModelSim® SE User's Manual, v10.7 1245

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Enabling or Disabling Capacity Analysis

Table 26-1. Commands for Enabling and Viewing Capacity Analysis (cont.)
Command Result Description
vcover report -memory Reports coarse-grain data Use with -cvg and -details
from a previously saved switches to obtain fine-
code or functional coverage grain data for covergroups.
run in either the Transcript
window or to a file.
vcover stats -memory Reports coarse-grain data No fine-grain analysis
from a previously saved available.
code or functional coverage
run in either the Transcript
window or to a file.
Choose View > Capacity Displays the Capacity Same as entering the view
from main menu window containing capacity capacity command.
data.

1246 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Levels of Capacity Analysis

Levels of Capacity Analysis

ModelSim collects data as either a coarse-grain analysis or a fine-grain analysis of memory
capacity. The main difference between the two levels is the specificity of the capacity data
collected — coarse-grain is a summary and fine-grain is detailed.
Coarse-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Fine-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Enabling Fine-Grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248

Coarse-grain Analysis
The coarse-grain analysis data is enabled by default when you run the vsim command. The
purpose of this analysis is to provide a simple summary of the number of objects, the memory
allocated for each class of design objects, the peak memory allocated, and the time at which
peak memory occurred.
You can display the results of a coarse-grain analysis as either a graphical display in the user
interface (see Opening the Capacity Window) or as a text report (see Writing a Text-Based
Report).

Fine-grain Analysis
When you enable a fine-grain analysis, ModelSim collects detailed capacity data that you can
use to dig deeper into the area where memory consumption is problematic. The details about
each type of object are further quantified.
The display of the Capacity window expands the coarse-grain categories and shows the count
and current memory allocation per object declaration.

The solver data is expanded to show peak memory allocation per randomize call.

Classes — displays aggregate information about number of objects and memory usage for each
class type, including the name, file name and line number where the class is declared.

QDAS — displays aggregate information about number of objects and memory usage for each
object (queues, dynamic, associative and strings), including the name, file name and line
number where it is declared.

Assertions — displays aggregate information about the number of threads and memory usage
for each active assertion, including the name, file name and the line number where it is declared.

Covergroups — displays the aggregate information about the number of objects and memory
usage for each covergroup including name, file name and the line number where it is declared.

ModelSim® SE User's Manual, v10.7 1247

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Consolidated Memory Reports

Solver — displays the aggregate information about the number of calls and peak memory usage
for each randomize() call, including the file name and line number.

Verilog Memories — displays aggregate information about number of objects and memory
usage for each object (sparse or non-sparse memories), including the name, file name and line
number where it is declared.

Enabling Fine-Grain Analysis

Fine-grain analysis is enabled by using the -capacity argument with the vsim command.
Procedure
Enter the following at the command line to enable fine-grain analysis:

vsim -capacity

This generates capacity data based on the point of declaration. To show the point of
allocation as well as the point of declaration, use the “=line” option with -capacity as
follows:
vsim -capacity=line

You can then generate a fine-grained point of allocation (line) based report with the
write report command as follows:
write report -capacity -l -line

Consolidated Memory Reports

You can use the capstats command or the vsim -capstats argument to print a consolidated report
of the complete memory usage of your design. Both the command and the argument work on
fully optimized designs.
To get the most accurate and detailed memory reports, use capstats in conjunction with the vsim
-capacity argument.

The capstats consolidated memory report includes the following sections:

• A report header displaying information such as total memory usage, tools details,
collection simtime and so on.
• A top-level summary and category distribution of total memory usage.
• A detailed section for each top-level category.
• A detailed section for line-based and/or declaration based SV dynamic objects.
• A detailed section for design units.

1248 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Consolidated Memory Reports

Note
The report does not include memory allocated by PLI applications through system memory
calls.

The report divides total memory into a set of top level categories that show the memory used by
different segments of the design or tool. The top level categories include:

• HDL: Memory used by different HDL design objects.

• ELABORATION: Memory used during the design elaboration.
• SESSION_INFO: Memory used to allocate data that can be used across multiple
simulations.
• DESIGN_UNITS: Memory used for design units data structure.
• PRIMITIVES: Memory used for primitives data structure.
• COVERAGE: Memory used by coverage related functionality.
• COVERGROUP: Memory used by covergroups.
• PLI/VPI/FLI/OMI: Memory used to handle PLI/VPI/FLI/OMI calls.
• TIMING: Memory used to implement timing checks.
• QIS: Memory used by QIS data structure.
• QWAVEDB: Memory used to handle qwavedb generation.
• SOLVER: Memory used for randomization functionality.
• UCDB: Memory used for UCDB functionality.
• WLF: Memory used for waveform viewing/generation.
• PA: Memory used for Power Aware functionality.
• SDF: Memory used by SDF files.
• DPI: Memory used by DPI related functionality.
• DATAFLOW: Memory used by dataflow related functionality.
• DEBUG: Memory used to provide some of the debugging information.
• PROFILER: Memory used by the profiler.
• TCL: Memory used by the tcl code.
• GUI: Memory used by for graphical user interface related functionality.
• MPC: Memory used to provide multiple processor support.
• LIBRARY_INFO: Memory used by library data.

ModelSim® SE User's Manual, v10.7 1249

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Opening the Capacity Window

• OPT_DESIGN: Memory used to create optimized design.

Opening the Capacity Window

The Capacity window displays a tabular listing of memory capacity data.
Procedure
Choose View > Capacity from the main menu or enter the view command with “capacity” as
the window type:

view capacity

Results
This creates the Capacity window that displays memory data for the current design
(Figure 26-13).
Figure 26-13. The Capacity Window

Related Topics
Capacity-Object and Capacity-Line Windows [ModelSim SE GUI Reference Manual]

Displaying Capacity Data in the Wave Window

You can add capacity information to the Wave window like any other signal. Simply drag-and-
drop a capacity type from the Objects window to the Wave window, or use the add wave
command.
Procedure
1. To use the drag and drop method:
a. Click the Structure (sim) window tab.

1250 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Writing a Text-Based Report

b. Select the Instance labeled #vsim_capacity#. Selecting this instance displays a set of
capacity types in the Objects window (see Figure 26-14).
c. Select one or more objects in the Objects window. Note that you can click the [+]
indicator to expand the listing of data below any type.
d. Drag and drop the selected objects to the Wave window or click the middle mouse
button when the cursor is over an object.
Figure 26-14. Displaying Capacity Objects in the Wave Window

2. To use the add wave command the correct syntax is:

add wave /#vsim_capacity#/ {* | assertions | classes | covergroups | qdas | solver |
memories | totals}[.{Count | Current | Peak | Time}]
Examples
To display the count for classes in the Wave window, enter the following:

add wave /#vsim_capacity#/classes.Count

The “totals” argument creates a pool for memory data so you can see its growth. It allows you to
produce an analog waveform of the memory usage, which is especially useful for revealing
where you are leaking memory. Enter the command as follows:

add wave -format Analog-Step -height 300 -max 1300000000.0 -radix decimal /
#vsim_capacity#/totals

The default format of the "totals" field in the #vsim_capacity# region is Analog, with a height of
500 and a maximum value that corresponds to the available physical memory.

Writing a Text-Based Report

ModelSim allows you to easily generate text-based reports of capacity data using the write
report command.

ModelSim® SE User's Manual, v10.7 1251

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Writing a Text-Based Report

Procedure
1. The proper syntax for generating a text-based capacity data report with the write report
command is:
write report -capacity [-l | -s] [-line] [-qdas | -assertions | -classes | -cvg | -solver | -
vmem]

2. When you specify -s or no other switch, the tool reports coarse-grain analysis. When you
specify -l, it reports the fine-grain analysis.
3. When you specify -capacity -l -line together, the tool reports fine-grained point of
allocation (line) based capacity data. (You must use vsim -capacity=line prior to this
step to create a line-based capacity data.)
Examples
This command,

write report -capacity -l -qdas

1252 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Writing a Text-Based Report

produces a report with the following format:

Reporting total capacity data for QDAS objects

Objects CurrMem PeakMem PeakTime@ps
---------- ---------- ---------- -------------
4125086 290.0M 304.0M 40000001Reporting detailed capacity data for
Dynamic arrays
Objects CurrMem Name Type FileInfo
---------- ------- ------ ------------- --------------------
1 12B data Dynamic Array xackdoorModule.sv(12)
1 12B data Dynamic Array
pTopBackdoorModule.sv(18)Reporting detailed capacity data for Queues
Objects CurrMem Name Type FileInfo
---------- ------- ------ ------------- --------------------
297 42.0K UNKNOWN Queue uvm_queue.svh(36)
201 25.7K items Queue std.sv(20)
8 1.0K UNKNOWN Queue uvm_callback.svh(467) # Total
Memory Allocated:3866920
# TYPE: (COUNT, CURRENT MEM, PEAK MEM, PEAK MEM TIME)
# Classes: (159, 16136, 16136, 4450 ns)
# /std::semaphore: (18, 504, 504, 1650 ns)
# verilog_src/std/std.sv(25): (10, 280, 280, 1650 ns)
# /std::process: (8, 256, 320, 1658 ns)
# src/test_router.sv(309): (97, 12416, 12416, 4450 ns)
# /test_router_sv_unit::scoreboard: (1, 168, 168, 1650 ns)
# src/test_router.sv(355): (1, 168, 168, 1650 ns)
# QDAS: (310, 3078, 3091, 4450 ns)
# Arrays: (300, 2170, 2183, 4450 ns)
#src/test_router.sv(355): (1, 40, 40, 1650 ns)
# src/defs.sv(24): (97, 194, 194, 4450ns)
# <NOFILE>: (15, 26, 26, 4450 ns)
# Queues: (9, 888, 888, 1657 ns)
# c:/verilog_src/std/std.sv(39): (9, 888, 888, 1657 ns)
# Associative: (1, 20, 20, 1650 ns)
# src/test_router.sv(355): (1, 20, 20, 1650 ns)
# Assertions/Cover Directives: (0, 0, 0, 0 ns)
# Covergroups: (3, 1696, 1696, 1650 ns)
# /test_router_sv_unit::scoreboard::cov1: (3, 1696, 1696, 1650 ns)
# Solver: (97, 2072816, 2081036, 1651 ns)
# src/test_router.sv(311): (97, 2891148, 2891148, 4450 ns)

Note
'UNKNOWN' object name is displayed if the object is either an implicit object or it is in
protected part of the design.

To generate a point of allocation (line) based capacity report, use the following syntax:

write report -capacity -l -line

Vsim must be run with -capacity=line to print a line-based capacity report.

ModelSim® SE User's Manual, v10.7 1253

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Reporting Capacity Analysis Data From a UCDB File

Reporting Capacity Analysis Data From a UCDB

File
By default, coarse-grain analysis data is saved into a UCDB file, along with the simulation
coverage data using the coverage save command. You can report this data from UCDB file
using the vcover report command or the vcover stats command.
Procedure
1. The proper syntax for using the vcover report command or the vcover stats command to
report capacity analysis data from a UCDB file is as follows:
vcover report -memory <UCDB_filename>
vcover stats -memory <UCDB_filename>

2. Currently the fine-grain analysis data is not available from this report except as details
related to covergroup memory usage.
3. To report the covergroup memory usage details, you can use the vcover report command
with the following arguments:
vcover report -cvg -details -memory

Examples
The command,

vcover report -memory test.ucdb

produces a report with the following format:

COVERGROUP MEMORY USAGE: Total 13.3 KBytes, Peak 13.3 KBytes at time 0 ns
for total 4 coverpoints/crosses.

ASSERT/COVER MEMORY USAGE: Total Memory 0 Bytes.

CONSTRAINT SOLVER MEMORY USAGE: Total 1.1 MBytes, Peak 1.1 MBytes at time
0 ns for total 100 randomize() calls.
CLASS OBJECTS MEMORY USAGE: Total Memory 68 Bytes and Peak Memory 68 Bytes
used at time 0 ns for total 1 class objects.

DYNAMIC OBJECTS MEMORY USAGE: Total Memory 35 Bytes and Peak Memory 35
Bytes used at time 0 ns for total 2 dynamic objects.

Examining Memory Usage for Assertions and

Cover Directives
Although it is not the same as reporting memory capacity, the assertion profile command
generates a report of memory usage for assertions and cover directives. The -threadthreshold
switch of this command sets a minimum memory level (threshold) that generates a report
statement each time an assertion or cover statement exceeds that level.

1254 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Profiling Performance and Memory Use
Examining Memory Usage for Assertions and Cover Directives

Related Topics
assertion profile [ModelSim SE Command Reference Manual]
ModelSim Reference Manual

ModelSim® SE User's Manual, v10.7 1255

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Profiling Performance and Memory Use
Examining Memory Usage for Assertions and Cover Directives

1256 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 27
Signal Spy

The Verilog language allows access to any signal from any other hierarchical block without
having to route it through the interface. This means you can use hierarchical notation to either
write or read the value of a signal in the design hierarchy from a test bench. Verilog can also
reference a signal in a VHDL block or reference a signal in a Verilog block through a level of
VHDL hierarchy.
Signal Spy Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Signal Spy Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261

ModelSim® SE User's Manual, v10.7 1257

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
Signal Spy Concepts

Signal Spy Concepts

Signal Spy procedures for VHDL are provided in the VHDL Utilities Package (util) within the
modelsim_lib library.
To access these procedures, you would add lines like the following to your VHDL code:

library modelsim_lib;
use modelsim_lib.util.all;

The Verilog tasks and SystemC functions are available as built-in SystemVerilog System Tasks
and Functions.
Table 27-1. Signal Spy Reference Comparison
Refer to: VHDL procedures Verilog system tasks SystemC function
disable_signal_spy disable_signal_spy() $disable_signal_spy() disable_signal_spy()
enable_signal_spy enable_signal_spy() $enable_signal_spy() enable_signal_spy()
init_signal_driver init_signal_driver() $init_signal_driver() init_signal_driver()
init_signal_spy init_signal_spy() $init_signal_spy() init_signal_spy()
signal_force signal_force() $signal_force() signal_force()
signal_release signal_release() $signal_release() signal_release()

Note that using Signal Spy procedures limits the portability of your code—HDL code with
Signal Spy procedures or tasks works only in Questa and Modelsim. Consequently, you should
use Signal Spy only in test benches, where portability is less of a concern and the need for such
procedures and tasks is more applicable.

Signal Spy Formatting Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258

Signal Spy Supported Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259

Signal Spy Formatting Syntax

Strings that you pass to Signal Spy commands are not language-specific and should be
formatted as if you were referring to the object from the command line of the simulator. Thus,
you use the simulator's path separator. For example, the Verilog LRM specifies that a Verilog
hierarchical reference to an object always has a period (.) as the hierarchical separator, but the
reference does not begin with a period.
The following pathname lookup rules are used by the SignalSpy commands:

• If the name does not include a dataset name, then the current dataset is used.
• If the name does not start with a path separator, then the current context is used.

1258 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
Signal Spy Supported Types

• If the name is a path separator followed by a name that is not the name of a top-level
design unit, then the first top-level design unit in the design is used.
• For a relative name containing a hierarchical path, if the first object name cannot be
found in the current context, then an upward search is done up to the top of the design
hierarchy to look for a matching object name.
• If no objects of the specified name can be found in the specified context, then an upward
search is done to look for a matching object in any visible enclosing scope up to an
instance boundary. If at least one match is found within a given context, no (more)
upward searching is done; therefore, some objects that may be visible from a given
context will not be found when wildcards are used if they are within a higher enclosing
scope.
• The wildcards '*' and '?' can be used at any level of a name except in the dataset name
and inside of a slice specification.
• A wildcard character will never match a path separator. For example, /dut/* will match /
dut/siga and /dut/clk. However, /dut* will not match either of those.
Related Topics
VHDL Utilities Package (util)

Signal Spy Supported Types

Signal Spy supports the following SystemVerilog types and user-defined SystemC types.
• SystemVerilog types
o All scalar and integer SV types (bit, logic, int, shortint, longint, integer, byte, both
signed and unsigned variations of these types)
o Real and Shortreal
o User defined types (packed/unpacked structures including nested structures, packed/
unpacked unions, enums)
o Arrays and Multi-D arrays of all supported types.
• SystemC types
o Primitive C floating point types (double, float)
o User defined types (structures including nested structures, unions, enums)
Cross-language type-checks and mappings are included to support these types across all the
possible language combinations:

• SystemC-SystemVerilog
• SystemC-SystemC

ModelSim® SE User's Manual, v10.7 1259

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
Signal Spy Supported Types

• SystemC-VHDL
• VHDL-SystemVerilog
• SystemVerilog-SystemVerilog
In addition to referring to the complete signal, you can also address the bit-selects, field-selects
and part-selects of the supported types. For example:

/top/myInst/my_record[2].my_field1[4].my_vector[8]

1260 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
Signal Spy Reference

Signal Spy Reference

The signal spy calls enumerated below include the syntax and arguments for the VHDL
procedure, the Verilog task, and the SystemC function for each call.
disable_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
enable_signal_spy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
init_signal_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266
init_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
signal_force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
signal_release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278

ModelSim® SE User's Manual, v10.7 1261

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
disable_signal_spy

disable_signal_spy
This reference section describes the following:
• VHDL Procedure — disable_signal_spy()
• Verilog Task — $disable_signal_spy()
• SystemC Function — disable_signal_spy()
The disable_signal_spy call disables the associated init_signal_spy. The association between
the disable_signal_spy call and the init_signal_spy call is based on specifying the same
src_object and dest_object arguments to both. The disable_signal_spy call can only affect
init_signal_spy calls that had their control_state argument set to “0” or “1”.
Syntax
VHDL Syntax
disable_signal_spy(<src_object>, <dest_object>, <verbose>)
Verilog Syntax
$disable_signal_spy(<src_object>, <dest_object>, <verbose>)
SystemC Syntax
disable_signal_spy(<src_object>, <dest_object>, <verbose>)
Arguments
• src_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal, SystemVerilog or Verilog register/net, or SystemC signal.
This path should match the path that was specified in the init_signal_spy call that you want
to disable.
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal, SystemVerilog or Verilog register/net, or SystemC signal.
This path should match the path that was specified in the init_signal_spy call that you want
to disable.
• verbose
Optional integer. Specifies whether you want a message reported in the transcript stating
that a disable occurred and the simulation time that it occurred.
0 — Does not report a message. Default.
1 — Reports a message.
Return Values
Nothing

1262 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
disable_signal_spy

Description
By default this command uses a forward slash (/) as a path separator. You can change this
behavior with the SignalSpyPathSeparator variable in the modelsim.ini file.

Examples
See init_signal_spy.

Related Topics
init_signal_spy
enable_signal_spy

ModelSim® SE User's Manual, v10.7 1263

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
enable_signal_spy

enable_signal_spy
This reference section describes the following:
• VHDL Procedure — enable_signal_spy()
• Verilog Task — $enable_signal_spy()
• SystemC Function — enable_signal_spy()
The enable_signal_spy() call enables the associated init_signal_spy call. The association
between the enable_signal_spy call and the init_signal_spy call is based on specifying the same
src_object and dest_object arguments to both. The enable_signal_spy call can only affect
init_signal_spy calls that had their control_state argument set to “0” or “1”.
Syntax
VHDL Syntax
enable_signal_spy(<src_object>, <dest_object>, <verbose>)
Verilog Syntax
$enable_signal_spy(<src_object>, <dest_object>, <verbose>)
SystemC Syntax
enable_signal_spy(<src_object>, <dest_object>, <verbose>)
Arguments
• src_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal, SystemVerilog or Verilog register/net, or SystemC signal.
This path should match the path that was specified in the init_signal_spy call that you want
to enable.
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal, SystemVerilog or Verilog register/net, or SystemC signal.
This path should match the path that was specified in the init_signal_spy call that you want
to enable.
• verbose
Optional integer. Possible values are 0 or 1. Specifies whether you want a message reported
in the transcript stating that an enable occurred and the simulation time that it occurred.
0 — Does not report a message. Default.
1 — Reports a message.
Return Values
Nothing

1264 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
enable_signal_spy

Description
By default this command uses a forward slash (/) as a path separator. You can change this
behavior with the SignalSpyPathSeparator variable in the modelsim.ini file.

Related Topics
init_signal_spy
disable_signal_spy

ModelSim® SE User's Manual, v10.7 1265

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
init_signal_driver

init_signal_driver
This reference section describes the following:
• VHDL Procedure — init_signal_driver()
• Verilog Task — $init_signal_driver()
• SystemC Function— init_signal_driver()
The init_signal_driver() call drives the value of a VHDL signal, Verilog net, or SystemC (called
the src_object) onto an existing VHDL signal or Verilog net (called the dest_object). This
allows you to drive signals or nets at any level of the design hierarchy from within a VHDL
architecture or Verilog or SystemC module (for example, a test bench).
Note
Destination SystemC signals are not supported.

Syntax
VHDL Syntax
init_signal_driver(<src_object>, <dest_object>, <delay>, <delay_type>, <verbose>)
Verilog Syntax
$init_signal_driver(<src_object>, <dest_object>, <delay>, <delay_type>, <verbose>)
SystemC Syntax
init_signal_driver(<src_object>, <dest_object>, <delay>, <delay_type>, <verbose>)
Arguments
• src_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal, Verilog net, or SystemC signal. Use the path separator to
which your simulation is set (for example, “/” or “.”). A full hierarchical path must begin
with a “/” or “.”. The path must be contained within double quotes.
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to an existing VHDL signal or Verilog net. Use the path separator to which
your simulation is set (for example, “/” or “.”). A full hierarchical path must begin with a “/
” or “.”. The path must be contained within double quotes.
• delay
Optional time value. Specifies a delay relative to the time at which the src_object changes.
The delay can be an inertial or transport delay. If no delay is specified, then a delay of zero
is assumed.

1266 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
init_signal_driver

• delay_type
Optional del_mode or integer. Specifies the type of delay that will be applied.
For the VHDL init_signal_driver Procedure, The value must be either:
mti_inertial (default)
mti_transport
For the Verilog $init_signal_driver Task, The value must be either:
0 — inertial (default)
1 — transport
For the SystemC init_signal_driver Function, The value must be either:
0 — inertial (default)
1 — transport
• verbose
Optional integer. Possible values are 0 or 1. Specifies whether you want a message reported
in the Transcript stating that the src_object is driving the dest_object.
0 — Does not report a message. Default.
1 — Reports a message.
Return Values
Nothing

Description
The init_signal_driver procedure drives the value onto the destination signal just as if the
signals were directly connected in the HDL code. Any existing or subsequent drive or force of
the destination signal, by some other means, will be considered with the init_signal_driver value
in the resolution of the signal.By default this command uses a forward slash (/) as a path
separator. You can change this behavior with the SignalSpyPathSeparator variable in the
modelsim.ini file.

Call Only Once

The init_signal_driver procedure creates a persistent relationship between the source and
destination signals. Hence, you need to call init_signal_driver only once for a particular pair of
signals. Once init_signal_driver is called, any change on the source signal will be driven on the
destination signal until the end of the simulation.

For VHDL, you should place all init_signal_driver calls in a VHDL process and code this
VHDL process correctly so that it is executed only once. The VHDL process should not be
sensitive to any signals and should contain only init_signal_driver calls and a simple wait
statement. The process will execute once and then wait forever. See the example below.

ModelSim® SE User's Manual, v10.7 1267

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
init_signal_driver

For Verilog, you should place all $init_signal_driver calls in a Verilog initial block. See the
example below.

Limitations
• For the VHDL init_signal_driver procedure, when driving a Verilog net, the only
delay_type allowed is inertial. If you set the delay type to mti_transport, the setting will
be ignored and the delay type will be mti_inertial.
• For the Verilog $init_signal_driver task, when driving a Verilog net, the only delay_type
allowed is inertial. If you set the delay type to 1 (transport), the setting will be ignored,
and the delay type will be inertial.
• For the SystemC init_signal_driver function, when driving a Verilog net, the only
delay_type allowed is inertial. If you set the delay type to 1 (transport), the setting will
be ignored, and the delay type will be inertial.
• Any delays that are set to a value less than the simulator resolution will be rounded to
the nearest resolution unit; no special warning will be issued.
• Verilog memories (arrays of registers) are not supported.
Examples
This example creates a local clock (clk0) and connects it to two clocks within the design
hierarchy. The .../blk1/clk will match local clk0 and a message will be displayed. The .../blk2/clk
will match the local clk0 but be delayed by 100 ps. For the second call to work, the .../blk2/clk
must be a VHDL based signal, because if it were a Verilog net a 100 ps inertial delay would
consume the 40 ps clock period. Verilog nets are limited to only inertial delays and thus the
setting of 1 (transport delay) would be ignored.

`timescale 1 ps / 1 ps

module testbench;

reg clk0;

initial begin
clk0 = 1;
forever begin
#20 clk0 = ~clk0;
end
end

initial begin
$init_signal_driver("clk0", "/testbench/uut/blk1/clk", , , 1);
$init_signal_driver("clk0", "/testbench/uut/blk2/clk", 100, 1);
end

...

endmodule

1268 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
init_signal_driver

This example creates a local clock (clk0) and connects it to two clocks within the design
hierarchy. The .../blk1/clk will match local clk0 and a message will be displayed. The open
entries allow the default delay and delay_type while setting the verbose parameter to a 1. The .../
blk2/clk will match the local clk0 but be delayed by 100 ps.

library IEEE, modelsim_lib;

use IEEE.std_logic_1164.all;
use modelsim_lib.util.all;
entity testbench is
end;

architecture only of testbench is

signal clk0 : std_logic;
begin
gen_clk0 : process
begin
clk0 <= '1' after 0 ps, '0' after 20 ps;
wait for 40 ps;
end process gen_clk0;

drive_sig_process : process
begin
init_signal_driver("clk0", "/testbench/uut/blk1/clk", open, open, 1);
init_signal_driver("clk0", "/testbench/uut/blk2/clk", 100 ps,
mti_transport);
wait;
end process drive_sig_process;
...
end;

Related Topics
init_signal_spy
signal_force
signal_release

ModelSim® SE User's Manual, v10.7 1269

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
init_signal_spy

init_signal_spy
This reference section describes the following:
• VHDL Procedure — init_signal_spy()
• Verilog Task — $init_signal_spy()
• SystemC Function — init_signal_spy()
The init_signal_spy() call mirrors the value of a VHDL signal, SystemVerilog or Verilog
register/net, or SystemC signal (called the src_object) onto an existing VHDL signal, Verilog
register, or SystemC signal (called the dest_object). This allows you to reference signals,
registers, or nets at any level of hierarchy from within a VHDL architecture or Verilog or
SystemC module (for example, a test bench).
Syntax
VHDL Syntax
init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)
Verilog Syntax
$init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)
SystemC Syntax
init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)
Arguments
• src_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to a VHDL signal or SystemVerilog or Verilog register/net. Use the path
separator to which your simulation is set (for example, “/” or “.”). A full hierarchical path
must begin with a “/” or “.”. The path must be contained within double quotes.
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to an existing VHDL signal or Verilog register. Use the path separator to
which your simulation is set (for example, “/” or “.”). A full hierarchical path must begin
with a “/” or “.”. The path must be contained within double quotes.
• verbose
Optional integer. Possible values are 0 or 1. Specifies whether you want a message reported
in the Transcript stating that the src_object value is mirrored onto the dest_object.
0 — Does not report a message. Default.
1 — Reports a message.

1270 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
init_signal_spy

• control_state
Optional integer. Possible values are -1, 0, or 1. Specifies whether or not you want the
ability to enable/disable mirroring of values and, if so, specifies the initial state.
-1 — no ability to enable/disable and mirroring is enabled. (default)
0 — turns on the ability to enable/disable and initially disables mirroring.
1— turns on the ability to enable/disable and initially enables mirroring.
Return Values
Nothing

Description
The init_signal_spy call only sets the value onto the destination signal and does not drive or
force the value. Any existing or subsequent drive or force of the destination signal, by some
other means, will override the value that was set by init_signal_spy.

By default this command uses a forward slash (/) as a path separator. You can change this
behavior with the SignalSpyPathSeparator variable in the modelsim.ini file.

Call only once

The init_signal_spy call creates a persistent relationship between the source and destination
signals. Hence, you need to call init_signal_spy once for a particular pair of signals. Once
init_signal_spy is called, any change on the source signal will mirror on the destination signal
until the end of the simulation unless the control_state is set.

However, you can place simultaneous read/write calls on the same signal using multiple
init_signal_spy calls, for example:

init_signal_spy ("/sc_top/sc_sig", "/top/hdl_INST/hdl_sig");

init_signal_spy ("/top/hdl_INST/hdl_sig", "/sc_top/sc_sig");

The control_state determines whether the mirroring of values can be enabled/disabled and what
the initial state is. Subsequent control of whether the mirroring of values is enabled/disabled is
handled by the enable_signal_spy and disable_signal_spy calls.

For VHDL procedures, you should place all init_signal_spy calls in a VHDL process and code
this VHDL process correctly so that it is executed only once. The VHDL process should not be
sensitive to any signals and should contain only init_signal_spy calls and a simple wait
statement. The process will execute once and then wait forever, which is the desired behavior.
See the example below.

For Verilog tasks, you should place all $init_signal_spy tasks in a Verilog initial block. See the
example below.

ModelSim® SE User's Manual, v10.7 1271

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
init_signal_spy

Limitations
• When mirroring the value of a SystemVerilog or Verilog register/net onto a VHDL
signal, the VHDL signal must be of type bit, bit_vector, std_logic, or std_logic_vector.
• Verilog memories (arrays of registers) are not supported.
Examples
In this example, the value of /top/uut/inst1/sig1 is mirrored onto /top/top_sig1. A message is
issued to the transcript. The ability to control the mirroring of values is turned on and the
init_signal_spy is initially enabled.

The mirroring of values will be disabled when enable_sig transitions to a ‘0’ and enable when
enable_sig transitions to a ‘1’.

library ieee;
library modelsim_lib;
use ieee.std_logic_1164.all;
use modelsim_lib.util.all;
entity top is
end;

architecture only of top is

signal top_sig1 : std_logic;

begin
...

spy_process : process
begin
init_signal_spy("/top/uut/inst1/sig1","/top/top_sig1",1,1);
wait;
end process spy_process;
...

spy_enable_disable : process(enable_sig)
begin
if (enable_sig = '1') then
enable_signal_spy("/top/uut/inst1/sig1","/top/top_sig1",0);
elseif (enable_sig = '0')

disable_signal_spy("/top/uut/inst1/sig1","/top/top_sig1",0);
end if;
end process spy_enable_disable;
...
end;

In this example, the value of .top.uut.inst1.sig1 is mirrored onto .top.top_sig1. A message is

issued to the transcript. The ability to control the mirroring of values is turned on and the
init_signal_spy is initially enabled.

1272 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
init_signal_spy

The mirroring of values will be disabled when enable_reg transitions to a ‘0’ and enabled when
enable_reg transitions to a ‘1’.

module top;
...
reg top_sig1;
reg enable_reg;
...
initial
begin
$init_signal_spy(".top.uut.inst1.sig1",".top.top_sig1",1,1);
end
always @ (posedge enable_reg)
begin
$enable_signal_spy(".top.uut.inst1.sig1",".top.top_sig1",0);
end
always @ (negedge enable_reg)
begin
$disable_signal_spy(".top.uut.inst1.sig1",".top.top_sig1",0);
end
...
endmodule

Related Topics
init_signal_driver
signal_force
signal_release
enable_signal_spy
disable_signal_spy

ModelSim® SE User's Manual, v10.7 1273

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
signal_force

signal_force
This reference section describes the following:
• VHDL Procedure — signal_force()
• Verilog Task — $signal_force()
• SystemC Function — signal_force()
The signal_force() call forces the value specified onto an existing VHDL signal, Verilog
register/register bit/net, or SystemC signal (called the dest_object). This allows you to force
signals, registers, bits of registers, or nets at any level of the design hierarchy from within a
VHDL architecture or Verilog or SystemC module (for example, a test bench).
Syntax
VHDL Syntax
signal_force(<dest_object>, <value>, <rel_time>, <force_type>, <cancel_period>, <verbose>)
Verilog Syntax
$signal_force(<dest_object>, <value>, <rel_time>, <force_type>, <cancel_period>,
<verbose>)
SystemC Syntax
signal_force(<dest_object>, <value>, <rel_time>, <force_type>, <cancel_period>, <verbose>)
Arguments
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to an existing VHDL signal, SystemVerilog or Verilog register/bit of a
register/net or SystemC signal. Use the path separator to which your simulation is set (for
example, “/” or “.”). A full hierarchical path must begin with a “/” or “.”. The path must be
contained within double quotes.
• value
Required string. Specifies the value to which the dest_object is to be forced. The specified
value must be appropriate for the type.
Where value can be:
o a sequence of character literals or as a based number with a radix of 2, 8, 10 or 16.
For example, the following values are equivalent for a signal of type bit_vector (0 to
3):
• 1111 — character literal sequence
• 2#1111 —binary radix
• 10#15— decimal radix

1274 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
signal_force

• 16#F — hexadecimal radix

o a reference to a Verilog object by name. This is a direct reference or hierarchical
reference, and is not enclosed in quotation marks. The syntax for this named object
should follow standard Verilog syntax rules.
• rel_time
Optional time. Specifies a time relative to the current simulation time for the force to occur.
The default is 0.
• force_type
Optional forcetype or integer. Specifies the type of force that will be applied.
For the VHDL procedure, the value must be one of the following;
default — which is “freeze” for unresolved objects or “drive” for resolved objects
deposit
drive
freeze
For the Verilog task, the value must be one of the following;
0 — default, which is “freeze” for unresolved objects or “drive” for resolved objects
1 — deposit
2 — drive
3 — freeze
For the SystemC function, the value must be one of the following;
0 — default, which is “freeze” for unresolved objects or “drive” for resolved objects
1 — deposit
2 — drive
3 — freeze
See the force command for further details on force type.
• cancel_period
Optional time or integer. Cancels the signal_force command after the specified period of
time units. Cancellation occurs at the last simulation delta cycle of a time unit.
For the VHDL procedure, a value of zero cancels the force at the end of the current time
period. Default is -1 ms. A negative value means that the force will not be canceled.
For the Verilog task, A value of zero cancels the force at the end of the current time period.
Default is -1. A negative value means that the force will not be canceled.
For the SystemC function, A value of zero cancels the force at the end of the current time
period. Default is -1. A negative value means that the force will not be canceled.

ModelSim® SE User's Manual, v10.7 1275

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
signal_force

• verbose
Optional integer. Possible values are 0 or 1. Specifies whether you want a message reported
in the Transcript stating that the value is being forced on the dest_object at the specified
time.
0 — Does not report a message. Default.
1 — Reports a message.
Return Values
Nothing

Description
A signal_force works the same as the force command with the exceptions that you cannot issue
a repeating force. The force will remain on the signal until a signal_release, a force or noforce
command, or a subsequent signal_force is issued. Signal_force can be called concurrently or
sequentially in a process.

This command displays any signals using your radix setting (either the default, or as you
specify) unless you specify the radix in the value you set.

By default this command uses a forward slash (/) as a path separator. You can change this
behavior with the SignalSpyPathSeparator variable in the modelsim.ini file.

Limitations
• Verilog memories (arrays of registers) are not supported.
Examples
This example forces reset to a “1” from time 0 ns to 40 ns. At 40 ns, reset is forced to a “0”,
200000 ns after the second $signal_force call was executed.

`timescale 1 ns / 1 ns

module testbench;

initial
begin
$signal_force("/testbench/uut/blk1/reset", "1", 0, 3, , 1);
$signal_force("/testbench/uut/blk1/reset", "0", 40, 3, 200000, 1);
end

...

endmodule

This example forces reset to a “1” from time 0 ns to 40 ns. At 40 ns, reset is forced to a “0”, 2
ms after the second signal_force call was executed.

1276 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
signal_force

If you want to skip parameters so that you can specify subsequent parameters, you need to use
the keyword “open” as a placeholder for the skipped parameter(s). The first signal_force
procedure illustrates this, where an “open” for the cancel_period parameter means that the
default value of -1 ms is used.

library IEEE, modelsim_lib;

use IEEE.std_logic_1164.all;
use modelsim_lib.util.all;

entity testbench is
end;

architecture only of testbench is

begin

force_process : process
begin
signal_force("/testbench/uut/blk1/reset", "1", 0 ns, freeze, open, 1);
signal_force("/testbench/uut/blk1/reset", "0", 40 ns, freeze, 2 ms,
1);
wait;
end process force_process;

...

end;

Related Topics
init_signal_driver
init_signal_spy
signal_release

ModelSim® SE User's Manual, v10.7 1277

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
signal_release

signal_release
This reference section describes the following:
• VHDL Procedure — signal_release()
• Verilog Task — $signal_release()
• SystemC Function — signal_release()
A signal_release works the same as the noforce command. Signal_release can be called
concurrently or sequentially in a process.
By default this command uses a forward slash (/) as a path separator. You can change this
behavior with the SignalSpyPathSeparator variable in the modelsim.ini file.
The signal_release() call releases any force that was applied to an existing VHDL signal,
SystemVerilog or Verilog register/register bit/net, or SystemC signal (called the dest_object).
This allows you to release signals, registers, bits of registers, or nets at any level of the design
hierarchy from within a VHDL architecture or Verilog or SystemC module (for example, a test
bench).
Syntax
VHDL Syntax
signal_release(<dest_object>, <verbose>)
Verilog Syntax
$signal_release(<dest_object>, <verbose>)
SystemC Syntax
signal_release(<dest_object>, <verbose>)
Arguments
• dest_object
Required string. A full hierarchical path (or relative downward path with reference to the
calling block) to an existing VHDL signal, SystemVerilog or Verilog register/net, or
SystemC signal. Use the path separator to which your simulation is set (for example, “/” or
“.”). A full hierarchical path must begin with a “/” or “.”. The path must be contained within
double quotes.
• verbose
Optional integer. Possible values are 0 or 1. Specifies whether you want a message reported
in the Transcript stating that the signal is being released and the time of the release.
0 — Does not report a message. Default.
1 — Reports a message.
Return Values
Nothing

1278 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
signal_release

Examples
This example releases any forces on the signals data and clk when the signal release_flag is a
“1”. Both calls will send a message to the transcript stating which signal was released and when.

library IEEE, modelsim_lib;

use IEEE.std_logic_1164.all;
use modelsim_lib.util.all;

entity testbench is
end;

architecture only of testbench is

signal release_flag : std_logic;

begin

stim_design : process
begin
...
wait until release_flag = '1';
signal_release("/testbench/dut/blk1/data", 1);
signal_release("/testbench/dut/blk1/clk", 1);
...
end process stim_design;

...

end;

This example releases any forces on the signals data and clk when the register release_flag
transitions to a “1”. Both calls will send a message to the transcript stating which signal was
released and when.

module testbench;

reg release_flag;

always @(posedge release_flag) begin

$signal_release("/testbench/dut/blk1/data", 1);
$signal_release("/testbench/dut/blk1/clk", 1);
end

...
endmodule

Related Topics
init_signal_driver
init_signal_spy
signal_force

ModelSim® SE User's Manual, v10.7 1279

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
signal_release

1280 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 28
Monitoring Simulations with JobSpy

This chapter describes JobSpy™®, a tool for monitoring and controlling batch simulations and
simulation farms.
Designers frequently run multiple simulation jobs in batch mode once verification reaches the
regression testing stage. They face the problem that simulation farms and batch-mode runs offer
little visibility into and control over simulation jobs. JobSpy helps alleviate this problem by
allowing you to interact with batch jobs. By creating a process external to the running simulator,
JobSpy can send and receive information about the running jobs.

Some applications of JobSpy include the following:

• Checking the progress of a simulation.

• Examining internal signal values to check if the design is functioning correctly, without
stopping the simulation.
• Suspending one job to release a license for a more important job, also allowing you to
restart the suspended job later.
• Instructing the running batch job to do a checkpoint of the job and then continue the run.
If the workstation that was running a batch job were to fail at sometime in the future,
you would could restart the job again from the saved checkpoint file.
You can run JobSpy from the command line, from within the ModelSim GUI, or from a
standalone GUI. The actual commands that are sent and received across the communication
pipe are the same for all modes of operation. The standalone GUI simply provides a dialog box
where you can see all the running jobs.

Basic JobSpy Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282

Running JobSpy from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Running the JobSpy GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Viewing Results During Active Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Licensing and Job Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Checkpointing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Connecting to Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291

ModelSim® SE User's Manual, v10.7 1281

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Basic JobSpy Flow

Basic JobSpy Flow

There are four basic steps in setting up and using JobSpy.
1. Set the JOBSPY_DAEMON environment variable.
2. Start the JobSpy Daemon.
3. Start simulation jobs as you normally would. The tool will communicate with the
JobSpy daemon through the use of the JOBSPY_DAEMON environment variable.
4. Use jobspy command or Job Manager GUI to monitor results.
Set JOBSPY_DAEMON Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Start the JobSpy Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Set the JOBSPY_DAEMON Variable as a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283

Set JOBSPY_DAEMON Environment Variable

The first step to setup JobSpy is to set the JOBSPY_DAEMON environment variable.
Procedure
You can set JOBSPY_DAEMON environment variable in the following ways.

• port@host— Refer to the section ““Start the JobSpy Daemon” on page 1282”
• directory — Refer to the section ““Set the JOBSPY_DAEMON Variable as a
Directory” on page 1283”

Start the JobSpy Daemon

You must start the JobSpy daemon prior to launching any simulation jobs. The daemon tracks
jobs by setting up a communication pipe with each running simulation.
You can start the JobSpy daemon in the following ways.;

• Command line: jobspy -startd

You do not need to specify -startd if you set the JOBSPY_DAEMON to a directory.
• GUI: Tools > JobSpy > Daemon > Start Daemon
When a simulation job starts, the daemon opens a TCP/IP port for the job and then records to a
file:

• port number
• host name that the job was started on

1282 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Set the JOBSPY_DAEMON Variable as a Directory

• working directory
With a connection to the job established, you can invoke various commands via the command
line or GUI to monitor or control the job. There are two steps to starting the daemon:

Procedure
1. Set the JOBSPY_DAEMON environment variable.
The environment variable is set with the following syntax:
JOBSPY_DAEMON=<port_NUMBER>@<host>

For example,
JOBSPY_DAEMON=1301@mymachine

Every user who runs JobSpy must set this environment variable, typically in a start-up
script such as the .cshrc file. This gives every new shell access to the daemon.
2. Invoke the daemon using the jobspy -startd command or by selecting
Tools > JobSpy > Daemon > Start Daemon from within ModelSim.
You do not need to specify -startd if you set the JOBSPY_DAEMON to a directory.
3. If you correctly set port@host in the JOBSPY_DAEMON variable, you can control jobs
submitted to that host. The intended use is that you set your JOBSPY_DAEMON
variable, start the daemon, and then control only your jobs (unless you tell others what
port@host to use). Each user can use his/her own port id to monitor only their jobs.

Set the JOBSPY_DAEMON Variable as a Directory

As an alternative to using a TCP/IP port, you can instruct the JobSpy Daemon to communicate
with simulation jobs via a directory and file structure. Although a directory location is not
technically a Daemon, for ease of use we will be referring to it as one in this document.
To specify a directory as your JobSpy Daemon, use the JOBSPY_DAEMON environment
variable similar to the following:

JOBSPY_DAEMON=/server/directory/subdirectory

This instructs any simulation job invoked with the same $JOBSPY_DAEMON to create files
containing communication and run information in the specified directory, which enables
communication between JobSpy and the simulation jobs.

The jobspy command behaves similarly regardless of your using a TCP/IP port or a directory
name for your JobSpy Daemon.

ModelSim® SE User's Manual, v10.7 1283

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Running JobSpy from the Command Line

Running JobSpy from the Command Line

The JobSpy command-line interface is accessible from a shell prompt or within the ModelSim
GUI.
The proper syntax is:

jobspy [-gui] [-killd] [-startd] | jobs | status | <jobid> <command>

See the jobspy command for complete syntax. The most common invocations are:

• jobspy -startd — invokes the daemon

You do not need to specify -startd if you set the JOBSPY_DAEMON to a directory.
• jobspy jobs — lists all jobs and their id numbers; you need the ids in order to execute
commands on the jobs
• <jobid> <command> — allows you to issue commands to a job; only certain
commands can be used, as noted below
Simulation Commands Available to JobSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284

Simulation Commands Available to JobSpy

You can perform a select number of simulator commands on jobs via JobSpy.
The table below lists the available commands with a brief description.
Table 28-1. Simulation Commands You can Issue from JobSpy
Command Description
stop stops a simulation
go resumes a stopped job
checkpoint or check checkpoints a simulation
savewlf saves simulation results to a WLF file; see Viewing Results
During Active Simulation; by default this command uses the
pathname from the remote machine
examine prints the value of a signal in the remote job
force forces signal values in the remote job
log logs signals in the waveform log file (.wlf)
nolog removes logged signals from the waveform log file (.wlf)
now prints job's current simulation time
profile on enable profiling of remote job
profile off disable profiling of remote job

1284 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Simulation Commands Available to JobSpy

Table 28-1. Simulation Commands You can Issue from JobSpy (cont.)
Command Description
profile save [<filename>] save a profile of remote job. Default <filename> is
job<jobid>.prof
pwd prints the job's current working directory
quit exits a simulation (terminates job)
savecov [<filename>] writes out a coverage data UCDB file, equivalent to the
coverage save command. Default <filename> is
Job_<gridtype>_<jobid>.ucdb where <gridtype> is mti,
sge, lsf or vov.
set sets a TCL variable in the remote job's interpreter
simstatus shows current status of the simulation
suspend suspends job (releases license)
unsuspend un-suspends job (reacquires license)

Example Session
The following example illustrates a session of JobSpy:

$ JOBSPY_DAEMON=1300@time //sets the daemon to a port@host

$ export JOBSPY_DAEMON //exports the environment variable
$ jobspy -startd //start the daemon
$ jobspy jobs // print list of jobs
JobID Type Sim Status Sim Time user Host PID Start Time Directory
5 mti Running 1,200ns alla time 24710 Mon Dec 27. /u/alla/z
11 mti Running 3,433ns mcar larg 24915 Tue Dec 28. /u/mcar/x

$ jobspy 11 checkpoint //checkpoint job 11

Checkpointing Job

$ jobspy 11 cont //resume job 11

continuing

$ jobspy 5 savewlf snap.wlf // saving waveforms from job 5

Dataset "sim" exported as WLF file: snap.wlf. @ 1,200ns

$ vsim -view snap.wlf //viewing waveforms from job 5

ModelSim® SE User's Manual, v10.7 1285

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Running the JobSpy GUI

Running the JobSpy GUI

JobSpy includes a GUI called Job Manager that you can invoke from within ModelSim or
separately as a stand-alone tool. The Job Manager shows all active simulations in real time and
provides convenient access to JobSpy commands.
Starting Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Invoking Simulation Commands in Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Interactive Job Session Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287
View Commands and Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288

Starting Job Manager

You can start Job Manager with a command from a shell prompt or with ModelSim GUI menu
selections.
Procedure
Do either of the following:

Shell Prompt — jobspy -gui

GUI— Tools > JobSpy > JobSpy Job Manager

Invoking Simulation Commands in Job Manager

You can invoke simulation commands in Job Manager via a right-click menu or from the
prompt in the Interactive Job Session window.
Procedure
Right-click a job in the list displayed int the JobSpy Job Manager window (Figure 28-2) to
access menu commands.

1286 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Interactive Job Session Pane

Figure 28-1. JobSpy Job Manager

Interactive Job Session Pane

The Interactive Job Session pane provides a command line for interacting with jobs. Commands
you enter affect the job currently selected in the Running Jobs portion of the dialog box.
See Table 28-1 for a list of commands you can enter in the Interactive Job Session pane.

Note
If you check Advanced Mode, you can enter any ModelSim command at the prompt.
However, you need to be careful as many ModelSim commands will not function properly
with JobSpy.

ModelSim® SE User's Manual, v10.7 1287

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
View Commands and Pathnames

View Commands and Pathnames

The View Transcript and View Waveform commands display files (transcript and
<name>.wlf, respectively) that are output by the simulator.
These commands use the pathname from the remote machine to locate the required file.
Depending on how your network is organized, the pathname may be different or inaccessible
from the machine which is running JobSpy. In such cases, these commands will not work. The
work around is to use jobspy savewlf to specify a known location for the WLF file or cp to
copy the Transcript file to a known location.

1288 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Viewing Results During Active Simulation

Viewing Results During Active Simulation

You may want to check simulation results while your simulation jobs are still running. You can
do this via the GUI or by using the savewlf command.
To view waveforms from the JobSpy GUI, right-click a job and select View Waveform.

Figure 28-2. Job Manager View Waveform

Here are two important points to remember about viewing waveforms from the GUI:

• You must first log signals before you can view them as waveforms. If you have not
logged any signals, the View Waveform command in the GUI will be disabled.
• View Waveform uses the pathname from the remote machine to access a WLF file. The
command may not work on some networks. See View Commands and Pathnames for
details.
Viewing Waveforms from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289

Viewing Waveforms from the Command Line

From the command line, there are three steps to viewing waveforms.
Procedure
1. Log the appropriate signals
add log *

ModelSim® SE User's Manual, v10.7 1289

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Licensing and Job Suspension

2. Save a dataset
$ jobspy 1204 savewlf snap.wlf
Dataset "sim" exported as WLF file: snap.wlf. @ 84,785,547 ns

3. View the dataset

vsim -view snap.wlf

Licensing and Job Suspension

When you suspend a job via JobSpy, the simulation license is released by default. You can
change this behavior by modifying the MTI_RELEASE_ON_SUSPEND environment variable.
By default the variable is set to 10 (in seconds), which releases the license 10 seconds after
receiving a suspend signal. If you change the value to 0 (off), simulation licenses will not be
released upon job suspension.

Checkpointing Jobs
Checkpointing allows you to save the state of a simulation and restore it at a later time.
There are three primary reasons for checkpointing jobs:

• Free up a license for a more important job

• Migrate a job from one machine to another
• Backup a job in case of a hardware crash or failure
In the case of freeing up a license, you should use the suspend command instead. Job suspension
does not have the restrictions that checkpointing does.

If you need to checkpoint a job for migration or backup, keep in mind the following restrictions:

• The job must be restored on the same platform and exact OS on which the job was
checkpointed.
• If your job includes any foreign C code (such as PLI or FLI), the foreign application
must be written to support checkpointing. See The PLI Callback reason Argument for
more information on checkpointing with PLI applications. See the Foreign Language
Interface Reference Manual for information on checkpointing with FLI applications.
• Checkpoint is not supported once a SystemC design has been loaded.

1290 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Connecting to Load-Sharing Software

Connecting to Load-Sharing Software

Load-sharing software, such as Platform Computing’s LSF or Sun’s Grid Engine, centralize
management of distributed computing resources. JobSpy can access and monitor simulation
runs that were submitted to these load-managing products.
With the exception of checkpointing (discussed below), the only requirement for connecting to
load-sharing software is that the JobSpy daemon be running prior to submitting the jobs. If the
daemon is running, the jobs will show up in JobSpy automatically.

JobSpy supports Sun Grid Engine’s task arrays, where the simulation jobs use the JOB_ID and
the SGE_TASK_ID environment variables. The jobspy command can reference these jobs as
“<taskId>.<jobId>”.

Checkpointing with Load-Sharing Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292

ModelSim® SE User's Manual, v10.7 1291

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Checkpointing with Load-Sharing Software

Checkpointing with Load-Sharing Software

Some additional steps are required to configure load-sharing software for checkpointing vsim
jobs. The configuration depends on which load-sharing software you run.
Configuring LSF for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Configuring Flowtracer for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Configuring Grid Engine for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292

Configuring LSF for Checkpointing

Configuring LSF for Checkpointing requires that you set two environment variables.
Procedure
1. Set the environment variable LSB_ECHKPNT_METHOD_DIR to point to
<install_dir>/modeltech/<platform>
<platform> refers to the VCO for the ModelSim installation (for example, linux, sunos5,
and so forth). See the Installation Guide for a complete list.
2. Set the environment variable LSB_ECHKPNT_METHOD to “modelsim”
3. With these environment variables set, you can use standard LSF commands to
checkpoint vsim jobs. Consult LSF documentation for information on those commands.

Configuring Flowtracer for Checkpointing

Flowtracer does not support checkpointing of vsim jobs.

Configuring Grid Engine for Checkpointing

To checkpoint vsim jobs with Grid Engine, you must create a Checkpoint Object and make the
settings in the following procedure.
Procedure
1. Set Interface to:
APPLICAITON-LEVEL.

2. Set the Checkpoint Command field to:

<install_dir>/modeltech/<platform>/jobspy -check

where <platform> refers to the VCO for the ModelSim installation (for example, linux,
sunos5, and so forth). See the Installation Guide for a complete list.

1292 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Monitoring Simulations with JobSpy
Checkpointing with Load-Sharing Software

3. Set the Migration Command field to:

<install_dir>/modeltech/<platform>/jobspy -check k

4. Consult the Grid Engine documentation for additional information.

ModelSim® SE User's Manual, v10.7 1293

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Monitoring Simulations with JobSpy
Checkpointing with Load-Sharing Software

1294 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 29
Generating Stimulus with Waveform Editor

The ModelSim Waveform Editor offers a simple method for creating design stimulus. You can
generate and edit waveforms in a graphical manner and then drive the simulation with those
waveforms.
Common tasks you can perform with the Waveform Editor:

• Create waveforms using four predefined patterns: clock, random, repeater, and counter.
Refer to Accessing the Create Pattern Wizard.
• Edit waveforms with numerous functions including inserting, deleting, and stretching
edges; mirroring, inverting, and copying waveform sections; and changing waveform
values on-the-fly. Refer to Editing Waveforms.
• Drive the simulation directly from the created waveforms
• Save created waveforms to four stimulus file formats: Tcl force format, extended VCD
format, Verilog module, or VHDL architecture. The HDL formats include code that
matches the created waveforms and can be used in test benches to drive a simulation.
Refer to Exporting Waveforms to a Stimulus File
The current version does not support the following:

• Enumerated signals, records, multi-dimensional arrays, and memories

• User-defined types
• SystemC or SystemVerilog
Getting Started with the Waveform Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Using Waveform Editor Prior to Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298
Accessing the Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Creating Waveforms with Wave Create Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Editing Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Stretching and Moving Edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Simulating Directly from Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Exporting Waveforms to a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Driving Simulation with the Saved Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306

ModelSim® SE User's Manual, v10.7 1295

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor

Signal Mapping and Importing EVCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306

Using Waveform Compare with Created Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
Saving the Waveform Editor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307

1296 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Getting Started with the Waveform Editor

Getting Started with the Waveform Editor

You can use Waveform Editor before or after loading a design. Regardless of which method
you choose, you will select design objects and use them as the basis for created waveforms.
Using Waveform Editor Prior to Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298

Using Waveform Editor Prior to Loading a Design

Here are the basic steps for using waveform editor prior to loading a design.
Procedure
1. Right-click a design unit on the Library Window and select Create Wave.
Figure 29-1. Waveform Editor: Library Window

2. Edit the waveforms in the Wave window. See Editing Waveforms for more details.
3. Run the simulation (see Simulating Directly from Waveform Editor) or save the created
waveforms to a stimulus file (see Exporting Waveforms to a Stimulus File).
Results
After the first step, a Wave window opens and displays signal names with the orange Waveform
Editor icon (Figure 29-2).

ModelSim® SE User's Manual, v10.7 1297

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Using Waveform Editor After Loading a Design

Figure 29-2. Results of Create Wave Operation

Using Waveform Editor After Loading a Design

Here are the basic steps for using waveform editor after loading a design.
Procedure
1. Right-click an object in the Objects window and select Modify > Apply Wave.
Figure 29-3. Opening Waveform Editor from Objects Windows

2. Use the Create Pattern wizard to create the waveforms (see Accessing the Create Pattern
Wizard).
3. Edit the waveforms as required (see Editing Waveforms).

1298 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Accessing the Create Pattern Wizard

4. Run the simulation (see Simulating Directly from Waveform Editor) or save the created
waveforms to a stimulus file (see Exporting Waveforms to a Stimulus File).

Accessing the Create Pattern Wizard

Waveform Editor includes a Create Pattern wizard that walks you through the process of
creating waveforms.
Procedure
1. Right-click an object in the Objects pane to open a popup menu.
2. Select Modify > Apply Wave from the popup menu.
Results
The Create Pattern Wizard opens to the initial dialog box shown in Figure 29-4. Note that the
Drive Type field is not present for input and output signals.
Figure 29-4. Create Pattern Wizard

In this dialog you specify the signal that the waveform will be based upon, the Drive Type (if
applicable), the start and end time for the waveform, and the pattern for the waveform.
The second dialog in the wizard lets you specify the appropriate attributes based on the pattern
you select. The table below shows the five available patterns and their attributes:
Table 29-1. Signal Attributes in Create Pattern Wizard
Pattern Description
Clock Specify an initial value, duty cycle, and clock period for
the waveform.
Constant Specify a value.

ModelSim® SE User's Manual, v10.7 1299

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Creating Waveforms with Wave Create Command

Table 29-1. Signal Attributes in Create Pattern Wizard (cont.)

Pattern Description
Random Generates different patterns depending upon the seed
value. Specify the type (normal or uniform), an initial
value, and a seed value. If you do not specify a seed value,
ModelSim uses a default value of 5.
Repeater Specify an initial value and pattern that repeats. You can
also specify how many times the pattern repeats.
Counter Specify start and end values, time period, type (Range,
Binary, Gray, One Hot, Zero Hot, Johnson), counter
direction, step count, and repeat number.

Creating Waveforms with Wave Create

Command
The wave create command gives you the ability to generate clock, constant, random, repeater,
and counter waveform patterns from the command line. You can then modify the waveform
interactively in the GUI and use the results to drive simulation. See the wave create command in
the Command Reference for correct syntax, argument descriptions, and examples.
Related Topics
wave create [ModelSim SE Command Reference Manual]

Editing Waveforms
You can edit waveforms interactively with menu commands, mouse actions, or by using the
wave edit command.
Procedure
1. Create an editable pattern as described under Accessing the Create Pattern Wizard.
2. Enter editing mode by right-clicking a blank area of the toolbar and selecting
Wave_edit from the toolbar popup menu.
This will open the Wave Edit toolbar.
Figure 29-5. Wave Edit Toolbar

3. Select an edge or a section of the waveform with your mouse. See Selecting Parts of the
Waveform for more details.

1300 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Editing Waveforms

4. Select a command from the Wave > Wave Editor menu when the Wave window is
docked, from the Edit > Wave menu when the Wave window is undocked, or right-
click the waveform and select a command from the Wave context menu.
5. The table below summarizes the editing commands that are available.

Table 29-2. Waveform Editing Commands

Operation Description
Cut Cut the selected portion of the waveform to the clipboard
Copy Copy the selected portion of the waveform to the
clipboard
Paste Paste the contents of the clipboard over the selected
section or at the active cursor location
Insert Pulse Insert a pulse at the location of the active cursor
Delete Edge Delete the edge at the active cursor
Invert Invert the selected waveform section
Mirror Mirror the selected waveform section
Value Change the value of the selected portion of the waveform
Stretch Edge Move an edge forward/backward by “stretching” the
waveform; see Stretching and Moving Edges for more
information
Move Edge Move an edge forward/backward without changing other
edges; see Stretching and Moving Edges for more
information
Extend All Extend all created waveforms by the specified amount or
Waves to the specified simulation time; ModelSim cannot undo
this edit or any edits done prior to an extend command
Change Drive Change the drive type of the selected portion of the
Type waveform
Undo Undo waveform edits (except changing drive type and
extending all waves)
Redo Redo previously undone waveform edits

6. These commands can also be accessed via toolbar buttons.

Related Topics
wave edit command and the Wave Edit Toolbar. [ModelSim SE GUI Reference Manual]

ModelSim® SE User's Manual, v10.7 1301

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Selecting Parts of the Waveform

Selecting Parts of the Waveform

There are several methods for selecting edges or sections of a waveform. The table and graphic
below describe the various options.

Table 29-3. Selecting Parts of the Waveform

Action Method
Select a waveform edge Click the waveform edge, or just to the
right of the edge
Select a section of the waveform Click-and-drag the mouse pointer in the
waveform pane
Select a section of multiple Click-and-drag the mouse pointer while
waveforms holding the <Shift> key
Extend/contract the selection size Drag a cursor in the cursor pane
Extend/contract selection from Click Next Transition/Previous Transition
edge-to-edge icons after selecting section

1302 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Selection and Zoom Percentage

Figure 29-6. Manipulating Waveforms with the Wave Edit Toolbar and Cursors

Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303

Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Stretching and Moving Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304

Selection and Zoom Percentage

You may find that you cannot select the exact range you want because the mouse moves more
than one unit of simulation time (for example, 228 ns to 230 ns). If this happens, zoom in on the
Wave display and you should be able to select the range you want.
Related Topics
Zooming the Wave Window Display

ModelSim® SE User's Manual, v10.7 1303

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Auto Snapping of the Cursor

Auto Snapping of the Cursor

When you click just to the right of a waveform edge in the waveform pane, the cursor
automatically snaps to the nearest edge. This behavior is controlled by the Snap Distance setting
in the Wave window preferences dialog.

Stretching and Moving Edges

There are mouse and keyboard shortcuts for moving and stretching edges.

Table 29-4. Wave Editor Mouse/Keyboard Shortcuts

Action Mouse/keyboard shortcut
Stretch an edge Hold the <Ctrl> key and drag the edge
Move an edge Hold the <Ctrl> key and drag the edge
with the 2nd (middle) mouse button

Here are some points to keep in mind about stretching and moving edges:

• If you stretch an edge forward, more waveform is inserted at the beginning of simulation
time.
• If you stretch an edge backward, waveform is deleted at the beginning of simulation
time.
• If you move an edge past another edge, either forward or backward, the edge you moved
past is deleted.

Simulating Directly from Waveform Editor

You need not save the waveforms in order to use them as stimulus for a simulation.
Once you have configured all the waveforms, you can run the simulation as normal by selecting
Simulate > Start Simulation in the Main window or using the vsim command. ModelSim
automatically uses the created waveforms as stimulus for the simulation. Furthermore, while
running the simulation you can continue editing the waveforms to modify the stimulus for the
part of the simulation yet to be completed.

Related Topics
vsim [ModelSim SE Command Reference Manual]

1304 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Exporting Waveforms to a Stimulus File

Exporting Waveforms to a Stimulus File

Once you have created and edited the waveforms, you can save the data to a stimulus file that
can be used to drive a simulation now or at a later time.
Procedure
To save the waveform data, select File > Export > Waveform or use the wave export
command.

Figure 29-7. Export Waveform Dialog

You can save the waveforms in four different formats:

Table 29-5. Formats for Saving Waveforms

Format Description
Force format Creates a Tcl script that contains force commands
necessary to recreate the waveforms; source the file
when loading the simulation as described under
Driving Simulation with the Saved Stimulus File
EVCD format Creates an extended VCD file which can be reloaded
using the Import > EVCD File command, or can be
used with the -vcdstim argument to vsim to simulate
the design
VHDL Testbench Creates a VHDL architecture that you load as the top-
level design unit
Verilog Testbench Creates a Verilog module that you load as the top-level
design unit

Related Topics
wave export [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1305

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Driving Simulation with the Saved Stimulus File

Driving Simulation with the Saved Stimulus

File
The method for loading the stimulus file depends upon what type of format you saved.
In each of the following examples, assume that the top-level of your block is named “top” and
you saved the waveforms to a stimulus file named “mywaves” with the default extension.
Table 29-6. Examples for Loading a Stimulus File
Format Loading example
Force format vsim top -do mywaves.do
Extended VCD format1 vsim top -vcdstim mywaves.vcd
VHDL Testbench vcom mywaves.vhd
vsim mywaves
Verilog Testbench vlog mywaves.v
vsim mywaves
1. You can also use the Import > EVCD command from the Wave window. See below
for more details on working with EVCD files.

Signal Mapping and Importing EVCD Files

When you import a previously saved EVCD file, ModelSim attempts to map the signals in the
EVCD file to the signals in the loaded design by matching signals based on name and width.
If ModelSim can not map the signals automatically, you can do the mapping yourself by
selecting a signal, right-clicking the selected signal, then selecting Map to Design Signal from
the popup menu. This opens the Evcd Import dialog.

Figure 29-8. Evcd Import Dialog

Select a signal from the drop-down arrow and click OK.

Note
This command works only with extended VCD files created with ModelSim.

1306 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Generating Stimulus with Waveform Editor
Using Waveform Compare with Created Waveforms

Using Waveform Compare with Created

Waveforms
The Waveform Compare feature compares two or more waveforms and displays the differences
in the Wave window. This feature can be used in tandem with Waveform Editor. The
combination is most useful in situations where you know the expected output of a signal and
want to compare visually the differences between expected output and simulated output.
Procedure
1. Create a waveform based on the signal of interest with a drive type of expected output
2. Add the design signal of interest to the Wave window and then run the design
3. Start a comparison and use the created waveform as the reference dataset for the
comparison. Use the text “Edit” to designate a create waveform as the reference dataset.
For example:
compare start Edit sim
compare add -wave /test_counter/count
compare run

Related Topics
Waveform Compare

Saving the Waveform Editor Commands

When you create and edit waveforms in the Wave window, ModelSim tracks the underlying Tcl
commands and reports them to the transcript. You can save those commands to a DO file that
can be run at a later time to recreate the waveforms.
Procedure
Select File > Save.

ModelSim® SE User's Manual, v10.7 1307

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Generating Stimulus with Waveform Editor
Saving the Waveform Editor Commands

1308 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 30
Standard Delay Format (SDF) Timing
Annotation

This chapter covers the ModelSim implementation of SDF (Standard Delay Format) timing
annotation. Included are sections on VITAL SDF and Verilog SDF, plus troubleshooting.
Verilog and VHDL VITAL timing data can be annotated from SDF files by using the
simulator’s built-in SDF annotator.

ASIC and FPGA vendors usually provide tools that create SDF files for use with their cell
libraries. Refer to your vendor’s documentation for details on creating SDF files for your
library. Many vendors also provide instructions on using their SDF files and libraries with
ModelSim.

The SDF specification was originally created for Verilog designs, but it has also been adopted
for VHDL VITAL designs. In general, the designer does not need to be familiar with the details
of the SDF specification because the cell library provider has already supplied tools that create
SDF files that match their libraries.

Note
ModelSim can read SDF files that were compressed using gzip. Other compression formats
(for example, Unix zip) are not supported.

Specifying SDF Files for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310

Compiling SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312
VHDL VITAL SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Verilog SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316
SDF for Mixed VHDL and Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Interconnect Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328

ModelSim® SE User's Manual, v10.7 1309

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Specifying SDF Files for Simulation

Specifying SDF Files for Simulation

ModelSim supports SDF versions 1.0 through 4.0 (IEEE 1497), except the NETDELAY and
LABEL statements. The simulator’s built-in SDF annotator automatically adjusts to the version
of the file.
Use the following vsim command line options to specify the SDF files, the desired timing
values, and their associated design instances:

-sdfmin [<instance>=]<filename>
-sdftyp [<instance>=]<filename>
-sdfmax [<instance>=]<filename>

Any number of SDF files can be applied to any instance in the design by specifying one of the
above options for each file. Use -sdfmin to select minimum, -sdftyp to select typical, and
-sdfmax to select maximum timing values from the SDF file.

Instance Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310

SDF Specification with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
Errors and Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311

Instance Specification
The instance paths in the SDF file are relative to the instance to which the SDF is applied.
Usually, this instance is an ASIC or FPGA model instantiated under a test bench.
For example, to annotate maximum timing values from the SDF file myasic.sdf to an instance
u1 under a top-level named testbench, invoke the simulator as follows:

vsim -sdfmax /testbench/u1=myasic.sdf testbench

If the instance name is omitted then the SDF file is applied to the top-level. This is usually
incorrect because in most cases the model is instantiated under a test bench or within a larger
system level simulation. In fact, the design can have several models, each having its own SDF
file. In this case, specify an SDF file for each instance. For example,

vsim -sdfmax /system/u1=asic1.sdf -sdfmax /system/u2=asic2.sdf system

SDF Specification with the GUI

As an alternative to the command line options, you can specify SDF files in the Start Simulation
dialog box under the SDF tab.

1310 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
Errors and Warnings

Figure 30-1. SDF Tab in Start Simulation Dialog

You can access this dialog by invoking the simulator without any arguments or by selecting
Simulate > Start Simulation.

For Verilog designs, you can also specify SDF files by using the $sdf_annotate system task. See
$sdf_annotate for more details.

Errors and Warnings

Errors issued by the SDF annotator while loading the design prevent the simulation from
continuing, whereas warnings do not.
• Use either the -sdfnoerror or the +nosdferror option with vsim to change SDF errors to
warnings so that the simulation can continue.
• Use either the -sdfnowarn or the +nosdfwarn option with vsim to suppress warning
messages.
Another option is to use the SDF tab from the Start Simulation dialog box (Figure 30-1).
Select Disable SDF warnings (-sdfnowarn +nosdfwarn) to disable warnings, or select Reduce
SDF errors to warnings (-sdfnoerror) to change errors to warnings.

See Troubleshooting for more information on errors and warnings and how to avoid them.

ModelSim® SE User's Manual, v10.7 1311

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Compiling SDF Files

Compiling SDF Files

The sdfcom command compiles SDF files. Compiled SDF can be annotated to Verilog and
VHDL regions, including those regions hierarchically underneath SystemC modules. However,
compiled SDF cannot be targeted to a SystemC node directly (even if the intended annotation
objects underneath the SystemC node are Verilog and/or VHDL).
In situations where the same SDF file is used for multiple simulation runs, the elaboration time
will be reduced significantly.

Note
When compiled SDF files are used, the annotator behaves as if the -v2k_int_delays switch
for the vsim command has been specified.

Simulating with Compiled SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312

Simulating with Compiled SDF Files

You can specify compiled SDF files on the vsim command line with the -sdfmin, -sdftyp, and -
sdfmax arguments. Alternatively, they may be specified as the filename in a $sdf_annotate()
system task in the Verilog source.

Using $sdf_annotate() with Compiled SDF

The following limitations exist when using compiled SDF files with $sdf_annotate():

• The $sdf_annotate() call cannot be made from a delayed initial block:

initial #10 $sdf_annotate(...); // Not allowed

• The $sdf_annotate() call cannot be made from an if statement:

reg doSdf = 1'b1;
initial begin
if (doSdf) $sdf_annotate(...); // Not allowed
end

• If the annotation order of multiple $sdf_annotate() calls is important, you must have all
of them in a single initial block.

1312 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
VHDL VITAL SDF

VHDL VITAL SDF

VHDL SDF annotation works on VITAL cells only. The IEEE Std 1076.4-2000, IEEE
Standard for VITAL ASIC Modeling Specification describes how cells must be written to
support SDF annotation. Once again, the designer does not need to know the details of this
specification because the library provider has already written the VITAL cells and tools that
create compatible SDF files. However, the following summary may help you understand
simulator error messages.
SDF to VHDL Generic Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314

ModelSim® SE User's Manual, v10.7 1313

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
SDF to VHDL Generic Matching

SDF to VHDL Generic Matching

An SDF file contains delay and timing constraint data for cell instances in the design. The
annotator must locate the cell instances and the placeholders (VHDL generics) for the timing
data. Each type of SDF timing construct is mapped to the name of a generic as specified by the
VITAL modeling specification. The annotator locates the generic and updates it with the timing
value from the SDF file. It is an error if the annotator fails to find the cell instance or the named
generic.
The following are examples of SDF constructs and their associated generic names:
Table 30-1. Matching SDF to VHDL Generics
SDF construct Matching VHDL generic name
(IOPATH a y (3)) tpd_a_y
(IOPATH (posedge clk) q (1) (2)) tpd_clk_q_posedge
(INTERCONNECT u1/y u2/a (5)) tipd_a
(SETUP d (posedge clk) (5)) tsetup_d_clk_noedge_posedge
(HOLD (negedge d) (posedge clk) (5)) thold_d_clk_negedge_posedge
(SETUPHOLD d clk (5) (5)) tsetup_d_clk & thold_d_clk
(WIDTH (COND (reset==1’b0) clk) (5)) tpw_clk_reset_eq_0
(DEVICE y (1)) tdevice_c1_y1
1. c1 is the instance name of the module containing the previous generic(tdevice_c1_y).

The SDF statement CONDELSE, when targeted for Vital cells, is annotated to a tpd generic of
the form tpd_<inputPort>_<outputPort>.

Resolving Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314

Resolving Errors
If the simulator finds the cell instance but not the generic, an error message is issued.
For example,

** Error (vsim-SDF-3240) myasic.sdf(18):

Instance ’/testbench/dut/u1’ does not have a generic named ’tpd_a_y’

In this case, make sure that the design is using the appropriate VITAL library cells. If it is, then
there is probably a mismatch between the SDF and the VITAL cells. You need to find the cell
instance and compare its generic names to those expected by the annotator. Look in the VHDL
source files provided by the cell library vendor.

1314 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
SDF to VHDL Generic Matching

If none of the generic names look like VITAL timing generic names, then perhaps the VITAL
library cells are not being used. If the generic names do look like VITAL timing generic names
but do not match the names expected by the annotator, then there are several possibilities:

• The vendor’s tools are not conforming to the VITAL specification.

• The SDF file was accidentally applied to the wrong instance. In this case, the simulator
also issues other error messages indicating that cell instances in the SDF could not be
located in the design.
• The vendor’s library and SDF were developed for the older VITAL 2.2b specification.
This version uses different name mapping rules. In this case, invoke vsim with the
-vital2.2b option:
vsim -vital2.2b -sdfmax /testbench/u1=myasic.sdf testbench

Related Topics
VITAL Usage and Compliance
Troubleshooting

ModelSim® SE User's Manual, v10.7 1315

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Verilog SDF

Verilog SDF
Verilog designs can be annotated using either the simulator command line options or the
$sdf_annotate system task (also commonly used in other Verilog simulators). The command
line options annotate the design immediately after it is loaded, but before any simulation events
take place. The $sdf_annotate task annotates the design at the time it is called in the Verilog
source code. This provides more flexibility than the command line options.
$sdf_annotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
SDF to Verilog Construct Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319

1316 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
$sdf_annotate

$sdf_annotate
The $sdf_annotate task annotates the design when it is called in the Verilog source code.
Syntax
$sdf_annotate
([“<sdffile>”], [<instance>], [“<config_file>”], [“<log_file>”], [“<mtm_spec>”],
[“<scale_factor>”], [“<scale_type>”]);
Arguments
• “<sdffile>”
String that specifies the SDF file. Required.
• <instance>
Hierarchical name of the instance to be annotated. Optional. Defaults to the instance where
the $sdf_annotate call is made.
• “<config_file>”
String that specifies the configuration file. Optional. Currently not supported, this argument
is ignored.
• “<log_file>”
String that specifies the logfile. Optional. Currently not supported, this argument is ignored.
• “<mtm_spec>”
String that specifies the delay selection. Optional. The allowed strings are “minimum”,
“typical”, “maximum”, and “tool_control”. Case is ignored and the default is
“tool_control”. The “tool_control” argument means to use the delay specified on the
command line by +mindelays, +typdelays, or +maxdelays (defaults to +typdelays).
• “<scale_factor>”
String that specifies delay scaling factors. Optional. The format is
“<min_mult>:<typ_mult>:<max_mult>”. Each multiplier is a real number that is used to
scale the corresponding delay in the SDF file.
• “<scale_type>”
String that overrides the <mtm_spec> delay selection. Optional. The <mtm_spec> delay
selection is always used to select the delay scaling factor, but if a <scale_type> is specified,
then it will determine the min/typ/max selection from the SDF file. The allowed strings are
“from_min”, “from_minimum”, “from_typ”, “from_typical”, “from_max”,
“from_maximum”, and “from_mtm”. Case is ignored, and the default is “from_mtm”,
which means to use the <mtm_spec> value.

ModelSim® SE User's Manual, v10.7 1317

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
$sdf_annotate

Examples
Optional arguments can be omitted by using commas or by leaving them out if they are at the
end of the argument list. For example, to specify only the SDF file and the instance to which it
applies:

$sdf_annotate("myasic.sdf", testbench.u1);

To also specify maximum delay values:

$sdf_annotate("myasic.sdf", testbench.u1, , , "maximum");

1318 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

SDF to Verilog Construct Matching

The annotator matches SDF constructs to corresponding Verilog constructs in the cells. Usually,
the cells contain path delays and timing checks within specify blocks. For each SDF construct,
the annotator locates the cell instance and updates each specify path delay or timing check that
matches. An SDF construct can have multiple matches, in which case each matching specify
statement is updated with the SDF timing value.
SDF constructs are matched to Verilog constructs as follows.

• IOPATH is matched to specify path delays or primitives:

Table 30-2. Matching SDF IOPATH to Verilog

SDF Verilog
(IOPATH (posedge clk) q (3) (4)) (posedge clk => q) = 0;
(IOPATH a y (3) (4)) buf u1 (y, a);

The IOPATH construct usually annotates path delays. If ModelSim cannot locate a
corresponding specify path delay, it returns an error unless you use the +sdf_iopath_to_prim_ok
argument to vsim. If you specify that argument and the module contains no path delays, then all
primitives that drive the specified output port are annotated.

• INTERCONNECT and PORT are matched to input ports:

Table 30-3. Matching SDF INTERCONNECT and PORT to Verilog

SDF Verilog
(INTERCONNECT u1.y u2.a (5)) input a;
(PORT u2.a (5)) inout a;

Both of these constructs identify a module input or inout port and create an internal net that is a
delayed version of the port. This is called a Module Input Port Delay (MIPD). All primitives,
specify path delays, and specify timing checks connected to the original port are reconnected to
the new MIPD net.

• PATHPULSE and GLOBALPATHPULSE are matched to specify path delays:

Table 30-4. Matching SDF PATHPULSE and GLOBALPATHPULSE to Verilog

SDF Verilog
(PATHPULSE a y (5) (10)) (a => y) = 0;
(GLOBALPATHPULSE a y (30) (60)) (a => y) = 0;

If the input and output ports are omitted in the SDF, then all path delays are matched in the cell.

ModelSim® SE User's Manual, v10.7 1319

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

• DEVICE is matched to primitives or specify path delays:

Table 30-5. Matching SDF DEVICE to Verilog

SDF Verilog
(DEVICE y (5)) and u1(y, a, b);
(DEVICE y (5)) (a => y) = 0; (b => y) = 0;

If the SDF cell instance is a primitive instance, then that primitive’s delay is annotated. If it is a
module instance, then all specify path delays are annotated that drive the output port specified in
the DEVICE construct (all path delays are annotated if the output port is omitted). If the module
contains no path delays, then all primitives that drive the specified output port are annotated (or
all primitives that drive any output port if the output port is omitted).

• SETUP is matched to $setup and $setuphold:

Table 30-6. Matching SDF SETUP to Verilog

SDF Verilog
(SETUP d (posedge clk) (5)) $setup(d, posedge clk, 0);
(SETUP d (posedge clk) (5)) $setuphold(posedge clk, d, 0, 0);

• HOLD is matched to $hold and $setuphold:

Table 30-7. Matching SDF HOLD to Verilog

SDF Verilog
(HOLD d (posedge clk) (5)) $hold(posedge clk, d, 0);
(HOLD d (posedge clk) (5)) $setuphold(posedge clk, d, 0, 0);

• SETUPHOLD is matched to $setup, $hold, and $setuphold:

Table 30-8. Matching SDF SETUPHOLD to Verilog

SDF Verilog
(SETUPHOLD d (posedge clk) (5) (5)) $setup(d, posedge clk, 0);
(SETUPHOLD d (posedge clk) (5) (5)) $hold(posedge clk, d, 0);
(SETUPHOLD d (posedge clk) (5) (5)) $setuphold(posedge clk, d, 0, 0);

1320 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

• RECOVERY is matched to $recovery:

Table 30-9. Matching SDF RECOVERY to Verilog

SDF Verilog
(RECOVERY (negedge reset) (posedge clk) $recovery(negedge reset, posedge clk, 0);
(5))

• REMOVAL is matched to $removal:

Table 30-10. Matching SDF REMOVAL to Verilog

SDF Verilog
(REMOVAL (negedge reset) (posedge clk) $removal(negedge reset, posedge clk, 0);
(5))

• RECREM is matched to $recovery, $removal, and $recrem:

Table 30-11. Matching SDF RECREM to Verilog

SDF Verilog
(RECREM (negedge reset) (posedge clk) $recovery(negedge reset, posedge clk, 0);
(5) (5))
(RECREM (negedge reset) (posedge clk) $removal(negedge reset, posedge clk, 0);
(5) (5))
(RECREM (negedge reset) (posedge clk) $recrem(negedge reset, posedge clk, 0);
(5) (5))

• SKEW is matched to $skew:

Table 30-12. Matching SDF SKEW to Verilog

SDF Verilog
(SKEW (posedge clk1) (posedge clk2) (5)) $skew(posedge clk1, posedge clk2, 0);

• WIDTH is matched to $width:

Table 30-13. Matching SDF WIDTH to Verilog

SDF Verilog
(WIDTH (posedge clk) (5)) $width(posedge clk, 0);

ModelSim® SE User's Manual, v10.7 1321

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

• PERIOD is matched to $period:

Table 30-14. Matching SDF PERIOD to Verilog

SDF Verilog
(PERIOD (posedge clk) (5)) $period(posedge clk, 0);

• NOCHANGE is matched to $nochange:

Table 30-15. Matching SDF NOCHANGE to Verilog

SDF Verilog
(NOCHANGE (negedge write) addr (5) (5)) $nochange(negedge write, addr, 0, 0);

To see complete mappings of SDF and Verilog constructs, please consult IEEE Std 1364-2005,
Chapter 16 - Back Annotation Using the Standard Delay Format (SDF).

Retain Delay Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322

Optional Edge Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324
Optional Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Rounded Timing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325

Retain Delay Behavior

The simulator processes RETAIN delays in SDF files as described in this section.
A RETAIN delay can appear as:

(IOPATH addr[13:0] dout[7:0]

(RETAIN (rval1) (rval2) (rval3)) // RETAIN delays
(dval1) (dval2) ... // IOPATH delays
)

Because rval2 and rval 3 on the RETAIN line are optional, the simulator makes the following
assumptions:

• Only rval1 is specified — rval1 is used as the value of rval2 and rval3.
• rval1 and rval2 are specified — the smaller of rval1 and rval2 is used as the value of
rval3.
During simulation, if any rval that would apply is larger than or equal to the applicable path
delay, then RETAIN delay is not applied.

You can specify that RETAIN delays should not be processed by using +vlog_retain_off on the
vsim command line.

1322 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

Retain delays apply to an IOPATH for any transition on the input of the PATH unless the
IOPATH specifies a particular edge for the input of the IOPATH. This means that for an
IOPATH such as RCLK -> DOUT, RETAIN delay should apply for a negedge on RCLK even
though a Verilog model is coded only to change DOUT in response to a posedge of RCLK. If
(posedge RCLK) -> DOUT is specified in the SDF then an associated RETAIN delay applies
only for posedge RCLK. If a path is conditioned, then RETAIN delays do not apply if a delay
path is not enabled.

Table 30-16 defines which delay is used depending on the transitions:

Table 30-16. RETAIN Delay Usage (default)
Path Retain Retain Delay Path Delay Note
Transition Transition Used Used
0->1 0->x->1 rval1 (0->x) 0->1
1->0 1->x->0 rval2 (1->x) 1->0
z->0 z->x->0 rval3 (z->x) z->0
z->1 z->x->1 rval3 (z->x) z->1
0->z 0->x->z rval1 (0->x) 0->z
1->z 1->x->z rval2 (1->x) 1->z
x->0 x->x->0 n/a x->0 use PATH delay, no RETAIN
delay is applicable
x->1 x->x->1 n/a x->1
x->z x->x->z n/a x->z
0->x 0->x->x rval1 (0->x) 0->x use RETAIN delay for PATH
delay if it is smaller
1->x 1->x->x rval2 (1->x) 1->x
z->x z->x->x rval3 (z->x) z->x

You can specify that X insertion on outputs that do not change except when the causal inputs
change by using +vlog_retain_same2same_on on the vsim command line. An example is when
CLK changes but bit DOUT[0] does not change from its current value of 0, but you want it to go
through the transition 0 -> X -> 0.
Table 30-17. RETAIN Delay Usage (with +vlog_retain_same2same_on)
Path Retain Retain Delay Path Delay Note
Transition Transition Used Used
0->0 0->x->0 rval1 (0->x) 1->0
1->1 1->x->1 rval2 (1->x) 0->1
z->z z->x->z rval3 (z->x) max(0->z,1->z)
x->x x->x->x No output transition

ModelSim® SE User's Manual, v10.7 1323

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

Optional Edge Specifications

Timing check ports and path delay input ports can have optional edge specifications.
The annotator uses the following rules to match edges:

• A match occurs if the SDF port does not have an edge.

• A match occurs if the specify port does not have an edge.
• A match occurs if the SDF port edge is identical to the specify port edge.
• A match occurs if explicit edge transitions in the specify port edge overlap with the SDF
port edge.
These rules allow SDF annotation to take place even if there is a difference between the number
of edge-specific constructs in the SDF file and the Verilog specify block. For example, the
Verilog specify block may contain separate setup timing checks for a falling and rising edge on
data with respect to clock, while the SDF file may contain only a single setup check for both
edges:
Table 30-18. Matching Verilog Timing Checks to SDF SETUP
SDF Verilog
(SETUP data (posedge clock) (5)) $setup(posedge data, posedge clk, 0);
(SETUP data (posedge clock) (5)) $setup(negedge data, posedge clk, 0);

In this case, the cell accommodates more accurate data than can be supplied by the tool that
created the SDF file, and both timing checks correctly receive the same value.

Likewise, the SDF file may contain more accurate data than the model can accommodate.
Table 30-19. SDF Data May Be More Accurate Than Model
SDF Verilog
(SETUP (posedge data) (posedge clock) (4)) $setup(data, posedge clk, 0);
(SETUP (negedge data) (posedge clock) (6)) $setup(data, posedge clk, 0);

In this case, both SDF constructs are matched and the timing check receives the value from the
last one encountered.

Timing check edge specifiers can also use explicit edge transitions instead of posedge and
negedge. However, the SDF file is limited to posedge and negedge. For example,
Table 30-20. Matching Explicit Verilog Edge Transitions to Verilog
SDF Verilog
(SETUP data (posedge clock) (5)) $setup(data, edge[01, 0x] clk, 0);

1324 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
SDF to Verilog Construct Matching

The explicit edge specifiers are 01, 0x, 10, 1x, x0, and x1. The set of [01, 0x, x1] is equivalent to
posedge, while the set of [10, 1x, x0] is equivalent to negedge. A match occurs if any of the
explicit edges in the specify port match any of the explicit edges implied by the SDF port.

Optional Conditions
Timing check ports and path delays can have optional conditions.
The annotator uses the following rules to match conditions:

• A match occurs if the SDF does not have a condition.

• A match occurs for a timing check if the SDF port condition is semantically equivalent
to the specify port condition.
• A match occurs for a path delay if the SDF condition is lexically identical to the specify
condition.
Timing check conditions are limited to very simple conditions, therefore the annotator can
match the expressions based on semantics. For example,
Table 30-21. SDF Timing Check Conditions
SDF Verilog
(SETUP data (COND (reset!=1) $setup(data, posedge clk &&&
(posedge clock)) (5)) (reset==0),0);

The conditions are semantically equivalent and a match occurs. In contrast, path delay
conditions may be complicated and semantically equivalent conditions may not match. For
example,
Table 30-22. SDF Path Delay Conditions
SDF Verilog
(COND (r1 || r2) (IOPATH clk q (5))) if (r1 || r2) (clk => q) = 5; // matches
(COND (r1 || r2) (IOPATH clk q (5))) if (r2 || r1) (clk => q) = 5; // does not match

The annotator does not match the second condition above because the order of r1 and r2 are
reversed.

Rounded Timing Values

The SDF TIMESCALE construct specifies time units of values in the SDF file. The annotator
rounds timing values from the SDF file to the time precision of the module that is annotated. For
example, if the SDF TIMESCALE is 1ns and a value of .016 is annotated to a path delay in a
module having a time precision of 10ps (from the timescale directive), then the path delay

ModelSim® SE User's Manual, v10.7 1325

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
SDF for Mixed VHDL and Verilog Designs

receives a value of 20ps. The SDF value of 16ps is rounded to 20ps. Interconnect delays are
rounded to the time precision of the module that contains the annotated MIPD.

SDF for Mixed VHDL and Verilog Designs

Annotation of a mixed VHDL and Verilog design is very flexible. VHDL VITAL cells and
Verilog cells can be annotated from the same SDF file. This flexibility is available only by
using the simulator’s SDF command line options. The Verilog $sdf_annotate system task can
annotate Verilog cells only.
Related Topics
vsim

Interconnect Delays
An interconnect delay represents the delay from the output of one device to the input of another.
ModelSim can model single interconnect delays or multisource interconnect delays for Verilog,
VHDL/VITAL, or mixed designs.
Timing checks are performed on the interconnect delayed versions of input ports. This may
result in misleading timing constraint violations, because the ports may satisfy the constraint
while the delayed versions may not. If the simulator seems to report incorrect violations, be sure
to account for the effect of interconnect delays.

Related Topics
vsim

Disabling Timing Checks

ModelSim offers a number of options for disabling timing checks on a global or individual
basis.
The table below provides a summary of those options. See the command and argument
descriptions in the Reference Manual for more details.
Table 30-23. Disabling Timing Checks
Command and argument Effect
tcheck_set 1 modifies reporting or X generation status on one or more
timing checks
tcheck_status 1 prints to the Transcript the current status of one or more
timing checks

1326 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
Disabling Timing Checks

Table 30-23. Disabling Timing Checks (cont.)

Command and argument Effect
vlog +notimingchecks disables timing check system tasks for all instances in the
specified Verilog design
vlog +nospecify disables specify path delays and timing checks for all
instances in the specified Verilog design
vopt +notimingchecks removes all timing check entries from the design as it is
parsed; fixes the TimingChecksOn generic for all Vital
models to FALSE; As a consequence, using vsim
+notimingchecks at simulation may not have any effect on
the simulation depending on the optimization of the model.
vsim +no_neg_tchk disables negative timing check limits by setting them to
zero for all instances in the specified design
vsim +no_notifier disables the toggling of the notifier register argument of the
timing check system tasks for all instances in the specified
design
vsim +no_tchk_msg disables error messages issued by timing check system
tasks when timing check violations occur for all instances
in the specified design
vsim +notimingchecks disables Verilog and VITAL timing checks for all instances
in the specified design; sets generic TimingChecksOn to
FALSE for all VHDL Vital models with the Vital_level0 or
Vital_level1 attribute. Setting this generic to FALSE
disables the actual calls to the timing checks along with
anything else that is present in the model's timing check
block.
vsim+nospecify disables specify path delays and timing checks for all
instances in the specified design
1. tcheck_set and tcheck_status commands will not operate on a module instance (and the underlying
hierarchy) that has been compiled with "-nodebug" option. A suppressible warning message will be
issued.

ModelSim® SE User's Manual, v10.7 1327

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Troubleshooting

Troubleshooting
ModelSim provides a number of tools for troubleshooting designs that use SDF files.
Specifying the Wrong Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Matching a Single Timing Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Mistaking a Component or Module Name for an Instance Label. . . . . . . . . . . . . . . . . . 1329
Forgetting to Specify the Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Reporting Unannotated Specify Path Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330

Specifying the Wrong Instance

By far, the most common mistake in SDF annotation is to specify the wrong instance to the
simulator’s SDF options. The most common case is to leave off the instance altogether, which is
the same as selecting the top-level design unit. This is generally wrong because the instance
paths in the SDF are relative to the ASIC or FPGA model, which is usually instantiated under a
top-level test bench.
Simple examples for both a VHDL and a Verilog test bench are provided below. For simplicity,
these test bench examples do nothing more than instantiate a model that has no ports.

VHDL Test Bench

entity testbench is end;
architecture only of testbench is
component myasic
end component;
begin
dut : myasic;
end;

Verilog Test Bench

module testbench;
myasic dut();
endmodule

The name of the model is myasic and the instance label is dut. For either test bench, an
appropriate simulator invocation might be:

vsim -sdfmax /testbench/dut=myasic.sdf testbench

Optionally, you can leave off the name of the top-level:

vsim -sdfmax /dut=myasic.sdf testbench

The important thing is to select the instance for which the SDF is intended. If the model is deep
within the design hierarchy, an easy way to find the instance name is to first invoke the
simulator without SDF options, view the structure pane, navigate to the model instance, select

1328 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
Matching a Single Timing Check

it, and enter the environment command. This command displays the instance name that should
be used in the SDF command line option.

Related Topics
Instance Specification

Matching a Single Timing Check

SDF annotation of RECREM or SETUPHOLD matching only a single setup, hold, recovery, or
removal timing check will result in a Warning message.

Mistaking a Component or Module Name for an

Instance Label
Another common error is to specify the component or module name rather than the instance
label.
For example, the following invocation is wrong for the above test benches:

vsim -sdfmax /testbench/myasic=myasic.sdf testbench

This results in the following error message:

** Error (vsim-SDF-3250) myasic.sdf(0):

Failed to find INSTANCE ’/testbench/myasic’.

Forgetting to Specify the Instance

If you leave off the instance altogether, then the simulator issues a message for each instance
path in the SDF that is not found in the design.
For example,

vsim -sdfmax myasic.sdf testbench

ModelSim® SE User's Manual, v10.7 1329

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Reporting Unannotated Specify Path Objects

Results in:

** Error (vsim-SDF-3250) myasic.sdf(0):

Failed to find INSTANCE ’/testbench/u1’
** Error (vsim-SDF-3250) myasic.sdf(0):
Failed to find INSTANCE ’/testbench/u2’
** Error (vsim-SDF-3250) myasic.sdf(0):
Failed to find INSTANCE ’/testbench/u3’
** Error (vsim-SDF-3250) myasic.sdf(0):
Failed to find INSTANCE ’/testbench/u4’
** Error (vsim-SDF-3250) myasic.sdf(0):
Failed to find INSTANCE ’/testbench/u5’
** Warning (vsim-SDF-3432) myasic.sdf:
This file is probably applied to the wrong instance.
** Warning (vsim-SDF-3432) myasic.sdf:
Ignoring subsequent missing instances from this file.

After annotation is done, the simulator issues a summary of how many instances were not found
and possibly a suggestion for a qualifying instance:

** Warning (vsim-SDF-3440) myasic.sdf:

Failed to find any of the 358 instances from this file.
** Warning (vsim-SDF-3442) myasic.sdf:
Try instance ’/testbench/dut’. It contains all instance paths from this
file.

The simulator recommends an instance only if the file was applied to the top-level and a
qualifying instance is found one level down.

Also see Resolving Errors for specific VHDL VITAL SDF troubleshooting.

Reporting Unannotated Specify Path Objects

ModelSim allows you to create a report about unannotated or partially-annotated specify path
objects, path delays and timing checks, to better understand a design that uses SDF files.
Unannotated specify objects occur either because the SDF file did not contain any SDF
statements targeting that object or (in a rather unusual situation) because all the values in the
statement were null, as signified by a pair of empty parentheses “()”.

The partial annotation of specify objects occurs when the SDF statements contain some null
values.

Procedure
1. (optional) Add the +acc argument to the vopt command to view line numbers in the
report.
2. Add the -sdfreport=<filename> argument to your vsim command line.

1330 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Standard Delay Format (SDF) Timing Annotation
Reporting Unannotated Specify Path Objects

Results
The Unannotated Specify Objects Report contains a list of objects that fit into any of the
following three categories:
• Unannotated specify paths (UASP).
• Unannotated timing checks (UATC). This indicates either a single-value timing check
that was not annotated or part of a $setuphold or $recrem that was not annotated.
• Incompletely-annotated specify path transition edges (IATE). This indicates that certain
edges of a specify path, such as 0->1, 1->Z, and so on, were incompletely annotated.
The header of the report contains a full description of the syntax.
Examples
This example report shows the format if you have full design visibility (vopt with the +acc
argument):

Unannotated Specify Objects Report:

===================================
(UASP) = Unannotated specify path.
(UATC) = Unannotated timing check.
(IATE) = Incompltely annotated specify path transition edges.
-------------------------------------------------------------
/test1/u1: ( [mymod(fast):test.v(4)]):
17: (CK => Q1) = (1000) : (UASP)
18: (S => Q1) = (102, 1000) : (IATE:10)
19: (SI => Q1) = (103, 104, 1000) : (IATE:tz)
20: (CK => Q2) = (1000, 201) : (IATE:01)
21: (S => Q2) = (1000, 1000, 202) : (IATE:01,10)
22: (SI => Q2) = (203, 1000, 204) : (IATE:10)
30: SETUP: (posedge CK &&& Sn1), (D &&& CKe0): 2000 : (UATC)
30: HOLD: (D &&& CKe0), (posedge CK &&& Sn1): 3000 : (UATC)
36: HOLD: (posedge CK &&& Sn0), (SI &&& Sn0): 1000 : (UATC)
37: SETUP: (posedge CK &&& Sn0), (SI &&& CKe0): 6000 : (IATC)
38: HOLD: (posedge CK), (SI): 9000 : (IATC)
Found 1 instances with unannotated or incompletely annotated specify block
objects.

ModelSim® SE User's Manual, v10.7 1331

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Standard Delay Format (SDF) Timing Annotation
Reporting Unannotated Specify Path Objects

This example report shows the format if you fully optimized the design (lines are abbreviated
for readability):

Unannotated Specify Objects Report:

===================================
(UASP) = Unannotated specify path.
(UATC) = Unannotated timing check.
(IATE) = Incompltely annotated specify path transition edges.
-------------------------------------------------------------------------
--------------------------------------------
/test1/u1: ( [mymod(fast):test.v(4)]):
(CK => Q1) = (1000, 1000, 1000, 1000, 1000, ... 1000) : (UASP)
(S => Q1) = (102, 1000, 102, 102, 1000, ... 102, 1000) :
(IATE:10,1Z,Z0,1X,X0,ZX)
(SI => Q1) = (103, 104, 1000, 103, 1000, ... 104, 1000, 103) :
(IATE:0Z,1Z,0X,1X,XZ)
(CK => Q2) = (1000, 201, 1000, 1000, ... 201, 201, 201, 1000) :
(IATE:01,0Z,Z1,0X,X1,ZX)
(S => Q2) = (1000, ... 1000, 1000, 202, 1000) :
(IATE:01,10,Z1,Z0,0X,X1,1X,X0,ZX)
(SI => Q2) = (203, 1000, 204, 203, 204, ... 1000, 204, 1000) :
(IATE:10,Z0,1X,X0,ZX)
HOLD: (posedge CK), (SI): 9000 : (UATC)
SETUP: (posedge CK &&& Sn0), (SI &&& CKe0): 6000 : (UATC)
SETUP: (posedge CK &&& Sn1), (D &&& CKe0): 2000 : (UATC)
HOLD: (D &&& CKe0), (posedge CK &&& Sn1): 3000 : (UATC)
HOLD: (posedge CK &&& Sn0), (SI &&& Sn0): 1000 : (UATC)
Found 1 instances with unannotated or incompletely annotated specify block
objects.

1332 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 31
Value Change Dump (VCD) Files

The Value Change Dump (VCD) file format is supported for use by ModelSim and is specified
in the IEEE 1364-2005 standard. A VCD file is an ASCII file that contains information about
value changes on selected variables in the design stored by VCD system tasks. This includes
header information, variable definitions, and variable value changes.
VCD is in common use for Verilog designs and is controlled by VCD system task calls in the
Verilog source code. ModelSim provides equivalent commands for these system tasks and
extends VCD support to SystemC and VHDL designs. You can use these ModelSim VCD
commands on Verilog, VHDL, SystemC, or mixed designs.

Extended VCD supports Verilog and VHDL ports in a mixed-language design containing
SystemC. However, extended VCD does not support SystemC ports in a mixed-language
design.

If you need vendor-specific ASIC design-flow documentation that incorporates VCD, contact
your ASIC vendor.

Creating a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334

Using Extended VCD as Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
VCD Commands and VCD Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340
VCD File from Source to Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
VCD to WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Capturing Port Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Resolving Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348

ModelSim® SE User's Manual, v10.7 1333

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Creating a VCD File

Creating a VCD File

ModelSim provides two general methods for creating a VCD file.
• Four-State VCD File — produces a four-state VCD file.
• Extended VCD File — produces an extended VCD (EVCD) file.
Both methods capture port driver changes unless you filter them out with optional
command-line arguments.

Four-State VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334

Extended VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
VCD Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Checkpoint/Restore and Writing VCD Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335

Four-State VCD File

This procedure produces a four-state VCD file with variable changes in 0, 1, x, and z with no
strength information.
Procedure
1. Compile and load the design. For example:
cd <installDir>/examples/tutorials/verilog/basicSimulation
vlib work
vlog counter.v tcounter.v
vopt test_counter +acc -o test_counter_opt
vsim test_counter_opt

2. With the design loaded, specify the VCD file name with the vcd file command and add
objects to the file with the vcd add command as follows:
vcd file myvcdfile.vcd
vcd add /test_counter/dut/*
VSIM 3> runVSIM 4> quit -f

Results
Upon quitting the simulation, there will be a VCD file in the working directory.

Extended VCD File

This procedure produces an extended VCD (EVCD) file with variable changes in all states and
strength information and port driver data.

1334 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
VCD Case Sensitivity

Procedure
1. Compile and load the design. For example:
cd <installDir>/examples/tutorials/verilog/basicSimulation
vlib work
vlog counter.v tcounter.v
vopt test_counter +acc -o test_counter_opt
vsim test_counter_opt

2. With the design loaded, specify the VCD file name and objects to add with the
vcd dumpports command:
vcd dumpports -file myvcdfile.vcd /test_counter/dut/*
run
VSIM 4> quit -f

Results
Upon quitting the simulation, there will be an extended VCD file called myvcdfile.vcd in the
working directory.
Note
There is an internal limit to the number of ports that can be listed with the vcd dumpports
command. If that limit is reached, use the vcd add command with the -dumpports option to
name additional ports.

VCD Case Sensitivity

Verilog designs are case-sensitive, so ModelSim maintains case when it produces a VCD file.
However, VHDL is not case-sensitive, so ModelSim converts all signal names to lower case
when it produces a VCD file.

Checkpoint/Restore and Writing VCD Files

If a checkpoint occurs while ModelSim is writing a VCD file, the entire VCD file is copied into
the checkpoint file. Since VCD files can be very large, it is possible that disk space problems
may occur. Consequently, ModelSim issues a warning in this situation.

ModelSim® SE User's Manual, v10.7 1335

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Using Extended VCD as Stimulus

Using Extended VCD as Stimulus

You can use an extended VCD file as stimulus to re-simulate your design.
There are two ways to do this:

1. Simulate the top level of a design unit with the input values from an extended VCD file.
2. Specify one or more instances in a design to be replaced with the output values from the
associated VCD file.
Simulating with Input Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Replacing Instances with Output Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . 1338
Port Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339

Simulating with Input Values from a VCD File

When simulating with inputs from an extended VCD file, you can simulate only one design unit
at a time. In other words, you can apply the VCD file inputs only to the top level of the design
unit for which you captured port data.
Procedure
1. Create a VCD file for a single design unit using the vcd dumpports command.
2. Resimulate the single design unit using the -vcdstim argument with the vsim command.
Note that -vcdstim works only with VCD files that were created by a ModelSim
simulation.
Examples
Verilog Counter
First, create the VCD file for the single instance using vcd dumpports:

cd <installDir>/examples/tutorials/verilog/basicSimulation
vlib work
vlog counter.v tcounter.v
vopt test_counter +acc -o test_counter_opt
vsim test_counter_opt +dumpports+nocollapse
vcd dumpports -file counter.vcd /test_counter/dut/*
run
quit -f

Next, rerun the counter without the test bench, using the -vcdstim argument:

vopt counter -o counter_replay

1336 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Simulating with Input Values from a VCD File

vsim counter_replay -vcdstim counter.vcd

add wave /*
run 200
VHDL Adder
First, create the VCD file using vcd dumpports:

cd <installDir>/examples/vcd
vlib work
vcom gates.vhd adder.vhd stimulus.vhd
vopt testbench2 +acc -o testbench2_opt
vsim testbench2_opt +dumpports+nocollapse
vcd dumpports -file addern.vcd /testbench2/uut/*
run 1000
quit -f

Next, rerun the adder without the test bench, using the -vcdstim argument:

vsim -vcdstim addern.vcd addern -gn=8 -do "add wave /*; run 1000"
Mixed-HDL Design
First, create three VCD files, one for each module:

cd <installDir>/examples/tutorials/mixed/projects
vlib work
vlog cache.v memory.v proc.v
vcom util.vhd set.vhd top.vhd
vopt top +acc -o top_opt
vsim top_opt +dumpports+nocollapse
vcd dumpports -file proc.vcd /top/p/*
vcd dumpports -file cache.vcd /top/c/*
vcd dumpports -file memory.vcd /top/m/*
run 1000
quit -f

Next, rerun each module separately, using the captured VCD stimulus:

vsim -vcdstim proc.vcd proc -do "add wave /*; run 1000"
quit -f
vsim -vcdstim cache.vcd cache -do "add wave /*; run 1000"

ModelSim® SE User's Manual, v10.7 1337

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Replacing Instances with Output Values from a VCD File

quit -f
vsim -vcdstim memory.vcd memory -do "add wave /*; run 1000"
quit -f

Note
When using VCD files as stimulus, the VCD file format does not support recording of delta
delay changes – delta delays are not captured and any delta delay ordering of signal changes
is lost. Designs relying on this ordering may produce unexpected results.

Replacing Instances with Output Values from a

VCD File
Replacing instances with output values from a VCD file lets you simulate without the instance’s
source or even the compiled object.
Procedure
1. Create VCD files for one or more instances in your design using the vcd dumpports
command. If necessary, use the -vcdstim switch to handle port order problems (see
below).
2. Re-simulate your design using the -vcdstim <instance>=<filename> argument to vsim.
Note that this works only with VCD files that were created by a ModelSim simulation.
Examples
Replacing Instances
In the following example, the three instances /top/p, /top/c, and /top/m are replaced in
simulation by the output values found in the corresponding VCD files.

First, create VCD files for all instances you want to replace:

vcd dumpports -vcdstim -file proc.vcd /top/p/*

vcd dumpports -vcdstim -file cache.vcd /top/c/*
vcd dumpports -vcdstim -file memory.vcd /top/m/*
run 1000

Next, simulate your design and map the instances to the VCD files you created:

vsim top_opt -vcdstim /top/p=proc.vcd -vcdstim /top/c=cache.vcd

-vcdstim /top/m=memory.vcd
quit -f

1338 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Port Order Issues

Note
When using VCD files as stimulus, the VCD file format does not support recording of delta
delay changes – delta delays are not captured and any delta delay ordering of signal changes
is lost. Designs relying on this ordering may produce unexpected results.

Port Order Issues

The -vcdstim argument for the vcd dumpports command ensures the order that port names
appear in the VCD file matches the order that they are declared in the instance’s module or
entity declaration.
Consider the following module declaration:

module proc(clk, addr, data, rw, strb, rdy);

input clk, rdy;
output addr, rw, strb;
inout data;

The order of the ports in the module line (clk, addr, data, ...) does not match the order of those
ports in the input, output, and inout lines (clk, rdy, addr, ...). In this case the -vcdstim argument
to the vcd dumpports command needs to be used.

In cases where the order is the same, you do not need to use the -vcdstim argument to vcd
dumpports. Also, module declarations of the form:

module proc(input clk, output addr, inout data, ...)

do not require use of the argument.

ModelSim® SE User's Manual, v10.7 1339

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
VCD Commands and VCD Tasks

VCD Commands and VCD Tasks

ModelSim VCD commands map to IEEE Std 1364 VCD system tasks and appear in the VCD
file along with the results of those commands. The table below maps the VCD commands to
their associated tasks.

Table 31-1. VCD Commands and SystemTasks

VCD commands VCD system tasks
vcd add $dumpvars
vcd checkpoint $dumpall
vcd file $dumpfile
vcd flush $dumpflush
vcd limit $dumplimit
vcd off $dumpoff
vcd on $dumpon

ModelSim also supports extended VCD (dumpports system tasks). The table below maps the
VCD dumpports commands to their associated tasks.
Table 31-2. VCD Dumpport Commands and System Tasks
VCD dumpports commands VCD system tasks
vcd dumpports $dumpports
vcd dumpportsall $dumpportsall
vcd dumpportsflush $dumpportsflush
vcd dumpportslimit $dumpportslimit
vcd dumpportsoff $dumpportsoff
vcd dumpportson $dumpportson

ModelSim supports multiple VCD files. This functionality is an extension of the IEEE Std
1364-2005 specification. The tasks behave the same as the IEEE equivalent tasks such as
$dumpfile, $dumpvar, and so forth. The difference is that $fdumpfile can be called multiple
times to create more than one VCD file, and the remaining tasks require a filename argument to
associate their actions with a specific file. Table 31-3 maps the VCD commands to their
associated tasks. For additional details, please see the Verilog IEEE Std 1364-2005
specification.
Table 31-3. VCD Commands and System Tasks for Multiple VCD Files
VCD commands VCD system tasks
vcd add -file <filename> $fdumpvars( levels, {, module_or_variable }1, filename)

1340 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Using VCD Commands with SystemC

Table 31-3. VCD Commands and System Tasks for Multiple VCD Files (cont.)
VCD commands VCD system tasks
vcd checkpoint <filename> $fdumpall( filename )
vcd files <filename> $fdumpfile( filename )
vcd flush <filename> $fdumpflush( filename )
vcd limit <filename> $fdumplimit( filename )
vcd off <filename> $fdumpoff( filename )
vcd on <filename> $fdumpon( filename )
1. denotes an optional, comma-separated list of 0 or more modules or variables

Using VCD Commands with SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341

Compressing Files with VCD Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1342

Using VCD Commands with SystemC

VCD commands are supported for SystemC signals and signal ports.

Supported SystemC Signals

sc_signal<T>, sc_signal_resolved, and sc_signal_rv<N>

Supported SystemC Signal Ports

sc_in_resolved, sc_out_resolved, sc_inout_resolved

sc_in_rv<N>, sc_out_rv<N>, sc_inout_rv<N>

sc_in<T>, sc_out<T>, sc_inout<T>, where <T> can be any of types shown in the following
table.
Table 31-4. SystemC Types
unsigned char char sc_int
unsigned short short sc_uint
unsigned int int sc_bigint
unsigned long float sc_biguint
unsigned long long double sc_signed
enum sc_unsigned
sc_logic
sc_bit

ModelSim® SE User's Manual, v10.7 1341

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Compressing Files with VCD Tasks

Table 31-4. SystemC Types (cont.)

sc_bv
sc_lv
Unsupported types are the SystemC fixed point types, class, structures and unions.

Compressing Files with VCD Tasks

ModelSim can produce compressed VCD files using the gzip compression algorithm. Since we
cannot change the syntax of the system tasks, we act on the extension of the output file name. If
you specify a .gz extension on the filename, ModelSim will compress the output.

1342 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
VCD File from Source to Output

VCD File from Source to Output

The following example code shows the VHDL source, a set of simulator commands, and the
resulting VCD output.
VHDL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
VCD Simulator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343

VHDL Source Code

The design is a simple shifter device represented by the following VHDL source code.
library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity SHIFTER_MOD is
port (CLK, RESET, data_in : IN STD_LOGIC;
Q : INOUT STD_LOGIC_VECTOR(8 downto 0));
END SHIFTER_MOD ;

architecture RTL of SHIFTER_MOD is

begin
process (CLK,RESET)
begin
if (RESET = '1') then
Q <= (others => '0') ;
elsif (CLK'event and CLK = '1') then
Q <= Q(Q'left - 1 downto 0) & data_in ;
end if ;
end process ;
end ;

VCD Simulator Commands

At simulator time zero, the designer executes the following commands.

ModelSim® SE User's Manual, v10.7 1343

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
VCD Simulator Commands

vcd file output.vcd

vcd add -r *
force reset 1 0
force data_in 0 0
force clk 0 0
run 100
force clk 1 0, 0 50 -repeat 100
run 100
vcd off
force reset 0 0
force data_in 1 0
run 100
vcd on
run 850
force reset 1 0
run 50
vcd checkpoint
quit -sim

VCD Output
The VCD file created as a result of the preceding scenario would be called output.vcd. The
following pages show how it would look.

1344 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
VCD Simulator Commands

ModelSim® SE User's Manual, v10.7 1345

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
VCD to WLF

VCD to WLF
The ModelSim vcd2wlf command is a utility that translates a .vcd file into a .wlf file that can be
displayed in ModelSim using the vsim -view argument. This command only works on VCD
files containing positive time values.

Capturing Port Driver Data

Some ASIC vendors’ toolkits read a VCD file format that provides details on port drivers. This
information can be used, for example, to drive a tester. For more information on a specific
toolkit, refer to the ASIC vendor’s documentation.
In ModelSim, use the vcd dumpports command to create a VCD file that captures port driver
data. Each time an external or internal port driver changes values, a new value change is
recorded in the VCD file with the following format:

p<state> <0 strength> <1 strength> <identifier_code>

Driver States
Table 31-5 shows the driver states recorded as TSSI states if the direction is known.
Table 31-5. Driver States
Input (testfixture) Output (dut)
D low L low
U high H high
N unknown X unknown
Z tri-state T tri-state
d low (two or more l low (two or more
drivers active) drivers active)
u high (two or more h high (two or more
drivers active) drivers active)

If the direction is unknown, the state will be recorded as one of the following:
Table 31-6. State When Direction is Unknown
Unknown direction
0 low (both input and output are driving low)
1 high (both input and output are driving high)
? unknown (both input and output are driving
unknown)
F three-state (input and output unconnected)

1346 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Capturing Port Driver Data

Table 31-6. State When Direction is Unknown (cont.)

Unknown direction
A unknown (input driving low and output driving
high)
a unknown (input driving low and output driving
unknown)
B unknown (input driving high and output driving
low)
b unknown (input driving high and output driving
unknown)
C unknown (input driving unknown and output
driving low)
c unknown (input driving unknown and output
driving high)
f unknown (input and output three-stated)

Driver Strength
The recorded 0 and 1 strength values are based on Verilog strengths:
Table 31-7. Driver Strength
Strength VHDL std_logic mappings
0 highz ’Z’
1 small
2 medium
3 weak
4 large
5 pull ’W’,’H’,’L’
6 strong ’U’,’X’,’0’,’1’,’-’
7 supply

Identifier Code
The <identifier_code> is an integer preceded by < that starts at zero and is incremented for each
port in the order the ports are specified. Also, the variable type recorded in the VCD header is
“port”.

ModelSim® SE User's Manual, v10.7 1347

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Resolving Values

Resolving Values
The resolved values written to the VCD file depend on which options you specify when creating
the file.
Default Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
When force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
Extended Data Type for VHDL (vl_logic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349
Ignoring Strength Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1350

Default Behavior
By default, ModelSim generates VCD output according to the IEEE Std 1364™-2005, IEEE
Standard for Verilog® Hardware Description Language. This standard states that the values 0
(both input and output are active with value 0) and 1 (both input and output are active with value
1) are conflict states. The standard then defines two strength ranges:
• Strong: strengths 7, 6, and 5
• Weak: strengths 4, 3, 2, 1
The rules for resolving values are as follows:

• If the input and output are driving the same value with the same range of strength, the
resolved value is 0 or 1, and the strength is the stronger of the two.
• If the input is driving a strong strength and the output is driving a weak strength, the
resolved value is D, d, U or u, and the strength is the strength of the input.
• If the input is driving a weak strength and the output is driving a strong strength, the
resolved value is L, l, H or h, and the strength is the strength of the output.

When force Command is Used

If you force a value on a net that does not have a driver associated with it, ModelSim uses the
port direction shown in the following table to dump values to the VCD file. When the port is an
inout, the direction cannot be determined.

Table 31-8. VCD Values When Force Command is Used

Value forced on Port Direction
net
input output inout
0 D L 0
1 U H 1

1348 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Extended Data Type for VHDL (vl_logic)

Table 31-8. VCD Values When Force Command is Used (cont.)

Value forced on Port Direction
net
input output inout
X N X ?
Z Z T F

Extended Data Type for VHDL (vl_logic)

Mentor Graphics has created an additional VHDL data type for use in mixed-language designs,
in case you need access to the full Verilog state set. The vl_logic type is an enumeration that
defines the full set of VHDL values for Verilog nets, as defined for Logic Strength Modeling in
IEEE 1364™-2005.
This specification defines the following driving strengths for signals propagated from gate
outputs and continuous assignment outputs:

Supply, Strong, Pull, Weak, HiZ

This specification also defines three charge storage strengths for signals originating in the trireg
net type:

Large, Medium, Small

Each of these strengths can assume a strength level ranging from 0 to 7 (expressed as a binary
value from 000 to 111), combined with the standard four-state values of 0, 1, X, and Z. This
results in a set of 256 strength values, which preserves Verilog strength values going through
the VHDL portion of the design and allows a VCD in extended format for any downstream
application.

The vl_logic type is defined in the following file installed with ModelSim, where you can view
the 256 strength values:

<install_dir>/vhdl_src/verilog/vltypes.vhd

This location is a pre-compiled verilog library provided in your installation directory, along
with the other pre-compiled libraries (std and ieee).

Note
The Wave window display and WLF do not support the full range of vl_logic values for
VHDL signals.

ModelSim® SE User's Manual, v10.7 1349

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Ignoring Strength Ranges

Ignoring Strength Ranges

You may wish to ignore strength ranges and have ModelSim handle each strength separately.
Any of the following options will produce this behavior:

• Use the -no_strength_range argument to the vcd dumpports command

• Use an optional argument to $dumpports (see Extended $dumpports Syntax below)
• Use the +dumpports+no_strength_range argument to vsim command
In this situation, ModelSim reports strengths for both the zero and one components of the value
if the strengths are the same. If the strengths are different, ModelSim reports only the “winning”
strength. In other words, the two strength values either match (for example, pA 5 5 !) or the
winning strength is shown and the other is zero (for instance, pH 0 5 !).

Extended $dumpports Syntax

ModelSim extends the $dumpports system task in order to support exclusion of strength ranges.

The extended syntax is as follows:

$dumpports (scope_list, file_pathname, ncsim_file_index, file_format)

The nc_sim_index argument is required yet ignored by ModelSim. It is required only to be

compatible with NCSim’s argument list.

The file_format argument accepts the following values or an ORed combination thereof (see
examples below):
Table 31-9. Values for file_format Argument
File_format Meaning
value
0 Ignore strength range
2 Use strength ranges; produces IEEE 1364-compliant
behavior
4 Compress the EVCD output
8 Include port direction information in the EVCD file
header; same as using -direction argument to vcd
dumpports

Here are some examples:

// ignore strength range

$dumpports(top, "filename", 0, 0)

1350 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Value Change Dump (VCD) Files
Ignoring Strength Ranges

// compress and ignore strength range

$dumpports(top, "filename", 0, 4)

// print direction and ignore strength range

$dumpports(top, "filename", 0, 8)

// compress, print direction, and ignore strength range

$dumpports(top, "filename", 0, 12)

Example 31-1. VCD Output from vcd dumpports

This example demonstrates how vcd dumpports resolves values based on certain combinations
of driver values and strengths and whether or not you use strength ranges. Table 31-10 is sample
driver data.
Table 31-10. Sample Driver Data
time in value out value in strength value out strength value
(range) (range)
0 0 0 7 (strong) 7 (strong)
100 0 0 6 (strong) 7 (strong)
200 0 0 5 (strong) 7 (strong)
300 0 0 4 (weak) 7 (strong)
900 1 0 6 (strong) 7 (strong)
27400 1 1 5 (strong) 4 (weak)
27500 1 1 4 (weak) 4 (weak)
27600 1 1 3 (weak) 4 (weak)

Given the driver data above and use of 1364 strength ranges, here is what the VCD file output
would look like:

#0
p0 7 0 <0
#100
p0 7 0 <0
#200
p0 7 0 <0
#300
pL 7 0 <0
#900
pB 7 6 <0
#27400
pU 0 5 <0
#27500
p1 0 4 <0
#27600
p1 0 4 <0

ModelSim® SE User's Manual, v10.7 1351

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Value Change Dump (VCD) Files
Ignoring Strength Ranges

1352 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 32
Tcl and DO Files

Tcl is a scripting language for controlling and extending ModelSim. Within ModelSim you can
develop implementations from Tcl scripts without the use of C code. Because Tcl is interpreted,
development is rapid; you can generate and execute Tcl scripts “on the fly” without stopping to
recompile or restart ModelSim. In addition, if ModelSim does not provide a command you
need, you can use Tcl to create your own commands.
Tcl Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354
Tcl Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355
Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
List Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366
Simulator Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373
The Tcl Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
TclPro Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384

ModelSim® SE User's Manual, v10.7 1353

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Tcl Features

Tcl Features
Using Tcl with ModelSim gives you these features:
• command history (like that in C shells)
• full expression evaluation and support for all C-language operators
• a full range of math and trig functions
• support of lists and arrays
• regular expression pattern matching
• procedures
• the ability to define your own commands
• command substitution (that is, commands may be nested)
• robust scripting language for DO files
Tcl References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354

Tcl References
For quick reference information on Tcl, choose the following from the ModelSim main menu:
Help > Tcl Man Pages

In addition, the following books provide more comprehensive usage information on Tcl:

• Tcl and the Tk Toolkit by John K. Ousterhout, published by Addison-Wesley Publishing

Company, Inc.
• Practical Programming in Tcl and Tk by Brent Welch, published by Prentice Hall.

1354 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Tcl Command Syntax

Tcl Command Syntax

The following eleven rules define the syntax and semantics of the Tcl language.
• A Tcl script is a string containing one or more commands. Semi-colons and newlines are
command separators unless quoted as described below. Close brackets (“]”) are
command terminators during command substitution (see below) unless quoted.
• A command is evaluated in two steps. First, the Tcl interpreter breaks the command into
words and performs substitutions as described below. These substitutions are performed
in the same way for all commands. The first word is used to locate a command
procedure to carry out the command, then all of the words of the command are passed to
the command procedure. The command procedure is free to interpret each of its words
in any way it likes, such as an integer, variable name, list, or Tcl script. Different
commands interpret their words differently.
• Words of a command are separated by white space (except for newlines, which are
command separators).
• If the first character of a word is a double-quote (") then the word is terminated by the
next double-quote character. If semi-colons, close brackets, or white space characters
(including newlines) appear between the quotes then they are treated as ordinary
characters and included in the word. Command substitution, variable substitution, and
backslash substitution are performed on the characters between the quotes as described
below. The double-quotes are not retained as part of the word.
• If the first character of a word is an open brace ({) then the word is terminated by the
matching close brace (}). Braces nest within the word: for each additional open brace
there must be an additional close brace (however, if an open brace or close brace within
the word is quoted with a backslash then it is not counted in locating the matching close
brace). No substitutions are performed on the characters between the braces except for
backslash-newline substitutions described below, nor do semi-colons, newlines, close
brackets, or white space receive any special interpretation. The word will consist of
exactly the characters between the outer braces, not including the braces themselves.
• If a word contains an open bracket ([) then Tcl performs command substitution. To do
this it invokes the Tcl interpreter recursively to process the characters following the
open bracket as a Tcl script. The script may contain any number of commands and must
be terminated by a close bracket (]). The result of the script (that is, the result of its last
command) is substituted into the word in place of the brackets and all of the characters
between them. There may be any number of command substitutions in a single word.
Command substitution is not performed on words enclosed in braces.
• If a word contains a dollar-sign ($) then Tcl performs variable substitution: the dollar-
sign and the following characters are replaced in the word by the value of a variable.
Variable substitution may take any of the following forms:
o $name

ModelSim® SE User's Manual, v10.7 1355

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Tcl Command Syntax

Name is the name of a scalar variable; the name is terminated by any character that is
not a letter, digit, or underscore.
o $name(index)
Name gives the name of an array variable and index gives the name of an element
within that array. Name must contain only letters, digits, and underscores. Command
substitutions, variable substitutions, and backslash substitutions are performed on
the characters of index.
o ${name}
Name is the name of a scalar variable. It may contain any characters whatsoever
except for close braces.
There may be any number of variable substitutions in a single word. Variable
substitution is not performed on words enclosed in braces.
• If a backslash (\) appears within a word then backslash substitution occurs. In all cases
but those described below the backslash is dropped and the following character is treated
as an ordinary character and included in the word. This allows characters such as double
quotes, close brackets, and dollar signs to be included in words without triggering
special processing. Table 32-1 lists the backslash sequences that are handled specially,
along with the value that replaces each sequence.

Table 32-1. Tcl Backslash Sequences

Sequence Value
\a Audible alert (bell) (0x7)
\b Backspace (0x8)
\f Form feed (0xc).
\n Newline (0xa)
\r Carriage-return (0xd)
\t Tab (0x9)
\v Vertical tab (0xb)
\<newline>whiteSpace A single space character replaces the backslash, newline,
and all spaces and tabs after the newline. This backslash
sequence is unique in that it is replaced in a separate pre-
pass before the command is actually parsed. This means
that it will be replaced even when it occurs between
braces, and the resulting space will be treated as a word
separator if it is not in braces or quotes.
\\ Backslash (“\”)

1356 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Tcl Command Syntax

Table 32-1. Tcl Backslash Sequences (cont.)

Sequence Value
\ooo The digits ooo (one, two, or three of them) give the octal
value of the character.
\xhh The hexadecimal digits hh give the hexadecimal value of
the character. Any number of digits may be present.
Backslash substitution is not performed on words enclosed in braces, except for backslash-
newline as described above.

1. If a pound sign (#) appears at a point where Tcl is expecting the first character of the first
word of a command, then the pound sign and the characters that follow it, up through the
next newline, are treated as a comment and ignored. The # character denotes a comment
only when it appears at the beginning of a command.
2. Each character is processed exactly once by the Tcl interpreter as part of creating the
words of a command. For example, if variable substitution occurs then no further
substitutions are performed on the value of the variable; the value is inserted into the
word verbatim. If command substitution occurs then the nested command is processed
entirely by the recursive call to the Tcl interpreter; no substitutions are performed before
making the recursive call and no additional substitutions are performed on the result of
the nested script.
3. Substitutions do not affect the word boundaries of a command. For example, during
variable substitution the entire value of the variable becomes part of a single word, even
if the variable's value contains spaces.
If Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
set Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
Command Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Command Separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Multiple-Line Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Evaluation Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1361
Tcl Relational Expression Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1361
Variable Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
System Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
ModelSim Replacements for Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362

ModelSim® SE User's Manual, v10.7 1357

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
If Command Syntax

If Command Syntax
The Tcl if command executes scripts conditionally. Note that in the syntax below the question
mark (?) indicates an optional argument.
Syntax
if expr1 ?then? body1 elseif expr2 ?then? body2 elseif ... ?else? ?bodyN?

Arguments
None
Description
The if command evaluates expr1 as an expression. The value of the expression must be a
boolean (a numeric value, where 0 is false and anything else is true, or a string value such as
true or yes for true and false or no for false); if it is true then body1 is executed by passing it to
the Tcl interpreter. Otherwise expr2 is evaluated as an expression and if it is true then body2 is
executed, and so on. If none of the expressions evaluates to true then bodyN is executed. The
then and else arguments are optional “noise words” to make the command easier to read. There
may be any number of elseif clauses, including zero. BodyN may also be omitted as long as else
is omitted too. The return value from the command is the result of the body script that was
executed, or an empty string if none of the expressions was non-zero and there was no bodyN.

1358 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
set Command Syntax

set Command Syntax

The Tcl set command returns or sets the values of variables.
Syntax
set <varName> [<value>]

Arguments
• The following arguments are available:
o <varName> — (required) The name of a Tcl variable. The variable name relates to
the following:
• GUI preference variables. You can view a complete list of these variables within
the GUI from the Tools > Edit Preferences menu selection.
• Simulator control variables.

UserTimeUnit IgnoreNote CheckpointCom

pressMode
RunLength IgnoreNote NumericStdNo
Warnings
IterationLimit IgnoreError StdArithNoWar
nings
BreakOnAsserti IgnoreFailure PathSeparator
on
DefaultForceKin DefaultRadix
d
WLFFilename DelayFileOpen
WLFTimeLimit
WLFSizeLimit

If you do not specify a <value> this command will return the value of the <varName> you
specify.
o <value> — (optional) The value to be assigned to the variable.
When you specify <value> you will change the current state of the <varName> you
specify.
Description
Returns the value of variable varName. If you specify value, the command sets the value of
varName to value, creating a new variable if one does not already exist, and returns its value. If
varName contains an open parenthesis and ends with a close parenthesis, then it refers to an
array element: the characters before the first open parenthesis are the name of the array, and the

ModelSim® SE User's Manual, v10.7 1359

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Command Substitution

characters between the parentheses are the index within the array. Otherwise varName refers to
a scalar variable. Normally, varName is unqualified (does not include the names of any
containing namespaces), and the variable of that name in the current namespace is read or
written. If varName includes namespace qualifiers (in the array name if it refers to an array
element), the variable in the specified namespace is read or written.

If no procedure is active, then varName refers to a namespace variable (global variable if the
current namespace is the global namespace). If a procedure is active, then varName refers to a
parameter or local variable of the procedure unless the global command was invoked to declare
varName to be global, or unless a Tcl variable command was invoked to declare varName to be
a namespace variable.

Command Substitution
Placing a command in square brackets ([ ]) will cause that command to be evaluated first and its
results returned in place of the command. For example:
set a 25
set b 11
set c 3
echo "the result is [expr ($a + $b)/$c]"

This generates the following output:

"the result is 12"

Substitution allows you to obtain VHDL variables and signals, and Verilog nets and registers
using the following construct:

[examine -<radix> name]

The %name substitution is no longer supported. Everywhere %name could be used, you now
can use [examine -value -<radix> name] which allows the flexibility of specifying command
options. The radix specification is optional.

Command Separator
A semicolon character (;) works as a separator for multiple commands on the same line. It is not
required at the end of a line in a command sequence.

Multiple-Line Commands
With Tcl, multiple-line commands can be used within scripts and on the command line. The
command line prompt will change (as in a C shell) until the multiple-line command is complete.

1360 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Evaluation Order

In the example below, note the way the opening brace “{” is at the end of the if and else lines.
This is important because otherwise the Tcl scanner does not know that there is more coming in
the command and will try to execute what it has up to that point, which is not what you intend.

if { [exa sig_a] == "0011ZZ"} {

echo "Signal value matches"
do do_1.do
} else {
echo "Signal value fails"
do do_2.do
}

Evaluation Order
An important thing to remember when using Tcl is that anything put in braces ({}) is not
evaluated immediately. This is important for if-then-else statements, procedures, loops, and so
forth.

Tcl Relational Expression Evaluation

When you are comparing values, the following hints may be useful:
• Tcl stores all values as strings, and will convert certain strings to numeric values when
appropriate. If you want a literal to be treated as a numeric value, do not quote it.
if {[exa var_1] == 345}...

The following will also work:

if {[exa var_1] == "345"}...

• However, if a literal cannot be represented as a number, you must quote it, or Tcl gives
you an error. For instance:
if {[exa var_2] == 001Z}...

gives an error.
if {[exa var_2] == "001Z"}...

does not give an error.

• Do not quote single characters between apostrophes; use quotation marks instead. For
example:
if {[exa var_3] == 'X'}...

will produce an error. However, the following:

if {[exa var_3] == "X"}...

ModelSim® SE User's Manual, v10.7 1361

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Variable Substitution

will work.
• For the equal operator, you must use the C operator (==). For not-equal, you must use
the C operator (!=).

Variable Substitution
When a $<var_name> is encountered, the Tcl parser will look for variables that have been
defined either by ModelSim or by you, and substitute the value of the variable.
Note
Tcl is case sensitive for variable names.

To access environment variables, use the construct:

$env(<var_name>)
echo My user name is $env(USER)

Environment variables can also be set using the env array:

set env(SHELL) /bin/csh

See modelsim.ini Variables for more information about ModelSim-defined variables.

System Commands
To pass commands to the UNIX shell or DOS window, use the Tcl exec command:
echo The date is [exec date]

ModelSim Replacements for Tcl Commands

For complete information on Tcl commands, select Help > Tcl Man Pages.
ModelSim command names that conflict with Tcl commands have been renamed or have been
replaced by Tcl commands, as shown in Table 32-2.
Table 32-2. Changes to ModelSim Commands
Previous ModelSim Command changed to (or replaced by)
command
continue run with the -continue option
format list | wave write format with either list or wave specified
if replaced by the Tcl if command, see If Command
Syntax for more information
list add list

1362 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
ModelSim Replacements for Tcl Commands

Table 32-2. Changes to ModelSim Commands (cont.)

Previous ModelSim Command changed to (or replaced by)
command
nolist | nowave delete with either list or wave specified
set replaced by the Tcl set command. Refer to the set
Command Syntax for more information.
source vsource
wave add wave

Related Topics
Simulator GUI Preferences [ModelSim SE GUI Reference Manual]

ModelSim® SE User's Manual, v10.7 1363

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Simulator State Variables

Simulator State Variables

Unlike other variables that must be explicitly set, simulator state variables return a value
relative to the current simulation. Simulator state variables can be useful in commands,
especially when used within ModelSim DO file scripts. The variables are referenced in
commands by prefixing the name with a dollar sign ($).

Table 32-3. Simulator State Variables

Variable Description
architecture This variable returns the name of the top-level architecture currently
being simulated; for an optimized Verilog module, returns architecture
name; for a configuration or non-optimized Verilog module, this
variable returns an empty string.
argc This variable returns the total number of parameters passed to the
current script.
argv This variable returns the list of parameters (arguments) passed to the
vsim command line.
configuration This variable returns the name of the top-level configuration currently
being simulated; returns an empty string if no configuration.
delta This variable returns the number of the current simulator iteration.
entity This variable returns the name of the top-level VHDL entity or Verilog
module currently being simulated.
library This variable returns the library name for the current region.
MacroNestingLevel This variable returns the current depth of script call nesting.
n This variable represents a script parameter, where n can be an integer in
the range 1-9.
Now This variable always returns the current simulation time with time units
(for example, 110,000 ns). Note: the returned value contains a comma
inserted between thousands.
now This variable returns the current simulation time with or without time
units—depending on the setting for time resolution, as follows:
• When time resolution is a unary unit (such as 1ns, 1ps, 1fs), this
variable returns the current simulation time without time units (for
example, 100000).
• When time resolution is a multiple of the unary unit (such as 10ns,
100ps, 10fs), this variable returns the current simulation time with
time units (for example, 110000 ns).
Note: the returned value does not contain a comma inserted between
thousands.
resolution This variable returns the current simulation time resolution.

1364 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Referencing Simulator State Variables

Referencing Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365

Special Considerations for the now Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Reading Variable Values From the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365
Setting Variable Values for the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366

Referencing Simulator State Variables

Variable values may be referenced in simulator commands by preceding the variable name with
a dollar sign ($). For example, to use the now and resolution variables in an echo command
type:
echo "The time is $now $resolution."

Depending on the current simulator state, this command could result in:

The time is 12390 ps 10ps.

If you do not want the dollar sign to denote a simulator variable, precede it with a “\”. For
example, \$now will not be interpreted as the current simulator time.

Special Considerations for the now Variable

For the when command, special processing is performed on comparisons involving the now
variable. If you specify “when {$now=100}...”, the simulator will stop at time 100 regardless of
the multiplier applied to the time resolution.
You must use 64-bit time operators if the time value of now will exceed 2147483647 (the limit
of 32-bit numbers). For example:

if { [gtTime $now 2us] }

{…}

See Simulator Tcl Time Commands for details on 64-bit time operators.

Related Topics
when [ModelSim SE Command Reference Manual]

Reading Variable Values From the INI File

You can read values from the modelsim.ini file with the following function:
GetPrivateProfileString <section> <key> <defaultValue>

Reads the string value for the specified variable in the specified section. Optionally provides a
default value if no value is present.

ModelSim® SE User's Manual, v10.7 1365

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Setting Variable Values for the INI File

Setting Tcl variables with values from the modelsim.ini file is one use of these Tcl functions.
For example,

set MyCheckpointCompressMode [GetPrivateProfileString vsim

CheckpointCompressMode 1 modelsim.ini ]

set PrefMain(file) [GetPrivateProfileString vsim TranscriptFile ""

modelsim.ini]

This example reports the value of the variable named SolveGraphMaxSize from the vsim
section in the modelsim.ini file.

echo [GetPrivateProfileString vsim SolveGraphMaxSize "" modelsim.ini ]

Setting Variable Values for the INI File

You can set values for the modelsim.ini file with the WritePrivateProfileString Tcl function.
Procedure
To set a variable value, use the following Tcl function:

WritePrivateProfileString variable_name section key value filename

This Tcl function sets the string value for the specified variable in the specified section.
Optionally, it provides a default value if no value is present.

List Processing
In Tcl, a “list” is a set of strings in braces separated by spaces. Several Tcl commands are
available for creating lists, indexing into lists, appending to lists, getting the length of lists and
shifting lists, as shown in the following table.

Table 32-4. Tcl List Commands

Command syntax Description
lappend var_name val1 val2 ... appends val1, val2, ..., to list var_name
lindex list_name index returns the index-th element of list_name; the first
element is 0
linsert list_name index val1 val2 ... inserts val1, val2, ..., just before the index-th element of
list_name
list val1, val2 ... returns a Tcl list consisting of val1, val2, ...
llength list_name returns the number of elements in list_name

1366 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
List Processing

Table 32-4. Tcl List Commands (cont.)

Command syntax Description
lrange list_name first last returns a sublist of list_name, from index first to index
last; first or last may be “end”, which refers to the last
element in the list
lreplace list_name first last val1, replaces elements first through last with val1, val2, ...
val2, ...
Two other commands, lsearch and lsort, are also available for list manipulation. See the Tcl man
pages (Help > Tcl Man Pages) for more information on these commands.

Related Topics
when [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1367

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Simulator Tcl Commands

Simulator Tcl Commands

These additional commands enhance the interface between Tcl and ModelSim. Only brief
descriptions are provided in the following table.

Table 32-5. Simulator-Specific Tcl Commands

Command Description
alias creates a new Tcl procedure that evaluates the specified
commands; used to create a user-defined alias
find locates incrTcl classes and objects
lecho takes one or more Tcl lists as arguments and pretty-prints
them to the Transcript pane
lshift takes a Tcl list as argument and shifts it in-place one place
to the left, eliminating the 0th element
lsublist returns a sublist of the specified Tcl list that matches the
specified Tcl glob pattern
printenv echoes to the Transcript pane the current names and values
of all environment variables

Simulator Tcl Time Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369

1368 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Simulator Tcl Time Commands

Simulator Tcl Time Commands

ModelSim Tcl time commands make simulator-time-based values available for use within other
Tcl procedures.
Time values may optionally contain a units specifier where the intervening space is also
optional. If the space is present, the value must be quoted (for example, 10ns, “10 ns”). Time
values without units are taken to be in the UserTimeScale. Return values are always in the
current Time Scale Units. All time values are converted to a 64-bit integer value in the current
Time Scale. When values are smaller than the current Time Scale, the values are truncated to 0
and a warning is issued.

Time Conversion Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369

Time Relations Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1369
Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370

Time Conversion Tcl Commands

The following table provides Tcl time conversion commands.

Table 32-6. Tcl Time Conversion Commands

Command Description
intToTime <intHi32> <intLo32> converts two 32-bit pieces (high and low
order) into a 64-bit quantity (Time in
ModelSim is a 64-bit integer)
RealToTime <real> converts a <real> number to a 64-bit integer
in the current Time Scale
scaleTime <time> <scaleFactor> returns the value of <time> multiplied by
the <scaleFactor> integer

Time Relations Tcl Commands

The following table provides Tcl time relation commands.

Table 32-7. Tcl Time Relation Commands

Command Description
eqTime <time> <time> evaluates for equal
neqTime <time> <time> evaluates for not equal
gtTime <time> <time> evaluates for greater than
gteTime <time> <time> evaluates for greater than or equal

ModelSim® SE User's Manual, v10.7 1369

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Tcl Examples

Table 32-7. Tcl Time Relation Commands (cont.)

Command Description
ltTime <time> <time> evaluates for less than
lteTime <time> <time> evaluates for less than or equal
All relation operations return 1 or 0 for true or false respectively and are suitable return values
for TCL conditional expressions. For example,

if {[eqTime $Now 1750ns]} {

...
}

Tcl Time Arithmetic Commands

The following table provides commands for performing arithmetic operations on time.

Table 32-8. Tcl Time Arithmetic Commands

Command Description
addTime <time> <time> add time
divTime <time> <time> 64-bit integer divide
mulTime <time> <time> 64-bit integer multiply
subTime <time> <time> subtract time

Tcl Examples
This section provides examples of Tcl command usage.
• Tcl while Loop
This example uses the Tcl while loop to copy a list from variable a to variable b,
reversing the order of the elements along the way:
set b [list]
set i [expr {[llength $a] - 1}]
while {$i >= 0} {
lappend b [lindex $a $i]
incr i -1
}

• Tcl for Command

1370 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Tcl Examples

This example uses the Tcl for command to copy a list from variable a to variable b,
reversing the order of the elements along the way:
set b [list]
for {set i [expr {[llength $a] - 1}]} {$i >= 0} {incr i -1} {
lappend b [lindex $a $i]
}

• Tcl foreach Command

This example uses the Tcl foreach command to copy a list from variable a to variable b,
reversing the order of the elements along the way (the foreach command iterates over all
of the elements of a list):
set b [list]
foreach i $a { set b [linsert $b 0 $i] }

• Tcl break Command

This example shows a list reversal as above, this time aborting on a particular element
using the Tcl break command:
set b [list]
foreach i $a {
if {$i = "ZZZ"} break
set b [linsert $b 0 $i]
}

• Tcl continue Command

This example is a list reversal that skips a particular element by using the Tcl continue
command:
set b [list]
foreach i $a {
if {$i = "ZZZ"} continue
set b [linsert $b 0 $i]
}

• Access and Transfer System Information

This example works in UNIX only. In a Windows environment, the Tcl exec command
will execute compiled files only, not system commands.) The example shows how you
can access system information and transfer it into VHDL variables or signals and
Verilog nets or registers. When a particular HDL source breakpoint occurs, a Tcl
function is called that gets the date and time and deposits it into a VHDL signal of type
STRING. If a particular environment variable (DO_ECHO) is set, the function also
echoes the new date and time to the transcript file by examining the VHDL variable.

ModelSim® SE User's Manual, v10.7 1371

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Tcl Examples

(in VHDL source):

signal datime : string(1 to 28) := " ";# 28 spaces

(on VSIM command line or in a DO file script):

proc set_date {} {
global env
set do_the_echo [set env(DO_ECHO)]
set s [clock format [clock seconds]]
force -deposit datime $s
if {do_the_echo} {
echo "New time is [examine -value datime]"
}
}

bp src/waveadd.vhd 133 {set_date; continue}

--sets the breakpoint to call set_date

• Tcl Used to Specify Compiler Arguments

This example specifies the compiler arguments and lets you compile any number of
files.
set Files [list]
set nbrArgs $argc
for {set x 1} {$x <= $nbrArgs} {incr x} {
set lappend Files $1
shift
}
eval vcom -93 -explicit -noaccel std_logic_arith $Files

• Tcl Used to Specify Compiler Arguments—Enhanced

This example is an enhanced version of the last one. The additional code determines
whether the files are VHDL or Verilog and uses the appropriate compiler and arguments
depending on the file type. Note that the script assumes your VHDL files have a .vhd file
extension.
set vhdFiles [list]
set vFiles [list]
set nbrArgs $argc
for {set x 1} {$x <= $nbrArgs} {incr x} {
if {[string match *.vhd $1]} {
lappend vhdFiles $1
} else {
lappend vFiles $1
}
shift
}
if {[llength $vhdFiles] > 0} {
eval vcom -93 -explicit -noaccel std_logic_arith $vhdFiles
}
if {[llength $vFiles] > 0} {
eval vlog $vFiles
}

1372 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
DO Files

DO Files
ModelSim DO files are simply scripts that contain ModelSim and, optionally, Tcl commands.
You invoke these scripts with the Tools > TCL > Execute Macro menu selection or the do
command.
Creating DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373
Using Parameters with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Deleting a File from a .do Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
Making Script Parameters Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375
Breakpoint Flow Control in Nested DO files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376
Useful Commands for Handling Breakpoints and Errors . . . . . . . . . . . . . . . . . . . . . . . . 1378
Error Action in DO File Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379
Using the Tcl Source Command with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379

Creating DO Files
You can create DO file scripts, like any other Tcl script, by doing one of the following.
Procedure
1. Type the required commands in any editor and save the file with the extension .do.
2. Save the transcript as a DO file (refer to Saving a Transcript File as a DO file in the GUI
Reference Manual).
3. Use the write format restart command to create a .do file that will recreate all debug
windows, all file/line breakpoints, and all signal breakpoints created with the when
command.
4. All “event watching” commands (for example, onbreak, onerror, and so forth) must be
placed before run commands within the script in order to take effect.
5. The following is a simple DO file script that was saved from the transcript. It is used in
the dataset exercise in the ModelSim Tutorial. This script adds several signals to the
Wave window, provides stimulus to those signals, and then advances the simulation.

ModelSim® SE User's Manual, v10.7 1373

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Using Parameters with DO Files

add wave ld
add wave rst
add wave clk
add wave d
add wave q
force -freeze clk 0 0, 1 {50 ns} -r 100
force rst 1
force rst 0 10
force ld 0
force d 1010
onerror {cont}
run 1700
force ld 1
run 100
force ld 0
run 400
force rst 1
run 200
force rst 0 10
run 1500

Using Parameters with DO Files

You can increase the flexibility of DO file scripts by using parameters. Parameters specify
values that are passed to the corresponding parameters $1 through $9 in the script. For example
say the DO file “testfile” contains the line bp $1 $2. The command below would place a
breakpoint in the source file named design.vhd at line 127:
do testfile design.vhd 127

There is no limit to the number of parameters that can be passed to DO file scripts, but only nine
values are visible at one time. You can use the shift command to see the other parameters.

Deleting a File from a .do Script

To delete a file from a .do script, use the Tcl file command.
Procedure
1. The Tcl file command
file delete myfile.log

2. will delete the file “myfile.log.”

3. You can also use the transcript file command to perform a deletion:
transcript file ()
transcript file my file.log

4. The first line will close the current log file. The second will open a new log file. If it has
the same name as an existing file, it will replace the previous one.

1374 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Making Script Parameters Optional

Making Script Parameters Optional

If you want to make DO file script parameters optional (that is, be able to specify fewer
parameter values with the do command than the number of parameters referenced in the DO file
script), you must use the argc simulator state variable. The argc simulator state variable returns
the number of parameters passed. The examples below show several ways of using argc.
• Specifying Files to Compile With argc DO File Scripts
This script specifies the files to compile and handles 0-2 compiler arguments as
parameters. If you supply more arguments, ModelSim generates a message.
switch $argc {
0 {vcom file1.vhd file2.vhd file3.vhd }
1 {vcom $1 file1.vhd file2.vhd file3.vhd }
2 {vcom $1 $2 file1.vhd file2.vhd file3.vhd }
default {echo Too many arguments. The macro accepts 0-2 args. }
}

• Specifying Compiler Arguments With DO File Scripts

This script specifies the compiler arguments and lets you compile any number of files.
variable Files ""
set nbrArgs $argc
for {set x 1} {$x <= $nbrArgs} {incr x} {
set Files [concat $Files $1]
shift
}
eval vcom -93 -explicit -noaccel std_logic_arith $Files

• Specifying Compiler Arguments With Scripts — Enhanced

This DO file script is an enhanced version of the one shown in example 2. The
additional code determines whether the files are VHDL or Verilog and uses the
appropriate compiler and arguments depending on the file type. Note that the script
assumes your VHDL files have a .vhd file extension.

ModelSim® SE User's Manual, v10.7 1375

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Breakpoint Flow Control in Nested DO files

variable vhdFiles ""

variable vFiles ""
set nbrArgs $argc
set vhdFilesExist 0
set vFilesExist 0
for {set x 1} {$x <= $nbrArgs} {incr x} {
if {[string match *.vhd $1]} {
set vhdFiles [concat $vhdFiles $1]
set vhdFilesExist 1
} else {
set vFiles [concat $vFiles $1]
set vFilesExist 1
}
shift
}
if {$vhdFilesExist == 1} {
eval vcom -93 -explicit -noaccel std_logic_arith $vhdFiles
}
if {$vFilesExist == 1} {
eval vlog $vFiles}

Related Topics
Simulator State Variables

Breakpoint Flow Control in Nested DO files

The following diagram shows how control flows from one DO file to another and out to the
command line interface for input from the user.

1376 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Breakpoint Flow Control in Nested DO files

Figure 32-1. Breakpoint Flow Control in Nested DO Files

ModelSim® SE User's Manual, v10.7 1377

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Useful Commands for Handling Breakpoints and Errors

Useful Commands for Handling Breakpoints and

Errors
If you are executing a script when your simulation hits a breakpoint or causes a run-time error,
ModelSim interrupts the script and returns control to the command line. The commands in the
following table may be useful for handling such events. (Any other legal command may be
executed as well.)

Table 32-9. Commands for Handling Breakpoints and Errors in DO scripts

Command Result
run -continue continue as if the breakpoint had not been executed,
completes the run that was interrupted
resume continue running the script
onbreak specify a command to run when you hit a breakpoint
within a script
onElabError specify a command to run when an error is
encountered during elaboration
onerror specify a command to run when an error is
encountered within a script
status get a traceback of nested script calls when a script is
interrupted
abort terminate a script once the script has been interrupted
or paused
pause cause the script to be interrupted; the script can be
resumed by entering a resume command via the
command line
transcript control echoing of script commands to the Transcript
pane

You can also set the OnErrorDefaultAction Tcl variable to determine what action ModelSim
takes when an error occurs.

To set the variable on a permanent basis, you must define the variable in a modelsim.tcl file
(refer to The modelsim.tcl File for details).

1378 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Error Action in DO File Scripts

Error Action in DO File Scripts

If a command in a script returns an error, ModelSim does the following:
1. If an onerror command has been set in the script, ModelSim executes that command.
The onerror command must be placed prior to the run command in the DO file to take
effect.
2. If no onerror command has been specified in the script, ModelSim checks the
OnErrorDefaultAction variable. If the variable is defined, its action will be invoked.
3. If neither 1 or 2 is true, the script aborts.

Using the Tcl Source Command with DO Files

Either the do command or Tcl source command can execute a DO file, but they behave
differently.
With the Tcl source command, the DO file is executed exactly as if the commands in it were
typed in by hand at the prompt. Each time a breakpoint is hit, the Source window is updated to
show the breakpoint. This behavior could be inconvenient with a large DO file containing many
breakpoints.

When a do command is interrupted by an error or breakpoint, it does not update any windows,
and keeps the DO file “locked”. This keeps the Source window from flashing, scrolling, and
moving the arrow when a complex DO file is executed. Typically an onbreak resume command
is used to keep the script running as it hits breakpoints. Add an onbreak abort command to the
DO file if you want to exit the script and update the Source window.

ModelSim® SE User's Manual, v10.7 1379

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
The Tcl Debugger

The Tcl Debugger

The Tcl Debugger, TDebug, works by parsing and redefining Tcl/Tk-procedures, inserting calls
to `td_eval' at certain points, which takes care of the display, stepping, breakpoints, variables
and so forth. The advantages are that TDebug knows which statement in which procedure is
currently being executed and can give visual feedback by highlighting it. All currently
accessible variables and their values are displayed as well. Code can be evaluated in the context
of the current procedure. Breakpoints can be set and deleted with the mouse.
Unfortunately there are drawbacks to this approach. Preparation of large procedures is slow and
due to Tcl's dynamic nature there is no guarantee that a procedure can be prepared at all. This
problem has been alleviated somewhat with the introduction of partial preparation of
procedures. There is still no possibility to get at code running in the global context.

Note
Mentor Graphics would like to acknowledge the contribution from Gregor Schmid for
making TDebug available for use in the public domain.

The TDebug program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of FITNESS FOR A PARTICULAR
PURPOSE.

The Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380

The Chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Tcl Debugger Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1383
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384

The Debugger
Select Tools > TCL > Tcl Debugger to run the debugger. Make sure you use the ModelSim
and TDebug menu selections to invoke and close the debugger.
Select the Popup button in the Chooser to open the debugger window (Figure 32-2).

1380 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
The Debugger

Figure 32-2. Tcl Debugger for vsim

The debugger window is divided into the main region with the name of the current procedure
(Proc), a listing in which the expression just executed is highlighted, the Result of this
execution and the currently available Variables and their values, an entry to Eval expressions
in the context of the current procedure, and some button controls for the state of the debugger.

A procedure listing displayed in the main region will have a darker background on all lines that
have been prepared. You can prepare or restore additional lines by selecting a region
(<Button-1>, standard selection) and choosing Selection > Prepare Proc or Selection >
Restore Proc from the debugger menu (or by pressing Ctrl-P or Ctrl-R).

When using `Prepare' and `Restore', try to be smart about what you intend to do. If you select
just a single word (plus some optional white space) it will be interpreted as the name of a
procedure to prepare or restore. Otherwise, if the selection is owned by the listing, the
corresponding lines will be used.

Be careful with partial prepare or restore! If you prepare random lines inside a `switch' or `bind'
expression, you may get surprising results on execution, because the parser does not know about
the surrounding expression and cannot try to prevent problems.

There are seven possible debugger states, one for each button and an `idle' or `waiting' state
when no button is active. The button-activated states are shown in Table 32-10.
Table 32-10. Tcl Debug States
Button Description
Stop stop after next expression, used to get out of slow/fast/
nonstop mode

ModelSim® SE User's Manual, v10.7 1381

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
The Chooser

Table 32-10. Tcl Debug States (cont.)

Button Description
Next execute one expression, then revert to idle
Slow execute until end of procedure, stopping at breakpoints or
when the state changes to stop; after each execution, stop
for ‘delay’ milliseconds; the delay can be changed with
the ‘+’ and ‘-’ buttons
Fast execute until end of procedure, stopping at breakpoints
Nonstop execute until end of procedure without stopping at
breakpoints or updating the display
Break terminate execution of current procedure
Closing the debugger does not quit it, it only does `wm withdraw'. The debugger window will
pop up the next time a prepared procedure is called. Make sure you close the debugger with
Debugger > Close.

The Chooser
Select Tools > TCL > Tcl Debugger to open the TDebug chooser.
The TDebug chooser has three parts. At the top the current interpreter, vsim.op_, is shown. In
the main section there are two list boxes. All currently defined procedures are shown in the left
list box. By clicking the left mouse button on a procedure name, the procedure gets prepared for
debugging and its name is moved to the right list box. Clicking a name in the right list box
returns a procedure to its normal state.

Figure 32-3. TDebug Choose Dialog

Press the right mouse button on a procedure in either list box to get its program code displayed
in the main debugger window.

1382 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Tcl Debugger Breakpoints

The three buttons at the bottom let you force a Rescan of the available procedures, Popup the
debugger window or Exit TDebug. Exiting from TDebug does not terminate ModelSim, it
merely detaches from vsim.op_, restoring all prepared procedures to their unmodified state.

Tcl Debugger Breakpoints

To set/unset a breakpoint, double-click inside the listing. The breakpoint will be set at the
innermost available expression that contains the position of the click. Conditional or counted
breakpoints are not supported.
Figure 32-4. Setting a Breakpoint in the Debugger

The Eval entry supports a simple history mechanism available via the <Up_arrow> and
<Down_arrow> keys. If you evaluate a command while stepping through a procedure, the
command will be evaluated in the context of the procedure; otherwise it will be evaluated at the
global level. The result will be displayed in the result field. This entry is useful for a lot of
things, but especially to get access to variables outside the current scope.

Try entering the line `global td_priv' and watch the Variables box (with global and array
variables enabled of course).

Figure 32-5. Variables Dialog Box

ModelSim® SE User's Manual, v10.7 1383

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
Configuration

Configuration
You can customize TDebug by setting up a file named .tdebugrc in your home directory.

TclPro Debugger
The Tools menu in the Main window contains a selection for the TclPro Debugger from
Scriptics Corporation. This debugger and any available documentation can be acquired from
Scriptics. Once acquired, do the following steps to use the TclPro Debugger:
1. Make sure the TclPro bin directory is in your PATH.
2. In TclPro Debugger, create a new project with Remote Debugging enabled.
3. Start ModelSim and select Tools > TclPro Debugger.
4. Press the Stop button in the debugger in order to set breakpoints, and so forth.

Note
TclPro Debugger version 1.4 does not work with ModelSim.

1384 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix A
modelsim.ini Variables

The modelsim.ini file is the default initialization file and contains control variables that specify
reference library paths, optimization, compiler and simulator settings, and various other
functions. This chapter covers the contents and modification of the modelsim.ini file.
Organization of the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
AcceptLowerCasePragmaOnly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
AmsStandard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
AssertionCover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
AutoExclusionsDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1431
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432
BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433
BatchTranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
BindAtCompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
BreakOnAssertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
CheckPlusargs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438

ModelSim® SE User's Manual, v10.7 1385

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

CheckSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
CodeCoverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
CommandHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
CompilerTempDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
CoverCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
CoverClkOptBuiltins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
CoverExcludeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
CoverOpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
CoverREC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1459
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
CoverThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
CoverWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467
CppOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468
CppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
DefaultLibType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475
DefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
DefaultRestartOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1480
DpiCppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483

1386 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
EnableSVCoverpointExprVariable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
EnumBaseInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488
error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1490
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
ExtendedToggleMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
FecEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
FlatLibPageDeletePercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
floatfixlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1500
ForceSigNextIter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
ForceUnsignedIntegerToVHDLInteger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503
FsmResetTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
GCThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
GenerateFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1509
GenerateLoopIterationMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510
GenerateRecursionDepthMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513
GlobalSharedObjectsList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
Hazard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
IgnoreFailure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
IgnoreSVAWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
IgnoreWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528

ModelSim® SE User's Manual, v10.7 1387

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
InitOutCompositeParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
IterationLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
LargeObjectSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
MaxReportRhsSVCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
MaxSVCoverpointBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
MaxSVCrossBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
MessageFormatFail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
MessageFormatWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
modelsim_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
MsgLimitCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
MultiFileCompilationUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
NoCaseStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
NoRangeCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
NumericStdNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573

1388 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

OnFinishPendingAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
osvvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
PedanticErrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
RequireConfigForAllDefaultBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
Sc22Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
ScMainFinishOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
ScStackSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
Show_Warning1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
Show_Warning2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Show_Warning3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Show_Warning4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
Show_Warning5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
SignalForceFunctionUseDefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618

ModelSim® SE User's Manual, v10.7 1389

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
SmartDbgSym. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
SolveACTMaxOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
SolveACTMaxTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
SolveACTRetryCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
SolveBeforeErrorSeverity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
SolveFailDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
SolveFailDebugMaxSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
SolveGraphMaxEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
SolveIgnoreOverflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
StackTraceDepth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
Stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
StdArithNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
sv_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
SVCovergroupGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
SVCovergroupPerInstanceDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
SVCovergroupTypeGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
SVCoverpointAutoBinMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664

1390 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

SVCoverpointWildCardBinValueSizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
ToggleMaxRealValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
ToggleVlogEnumBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
TranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
UnattemptedImmediateAssertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
UVMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
VhdlSeparatePduPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
WarnConstantChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712

ModelSim® SE User's Manual, v10.7 1391

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
WildcardSizeThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
WildcardSizeThresholdVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
WLFCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
WLFCollapseMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
WLFDeleteOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
WLFFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
WLFOptimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
WLFSimCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
WLFTimeLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
WrapColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
WrapWSColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
Commonly Used modelsim.ini Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
Common Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
Hierarchical Library Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Warnings from Arithmetic Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
Restart Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736

1392 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Organization of the modelsim.ini File

Organization of the modelsim.ini File

The modelsim.ini file is located in your install directory and is organized into the following
sections.
• The [library] section contains variables that specify paths to various libraries used by
ModelSim.
• The [vcom] section contains variables that control the compilation of VHDL files.
• The [vlog] section contains variables that control the compilation of Verilog files.
• The [sccom] section contains variables that control the compilation of SystemC files.
• The [vopt] section contains variables that control optimization.
• The [DefineOptionset] section allows you to define groups of commonly used
command line arguments. Refer to “Optionsets” in the Reference Manual for more
information.
• The [vsim] section contains variables that control the simulator.
• The [lmc] section contains variables that control the interface between the simulator
and Logic Modeling’s SmartModel SWIFT software.
• The [msg_system] section contains variables that control the severity of notes,
warnings, and errors that come from vcom, vlog and vsim.
• The [utils] section contains variables that control utility functions in the tool
environment.
The System Initialization chapter contains descriptions of Environment Variables.

Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393

Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395

Making Changes to the modelsim.ini File

When first installed, the modelsim.ini file is protected as a Read-only file. In order to make and
save changes to the file, you must first turn off the Read-only attribute in the modelsim.ini
Properties dialog box.
Procedure
1. Navigate to the location of the modelsim.ini file:
<install directory>/modelsim.ini

ModelSim® SE User's Manual, v10.7 1393

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Editing modelsim.ini Variables

2. Right-click the modelsim.ini file and choose Properties from the popup menu. This
displays the modelsim.ini Properties dialog box.
3. Uncheck the Attribute: Read-only.
4. Click OK.
5. To protect the modelsim.ini file after making changes, repeat the preceding steps, but at
Step 3, check the Read-only attribute.

Editing modelsim.ini Variables

Once the Read-only attribute has been turned off, you can make changes to the values of the
variables in the file.
The syntax for variables in the file is as follows:

<variable> = <value>

Procedure
1. Open the modelsim.ini file with a text editor.
2. Find the variable you want to edit in the appropriate section of the file.
3. Type the new value for the variable after the equal ( = ) sign.
4. If the variable is commented out with a semicolon ( ; ) remove the semicolon.
5. Save.

Note
Reading and setting Tcl variable values is detailed in “Reading Variable Values
From the INI File”.

Overriding the Default Initialization File

You can make changes to the working environment during a work session by loading an
alternate initialization file that replaces the default modelsim.ini file. This file overrides the file
and path specified by the MODELSIM environment variable.
Refer to “Initialization Sequence” for the modelsim.ini file search precedence.

Procedure
1. Open the modelsim.ini file with a text editor.
2. Make changes to the modelsim.ini variables.
3. Save the file with an alternate name to any directory.

1394 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
The Runtime Options Dialog

4. After start up of the tool, specify the -modelsimini <ini_filepath> switch with one of the
following commands:

Table A-1. Commands for Overriding the Default Initialization File

Simulator Commands Compiler Commands Utility Commands
vsim sccom scgenmod
vcom vcover attribute
vlog vcover merge
vopt vcover ranktest
vcover report
vcover stats
vcover testnames
vdel
vdir
vgencomp
vmake

5. Refer to the <command> -modelsimini argument description for further information.

The Runtime Options Dialog

The Runtime Options dialog box writes changes to the active modelsim.ini file that affect the
current session. To access, choose Simulate > Runtime Options in the Main window. The
dialog contains three tabs - Defaults, Message Severity, and WLF Files.
If the read-only attribute for the modelsim.ini file is turned off, the changes are saved, and affect
all future sessions. Refer to Making Changes to the modelsim.ini File.

ModelSim® SE User's Manual, v10.7 1395

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
The Runtime Options Dialog

Figure A-1. Runtime Options Dialog: Defaults Tab

Table A-2. Runtime Option Dialog: Defaults Tab Contents

Option Description
Default Radix Sets the default radix for the current simulation run.
The chosen radix is used for all commands (force, examine, change are
examples) and for displayed values in the Objects, Locals, Dataflow,
Schematic, List, and Wave windows, as well as the Source window in
the source annotation view.
You can override this variable with the radix command.
Default Radix Flags Displays SystemVerilog and SystemC enums as numbers rather than
strings.
This option overrides the global setting of the default radix. You can
override this variable with add list -radixenumsymbolic.

1396 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
The Runtime Options Dialog

Table A-2. Runtime Option Dialog: Defaults Tab Contents (cont.)

Option Description
Suppress Warnings From Synopsys Packages suppresses warnings generated within the
accelerated Synopsys std_arith packages. The corresponding
modelsim.ini variable is StdArithNoWarnings.
From IEEE Numeric Std Packages suppresses warnings generated
within the accelerated numeric_std and numeric_bit packages. The
corresponding modelsim.ini variable is NumericStdNoWarnings.
Default Run Sets the default run length for the current simulation. The
corresponding modelsim.ini variable is RunLength. You can override
this variable by specifying the run command.
Iteration Limit Sets a limit on the number of deltas within the same simulation time
unit to prevent infinite looping. The corresponding modelsim.ini
variable is IterationLimit.
Default Force Type Selects the default force type for the current simulation. The
corresponding modelsim.ini variable is DefaultForceKind. You can
override this variable by specifying the force command argument
-default, -deposit, -drive, or -freeze.
Figure A-2. Runtime Options Dialog Box: Message Severity Tab

ModelSim® SE User's Manual, v10.7 1397

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
The Runtime Options Dialog

Table A-3. Runtime Option Dialog: Message Severity Tab Contents

Option Description
Immediate Assertion Selects the Verilog and VHDL immediate assertion severity level that
Break Severity will stop simulation. The corresponding modelsim.ini variable is
BreakOnAssertion.
Assertions that appear within an instantiation or configuration port
map clause conversion function will not stop the simulation regardless
of the severity level of the assertion.
No Message Display Selects the SystemVerilog concurrent assertion severity for which
For - Verilog messages will not be displayed. Multiple selections are possible.
Corresponding modelsim.ini variables are IgnoreSVAFatal,
IgnoreSVAError, IgnoreSVAWarning, and IgnoreSVAInfo.
No Message Display Selects the VHDL assertion severity for which messages will not be
For -VHDL displayed (even if break on assertion is set for that severity). Multiple
selections are possible. The corresponding modelsim.ini variables are
IgnoreFailure, IgnoreError, IgnoreWarning, and IgnoreNote.

Figure A-3. Runtime Options Dialog Box: WLF Files Tab

1398 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
The Runtime Options Dialog

Table A-4. Runtime Option Dialog: WLF Files Tab Contents

Option Description
WLF File Size Limit Limits the WLF file by size (as closely as possible) to the specified
number of megabytes. If both size and time limits are specified, the
most restrictive is used. Setting it to 0 results in no limit. The
corresponding modelsim.ini variable is WLFSizeLimit.
WLF File Time Limit Limits the WLF file by size (as closely as possible) to the specified
amount of time. If both time and size limits are specified, the most
restrictive is used. Setting it to 0 results in no limit. The corresponding
modelsim.ini variable is WLFTimeLimit.
WLF Attributes Specifies whether to compress WLF files and whether to delete the
WLF file when the simulation ends. You would typically only disable
compression for troubleshooting purposes. The corresponding
modelsim.ini variables are WLFCompress for compression and
WLFDeleteOnQuit for WLF file deletion.
Design Hierarchy Specifies whether to save all design hierarchy in the WLF file or only
regions containing logged signals. The corresponding modelsim.ini
variable is WLFSaveAllRegions.

ModelSim® SE User's Manual, v10.7 1399

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

Variables
The modelsim.ini variables are listed in order alphabetically. The following information is given
for each variable.
• A short description of how the variable functions.
• The location of the variable, by section, in the modelsim.ini file.
• The syntax for the variable.
• A listing of all values and the default value where applicable.
• Related arguments that are entered on the command line to override variable settings.
Commands entered at the command line always take precedence over modelsim.ini
settings. Not all variables have related command arguments.
• Related topics and links to further information about the variable.
AcceptLowerCasePragmaOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
AmsStandard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
AssertionCover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
AutoExclusionsDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1431
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432

1400 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433
BatchTranscriptFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
BindAtCompile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
BreakOnAssertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
CheckPlusargs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
CheckSynthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
CodeCoverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
CommandHistory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
CompilerTempDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
CoverCells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
CoverClkOptBuiltins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
CoverExcludeDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
CoverOpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
CoverREC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1459
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
CoverThreadLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
CoverWeight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467

ModelSim® SE User's Manual, v10.7 1401

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

CppOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468
CppPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
DefaultLibType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475
DefaultRadix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
DefaultRestartOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1480
DpiCppPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
EnableSVCoverpointExprVariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
EnumBaseInit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488
error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1490
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
ExtendedToggleMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
FecEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
FlatLibPageDeletePercentage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
floatfixlib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1500
ForceSigNextIter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
ForceUnsignedIntegerToVHDLInteger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502

1402 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503
FsmResetTrans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
GCThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
GenerateFormat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1509
GenerateLoopIterationMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510
GenerateRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513
GlobalSharedObjectsList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
Hazard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
IgnoreFailure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
IgnoreSVAWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
IgnoreWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
InitOutCompositeParam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
IterationLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
LargeObjectSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
MaxReportRhsSVCrossProducts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537

ModelSim® SE User's Manual, v10.7 1403

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
MaxSVCoverpointBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
MaxSVCrossBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
MessageFormatFail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
MessageFormatWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
modelsim_lib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
MsgLimitCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
MultiFileCompilationUnit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
NoCaseStaticError. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
NoRangeCheck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
NumericStdNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572

1404 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
OnFinishPendingAssert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
osvvm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
PedanticErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
RequireConfigForAllDefaultBinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
Sc22Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
ScMainFinishOnQuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
ScStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607

ModelSim® SE User's Manual, v10.7 1405

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

Show_Warning1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
Show_Warning2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
Show_Warning3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
Show_Warning4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
Show_Warning5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
SignalForceFunctionUseDefaultRadix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
SmartDbgSym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
SolveACTMaxOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
SolveACTMaxTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
SolveACTRetryCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
SolveBeforeErrorSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
SolveFailDebug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
SolveFailDebugMaxSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
SolveGraphMaxEval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
SolveIgnoreOverflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
StackTraceDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
Stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642

1406 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
StdArithNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
sv_std. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
SVCovergroupGoalDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
SVCovergroupPerInstanceDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
SVCovergroupTypeGoal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
SVCoverpointAutoBinMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
SVCoverpointWildCardBinValueSizeWarn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681

ModelSim® SE User's Manual, v10.7 1407

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

ToggleMaxRealValues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
ToggleVlogEnumBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
TranscriptFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
UnattemptedImmediateAssertions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
UVMControl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
VhdlSeparatePduPackage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
WarnConstantChange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
WildcardSizeThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
WildcardSizeThresholdVerbose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
WLFCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716

1408 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

WLFCollapseMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
WLFDeleteOnQuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
WLFFilename. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
WLFOptimize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
WLFSimCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
WLFTimeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
WrapColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
WrapWSColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731

ModelSim® SE User's Manual, v10.7 1409

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AcceptLowerCasePragmaOnly

AcceptLowerCasePragmaOnly
Section [vlog]
This variable instructs the Verilog compiler to accept only lower case pragmas in Verilog
source files.
Syntax
AcceptLowerCasePragmaOnly = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vlog -lowercasepragma.

1410 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AccessObjDebug

AccessObjDebug
Section [vsim]
This variable enables logging a VHDL access variable—both the variable value and any access
object that the variable points to during the simulation.
Syntax
AccessObjDebug = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim-accessobjdebug or
-noaccessobjdebug.
Description
Display-only names such as [10001] take on a different form, as follows:

• the initial character, @

• the name of the access type or subtype
• another @
• a unique integer N that represents the sequence number (starting with 1) of the objects of
that designated type that were created with the VHDL allocator called new.
For example: @ptr@1

By default, this variable is turned off. This means that while access variables themselves can be
logged and displayed in the various display windows, any access objects that they point to will
not be logged. The value of an access variable, which is the “name” of the access object it points
to, is suitable only for displaying, and cannot be used as a way for a command to reference it.

For example, for an access variable “v1” that designates some access object, the value of “v1”
will show as [10001]. This name cannot be used as input to any command that expects an object
name, it is for display only; but it is a unique identifier for any access object that the design may
produce. This value replaces any hexadecimal address-based 'value' that may have been
displayed in prior versions of ModelSim.

ModelSim® SE User's Manual, v10.7 1411

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AddPragmaPrefix

AddPragmaPrefix
Section [vcom], [vlog]
This variable enables recognition of synthesis and coverage pragmas with a user specified
prefix. If this argument is not specified, pragmas are treated as comments and the previously
excluded statements included in the synthesized design. All regular synthesis and coverage
pragmas are honored.
Syntax
AddPragmaPrefix = <prefix>
Arguments
• The arguments are described as follows:
o <prefix> — Specifies a user defined string where the default is no string, indicated
by quotation marks ("").

1412 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AllowCheckpointCpp

AllowCheckpointCpp
Section [vsim]
This variable enables/disables support for checkpointing foreign C++ libraries.
Syntax
AllowCheckpointCpp 1|0
Arguments
• The arguments are described as follows:
o 1 — Turn on the support.
o 0 — (default) Turn off the support.
Description
This variable may be overridden with the vsim -allowcheckpointcpp command. It is not
supported on Windows platforms.

ModelSim® SE User's Manual, v10.7 1413

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AmsStandard

AmsStandard
Section [vcom]
This variable specifies whether vcom adds the declaration of REAL_VECTOR to the
STANDARD package. This is useful for designers using VHDL-AMS to test digital parts of
their model.
Syntax
AmsStandard = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom {-amsstd | -noamsstd}.
Related Topics
vcom [ModelSim SE Command Reference Manual]
Setting Environment Variables

1414 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AppendClose

AppendClose
Section [vsim]
This variable immediately closes files previously opened in the APPEND mode as soon as there
is either an explicit call to file_close, or when the file variable's scope is closed. You can
override this variable by specifying vsim -noappendclose at the command line.
Syntax
AppendClose = {0 | 1}
Arguments
• The arguments are described as follows:
o 0
Off
o 1
(default) On
When set to zero, the simulator will not immediately close files opened in the
APPEND mode. Subsequent calls to file_open in APPEND mode will therefore not
require operating system interaction, resulting in faster performance. If your designs
rely on files to be closed and completely written to disk following calls to file_close,
because they perform operations on the files outside the simulation, this
enhancement could adversely impact those operations. In those situations, turning
this variable on is not recommended.

ModelSim® SE User's Manual, v10.7 1415

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertFile

AssertFile
Section [vsim]
This variable specifies an alternative file for storing VHDL/PSL/SVA assertion messages.
Syntax
AssertFile = <filename>
Arguments
• The arguments are described as follows:
o <filename> — Any valid file name containing assertion messages, where the default
name is assert.log.
You can override this variable by specifying vsim-assertfile.
Description
By default, assertion messages are output to the file specified by the TranscriptFile variable in
the modelsim.ini file. If the AssertFile variable is specified, all assertion messages will be stored
in the specified file, not in the transcript.

Related Topics
TranscriptFile
Creating a Transcript File

1416 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionActiveThreadMonitor

AssertionActiveThreadMonitor
Section [vsim]
This variable enables tracking of currently active assertion threads for a given instance.
Syntax
AssertionActiveThreadMonitor = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Tracking is disabled.
o 1 — (default) Tracking is enabled.
Related Topics
Using the Assertion Active Thread Monitor

ModelSim® SE User's Manual, v10.7 1417

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionActiveThreadMonitorLimit

AssertionActiveThreadMonitorLimit
Section [vsim]
This variable limits the number of active assertion threads displayed for a given instance.
Syntax
AssertionActiveThreadMonitorLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer, where 5 is the default.
Related Topics
Using the Assertion Active Thread Monitor

1418 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionCover

AssertionCover
Section [vsim]
This variable enables extended count information for assertions.
Syntax
AssertionCover = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -assertcounts or -noassertcounts at the
command line.
Note
The vsim -assertcounts and -noasssertcounts arguments were formerly named
-assertcover and -noassertcover. The -assertcover and -noassertcover arguments are
still supported, but their use is deprecated.

ModelSim® SE User's Manual, v10.7 1419

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionDebug

AssertionDebug
Section [vsim]
This variable specifies that assertion passes are reported and enables debug options such as
assertion thread viewing (ATV), HDL failed expression analysis, extended count information,
and causality traceback.
Syntax
AssertionDebug = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -assertdebug or -noassertdebug at
the command line.
Related Topics
Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window

1420 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionEnable

AssertionEnable
Section [vsim]
This variable enables VHDL/PSL/SVA assertions.
Syntax
AssertionEnable = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying assertion enable -off.
Passes and failures cannot be enabled or disabled independently. So if
AssertionEnable is used, both passes and failures are enabled or disabled.

ModelSim® SE User's Manual, v10.7 1421

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionEnableVacuousPassActionBlock

AssertionEnableVacuousPassActionBlock
Section [vsim]
This variable enables execution of assertion pass actions for vacuous passes in action blocks.
Syntax
AssertionEnableVacuousPassActionBlock = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You may override this variable, when it is turned on (1), by specifying assertion
action
-actionblock vacuousoff.

1422 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionFailAction

AssertionFailAction
Section [vsim]
This variable sets an action for a PSL/SVA failure event.
Syntax
AssertionFailAction = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — (default) Continue
o 1 — Break
o 2 — Exit
You can override this variable by specifying assertion fail -action.

ModelSim® SE User's Manual, v10.7 1423

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionFailLocalVarLog

AssertionFailLocalVarLog
Section [vsim]
This variable prints SVA concurrent assertion local variable values corresponding to failed
assertion threads when you run vsim -assertdebug.
Syntax
AssertionFailLocalVarLog = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying assertion fail -lvlog.

1424 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionFailLog

AssertionFailLog
Section [vsim]
This variable enables transcript logging for PSL assertion failure events.
Syntax
AssertionFailLog = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying assertion fail -log.

ModelSim® SE User's Manual, v10.7 1425

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionLimit

AssertionLimit
Section [vsim]
This variable sets a limit for the number of times ModelSim responds to a VHDL/PSL/SVA
assertion failure event. ModelSim disables an assertion after reaching the limit.
Syntax
AssertionLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is -1 (unlimited).
You can override this variable by specifying assertion fail -limit.

1426 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionPassLog

AssertionPassLog
Section [vsim]
This variable enables logging of SystemVerilog and PSL assertion pass events.
Syntax
AssertionPassLog = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying assertion pass -log.

ModelSim® SE User's Manual, v10.7 1427

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AssertionThreadLimit

AssertionThreadLimit
Section [vsim]
This variable sets a limit on the number of threads logged for each assertion. If the number of
threads logged for an assert directive exceeds the limit, the assertion is either killed or switched
off as specified by the AssertionThreadLimitAction variable.
Syntax
AssertionThreadLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is -1 (unlimited hits)
Related Topics
AssertionThreadLimitAction

1428 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AssertionThreadLimitAction

AssertionThreadLimitAction
Section [vsim]
This variable controls the action taken once the assert limit set by the AssertionThreadLimit
variable has been reached.
Syntax
AssertionThreadLimitAction = {kill | off}
Arguments
• The arguments are described as follows:
o kill — (default) All existing threads for an assertion are terminated and no new
instances of the assertion are started.
o off — All current assertions and threads are kept but no new instances of the
assertion are started. Existing instances of the assertion continue to be evaluated and
generate threads.
Related Topics
AssertionThreadLimit
assertion enable [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1429

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ATVStartTimeKeepCount

ATVStartTimeKeepCount
Section [vsim]
This variable controls how many thread start times will be preserved for ATV viewing for a
given assertion instance.
Syntax
ATVStartTimeKeepCount = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative number where the default is -1 (all).

1430 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
AutoExclusionsDisable

AutoExclusionsDisable
Section [vsim]
This variable is used to control automatic code coverage exclusions. By default, assertions and
FSMs are excluded from the code coverage. For FSMs, all transitions to and from excluded
states are also automatically excluded. When “all” is selected, code coverage is enabled for both
assertions and FSMs.
Syntax
AutoExclusionsDisable = {assertions | fsm | all}
Arguments
• The arguments are described as follows:
o assertions — Enable code coverage for assertions.
o fsm — Enable code coverage for FSMs.
o all — Enable code coverage for all automatic exclusions.
To enable multiple values, use a comma or space separated list.
You can override this variable by specifying vsim -autoexclusionsdisable.

ModelSim® SE User's Manual, v10.7 1431

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
AutoLibMapping

AutoLibMapping
Section [Library]
Automatically perform logical-to-physical mapping for physical libraries that appear in -L/-Lf
options with file system path delimiters (for example, '.' or '/'). The tail of the file system path
name will be the logical library name.
Syntax
AutoLibMapping = {0 | 1}
Arguments
• The arguments are:
0 — (default) Off
1 — On
Examples
In the command:

vopt -L ./path/to/lib1 -o opttop top

vopt automatically performs the mapping:

lib1 -> ./path/to/lib1.

This implicit mapping will occur as long as there is no other logical library present with a
matching name (lib1 in this case). Any implicit mapping which does not occur for any reason is
flagged with a suppressible “Note.”

1432 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
BatchMode

BatchMode
Section [vsim]
This variable runs batch (non-GUI) simulations. The simulations are executed via scripted files
from a Windows command prompt or UNIX terminal and do not provide for interaction with
the design during simulation. The BatchMode variable will be ignored if you use the -batch, -c,
-gui, or -i options to vsim. Refer to BatchMode for more information about running batch
simulations.
Syntax
BatchMode = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Runs the simulator in interactive mode. Refer to vsim -i for more
information.
o 1 — Enables batch simulation mode.
You can also enable batch mode by specifying vsim -batch.
Related Topics
Batch Mode
BatchTranscriptFile
TranscriptFile
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1433

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
BatchTranscriptFile

BatchTranscriptFile
Section [vsim]
This variable enables automatic creation of a transcript file when the simulator runs in batch
mode. All transcript data is sent to stdout when this variable is disabled and the simulator is run
in batch mode (BatchMode = 1, or vsim -batch).
Syntax
BatchTranscriptFile = <filename>
Arguments
• The arguments are described as follows:
o <filename> — Any string representing a valid filename where the default is
transcript.
You can override this variable by specifying vsim -logfile <filename>, vsim -nolog.
Related Topics
Batch Mode
BatchMode
TranscriptFile
transcript file [ModelSim SE Command Reference Manual]
vsim [ModelSim SE Command Reference Manual]

1434 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
BindAtCompile

BindAtCompile
Section [vcom]
This variable instructs ModelSim to perform VHDL default binding at compile time rather than
load time.
Syntax
BindAtCompile = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom {-bindAtCompile |
-bindAtLoad}.
Related Topics
Default Binding
RequireConfigForAllDefaultBinding

ModelSim® SE User's Manual, v10.7 1435

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
BreakOnAssertion

BreakOnAssertion
Section [vsim]
This variable stops the simulator when the severity of a VHDL assertion message or a
SystemVerilog severity system task is equal to or higher than the value set for the variable.
Syntax
BreakOnAssertion = {0 | 1 | 2 | 3 | 4}
Arguments
• The arguments are described as follows:
o 0 — Note
o 1 — Warning
o 2 — Error
o 3 — (default) Failure
o 4 — Fatal
Related Topics
The Runtime Options Dialog
Tcl Command Syntax

1436 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CheckPlusargs

CheckPlusargs
Section [vsim]
This variable defines the simulator’s behavior when encountering unrecognized plusargs. The
simulator checks the syntax of all system-defined plusargs to ensure they conform to the syntax
defined in the Reference Manual. By default, the simulator does not check syntax or issue
warnings for unrecognized plusargs (including accidentally misspelled, system-defined
plusargs), because there is no way to distinguish them from a user-defined plusarg.
Syntax
CheckPlusargs = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — (default) Ignore
o 1 — Issues a warning and simulates while ignoring.
o 2 — Issues an error and exits.

ModelSim® SE User's Manual, v10.7 1437

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CheckpointCompressMode

CheckpointCompressMode
Section [vsim]
This variable specifies that checkpoint files are written in compressed format.
Syntax
CheckpointCompressMode = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Related Topics
set Command Syntax

1438 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CheckSynthesis

CheckSynthesis
Section [vcom]
This variable turns on limited synthesis rule compliance checking, which includes checking
only signals used (read) by a process and understanding only combinational logic, not clocked
logic.
Syntax
CheckSynthesis = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -check_synthesis.

ModelSim® SE User's Manual, v10.7 1439

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ClassDebug

ClassDebug
Section [vsim]
This variable enables visibility into and tracking of class instances.
Syntax
ClassDebug = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -classdebug.

1440 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CodeCoverage

CodeCoverage
Section [vsim]
This variable enables code coverage.
Syntax
CodeCoverage = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1441

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CommandHistory

CommandHistory
Section [vsim]
This variable specifies the name of a file in which to store the Main window command history.
Syntax
CommandHistory = <filename>
Arguments
• The arguments are described as follows:
o <filename> — Any string representing a valid filename where the default is
cmdhist.log.
The default setting for this variable is to comment it out with a semicolon ( ; ).

1442 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CompilerTempDir

CompilerTempDir
Section [vcom]
This variable specifies a directory for compiler temporary files instead of “work/_temp.”
Syntax
CompilerTempDir = <directory>
Arguments
• The arguments are described as follows:
o <directory> — Any user defined directory where the default is work/_temp.

ModelSim® SE User's Manual, v10.7 1443

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ConcurrentFileLimit

ConcurrentFileLimit
Section [vsim]
This variable controls the number of VHDL files open concurrently. This number should be less
than the current limit setting for maximum file descriptors.
Syntax
ConcurrentFileLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where 0 is unlimited and 40 is the default.
Related Topics
Syntax for File Declaration

1444 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Coverage

Coverage
Section [vcom], [vlog]
This variable enables coverage statistic collection.
Syntax
Coverage = {0 | s | b | c| e | f | t}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o s — statement
o b— branch
o c — condition
o e — expression
o f — fsm
o t — toggle

ModelSim® SE User's Manual, v10.7 1445

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverAtLeast

CoverAtLeast
Section [vsim]
This variable specifies the minimum number of times a functional coverage directive must
evaluate to true.
Syntax
CoverAtLeast = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 1.

1446 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverCells

CoverCells
Section [vlog]
This variable enables code coverage of Verilog modules defined by `celldefine and
`endcelldefine compiler directives.
Syntax
CoverCells = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vlog or vopt {-covercells
|-nocovercells}.
Related Topics
Verilog-XL Compatible Compiler Arguments

ModelSim® SE User's Manual, v10.7 1447

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverClkOptBuiltins

CoverClkOptBuiltins
Section [vcom]
This variable enables clock optimization builtins for code coverage. When these clock
optimizations are enabled, some branches of VHDL code may be excluded from code coverage,
and given a code of ECOP (when not hit).
Syntax
CoverClkOptBuiltins = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Description
Refer to“Missing Branches in VHDL and Clock Optimizations” for more details.

1448 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverConstruct

CoverConstruct
Section [vopt]
This variable controls the set of HDL cover constructs that will be considered for coverage
collection.
Syntax
CoverConstruct = <argument>
Arguments
• bind, cafif, cafcase, cdcase, cicl, cifl, citf, cpkg, cpm, cprc, csva, ctes, fsmqs, fsmqs, fsmup,
tce, tcint, tcpmda, tcua, tcuu, tcpu
The arguments listed here are mnemonics for particular HDL code constructs. The list is not
comprehensive and can include other options. The default for each mnemonic is “on.” To
turn the construct off, place “no” before the mnemonic: as in nofsmup.
Description
Cover constructs are a comma-separated list of mnemonics that designate particular HDL code
constructs that may be instrumented for coverage collection. The CoverConstruct modelsim.ini
variable may be overridden with the vopt -coverconstruct command.

Examples
Cover constructs are named by mnemonic abbreviations. For example, the CoverConstruct
“condition coverage inside a task or function” is abbreviated with the mnemonic “citf”, and the
coverage of packages is "cpkg". Both mnemonics are designated with the CoverConstruct
variable as follows:

CoverConstruct citf, cpkg

Use the “no” prefix to turn off a code construct.

CoverConstruct nocpkg

Related Topics
CoverMode
Code Coverage Modes
Coverconstructs

ModelSim® SE User's Manual, v10.7 1449

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverDeglitchOn

CoverDeglitchOn
Section [vcom], [vlog]
This variable enables deglitching of statement, branch, condition, and expression code coverage
in combinatorial, non-clocked processes.
Syntax
CoverDeglitchOn = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1450 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverDeglitchPeriod

CoverDeglitchPeriod
Section [vcom], [vlog]
This variable controls the period of statement, branch, condition, and expression code coverage
deglitching in combinatorial, non-clocked processes. If a process is entered more than once
during any period of length <period>, only the last execution during that period will be added
into the coverage data for that process. For a new pass to be counted, it must occur at a time
greater than the previous pass plus the deglitch period.
Syntax
CoverDeglitchPeriod = {“<n> <time_unit>”}
Arguments
• The arguments are described as follows:
o <n> — A string specifying the number of time units. A value of zero ( 0 ) eliminates
delta cycle glitches: only the last delta cycle pass will be counted toward the
coverage data.
o <time_unit> — (required if “n” is anything other than “0”) fs, ps, ns, us, ms, or sec.
You must surround n <time_unit> with quotation marks (“ “) when you put a space
between “n” and <time_unit>.

ModelSim® SE User's Manual, v10.7 1451

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverEnable

CoverEnable
Section [vsim]
This variable specifies that all PSL/SVA coverage directives in the current simulation are
enabled.
Syntax
CoverEnable = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1452 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverExcludeDefault

CoverExcludeDefault
Sections [vcom], [vlog]
This variable excludes VHDL code coverage data collection from the OTHERS branch in both
Case statements and Selected Signal Assignment statements.
Syntax
CoverExcludeDefault = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1453

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverFEC

CoverFEC
Sections [vcom], [vlog]
This variable controls the collection of code coverage for focused expression and condition
coverage statistics.
Syntax
CoverFEC = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom, vlog, or vopt -coverfec.

1454 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverLimit

CoverLimit
Section [vsim]
This variable specifies the number of cover directive hits before the directive is auto disabled.
Syntax
CoverLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is -1 (unlimited hits).

ModelSim® SE User's Manual, v10.7 1455

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverLog

CoverLog
Section [vsim]
This variable enables transcript logging for functional coverage directive messages.
Syntax
CoverLog = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off (default)
o 1 — On

1456 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverMode

CoverMode
Section [vopt]
This variable controls the set of cover constructs that are being considered for coverage
collection.
Syntax
CoverMode = <argument>
Arguments
• full, default, set1, set2, fast
The default CoverMode set (the current behavior) is default. Other CoverModes – full, set1,
set2, and fast – differ from the default CoverMode and are essentially synonyms for sets of
enabled CoverConstructs. You can think of CoverMode as a shortcut for a specific list of
CoverConstruct mnemonics.
Description
The CoverMode modelsim.ini variable may be overridden with the vopt -covermode command.

Related Topics
CoverConstruct
Code Coverage Modes
Covermodes

ModelSim® SE User's Manual, v10.7 1457

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverOpt

CoverOpt
Section [vcom], [vlog]
This variable controls the default level of optimizations for compilations with code coverage.
Syntax
CoverOpt = {1 | 2 | 3 | 4 | 5}
Arguments
• The arguments are described as follows:
o 1 — Turns off all optimizations that affect coverage reports.
o 2 — Allows optimizations that provide large performance improvements by
invoking sequential processes only when the data changes. This setting may result in
major reductions in coverage counts.
o 3 — (default) Allows all optimizations in 2, and allows optimizations that may
remove some statements. Also allows constant propagation and VHDL subprogram
inlining.
o 4 — Allows all optimizations in 2 and 3, and allows optimizations that may remove
major regions of code by changing assignments to built-ins or removing unused
signals. It also changes Verilog gates to continuous assignments and optimizes
Verilog expressions. Allows VHDL subprogram inlining. Allows VHDL flip-flop
recognition.
o 5 — Allows all optimizations in 2-4 and activates code coverage for Verilog merged
always blocks, merged initialization blocks, merged final blocks, and merged if
statements.
You can override this variable by specifying the vcom, vlog, or vopt command with
the -coveropt argument.

Note
If fsm coverage is turned on, optimizations are forced to level 3 and conversion
of primitives to continuous assigns is turned off.

Related Topics
vlog [ModelSim SE Command Reference Manual]

1458 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverREC

CoverREC
Sections [vcom], [vlog]
This variable controls the collection of code coverage for rapid expression and condition
coverage statistics. Disabling (0) REC collection converts non-masking conditions in FEC
tables to matching input patterns.
Syntax
CoverREC = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vcom, vlog, or vopt -nocoverrec.
Description
Refer to Legacy FEC Reporting for more information on the new REC-style reports vs. old style
FEC reports.

ModelSim® SE User's Manual, v10.7 1459

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverRespectHandL

CoverRespectHandL
Section: [vcom]
This variable specifies whether you want the VHDL 'H' and 'L' input values on conditions and
expressions to be automatically converted to ‘1’ and ‘0’, respectively.
Syntax
CoverRespectHandL = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — On.
o 1 — (default) Off. H and L values are not automatically converted.
If you are not using 'H' and 'L' values you can:
• Change your VHDL expressions of the form (a = '1') to (to_x01(a) = '1') or to
std_match(a,'1').
• Override this variable by specifying vcom -nocoverrespecthandl.

1460 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverReportCancelled

CoverReportCancelled
This variable Enables code coverage reporting of branch conditions that have been optimized
away due to a static or null condition. The line of code is labeled EA in the Source Window and
EBCS in the hits column in a Coverage Report.
Syntax
CoverReportCancelled = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Do not report code that has been optimized away.
o 1 — Enable code coverage reporting of code that has been optimized away.

ModelSim® SE User's Manual, v10.7 1461

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverShortCircuit

CoverShortCircuit
Sections [vcom], [vlog]
This variable enables short-circuiting of expressions when coverage is enabled.
Syntax
CoverShortCircuit = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying either the vcom or vlog command with
the -nocovershort argument.

1462 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverSub

CoverSub
Section [vcom]
This variable controls the collection of code coverage statistics in VHDL subprograms.
Syntax
CoverSub = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1463

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverThreadLimit

CoverThreadLimit
Section [vsim]
This variable sets a limit on the number of threads logged for each cover directive. If the
number of threads logged for a cover directive exceeds the limit, the assertion is either killed or
switched off as specified by the CoverThreadLimitAction variable.
Syntax
CoverThreadLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is -1 (unlimited hits)
Related Topics
CoverThreadLimitAction

1464 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverThreadLimitAction

CoverThreadLimitAction
Section [vsim]
This variable controls the action taken once the cover directive limit set by the
CoverThreadLimit variable has been reached.
Syntax
AssertionThreadLimitAction = {kill | off}
Arguments
• The arguments are described as follows:
o kill — (default) All existing threads for an assertion are terminated and no new
instances of the assertion are started.
o off — All current assertions and threads are kept but no new instances of the
assertion are started. Existing instances of the assertion continue to be evaluated and
generate threads.
Related Topics
CoverThreadLimit
assertion enable [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1465

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CoverWeight

CoverWeight
Section [vsim]
This variable specifies the relative weighting for functional coverage directives.
Syntax
CoverWeight = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer, where the default is 1.

1466 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CppInstall

CppInstall
This variable specifies the version of the desired GNU compiler supported and distributed by
ModelSim, such as with the entry:
Syntax
CppInstall = <(gcc|g++) version>
Arguments
• The arguments are described as follows:
o <version> — Any version of a GNU compiler that is supported and distributed with
ModelSim. See Supported Platforms and Compiler Versions for details.
Description
CppInstall = 4.5.0
Use this variable to set an alternate GNU compiler, other than the default one.

ModelSim® SE User's Manual, v10.7 1467

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CppOptions

CppOptions
Section [sccom]
This variable adds any specified C++ compiler options to the sccom command line at the time
of invocation.
Syntax
CppOptions = <options>
Arguments
• The arguments are described as follows:
o <options> — Any normal C++ compiler options where the default is -g (enable
source debugging).
You turn this variable off by commenting the variable line in the modelsim.ini file.
Related Topics
sccom [ModelSim SE Command Reference Manual]

1468 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CppPath

CppPath
This variable should point directly to the location of the g++ executable, such as:
Syntax
CppPath = <path>
Arguments
• The arguments are described as follows:
o <path> — The path to the g++ executable.
Description
CppPath = /usr/bin/g+

This variable is not required when running SystemC designs. By default, you should install and
use the built-in g++ compiler that comes with ModelSim.

ModelSim® SE User's Manual, v10.7 1469

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CreateDirForFileAccess

CreateDirForFileAccess
Section [vsim]
This variable controls whether the Verilog system task $fopen or vpi_mcd_open() will create a
non-existent directory when opening a file in append (a), or write (w) modes.
Syntax
CreateDirForFileAccess = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
New Directory Path With $fopen

1470 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CreateLib

CreateLib
Section [vcom], [vlog], [vopt]
This variable enables automatic creation of missing work libraries.
Syntax
CreateLib = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Description
You can use the -nocreatelib option for the vcom, vlog, or vopt commands to override this
variable and stop automatic creation of missing work libraries (which reverts back to the 10.3x
and earlier version behavior).

ModelSim® SE User's Manual, v10.7 1471

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
CvgZWNoCollect

CvgZWNoCollect
Section [vsim]
This variable controls coverage collection for any coverage item (coverpoint, cross, or the entire
covergroup) when 0 is assigned as its option.weight.
Syntax
CvgZWNoCollect = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Collect coverage data for zero-weight coverage items as normal.
o 1 — On. Disables collection of coverage data for the zero-weight coverage item.
Zero-weight coverage items will not be displayed in any coverage report or
contribute to any coverage score computation.
You can override this variable with the -cvgzwnocollect argument to vsim

1472 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DatasetSeparator

DatasetSeparator
Section [vsim]
This variable specifies the dataset separator for fully-rooted contexts, for example:
Syntax
DatasetSeparator = <character>
Arguments
• The arguments are described as follows:
o <character> — Any character except special characters, such as backslash (\),
brackets ({}), and so forth, where the default is a colon ( : ).
Description
sim:/top

The variable for DatasetSeparator must not be the same character as the PathSeparator variable,
or the SignalSpyPathSeparator variable.

ModelSim® SE User's Manual, v10.7 1473

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
DefaultForceKind

DefaultForceKind
Section [vsim]
This variable defines the kind of force used when not otherwise specified.
Syntax
DefaultForceKind = {default | deposit | drive | freeze}
Arguments
• The arguments are described as follows:
o default — Uses the signal kind to determine the force kind.
o deposit — Sets the object to the specified value.
o drive — Default for resolved signals.
o freeze — Default for unresolved signals.
You can override this variable by specifying force {-default | -deposit | -drive |
-freeze}.
Related Topics
The Runtime Options Dialog
set Command Syntax

1474 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DefaultLibType

DefaultLibType
Section [utils]
This variable determines the default type for a library created with the vlib command.
Syntax
DefaultLibType = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 - legacy library using subdirectories for design units
o 1 - archive library (deprecated)
o 2 - (default) flat library
Related Topics
vlib [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1475

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
DefaultRadix

DefaultRadix
Section [vsim]
This variable allows a numeric radix to be specified as a name or number. For example, you can
specify binary as “binary” or “2” or octal as “octal” or “8”.
Usage
DefaultRadix = {ascii | binary | decimal | hexadecimal | octal | symbolic | unsigned}
Arguments
• The arguments are described as follows:
o ascii — Display values in 8-bit character encoding.
o binary— Display values in binary format. You can also specify 2.
o decimal or 10 — Display values in decimal format. You can also specify 10.
o hexadecimal— (default) Display values in hexadecimal format. You can also
specify 16.
o octal — Display values in octal format. You can also specify 8.
o symbolic — Display values in a form closest to their natural format.
o unsigned — Display values in unsigned decimal format.
You can override this variable by specifying radix {ascii | binary | decimal |
hexadecimal | octal | symbolic | unsigned}, or by using the -default_radix switch
with the vsim command.
Related Topics
Changing Radix (base) for the Wave Window
The Runtime Options Dialog
set Command Syntax

1476 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DefaultRadixFlags

DefaultRadixFlags
Section [vsim]
This variable controls the display of enumeric radices.
Syntax
DefaultRadixFlags = {" " | enumnumeric | enumsymbolic | showbase | showverbose | wreal}
Arguments
• You can specify the following arguments for this variable:
o No argument. — Format enums symbolically.
o enumnumeric — Display enums in numeric format.
o enumsybmolic — Display enums in symbolic format.
o showbase — (default) Display enums showing the number of bits of the vector and
the radix that was used where:
binary = b
decimal = d
hexadecimal = h
ASCII = a
time = t
For example, instead of simply displaying a vector value of “31”, a value of
“16’h31” may be displayed to show that the vector is 16 bits wide, with a
hexadecimal radix.
o showverbose — Display enums with verbose information enabled.
You can override this argument with the radix command.
o wreal — Display internal values of real numbers that are determined to be not-a-
number (NaN) as X or Z instead of as "nan." If the internal value of NaN matches
`wrealZState, then a 'Z' will be displayed; otherwise, an 'X' will be displayed.
This affects all windows and commands that display or return simulation values and
is disabled by default. You can override this argument with the radix command.

ModelSim® SE User's Manual, v10.7 1477

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
DefaultRestartOptions

DefaultRestartOptions
Section [vsim]
This variable sets the default behavior for the restart command.
Syntax
DefaultRestartOptions = {-force | -noassertions | -nobreakpoint | -nofcovers | -nolist | -nolog |
-nowave}
Arguments
• The arguments are described as follows:
o -force — Restart simulation without requiring confirmation in a popup window.
o -noassertions — Restart simulation without maintaining the current assert directive
configurations.
o -nobreakpoint — Restart simulation with all breakpoints removed.
o -nofcovers — Restart without maintaining the current cover directive
configurations.
o -nolist — Restart without maintaining the current List window environment.
o -nolog — Restart without maintaining the current logging environment.
o -nowave — Restart without maintaining the current Wave window environment.
o semicolon ( ; ) — Default is to prevent initiation of the variable by commenting the
variable line.
You can specify one or more value in a space separated list.
You can override this variable by specifying restart {-force | -noassertions |
-nobreakpoint | -nofcovers | -nolist | -nolog | -nowave}.
Related Topics
vsim [ModelSim SE Command Reference Manual]
Checkpointing and Restoring Simulations

1478 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DelayFileOpen

DelayFileOpen
Section [vsim]
This variable instructs ModelSim to open VHDL87 files on first read or write, else open files
when elaborated.
Syntax
DelayFileOpen = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) On
o 1 — Off
Related Topics
set Command Syntax

ModelSim® SE User's Manual, v10.7 1479

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
displaymsgmode

displaymsgmode
Section [msg_system]
This variable controls where the simulator outputs system task messages. The display system
tasks displayed with this functionality include: $display, $strobe, $monitor, $write as well as the
analogous file I/O tasks that write to STDOUT, such as $fwrite or $fdisplay.
Syntax
displaymsgmode = {both | tran | wlf}
Arguments
• The arguments are described as follows:
o both — Outputs messages to both the transcript and the WLF file.
o tran — (default) Outputs messages only to the transcript, therefore they are
unavailable in the Message Viewer.
o wlf — Outputs messages only to the WLF file/Message Viewer, therefore they are
unavailable in the transcript.
You can override this variable by specifying vsim -displaymsgmode.
Related Topics
Message Viewer Window [ModelSim SE GUI Reference Manual]

1480 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DpiCppPath

DpiCppPath
Section [vsim], [vlog]
This variable specifies an explicit location to a gcc compiler for use with automatically
generated DPI export wrappers.
Syntax
DpiCppPath = <gcc_installation_directory>/bin/gcc
Arguments
• The arguments are described as follows:
o <gcc_installation_directory> — Specifies the path to the gcc compiler. Ensure that
the argument points directly to the compiler executable.

ModelSim® SE User's Manual, v10.7 1481

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
DpiOutOfTheBlue

DpiOutOfTheBlue
Section [vsim]
This variable enables DPI out-of-the-blue Verilog function calls. It is also used to enable
debugging support for a SystemC thread. The C functions must not be declared as import tasks
or functions.
Syntax
DpiOutOfTheBlue = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — (default) Support for DPI out-of-the-blue calls is disabled.
o 1 — Support for DPI out-of-the-blue calls is enabled, but debugging support is not
available.
o 2 — Support for DPI out-of-the-blue calls is enabled with debugging support for a
SystemC thread.
To turn on debugging support in a SystemC method, set DpiOutOfTheBlue = 2 and
specify vsim -scdpidebug.
You can override this variable using vsim -dpioutoftheblue.
Related Topics
Making Verilog Function Calls from non-DPI C Models

1482 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
DumpportsCollapse

DumpportsCollapse
Section [vsim]
This variable collapses vectors (VCD id entries) in dumpports output.
Syntax
DumpportsCollapse = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim {+dumpports+collapse |
+dumpports+nocollapse}.

ModelSim® SE User's Manual, v10.7 1483

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
EmbeddedPsl

EmbeddedPsl
Sections [vcom], [vlog]
This variable enables the parsing of embedded PSL statements in VHDL files.
Syntax
EmbeddedPsl = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1484 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
EnableDpiSosCb

EnableDpiSosCb
Section [vsim]
Enables DPI export calls from the SystemC start_of_simualtion() callback.
Syntax
EnableDpiSosCb = {0 | 1}
Arguments
• The arguments are as follows:
0 — (default) Off
1 — On
You can override this variable by specifying vsim -enabledpisoscb.
Description
The side effect of this option is that any SystemC signal writes done in start_of_simulation()
callback will not reflect the updated value at time 0. Insert a delta cycle using a wait statement
in the processes to get the correct value updated for these signals. Also, with mixed language
simulation, process execution order may change at time 0 with this option.

ModelSim® SE User's Manual, v10.7 1485

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
EnableSVCoverpointExprVariable

EnableSVCoverpointExprVariable
Section [vlog]
This variable, used in conjunction with the SVCoverpointExprVariablePrefix variable, creates
variables containing the effective values of Coverpoint expressions. The current settings for
both expression variables are displayed in the Object view.
Note
You must re-compile your design after any change in the setting of either this variable, or
the SVCoverpointExprVariablePrefix variable.

Syntax
EnableSVCoverpointExprVariable = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
SVCoverpointExprVariablePrefix

1486 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
EnableTypeOf

EnableTypeOf
Section [vlog]
This variable enables support of SystemVerilog 3.1a $typeof() function. This variable has no
impact on SystemVerilog 1364-2005 designs.
Syntax
EnableTypeOf = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1487

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
EnumBaseInit

EnumBaseInit
Section [vsim]
This variable initializes enum variables in SystemVerilog using either the default value of the
base type or the leftmost value.
Syntax
EnumBaseInit= {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Initialize to leftmost value
o 1 — (default) Initialize to default value of base type

1488 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
error

error
Section [msg_system]
This variable changes the severity of the listed message numbers to “error.”
Syntax
error = <msg_number>…
Arguments
• The arguments are described as follows:
o <msg_number>… — An unlimited list of message numbers, comma separated.
You can override this variable by specifying the sccom, vcom, vlog, vopt, or vsim
command with the -error argument.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
fatal
note
suppress
warning

ModelSim® SE User's Manual, v10.7 1489

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ErrorFile

ErrorFile
Section [vsim]
This variable specifies an alternative file for storing error messages. By default, error messages
are output to the file specified by the TranscriptFile variable in the modelsim.ini file. If the
ErrorFile variable is specified, all error messages will be stored in the specified file, not in the
transcript.
Syntax
ErrorFile = <filename>
Arguments
• The arguments are described as follows:
o <filename> — Any valid filename where the default is error.log.
You can override this variable by specifying vsim -errorfile.
Related Topics
Creating a Transcript File
TranscriptFile

1490 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Explicit

Explicit
Section [vcom]
This variable enables the resolving of ambiguous function overloading in favor of the “explicit”
function declaration (not the one automatically created by the compiler for each type
declaration). Using this variable makes Questa Sim compatible with common industry practice.
Syntax
Explicit = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -explicit.

ModelSim® SE User's Manual, v10.7 1491

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ExtendedToggleMode

ExtendedToggleMode
Section [vsim]
This variable specifies one of three modes for extended toggle coverage.
Syntax
ExtendedToggleMode = {1 | 2 | 3}
Arguments
• The arguments are described as follows:
o 1 — 0L->1H & 1H->0L & any one 'Z' transition (to/from 'Z')
o 2 — 0L->1H & 1H->0L & one transition to 'Z' & one transition from 'Z'
o 3 — (default) 0L->1H & 1H->0L & all 'Z' transitions
You can override this variable by specifying -extendedtogglemode {1|2|3} to the
vcom, vlog, vopt, or toggle add commands.
Related Topics
Understanding Toggle Counts

1492 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
fatal

fatal
Section [msg_system]
This variable changes the severity of the listed message numbers to “fatal”.
Syntax
fatal = <msg_number>…
Arguments
• The arguments are described as follows:
o <msg_number>… — An unlimited list of message numbers, comma separated.
You can override this variable by specifying the sccom, vcom, vlog, vopt, or vsim
command with the -fatal argument.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
error
note
suppress
warning

ModelSim® SE User's Manual, v10.7 1493

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
FecCountLimit

FecCountLimit
Section [vsim]
This variable limits the number of counts that are tracked for Focused Expression Coverage.
Specifically, when a bin has reached the specified count, coverage will ignore further tracking
of the inputs linked to the bin.
Note
If you change this value from the default you may affect simulation performance.

Syntax
FecCountLimit = {<n> | 0 }
Arguments
• The arguments are described as follows:
o <n> — Specifies the count limit for FEC. The default is 1.
o 0 — Specifies an unlimited count

1494 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
FecEffort

FecEffort
Section [vcom], [vlog], [vopt]
This variable increases or decreases the limit on the size of FEC expressions and conditions
considered for coverage. A higher FecEffort value allows more expressions/conditions to be
considered for coverage, though as a result, the compile, optimization and simulation times may
increase.
Syntax
FecEffort = {1 | 2 | 3}
Arguments
• The arguments are described as follows:
o 1 — (low) (Default) Only small expressions or conditions considered for coverage.
o 2 — (medium) Bigger expressions/conditions considered.
o 3 — (high) Very large expressions/conditions considered.

ModelSim® SE User's Manual, v10.7 1495

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
FecUdpEffort

FecUdpEffort
Section [vcom], [vlog], [vopt]
This variable increases or decreases the limit on the size of FEC/UDP expressions and
conditions considered for coverage. A higher FecUdpEffort value allows more expressions/
conditions to be considered for coverage, though as a result, the compile, optimization and
simulation times may increase.
Syntax
FecUdpEffort = {1 | 2 | 3}
Arguments
• The arguments are described as follows:
o 1 — (low) (Default) Only small expressions or conditions considered for coverage.
o 2 — (medium) Bigger expressions/conditions considered.
o 3 — (high) Very large expressions/conditions considered.

1496 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
FlatLibPageSize

FlatLibPageSize
Section [utils]
This variable sets the size in bytes for flat library file pages. Very large libraries may benefit
from a larger value, at the expense of disk space.
Syntax
FlatLibPageSize = <value>
Arguments
• The arguments are described as follows:
o <value> — Specifies a library size in Mb where the default value is 8192.

ModelSim® SE User's Manual, v10.7 1497

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
FlatLibPageDeletePercentage

FlatLibPageDeletePercentage
Section [utils]
This variable sets the percentage of total pages deleted before library cleanup can occur. This
setting is applied together with FlatLibPageDeleteThreshold.
Syntax
FlatLibPageDeletePercentage = <value>
Arguments
• The arguments are described as follows:
o <value> — Specifies a percentage where the default value is 50.

1498 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
FlatLibPageDeleteThreshold

FlatLibPageDeleteThreshold
Section [utils]
Set the number of pages deleted before library cleanup can occur. This setting is applied
together with FlatLibPageDeletePercentage.
Syntax
FlatLibPageDeletePercentage = <value>
Arguments
• The arguments are described as follows:
o <value> — Specifies a percentage where the default value is 1000.

ModelSim® SE User's Manual, v10.7 1499

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
floatfixlib

floatfixlib
Section [library]
This variable sets the path to the library containing VHDL floating and fixed point packages.
Syntax
floatfixlib = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../floatfixlib. May
include environment variables.

1500 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ForceSigNextIter

ForceSigNextIter
Section [vsim]
This variable controls the iteration of events when a VHDL signal is forced to a value.
Syntax
ForceSigNextIter = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Update and propagate in the same iteration.
o 1 — On. Update and propagate in the next iteration.

ModelSim® SE User's Manual, v10.7 1501

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ForceUnsignedIntegerToVHDLInteger

ForceUnsignedIntegerToVHDLInteger
Section [vlog]
This variable controls whether untyped Verilog parameters in mixed-language designs that are
initialized with unsigned values between 2*31-1 and 2*32 are converted to VHDL generics of
type INTEGER or ignored. If mapped to VHDL Integers, Verilog values greater than 2*31-1
(2147483647) are mapped to negative values. Default is to map these parameter to generic of
type INTEGER.
Syntax
ForceUnsignedIntegerToVHDLInteger = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1502 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
FsmImplicitTrans

FsmImplicitTrans
Sections [vcom], [vlog]
This variable controls recognition of FSM Implicit Transitions.
Syntax
FsmImplicitTrans = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On. Enables recognition of implied same state transitions.
Related Topics
vcom [ModelSim SE Command Reference Manual]
vlog [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1503

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
FsmResetTrans

FsmResetTrans
Sections [vcom], [vlog]
This variable controls the recognition of asynchronous reset transitions in FSMs.
Syntax
FsmResetTrans = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Related Topics
vcom [ModelSim SE Command Reference Manual]
vlog [ModelSim SE Command Reference Manual]

1504 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
FsmSingle

FsmSingle
Section [vcom], [vlog]
This variable controls the recognition of FSMs with a single-bit current state variable.
Syntax
FsmSingle = { 0 | 1 }
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Related Topics
vcom [ModelSim SE Command Reference Manual]
vlog [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1505

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
FsmXAssign

FsmXAssign
Section [vlog]
This variable controls the recognition of FSMs where a current-state or next-state variable has
been assigned “X” in a case statement.
Syntax
FsmXAssign = { 0 | 1 }
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Related Topics
vlog [ModelSim SE Command Reference Manual]

1506 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
GCThreshold

GCThreshold
Section [vsim]
This variable sets the memory threshold for SystemVerilog garbage collection.
Syntax
GCThreshold = <n>
Arguments
• The arguments are described as follows:
o <n>
Any positive integer where <n> is the number of megabytes. The default is 100.
You can override this variable with the gc configure command or with vsim
-threshold.
Related Topics
Class Instance Garbage Collection
Changing the Garbage Collector Configuration
ClassDebug
Default Garbage Collector Settings

ModelSim® SE User's Manual, v10.7 1507

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
GCThresholdClassDebug

GCThresholdClassDebug
Section [vsim]
This variable sets the memory threshold for SystemVerilog garbage collection when class
debug mode is enabled with vsim -classdebug.
Syntax
GCThresholdClassDebug = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where <n> is the number of megabytes. The default is
5.
You can override this variable with the gc configure command.
Related Topics
Class Instance Garbage Collection
Changing the Garbage Collector Configuration
ClassDebug
Default Garbage Collector Settings

1508 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
GenerateFormat

GenerateFormat
Section [vsim]
This variable controls the format of the old-style VHDL for … generate statement region name
for each iteration.
Syntax
GenerateFormat = <non-quoted string>
Arguments
• The arguments are described as follows:
o <non-quoted string> — The default is %s__%d. The format of the argument must
be unquoted, and must contain the conversion codes %s and %d, in that order. This
string should not contain any uppercase or backslash (\) characters.
The %s represents the generate statement label and the %d represents the generate
parameter value at a particular iteration (this is the position number if the generate
parameter is of an enumeration type). Embedded white space is allowed (but
discouraged) while leading and trailing white space is ignored. Application of the
format must result in a unique region name over all loop iterations for a particular
immediately enclosing scope so that name lookup can function properly.
Related Topics
OldVhdlForGenNames
Naming Behavior of VHDL for Generate Blocks

ModelSim® SE User's Manual, v10.7 1509

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
GenerateLoopIterationMax

GenerateLoopIterationMax
Section [vopt]
This variable specifies the maximum number of iterations permitted for a generate loop;
restricting this permits the implementation to recognize infinite generate loops.
Syntax
GenerateLoopIterationMax = <n>
Arguments
• The arguments are described as follows:
o <n> — Any natural integer greater than or equal to 0, where the default is 100000.

1510 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
GenerateRecursionDepthMax

GenerateRecursionDepthMax
Section [vopt]
This variable specifies the maximum depth permitted for a recursive generate instantiation;
restricting this permits the implementation to recognize infinite recursions.
Syntax
GenerateRecursionDepthMax = <n>
Arguments
• The arguments are described as follows:
o <n> — Any natural integer greater than or equal to 0, where the default is 200.

ModelSim® SE User's Manual, v10.7 1511

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
GenerousIdentifierParsing

GenerousIdentifierParsing
Section [vsim]
Controls parsing of identifiers input to the simulator. If this variable is on (value = 1), either
VHDL extended identifiers or Verilog escaped identifier syntax may be used for objects of
either language kind. This provides backward compatibility with older .do files, which often
contain pure VHDL extended identifier syntax, even for escaped identifiers in Verilog design
regions.
Syntax
GenerousIdentifierParsing = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1512 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
GlobalSharedObjectList

GlobalSharedObjectList
Section [vopt]
This variable instructs ModelSim to load the specified shared objects library with global symbol
visibility. Essentially, setting this variable would be required if the SystemC top is elaborated in
vopt and is depending on the symbols from a common library being loaded with the
GlobalSharedObjectsList variable for vsim (or using vsim -gblso).
Syntax
GlobalSharedObjectList = <filename>
Arguments
• The arguments are described as follows:
o <filename> — A comma separated list of filenames.
o semicolon ( ; ) — (default) Prevents initiation of the variable by commenting the
variable line.
You can override this variable by specifying vopt -gblso.

ModelSim® SE User's Manual, v10.7 1513

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
GlobalSharedObjectsList

GlobalSharedObjectsList
Section [vsim]
This variable instructs ModelSim to load the specified PLI/FLI shared objects with global
symbol visibility. Essentially, setting this variable exports the local data and function symbols
from each shared object as global symbols so they become visible among all other shared
objects. Exported symbol names must be unique across all shared objects.
Syntax
GlobalSharedObjectsList = <filename>
Arguments
• The arguments are described as follows:
o <filename> — A comma separated list of filenames.
o semicolon ( ; ) — (default) Prevents initiation of the variable by commenting the
variable line.
You can override this variable by specifying vsim -gblso.

1514 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Hazard

Hazard
Section [vlog]
This variable turns on Verilog hazard checking (order-dependent accessing of global variables).
Syntax
Hazard = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1515

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ieee

ieee
Section [library]
This variable sets the path to the library containing IEEE and Synopsys arithmetic packages.
Syntax
ieee = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path, including environment variables where the default is
$MODEL_TECH/../ieee.

1516 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IgnoreError

IgnoreError
Section [vsim]
This variable instructs ModelSim to disable runtime error messages.
Syntax
IgnoreError = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1517

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
IgnoreFailure

IgnoreFailure
Section [vsim]
This variable instructs ModelSim to disable runtime failure messages.
Syntax
IgnoreFailure = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

1518 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IgnoreNote

IgnoreNote
Section [vsim]
This variable instructs ModelSim to disable runtime note messages.
Syntax
IgnoreNote = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1519

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
IgnorePragmaPrefix

IgnorePragmaPrefix
Section [vcom, vlog]
This variable instructs the compiler to ignore synthesis and coverage pragmas with the specified
prefix name. The affected pragmas will be treated as regular comments.
Syntax
IgnorePragmaPrefix = {<prefix> | "" }
Arguments
• The arguments are described as follows:
o <prefix> — Specifies a user defined string.
"" — (default) No string.
You can override this variable by specifying vcom -ignorepragmaprefix or vlog
-ignorepragmaprefix.

1520 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ignoreStandardRealVector

ignoreStandardRealVector
Section [vcom]
This variable instructs ModelSim to ignore the REAL_VECTOR declaration in package
STANDARD when compiling with vcom -2008. For more information refer to the
REAL_VECTOR section in Help > Technotes > vhdl2008migration technote.
Syntax
IgnoreStandardRealVector = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -ignoreStandardRealVector.

ModelSim® SE User's Manual, v10.7 1521

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
IgnoreSVAError

IgnoreSVAError
Section [vsim] [vopt]
This variable instructs ModelSim to disable SystemVerilog assertion messages for Error
severity and suppresses output of elaboration system $error tasks.
Syntax
IgnoreSVAError = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

1522 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IgnoreSVAFatal

IgnoreSVAFatal
Section [vsim] [vopt]
This variable instructs ModelSim to disable SystemVerilog assertion messages for Fatal
severity (for vsim command) and suppresses output of elaboration system $fatal tasks (for vsim
and vopt commands).
Syntax
IgnoreSVAFatal = 0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. SystemVerilog assertion messages enabled.
o 1 — On. SystemVerilog assertion messages disabled.
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1523

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
IgnoreSVAInfo

IgnoreSVAInfo
Section [vsim] [vopt]
This variable instructs ModelSim to disable SystemVerilog assertion messages for Info severity
and suppresses output of elaboration system $info tasks.
Syntax
IgnoreSVAInfo = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Info severity messages enabled.
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

1524 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IgnoreSVAWarning

IgnoreSVAWarning
Section [vsim] [vopt]
This variable instructs ModelSim to disable SystemVerilog assertion messages for Warning
severity and suppresses output of elaboration system $warning tasks.
Syntax
IgnoreSVAWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. SystemVerilog assertion messages for warning severity enabled.
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1525

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
IgnoreVitalErrors

IgnoreVitalErrors
Section [vcom]
This variable instructs ModelSim to ignore VITAL compliance checking errors.
Syntax
IgnoreVitalErrors = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Allow VITAL compliance checking errors.
o 1 — On
You can override this variable by specifying vcom -ignorevitalerrors.

1526 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IgnoreWarning

IgnoreWarning
Section [vsim]
This variable instructs ModelSim to disable runtime warning messages.
Syntax
IgnoreWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Enable runtime warning messages.
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1527

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ImmediateContinuousAssign

ImmediateContinuousAssign
Section [vsim]
This variable instructs ModelSim to run continuous assignments before other normal priority
processes that are scheduled in the same iteration. This event ordering minimizes race
differences between optimized and non-optimized designs and is the default behavior.
Syntax
ImmediateContinuousAssign = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim -noimmedca.

1528 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IncludeRecursionDepthMax

IncludeRecursionDepthMax
Section [vlog]
This variable limits the number of times an include file can be called during compilation. This
prevents cases where an include file could be called repeatedly.
Syntax
IncludeRecursionDepthMax = <n>
Arguments
• The arguments are described as follows:
o <n> — An integer that limits the number of loops. A setting of 0 would allow one
pass through before issuing an error, 1 would allow two passes, and so on.

ModelSim® SE User's Manual, v10.7 1529

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
InitOutCompositeParam

InitOutCompositeParam
Section [vcom]
This variable controls how subprogram output parameters of array and record types are treated.
Syntax
InitOutCompositeParam = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — Use the default for the language version being compiled.
o 1 — (default) Always initialize the output parameter to its default or “left” value
immediately upon entry into the subprogram.
o 2 — Do not initialize the output parameter.
You can override this variable by specifying vcom or vopt -initoutcompositeparam.

1530 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
IterationLimit

IterationLimit
Section [vlog], [vsim]
This variable specifies a limit on simulation kernel iterations allowed without advancing time.
Syntax
IterationLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 10000000.
Related Topics
The Runtime Options Dialog
set Command Syntax

ModelSim® SE User's Manual, v10.7 1531

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
LargeObjectSilent

LargeObjectSilent
Section [vsim]
This variable controls whether “large object” warning messages are issued or not. Warning
messages are issued when the limit specified in the variable LargeObjectSize is reached.
Syntax
LargeObjectSilent = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) On
o 1 — Off

1532 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
LargeObjectSize

LargeObjectSize
Section [vsim]
This variable specifies the relative size of log, wave, or list objects in bytes that will trigger
“large object” messages. This size value is an approximation of the number of bytes needed to
store the value of the object before compression and optimization.
Syntax
LargeObjectSize = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 500000 bytes.

ModelSim® SE User's Manual, v10.7 1533

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
LibrarySearchPath

LibrarySearchPath
Section [vlog, vsim]
This variable specifies the location of one or more resource libraries containing a precompiled
package. The behavior of this variable is identical to specifying the -L <libname> command
line option with vlog or vsim.
Syntax
LibrarySearchPath = <variable> | <path/lib> ...
Arguments
• The arguments are described as follows:
o <variable>— Any library variable where the default is:
LibrarySearchPath = mtiAvm mtiOvm mtiUvm mtiUPF infact

o path/lib — Any valid library path. May include environment variables.

Multiple library paths and variables are specified as a space separated list.
You can use the vsim -showlibsearchpath option to return all libraries specified by
the LibrarySearchPath variable. You can use the vsim -ignoreinilibs to prevent vsim
from using the libraries specified in LibrarySearchPath.
Related Topics
Verilog Resource Libraries
VHDL Resource Libraries
vlog [ModelSim SE Command Reference Manual]
vsim [ModelSim SE Command Reference Manual]

1534 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
License

License
Section [vsim]
This variable controls the license file search.
Usage
License = <license_option>
Arguments
• The arguments are described as follows:
o <license_option> — One or more license options separated by spaces where the
default is to search all licenses.
Table A-5. License Variable: License Options
license_option Description
lnlonly check out msimhdlsim license only
mixedonly check out msimhdlsim/msimhdlmix licenses only
nolnl exclude msimhdlsim license
nomix exclude msimhdlmix license
noqueue do not wait in license queue if no licenses are available
noslvhdl exclude qhsimvh license
noslvlog exclude qhsimvl license
plus check out PLUS (VHDL and Verilog) license
immediately after invocation
vlog check out VLOG license immediately after invocation
vhdl check out VHDL license immediately after invocation

You can override this variable by specifying vsim <license_option>.

ModelSim® SE User's Manual, v10.7 1535

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MaxReportRhsCrossProducts

MaxReportRhsCrossProducts
Section [vsim]
This variable specifies a maximum limit for the number of Cross (bin) products reported against
a Cross when a XML or UCDB report is generated. The warning is issued if the limit is crossed.
Syntax
MaxReportRhsCrossProducts = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 0.

1536 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MaxReportRhsSVCrossProducts

MaxReportRhsSVCrossProducts
Section [vsim]
This variable limits the number of “bin_rhs” values associated with cross bins in the XML
version of the coverage report for a SystemVerilog design. It also limits the values saved to a
UCDB.
Syntax
MaxReportRhsSVCrossProducts = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 0.

ModelSim® SE User's Manual, v10.7 1537

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MaxSVCoverpointBinsDesign

MaxSVCoverpointBinsDesign
Section [vsim]
This variable limits the maximum number of Coverpoint bins allowed in the whole design.
Syntax
MaxSVCoverpointBinsDesign = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 2147483648.

1538 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MaxSVCoverpointBinsInst

MaxSVCoverpointBinsInst
Section [vsim]
This variable limits the maximum number of Coverpoint bins allowed in any instance of a
Covergroup.
Syntax
MaxSVCoverpointBinsInst = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 2147483648.

ModelSim® SE User's Manual, v10.7 1539

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MaxSVCrossBinsDesign

MaxSVCrossBinsDesign
Section [vsim]
This variable issues a warning when the number of Coverpoint bins in the design exceeds the
value specified by <n>.
Syntax
MaxSVCrossBinsDesign = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 2147483648.

1540 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MaxSVCrossBinsInst

MaxSVCrossBinsInst
Section [vsim]
This variable issues a warning when the number of Coverpoint bins in any instance of a
Covergroup exceeds the value specified by <n>.
Syntax
MaxSVCrossBinsInst = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 2147483648.

ModelSim® SE User's Manual, v10.7 1541

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MessageFormat

MessageFormat
Section [vsim]
This variable defines the format of VHDL/PSL/SVA assertion messages as well as normal error
messages.
Syntax
MessageFormat = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D%I\n.

Table A-6. MessageFormat Variable: Accepted Values

Variable Description
%S severity level
%R report message
%T time of assertion
%D delta
%I instance or region pathname (if available)
%i instance pathname with process
%O process name
%K kind of object path points to; returns Instance, Signal,
Process, or Unknown
%P instance or region path without leaf process
%F file
%L line number of assertion, or if from subprogram, line from
which call is made
%u Design unit name in form: library.primary. Returns
<protected> if the design unit is protected.
%U Design unit name in form: library.primary(secondary).
Returns <protected> if the design unit is protected.
%% print ’%’ character

1542 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MessageFormatBreak

MessageFormatBreak
Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA assertions that trigger a
breakpoint.
Syntax
MessageFormatBreak = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D %K: %i File: %F\n

ModelSim® SE User's Manual, v10.7 1543

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MessageFormatBreakLine

MessageFormatBreakLine
Section [vsim]Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA assertions that trigger a
breakpoint.
Syntax
MessageFormatBreakLine = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D %K: %i File: %F Line: %L\n

%L specifies the line number of the assertion or, if the breakpoint is from a
subprogram, the line from which the call is made.

1544 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MessageFormatError

MessageFormatError
Section [vsim]
This variable defines the format of all error messages. If undefined, MessageFormat is used
unless the error causes a breakpoint in which case MessageFormatBreak is used.
Syntax
MessageFormatError = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D %K: %i File: %F\n

Related Topics
MessageFormatBreak

ModelSim® SE User's Manual, v10.7 1545

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MessageFormatFail

MessageFormatFail
Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA Fail assertions.
Syntax
MessageFormatFail = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D %K: %i File: %F\n

Description
If undefined, MessageFormat is used unless assertion causes a breakpoint in which case
MessageFormatBreak is used.

Related Topics
MessageFormatBreak

1546 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MessageFormatFatal

MessageFormatFatal
Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA Fatal assertions.
Syntax
MessageFormatFatal = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D %K: %i File: %F\n

Description
If undefined, MessageFormat is used unless assertion causes a breakpoint in which case
MessageFormatBreak is used.

Related Topics
MessageFormatBreak

ModelSim® SE User's Manual, v10.7 1547

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MessageFormatNote

MessageFormatNote
Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA Note assertions.
Syntax
MessageFormatNote = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D%I\n

Description
If undefined, MessageFormat is used unless assertion causes a breakpoint in which case
MessageFormatBreak is used.

Related Topics
MessageFormatBreak

1548 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MessageFormatWarning

MessageFormatWarning
Section [vsim]
This variable defines the format of messages for VHDL/PSL/SVA Warning assertions.
Syntax
MessageFormatWarning = <%value>
Arguments
• The arguments are described as follows:
o <%value> — One or more of the variables from Table A-6 where the default is:
** %S: %R\n Time: %T Iteration: %D%I\n

Description
If undefined, MessageFormat is used unless assertion causes a breakpoint in which case
MessageFormatBreak is used.

Related Topics
MessageFormatBreak

ModelSim® SE User's Manual, v10.7 1549

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MixedAnsiPorts

MixedAnsiPorts
Section [vlog]
This variable supports mixed ANSI and non-ANSI port declarations and task/function
declarations.
Syntax
MixedAnsiPorts = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vlog -mixedansiports.

1550 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
modelsim_lib

modelsim_lib
Section [library]
This variable sets the path to the library containing Mentor Graphics VHDL utilities such as
Signal Spy.
Syntax
modelsim_lib = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../modelsim_lib.
May include environment variables.

ModelSim® SE User's Manual, v10.7 1551

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MsgLimitCount

MsgLimitCount
Section [msg_system]
This variable limits the number of times warning messages will be displayed. The default limit
value is five.
Syntax
MsgLimitCount = <limit_value>
Arguments
• The arguments are described as follows:
o <limit_value> — Any positive integer where the default limit value is 5.
You can override this variable by specifying vsim -msglimitcount.
Related Topics
Message Viewer Window. [ModelSim SE GUI Reference Manual]

1552 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
msgmode

msgmode
Section [msg_system]
This variable controls where the simulator outputs elaboration and runtime messages.
Syntax
msgmode = {tran | wlf | both}
Arguments
• The arguments are described as follows:
o tran — (default) Messages appear only in the transcript.
o wlf — Messages are sent to the wlf file and can be viewed in the MsgViewer.
o both — Transcript and wlf files.
You can override this variable by specifying vsim -msgmode.
Related Topics
Message Viewer Window. [ModelSim SE GUI Reference Manual]

ModelSim® SE User's Manual, v10.7 1553

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
mtiAvm

mtiAvm
Section [library]
This variable sets the path to the location of the Advanced Verification Methodology libraries.
Syntax
mtiAvm = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../avm
The behavior of this variable is identical to specifying vlog -L mtiAvm.

1554 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
mtiOvm

mtiOvm
Section [library]
This variable sets the path to the location of the Open Verification Methodology libraries.
Syntax
mtiOvm = <path>
Arguments
• The arguments are described as follows:
o <path> — $MODEL_TECH/../ovm-2.1.2
The behavior of this variable is identical to specifying vlog -L mtiOvm.

ModelSim® SE User's Manual, v10.7 1555

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
mtiPA

mtiPA
Section [library]
This variable sets the path to the location of Power Aware libraries.
Syntax
mtiPA = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../pa_lib. May
include environment variables.
The behavior of this variable is identical to specifying vlog -L mtiPA.

1556 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
mtiUPF

mtiUPF
Section [library]
This variable sets the path to the location of Unified Power Format (UPF) libraries.
Syntax
mtiUPF = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../upf_lib. May
include environment variables.
The behavior of this variable is identical to specifying vlog -L mtiUPF.
Related Topics
Verilog Resource Libraries
VHDL Resource Libraries

ModelSim® SE User's Manual, v10.7 1557

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
mtiUvm

mtiUvm
Section [library]
This variable sets the path to the location of the Universal Verification Methodology libraries.
Syntax
mtiUvm = <path>
Arguments
• The arguments are described as follows:
o <path> — $MODEL_TECH/../uvm-1.1d
The behavior of this variable is identical to specifying vlog -L mtiUvm.

1558 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
MultiFileCompilationUnit

MultiFileCompilationUnit
Section [vlog]
This variable controls whether Verilog files are compiled separately or concatenated into a
single compilation unit.
Syntax
MultiFileCompilationUnit = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Single File Compilation Unit (SFCU) mode.
o 1 — Multi File Compilation Unit (MFCU) mode.
You can override this variable by specifying vlog {-mfcu | -sfcu}.
Related Topics
SystemVerilog Multi-File Compilation

ModelSim® SE User's Manual, v10.7 1559

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
MvcHome

MvcHome
Section [vsim]
This variable specifies the location of the installation of Questa Verification IPs (which
previously were known as Multi-View Verification Components (MVC)).
Syntax
MvcHome = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path. May include environment variables.
You can override this variable by specifying vsim -mvchome.

1560 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
NoCaseStaticError

NoCaseStaticError
Section [vcom]
This variable changes case statement static errors to warnings.
Syntax
NoCaseStaticError = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vcom -nocasestaticerror.
Related Topics
PedanticErrors

ModelSim® SE User's Manual, v10.7 1561

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
NoDebug

NoDebug
Sections [vcom], [vlog]
This variable controls inclusion of debugging info within design units.
Syntax
NoDebug = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1562 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
NoDeferSubpgmCheck

NoDeferSubpgmCheck
Section [vcom]
This variable controls the reporting of range and length violations detected within subprograms
as errors (instead of as warnings).
Syntax
NoDeferSubpgmCheck = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vcom -deferSubpgmCheck.

ModelSim® SE User's Manual, v10.7 1563

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
NoIndexCheck

NoIndexCheck
Section [vcom]
This variable controls run time index checks.
Syntax
NoIndexCheck = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override NoIndexCheck = 0 by specifying vcom -noindexcheck.
Related Topics
Compilation of a VHDL Design—the vcom Command

1564 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
NoOthersStaticError

NoOthersStaticError
Section [vcom]
This variable disables errors caused by aggregates that are not locally static.
Syntax
NoOthersStaticError = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -noothersstaticerror.
Related Topics
Message Severity Level
PedanticErrors

ModelSim® SE User's Manual, v10.7 1565

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
NoRangeCheck

NoRangeCheck
Section [vcom]
This variable disables run time range checking. In some designs this results in a 2x speed
increase.
Syntax
NoRangeCheck = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this NoRangeCheck = 1 by specifying vcom -rangecheck.
Related Topics
Compilation of a VHDL Design—the vcom Command

1566 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
note

note
Section [msg_system]
This variable changes the severity of the listed message numbers to “note”.
Syntax
note = <msg_number>…
Arguments
• The arguments are described as follows:
o <msg_number>… — An unlimited list of message numbers, comma separated.
You can override this variable setting by specifying the sccom, vcom, vlog, vopt, or
vsim command with the -note argument.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
error
fatal
suppress
warning

ModelSim® SE User's Manual, v10.7 1567

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
NoVital

NoVital
Section [vcom]
This variable disables acceleration of the VITAL packages.
Syntax
NoVital = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -novital.

1568 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
NoVitalCheck

NoVitalCheck
Section [vcom]
This variable disables VITAL level 0 and VITAL level 1 compliance checking.
Syntax
NoVitalCheck = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vcom -novitalcheck.

ModelSim® SE User's Manual, v10.7 1569

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
NumericStdNoWarnings

NumericStdNoWarnings
Section [vsim]
This variable disables warnings generated within the accelerated numeric_std and numeric_bit
packages.
Syntax
NumericStdNoWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 —(default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

1570 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
OldVHDLConfigurationVisibility

OldVHDLConfigurationVisibility
Section [vcom]
Controls visibility of VHDL component configurations during compile.
Syntax
OldVHDLConfigurationVisibility = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Use Language Reference Manual compliant visibility rules when processing
VHDL configurations.
o 1 — (default) Force vcom to process visibility of VHDL component configurations
consistent with prior releases.
Related Topics
vcom [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1571

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
OldVhdlForGenNames

OldVhdlForGenNames
The previous style is controlled by the value of the GenerateFormat value. The default behavior
is to use the current style names, which is described in the section “Naming Behavior of
VHDL for Generate Blocks”.
Section [vsim]
This variable instructs the simulator to use a previous style of naming (pre-6.6) for VHDL
for … generate statement iteration names in the design hierarchy.
Syntax
OldVhdlForGenNames = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
GenerateFormat
Naming Behavior of VHDL for Generate Blocks

1572 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
OnFinish

OnFinish
Section [vsim]
This variable controls the behavior of ModelSim when it encounters either an assertion failure,
a $finish, or an sc_stop() in the design code.
Syntax
OnFinish = {ask | exit | final | stop}
Arguments
• The arguments are described as follows:
o ask — (default) In batch mode, the simulation exits. In GUI mode, a dialog box pops
up and asks for user confirmation on whether to quit the simulation.
o stop — Causes the simulation to stay loaded in memory. This can make some post-
simulation tasks easier.
o exit — The simulation exits without asking for any confirmation.
o final — The simulation executes all final blocks then exits the simulation.
You can override this variable by specifying vsim -onfinish.

ModelSim® SE User's Manual, v10.7 1573

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
OnFinishPendingAssert

OnFinishPendingAssert
Section [vsim]
This variable prints pending deferred assertion messages. Deferred assertion messages may be
scheduled after the $finish in the same time step. Deferred assertions scheduled to print after the
$finish are printed to the Transcript before exiting. They are printed with severity level NOTE
because it is not known whether the assertion is still valid due to being printed in the active
region instead of the reactive region where they are normally printed.
Syntax
OnFinishPendingAssert = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1574 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Optimize_1164

Optimize_1164
Section [vcom]
This variable disables optimization for the IEEE std_logic_1164 package.
Syntax
Optimize_1164 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1575

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
osvvm

osvvm
Section [Library]
This variable sets the path to the location of the pre-compiled Open Source VHDL Verification
Methodology library.
Syntax
osvvm = <path>
Arguments
• The arguments are described as follows:
o <path> — $MODEL_TECH/../osvvm
The source code for building this library is copied under the Perl foundation's artistic
license from the Open Source VHDL Verification Methodology web site at http://
www.osvvm.org. A copy of the source code is in the directory vhdl_src/
vhdl_osvvm_packages.

1576 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ParallelJobs

ParallelJobs
Section [vopt]
This variable may be set to zero (0) to disable parallel processing during vopt code generation
phase. Normally a heuristic is used to set this value.
Syntax
ParallelJobs = <n>
Arguments
• The arguments are described as follows:
o <n> — Any natural integer greater than or equal to 0 where 0 disables parallel
processing.

ModelSim® SE User's Manual, v10.7 1577

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
PathSeparator

PathSeparator
Section [vsim]
This variable specifies the character used for hierarchical boundaries of HDL modules. This
variable does not affect file system paths. The argument to PathSeparator must not be the same
character as DatasetSeparator. This variable setting is also the default for the
SignalSpyPathSeparator variable.
Note
When creating a virtual bus, you must set the PathSeparator variable to either a period (.) or
a forward slash (/). For more information on creating virtual buses, refer to the section
“Combining Objects into Buses”.

Syntax
PathSeparator = <n>
Arguments
• The arguments are described as follows:
o <n> — Any character except special characters, such as backslash ( \ ), brackets ( {}
), and so forth, where the default is a forward slash ( / ).
Related Topics
Using Escaped Identifiers
SignalSpyPathSeparator
DatasetSeparator
Preserving Design Visibility with the Learn Flow
set Command Syntax

1578 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
PedanticErrors

PedanticErrors
Section [vcom]
This variable forces display of an error message (rather than a warning) on a variety of
conditions. It overrides the NoCaseStaticError and NoOthersStaticError variables.
Syntax
PedanticErrors = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
See the vcom [ModelSim SE Command Reference Manual]
NoCaseStaticError
NoOthersStaticError
Enforcing Strict 1076 Compliance

ModelSim® SE User's Manual, v10.7 1579

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
PliCompatDefault

PliCompatDefault
Section [vsim]
This variable specifies the VPI object model behavior within vsim.
Syntax
PliCompatDefault = {1995 | 2001 | 2005 | 2009 | latest}
Arguments
• The arguments are described as follows:
o 1995 — Instructs vsim to use the object models as defined in IEEE Std 1364-1995.
When you specify this argument, SystemVerilog objects will not be accessible.
Aliases include:
95, 1364v1995, 1364V1995, VL1995,
VPI_COMPATIBILITY_VERSION_1364v1995, 1 — On
o 2001 — Instructs vsim to use the object models as defined in IEEE Std 1364-2001.
When you specify this argument, SystemVerilog objects will not be accessible.
Aliases include:
01, 1364v2001, 1364V2001, VL2001,
VPI_COMPATIBILITY_VERSION_1364v2001

Note
There are a few cases where the 2005 VPI object model is incompatible with the
2001 model, which is inherent in the specifications.

o 2005 — Instructs vsim to use the object models as defined in IEEE Std 1800-2005
and IEEE Std 1364-2005. Aliases include:
05, 1800v2005, 1800V2005, SV2005,
VPI_COMPATIBILITY_VERSION_1800v2005
o 2009 — Instructs vsim to use the object models as defined in IEEE Std 1800-2009.
Aliases include:
09, 1800v2009, 1800V2009, SV2009,
VPI_COMPATIBILITY_VERSION_1800v2009
o latest — (default) This is equivalent to the “2009” argument. This is the default
behavior if you do not specify this argument or if you specify the argument without
an argument.
You can override this variable by specifying vsim -plicompatdefault.
Related Topics
Verilog Interfaces to C

1580 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
PreserveCase

PreserveCase
Section [vcom]
This variable instructs the VHDL compiler either to preserve the case of letters in basic VHDL
identifiers or to convert uppercase letters to lowercase.
Syntax
PreserveCase = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vcom -lower or vcom -preserve.

ModelSim® SE User's Manual, v10.7 1581

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
PrintSimStats

PrintSimStats
Section [vsim]
This variable instructs the simulator to print out simulation statistics at the end of the simulation
before it exits. Statistics are printed with relevant units in separate lines. The Stats variable
overrides the PrintSimStats if the two are both enabled.
Syntax
PrintSimStats = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — print at end of simulation
o 2 — print at end of each run and end of simulation
You can override this variable by specifying vsim -printsimstats.
Related Topics
simstats [ModelSim SE Command Reference Manual]
Stats

1582 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
PrintSVPackageLoadingAttribute

PrintSVPackageLoadingAttribute
Section [vlog]
This variable prints the attribute placed upon SV packages during package import when true (1).
The attribute will be ignored when this variable entry is false (0). The attribute name is
“package_load_message.” The value of this attribute is a string literal.
Syntax
PrintSVPackageLoadingAttribute = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — False
o 1 — (default) True

ModelSim® SE User's Manual, v10.7 1583

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Protect

Protect
Section [vlog]
This variable enables protect directive processing.
Syntax
Protect = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
Compiler Directives

1584 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
PslOneAttempt

PslOneAttempt
Section [vsim]
This variable affects PSL directives with top level “always/never” properties. As per strict IEEE
Std 1850-2005, an always/never property can either pass or fail. However, by default,
ModelSim reports multiple passes and/or failures, which corresponds to multiple attempts made
while executing a top level “always/never” property. With this variable, you can force a single
attempt to start at the beginning of simulation. The directive will either match (pass), fail, or
vacuously-match (provided it is not disabled/aborted). If the “always/never” property fails, the
directive is immediately considered a failure and the simulation will not go further. If there is no
failure (or disable/abort) until end of simulation then a match (pass) is reported. By default, this
feature is off and can only be explicitly turned on using this variable or vsim -psloneattempt.
Syntax
PslOneAttempt = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1585

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
PslInfinityThreshold

PslInfinityThreshold
Section [vsim]
This variable allows you to specify the number of clock ticks that will represent infinite clock
ticks. It only affects PSL strong operators, namely eventually!, until! and until_!. If at End of
Simulation an active strong-property has not clocked this number of clock ticks, neither pass
nor fail (that is, vacuous match) is returned; else, respective fail/pass is returned. The default
value is '0' (zero) which effectively does not check for clock tick condition. This feature can
only be explicitly turned on using this variable or vsim -pslinfinitethreshold.
Syntax
PslOneAttempt = {0 | <n>}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o <n> — Any positive integer

1586 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Quiet

Quiet
Sections [vcom], [vlog]
This variable turns off “loading…” messages.
Syntax
Quiet = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vlog -quiet or vcom -quiet.

ModelSim® SE User's Manual, v10.7 1587

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
RequireConfigForAllDefaultBinding

RequireConfigForAllDefaultBinding
Section [vcom]
This variable instructs the compiler to not generate any default bindings when compiling with
vcom and when elaborating with vsim. All instances are left unbound unless you specifically
write a configuration specification or a component configuration that applies to the instance.
You must explicitly bind all components in the design through either configuration
specifications or configurations. If an explicit binding is not fully specified, defaults for the
architecture, port maps, and generic maps will be used as needed.
Syntax
RequireConfigForAllDefaultBinding = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override RequireConfigForAllDefaultBinding = 1 by specifying vcom
-performdefaultbinding.
Related Topics
Default Binding
BindAtCompile
vcom [ModelSim SE Command Reference Manual]

1588 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Resolution

Resolution
Section [vsim]
This variable specifies the simulator resolution. The argument must be less than or equal to the
UserTimeUnit and must not contain a space between value and units.
Syntax
Resolution = {[n]<time_unit>}
Arguments
• The arguments are described as follows:
o [n] — Optional prefix specifying number of time units as 1, 10, or 100.
o <time_unit> — fs, ps, ns, us, ms, or sec where the default is ns.
The argument must be less than or equal to the UserTimeUnit and must not contain a
space between value and units, for example:
Resolution = 10fs

You can override this variable by specifying vsim -t. You should set a smaller
resolution if your delays get truncated.
Related Topics
UserTimeUnit

ModelSim® SE User's Manual, v10.7 1589

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
RunLength

RunLength
Section [vsim]
This variable specifies the default simulation length in units specified by the UserTimeUnit
variable.
Syntax
RunLength = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 100.
You can override this variable by specifying the run command.
Related Topics
UserTimeUnit
The Runtime Options Dialog
set Command Syntax

1590 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Sc22Mode

Sc22Mode
Section [sccom]
This variable enables SystemC-2.2 (the IEEE 1666-2005 standard) for both compiling and
linking.
Syntax
Sc22Mode = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying the -sc22 argument with sccom, vopt,
or vsim.

ModelSim® SE User's Manual, v10.7 1591

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ScalarOpts

ScalarOpts
Sections [vcom], [vlog]
This variable activates optimizations on expressions that do not involve signals, waits, or
function/procedure/task invocations.
Syntax
ScalarOpts = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1592 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SccomLogfile

SccomLogfile
Section [sccom]
This variable creates a log file for sccom.
Syntax
SccomLogfile = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying sccom -log.

ModelSim® SE User's Manual, v10.7 1593

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SccomVerbose

SccomVerbose
Section [sccom]
This variable prints the name of each sc_module encountered during compilation.
Syntax
SccomVerbose = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying sccom -verbose.

1594 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ScEnableScSignalWriteCheck

ScEnableScSignalWriteCheck
Section [vsim]
This variable enables a check for multiple writers on a SystemC signal.
Syntax
ScEnableScSignalWriteCheck = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1595

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ScMainFinishOnQuit

ScMainFinishOnQuit
Section [vsim]
This variable determines when the sc_main thread exits. This variable is used to turn off the
execution of remainder of sc_main upon quitting the current simulation session. Disabling this
variable (0) has the following effect: If the cumulative length of sc_main() in simulation time
units is less than the length of the current simulation run upon quit or restart, sc_main() is
aborted in the middle of execution. This can cause the simulator to crash if the code in sc_main
is dependent on a particular simulation state.
On the other hand, one drawback of not running sc_main until the end is potential memory leaks
for objects created by sc_main. By default, the remainder of sc_main is executed regardless of
delays.
Syntax
ScMainFinishOnQuit = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1596 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ScMainStackSize

ScMainStackSize
Section [vsim]
This variable sets the stack size for the sc_main() thread process.
Syntax
ScMainStackSize = <n>{Kb | Mb | Gb}
Arguments
• The arguments are described as follows:
o <n> — An integer followed by Kb, Mb, Gb where the default is 1Mb.

ModelSim® SE User's Manual, v10.7 1597

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ScStackSize

ScStackSize
Section [vsim]
This variable sets the stack size for the sc_thread process.
Syntax
ScStackSize = <n>{Kb | Mb | Gb}
Arguments
• The arguments are described as follows:
o <n> — An integer followed by Kb, Mb, Gb. There is no default for ScStackSize.

1598 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ScShowIeeeDeprecationWarnings

ScShowIeeeDeprecationWarnings
Section [vsim]
This variable displays warning messages for many of the deprecated features in Annex C of the
IEEE Std 1666-2005, and Std 1666-2011, Standard SystemC Language Reference Manual.
Syntax
ScShowIeeeDeprecationWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1599

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ScTimeUnit

ScTimeUnit
Section [vsim]
This variable sets the default time unit for SystemC simulations.
Syntax
ScTimeUnit = {[n]<time_unit>}
Arguments
• The arguments are described as follows:
o [<n>] — Optional prefix specifying number of time units as 1, 10, or 100.
o <time_unit> — fs, ps, ns, us, ms, or sec where the default is 1 ns.

1600 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ScvPhaseRelationName

ScvPhaseRelationName
Section [vsim]
This variable changes the precise name used by SCV to specify “phase” transactions in the
WLF file.
Syntax
ScvPhaseRelationName = <string>
Arguments
• The arguments are described as follows:
o <string> — Any legal string where the default is mti_phase. Legal C-language
identifiers are recommended.
Related Topics
About Transaction Streams
Recording SCV Transactions

ModelSim® SE User's Manual, v10.7 1601

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SeparateConfigLibrary

SeparateConfigLibrary
Section [vcom]
This variable allows the declaration of a VHDL configuration to occur in a different library than
the entity being configured. Strict conformance to the VHDL standard (LRM) requires that they
be in the same library.
Syntax
SeparateConfigLibrary = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom -separateConfigLibrary.

1602 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Show_BadOptionWarning

Show_BadOptionWarning
Section [vlog]
This variable instructs ModelSim to generate a warning whenever an unknown plus argument is
encountered.
Syntax
Show_BadOptionWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1603

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Show_Lint

Show_Lint
Sections [vcom], [vlog]
This variable instructs ModelSim to display lint warning messages.
Syntax
Show_Lint = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vlog -lint or vcom -lint.

1604 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Show_PslChecksWarnings

Show_PslChecksWarnings
Section [vcom], [vlog]
This variable instructs ModelSim to display PSL warning messages.
Syntax
Show_PslChecksWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1605

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Show_source

Show_source
Sections [vcom], [vlog]
This variable shows source line containing error.
Syntax
Show_source = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying the vlog -source or vcom -source.

1606 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Show_VitalChecksWarnings

Show_VitalChecksWarnings
Section [vcom]
This variable enables VITAL compliance-check warnings.
Syntax
Show_VitalChecksWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1607

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Show_Warning1

Show_Warning1
Section [vcom]
This variable enables unbound-component warnings.
Syntax
Show_Warning1 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1608 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Show_Warning2

Show_Warning2
Section [vcom]
This variable enables process-without-a-wait-statement warnings.
Syntax
Show_Warning2 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1609

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Show_Warning3

Show_Warning3
Section [vcom]
This variable enables null-range warnings.
Syntax
Show_Warning3 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1610 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Show_Warning4

Show_Warning4
Section [vcom]
This variable enables no-space-in-time-literal warnings.
Syntax
Show_Warning4 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1611

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Show_Warning5

Show_Warning5
Section [vcom]
This variable enables multiple-drivers-on-unresolved-signal warnings.
Syntax
Show_Warning5 = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1612 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ShowConstantImmediateAsserts

ShowConstantImmediateAsserts
Section [vcom], [vlog], [vopt]
This variable controls the display of immediate assertions with constant expressions. By default,
immediate assertions with constant expressions are displayed in the GUI, in reports, and in the
UCDB.
Syntax
ShowConstantImmediateAsserts = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

ModelSim® SE User's Manual, v10.7 1613

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ShowFunctions

ShowFunctions
Section [vsim]
This variable sets the format for Breakpoint and Fatal error messages. When set to 1 (the default
value), messages will display the name of the function, task, subprogram, module, or
architecture where the condition occurred, in addition to the file and line number. Set to 0 to
revert messages to the previous format.
Syntax
ShowFunctions = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1614 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ShowUnassociatedScNameWarning

ShowUnassociatedScNameWarning
Section [vsim]
This variable instructs ModelSim to display unassociated SystemC name warnings.
Syntax
ShowUnassociatedScNameWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1615

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ShowUndebuggableScTypeWarning

ShowUndebuggableScTypeWarning
Section [vsim]
This variable instructs ModelSim to display un-debuggable SystemC type warnings.
Syntax
ShowUndebuggableScTypeWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1616 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ShutdownFile

ShutdownFile
Section [vsim]
This variable calls the write format restart command upon exit and executes the .do file created
by that command. This variable should be set to the name of the file to be written, or the value
“--disable-auto-save” to disable this feature. If the filename contains the pound sign character
(#), then the filename will be sequenced with a number replacing the #. For example, if the file
is “restart#.do”, then the first time it will create the file “restart1.do” and the second time it will
create “restart2.do”, and so forth.
Syntax
ShutdownFile = <filename>.do | <filename>#.do | --disable-auto-save}
Arguments
• The arguments are described as follows:
o <filename>.do — A user defined filename where the default is restart.do.
o <filename>#.do — A user defined filename with a sequencing character.
o --disable-auto-save — Disables auto save.
Related Topics
write format restart command. [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1617

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SignalForceFunctionUseDefaultRadix

SignalForceFunctionUseDefaultRadix
Section [vsim]
Set this variable to 1 cause the signal_force VHDL and Verilog functions use the default radix
when processing the force value. Prior to 10.2 signal_force used the default radix and now it
always uses symbolic unless the value explicitly indicates a base radix.
Syntax
SignalForceFunctionUseDefaultRadix = { 0 | 1 }
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1618 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SignalSpyPathSeparator

SignalSpyPathSeparator
Section [vsim]
This variable specifies a unique path separator for the Signal Spy functions. The argument to
SignalSpyPathSeparator must not be the same character as the DatasetSeparator variable.
Syntax
SignalSpyPathSeparator = <character>
Arguments
• The arguments are described as follows:
o <character> — Any character except special characters, such as backslash ( \ ),
brackets
( {} ), and so forth, where the default is to use the PathSeparator variable or a
forward slash ( / ).
Related Topics
Signal Spy
DatasetSeparator

ModelSim® SE User's Manual, v10.7 1619

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SimulateAssumeDirectives

SimulateAssumeDirectives
Section [vsim]
This variable instructs ModelSim to assume directives are simulated as if they were assert
directives.
Syntax
SimulateAssumeDirectives = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim {-assume | -noassume}.
Related Topics
Processing Assume Directives

1620 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SimulateImmedAsserts

SimulateImmedAsserts
Section [vsim]
This variable controls whether or not SVA and VHDL immediate assertion directives will be
simulated.
Syntax
SimulateImmedAsserts = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim {-immedassert | -noimmedassert].

ModelSim® SE User's Manual, v10.7 1621

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SimulatePSL

SimulatePSL
Section [vsim]
This variable controls whether or not PSL assertion directives will be elaborated.
Syntax
SimulatePSL = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim {-psl | -nopsl}.

1622 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SimulateSVA

SimulateSVA
Section [vsim]
This variable controls whether or not SVA concurrent assertion directives will be elaborated.
Syntax
SimulateSVA = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim {-sva | -nosva].

ModelSim® SE User's Manual, v10.7 1623

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SmartDbgSym

SmartDbgSym
This variable reduces the size of design libraries by minimizing the amount of debugging
symbol files generated at compile time. Default is to generate debugging symbol database file
for all design-units.
Syntax
SmartDbgSym = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vcom/vlog -smartdbgsym.

1624 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveACTMaxOps

SolveACTMaxOps
Section [vsim]
This variable specifies the maximum number of operations that the ACT solver may perform
before abandoning an attempt to solve a particular constraint scenario. The value is specified in
1,000,000s of operations.
Syntax
SolveACTMaxOps = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 10000 and 0 indicates no limit.

ModelSim® SE User's Manual, v10.7 1625

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveACTMaxTests

SolveACTMaxTests
Section [vsim]
This variable specifies the maximum number of tests that the ACT solver may evaluate before
abandoning an attempt to solve a particular randomize scenario.
Syntax
SolveACTMaxTests = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where 0 indicates no limit and the default is 2000000.

1626 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveACTRetryCount

SolveACTRetryCount
Section [vsim]
This variable specifies the number of times to retry the ACT solver on a randomization scenario
that fails due to the value of the SolveACTMaxTests threshold. The default is 0, meaning that if
the first attempt fails after SolveACTMaxTests tests, no subsequent attempts are made, and the
solver moves on to the next engine (for example, the BDD engine). This can be useful in
scenarios where the BDD engine is known to fail, and the ACT solver succeeds most of the
time. A small nonzero value of SolveACTRetryCount can decrease the percentage of the time
that a randomize call might not ultimately succeed.
Syntax
SolveACTRetryCount = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 0.

ModelSim® SE User's Manual, v10.7 1627

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveArrayResizeMax

SolveArrayResizeMax
Section [vsim]
This variable specifies the maximum size randomize() will allow a dynamic array to be resized.
If randomize() attempts to resize a dynamic array to a value greater than SolveArrayResizeMax,
an error will be displayed and randomize() will fail.
Syntax
SolveArrayResizeMax = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer (a value of 0 indicates no limit). Default value is 10000.
Related Topics
set Command Syntax

1628 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveBeforeErrorSeverity

SolveBeforeErrorSeverity
Section [vsim]
This variable modifies the severity of suppressible index, out-of-bounds, null-dereference,
solve/before constraint errors.
Syntax
SolveBeforeErrorSeverity = [0 | 1 | 2 | 3 | 4]
Arguments
• The arguments are described as follows:
o 0 — No error
o 1 — Warning
o 2 — Error
o 3 — (default) Failure
o 4 — Fatal
You can override this variable by specifying vsim -solvebeforeerrorseverity.

ModelSim® SE User's Manual, v10.7 1629

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveEngine

SolveEngine
Section [vsim]
This variable specifies which solver engine to use when evaluating randomize calls.
Syntax
SolveEngine = auto | act | bdd
Arguments
• The arguments are described as follows:
o auto — (default) automatically select the best engine for the current randomize
scenario
o act — evaluate all randomize scenarios using the ACT solver engine
o bdd — evaluate all randomize scenarios using the BDD solver engine
You can override this variable by specifying vsim -solveengine at the command line.

1630 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveFailDebug

SolveFailDebug
Section [vsim]
This variable enables the feature to debug SystemVerilog randomize() failures. Whenever a
randomize() failure is detected during simulation, ModelSim displays the minimum set of
constraints that caused the randomize() call to fail.
Syntax
SolveFailDebug = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 - (default) Disable solvefaildebug
o 1 - Basic debug (provides a testcase and prints contradicting constraints with no
performance penalty)
o 2 - Enhanced debug (provides constraints in more original form with a runtime
performance penalty)
If no value is specified, basic debug will be enabled. You can override this variable
by specifying vsim -solvefaildebug.
Related Topics
Debugging randomize() Failures

ModelSim® SE User's Manual, v10.7 1631

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveFailDebugMaxSet

SolveFailDebugMaxSet
Section [vsim]
When SolveFailDebug is enabled, this variable specifies the maximum size of constraint
subsets (in number of constraints) that will be tested for conflicts.
Syntax
SolveFailDebugMaxSet = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1632 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveFailSeverity

SolveFailSeverity
Section [vsim]
Defines the severity of messages that result when a SystemVerilog call to randomize() and
randomize(null) fails. When you specify a single argument, the severity applies to both
randomize() and randomize(null). When you specify two arguments (no space between them),
the first applies to randomize() and the second applies to randomize(null).
Syntax
SolveFailSeverity = {<value1>[<value2>}
Arguments
• The arguments are described as follows:
o 0 — (default) No error
o 1 — Warning
o 2 — Error
o 3 — Failure
o 4 — Fatal

ModelSim® SE User's Manual, v10.7 1633

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveGraphMaxEval

SolveGraphMaxEval
Section [vsim]
This variable specifies the maximum number of evaluations that may be performed on the
solution graph generated during randomize(). This value can be used to force randomize() to
abort if the complexity of the constraint scenario (in time) exceeds the specified limit. The value
is specified in 10000s of evaluations.
Syntax
SolveGraphMaxEval = <n>
Arguments
• The arguments are described as follows:
o <n>— A non-negative integer where 0 indicates no limit and the default is 10000.

1634 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveGraphMaxSize

SolveGraphMaxSize
Section [vsim]
This variable specifies the maximum size of the solution graph that may be generated during a
SystemVerilog call to randomize(). You can use this value to force randomize() to abort if the
complexity of the constraint scenario exceeds the specified limit. The limit is specified in 1000s
of nodes.
Syntax
SolveGraphMaxSize = <n>
Arguments
• The arguments are described as follows:
o <n> — A non-negative integer (with the unit of 1000 nodes) where 0 indicates no
limit and 10000 is the default.

ModelSim® SE User's Manual, v10.7 1635

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveIgnoreOverflow

SolveIgnoreOverflow
Section [vsim]
This variable instructs the solver to ignore calculation overflow or underflow while evaluating
constraints.
Syntax
SolveIgnoreOverflow = 0 | 1
Arguments
• The arguments are described as follows:
o 0 — (default) Do not ignore overflow or underflow.
o 1 — Ignore overflow or underflow.

1636 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveRev

SolveRev
Section [vsim]
This variable allows you to specify random sequence generator compatibility with a prior letter
release for the SystemVerilog solver. (It does not apply to the SystemC/SCV solver.) This
option is used to get the same random sequences during simulation as a prior letter release.
Syntax
SolveRev = <string> | " "
Arguments
• The arguments are described as follows:
o <string> — A string of a ModelSim release number and letter, such as 6.4a
(SolveRev = 6.4a).
" " — (default) Off.

Note
Only prior letter releases (within the same number release) are allowed. For
example, in 6.4b you can set “SolveRev= 6.4” or “SolveRev = 6.4a”, but cannot
set “SolveRev = 6.4g”.

You can override this variable by specifying vsim -solverev.

ModelSim® SE User's Manual, v10.7 1637

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveTimeout

SolveTimeout
Section [vsim]
This variable allows you to specify the solver timeout threshold (in seconds), to improve the
handling of randomize() timeouts. A randomize() call will fail if the CPU time required to
evaluate any randset exceeds the specified timeout.
Syntax
SolveTimeout = <val>
Arguments
• The arguments are described as follows:
o <val> — Number of seconds before the randomize() call times out. The default is
500. A setting of 0 disables the timeout feature.
You can override this variable by specifying vsim -solvetimeout.

1638 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SparseMemThreshold

SparseMemThreshold
Section [vlog]
This variable specifies the size at which memories will automatically be marked as sparse
memory. A memory with depth equal to or more than the sparse memory threshold gets marked
as sparse automatically, unless specified otherwise in source code or by vlog +nonsparse, or
vopt +nonsparse.
Syntax
SparseMemThreshold = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 1048576.
Related Topics
Sparse Memory Modeling
vlog [ModelSim SE Command Reference Manual]
vopt [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1639

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
StackTraceDepth

StackTraceDepth
Section [vsim]
This variable specifies the depth of stack frames returned by the level argument to the
$stacktrace() function call. The depth specified is used when the optional ‘level’ argument is not
specified or its value is not a positive integer.
Syntax
StackTraceDepth = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative number where the default is 100.
Related Topics
$stacktrace()

1640 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Startup

Startup
Section [vsim]
This variable specifies a simulation startup DO file.
Syntax
Startup = {do <DO filename>}
Arguments
• The arguments are described as follows:
o <DO filename> — Any valid DO file where the default is to comment out the line ( ;
).
Related Topics
do [ModelSim SE Command Reference Manual]
Using a Startup File

ModelSim® SE User's Manual, v10.7 1641

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Stats

Stats
Section [sccom, vcom, vlog, vopt, vsim]
This variable controls the display of statistics messages in a logfile and stdout. Stats variable
overrides PrintSimStats variable if both are enabled.
Syntax
Stats [=[+|-]<feature>[,[+|-]<mode>]
Arguments
• The arguments are described as follows:
o [+|-] — Controls activation of the feature or mode. You can also enable a feature or
mode by specifying a feature or mode without the plus (+) character. Multiple
features and modes for each instance of -stats are specified as a comma separated
list.
o <feature>
• all — All statistics features displayed (cmd, msg, perf, time). Mutually exclusive
with none option. When specified in a string with other options, +|-all is applied
first.
• cmd — (default) Echo the command line
• msg — (default) Display error and warning summary at the end of command
execution
• none — Disable all statistics features. Mutually exclusive with all option. When
specified in a string with other options, +|-none is applied first.
• perf — Display time and memory performance statistics
• time — (default) Display Start, End, and Elapsed times
o <mode>
Modes can be set for a specific feature or globally for all features. To add or subtract
a mode for a specific feature, specify using the plus (+) or minus (-) character with
the feature, for example, Stats=cmd+verbose,perf+list. To add or subtract a mode
globally for all features, specify the modes in a comma-separated list, for example,
Stats=time,perf,list,-verbose. You cannot specify global and feature specific modes
together.
• kb — Prints memory statistics in Kb units with no auto-scaling
• list — Display statistics in a Tcl list format when available
• verbose — Display verbose statistics information when available

1642 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Stats

You can add or subtract individual elements of this variable by specifying the -stats
argument with sccom, vcom, vcover attribute, and other vcover commands,
vencrypt, vhencrypt, vlog, vopt, and vsim.
You can disable all default or user-specified Stats features with the -quiet argument
for:
• vcom
• vencrypt
• vhencrypt
• vlog
• vopt
Description
You can specify modes globally or for a specific feature.

Examples
• Use this example to enable the display of Start, End, and Elapsed time as well as a
message count summary, while disabling the echoing of the command line.
vcom -stats=time,-cmd,msg

• In this example, the first -stats option is ignored. The none option disables all default
settings and then enables the perf option.
vlog -stats=time,cmd,msg -stats=none,perf

Related Topics
PrintSimStats

ModelSim® SE User's Manual, v10.7 1643

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
std

std
Section [library]
This variable sets the path to the VHDL STD library.
Syntax
std = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../std. May include
environment variables.

1644 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
std_developerskit

std_developerskit
Section [library]
This variable sets the path to the libraries for Mentor Graphics standard developer’s kit.
Syntax
std_developerskit = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../
std_developerskit. May include environment variables.

ModelSim® SE User's Manual, v10.7 1645

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
StdArithNoWarnings

StdArithNoWarnings
Section [vsim]
This variable suppresses warnings generated within the accelerated Synopsys std_arith
packages.
Syntax
StdArithNoWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
The Runtime Options Dialog
set Command Syntax

1646 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
suppress

suppress
Section [msg_system]
This variable suppresses the listed message numbers and/or message code strings (displayed in
square brackets).
Syntax
suppress = <msg_number>…
Arguments
• The arguments are described as follows:
o <msg_number>… — An unlimited list of message numbers, comma separated.
You can override this variable setting by specifying the sccom, vcom, vlog, vopt, or
vsim command with the -suppress argument.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
error
fatal
note
warning

ModelSim® SE User's Manual, v10.7 1647

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SuppressFileTypeReg

SuppressFileTypeReg
Section [vsim]
This variable suppresses a prompt from the GUI asking if ModelSim file types should be
applied to the current version.
Syntax
SuppressFileTypeReg = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can suppress the GUI prompt for ModelSim type registration by setting the
SuppressFileTypeReg variable value to 1 in the modelsim.ini file on each server in a
server farm. This variable only applies to Microsoft Windows platforms.

1648 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Sv_Seed

Sv_Seed
Section [vsim]
This is a read-only variable that shows the initial seed specified for the Random Number
Generator (RNG) of the root thread in SystemVerilog. You cannot change its value directly in
the modelsim.ini file.
Syntax
Sv_Seed
Arguments
• none
o This variable assumes the value that you specify with either sv_reseed or vsim
-sv_seed.
Related Topics
Seeding the Random Number Generator (RNG)

ModelSim® SE User's Manual, v10.7 1649

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
sv_std

sv_std
Section [library]
This variable sets the path to the SystemVerilog STD library.
Syntax
sv_std = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../sv_std. May
include environment variables.

1650 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVAPrintOnlyUserMessage

SVAPrintOnlyUserMessage
Section [vsim]
This variable controls the printing of user-defined assertion error messages along with severity
information.
Syntax
SVAPrintOnlyUserMessage = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Prints additional information from LRM-defined (IEEE Std 1800-
2009) Severity System tasks.
o 1 — Prints only the severity information and the user message.

ModelSim® SE User's Manual, v10.7 1651

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupGetInstCoverageDefault

SVCovergroupGetInstCoverageDefault
Section [vlog], [vsim]
This variable allows you to specify an override for the default value of the “get_inst_coverage”
option for Covergroup variables. This is a compile time option which forces
“get_inst_coverage” to a user specified default value and supersedes the SystemVerilog
specified default value of '0' (zero).
Syntax
SVCovergroupGetInstCoverageDefault = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1652 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCovergroupGoal

SVCovergroupGoal
Section [vsim]
This variable is used to override both the default value of option.goal (100, unless otherwise set
with the SVCovergroupGoalDefault compiler control variable), as well as any explicit
assignments to covergroup, coverpoint, and cross option.goal placed in SystemVerilog.
Syntax
SVCovergroupGoal = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 100.
Related Topics
SVCovergroupGoalDefault

ModelSim® SE User's Manual, v10.7 1653

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupGoalDefault

SVCovergroupGoalDefault
Section [vlog]
This variable is used in conjunction with the SVCovergroupGoal simulator control variable, and
overrides the default value of the SystemVerilog covergroup, coverpoint, and cross option.goal
(defined to be 100 in the IEEE Std 1800-2009). This variable does not override specific
assignments in SystemVerilog source code.
Note
You must re-compile the design after changing the setting of this variable.

Syntax
SVCovergroupGoalDefault = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 100.
Related Topics
SVCovergroupGoal

1654 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCovergroupMergeInstancesDefault

SVCovergroupMergeInstancesDefault
Section [vsim]
This variable exists in the vsim sections of the modelsim.ini file.
Syntax
SVCovergroupMergeInstancesDefault = {0 | 1 | -1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — On
o -1 — (default) Don't care
Description
For simulation, this variable enforces the default behavior of covergroup get_coverage() built-
in functions, GUI operations, and reports. It sets the default value of
type_option.merge_instances to ensure IEEE 1800-2009 compliant behavior. Two vsim
command line options— -cvgmergeinstances and -nocvgmergeinstances—override this
variable setting.

The default value of this variable, -1 (don't care), allows the tool to determine the effective
value, based on factors related to capacity and optimization. The type_option.merge_instances
appears in the GUI and coverage reports as either auto(1) or auto(0), depending on whether the
effective value was determined to be a 1 or a 0.

Related Topics
vsim command. [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1655

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupPerInstanceDefault

SVCovergroupPerInstanceDefault
Section [vlog]
This variable is used to set the default value for SystemVerilog option.per_instance (defined to
be 0 in the IEEE Std 1800-2009). It does not override explicit assignments to
option.per_instance.
Note
You must re-compile the design after changing the setting of this variable.

Syntax
SVCovergroupPerInstanceDefault = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1656 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCovergroupSampleInfo

SVCovergroupSampleInfo
Section [vsim]
This variable is used to enable generation of more detailed information about the sampling of
covergroup, cross, and coverpoints. It provides details about the number of times the
covergroup instance and type were sampled, as well as details about why covergroup, cross, and
coverpoint were not covered.
Syntax
SVCovergroupSampleInfo = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 0.

ModelSim® SE User's Manual, v10.7 1657

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupStrobe

SVCovergroupStrobe
Section [vsim]
This variable is used to override both the default value of type_option.strobe (0, unless
otherwise set with the SVCovergroupStrobeDefault variable), as well as any user assignments
for covergroup, coverpoint, and cross type_option.strobe, placed in SystemVerilog.
Syntax
SVCovergroupStrobe = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 0.
Related Topics
SVCovergroupStrobeDefault

1658 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCovergroupStrobeDefault

SVCovergroupStrobeDefault
Section [vlog]
This variable is used in conjunction with the SVCovergroupStrobe variable, and overrides the
SystemVerilog covergroup type_option.strobe (defined to be 0 in the IEEE Std 1800-2009). It
does not override explicit assignments to type_option.strobe.
Note
You must re-compile the design after changing the setting of this variable.

Syntax
SVCovergroupStrobeDefault = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 0.
Related Topics
SVCovergroupStrobe

ModelSim® SE User's Manual, v10.7 1659

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupTypeGoal

SVCovergroupTypeGoal
Section [vsim]
This variable is used to override both the default value of type_option.goal (100, unless
otherwise set with the SVCovergroupTypeGoalDefault variable), as well as any user
assignments for covergroup, coverpoint, and cross type_option.goal, placed in SystemVerilog.
Syntax
SVCovergroupTypeGoal = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 100.
Related Topics
SVCovergroupTypeGoalDefault

1660 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCovergroupTypeGoalDefault

SVCovergroupTypeGoalDefault
Section [vlog]
This variable is used to override the default value of the SystemVerilog covergroup, coverpoint,
and cross type_option.goal (defined to be 100 in the IEEE Std 1800-2009). It does not override
specific assignments in SystemVerilog source code.
Note
You must re-compile the design after changing the setting of this variable.

Syntax
SVCovergroupTypeGoal Default = <n>
Arguments
• The arguments are described as follows:
o <n> — Any integer where the default is 100.

ModelSim® SE User's Manual, v10.7 1661

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCovergroupZWNoCollect

SVCovergroupZWNoCollect
Section [vsim]
This variable is used to disable coverage collection for any coverage item (coverpoint or cross
or the entire covergroup), when 0 is assigned as its option.weight. Item will not be displayed in
any coverage report, nor will it contribute to any coverage score computation.
Syntax
SVCovergroupZWNoCollect = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On - disables coverage collection for coverage item

1662 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCoverpointAutoBinMax

SVCoverpointAutoBinMax
Section [vsim]
This variable is used to override both the default value of option.auto_bin_max (64), as well as
any explicit assignments in source code to SystemVerilog covergroup option.auto_bin_max.
Syntax
SVCoverpointAutoBinMax = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 64.

ModelSim® SE User's Manual, v10.7 1663

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCoverpointExprVariablePrefix

SVCoverpointExprVariablePrefix
Section [vlog]
When GenerateLoopIterationMax = 1, this variable sets the prefix in the name of the user-
visible variable generated for the coverpoint expression sampled value.
Note
You must re-compile the design after changing the setting of either this variable or the
EnableSVCoverpointExprVariable.

Syntax
SVCoverpointExprVariablePrefix = [<value><coverpoint name> | expr]
Arguments
• The arguments are described as follows:
o <value> — A user defined string.
o <coverpoint name> — The name of the coverpoint.
o expr — (default)
Description
The current settings for both this variable and the EnableSVCoverpointExprVariable are
displayed in the Objects window.

Related Topics
GenerateLoopIterationMax
EnableSVCoverpointExprVariable

1664 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCoverpointWildCardBinValueSizeWarn

SVCoverpointWildCardBinValueSizeWarn
Section [vsim]
This variable sets the threshold value range beyond which a warning for SV Coverpoint
wildcard bin size is issued. The default threshold is 4096 (12 wildcard bits).
Syntax
SVCoverpointWildCardBinValueSizeWarn = [<value>]
Arguments
• The arguments are described as follows:
o <value> — Any non-negative integer.

ModelSim® SE User's Manual, v10.7 1665

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVCrossNumPrintMissing

SVCrossNumPrintMissing
Section [vsim]
This variable is used to override all other settings for the number of missing values that will be
printed to the coverage report. It overrides both the default value (0, unless otherwise set with
the SVCrossNumPrintMissingDefault variable), as well as any user assignments placed in
SystemVerilog.
Syntax
SVCrossNumPrintMissing = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 0.
Related Topics
SVCrossNumPrintMissingDefault

1666 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVCrossNumPrintMissingDefault

SVCrossNumPrintMissingDefault
Section [vlog]
This variable is used in conjunction with SVCrossNumPrintMissing variable, and overrides the
default value of the SystemVerilog covergroup option.cross_num_print_missing (defined to be
0 in the IEEE Std 1800-2009).
Note
You must recompile the design after changing the setting of this variable.

Syntax
SVCrossNumPrintMissingDefault = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 0.
Related Topics
SVCrossNumPrintMissing

ModelSim® SE User's Manual, v10.7 1667

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SvExtensions

SvExtensions
Section [vlog], [vopt], [vsim]
This variable enables SystemVerilog language extensions. The extensions enable non-LRM
compliant behavior.
Syntax
SvExtensions = [+|-]<val>[,[+|-]<val>] …
Arguments
• The arguments are described as follows:
o [+ | -] — controls activation of the val.
• + — activates the val.
• - — deactivates the val.
• If you do not specify either a “+” or “-”, the variable assumes you are activating
the specified val.
o <val>
• acum — Specifies that the get(), try_get(), peek(), and try_peek() methods on an
untyped mailbox will return successfully if the argument passed is assignment-
compatible with the entry in the mailbox. The LRM-compliant behavior is to
return successfully only if the argument and entry are of equivalent types.
• aswe — Enables support for the symmetric wild equality operators =?= and !?=.
• atpi — Use type names as port identifiers. Disabled when compiling with
-pedanticerrors.
• catx — Allow an assignment of a single un-sized constant in a concat to be
treated as an assignment of 'default:val'.
• cfce — Error message will be generated if $cast is used as a function and the
casting operation fails.
• ctlc — Casts time literals in constraints to the type: time. The LRM dictates that
a time literal, such as “10ns” is to be interpreted as a “realtime” type, but this is
not always adhered to, for example:
class Foo;
rand time t;
constraint c1 {
t < 10ns; // NON-LRM compliant use of ‘real’ type
}
endclass

1668 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SvExtensions

• daoa — Allows the passing a dynamic array as the actual argument of DPI open
array output port. Without this option, a runtime error, similar to the following, is
generated, which is compliant with LRM requirement.
# ** Fatal: (vsim-2211) A dynamic array cannot be passed as an
argument to the DPI import function 'impcall' because the
formal 'o' is an unsized output.

# Time: 0 ns Iteration: 0 Process: /top/#INITIAL#56 File:

dynarray.sv

# Fatal error in Module dynarray_sv_unit at dynarray.sv line 2

• ddup — (Drive Default Unconnected Port) Reverts behavior to where explicit

named unconnected ports are driven by the default value of the port.
• dfsp — (vsim only) Sets the default format specifier to %p if you do not provide
one for unpacked arrays in display-related tasks.
• extscan — (vsim only) Enables support for values greater than 32 bits in string
methods, such as atohex, atoi, atobin, and atooct. By default, these methods
return a 32-bit value irrespective of the variable type. With this extension, the
value returned is as per the size of variable type. For example, given the
following:
longint d;
string s = “12341231234abcd”;
d = s.atohex();

by default, d will be 64’h000000001234abcd, where if you specify extscan, d

will be 64’h123412341234abcd
• evis — Supports the expansion of environment variables within curly braces ( {}
) within `include string literals and in `include path names. For example, if
MYPATH exists in the environment then it will be expanded in the following:
`include "$MYPATH/inc.svh"

• feci — Treat constant expressions in a foreach loop variable index as constant.

• fin0 — Treats $finish() system call as $finish(0), which results in no diagnostic
information being printed.
• idcl — Allows passing of import DPI call locations as implicit scopes.
• iddp — Ignore the DPI task disable protocol check.
• jnds — (vsim only) Schedules the fork/join_none processes at the end of the
active region.
• lfmt — (Legacy Format) Changes data display to show leading zeroes when
displaying decimal values.

ModelSim® SE User's Manual, v10.7 1669

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SvExtensions

• mewq — (vlog only) Allows macro substitutions inside string literals.

• ncref — A ref argument in the new operator of a covergroup will not be treated
as a constant, unless specified.
• nonrandstab — (applies to vsim only) When enabled, any allocation of a new
“non random” class instance will not consume a random number from the
current thread context. A class is considered “non random” when it, or its base
classes, does not declare any rand or randc fields, or it does not invoke
class::randomize() anywhere.
• pae — Automatically export all symbols imported and referenced in a package.
• pael — Allows the export, using wildcard export only, of package symbols from
a subsequent import of a package. These symbols may or may not be referenced
in the exporting package.
• sccts — (default) Process string concatenations converting the result to string
type.
• spsl — (default) Search for packages in source libraries specified with -y and
+libext.
• stop0 — Treats $stop and $stop() as $stop(0), which results in no diagnostic
information being printed.
• substr1 — Allows one argument in the builtin function substr. A second
argument will be treated as the end of the string.
• ubdic — (vlog and vopt only) Allows the use of a variable in a SystemVerilog
class before it is defined. For example:
class A;
function func();
int y = x; // variable ‘x’ is used before it is
defined
endfunction
int x = 1;
endclass

If you do not enable this extension, you will receive unresolved reference errors.
• udm0 — Expands any undefined macro with the text “1'b0”.
• uslt — (default) Promote unused design units found in source library files
specified with the -y option to top-level design units.
• Multiple extensions are specified as a comma separated list. For example:
SvExtensions = +feci,-uslt,pae

1670 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVFileSuffixes

SVFileSuffixes
Section [vlog]
Defines one or more filename suffixes that identify a file as a SystemVerilog file.
Syntax
SVFileSuffixes = <suffix>…
Arguments
• <suffix> …
A space separated list of suffixes, where the default is “sv svp svh”. To insert white space in
an extension, use a backslash (\) as a delimiter. To insert a backslash in an extension, use
two consecutive back-slashes (\\).

ModelSim® SE User's Manual, v10.7 1671

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Svlog

Svlog
Section [vlog]
This variable instructs the vlog compiler to compile in SystemVerilog mode. This variable does
not exist in the default modelsim.ini file, but is added when you select Use SystemVerilog in the
Compile Options dialog box > Verilog and SystemVerilog tab.
Syntax
Svlog = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1672 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SVPrettyPrintFlags

SVPrettyPrintFlags
Section [vsim]
This variable controls the formatting of '%p' and '%P' conversion specifications used in $display
and similar system tasks.
Syntax
SVPrettyPrintFlags=[I<n><S | T>] [L<numLines>] [C<numChars>] [R{d | b | o | h}]
[F<numFields>] [E<numElements>] [D<depth>]
Arguments
• The arguments are described as follows:
o I <n><S | T> — Expand and indent the format for printing records, structures, and
so forth by <n> spaces (S) or <n> tab stops (T).
o <n> — (required) Any positive integer
o S — (required when indenting with spaces) Indent with spaces.
o T — (required when indenting with tab stops) Indent with tab stops.
o For example, SVPrettyPrintFlags=I4S will cause 4 spaces to be used per indentation
level.
o L<numLines> — (optional) Limit the number of lines of output to <numLines>.
o R {d | b | o | h} — (optional) Specify a radix for printing the data specified using the
%p format:
d decimal (default)
b binary
o octal
h hexadecimal
For example, SVPrettyPrintFlags=Rh specifies a hexadecimal radix. Further,
SVPrettyPrintFlags=R shows the output of specifier %p as per the specifed radix. It
changes the output in $display and similar systasks. It does not affect formatted
output functions (such as $displayh).
o <numLines> — (required) Any positive integer.
o For example, SVPrettyPrintFlags=L10 will cause the output to be limited to 10 lines.
o C<numChars> — (optional) Limit the number of characters of output to
<numChars>.
o <numChars> — (required) Any positive integer.
o For example, SVPrettyPrintFlags=C256 will limit the output to 256 characters.

ModelSim® SE User's Manual, v10.7 1673

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVPrettyPrintFlags

o F<numFields> — (optional) Limit the number of fields of records, structures, and so

forth to <numFields>.
o <numFields> — (required) Any positive integer.
o For example, SVPrettyPrintFlags=F4 will limit the output to 4 fields of a structure.
o E<numElements> — (optional) Limit the number of elements of arrays to
<numElements>.
o <numElements> — (required) Any positive integer.
o For example, SVPrettyPrintFlags=E50 will limit the output to 50 elements of an
array.
o D<depth> — (optional) Suppress the output of sub-elements below a specified depth
to <depth>.
o <depth> — (required) Any positive integer.
For example, SVPrettyPrintFlags=D5 will suppresses the output of sub elements
below a depth of 5.
Multiple options are specified as a comma separated list. For example,
SVPrettyPrintFlags=I4S,L20,C256,F4,E50,D5.

1674 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
synopsys

synopsys
Section [vsim]
This variable sets the path to the accelerated arithmetic packages.
Syntax
synopsys = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../synopsys. May
include environment variables.

ModelSim® SE User's Manual, v10.7 1675

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SyncCompilerFiles

SyncCompilerFiles
Section [vcom]
This variable causes compilers to force data to be written to disk when files are closed.
Syntax
SyncCompilerFiles = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1676 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleCountLimit

ToggleCountLimit
Section [vsim]
This variable limits the toggle coverage count for a toggle node. After the limit is reached,
further activity on the node will be ignored for toggle coverage. All possible transition edges
must reach this count for the limit to take effect. For example, if you are collecting toggle data
on 0->1 and 1->0 transitions, both transition counts must reach the limit. If you are collecting
full data on 6 edge transitions, all 6 must reach the limit. If the limit is set to zero, then it is
treated as unlimited.
Syntax
ToggleCountLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer with a maximum positive value of a 32-bit signed
integer and a default of 1.
You can override this variable by specifying vsim -togglecountlimit or toggle add
-countlimit.

ModelSim® SE User's Manual, v10.7 1677

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleDeglitchPeriod

ToggleDeglitchPeriod
Section [vsim]
This variable controls the period of toggle deglitching.
Syntax
ToggleDeglitchPeriod = {“n <time_unit>”}
Arguments
• The arguments are described as follows:
o [n] — A string specifying the number of time units. A value of zero ( 0 ) eliminates
delta cycle glitches.
o <time_unit> — (required) fs, ps, ns, us, ms, or sec.
You must surround n <time_unit> with quotation marks (“ “) when you put a space
between “n” and <time_unit>.

1678 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleFixedSizeArray

ToggleFixedSizeArray
Section [vsim]
This variable is used to control whether Verilog fixed-size unpacked arrays, VHDL multi-
dimensional arrays, and VHDL arrays-of-arrays are included for toggle coverage.
Syntax
ToggleFixedSizeArray = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim {-togglefixedsizearray |
-notogglefixedsizearray}.
Related Topics
set Command Syntax

ModelSim® SE User's Manual, v10.7 1679

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleMaxFixedSizeArray

ToggleMaxFixedSizeArray
Section [vsim]
This variable is used to control the limit on the size of Verilog fixed-size unpacked arrays,
VHDL multi-dimensional arrays, and VHDL arrays-of-arrays that are included for toggle
coverage. Increasing the size of the limit has the effect of increasing the size of the array that
can be included for toggle coverage.
Syntax
ToggleMaxFixedSizeArray = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 1024.
You can override this variable by specifying vsim -togglemaxfixedsizearray.
Related Topics
set Command Syntax

1680 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleMaxIntValues

ToggleMaxIntValues
Section [vsim]
This variable sets the maximum number of unique VHDL integer values to record with toggle
coverage.
Syntax
ToggleMaxIntValues = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 100.
You can override this variable by specifying vsim -togglemaxintvalues.
Related Topics
set Command Syntax

ModelSim® SE User's Manual, v10.7 1681

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleMaxRealValues

ToggleMaxRealValues
Section [vsim]
This variable sets the maximum number of unique SystemVerilog real values to record with
toggle coverage.
Syntax
ToggleMaxIntValues = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer where the default is 100.
You can override this variable by specifying vsim -togglemaxrealvalues.
Related Topics
set Command Syntax

1682 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleNoIntegers

ToggleNoIntegers
Section [vsim]
This variable controls the automatic inclusion of VHDL integer types in toggle coverage.
Syntax
ToggleNoIntegers = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim -notoggleints.

ModelSim® SE User's Manual, v10.7 1683

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
TogglePackedAsVec

TogglePackedAsVec
Section [vsim]
This variable treats Verilog multi-dimensional packed vectors and packed structures as
equivalently sized one_dimensional packed vectors for toggle coverage.
Syntax
TogglePackedAsVec = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -togglepackedasvec.

1684 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
TogglePortsOnly

TogglePortsOnly
Section [vsim]
This variable controls the inclusion into toggle coverage numbers of ports only; when enabled,
all internal nodes are not included in the coverage numbers. When disabled, both ports and
internal nodes are included. In order for this variable to function properly, you must also use
“vopt +acc=p”.
Syntax
TogglePortsOnly = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -toggleportsonly.

ModelSim® SE User's Manual, v10.7 1685

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleVHDLRecords

ToggleVHDLRecords
Section [vsim]
This variable controls the inclusion of VHDL records in toggle coverage metrics. By default,
VHDL records are included in coverage.
Syntax
ToggleVHDLRecords = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim -notogglevhdlrecords.

1686 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleVlogEnumBits

ToggleVlogEnumBits
Section [vsim]
This variable treats Verilog enumerated types as equivalently sized one-dimensional packed
vectors for toggle coverage.
Syntax
ToggleVlogEnumBits = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -togglevlogenumbits.

ModelSim® SE User's Manual, v10.7 1687

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleVlogIntegers

ToggleVlogIntegers
Section [vsim]
This variable controls toggle coverage for SystemVerilog integer types (that is, byte, shortint,
int, longint, but not enumeration types).
Syntax
ToggleVlogIntegers = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim [-togglevlogints |
-notogglevlogints}.

1688 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
ToggleVlogReal

ToggleVlogReal
Section [vsim]
This variable controls toggle coverage for SystemVerilog real value types.
Syntax
ToggleVlogReal = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim {-togglevlogreal |
-notogglevlogreal}.

ModelSim® SE User's Manual, v10.7 1689

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
ToggleWidthLimit

ToggleWidthLimit
Section [vsim]
This variable limits the width of signals that are automatically added to toggle coverage with the
+cover=t argument for vcom or vlog. The limit applies to Verilog registers and VHDL arrays. A
value of 0 is taken as unlimited.
Syntax
ToggleWidthLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer with a maximum positive value of a 32-bit signed
integer and a default of 128.
You can override this variable by specifying vsim -togglewidthlimit.
Related Topics
vcom [ModelSim SE Command Reference Manual]
vlog [ModelSim SE Command Reference Manual]

1690 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
TranscriptFile

TranscriptFile
Section [vsim]
This variable specifies a file for saving a command transcript. You can specify environment
variables in the pathname.
Note
Once you load a modelsim.ini file with TranscriptFile set to a file location, this location will
be used for all output until you override the location with the transcript file command. This
includes the scenario where you load a new design with a new TranscriptFile variable set to a
different file location. You can determine the current path of the transcript file by executing the
transcript path command with no arguments.

Syntax
TranscriptFile = {<filename> | transcript}
Arguments
• The arguments are described as follows:
o <filename> — Any valid filename where transcript is the default.
Related Topics
Batch Mode
AssertFile
BatchMode
BatchTranscriptFile
transcript file [ModelSim SE Command Reference Manual]
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1691

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UCDBFilename

UCDBFilename
Section [vsim]
This variable specifies the default unified coverage database file name that is written at the end
of the simulation. If this variable is set, the UCDB is saved automatically at the end of
simulation. All coverage statistics are saved to the specified .ucdb file.
Syntax
UCDBFilename = {<filename> | vsim.ucdb}
Arguments
• The arguments are described as follows:
o <filename> — Any valid filename where vsim.ucdb is the default.

1692 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
UCDBTestStatusMessageFilter

UCDBTestStatusMessageFilter
Section [vsim]
This variable specifies a regular expression which, if matched when compared against all
messages, prevents the status of that message from being propagated to the UCDB
TESTSTATUS. If this variable is set, the matching regular expression is ignored for all
messages which contain that match.
Syntax
UCDBTestStatusMessageFilter =“<subtext>” [“<additional subtext>”]
Arguments
• The arguments are described as follows:
o <subtext> — Subtext of message you wish to be exempt from altering UCDB
TESTSTATUS.

ModelSim® SE User's Manual, v10.7 1693

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UnattemptedImmediateAssertions

UnattemptedImmediateAssertions
Section [vsim]
This variable controls the inclusion or exclusion of unattempted (un-executed) immediate
assertions from the coverage calculations shown in the UCDB and coverage reports.
Syntax
UnattemptedImmediateAssertions = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off, Excluded
o 1 — On, Included

1694 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
UnbufferedOutput

UnbufferedOutput
Section [vsim]
This variable controls VHDL files open for write.
Syntax
UnbufferedOutput = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off, Buffered
o 1 — On, Unbuffered

ModelSim® SE User's Manual, v10.7 1695

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UndefSyms

UndefSyms
Section [vsim]
This variable allows you to manage the undefined symbols in the shared libraries currently
being loaded into the simulator.
Syntax
UndefSyms = {on | off | verbose}
Arguments
• The arguments are described as follows:
o on — (default) Enables automatic generation of stub definitions for undefined
symbols and permits loading of the shared libraries despite the undefined symbols.
o off — Disables loading of undefined symbols. Undefined symbols trigger an
immediate shared library loading failure.
o verbose — Permits loading to the shared libraries despite the undefined symbols and
reports the undefined symbols for each shared library.

1696 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
UpCase

UpCase
Section [vlog]
This variable instructs ModelSim to activate the conversion of regular Verilog identifiers to
uppercase and allows case insensitivity for module names.
Syntax
UpCase = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
Related Topics
Verilog-XL Compatible Compiler Arguments

ModelSim® SE User's Manual, v10.7 1697

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UserTimeUnit

UserTimeUnit
Section [vsim]
This variable specifies the multiplier for simulation time units and the default time units for
commands such as force and run. Generally, you should set this variable to default, in which
case it takes the value of the Resolution variable.
Note
The value you specify for UserTimeUnit does not affect the display in the Wave window.
To change the time units for the X-axis in the Wave window, choose Wave > Wave
Preferences > Grid & Timeline from the main menu and specify a value for Grid Period.

Syntax
UserTimeUnit = {<time_unit> | default}
Arguments
• The arguments are described as follows:
o <time_unit> — fs, ps, ns, us, ms, sec, or default.
Related Topics
set Command Syntax
Resolution
RunLength
force [ModelSim SE Command Reference Manual]
run [ModelSim SE Command Reference Manual]

1698 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
UseScv

UseScv
Section [sccom]
This variable enables the use of SCV include files and verification library.
Syntax
UseScv = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying sccom -scv.

ModelSim® SE User's Manual, v10.7 1699

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UseSVCrossNumPrintMissing

UseSVCrossNumPrintMissing
Section [vsim]
Specify whether to display and report the value of the “cross_num_print_missing” option for
the Cross in Covergroups. If not specified then “cross_num_print_missing” is ignored for
creating reports and displaying covergroups in GUI. Default is 0, which means ignore
“cross_num_print_missing.”
Syntax
UseSVCrossNumPrintMissing = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1700 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
UseUvmc

UseUvmc
Section [sccom]
This variable controls automatic linking of the precompiled UVMC libraries shipped with
ModelSim.
Usage
UseUvmc = { 0 | 1 }
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

ModelSim® SE User's Manual, v10.7 1701

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
UVMControl

UVMControl
Section [vsim]
This variable controls UVM-Aware debug features. These features work with either a standard
Accelera-released open source toolkit or the pre-compiled UVM library package in ModelSim.
Syntax
UVMControl={all | certe | disable | msglog | none | struct | trlog | verbose}
Arguments
• You must specify at least one argument. You can enable or disable some arguments by
prefixing the argument with a dash (-). Arguments may be specified as multiple instances of
-uvmcontrol. Multiple arguments are specified as a comma separated list without spaces.
Refer to the argument descriptions for more information.
o all — Enables all UVM-Aware functionality and debug options except disable and
verbose. You must specify verbose separately.
o certe — Enables the integration of the elaborated design in the Certe tool. Disables
Certe features when specified as -certe.
o disable — Prevents the UVM-Aware debug package from being loaded. Changes
the results of randomized values in the simulator.
o msglog — Enables messages logged in UVM to be integrated into the Message
Viewer. You must also enable wlf message logging by specifying tran or wlf with
vsim -msgmode. Disables message logging when specified as -msglog
o none — Turns off all UVM-Aware debug features. Useful when multiple
-uvmcontrol options are specified in a separate script, makefile or alias and you want
to be sure all UVM debug features are turned off.
o struct — (default) Enables UVM component instances to appear in the Structure
window. UVM instances appear under “uvm_root” in the Structure window.
Disables Structure window support when specified as -struct.
o trlog — Enables or disables UVM transaction logging. Logs UVM transactions for
viewing in the Wave window. Disables transaction logging when specified as -trlog.
o verbose — Sends UVM debug package information to the transcript. Does not
affect functionality. Must be specified separately.
You can also control UVM-Aware debugging with the -uvmcontrol argument to the
vsim command.

1702 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
verilog

verilog
Section [library]
This variable sets the path to the library containing VHDL/Verilog type mappings.
Syntax
verilog = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../verilog. May
include environment variables.

ModelSim® SE User's Manual, v10.7 1703

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Veriuser

Veriuser
Section [vsim]
This variable specifies a list of dynamically loadable objects for Verilog interface applications.
Syntax
Veriuser = <name>
Arguments
• The arguments are described as follows:
o <name> — One or more valid shared object names where the default is to comment
out the variable.
Related Topics
Registering PLI Applications
vsim [ModelSim SE Command Reference Manual]
restart [ModelSim SE Command Reference Manual]

1704 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
VHDL93

VHDL93
Section [vcom]
This variable enables support for VHDL language version.
Syntax
VHDL93 = {0 | 1 | 2 | 3 | 87 | 93 | 02 | 08 | 1987 | 1993 | 2002 | 2008}
Arguments
• The arguments are described as follows:
o 0 — Support for VHDL-1987. You can also specify 87 or 1987.
o 1 — Support for VHDL-1993. You can also specify 93 or 1993.
o 2 — (default) Support for VHDL-2002. You can also specify 02 or 2002.
o 3 — Support for VHDL-2008. You can also specify 08 or 2008.
You can override this variable by specifying vcom {-87 | -93 | -2002 | -2008}.

ModelSim® SE User's Manual, v10.7 1705

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
VhdlSeparatePduPackage

VhdlSeparatePduPackage
Section [vsim]
This variable turns off sharing of a package from a library between two or more PDUs. Each
PDU will have a separate copy of the package. By default PDUs calling the same package from
a library share one copy of that package.
Syntax
VhdlSeparatePduPackage = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -vhdlmergepdupackage.
Related Topics
vsim [ModelSim SE Command Reference Manual]

1706 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
VhdlVariableLogging

VhdlVariableLogging
Section [vsim]
This switch makes it possible for process variables to be recursively logged or added to the
Wave and List windows (process variables can still be logged or added to the Wave and List
windows explicitly with or without this switch).
Note
Logging process variables is inherently expensive on simulation performance because of
their nature. It is recommended that they not be logged, or added to the Wave and List
windows. However, if your debugging needs require them to be logged, then use of this switch
will lessen the performance hit in doing so.

Syntax
VhdlVariableLogging = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vsim -novhdlvariablelogging.
Description
For example with this vsim switch, log -r /* will log process variables as long as vopt is
specified with +acc=v and the variables are not filtered out by the WildcardFilter (via the
“Variable” entry).

Related Topics
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1707

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
vital2000

vital2000
Section [library]
This variable sets the path to the VITAL 2000 library.
Syntax
vital2000 = <path>
Arguments
• The arguments are described as follows:
o <path> — Any valid path where the default is $MODEL_TECH/../vital2000. May
include environment variables.

1708 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
vlog95compat

vlog95compat
Section [vlog]
This variable instructs ModelSim to disable SystemVerilog and Verilog 2001 support, making
the compiler revert to IEEE Std 1364-1995 syntax.
Syntax
vlog95compat = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying vlog -vlog95compat.

ModelSim® SE User's Manual, v10.7 1709

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WarnConstantChange

WarnConstantChange
Section [vsim]
This variable controls whether a warning is issued when the change command changes the value
of a VHDL constant or generic.
Syntax
WarnConstantChange = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
Related Topics
change [ModelSim SE Command Reference Manual]

1710 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
warning

warning
Section [msg_system]
This variable changes the severity of the listed message numbers to “warning”.
Syntax
warning = <msg_number>…
Arguments
• The arguments are described as follows:
o <msg_number>… — An unlimited list of message numbers, comma separated.
You can override this variable by specifying the sccom, vcom, vlog, vopt, or vsim
command with the -warning argument.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
error
fatal
note
suppress

ModelSim® SE User's Manual, v10.7 1711

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WaveSignalNameWidth

WaveSignalNameWidth
Section [vsim]
This variable controls the number of visible hierarchical regions of a signal name shown in the
Wave Window.
Syntax
WaveSignalNameWidth = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 0 (display full path). 1
displays only the leaf path element, 2 displays the last two path elements, and so on.
You can override this variable by specifying configure -signalnamewidth.
Related Topics
verror [ModelSim SE Command Reference Manual]
Message Severity Level
Wave Window [ModelSim SE GUI Reference Manual]
error
fatal
note
suppress

1712 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WildcardFilter

WildcardFilter
Section [vsim]
This variable sets the default list of object types that are excluded when performing wildcard
matches with simulator commands. The default WildcardFilter variables are loaded every time
you invoke the simulator.
Syntax
WildcardFilter = <object_list>
Arguments
• The arguments are described as follows:
o <object_list> — A space separated list of objects where the default is:
• Variable Constant Generic Parameter SpecParam Memory Assertion Cover
Endpoint ScVariable CellInternal ImmediateAssert VHDLFile
You can override this variable by specifying set WildcardFilter “<object_list>” or by
selecting Tools > Wildcard Filter to open the Wildcard Filter dialog. Refer to Using
the WildcardFilter Preference Variable in the Command Reference Manual for more
information and a list of other possible WildcardFilter object types.
Related Topics
Using the WildcardFilter Preference Variable [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1713

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WildcardSizeThreshold

WildcardSizeThreshold
Section [vsim]
This variable prevents logging of very large non-dynamic objects when performing wildcard
matches with simulator commands, for example, “log -r*” and “add wave *”. Objects of size
equal to or greater than the WildcardSizeThreshold setting will be filtered out of wildcard
matches. The size is a simple calculation of the number of bits or items in the object.
Syntax
WildcardSizeThreshold = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive whole number where the default is 8192 bits (8 k). Specifying 0
disables the checking of the object size against this threshold and allows logging
objects of any size.
You can override this variable by specifying set WildcardSizeThreshold <n>
where <n> is any positive whole number.
Related Topics
Wildcard Characters [ModelSim SE Command Reference Manual]

1714 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WildcardSizeThresholdVerbose

WildcardSizeThresholdVerbose
Section [vsim]
This variable controls whether warning messages are output when objects are filtered out due to
the WildcardSizeThreshold variable.
Syntax
WildcardSizeThresholdVerbose = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On
You can override this variable by specifying set WildcardSizeThresholdVerbose
with a 1 or a 0.
Related Topics
Wildcard Characters [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1715

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFCacheSize

WLFCacheSize
Section [vsim]
This variable sets the number of megabytes for the WLF reader cache. WLF reader caching
caches blocks of the WLF file to reduce redundant file I/O.
Syntax
WLFCacheSize = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default on Linux systems is 2000M. The
default for Windows platforms is 1000M.
You can override this variable by specifying vsim -wlfcachesize.
Related Topics
WLF File Parameter Overview

1716 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFCollapseMode

WLFCollapseMode
Section [vsim]
This variable controls when the WLF file records values.
Syntax
WLFCollapseMode = {0 | 1 | 2}
Arguments
• The arguments are described as follows:
o 0 — Preserve all events and event order. Same as vsim -nowlfcollapse.
o 1 — (default) Only record values of logged objects at the end of a simulator
iteration. Same as vsim -wlfcollapsedelta.
o 2 — Only record values of logged objects at the end of a simulator time step. Same
as vsim -wlfcollapsetime.
You can override this variable by specifying vsim {-nowlfcollapse |
-wlfcollapsedelta | -wlfcollapsetime}.
Related Topics
WLF File Parameter Overview

ModelSim® SE User's Manual, v10.7 1717

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFCompress

WLFCompress
Section [vsim]
This variable enables WLF file compression.
Syntax
WLFCompress = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim -nowlfcompress.
Related Topics
The Runtime Options Dialog
WLF File Parameter Overview

1718 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFDeleteOnQuit

WLFDeleteOnQuit
Section [vsim]
This variable specifies whether a WLF file should be deleted when the simulation ends.
Syntax
WLFDeleteOnQuit = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Do not delete.
o 1 — On.
You can override this variable by specifying vsim -nowlfdeleteonquit.
Related Topics
The Runtime Options Dialog
WLF File Parameter Overview
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1719

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFFileLock

WLFFileLock
Section [vsim]
This variable controls overwrite permission for the WLF file.
Syntax
WLFFileLock = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Allow overwriting of the WLF file.
o 1 — (default) Prevent overwriting of the WLF file.
You can override this variable by specifying vsim -wlflock or vsim -nowlflock.
Related Topics
WLF File Parameter Overview
vsim [ModelSim SE Command Reference Manual]

1720 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFFilename

WLFFilename
Section [vsim]
This variable specifies the default WLF file name.
Syntax
WLFFilename = {<filename> | vsim.wlf}
Arguments
• The arguments are described as follows:
o <filename> — User defined WLF file to create.
vsim.wlf — (default) filename
You can override this variable by specifying vsim -wlf.
Related Topics
WLF File Parameter Overview
set Command Syntax

ModelSim® SE User's Manual, v10.7 1721

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFOptimize

WLFOptimize
Section [vsim]
This variable specifies whether the viewing of waveforms is optimized.
Syntax
WLFOptimize = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On
You can override this variable by specifying vsim -nowlfopt.
Related Topics
WLF File Parameter Overview

1722 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFSaveAllRegions

WLFSaveAllRegions
Section [vsim]
This variable specifies the regions to save in the WLF file.
Syntax
WLSaveAllRegions = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Only save regions containing logged signals.
o 1 — Save all design hierarchy.
Related Topics
The Runtime Options Dialog

ModelSim® SE User's Manual, v10.7 1723

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFSimCacheSize

WLFSimCacheSize
Section [vsim]
This variable sets the number of megabytes for the WLF reader cache for the current simulation
dataset only. WLF reader caching caches blocks of the WLF file to reduce redundant file I/O.
This makes it easier to set different sizes for the WLF reader cache used during simulation, and
those used during post-simulation debug. If the WLFSimCacheSize variable is not specified, the
WLFCacheSize variable is used.
Syntax
WLFSimCacheSize = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer where the default is 500.
You can override this variable by specifying vsim -wlfsimcachesize.
Related Topics
WLFCacheSize
WLF File Parameter Overview

1724 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFSizeLimit

WLFSizeLimit
Section [vsim]
This variable limits the WLF file by size (as closely as possible) to the specified number of
megabytes; if both size (WLFSizeLimit) and time (WLFTimeLimit) limits are specified the
most restrictive is used.
Syntax
WLFSizeLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer in units of MB where the default is 0 (unlimited).
You can override this variable by specifying vsim -wlfslim.
Related Topics
WLFTimeLimit
Limiting the WLF File Size
WLF File Parameter Overview
set Command Syntax

ModelSim® SE User's Manual, v10.7 1725

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFTimeLimit

WLFTimeLimit
Section [vsim]
This variable limits the WLF file by time (as closely as possible) to the specified amount of
time. If both time and size limits are specified the most restrictive is used.
Syntax
WLFTimeLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer in units of MB where the default is 0 (unlimited).
You can override this variable by specifying vsim -wlftlim.
Related Topics
WLF File Parameter Overview
Limiting the WLF File Size
The Runtime Options Dialog
set Command Syntax

1726 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WLFUpdateInterval

WLFUpdateInterval
Section [vsim]
This variable specifies the update interval for the WLF file. After the interval has elapsed, the
live data is flushed to the .wlf file, providing an up to date view of the live simulation. If you
specify 0, the live view of the wlf file is correct, however the file update lags behind the live
simulation.
Syntax
WLFUpdateInterval = <n>
Arguments
• The arguments are described as follows:
o <n> — Any non-negative integer in units of seconds where the default is 10 and 0
disables updating.

ModelSim® SE User's Manual, v10.7 1727

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WLFUseThreads

WLFUseThreads
Section [vsim]
This variable specifies whether the logging of information to the WLF file is performed using
multithreading.
Syntax
WLFUseThreads = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off. Windows systems only, or when one processor is available.
o 1 — On Linux systems only, with more than one processor on the system. When this
behavior is enabled, the logging of information is performed by the secondary
processor while the simulation and other tasks are performed by the primary
processor.
You can override this variable by specifying vsim -nowlfopt.
Related Topics
Limiting the WLF File Size

1728 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WrapColumn

WrapColumn
Section [vsim]
This variable defines the column width when wrapping output lines in the transcript file.
Usage
WrapColumn = <integer>
Arguments
• <integer>
An integer that defines the width, in characters, before forcing a line break. The default
value is 30000.
Description
This column is somewhat soft; the wrap will occur at the first white-space character after
reaching the WrapWSColumn column or at exactly the column width if no white-space is
found.

ModelSim® SE User's Manual, v10.7 1729

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
WrapMode

WrapMode
Section [vsim]
This variable controls wrapping of output lines in the transcript file.
Syntax
WrapMode = {0 | 1 | 2}
Arguments
• 0
(default) Disables wrapping.
• 1
Enables wrapping, based on the value of the WrapColumn variable, which defaults to
30,000 characters.
• 2
Enables wrapping and adds a continuation character (\) at the end of every wrapped line,
except for the last.

1730 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
WrapWSColumn

WrapWSColumn
Section [vsim]
This variable defines the column width when wrapping output lines in the transcript file.
Usage
WrapWSColumn = <integer>
Arguments
• <integer>
An integer that specifies that the wrap will occur at the first white-space character after
reaching the specified number of characters. If there is no white-space, the wrap will occur
at the WrapColumn variable value. The default value is 27000.

ModelSim® SE User's Manual, v10.7 1731

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Commonly Used modelsim.ini Variables

Commonly Used modelsim.ini Variables

Several of the more commonly used modelsim.ini variables are further explained below.
Tip
: When a design is loaded, you can use the where command to display which modelsim.ini
or ModelSim Project File (.mpf) file is in use.

Common Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732

Hierarchical Library Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Turn Off Warnings from Arithmetic Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
Restart Command Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736

Common Environment Variables

You can use environment variables in the modelsim.ini file. Insert a dollar sign ($) before the
name of the environment variable so that its defined value is used. For example:
[Library]
work = $HOME/work_lib
test_lib = ./$TESTNUM/work
...
[vsim]
IgnoreNote = $IGNORE_ASSERTS
IgnoreWarning = $IGNORE_ASSERTS
IgnoreError = 0
IgnoreFailure = 0

Note
The MODEL_TECH environment variable is a special variable that is set by ModelSim (it
is not user-definable). ModelSim sets this value to the name of the directory from which the
VCOM or VLOG compilers or the VSIM simulator was invoked. This directory is used by other
ModelSim commands and operations to find the libraries.

1732 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Hierarchical Library Mapping

Hierarchical Library Mapping

By adding an “others” clause to your modelsim.ini file, you can have a hierarchy of library
mappings. If the ModelSim tools do not find a mapping in the modelsim.ini file, then they will
search only the library section of the initialization file specified by the “others” clause. For
example:
[Library]
asic_lib = /cae/asic_lib
work = my_work
others = /install_dir/modeltech/modelsim.ini

Since the file referred to by the “others” clause may itself contain an “others” clause, you can
use this feature to chain a set of hierarchical INI files for library mappings.

Creating a Transcript File

You can use the TranscriptFile variable to keep a record of everything that is sent to the
transcript from stdout: error messages, assertions, commands, command outputs, and so forth.
To do this, set the value for the TranscriptFile line in the modelsim.ini file to the name of the file
in which you would like to record the ModelSim history. You can also choose what type of data
to send to the transcript with the Stats variable.

; Save the command window contents to this file

TranscriptFile = trnscrpt

You can prevent overwriting older transcript files by including a pound sign (#) in the name of
the file. The simulator replaces the ’#’ character with the next available sequence number when
saving a new transcript file.

When you invoke vsim using the default modelsim.ini file, a transcript file is opened in the
current working directory. If you then change (cd) to another directory that contains a different
modelsim.ini file with a TranscriptFile variable setting, the simulator continues to save to the
original transcript file in the former location. You can change the location of the transcript file
to the current working directory by:

• changing the preference setting (Tools > Edit Preferences > By Name > Main > file).
• using the transcript file command.
To limit the amount of disk space used by the transcript file, you can set the maximum size of
the transcript file with the transcript sizelimit command.

You can disable the creation of the transcript file by using the following ModelSim command
immediately after ModelSim starts:

transcript file ""

ModelSim® SE User's Manual, v10.7 1733

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Using a Startup File

Related Topics
TranscriptFile
Stats

Using a Startup File

The system initialization file allows you to specify a command or a .do file that is to be executed
after the design is loaded. For example:
; VSIM Startup command
Startup = do mystartup.do

The line shown above instructs ModelSim to execute the commands in the DO file named
mystartup.do.

; VSIM Startup command

Startup = run -all

The line shown above instructs VSIM to run until there are no events scheduled.

Refer to the do command for additional information on creating DO files.

Turn Off Assertion Messages

You can turn off assertion messages from your VHDL code by setting a variable in the
modelsim.ini file. This option was added because some utility packages print a huge number of
warnings.
[vsim]
IgnoreNote = 1
IgnoreWarning = 1
IgnoreError = 1
IgnoreFailure = 1

Turn Off Warnings from Arithmetic Packages

You can disable warnings from the Synopsys and numeric standard packages by adding the
following lines to the [vsim] section of the modelsim.ini file.
[vsim]
NumericStdNoWarnings = 1
StdArithNoWarnings = 1

1734 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Force Command Defaults

These variables can also be set interactively using the Tcl set Command Syntax. This capability
provides an answer to a common question about disabling warnings at time 0. You might enter
commands like the following in a DO file or at the ModelSim prompt:

set NumericStdNoWarnings 1
run 0
set NumericStdNoWarnings 0
run -all

Force Command Defaults

The force command has -freeze, -drive, and -deposit arguments. When none of these is
specified, then -freeze is assumed for unresolved signals and -drive is assumed for resolved
signals. But if you prefer -freeze as the default for both resolved and unresolved signals, you can
change the defaults in the modelsim.ini file.
[vsim]
; Default Force Kind
; The choices are freeze, drive, or deposit
DefaultForceKind = freeze

Related Topics
force [ModelSim SE Command Reference Manual]

Restart Command Defaults

The restart command has -force, -nobreakpoint, -nofcovers, -nolist, -nolog, and -nowave
arguments. You can set any of these as defaults by entering the following line in the
modelsim.ini file.
DefaultRestartOptions = <options>

where <options> can be one or more of -force, -nobreakpoint, -nofcovers, -nolist, -nolog, and
-nowave.

Example:

DefaultRestartOptions = -nolog -force

Related Topics
restart [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1735

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
VHDL Standard

VHDL Standard
You can specify which version of the 1076 Std ModelSim follows by default using the
VHDL93 variable.
[vcom]
; VHDL93 variable selects language version as the default.
; Default is VHDL-2002.
; Value of 0 or 1987 for VHDL-1987.
; Value of 1 or 1993 for VHDL-1993.
; Default or value of 2 or 2002 for VHDL-2002.
VHDL93 = 2002

Related Topics
VHDL93

Delay Opening VHDL Files

You can delay the opening of VHDL files with an entry in the modelsim.ini file if you wish.
Normally VHDL files are opened when the file declaration is elaborated. If the DelayFileOpen
option is enabled, then the file is not opened until the first read or write to that file.
[vsim]
DelayFileOpen = 1

Related Topics
DelayFileOpen

1736 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix B
Location Mapping

Pathnames to source files are recorded in libraries by storing the working directory from which
the compile is invoked and the pathname to the file as specified in the invocation of the
compiler. The pathname may be either a complete pathname or a relative pathname.
Referencing Source Files with Location Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738

ModelSim® SE User's Manual, v10.7 1737

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Location Mapping
Referencing Source Files with Location Maps

Referencing Source Files with Location Maps

ModelSim tools that reference source files from the library locate a source file in two ways.
• If the pathname stored in the library is complete, then this is the path used to reference
the file.
• If the pathname is relative, then the tool looks for the file relative to the current working
directory. If this file does not exist, then the path relative to the working directory stored
in the library is used.
This method of referencing source files generally works fine if the libraries are created and used
on a single system. However, when multiple systems access a library across a network, the
physical pathnames are not always the same and the source file reference rules do not always
work.

Using Location Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738

Pathname Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
How Location Mapping Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739

Using Location Mapping

Location maps are used to replace prefixes of physical pathnames in the library with
environment variables. The location map defines a mapping between physical pathname
prefixes and environment variables.
ModelSim tools open the location map file on invocation if the MGC_LOCATION_MAP
environment variable is set. If MGC_LOCATION_MAP is not set, ModelSim will look for a
file named "mgc_location_map" in the following locations, in order:

• the current directory

• your home directory
• the directory containing the ModelSim binaries
• the ModelSim installation directory
You can map your files in two steps.

Procedure
1. Set the environment variable MGC_LOCATION_MAP to the path of your location map
file.
2. Specify the mappings from physical pathnames to logical pathnames:
$SRC
/home/vhdl/src
/usr/vhdl/src

1738 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Location Mapping
Pathname Syntax

$IEEE
/usr/modeltech/ieee

Pathname Syntax
The logical pathnames must begin with $ and the physical pathnames must begin with /. The
logical pathname is followed by one or more equivalent physical pathnames. Physical
pathnames are equivalent if they refer to the same physical directory (they just have different
pathnames on different systems).

How Location Mapping Works

When a pathname is stored, an attempt is made to map the physical pathname to a path relative
to a logical pathname.
This is done by searching the location map file for the first physical pathname that is a prefix to
the pathname in question. The logical pathname is then substituted for the prefix. For example,
“/usr/vhdl/src/test.vhd” is mapped to “$SRC/test.vhd”. If a mapping can be made to a logical
pathname, then this is the pathname that is saved. The path to a source file entry for a design
unit in a library is a good example of a typical mapping.

For mapping from a logical pathname back to the physical pathname, ModelSim expects an
environment variable to be set for each logical pathname (with the same name). ModelSim
reads the location map file when a tool is invoked. If the environment variables corresponding
to logical pathnames have not been set in your shell, ModelSim sets the variables to the first
physical pathname following the logical pathname in the location map. For example, if you do
not set the SRC environment variable, ModelSim will automatically set it to “/home/vhdl/src”.

ModelSim® SE User's Manual, v10.7 1739

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Location Mapping
How Location Mapping Works

1740 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix C
Error and Warning Messages

This appendix describes the messages and status information that ModelSim displays in the
Transcript window.
Message System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Suppression of Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
Miscellaneous Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1748
Error Messages from the sccom Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
Enforcing Strict 1076 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753

ModelSim® SE User's Manual, v10.7 1741

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Message System

Message System
The ModelSim message system helps you identify and troubleshoot problems while using the
application. The messages display in a standard format in the Transcript window.
Accordingly, you can also access them from a saved transcript file (see Saving the Transcript
File for more details).

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742

Getting More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Message Severity Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Syntax Error Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743

Message Format
The format for messages consists of several fields.
The fields for a given message appear as:

** <SEVERITY LEVEL>: ([<Tool>[-<Group>]]-<MsgNum>) <Message>

• SEVERITY LEVEL — may be one of the following:

Table C-1. Severity Level Types

severity level meaning
Note This is an informational message.
Warning There may be a problem that will affect the accuracy of
your results.
Error The tool cannot complete the operation.
Fatal The tool cannot complete execution.
INTERNAL ERROR This is an unexpected error that should be reported to your
support representative.

• Tool — indicates which ModelSim tool was being executed when the message was
generated. For example, tool could be vcom, vdel, vsim, and so forth.
• Group — indicates the topic to which the problem is related. For example group could
be PLI, VCD, and so forth.

Example
# ** Error: (vsim-PLI-3071) ./src/19/testfile(77): $fdumplimit : Too few
arguments.

1742 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Getting More Information

Getting More Information

Each message is identified by a unique MsgNum id consisting of four numerical digits.
You can access additional information about a message using the unique id and the verror
command. For example:

% verror 3071
Message # 3071:
Not enough arguments are being passed to the specified system task or
function.

Message Severity Level

You can suppress or change the severity of notes, warnings, and errors that come from vcom,
vlog, and vsim commands. You cannot suppress Fatal or Internal messages or change their
severity.
There are three ways to modify the severity of or to suppress notes, warnings, and errors:

Related Topics
Suppression of Warning Messages

Syntax Error Debug Flow

ModelSim commands issue errors when you provide design files that have syntax errors due to
typos or illegal code. You can work to debug these errors using this flow.
Procedure
1. Begin with the first error issued by the command.
2. Review the error message for a specific error number and information about the
filename and line number.
3. Use the verror command to access more information about the error number.
4. Review the area around the line number for typos in identifiers and correct as needed.
5. Review the previous line for a malformed token or missing semicolon (;) or other ending
bracket and correct as needed.
6. Review the specific line to ensure the syntax is legal based on the BNF of the language
used and correct as needed.
7. Run the command again and repeat these steps for any further messages.

ModelSim® SE User's Manual, v10.7 1743

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Suppression of Warning Messages

Suppression of Warning Messages

You can suppress the display of a specific warning message or categories of warning messages
that are trivial or not relevant to operation of a given command. For example, you can suppress
warning messages about unbound components that you are not interested in seeing.
Each of the following commands provides an argument you can specify to control the display of
warning messages issued while that command is running:

• vcom — see Suppress Warning Messages for the vcom Command.

• vlog — see Suppress Warning Messages for the vlog Command.
• vopt — see Suppress Warning Messages for the vopt Command.
• vsim — see Suppress Warning Messages for the vsim Command.

Suppress Warning Messages for the vcom Command

Use the vcom -nowarn <category_number> argument to suppress a specific warning message.
For example:

vcom -nowarn 1

suppresses unbound component warning messages.

Alternatively, warnings may be disabled for all compiles via the Main window Compile >
Compile Options menu selections or the modelsim.ini file (see modelsim.ini Variables).

The warning message category numbers are:

1 = unbound component
2 = process without a wait statement
3 = null range
4 = no space in time literal
5 = multiple drivers on unresolved signal
6 = VITAL compliance checks ("VitalChecks" also works)
7 = VITAL optimization messages
8 = lint checks
9 = signal value dependency at elaboration
10 = VHDL-1993 constructs in VHDL-1987 code
11 = PSL warnings
13 = constructs that coverage cannot handle
14 = locally static error deferred until simulation run

These numbers are unrelated to vcom arguments that are specified by numbers, such as vcom -
87 – which disables support for VHDL-1993 and 2002.

1744 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Suppression of Warning Messages

Suppress Warning Messages for the vlog Command

Use the vlog -nowarn <category_number> command to suppress a specific warning message.
The warning message category numbers for vlog are:

11 = PSL warnings
12 = non-LRM compliance in order to match other product behavior
13 = constructs that coverage cannot handle
15 = SystemVerilog assertions using local variable

Alternatively, you can use the +nowarn<CODE> argument with the vlog command to suppress
a specific warning message. Warning messages that can be disabled this way contain the
<CODE> string in square brackets, [ ].

For example:

vlog +nowarnDECAY

suppresses decay warning messages.

Suppress Warning Messages for the vopt Command

Use the vopt -nowarn <category_number> command to suppress a specific warning message.
For example:

vopt -nowarn 1

suppresses unbound component warning messages.

Alternatively, you can disable warnings for all compiles by choosing Compile > Compile
Options from the main menu in the Main window or by editing the modelsim.ini file (see
modelsim.ini Variables).

The warning message category numbers are:

1 = unbound component
2 = process without a wait statement
3 = null range
4 = no space in time literal
5 = multiple drivers on unresolved signal
6 = VITAL compliance checks (“VitalChecks” also works)
7 = VITAL optimization messages
8 = lint checks
9 = signal value dependency at elaboration
10 = VHDL-1993 constructs in VHDL-1987 code
11 = PSL warnings
12 = non-LRM compliance in order to match other product behavior
13 = constructs that coverage cannot handle
14 = locally static error deferred until simulation run
15 = SystemVerilog assertions using local variable

ModelSim® SE User's Manual, v10.7 1745

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Exit Codes

Or, you can use the +nowarn<CODE> argument with the vopt command to suppress a specific
warning message. Warnings that can be disabled include the <CODE> name in square brackets
in the warning message. For example:

vopt +nowarnDECAY

suppresses decay warning messages.

Suppress Warning Messages for the vsim Command

Use the vsim +nowarn<CODE> command to suppress a specific warning message. Warnings
that can be disabled include the <CODE> name in square brackets [ ] in the warning message.
For example:

vsim +nowarnTFMPC

suppresses warning messages about too few port connections.

You can use vsim -msglimit <msg_number>[,<msg_number>,…], or the MsgLimitCount

variable in the modelsim.ini file, to limit the number of times specific warning message(s) are
displayed to five. All instances of the specified messages are suppressed after the limit is
reached.

Exit Codes
When ModelSim exits a process, it displays a numerical exit code in the Transcript window.
Each code corresponds to a status condition of the process or operation.
Table C-1 lists the exit codes used by ModelSim commands, processes, and languages.
Table C-2. Exit Codes
Exit code Description
0 Normal (non-error) return
1 Incorrect invocation of tool
2 Previous errors prevent continuing
3 Cannot create a system process (execv, fork, spawn, and so
forth.)
4 Licensing problem
5 Cannot create/open/find/read/write a design library
6 Cannot create/open/find/read/write a design unit
7 Cannot open/read/write/dup a file (open, lseek, write, mmap,
munmap, fopen, fdopen, fread, dup2, and so forth.)
8 File is corrupted or incorrect type, version, or format of file

1746 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Exit Codes

Table C-2. Exit Codes (cont.)

Exit code Description
9 Memory allocation error
10 General language semantics error
11 General language syntax error
12 Problem during load or elaboration
13 Problem during restore
14 Problem during refresh
15 Communication problem (Cannot create/read/write/close pipe/
socket)
16 Version incompatibility
19 License manager not found/unreadable/unexecutable (vlm/
mgvlm)
22 SystemC link error
23 SystemC DPI internal error
24 SystemC archive error
42 Lost license
43 License read/write failure
44 Modeltech daemon license checkout failure #44
45 Modeltech daemon license checkout failure #45
90 Assertion failure (SEVERITY_QUIT)
93 Reserved for Verification Run Manager
99 Unexpected error in tool
100 GUI Tcl initialization failure
101 GUI Tk initialization failure
102 GUI IncrTk initialization failure
111 X11 display error
201 Hang Up (SIGHUP)
202 Interrupt (SIGINT)
204 Illegal instruction (SIGILL)
205 Trace trap (SIGTRAP)
206 Abort (SIGABRT)

ModelSim® SE User's Manual, v10.7 1747

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Miscellaneous Messages

Table C-2. Exit Codes (cont.)

Exit code Description
208 Floating point exception (SIGFPE)
210 Bus error (SIGBUS)
211 Segmentation violation (SIGSEGV)
213 Write on a pipe with no reader (SIGPIPE)
214 Alarm clock (SIGALRM)
215 Software termination signal from kill (SIGTERM)
216 User-defined signal 1 (SIGUSR1)
217 User-defined signal 2 (SIGUSR2)
218 Child status change (SIGCHLD)
230 Exceeded CPU limit (SIGXCPU)
231 Exceeded file size limit (SIGXFSZ)

Miscellaneous Messages
This section describes miscellaneous messages that may appear for various ModelSim
commands, processes, or design languages.

Compilation of DPI Export TFs Error

# ** Fatal: (vsim-3740) Can't locate a C compiler for compilation of
DPI export tasks/functions.

• Description — ModelSim was unable to locate a C compiler to compile the DPI

exported tasks or functions in your design.
• Suggested Action —Make sure that a C compiler is visible from where you are running
the simulation.

Empty port name warning

# ** WARNING: [8] <path/file_name>: empty port name in port list.

• Description — ModelSim reports these warnings if you use the -lint argument to vlog.
It reports the warning for any NULL module ports.
• Suggested action — If you want to suppress this warning, do not use the -lint argument.

Lock message
waiting for lock by user@user. Lockfile is <library_path>/_lock

1748 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Miscellaneous Messages

• Description — ModelSim creates a _lock file in a library when you begin a compilation
into that library; it is removed when the compilation completes. This prevents
simultaneous updates to the library. If a previous compile did not terminate properly,
ModelSim may fail to remove the _lock file.
• Suggested action — Manually remove the _lock file after making sure that no one else
is actually using that library.

Metavalue detected warning

Warning: NUMERIC_STD.">": metavalue detected, returning FALSE

• Description — This warning is an assertion being issued by the IEEE numeric_std

package. It indicates that there is an 'X' in the comparison.
• Suggested action — The message does not indicate which comparison is reporting the
problem since the assertion is coming from a standard package. To track the problem,
note the time the warning occurs, restart the simulation, and run to one time unit before
the noted time. At this point, start stepping the simulator until the warning appears. The
location of the blue arrow in a Source window will be pointing at the line following the
line with the comparison.
You can turn off these messages by setting the NumericStdNoWarnings variable to 1
from the command line or in the modelsim.ini file.

Sensitivity list warning

signal is read by the process but is not in the sensitivity list

• Description — ModelSim displays this message when you use the -check_synthesis
argument to vcom. This warning occurs for any signal that is read by the process but is
not in the sensitivity list.
• Suggested action — There are cases where you may purposely omit signals from the
sensitivity list even though they are read by the process. For example, in a strictly
sequential process, you may prefer to include only the clock and reset in the sensitivity
list because it would be a design error if any other signal triggered the process. In such
cases, your only option is to omit the -check_synthesis argument.

Tcl Initialization error 2

Tcl_Init Error 2 : Can't find a usable Init.tcl in the following
directories :
./../tcl/tcl8.3 .

• Description — This message typically occurs when the base file was not included in a
Linux installation. When you install ModelSim, you need to download and install 3 files
from the ftp site. These files are:
modeltech-base.mis

ModelSim® SE User's Manual, v10.7 1749

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Miscellaneous Messages

modeltech-docs.mis

install.<platform>

If you install only the <platform> file, you will not get the Tcl files that are located in the
base file.
This message could also occur if the file or directory was deleted or corrupted.
• Suggested action — Reinstall ModelSim with all three files.

Too few port connections

# ** Warning (vsim-3017): foo.v(1422): [TFMPC] - Too few port
connections. Expected 2, found 1.
# Region: /foo/tb

• Description — This warning occurs when an instantiation has fewer port connections
than the corresponding module definition. The warning does not necessarily mean
anything is wrong; it is legal in Verilog to have an instantiation that does not connect all
of the pins. However, someone that expects all pins to be connected would like to see
such a warning.
The following examples demonstrate legal instantiations that will and will not cause the
warning message.
o Module definition
module foo (a, b, c, d);

o Instantiation that does not connect all pins but will not produce the warning
foo inst1(e, f, g, ); // positional association
foo inst1(.a(e), .b(f), .c(g), .d()); // named association

o Instantiation that does not connect all pins but will produce the warning
foo inst1(e, f, g); // positional association
foo inst1(.a(e), .b(f), .c(g)); // named association

o Any instantiation above will leave pin d unconnected but the first example has a
placeholder for the connection. Another example is:
foo inst1(e, , g, h);
foo inst1(.a(e), .b(), .c(g), .d(h));

• Suggested actions —
o Check for an extra comma at the end of the port list. For example:
model(a,b,)

The extra comma is legal Verilog, but it implies that there is a third port connection
that is unnamed.

1750 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Miscellaneous Messages

o If you are purposefully leaving pins unconnected, you can disable these messages
using the +nowarnTFMPC argument to vsim.

VSIM license lost

Console output:
Signal 0 caught... Closing vsim vlm child.
vsim is exiting with code 4
FATAL ERROR in license manager

transcript/vsim output:
# ** Error: VSIM license lost; attempting to re-establish.
# Time: 5027 ns Iteration: 2
# ** Fatal: Unable to kill and restart license process.
# Time: 5027 ns Iteration: 2

• Description — ModelSim queries the license server for a license at regular intervals.
Usually a “License Lost” error message indicates that network traffic is high, and
communication with the license server times out.
• Suggested action — Any action you can take to improve network communication with
the license server has a chance of solving or decreasing the frequency of this problem.

Failed to find libswift entry

** Error: Failed to find LMC Smartmodel libswift entry in project file.
# Fatal: Foreign module requested halt

• Description — ModelSim could not locate the libswift entry and therefore could not
link to the Logic Modeling library.
• Suggested action — Uncomment the appropriate libswift entry in the [lmc] section of
the modelsim.ini or project .mpf file. See VHDL SmartModel Interface for more
information.

Detecting Infinite Zero-Delay Loops

# ** Error: (vsim-3601) Iteration limit reached at time 132025 ps.

• Description — ModelSim has ended the simulation after 10000000 iterations in a zero-
delay oscillation. The IterationLimit modelsim.ini variable sets the number of iterations
before issuing the error.
• Suggested action — Follow these steps to find and debug the zero-delay loop causing
the error.
1. Re-run vopt with +acc to open full visibility to the design.
2. Re-run vsim with +autofindloop.
This will produce the vsim-3601 error again, but this time with information about zero-
delay loops.

ModelSim® SE User's Manual, v10.7 1751

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Error Messages from the sccom Command

# ** Error: (vsim-3601) Iteration limit reached at time 132025 ps.

# This is a zero-delay loop:

# /top/#ALWAYS#5 src/alcomb.sv:5
# /top/#ALWAYS#8 src/alcomb.sv:8
# /top/#ALWAYS#14 src/alcomb.sv:14

3. Use this information to debug any loops in your design. The following are potential
coding techniques that lead to zero-delay loops:
o A missing or incorrectly applied SDF annotation to a netlist.
o An RTL design with an asynchronous feedback loop with no delays.
o Processes without wait statements or sensitivity lists, for example:
a <= not b;
b <= not a;

o A long string of assignments in VHDL, such as:

a1 <= a0;
a2 <= a1;
...
a500 <= a499;

Error Messages from the sccom Command

For designs written in SystemC, you use the sccom command.
This section describes error messages that may be associated with ModelSim when using the
sccom command.

Failed to load sc lib error: undefined symbol

# ** Error: (vsim-3197) Load of
"/home/cmg/newport2_systemc/chip/vhdl/work/systemc.so"
failed:ld.so.1:
/home/icds_nut/modelsim/5.8a/sunos5/vsimk:
fatal: relocation error: file
/home/cmg/newport2_systemc/chip/vhdl/work/systemc.so:
symbol_Z28host_respond_to_vhdl_requestPm:
referenced symbol not found.
# ** Error: (vsim-3676) Could not load shared library
/home/cmg/newport2_systemc/chip/vhdl/work/systemc.so
for SystemC module 'host_xtor'.

• Description — The causes for such an error could be:

o missing symbol definition
o bad link order specified in sccom -link
o multiply defined symbols (see Source of Undefined Symbol Message)

1752 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Enforcing Strict 1076 Compliance

• Suggested action —
o If the undefined symbol is a C function in your code or a library you are linking
with, be sure that you declared it as an external “C” function:
extern "C" void myFunc();

o The order in which you place the -link option within the sccom -link command is
critical. Make sure you have used it appropriately. See sccom for syntax and usage
information. See Misplaced -link Option for further explanation of error and
correction.

Multiply defined symbols

work/sc/gensrc/test_ringbuf.o: In function
`test_ringbuf::clock_generator(void)':
work/sc/gensrc/test_ringbuf.o(.text+0x4): multiple definition of
`test_ringbuf::clock_generator(void)'
work/sc/test_ringbuf.o(.text+0x4): first defined here

• Meaning — The most common type of error found during sccom -link operation is the
multiple symbol definition error. This typically arises when the same global symbol is
present in more than one .o file. Several causes are likely:
o A common cause of multiple symbol definitions involves incorrect definition of
symbols in header files. If you have an out-of-line function (one that is not preceded
by the “inline” keyword) or a variable defined (that is, not just referenced or
prototyped, but truly defined) in a .h file, you cannot include that .h file in more than
one .cpp file.
o Another cause of errors is due to ModelSim’s name association feature. The name
association feature automatically generates .cpp files in the work library. These files
include your header files. Thus, while it might appear as though you have included
your header file in only one .cpp file, from the linker’s point of view, it is included in
multiple .cpp files.
• Suggested action — Make sure you do not have any out-of-line functions. Use the
“inline” keyword. See Multiple Symbol Definitions.

Enforcing Strict 1076 Compliance

The optional -pedanticerrors argument to vcom enforces strict compliance to the IEEE Std
1076-2002, IEEE Standard VHDL Language Reference Manual (LRM) in the cases listed
below. The default behavior for these cases is to issue a warning message that is not
suppressible.
If you compile with vcom -pedanticerrors, the warnings change to an error, unless otherwise
noted. Descriptions in quotes are actual warning/error messages emitted by vcom. As noted, in
some cases you can suppress the warning using vcom -nowarn [level].

ModelSim® SE User's Manual, v10.7 1753

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Enforcing Strict 1076 Compliance

• Type conversion between array types, where the element subtypes of the arrays do not
have identical constraints.
• “Extended identifier terminates at newline character (0xa).”
• “Extended identifier contains non-graphic character 0x%x.”
• “Extended identifier \"%s\" contains no graphic characters.”
• “Extended identifier \"%s\" did not terminate with backslash character.”
• “An abstract literal and an identifier must have a separator between them.”
This is for forming physical literals, which comprise an optional numeric literal,
followed by a separator, followed by an identifier (the unit name). Warning is level 4,
which means “-nowarn 4” will suppress it.
• In VHDL 1993 or 2002, a subprogram parameter was declared using VHDL 1987
syntax (which means that it was a class VARIABLE parameter of a file type, which is
the only way to do it in VHDL 1987 and is illegal in later VHDLs). Warning is level 10.
• “Shared variables must be of a protected type.” Applies to VHDL 2002 only.
• Expressions evaluated during elaboration cannot depend on signal values. Warning is
level 9.
• “Non-standard use of output port '%s' in PSL expression.” Warning is level 11.
• “Non-standard use of linkage port '%s' in PSL expression.” Warning is level 11.
• Type mark of type conversion expression must be a named type or subtype, it cannot
have a constraint on it.
• When the actual in a PORT MAP association is an expression, it must be a (globally)
static expression. The port must also be of mode IN.
• The expression in the CASE and selected signal assignment statements must follow the
rules given in Section 8.8 of the IEEE Std 1076-2002. In certain cases we can relax these
rules, but -pedanticerrors forces strict compliance.
• A CASE choice expression must be a locally static expression. We allow it to be only
globally static, but -pedanticerrors will check that it is locally static. Same rule for
selected signal assignment statement choices. Warning level is 8.
• When making a default binding for a component instantiation, ModelSim's non-standard
search rules found a matching entity. Section 5.2.2 of the IEEE Std 1076-2002 describes
the standard search rules. Warning level is 1.
• Both FOR GENERATE and IF GENERATE expressions must be globally static. We
allow non-static expressions unless -pedanticerrors is present.
• When the actual part of an association element is in the form of a conversion function
call [or a type conversion], and the formal is of an unconstrained array type, the return

1754 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Error and Warning Messages
Enforcing Strict 1076 Compliance

type of the conversion function [type mark of the type conversion] must be of a
constrained array subtype. We relax this (with a warning) unless -pedanticerrors is
present when it becomes an error.
• OTHERS choice in a record aggregate must refer to at least one record element.
• In an array aggregate of an array type whose element subtype is itself an array, all
expressions in the array aggregate must have the same index constraint, which is the
element's index constraint. No warning is issued; the presence of -pedanticerrors will
produce an error.
• Non-static choice in an array aggregate must be the only choice in the only element
association of the aggregate.
• The range constraint of a scalar subtype indication must have bounds both of the same
type as the type mark of the subtype indication.
• The index constraint of an array subtype indication must have index ranges each of
whose both bounds must be of the same type as the corresponding index subtype.
• When compiling VHDL 1987, various VHDL 1993 and 2002 syntax is allowed. Use
-pedanticerrors to force strict compliance. Warnings are all level 10.
• For a FUNCTION having a return type mark that denotes a constrained array subtype, a
RETURN statement expression must evaluate to an array value with the same index
range(s) and direction(s) as that type mark. This language requirement (Section 8.12 of
the IEEE Std 1076-2002) has been relaxed such that ModelSim displays only a compiler
warning and then performs an implicit subtype conversion at run time.
To enforce the prior compiler behavior, use vcom -pedanticerrors.

ModelSim® SE User's Manual, v10.7 1755

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Error and Warning Messages
Enforcing Strict 1076 Compliance

1756 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix D
Questa Verification IP Errors

The Questa Verification IP library contains a number of industry standard protocols that you
can use to verify legal protocol activity.
Note
The functionality described in this chapter requires an additional license feature for
ModelSim SE. Refer to "License Feature Names" in the Installation and Licensing Guide
for more information, or contact your Mentor Graphics sales representative.

The activity may be between a transaction-level model (TLM) and a wire-level models (WLM),
or activity between WLMs. Each QVIP library protocol has built-in error-checking to cover a
vast range of situations whereby the activity on the protocol signals may be illegal. If illegal
activity occurs, then a QuestaSim 60000 series error code specific to the protocol is normally
reported, along with an explanation of the illegality and a reference to the protocol specification
to assist in the debugging of the testbench or DUT.

There may be a circumstance when a QuestaSim 60000 series error is not reported as a result of
illegal protocol activity. In an attempt to assist in the debugging of such errors, the Questa
Verification IP reports 50000 series errors instead. These 50000 series errors are not protocol
specific and report internal errors found within the Questa Verification IP due to the illegal
protocol activity. To completely understand the meaning of each error would require intimate
knowledge of the Questa Verification IP internal workings, but an understanding of the basic
concepts and terminology used within the 50000 series error messages may help to speed up the
process of debugging your testbench and DUT.

60000 series error protocol specific documentation is supplied with the Questa Verification IP
software (see “Accessing 60000 Series Error Documentation”).

Note
It is more usual for a QuestaSIM 60000 series protocol specific error to be reported than an
internal Questa Verification IP 50000 series error.

This appendix provides an explanation of both the concepts behind the Questa Verification IP
50000 series errors, and the terminology used in the reporting of those errors. The aim of doing
so is to assist you in the debugging of your testbench and DUT.

Accessing 60000 Series Error Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758

Why Series 50000 Errors Occur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
Concepts Involved in the Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762

ModelSim® SE User's Manual, v10.7 1757

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Accessing 60000 Series Error Documentation

Transaction Types and Time Queue ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762

Parents and Children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
Deleted Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
Understanding the ‘Time Queue’ ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
Viewing the Time Queue ID Number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
TQ Id Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
Understanding ‘Parents’ and ‘Children’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
Parent/Child Relationship Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
Understanding Generation and Recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1774
Generation/Recognition Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775
Understanding Deletions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Deletion Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Understanding Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Activated Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1780
Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1782
Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1783
Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
Understanding Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
Understanding the Volatile Clause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
Volatile Clause Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
Understanding Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
Activity Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
Understanding ‘Throw’ and ‘Catch’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Throw and Catch Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Understanding TLM and WLM Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
WLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
WLM-connected and TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791

Accessing 60000 Series Error Documentation

The 60000 series documentation is included in the install.

1758 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Accessing 60000 Series Error Documentation

Note
To access documentation regarding the 60000 series errors, you must open a browser to a
specific path within the installed QVIP library:

Procedure
1. Open the QVIP documentation in your web browser using:
<QVIP_install_directory>/docs/index.html

This opens the InfoHub for the QVIP library (Figure D-1).
Figure D-1. InfoHub for QVIP Library

ModelSim® SE User's Manual, v10.7 1759

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Why Series 50000 Errors Occur

2. Choose the documentation set of the QVIP protocol family you want by clicking the
appropriate selection on the left hand column titled "Choose Scope," for example,
“AMBA Family QVIPs.”
3. Choose the documentation of the QVIP protocol by clicking the appropriate item under
the section titled "API Reference Information," for example, AHB QUIP API Reference.
Figure D-2. QVIP API Reference Information

4. Select "Assertions" on the left hand column (Figure D-3) to see the list of 6000 series
messages.
Figure D-3. Select Assertions

5. Click the appropriate 6000 series message to view its documentation.

Why Series 50000 Errors Occur

A 50000 series error can occur for a number of reasons, and depends on the connectivity of the
Questa Verification IP within the testbench environment.

1760 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Why Series 50000 Errors Occur

For example, if it is used to monitor protocol signal activity, it will attempt to 'recognize' all
signal activity into completed transaction-level activity. Sometimes this 'recognition' may fail
due to illegal protocol signal activity, resulting in a 50000 series 'recognition' error being
reported. In this case, it may be that the protocol signal activity is correct but the Questa
Verification IP configuration parameters have been set incorrectly.

Another example may be a TLM 'generating' protocol activity through a Questa Verification IP
to a WLM DUT. The 'generation' of the wire-level activity may not be allowed to happen within
a certain time frame causing an internal time-out to occur resulting in a 50000 series error. In
return the DUT may cause signal-level activity to occur on the protocol signals to be
'recognized' into completed transactions by the Questa Verification IP that subsequently fail due
to illegal protocol signal activity.

Prerequisites for Error Debugging

Familiarity with Questa Verification IP and the QuestaSIM GUI.

Related Topics
Verifying Designs with Questa Verification IP Library Components

ModelSim® SE User's Manual, v10.7 1761

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Concepts Involved in the Errors

Concepts Involved in the Errors

During a given simulation, a Questa Verification IP is translating information between different
levels of abstraction, checking for protocol compliance, recording transaction streams, and so
on.
These internal tasks and processes are hidden and can be ignored, except when a QuestaSim
50000 series error is reported due to illegal protocol activity that has failed to report a protocol
specific QuestaSim 60000 series error. The terminology used in a reported QuestaSim 50000
series error message relates to the internal tasks and processes of a Questa Verification IP, and
understanding the terminology and concepts in the reported message may assist you in the
debug of your testbench and DUT.

Transaction Types and Time Queue ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762

Parents and Children. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
Deleted Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765

Transaction Types and Time Queue ID

There are various methods and approaches to debugging a design, with the ModelSim Wave
window offering a visual interpretation of a simulation as it progresses with time.
Within the Wave window information can be viewed regarding the Questa Verification IP
transactions of MVC_Transaction, MVC_Message and MVC_Stripe, as shown Figure D-4. The
recording of these transactions for a protocol are organized as transaction streams (for instance,
a ‘read’ transaction stream records all transaction instances, parent/child relationships, state
history, and so on, necessary for a complete read transaction). Each transaction instance
recorded within a stream is given a unique transaction ID number (TQ_id), and these TQ_ids
can be viewed within the Wave window. TQ_ids may sometimes be reported within a 50000
series error message, and this can be used to identify the actual transaction instances involved in
the error within the Wave window.

1762 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Parents and Children

Figure D-4. Questa Verification IP Transactions in Wave Window

Parents and Children

Clicking on a transaction instance in the Wave window also highlights the ‘parent’ and ‘child’
relationships for that instance. More information on these relationships can be viewed in the
Transaction View window by right-clicking on the instance and selecting ‘Transaction View’
from the menu.
In general terms, the “Enabling parent” of a transaction instance resides at a higher level of
abstraction within the protocol, thus enabling the select transaction to exist. Likewise, the
“Enabled children” of a transaction reside at a lower level of abstraction within the protocol.

Related Topics
Questa Verification IP Transaction Details in Transaction View Window
Concepts Involved in the Errors

ModelSim® SE User's Manual, v10.7 1763

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Generation and Recognition

Generation and Recognition

If a Questa Verification IP transmits a transaction at the highest level of abstraction then it
‘generates’ the child transactions further down the hierarchy, and down to the wire level of the
protocol.
If a Questa Verification IP is observing wire level activity then it ‘recognizes’ the parent
transactions further up the hierarchy, and up to the highest level of abstraction, as shown in
Figure D-5. The ‘parent’ and ‘child’ of a transaction instance may be reported within a 50000
series error message, which can be useful in identifying the hierarchy of transaction instances
involved in the error within the Wave window.

Figure D-5. Generation and Recognition

Related Topics
Parents and Children
Questa Verification IP Transaction Details in Transaction View Window
Communication Semantics

1764 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Communication Semantics

Transaction Types and Time Queue ID

Communication Semantics
A Questa Verification IP transmits and receives transactions using communication semantics.
These semantics control the blocking and non-blocking of subsequent transactions being
transmitted and received to model various protocol scenarios.
• Activated Transactions semantics are used for the transmission and reception of bi-
directional MVC_Transaction.
• Uni-directional Transmission of Transactions semantics are used for the transmission of
uni-directional MVC_Message and MVC_Stripe transactions.
• Uni-directional Reception of Transactions semantics are used for the reception of uni-
directional MVC_transaction, MVC_Message and MVC_Stripe transactions.
The communication semantic of a transaction instance may be reported within a 50000 series
error message which can be used to understand if the transaction is being transmitted, received,
or is bi-directional transaction. Communication semantics may be further controlled with any
Now and Using constraints that are also reported within an error message.

Deleted Transactions
A transaction has a simulation ‘start time’ and an ‘end time’. The ‘end time’ indicates that the
transaction has completed. If a transaction has completed and it is subsequently deemed to be
illegal protocol, then the Questa Verification IP can make a decision about whether to tidy up
internally in a silent manner. A ‘volatile’ mechanism may be applied to the transaction so that
the Questa Verification IP will report an error message instead of silently deleting the
transaction.
Another mechanism the Questa Verification IP uses to tidy up internally is ‘throw’ and ‘catch’.
For example, it is used when a reset condition is detected part way through the transmission of a
transaction. The transaction is ‘thrown’ internally and an attempt is made to ‘catch’ it to prevent
an error message from being reported if successfully caught.

Related Topics
Questa Verification IP Transaction Details in Transaction View Window
Transaction Types and Time Queue ID

TLM and WLM Connections

A Questa Verification IP can be regarded as a protocol interface that has ‘ends’ for connecting a
master, slave, clock generator, reset generator, etc, as TLM-connected, WLM-connected, or
both.

ModelSim® SE User's Manual, v10.7 1765

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
TLM and WLM Connections

An interface ‘end’ that is TLM-connected drives the wire-level signals, as a consequence of a

transaction being generated within the Questa Verification IP. An interface ‘end’ that is WLM-
connected will monitor wire-level signals changes, and attempt to recognize them into
transactions.

Related Topics
Concepts Involved in the Errors
TLM-connected
WLM-connected

1766 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding the ‘Time Queue’ ID Number

Understanding the ‘Time Queue’ ID Number

Within the ModelSim Wave window, all instances of MVC_Transaction, MVC_Message and
MVC_Stripe are given a numerical identifier known as the Time Queue ID (TQ_id) which is
unique within each type of MVC transaction stream. The TQ_id for a transaction stream type
starts at ‘1’ for the first instance and increments by ‘1’ for each instance thereafter.
The easiest way to discover the TQ_id of a transaction instance is add transaction recording for
the transaction type to the Wave window and place the mouse pointer on the transaction
instance to cause the popup window to appear. The TQ_id number will be in the list of
displayed parameters for the instance.

Viewing the Time Queue ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767

The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
TQ Id Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768

Viewing the Time Queue ID Number

The first transaction instance displayed within a transaction stream may not have a TQ_id of
‘1’, and the TQ_id of subsequent instances in the stream may have incremented by more than
‘1’ from one visible instance to the next. This is due to the deletion of instances that have failed
to complete for a reason that is internal to the Questa Verification IP.
These internal ‘deletions’ have no detrimental effect on the operation of verifying a particular
protocol, but it is useful to know of their existence when debugging.By default, the transaction
recording of deleted instances is disabled.

Procedure
1. To enable the recording of deleted instances:
2. Right-click the transaction-stream name in the Wave window. This opens the
‘Transaction-Stream Properties window.
3. Select the ‘MVC Logging’ tab.
4. Select the ‘Deletion Logging Enabled’ check box.

The Time Queue ID Number Reported in Errors

If a QuestaSim 50000 series error is produced during simulation it may include a transaction
instance TQ_id number in the error message.

ModelSim® SE User's Manual, v10.7 1767

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
TQ Id Related Errors

For example:

# ** Error: (vsim-51309) MVC @ 109820000 ps for 109480475 ps:

/top/ddr2_mem_if write_command_issue: The item
/top/ddr2_mem_if/write_command_issue with TQ_id 474 (start:109400475
ps,end:109480475 ps) was received by item
/top/ddr2_mem_if/write_command_issue_ReceivedReceivingReceive_System
Verilog with TQ_id 1 but has then subsequently gone into ERROR.
Recognizing item /top/ddr2_mem_if/write_command_issue with TQ_id 474,
starting at 109400475 ps, is not legal ddr2 protocol at 109820000 ps

The information given in the error message tells us that the transaction stream
write_command_issue has a transaction instance with a TQ_id of 474, received by the external
method write_cmd_ReceivedReceivingReceive_SystemVerilog with TQ_ID of ‘1’, has gone into
error. Consequently the Questa Verification IP has attempted to recognize the received
write_command_issue but has deemed it to be illegal with regard to the DDR2 protocol. The
start and end times of the illegal write_command_issue instance with a TQ_id of 474 are also
reported.

The simulation ‘start’ and ‘end’ times of the transaction instance TQ_id of 474 assist in finding
the instance in the Wave window. Selecting the transaction instance also highlights ‘parent ‘and
‘child’ relationships. This may give a clue to why this particular instance is illegal within the
protocol specification.

TQ Id Related Errors
Context: The errors in this section are related to the transaction queue id.

Table D-1. TQ_Id Related Series 50000 Errors

Error Description
Number
51305 An attempt to perform a 'received now' has failed. No requested transactions have
been completed at this time.
51309 A transaction was 'received' (receive, receiving or received) by a Questa
Verification IP. However, something has subsequently happened in the protocol
such that the simulator has now determined that this transaction has gone into
error. A possible cause for this is the transaction's parent not succeeding in the
protocol after the transaction has been ‘received’.
51316 An incomplete transaction that has recognized its children has failed to be
recognized by any of its potential parents.
51325 The protocol specification has a parallel condition with a start constraint that has
not been met, possibly due to a transaction in the parallel condition starting too
late.

1768 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
TQ Id Related Errors

Table D-1. TQ_Id Related Series 50000 Errors (cont.)

Error Description
Number
51326 The protocol specification has a parallel condition with an end constraint that has
not been met, possibly due to a transaction in the parallel condition not ending on
time.
51327 A recognized child of this transaction can no longer be part of it, causing this
item to go into error.
51330 Transactions in a parallel condition must overlap and may have specific timing
starting and ending constraints. None of the transactions in the parallel condition
have a start time within that expected by the parallel condition.
51331 An attempt to complete the ‘receive’ of a transaction failed because no ‘receive’
of that transaction is currently active.
51332 An activated or joined transaction has not totally completed when the transaction
itself has completed, and some parameters have not been written. A list of these
parameters may be reported.
51334 A previous ‘activated’ or ‘joined’ transaction has not completed when this new
transaction wants to start.
51341 The transaction has been ‘thrown’ but the ‘catch’ has failed.
51342 The transaction which was recognized as being valid has failed and the ‘volatile’
clause has returned false.
51390 A time relation requires the simulator to move into the past.
51507 For a Questa Verification IP transaction, MVC_message or MVC_stripe to exist
it must be a descendant of a transaction declared within the Questa Verification
IP. This indicates an internal Questa Verification IP error.
51550 An internal Questa Verification IP ‘pre_condition’ has failed.
51553 An internal Questa Verification IP ‘check’ function has failed.
51555 An internal Questa Verification IP function did not end with a ‘return’, so the
default of the return type of the function was used.
52001 An internal Questa Verification IP thread has attempted to release a semaphored
resource that it has not previously acquired. This indicates an internal Questa
Verification IP error.
52002 An internal Questa Verification IP thread has attempted to acquire more
semaphored resources than available. This indicates an internal Questa
Verification IP error.
52003 An internal Questa Verification IP thread has attempted to release more
semaphored resources than available. This indicates an internal Questa
Verification IP error.

ModelSim® SE User's Manual, v10.7 1769

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
TQ Id Related Errors

Table D-1. TQ_Id Related Series 50000 Errors (cont.)

Error Description
Number
54000 An attempt has been made to access part of an internal Questa Verification IP
array which does not exist. This indicates an internal Questa Verification IP
error.
54001 An attempt has been made to access part of an internal Questa Verification IP
array which does not exist because the array has a length of zero. This indicates
an internal Questa Verification IP error.
54002 An internal Questa Verification IP assignment to a ‘struct’ from an aggregate
pattern, the aggregate pattern was found to have too few fields. This indicates an
internal Questa Verification IP error.

1770 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding ‘Parents’ and ‘Children’

Understanding ‘Parents’ and ‘Children’

A Questa Verification IP transaction is unique in that it can represent communication at
multiple levels of abstraction.
To illustrate, consider a hypothetical Questa Verification IP transaction shown in Figure D-6.
This transaction contains a single ‘Transfer’ transaction representing a read or a write.
However, the transaction also references lower level transactions, which separately represent
the ‘Address’ and ‘Data’ transfers. It is also referenced by a higher level transaction, ‘Burst
Transfer’. Note that ‘Burst Transfer’ can consist of multiple ‘Transfer’ transactions. Signals are
always represented at the lowest level of abstraction.

Figure D-6. Questa Verification IP Transaction at Different Levels of Abstraction

Where more than one level of abstraction exists, a ‘relationship’ exists between the different
levels. In the example shown in Figure D-6, a ‘Transfer’ transaction is related to the ‘Address’
and ‘Data’ transactions that communicate the address and data information for that transfer.
These transactions in turn are related to the individual signals which communicate the
equivalent information across the bus. Questa Verification IPs maintain these relationships,
allowing for simulation and debugging across the different levels of abstraction.

The term ‘parent’ describes a related transaction at a higher level of abstraction, and ‘child’
describes a related transaction, or signal, at a lower level of abstraction. Each transaction may
have many related ‘child’ and ‘parent’ transactions. In Figure D-6, the ‘Transfer’ transaction
has two children: an ‘Address’ transaction and a ‘Data’ transaction. It also has one parent:

ModelSim® SE User's Manual, v10.7 1771

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Parent/Child Relationship Related Errors

‘Burst Transfer’. Each ‘Burst Transfer’ transaction can have multiple ‘Transfer’ transactions as
children.

Parent/Child Relationship Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772

Parent/Child Relationship Related Errors

Context: QVIP
The errors in this section are related to the transaction queue id.

Table D-2. Parent/Child Related Series 50000 Errors

Error Description
Number
51201 The transaction has more than 32 internal Questa Verification IP processes or
tasks waiting to (activated/sent/d/ding) it. This may be intentional, but may also
indicate that this transaction is not able to exist within the protocol at this time.
Check whether it is expected to have so many transactions waiting. It is not
possible to modify the initial maximum number of waiting transactions - the
number will be increased as required, whenever this warning is printed.
51302 Attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the transactions
children cannot exist at this time.
51304 Attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the protocol
prohibits such an action at this time.
51305 An attempt to perform a 'received now' has failed. No requested transactions have
been completed at this time.
51306 A transaction that was ‘activated’, ‘sent/d/ding’ has since been determined to not
be part of the protocol.
51308 A transaction that has been generated has since been deleted. This may be due to
clashes with a previously generated transaction.
51309 A transaction was 'received' (‘receive’, ‘receiving’ or ‘received’) by a Questa
Verification IP. However, something has subsequently happened in the protocol
such that the simulator has now determined that this transaction has gone into
error. A possible cause for this is the transaction’s parent not succeeding in the
protocol after the transaction has been ‘received’.
51310 An attempt to perform a 'received now' failed. A transaction that has completed at
this time has the wrong parameter value(s).
51316 An incomplete transaction that has recognized its children has failed to be
recognized by any of its potential parents.
51317 A transaction that recognized its children has start and end times that do not match
those it should inherit from its children.

1772 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Parent/Child Relationship Related Errors

Table D-2. Parent/Child Related Series 50000 Errors (cont.)

Error Description
Number
51318 A transaction that recognized its children is not valid due to a prior transaction
existing.
51322 A transaction that is an MVC_Transaction that was ‘activated’ failed to be
recognized by any parent transaction higher up the protocol.
51327 A recognized child of this transaction can no longer be part of it, causing this
transaction to go into error.
51331 An attempt to complete the ‘receive’ of a transaction failed because no ‘receive’
of that transaction is currently active.
51332 An ‘activated’ or ‘joined’ transaction has not completed when the transaction
itself has completed, and some parameters have not been written.
51334 A previously ‘activated’ or ‘joined’ transaction has not completed when this new
transaction wants to start.
51343 Whilst creating the parent/child relationships within the Questa Verification IP
during initialization, a transaction tried to add itself as a parent. This indicates an
internal Questa Verification IP error.
51500 The maximum number of internal Questa Verification IP resources waiting to
‘received’ this MVC_Transaction, MVC_Message or MVC_Stripe has been
reached, and a new request has been made which causes the limit to be raised.
51501 The maximum number of internal Questa Verification IP resources waiting to
‘receiving’ this MVC_Transaction, MVC_Message or MVC_Stripe has been
reached, and a new request has been made which causes the limit to be raised.
51502 The maximum number of internal Questa Verification IP resources waiting to
‘receive’ this MVC_Transaction, MVC_Message or MVC_Stripe has been
reached and a new request has been made which causes the limit to be raised.
51507 For a Questa Verification IP MVC_Transaction, MVC_Message or MVC_Stripe
to exist it must be a descendant of a parent transaction. This indicates an internal
Questa Verification IP error.
51554 This indicates an internal Questa Verification IP error.
59330 An internal Questa Verification IP potential out-of-range array access between a
parent and child.

ModelSim® SE User's Manual, v10.7 1773

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Understanding Generation and Recognition

Understanding Generation and Recognition

A Questa Verification IP transaction communicates with an TLM model by translating the
transaction down to the signal level, and back to the transaction level.
The translation from a transaction down to the signal level is termed ‘generation’, causing
equivalent low level activity from high level activity. During the translation ‘child’ transactions
are ‘generated’ down to the signal level as shown in Figure D-7. At the top of the tree the
message ‘write’ causes stripes ‘request’ and ‘write_data’ to be generated. Generated stripe
‘request’ causes activity on wires ‘CMD’ and ‘ADDRESS’ to be generated. Generated stripe
‘write_data’ causes activity on wire ‘WDATA’ to be generated, and so on.

Figure D-7. Generation of Children

The translation from the signal level up to the transaction level is termed ‘recognition’, causing
equivalent high level activity from low level activity. During the translation ‘parent’
transactions are ‘recognized’ up to the highest transaction level as shown in Figure D-8. At the
bottom of the tree activity on wires ‘CMD’ and ‘ADDRESS’ causes stripe ‘request’ to be
recognized. Activity on wire ‘WDATA’ causes stripe ‘write_data’ to be recognized.
Recognized stripes ‘request’ and ‘write_data’ cause message ‘write’ to be recognized, and so
on.

Figure D-8. Recognition into Parents

The ‘generation’ and ‘recognition’ of transactions and signal activity can be viewed within the
Wave window. The color of a transaction object indicates what caused it to exist, if it was
generated from a parent object, or recognized from a child object(s). Refer to “What the Colors
Mean” in Chapter 13 of the Questa SIM User’s Manual for more information.

1774 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Generation/Recognition Related Errors

Knowing how a transaction instance came into existence can assist in the debugging of your
testbench or DUT. For example, Figure D-7 shows the message ‘write’ transaction in blue
because it has been created by a ‘communication semantic’. The generated child stripes
‘request’ and ‘write_data’ are shown in green, as are the generated wire activities ‘CMD’,
‘ADDRESS’ and ‘WDATA’.

Similarly, Figure D-8 shows the wires ‘CMD’, ‘ADDRESS’ and ‘WDATA’ in blue as they
have been created by signal level activity. The recognized parent stripes ‘request’ and
‘write_data’ are shown in light blue, as is the recognized ‘parent’ of message ‘write’.

Generation/Recognition Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775

Generation/Recognition Related Errors

Context: QVIP transactions
The errors in this section are related to the transaction queue id.

Table D-3. Generation/Recognition Related Series 50000 Errors

Error Description
Number
51302 An attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the
transaction’s children cannot exist at this time or point in the protocol.
51307 A transaction that has been partly ‘generated ‘is unable to complete. This may be
due to clashes with a previously ‘generated’ transaction.
51308 A transaction that has been ‘generated’ has since been deleted. This may be due to
clashes with a previously ‘generated’ transaction.
51312 A transaction that was ‘generated’ by a parent transaction higher up the protocol
has failed to be legal protocol at this time.
51314 A transaction that has recognized its children lower down the protocol, or by
observing wire activity, has failed to be legal protocol at this time.
51316 An incomplete transaction that has recognized its children has failed to be
recognized by any of its potential parents.
51317 A transaction that recognized its children has start and end times that do not
match those it should inherit from its children.
51318 A transaction that recognized its children is not valid due to a prior transaction
existing.
51320 A transaction that was part way through recognition failed to be recognized by
any parent transaction higher up the protocol.
51321 A transaction that is an MVC_Message or MVC_Stripe was ‘Sent/d/ding’ failed
to be recognized by any parent transaction higher up the protocol.

ModelSim® SE User's Manual, v10.7 1775

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Generation/Recognition Related Errors

Table D-3. Generation/Recognition Related Series 50000 Errors (cont.)

Error Description
Number
51322 A transaction that is an MVC_Transaction that was ‘activated’ failed to be
recognized by any transaction higher up the protocol.
51323 A transaction that was ‘generated’ failed to be ‘recognized’ by any parent
transaction higher up the protocol.
51324 A transaction that was part way through ‘generation’ failed to be ‘recognized’ by
any transaction higher up the protocol.
51327 A recognized child of this transaction can no longer be part of it, causing this
transaction to go into error.
51521 A transaction which is an MVC_Stripe has failed to be ‘generated’ correctly as
the hold time would be less than 0. Check the configuration using the QuestaSIM
command questa_mvc_show MVC_CONFIG.
51522 A transaction which is an MVC_Stripe has failed to be ‘generated’ correctly as
the valid after time would be less than -1. Check the configuration using the
QuestaSIM commend questa_mvc_show MVC_CONFIG.
52234 During initialization, a VPI routine has been unable to connect with a variable in
the SystemVerilog interface.
This sometimes happens when the SystemVerilog compiler or simulator has
optimized out the variable as it is only meaningfully set from VPI - check the
flags to the compile or simulate have (for example) +vpi or +acc.
Another cause could be if all VPI calls are failing because the model has been
built incorrectly; for example, if the model is using gcc 4.5.0 with a MVC
instance built with gcc 4.2.2
Also check the documentation in <QVIPHome>/release_documents/
questa_vip_install.pdf
55004 An attempt has been made to ‘generate’ a transaction on the emulator, but there is
no proxy for the active end instantiated on the emulator.

1776 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding Deletions

Understanding Deletions
A transaction instance that completes can subsequently fail to be a parent or child of other
transaction instances, for reasons that are internal to the Questa Verification IP. These ‘failures’
are a part of the normal internal operation of a Questa Verification IP and can be displayed as
‘deleted’ transaction instances in the Wave window. These failed transaction instances have no
detrimental effect on the operation of a Questa Verification IP, but it is useful to know of their
existence when debugging your testbench and DUT.
By default ‘deleted’ transaction instances are hidden in the Wave window. They can be
displayed by right clicking on the transaction stream name in the Wave window and selecting
‘Transaction Properties...’ from the menu to open the Transaction-Stream Properties window.
Selecting the ‘MVC Logging’ tab presents the ‘Deletion Logging Enabled’ check box to enable
the logging of deleted transaction instances for the selected transaction stream.

Note
It is advisable to enable only the transaction stream logging of deleted instances of interest
to assist in debugging. In common with logging any transaction stream information it will
consume additional simulation resources.

Deletion Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777

Deletion Related Errors

Context: QVIP errors.
The errors in this section are related to the transaction queue id.

Table D-4. Deletion Related Series 50000 Error

Error Description
Number
51308 A transaction item that has been ‘generated’ has since been ‘deleted’, this may be
due to clashes with previously generated transactions.

ModelSim® SE User's Manual, v10.7 1777

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Understanding Communication Semantics

Understanding Communication Semantics

A Questa Verification IP uses a number of standard communications semantics that define the
mode of transmission, or observation of, a transaction across the protocol interface. A Questa
Verification IP transaction type is defined as an MVC_transaction, an MVC_message or an
MVC_stripe. Each transaction type supports a sub-set of the available communications
semantics:
• An MVC_Transaction is bi-directional and can be transmitted using the Activate,
Activating or Activates semantics.
• An MVC_Message or MVC_Stripe is uni-directional can be transmitted using the Send,
Sending or Sent semantics.
• Any MVC_Transaction, MVC_Message or MVC_Stripe can be observed using the
Receive, Receiving or Received semantics.

Note
Each communication semantic is described below together with a diagram to help
with the explanation. In the diagrams “A” represents a thread of activity that is
happening within a Questa Verification IP prior to the use of the semantic (up to the
dashed line) and “B” represents a thread of activity that happens immediately after the
semantic has completed. The gap between “A” and “B” represents any suspension in
thread activity due to the semantics operation.

Activated Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778

Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1780
Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1782
Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1783
Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784

Activated Transactions
An “activated” Questa Verification IP transaction is bi-directional and supports the transmission
of the MVC_transaction type between a Questa Verification IP and a DUT. The Questa
Verification IP provides the outbound information, with return information provided by the
DUT to complete the transaction.
There are three different transmission modes, Activate, Activating, and Activates, that a Questa
Verification IP can use to transmit a transaction. Each mode provides a different blocking
mechanism for the internal queuing and transmission of subsequent transactions.

Note
If a QuestaSim 50000 series error reports that an item is “activated” within its error
message, then it can be any of the Activate, Activating, and Activates modes.

1778 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Activated Transactions

Activate
A “wait until transaction transmission complete” mechanism for a bi-directional
MVC_transaction. The Questa Verification IP will internally queue the current transaction and
block the transmission of subsequent transactions until the current transaction has completed.
The start of a transaction is determined by the rules of the protocol and the resources available.
On completion of the transaction the Questa Verification IP will permit the queuing and
transmission of subsequent transactions.

Figure D-9. Activate MVC_transaction

Activating
A “wait until able to start transaction” mechanism for a bi-directional MVC_transaction. The
Questa Verification IP will internally queue the current transaction and block the transmission
of subsequent transactions until the current transaction has started. The start of a transaction is
determined by the rules of the protocol and the resources available.

Figure D-10. Activating MVC_transaction

ModelSim® SE User's Manual, v10.7 1779

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Uni-directional Transmission of Transactions

Activates
A “fire and forget transaction” mechanism for a bi-directional MVC_transaction. The Questa
Verification IP internally queues the current transaction until it is able to be transmitted,
determined by the rules of the protocol and the resources available. The transmission of
subsequent transactions is permitted immediately.

Figure D-11. Activates MVC_transaction

Uni-directional Transmission of Transactions

The three modes — Send, Sending, or Sent — of a Questa Verification IP transaction are uni-
directional and support the transmission of the MVC_message and MVC_stripe types from a
Questa Verification IP to a DUT. Each mode provides a different blocking mechanism for the
internal queuing and transmission of subsequent transactions. The Questa Verification IP
provides the outbound information to complete the transaction.

Send
A “fire and forget transaction” mechanism for a uni-directional MVC_message or MVC_stripe
transactions. The Questa Verification IP internally queues the current transaction until it is able
to be transmitted, determined by the rules of the protocol and the resources available. The
transmission of subsequent transactions is permitted immediately.

1780 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Uni-directional Transmission of Transactions

Figure D-12. Send MVC_Message or MVC_Stripe

Sending
A “wait until able to start transaction” mechanism for a uni-directional MVC_message or
MVC_stripe transactions. The Questa Verification IP will internally queue the current
transaction and block the transmission of subsequent transactions until the current transaction
has started. The start of a transaction is determined by the rules of the protocol and the resources
available.

Figure D-13. Sending MVC_Message or MVC_Stripe

Sent
A “wait until transaction transmission complete” mechanism for a uni-directional
MVC_message or MVC_Stripe transaction. The Questa Verification IP will internally queue
the current transaction and block the transmission of subsequent transactions until the current
transaction has completed. The start of a transaction is determined by the rules of the protocol
and the resources available. On completion the Questa Verification IP will permit the queuing
and transmission of subsequent transactions.

ModelSim® SE User's Manual, v10.7 1781

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Uni-directional Reception of Transactions

Figure D-14. Sent MVC_Message or MVC_Stripe

Uni-directional Reception of Transactions

The three modes Receive, Receiving, or Received of a Questa Verification IP transaction are
uni-directional and support the reception of the MVC_transaction, MVC_message and
MVC_stripe transaction types from a DUT to a Questa Verification IP. Each mode provides a
different blocking mechanism for the internal reception of subsequent transactions. The DUT
provides the inbound information to complete the transaction.

Receive
A “take the next to start transaction” mechanism for a bi-directional MVC_transaction, or uni-
directional MVC_message and MVC_Stripe transactions. The Questa Verification IP will wait
for a transaction to start, ignoring any currently active transactions. Once a transaction starts it
blocks the reception of subsequent transactions until the current transaction has completed.

Figure D-15. Receive MVC_transaction, MVC_Message or MVC_Stripe

1782 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Constraining Communication Semantics

Receiving
A “take the current or next transaction” mechanism for a bi-directional MVC_transaction, or
uni-directional MVC_message and MVC_Stripe transactions. The Questa Verification IP waits
for the current transaction to complete, blocking the reception of subsequent transactions.

Figure D-16. Receiving MVC_transaction, MVC_Message or MVC_Stripe

Received
A “take whatever transaction is available” mechanism. The Questa Verification IP takes the
previous transaction that completed, not blocking the reception of subsequent transactions.

Figure D-17. Received MVC_Transaction, MVC_Message or MVC_Stripe

Constraining Communication Semantics

The Questa Verification IP internal communication semantics may be constrained internally by
the use of the ‘now’ and ‘using’ clauses to model specific protocol behavior.

ModelSim® SE User's Manual, v10.7 1783

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Communication Related Errors

Now
If a transaction has to be transmitted at the same time that it is created within a Questa
Verification IP, according to the protocol, the ‘now’ constraining semantic is used to avoid the
transaction queuing internally. If the transaction cannot be transmitted immediately then an
error message is reported.

Similarly, if a transaction has to be received immediately by a Questa Verification IP, according

to the protocol, the ‘now’ constraining semantic is used internally. If a transaction has not
occurred then an error message is reported.

Using
The ‘using’ constraint is applied to reception semantics within a Questa Verification IP to
model situations where more than one internal resource wants to ‘receive’ the same transaction.
This may be an undesirable side-effect of the protocol, and that only one internal resource
should ‘receive’ the transaction leaving the other resources to wait to ‘receive’ subsequent
transactions.

Communication Related Errors

Context: QVIP errors
The errors in this section are communication related series 50000 errrors..

Table D-5. Communication Related Series 50000 Errors

Error Description
Number
51201 The 'transaction' has more than 32 internally process or tasks waiting to
(activated/sent/d/ding) it. This may be intentional, but may also indicate that
transaction is not able to exist on the interface at this time.
Check whether it is expected to have so many transactions waiting. It is not
possible to modify the initial maximum number of waiting transactions - the
number will be increased as required, whenever this warning is printed.
51302 An attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the
transaction’s children cannot exist at this time in the protocol.
51303 An attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the
transaction cannot exist at this time in the protocol.
51304 An attempt to ‘send’, ‘sending’ or ‘sent’ 'now' failed. This is because the protocol
prohibits such an action at this time.
51305 An attempt to perform a 'received now' has failed. No requested transactions have
been completed at this time.

1784 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding Start and End Times

Table D-5. Communication Related Series 50000 Errors (cont.)

Error Description
Number
51306 A transaction that was ‘activated’, ‘sent/d/ding’ has since been determined to not
be part of the protocol.
51309 A transaction was 'received' (receive, receiving or received) by a Questa
Verification IP. However, something has subsequently happened in the protocol
such that the simulator has now determined that this transaction has gone into
error. A possible cause for this is the transaction’s parent not succeeding in the
protocol after this transaction has been ‘received’.
51310 An attempt to perform a 'received now' on a transaction failed. A transaction that
has completed at this time has the wrong parameter value(s).
51321 A transaction that is an MVC_Message or MVC_Stripe that was ‘sent/d/ding’
failed to be recognized by any parent transaction higher up the protocol.
51331 An attempt to register the completion of a ‘receive’ for a transaction has failed
because no ‘receive’ of the transaction is currently active.
51500 The maximum number of internal Questa Verification IP resources waiting to
‘received’ this MVC_Transaction, MVC_Message or MVC_Stripe> has been
reached and a new request has been made which causes the limit to be raised.
51502 The maximum number of internal Questa Verification IP resources waiting to
‘receive’ this MVC_Transaction, MVC_Message or MVC_Stripe has been
reached and a new request has been made which causes the limit to be raised.
59023 An attempt to cause a transaction has been made when the Questa Verification IP
has been disabled.

Understanding Start and End Times

The ‘start time’ and ‘end time’ reported for a Questa Verification IP MVC_Transaction,
MVC_Message and MVC_Stripe relates to the simulation time that the transaction starts and
completes on the protocol signals, respectively.
Figure D-18 shows the creation and queuing of an MVC_Transaction and MVC_Message
within a Questa Verification IP. The simulation time at which the protocol permits the
transaction to start on the protocol signals defines the ‘start time’. After a specified duration
from the ‘start time’ the transaction completes which defines the ‘end time’. For generation and
recognition of an MVC_Transaction or MVC_Message the start and end time definitions are the
same.

ModelSim® SE User's Manual, v10.7 1785

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Understanding Start and End Times

Figure D-18. MVC_Transaction and MVC_Message Start and End Times

Figure D-19 shows the ‘start time’ and ‘end time’ of an MVC_Stripe in relation to the protocol
signals. The simulation time at which the protocol permits the MVC_Stripe to start on the
protocol signals defines the ‘start time’. The ‘start time’ coincides with the ‘hold time’ after the
strobe point (in this case the rising edge of the clock signal CLK). The ‘end time’ coincides with
the ‘hold time’ after the following strobe point (in this case the next rising edge of the clock
signal CLK). For the generation and recognition of an MVC_Stripe the start and end time
definitions are the same.

Figure D-19. MVC_Stripe Start and End Times

1786 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding the Volatile Clause

Understanding the Volatile Clause

A Questa Verification IP incorporates a ‘volatile’ mechanism that is used to make a decision
about whether to tidy up after a transaction has been deemed to be illegal protocol. The decision
is made only when the transaction has completed; that is, it recognized the child transactions it
needed to succeed, but was unable to satisfy the requirements of a parent transaction. This
feature is commonly used to ‘catch’ an MVC_Stripe that does not find a parent transaction.
For example, if a wire is driven from a DUT this may cause an MVC_Stripe transaction to be
recognized within the Questa Verification IP. This MVC_Stripe transaction may be part of the
legal protocol and itself be recognized by a parent. However, the default behavior for an
MVC_Stripe which does not find a parent is to be silently deleted. Hence a ‘volatile’
mechanism is applied to the MVC_Stripe internal to the Questa Verification IP to ensure that an
error message is reported.

Volatile Clause Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787

Volatile Clause Related Error

Context: QVIP errors
The errors in this section are related to the volatile clause.

Table D-6. Volatile Clause Related Series 50000 Error

Error Description
Number
51342 The transaction which was recognized as being valid has failed and the volatile
clause has returned false, resulting in this error message.

ModelSim® SE User's Manual, v10.7 1787

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Understanding Activities

Understanding Activities
Activities within a Questa Verification IP perform tasks and processes to ensure adherence to a
protocol specification, for example, initialization routines, time-outs, and so on. They may
consume time, in that their execution advances simulation time. They can also be timeless in
that their execution consumes no simulation time.
Activity Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788

Activity Related Errors

Context: QVIP errors
The errors in this section are related to activities.

Table D-7. Activity Related Series 50000 Errors

Error Description
Number
51002 During simulation, the named activity (or process) within the Questa Verification
IP that should not consume any time has not finished execution at this time. This
indicates an internal Questa Verification IP error has occurred.
51003 During simulation, the named activity (or process) within the Questa Verification
IP that may consume time has executed a number of times within the same
simulation time. This indicates an internal Questa Verification IP error has
occurred.

1788 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Understanding ‘Throw’ and ‘Catch’

Understanding ‘Throw’ and ‘Catch’

A Questa Verification IP incorporates a ‘throw’ and ‘catch’ mechanism that permits the
termination of an existing transaction, and prevents the creation of a subsequent one. This
feature is commonly used to model reset behavior.
For example, if a Questa Verification IP detects a reset condition part way through the
transmission of a transaction it will ‘throw’ the transaction, preventing other transactions from
starting. A ‘catch’ of the ‘thrown’ transaction will be attempted to allow the Questa Verification
IP to tidy up internally to prevent an error message from being reported. If the transaction is
successfully caught then no error message is reported and the testbench can continue to perform
other tests as required.

Throw and Catch Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789

Throw and Catch Related Error

Context: QVIP errors
The error in this section is related to throw and catch errors.

Table D-8. Throw/Catch Related Series 50000 Errors

Error Description
Number
51341 Within the Questa Verification IP the transaction has been ‘thrown’ but the
‘catch’ clause has failed.

ModelSim® SE User's Manual, v10.7 1789

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Understanding TLM and WLM Connections

Understanding TLM and WLM Connections

A Questa Verification IP is configured with an ‘abstraction level’ for each end of its interface.
An interface end is connected to a model, for example, master, slave, clock generator, reset
generator, and so on. There are two defined levels of abstraction:
• A “Transaction Level Model” (TLM) refers to a style of modeling where the
information contained within the model is at a higher (more abstract) level than a
traditional RTL model.
• A “Wire Level Model” (WLM) refers to a style of modeling where the information
contained within the model is at the traditional RTL level.
A Questa Verification IP interface end is therefore defined as ‘WLM-connected’ or ‘TLM-
connected’, and determines the behavior of the end with respect to the generation and
recognition of signal changes on the protocol wires.

WLM-connected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
WLM-connected and TLM-connected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791

WLM-connected
An interface end that is WLM-connected will monitor wire-level signals changes, and attempt
to recognize them into transaction objects. It expects an externally connected model to drive
wire-level signals:
• directly by SystemVerilog assign statements
• by calls to the XYZ_set_AWIRE_driver() task declared in the Questa Verification IP
interface (where the protocol is called XYZ, and it contains a wire called AWIRE).
A WLM-connected interface end should not attempt to drive a wire-level signal from the Questa
Verification IP as this may cause an ‘X’ to appear on the signal wire(s) due to a clash with the
drivers of the external wire-level model.

Note
Use WLM-connected for a Questa Verification IP interface end where it is connected to an
external model written in RTL code.

1790 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
TLM-connected

TLM-connected
An interface end that is TLM-connected drives the wire-level signals, as a consequence of a
transaction being generated within the Questa Verification IP. It expects an externally
connected model to:
• not attempt to cause signal-changes directly on the connected wires
o by using continuous assignments.
o by calls to the XYZ_set_AWIRE_driver() task declared in the Questa Verification IP
interface
An external model connected to a TLM-connected interface end should not attempt to drive a
wire-level signal as this may cause an ‘X’ to occur on the signal wire(s) due to a clash with the
drivers of the Questa Verification IP interface end.

Note
Use TLM-connected for a Questa Verification IP interface end where it is connected to an
external model written as a Transaction Level Model.

WLM-connected and TLM-connected

An interface end that is both WLM-connected and TLM_connected monitors and drives wire-
level signals, respectively.
Connecting an external model to a WLM-connected and TLM-connected interface end requires
care to ensure that both monitor and driver behaviors are properly coordinated, otherwise an ‘X’
may occur on the signal wire(s). This type of external model only partially implements the
driving of the protocol wire-level signals, leaving the Questa Verification IP to implement the
driving of the remainder.

Note
Use both WLM-connected and TLM-connected for a Questa Verification IP interface end
where it is connected to an external model written as both a Transaction level model and an
RTL model.

TLM/WLM Related Errors

Context: QVIP errors
The errors in this section are related to TLM and WLM connections.

ModelSim® SE User's Manual, v10.7 1791

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
TLM/WLM Related Errors

Table D-9. TLM/WLM Related Series 50000 Errors

Error Description
Number
51907 An attempt to update the TLM/WLM abstraction level has been done when it has
already been set.
51908 Once the abstraction level of a Questa Verification IP end has been set to TLM-
connected it cannot be unset.
51909 The named wire is driven from within the Questa Verification IP, and has not
reached a stable value within this time step. This is often caused by externally
driving a conflicting value onto the wire.
If this behavior is expected, then number of iterations attempted before this error is
issued can be modified using the <questa_mvc_do_cmd> "config
max_wire_assignments 'new_iter_value'". For example:
questa_mvc_do_cmd "config max_wire_assignments 400"

1792 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix E
Verilog Interfaces to C

This appendix describes the ModelSim implementation of the Verilog interfaces:

• Verilog PLI (Programming Language Interface)
• VPI(Verilog Procedural Interface)
• SystemVerilog DPI (Direct Programming Interface).
These three interfaces provide a mechanism for defining tasks and functions that communicate
with the simulator through a C procedural interface. There are many third party applications
available that interface to Verilog simulators through the PLI (see Third Party PLI
Applications). In addition, you may write your own interface applications.

Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794

GCC Compiler Support for use with C Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
Registering PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
Registering VPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797
Registering DPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799
DPI Use Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
PLI Catalog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
Compiling and Linking C Applications for Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
Compiling and Linking C++ Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 1822
Specifying Application Files to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
PLI Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
VPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
DPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
The PLI Callback reason Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
The sizetf Callback Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
PLI Object Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
Third Party PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
Support for VHDL Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
IEEE Std 1364 ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
IEEE Std 1364 TF Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
SystemVerilog DPI Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
Verilog-XL Compatible Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840

ModelSim® SE User's Manual, v10.7 1793

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Implementation Information

64-bit Support for PLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840

PLI/VPI Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Checkpointing and Interface Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
Debugging Interface Application Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843

Implementation Information
This chapter describes only the details of using the Verilog interfaces with ModelSim Verilog
and SystemVerilog.
• ModelSim SystemVerilog implements DPI as defined in the IEEE Std 1800-2005.
• The PLI implementation (TF and ACC routines) as defined in IEEE Std 1364-2001 is
retained for legacy PLI applications. However, this interface was deprecated in IEEE
Std 1364-2005 and subsequent IEEE Std 1800-2009 (SystemVerilog) standards.
New applications should not rely on this functionality being present and should instead
use the VPI.
• VPI Implementation — The VPI is partially implemented as defined in the IEEE Std
1364-2005 and IEEE Std 1800-2005. The list of currently supported functionality can be
found in the following file:
<install_dir>/docs/technotes/Verilog_VPI.note

The simulator allows you to specify whether it runs in a way compatible with the IEEE
Std 1364-2001 object model or the combined IEEE Std 1364-2005/IEEE Std 1800-2005
object models. By default, the simulator uses the combined 2005 object models. This
control is accessed through the vsim -plicompatdefault switch or the PliCompatDefault
variable in the modelsim.ini file.
The following table outlines information you should know about when performing a
simulation with VPI and HDL files using the two different object models.

Table E-1. VPI Compatibility Considerations

Simulator VPI HDL Notes
Compatibility: Files Files
-plicompatdefault
2001 2001 2001 When your VPI and HDL are written based on the
2001 standard, be sure to specify, as an argument to
vsim, “-plicompatdefault 2001”.
2005 2005 2005 When your VPI and HDL are written based on the
2005 standard, you do not need to specify any
additional information to vsim because this is the
default behavior

1794 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
GCC Compiler Support for use with C Interfaces

Table E-1. VPI Compatibility Considerations (cont.)

Simulator VPI HDL Notes
Compatibility: Files Files
-plicompatdefault
2001 2001 2005 New SystemVerilog objects in the HDL will be
completely invisible to the application. This may be
problematic, for example, for a delay calculator,
which will not see SystemVerilog objects with delay
on a net.
2001 2005 2001 It is possible to write a 2005 VPI that is backwards-
compatible with 2001 behavior by using mode-
neutral techniques. The simulator will reject 2005
requests if it is running in 2001 mode, so there may
be VPI failures.
2001 2005 2005 You should only use this setup if there are other VPI
libraries in use for which it is absolutely necessary to
run the simulator in 2001-mode. This combination is
not recommended when the simulator is capable of
supporting the 2005 constructs.
2005 2001 2001 This combination is not recommended. You should
change the -plicompatdefault argument to 2001.
2005 2001 2005 This combination is most likely to result in errors
generated from the VPI as it encounters objects in
the HDL that it does not understand.
2005 2005 2001 This combination should function without issues, as
SystemVerilog is a superset of Verilog. All that is
happening here is that the HDL design is not using
the full subset of objects that both the simulator and
VPI ought to be able to handle.

GCC Compiler Support for use with C

Interfaces
To use GCC compilers with C interfaces, you must acquire the gcc/g++ compiler for your given
platform.
Related Topics
Compiling and Linking C Applications for Interfaces
Compiling and Linking C++ Applications for Interfaces

ModelSim® SE User's Manual, v10.7 1795

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Registering PLI Applications

Registering PLI Applications

Each PLI application must register its system tasks and functions with the simulator, providing
the name of each system task and function and the associated callback routines.
Since many PLI applications already interface to Verilog-XL, ModelSim Verilog PLI
applications make use of the same mechanism to register information about each system task
and function in an array of s_tfcell structures. This structure is declared in the veriuser.h include
file as follows:

typedef int (*p_tffn)();

typedef struct t_tfcell {

short type;/* USERTASK, USERFUNCTION, or USERREALFUNCTION */
short data;/* passed as data argument of callback function */
p_tffn checktf; /* argument checking callback function */
p_tffn sizetf; /* function return size callback function */
p_tffn calltf; /* task or function call callback function */
p_tffn misctf; /* miscellaneous reason callback function */
char *tfname;/* name of system task or function */

/* The following fields are ignored by ModelSim Verilog */

int forwref;
char *tfveritool;
char *tferrmessage;
int hash;
struct t_tfcell *left_p;
struct t_tfcell *right_p;
char *namecell_p;
int warning_printed;
} s_tfcell, *p_tfcell;

The various callback functions (checktf, sizetf, calltf, and misctf) are described in detail in the
IEEE Std 1364. The simulator calls these functions for various reasons. All callback functions
are optional, but most applications contain at least the calltf function, which is called when the
system task or function is executed in the Verilog code. The first argument to the callback
functions is the value supplied in the data field (many PLI applications do not use this field).
The type field defines the entry as either a system task (USERTASK) or a system function that
returns either a register (USERFUNCTION) or a real (USERREALFUNCTION). The tfname
field is the system task or function name (it must begin with $). The remaining fields are not
used by ModelSim Verilog.

On loading of a PLI application, the simulator first looks for an init_usertfs function, and then a
veriusertfs array. If init_usertfs is found, the simulator calls that function so that it can call
mti_RegisterUserTF() for each system task or function defined. The mti_RegisterUserTF()
function is declared in veriuser.h as follows:

void mti_RegisterUserTF(p_tfcell usertf);

The storage for each usertf entry passed to the simulator must persist throughout the simulation
because the simulator de-references the usertf pointer to call the callback functions. We

1796 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Registering VPI Applications

recommend that you define your entries in an array, with the last entry set to 0. If the array is
named veriusertfs (as is the case for linking to Verilog-XL), then you do not have to provide an
init_usertfs function, and the simulator automatically registers the entries directly from the array
(the last entry must be 0). For example,

s_tfcell veriusertfs[] = {
{usertask, 0, 0, 0, abc_calltf, 0, "$abc"},
{usertask, 0, 0, 0, xyz_calltf, 0, "$xyz"},
{0} /* last entry must be 0 */
};

Alternatively, you can add an init_usertfs function to explicitly register each entry from the
array:

void init_usertfs()
{
p_tfcell usertf = veriusertfs;
while (usertf->type)
mti_RegisterUserTF(usertf++);
}

It is an error if a PLI shared library does not contain a veriusertfs array or an init_usertfs
function.

Since PLI applications are dynamically loaded by the simulator, you must specify which
applications to load (each application must be a dynamically loadable library, see Compiling
and Linking C Applications for Interfaces). The PLI applications are specified as follows (note
that on a Windows platform the file extension would be .dll):

• As a list in the Veriuser entry in the modelsim.ini file:

Veriuser = pliapp1.so pliapp2.so pliappn.so

• As a list in the PLIOBJSenvironment variable:

% setenv PLIOBJS "pliapp1.so pliapp2.so pliappn.so"

• As a -pli argument to the simulator (multiple arguments are allowed):

-pli pliapp1.so -pli pliapp2.so -pli pliappn.so

The various methods of specifying PLI applications can be used simultaneously. The libraries
are loaded in the order listed above. Environment variable references can be used in the paths to
the libraries in all cases.

Registering VPI Applications

Each VPI application must register its system tasks and functions and its callbacks with the
simulator. To accomplish this, one or more user-created registration routines must be called at
simulation startup. Each registration routine should make one or more calls to
vpi_register_systf() to register user-defined system tasks and functions and vpi_register_cb() to

ModelSim® SE User's Manual, v10.7 1797

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Registering VPI Applications

register callbacks. The registration routines must be placed in a table named

vlog_startup_routines so that the simulator can find them. The table must be terminated with a 0
entry.
Example E-1. VPI Application Registration

PLI_INT32 MyFuncCalltf( PLI_BYTE8 *user_data )

{ ... }

PLI_INT32 MyFuncCompiletf( PLI_BYTE8 *user_data )

{ ... }

PLI_INT32 MyFuncSizetf( PLI_BYTE8 *user_data )

{ ... }

PLI_INT32 MyEndOfCompCB( p_cb_data cb_data_p )

{ ... }

PLI_INT32 MyStartOfSimCB( p_cb_data cb_data_p )

{ ... }

void RegisterMySystfs( void )

{

vpiHandle tmpH;
s_cb_data callback;
s_vpi_systf_data systf_data;

systf_data.type = vpiSysFunc;
systf_data.sysfunctype = vpiSizedFunc;
systf_data.tfname = "$myfunc";
systf_data.calltf = MyFuncCalltf;
systf_data.compiletf = MyFuncCompiletf;
systf_data.sizetf = MyFuncSizetf;
systf_data.user_data = 0;
tmpH = vpi_register_systf( &systf_data );
vpi_free_object(tmpH);

callback.reason = cbEndOfCompile;
callback.cb_rtn = MyEndOfCompCB;
callback.user_data = 0;
tmpH = vpi_register_cb( &callback );
vpi_free_object(tmpH);

callback.reason = cbStartOfSimulation;
callback.cb_rtn = MyStartOfSimCB;
callback.user_data = 0;
tmpH = vpi_register_cb( &callback );
vpi_free_object(tmpH);
}

void (*vlog_startup_routines[ ] ) () = {
RegisterMySystfs,
0 /* last entry must be 0 */
};

1798 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Registering DPI Applications

Loading VPI applications into the simulator is the same as described in Registering PLI
Applications.

Using PLI and VPI Together

PLI and VPI applications can co-exist in the same application object file.

In such cases, the applications are loaded at startup as follows:

• If an init_usertfs() function exists, then it is executed and only those system tasks and
functions registered by calls to mti_RegisterUserTF() will be defined.
• If an init_usertfs() function does not exist but a veriusertfs table does exist, then only
those system tasks and functions listed in the veriusertfs table will be defined.
• If an init_usertfs() function does not exist and a veriusertfs table does not exist, but a
vlog_startup_routines table does exist, then only those system tasks and functions and
callbacks registered by functions in the vlog_startup_routines table will be defined.
As a result, when PLI and VPI applications exist in the same application object file, they must
be registered in the same manner. VPI registration functions that would normally be listed in a
vlog_startup_routines table can be called from an init_usertfs() function instead.

Registering DPI Applications

DPI applications do not need to be registered. However, each DPI imported or exported task or
function must be identified using SystemVerilog ‘import “DPI-C”’ or ‘export “DPI-C”’syntax.
Examples of the syntax follow:

export "DPI-C" task t1;

task t1(input int i, output int o);
.
.
.
end task

import "DPI-C" function void f1(input int i, output int o);

Your C code must provide imported functions or tasks. An imported task must return an int
value, "1" indicating that it is returning due to a disable, or "0" indicating otherwise.

The default flow is to supply C/C++ files on the vlog command line. The vlog compiler will
automatically compile the specified C/C++ files and prepare them for loading into the
simulation. For example,

vlog dut.v imports.c

vsim top -do <do_file>

ModelSim® SE User's Manual, v10.7 1799

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Registering DPI Applications

Optionally, DPI C/C++ files can be compiled externally into a shared library. For example, third
party IP models may be distributed in this way. The shared library may then be loaded into the
simulator with either the command line option -sv_lib <lib> or -sv_liblist <bootstrap_file>.
For example,

vlog dut.v
gcc -shared -Bsymbolic -o imports.so imports.c
vsim -sv_lib imports top -do <do_file>

The -sv_lib option specifies the shared library name, without an extension. A file extension is
added by the tool, as appropriate to your platform. For a list of file extensions accepted by
platform, see DPI File Loading.

You can also use the command line options -sv_root and -sv_liblist to control the process for
loading imported functions and tasks. These options are defined in the IEEE Std 1800-2005.

1800 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
DPI Use Flow

DPI Use Flow

Correct use of ModelSim DPI depends on the flow presented in this section.
Figure E-1. DPI Use Flow Diagram

1. Run vlog to generate a dpiheader.h file.

This file defines the interface between C and ModelSim for exported and imported tasks
and functions. Though the dpiheader.h is a user convenience file rather than a
requirement, including dpiheader.h in your C code can immediately solve problems
caused by an improperly defined interface. An example command for creating the
header file would be:
vlog -dpiheader dpiheader.h files.v

[For WINDOWS platform users:] If a DPI header is not being generated or used, you
need to manually attach DPI_DLLESPEC in front of all DPI routines. DPI_DLLESPEC
is a standard macro defined inside svdpi.h.
The generated DPI header flow is recommended. Failing to do the above will incur the
following warning at elab time:
# ** Warning: (vsim-3770) Failed to find user specified function
'foo' in DPI C/C++ source files.

ModelSim® SE User's Manual, v10.7 1801

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
DPI and the vlog Command

and the fatal error at runtime:

# ** Fatal: (vsim-160) test.sv(11): Null foreign function pointer
encountered when calling 'foo'

2. Include the dpiheader.h file in your C code.

ModelSim recommends that any user DPI C code that accesses exported tasks/functions,
or defines imported tasks/functions, should include the dpiheader.h file. This allows the
C compiler to verify the interface between C and ModelSim.
3. Compile the C code using vlog. For example:
vlog *.c

4. Simulate the design. For example

vsim top

DPI and the vlog Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802

Deprecated Legacy DPI Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
When Your DPI Export Function is Not Getting Called . . . . . . . . . . . . . . . . . . . . . . . . . 1803
Troubleshooting a Missing DPI Import Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
Simplified Import of Library Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
Optimizing DPI Import Call Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
DPI Arguments of Parameterized Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
Making Verilog Function Calls from non-DPI C Models . . . . . . . . . . . . . . . . . . . . . . . . 1806
Calling C/C++ Functions Defined in PLI Shared Objects from DPI Code . . . . . . . . . . 1807

DPI and the vlog Command

You can specify C/C++ files on the vlog command line, and the command will invoke the
correct C/C++ compiler based on the file type passed. For example, you can enter the following
command:
vlog verilog1.v verilog2.v mydpicode.c

This vlog command compiles all Verilog files and C/C++ files into the work library. The vsim
command automatically loads the compiled C code at elaboration time.

It is possible to pass custom C compiler flags to vlog using the -ccflags option. vlog does not
check the validity of option(s) you specify with -ccflags. The options are directly passed on to
the compiler, and if they are not valid, an error message is generated by the C compiler.

You can also specify C/C++ files and options in a -f file, and they will be processed the same
way as Verilog files and options in a -f file.

1802 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Deprecated Legacy DPI Flows

It is also possible to pass custom C/C++ linker flags to vsim using the -ldflags option. For
example,

vsim top -ldflags ‘-lcrypt’

This command tells vsim to pass -lcrypt to the GCC linker.

The qverilog command also accepts C/C++ files on the command line. It works similarly to
vlog, but automatically invokes vsim at the end of compilation.

Deprecated Legacy DPI Flows

Legacy use flows may be in use for certain designs from previous versions of ModelSim.
These customized flows may have involved use of -dpiexportobj, -dpiexportonly, or -
nodpiexports, and may have been employed for the following scenarios:

• runtime work library locked

• running parallel vsim simulations on the same design (distributed vsim simulation)
• complex dependency between FLI/PLI/SystemC and DPI
None of the former special handling is required for these scenarios as of version 10.0d and
above. The recommended use flow is as documented in “DPI Use Flow”.

When Your DPI Export Function is Not Getting

Called
This issue can arise in your C code due to the way the C linker resolves symbols. It happens if a
name you choose for a SystemVerilog export function happens to match a function name in a
custom, or even standard C library (for example, “pow”). In this case, your C compiler will bind
calls to the function in that C library, rather than to the export function in the SystemVerilog
simulator.
The symptoms of such a misbinding can be difficult to detect. Generally, the misbound function
silently returns an unexpected or incorrect value.

To determine if you have this type of name aliasing problem, consult the C library
documentation (either the online help or man pages) and look for function names that match any
of your export function names. You should also review any other shared objects linked into
your simulation and look for name aliases there. To get a comprehensive list of your export
functions, you can use the vsim -dpiheader option and review the generated header file.

If you are using an external compilation flow, make sure to use -Bsymbolic on the GCC link
line. For more information, see “Correct Linking of Shared Libraries with -Bsymbolic”.

ModelSim® SE User's Manual, v10.7 1803

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Troubleshooting a Missing DPI Import Function

Troubleshooting a Missing DPI Import Function

DPI uses C function linkage. If your DPI application is written in C++, it is important to
remember to use extern "C" declaration syntax appropriately. Otherwise the C++ compiler will
produce a mangled C++ name for the function, and the simulator is not able to locate and bind
the DPI call to that function.
Also, if you do not use the -Bsymbolic argument on the command line for specifying a link, the
system may bind to an incorrect function, resulting in unexpected behavior. For more
information, see Correct Linking of Shared Libraries with -Bsymbolic.

Simplified Import of Library Functions

In addition to the traditional method of importing HDL interface, and C library functions, a
simplified method can be used: you can declare HDL interface functions as DPI-C imports.
When you declare HDL interface functions as DPI-C imports, the C implementation of the
import tf is not required.
Also, on most platforms (see Platform Specific Information), you can declare most standard C
library functions as DPI-C imports.

The following example is processed directly, without DPI C code:

package cmath;
import "DPI-C" function real sin(input real x);
import "DPI-C" function real sqrt(input real x);
endpackage

package fli;
import "DPI-C" function mti_Cmd(input string cmd);
endpackage

module top;
import cmath::*;
import fli::*;
int status, A;
initial begin
$display("sin(0.98) = %f", sin(0.98));
$display("sqrt(0.98) = %f", sqrt(0.98));
status = mti_Cmd("change A 123");
$display("A = %1d, status = %1d", A, status);
end
endmodule

To simulate, you would simply enter a command such as: vsim top.

Precompiled packages are available with that contain import declarations for certain commonly
used C calls.

<installDir>/verilog_src/dpi_cpack/dpi_cpackages.sv

1804 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Optimizing DPI Import Call Performance

You do not need to compile this file, it is automatically available as a built-in part of the
SystemVerilog simulator.

Platform Specific Information

On Windows, only FLI and PLI commands may be imported in this fashion. C library functions
are not automatically importable. They must be wrapped in user DPI C functions.

Optimizing DPI Import Call Performance

You can optimize the passing of some array data types across a language boundary.
Most of the overhead associated with argument passing is eliminated if the following conditions
are met:

• DPI import is declared as a DPI-C function, not a task.

• DPI function port mode is input or inout.
• DPI calls are not hierarchical. The actual function call argument must not make use of
hierarchical identifiers.
• For actual array arguments and return values, do not use literal values or concatenation
expressions. Instead, use explicit variables of the same datatype as the formal array
arguments or return type.
• DPI formal arguments can be either fixed-size or open array. They can use the element
types int, shortint, byte, or longint.
Fixed-size array arguments — declaration of the actual array and the formal array must
match in both direction and size of the dimension. For example: int_formal[2:0] and
int_actual[4:2] match and are qualified for optimization. int_formal[2:0] and
int_actual[2:4] do not match and will not be optimized.
Open-array arguments — Actual arguments can be either fixed-size arrays or dynamic
arrays. The topmost array dimension should be the only dimension considered open. All
lower dimensions should be fixed-size subarrays or scalars. High performance actual
arguments: int_arr1[10], int_arr2[], int_arr3[][2] int_arr4[][2][2]. A low performance
actual argument would be slow_arr[2][][2].

DPI Arguments of Parameterized Datatypes

DPI import and export TF's can be written with arguments of parameterized data types.
For example, assuming T1 and T2 are type parameters:

import "DPI-C" function T1 impf(input T2 arg);

ModelSim® SE User's Manual, v10.7 1805

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Making Verilog Function Calls from non-DPI C Models

This feature is only supported when the vopt flow is used (see Optimizing Designs with vopt).
On occasion, the tool may not be able to resolve type parameters while building the optimized
design, in which case the workaround is to rewrite the function without using parameterized
types. The LRM rules for tf signature matching apply to the finally resolved value of type
parameters. See the IEEE Std 1800-2005, Section 26.4.4 for further information on matching
rules.

Making Verilog Function Calls from non-DPI C

Models
Working in certain FLI or PLI C applications, you might want to interact with the simulator by
directly calling Verilog DPI export functions. Such applications may include complex 3rd party
integrations, or multi-threaded C test benches. Normally calls to export functions from PLI or
FLI code are illegal. These calls are referred to as out-of-the-blue calls, since they do not
originate in the controlled environment of a DPI import tf.
You can configure the ModelSim tool to allow out-of-the-blue Verilog function calls either for
all simulations (DpiOutOfTheBlue = 1 in modelsim.ini file), or for a specific simulation (vsim
-dpioutoftheblue 1).

See DpiOutOfTheBlue for information about debugging support for a SystemC method or a
SystemC thread.

The following is an example in which PLI code calls a SystemVerilog export function:

vlog test.sv
gcc -shared -o pli.so pli.c
vsim -pli pli.so top -dpioutoftheblue 1

Here is an example in which SystemC calls a SystemVerilog export function:

vlog test.sv
sccom test.cpp
sccom -link
vsim top sc_top

No -dpioutoftheblue specification is required for SystemC calls.

One restriction applies: only Verilog functions may be called out-of-the-blue. It is illegal to call
Verilog tasks in this way. The simulator issues an error if it detects such a call.

1806 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Calling C/C++ Functions Defined in PLI Shared Objects from DPI Code

Calling C/C++ Functions Defined in PLI Shared

Objects from DPI Code
In some instances you may need to share C/C++ code across different shared objects that
contain PLI and/or DPI code. There are two ways you can achieve this goal:
• The easiest is to include the shared code in an object containing PLI code, and then
make use of the vsim -gblso option.
• Another way is to define a standalone shared object that only contains shared function
definitions, and load that using vsim -gblso. In this case, the process does not require
PLI or DPI loading mechanisms, such as -pli or -sv_lib.
You should also take into consideration what happens when code in one global shared object
needs to call code in another global shared object. In this case, place the -gblso argument for the
calling code on the vsim command line after you place the -gblso argument for the called code.
This is because vsim loads the files in the specified order and you must load called code before
calling code in all cases.

Circular references are not possible to achieve. If you have that kind of condition, you are better
off combining the two shared objects into a single one.

For more information about this topic please refer to the section "Loading Shared Objects with
Global Symbol Visibility."

ModelSim® SE User's Manual, v10.7 1807

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Catalog Usage

PLI Catalog Usage

Use the PLI Catalog File (PCAT file) to control autocompilation of PLI files or as a method of
access control for system tasks and functions.
PLI Catalog (PCAT) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
PLI Catalog Use Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815

1808 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Catalog (PCAT) Files

PLI Catalog (PCAT) Files

The PLI Catalog encapsulates global or per-task access information for each system task or
function, which allows the simulator to preserve visibility while retaining high levels of
optimization.
Note
The syntax of PCAT files is a superset of TAB file syntax, which you may already be using.

PCAT File for Controlling Access Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809

PCAT File with PLI Autocompile Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
PLI Catalog File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811

PCAT File for Controlling Access Information

There are two flows for using a PCAT file in your PLI environment, where you specify only
access information.
It is suggested that you use a PCAT file to specify design object access requirements, as
opposed to using the +acc or -access options to the vopt command). The primary advantage to
using PCAT files is that it is easy to encapsulate design object access requirements for each PLI
systf. This encapsulation allows the simulator to optimize performance in the presence of PLI
without the need for a PLI Learn flow.

• For re-usable PLI-based IP's:

o Compile and distribute in .so form.
o Specify the .so file using the -pli argument to vsim.
o Define (*vlog_startup_routines[]) with function linkage in the C code.
o Distribute a PCAT file that contains access information, but no function linkage.
• For home-grown PLI C code:
o Use the PLI Autocompile flow.
o Define (*vlog_startup_routines[]) with function linkage in the C code.
o Create a PCAT file that contains access information, but no function linkage.

PCAT File with PLI Autocompile Flow

The PCAT file specifies PLI linkage (calltf, checktf, sizetf, compiletf) as well as design access
requirements used during PLI compilation.

ModelSim® SE User's Manual, v10.7 1809

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Catalog (PCAT) Files

The usual PLI/VPI symbol (calltf, misctf, checktf, size, and so on) registration mechanisms are
still required when using PLI Autocompile:

• Making init_usertfs() symbols available in a shared object.

• Specifying a veriusertfs[] table in your C/C++ code.
• Specifying a vlog_startup_routines[] table in your C/C++ code.
• Creating PCAT or TAB file linkage mechanisms.
We recommend using vpi_register_systf() along with (*vlog_startup_routines[]) for symbol
linkage. However, PLI Autocompile does not automate any aspect of the technique for symbol
linkage when you use vlog_startup_routines[], where each startup routine typically calls
vpi_register_systf() to register the symbols with vsim.

The set of all PLI and DPI C/C++ files you submit to the vlog command will be aggregated into
a single autocompile shared object that is loaded at the time you execute vsim.

You can use the method of using a veriusertfs[] table, which declares and registers all system
tasks. The vpi_register_systf() mechanism can be used as well. However, if the veriusertfs[]
registration mechanism is still used, there can only be one veriusertfs[] table in the entire set of
PLI C/C++ files. Otherwise a multiple-defined symbol error will occur upon execution of the
vsim command.

The usual PLI and VPI library registration mechanisms are not required when using PLI
Autocompile, specifically:

• The veriuser modelsim.ini variable.

• The -pli option to the vsim command.
• The PLIOBJS environment variable
However, you can continue using these mechanisms along with precompiled PLI applications in
.so files.

1810 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Catalog (PCAT) Files

PLI Catalog File Reference

PLI Autocompilation.
System Task and Function access control.
The PLI Catalog file contains PLI linkage and access specifications used during the
optimization and simulation stages of yourModelSim flow.
Format
In the PCAT file, the access specifications are processed left to right, for a particular system
task.

The options specified with %CELL, %TASK or <du> are design unit specific and those
specified with <instance> are instance specific.

Access specifications specified for each system task are considered to be independent of each
other and cannot remove an earlier applied access to a certain region. Similarly, the command-
line access specifications are considered to be independent of PLI catalog file access
specifications. The effects of command-line options are not removed by PCAT options.

PLI Catalog Files accept the # comment character.

Each line can take one of two forms:

$<name> <PLI_linkage> [<access_specification>]

or

$<name> <access_specification>

Parameters
• PLI Catalog File Line
Each line of the PCAT File may include the following arguments
Table E-2. PCAT File — Line Syntax
Argument Description
$<name> Identifies the user-defined system task.
<PLI_Linkage> Adds the binding information.
You can specify multiple linkage instructions in a space-
separated list.
<access_specification> adds the required design access information, or visibility. It
is also valid to for access_specification to appear
unqualified with the name and linkage information.

ModelSim® SE User's Manual, v10.7 1811

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Catalog (PCAT) Files

• PLI_Linkage
You can use these keys or key/value pairs on your PLI Catalog File Line
Table E-3. PLI_Linkage Options
Argument Description
call=<function_name> (Required) Name of the C function
corresponding to calltf.
check=<function_name> Name of the C function corresponding to
checktf
misc=<function_name> Name of the C function corresponding to
misctf
data=<integer> This value is passed as the first argument to
the call, check, and misc functions. Defaults
to 0.
size=<integer>[,=<function_name>] (Required for system functions) The size of
the return value in bits for a system function.
Ignored for systasks. Use 'r' for a real-
returning system function.
If <function_name> is present, call the sizetf
and verify its return value matches the
specified <integer>
args=<integer> The number of arguments accepted by the
systf
minargs=<integer> The minimum number of arguments that can
be passed to the systf
maxargs=<integer> The maximum number of arguments that can
be passed to the systf
persistent Allows command line invocation of specified
systf's, even if they are not present in the SV
source code.
• access_specification
The access_specification takes the form:
acc{ = | += | -= | :=}<accesscodes>[:<objectselection>]

Argument Description
acc A literal string that starts the access specification

1812 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Catalog (PCAT) Files

Argument Description
{ = | += | -= | :=} Defines how to treat the <accesscodes> argument.
• = — Adds the <accesscodes> to the selected objects.
• += — Adds the specified <accesscodes> to the selected objects.
• -= — Removes the specified <accesscodes> from the selected
objects.
• := — Replaces any existing <accesscodes> with the specified
<accesscodes> on the selected objects.
<accesscodes> Specifies any access rules, in a comma-separated list, where the
arguments include:
• r — Specifies read access.
• w — Specifies write access
• c — Specifies connectivity access (such as callback, bind, pdu
href.).
:<objectselection> Specifies the objects to which the access information applies. Note the
preceding colon (:) character.
You can specify multiple design units within a comma-separated list,
where the arguments can be:
• %CELL — literal string that allows the systf to access objects
within library cells; that is, modules defined within the scope of a
`celldefine compiler directive, or Verilog modules picked up by
vlog -y or vlog -v.
• %TASK — literal string that identifies all instances of du's that
contain the specified user-defined system task or function. It is
only valid on a line that contains PLI linkage for a specific systf.
• [<du>][+|,<hierlevel>] — specifies the design unit and any
recursion rules. Note that there is no space between the <du> and
subsequent argument.
• <du> — design unit name, that can take one of these forms:
<instance>

[<libname>.]<primary>[(secondary)]

<primary> accepts wildcard characters * and ?.

• + — specifies full recursion below the selected du.
• ,<hierlevel> — specifies recursion to the specified number of
descendant levels, note the preceding comma (,).
If you do not specify <objectselection>, the systf presumes no rights
to access any design information at all.

ModelSim® SE User's Manual, v10.7 1813

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Catalog (PCAT) Files

Examples
• This example defines a system task that will collect design-wide statistics. It can visit
the entire design and perform read accesses on all values.
$statscollector call=statscollect acc+=r:*

• This example defines a system task that implements an FPU model. It can read and write
all signals in instances of the module where it is declared. It can also set callbacks on
signals in those instances.
$fpumodel call=fpucall check=fpucheck acc+=r,w,c:%TASK

• This example defines a system function that adds bits together. It has no right to access
any design objects. It will work purely based on the arguments it is passed during
simulation.
$addbits call=addbits size=32

• This example adds read access to top1 and 3 levels of hierarchy underneath it. It adds
read access to top2 and all of its descendants. The access is unconditionally performed,
as if "vopt -access=r+top1+3+top2." was specified on the command line.
acc=r:top1,3,top2+

1814 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Catalog Use Models

PLI Catalog Use Models

Use PCAT files to manage access information for and autocompilation of PLI files.
Using a PCAT File for Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
Using a PCAT File with PLI Autocompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816

Using a PCAT File for Access Control

You should use a PCAT file to for access control when you have a system task that requests a
specific type of access to the design in order to function.
Procedure
1. Create a PCAT file where a line does not use any portion of the PLI_Linkage argument
set.
For example, the syntax would be:
$<name> <access_specification>

where $<name> is the name of the system task or function and <access_specification>
defines the access requirements for the systf to interact with the design
Refer to “PLI Catalog File Reference” for more information.
2. Specify your PCAT file by using the -P argument to the vopt command (note that this
argument is case-sensitive).
vopt <standard_arguments> -P filename.pcat

The vopt command reads the access specifications portion of the PCAT file, and it
ignores the linkage specifications.
3. (optional) Specify your PCAT file to use the linkage specifications, by using the -P
argument to the vsim command (note that this argument is case-sensitive).
vsim <standard_arguments> -P filename.pcat

If you are using the 2-step flow, vsim automatically forwards the PCAT file to vopt.
Examples
You can run a simulation, such that a system task $printreg can print values of all the registers
in the scope in which it is instantiated. You just need to create a PCAT file that allows the
implementer of that system task to request the defined access option. For example, if
filename.pcat file contains the line:

$printreg acc=read:%TASK

ModelSim® SE User's Manual, v10.7 1815

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Catalog Use Models

read access is applied to only the scopes (if any), in which this system task is instantiated. If the
implementer wants to print values of all the registers in that scope and those under this scope,
you could rewrite the line by appending a +, as shown:

$printreg acc=read:%TASK+

Using a PCAT File with PLI Autocompile

Use a PLI Catalog (PCAT) file to aid the PLI Autocompile flow in linking PLI system tasks and
functions (systf) into your simulation.
Prerequisites
• Create a PCAT file, as defined in the section PLI Catalog File Reference.
Procedure
1. Specify PLI and VPI C/C++ files directly on the vlog command line.
The set of files are aggregated into a single autocompile shared object to be loaded
during the elaboration phase of the vsim command.
2. Specify your PCAT file by using the -P argument to the vopt command (note that this
argument is case-sensitive).
vopt <standard_arguments> -P filename.pcat

The vopt command reads the access specifications portion of the PCAT file, and it
ignores the linkage specifications.
3. (optional) Specify your PCAT file to use the linkage specifications, by using the -P
argument to the vsim command (note that this argument is case-sensitive).
vsim <standard_arguments> -P filename.pcat

If you are using the 2-step flow, vsim automatically forwards the PCAT file to vopt.
Examples
• For this example:
vlib work
vlog test.sv pliapp.c -ccflags "-I /u/apps/include"
vsim -vopt top -c -P pliapp.pcat -do "run -all; quit -f"

o The vlog command includes a PLI C application (pliapp.c).

o The vsim command forwards the -P option to vopt, which is run implicitly. It then
reads the linkage specifications of the pliapp.pcat file and it automatically creates
and loads the auto-compiled PLI then simulates the optimized design along with its
PLI application.

1816 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Catalog Use Models

• For this example:

vlib work
vlog test.sv pliapp1.c pliapp2.c -ccflags "-I /u/apps/include"
vopt -o opttop top
vsim opttop -c -P pliapp1.tab -P pliapp2.tab -do "run -all; quit -f?

o The vlog command compiles two PLI C applications

o The vopt command creates an optimized top.
o The vsim command loads TAB files specific to the two PLI C applications. Note that
TAB files are compatible with PCAT files, as PCAT is a super-set of TAB syntax.

ModelSim® SE User's Manual, v10.7 1817

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Compiling and Linking C Applications for Interfaces

Compiling and Linking C Applications for

Interfaces
The following platform-specific instructions show you how to compile and link your HDL
interface C applications so that they can be loaded by ModelSim. Various native C/C++
compilers are supported on different platforms. The gcc compiler is supported on all platforms.
The following HDL interface routines are declared in the include files located in the ModelSim
<install_dir>/include directory:

• acc_user.h — declares the ACC routines

• veriuser.h — declares the TF routines
• vpi_user.h — declares the VPI routines
• svdpi.h — declares DPI routines
The following instructions assume that the HDL interface application is in a single source file.
For multiple source files, compile each file as specified in the instructions and link all of the
resulting object files together with the specified link instructions.

Although compilation and simulation switches are platform-specific, loading shared libraries is
the same for all platforms. For information on loading libraries for HDL interface see PLI and
VPI File Loading. For DPI loading instructions, see DPI File Loading.

For all UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818

Windows Platforms — C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819
Linux Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820

For all UNIX Platforms

The information in this section applies to all UNIX platforms.

app.so
If app.so is not in your current directory, you must tell the OS where to search for the shared
object. You can do this one of two ways:

• Add a path before app.so in the command line option or control variable (The path may
include environment variables.)
• Put the path in a UNIX shell environment variable:
LD_LIBRARY_PATH_32= <library path without filename> (for 32-bit)
or

1818 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Windows Platforms — C

LD_LIBRARY_PATH_64= <library path without filename> (for 64-bit)

Correct Linking of Shared Libraries with -Bsymbolic

In the examples shown throughout this appendix, the -Bsymbolic linker option is used with the
compilation (gcc or g++) or link (ld) commands to correctly resolve symbols. This option
instructs the linker to search for the symbol within the local shared library and bind to that
symbol if it exists. If the symbol is not found within the library, the linker searches for the
symbol within the vsimk executable and binds to that symbol, if it exists.

When using the -Bsymbolic option, the linker may warn about symbol references that are not
resolved within the local shared library. It is safe to ignore these warnings, provided the
symbols are present in other shared libraries or the vsimk executable. (An example of such a
warning would be a reference to a common API call such as vpi_printf()).

Windows Platforms — C
Windows platforms for C are supported for Microsoft Visual Studio and MinGW.
• Microsoft Visual Studio 2013
Refer to “Creating .dll or .exe Files using Compiled .lib files on Windows Platforms” in
the Installation and Licensing Guide for information on using Microsoft Visual Studio
2013.
For 32-bit:
cl -c -I<install_dir>\modeltech\include app.c
link -dll -export:<init_function> app.obj <install_dir>\win32\
mtipli.lib -out:app.dll

For 64-bit:
cl -c -I<install_dir>\modeltech\include app.c
link -dll -export:<init_function> app.obj <install_dir>\win64\
mtipli.lib -out:app.dll

For the Verilog PLI, the <init_function> should be "init_usertfs". Alternatively, if there
is no init_usertfs function, the <init_function> specified on the command line should be
"veriusertfs".
For the Verilog VPI, the <init_function> should be "vlog_startup_routines". These
requirements ensure that the appropriate symbol is exported, and thus ModelSim can
find the symbol when it dynamically loads the DLL.
If you need to run the profiler (see Profiling Performance and Memory Use) on a design
that contains interface code, add these two switches to the link commands shown above:
/DEBUG /DEBUGTYPE:COFF

ModelSim® SE User's Manual, v10.7 1819

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Linux Platforms — C

These switches add symbols to the .dll that the profiler can use in its report.
If you have Cygwin installed, make sure that the Cygwin link.exe executable is not in
your search path ahead of the Microsoft Visual Studio 2013 link executable. If you
mistakenly bind your dll's with the Cygwin link.exe executable, the .dll will not function
properly. It may be best to rename or remove the Cygwin link.exe file to permanently
avoid this scenario.
• MinGW
For 32-bit:
gcc -c -I<install_dir>\include app.c
gcc -shared -Bsymbolic -o app.dll app.o -L<install_dir>\win32
-lmtipli

The ModelSim tool requires the use of the MinGW gcc compiler rather than the Cygwin
gcc compiler. Remember to add the path to your gcc executable in the Windows
environment variables.
Refer to SystemC Supported Platforms in the Installation and Licensing Guide for more
information.
For 64-bit:
gcc -c -I<install_dir>\include app.c
gcc -shared -Bsymbolic -o app.dll app.o -L<install_dir>\win64
-lmtipli

SystemC is not supported on Windows 64-bit. However, the gcc-4.5.0-mingw64

compiler is shipped along with QuestaSim to enable users compile their C-interfaces
source files with mingw-gcc. The C Debug feature is not supported with this compiler.

Linux Platforms — C
If your HDL interface application uses anything from a system library, you must specify that
library when you link your HDL interface application.
• For 32-bit — using the standard C library, when linking the shared object:
gcc -c -I<install_dir>/modeltech/include app.c
gcc -shared -Bsymbolic -o app.so app.o -lc

The compiler switch -freg-struct-return must be used when compiling any FLI
application code that contains foreign functions that return real or time values.
• For 64-bit:
gcc -c -fPIC -I<install_dir>/modeltech/include app.c
gcc -shared -Bsymbolic -o app.so app.o

1820 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Linux Platforms — C

To compile 64-bit systems for 32-bit operation, specify the -m32 argument on both the
compile and link gcc command lines.
If your HDL interface application requires a user or vendor-supplied C library, or an
additional system library, you must specify that library when you link your HDL
interface application. For example, to use the system math library libm, specify -lm
when linking the shared object:
gcc -c -fPIC -I<install_dir>/modeltech/include math_app.c
gcc -shared -Bsymbolic -o math_app.so math_app.o -lm

ModelSim® SE User's Manual, v10.7 1821

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Compiling and Linking C++ Applications for Interfaces

Compiling and Linking C++ Applications for

Interfaces
ModelSim does not have direct support for any language other than standard C; however, C++
code can be loaded and executed under certain conditions.
Since ModelSim's HDL interface functions have a standard C prototype, you must prevent the
C++ compiler from mangling the HDL interface function names. This can be accomplished by
using the following type of extern:

extern "C"
{
<HDL interface application function prototypes>
}

The header files veriuser.h, acc_user.h, and vpi_user.h, svdpi.h, and dpiheader.h already
include this type of extern. You must also put the HDL interface shared library entry point
(veriusertfs, init_usertfs, or vlog_startup_routines) inside of this type of extern.

You must also place an ‘extern “C”’ declaration immediately before the body of every import
function in your C++ source code, for example:

extern "C"
int myimport(int i)
{
vpi_printf("The value of i is %d\n", i);
}

The following platform-specific instructions show you how to compile and link your
HDL interface C++ applications so that they can be loaded by ModelSim.

Although compilation and simulation switches are platform-specific, loading shared libraries is
the same for all platforms. For information on loading libraries, see DPI File Loading.

For PLI/VPI only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822

Windows Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823
Linux Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824

For PLI/VPI only

If app.so is not in your current directory you must tell Linux where to search for the shared
object. You can do this one of two ways:
• Add a path before app.so in the foreign attribute specification. (The path may include
environment variables.)

1822 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Windows Platforms — C++

• Put the path in a UNIX shell environment variable:

LD_LIBRARY_PATH_32= <library path without filename> (32-bit) or
LD_LIBRARY_PATH_64= <library path without filename> (64-bit)

Windows Platforms — C++

Windows platforms for C++ are supported for Microsoft Visual Studio and MinGW.
• Microsoft Visual Studio 2013
Refer to “Creating .dll or .exe Files using Compiled .lib files on Windows Platforms” in
the Installation and Licensing Guide for information on using Microsoft Visual Studio
2013.
For 32-bit:
cl -c [-GX] -I<install_dir>\modeltech\include app.cxx
link -dll -export:<init_function> app.obj
<install_dir>\modeltech\win32\mtipli.lib /out:app.dll

For 64-bit:
cl -c [-GX] -I<install_dir>\modeltech\include app.cxx
link -dll -export:<init_function> app.obj
<install_dir>\modeltech\win64\mtipli.lib /out:app.dll

The -GX argument enables exception handling.

For the Verilog PLI, the <init_function> should be "init_usertfs". Alternatively, if there
is no init_usertfs function, the <init_function> specified on the command line should be
"veriusertfs".
For the Verilog VPI, the <init_function> should be "vlog_startup_routines". These
requirements ensure that the appropriate symbol is exported, and thus ModelSim can
find the symbol when it dynamically loads the DLL.
If you need to run the profiler (see Profiling Performance and Memory Use) on a design
that contains HDL interface code, add these two switches to the link command shown
above:
/DEBUG /DEBUGTYPE:COFF

These switches add symbols to the .dll that the profiler can use in its report.
If you have Cygwin installed, make sure that the Cygwin link.exe executable is not in
your search path ahead of the Microsoft Visual C link executable. If you mistakenly bind
your dll's with the Cygwin link.exe executable, the .dll will not function properly. It may
be best to rename or remove the Cygwin link.exe file to permanently avoid this scenario.
• MinGW

ModelSim® SE User's Manual, v10.7 1823

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Linux Platforms — C++

For 32-bit:
g++ -c -I<install_dir>\modeltech\include app.cpp
g++ -shared -Bsymbolic -o app.dll app.o
-L<install_dir>\modeltech\win32 -lmtipli

For 64-bit:
g++ -c -I<install_dir>\modeltech\include app.cpp
g++ -shared -Bsymbolic -o app.dll app.o
-L<install_dir>\modeltech\win64 -lmtipli

ModelSim requires the use of the MinGW gcc compiler rather than the Cygwin gcc
compiler.

Linux Platforms — C++

Linux platforms are supported as follows.
• For 32-bit — the GNU C compiler and link commands might be:
g++ -c -fPIC -I<install_dir>/modeltech/include app.cpp
g++ -shared -Bsymbolic -fPIC -o app.so app.o

• For 64-bit — the GNU C compiler and link commands might be:
g++ -c -fPIC -I<install_dir>/modeltech/include app.cpp
g++ -shared -Bsymbolic -o app.so app.o

To compile 64-bit systems for 32-bit operation, specify the -m32 argument on both the
g++ compiler command line as well as the g++ -shared linker command line.
If your HDL interface application requires a user or vendor-supplied C library, or an
additional system library, you will need to specify that library when you link your HDL
interface application. For example, to use the system math library libm, specify -lm with
the link command:
g++ -c -fPIC -I<install_dir>/modeltech/include math_app.cpp
g++ -shared -Bsymbolic -o math_app.so math_app.o -lm

1824 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Specifying Application Files to Load

Specifying Application Files to Load

PLI and VPI file loading is identical. DPI file loading uses switches to the vsim command.
PLI and VPI File Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
DPI File Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
Loading Shared Objects with Global Symbol Visibility . . . . . . . . . . . . . . . . . . . . . . . . . 1826

PLI and VPI File Loading

The PLI/VPI applications are specified as follows:
• As a list in the Veriuser entry in the modelsim.ini file:
Veriuser = pliapp1.so pliapp2.so pliappn.so

• As a list in the PLIOBJS environment variable:

% setenv PLIOBJS "pliapp1.so pliapp2.so pliappn.so"

• As a -pli argument to the simulator (multiple arguments are allowed):

-pli pliapp1.so -pli pliapp2.so -pli pliappn.so

Note
On Windows platforms, the file names shown above should end with .dll rather than
.so.

The various methods of specifying PLI/VPI applications can be used simultaneously. The
libraries are loaded in the order listed above. Environment variable references can be used in the
paths to the libraries in all cases.

See also “modelsim.ini Variables” for more information on the modelsim.ini file.

DPI File Loading

This section applies only to external compilation flows. It is not necessary to use any of these
options in the default autocompile flow (using vlog to compile).
DPI applications are specified to vsim using the following SystemVerilog arguments:
Table E-4. vsim Arguments for DPI Application Using External Compilation
Flows
Argument Description
-sv_lib <name> specifies a library name to be searched and used. No filename
extensions must be specified. (The extensions ModelSim expects
are: .dll for Win32/Win64, .so for all other platforms.)

ModelSim® SE User's Manual, v10.7 1825

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Loading Shared Objects with Global Symbol Visibility

Table E-4. vsim Arguments for DPI Application Using External Compilation
Flows (cont.)
Argument Description
-sv_root <name> specifies a new prefix for shared objects as specified by -sv_lib
-sv_liblist specifies a “bootstrap file” to use. See The format for
<bootstrap_file> <bootstrap_file> is as follows:
#!SV_LIBRARIES
<path>/<to>/<shared>/<library>
<path>/<to>/<another>
...
No extension is expected on the shared library.
When the simulator finds an imported task or function, it searches for the symbol in the
collection of shared objects specified using these arguments.

For example, you can specify the DPI application as follows:

vsim -sv_lib dpiapp1 -sv_lib dpiapp2 -sv_lib dpiappn top

It is a mistake to specify DPI import tasks and functions (tf) inside PLI/VPI shared objects.
However, a DPI import tf can make calls to PLI/VPI C code, providing that vsim -gblso was
used to mark the PLI/VPI shared object with global symbol visibility. See Loading Shared
Objects with Global Symbol Visibility.

Loading Shared Objects with Global Symbol

Visibility
On Unix platforms you can load shared objects such that all symbols in the object have global
visibility. To do this, use the -gblso argument to vsim when you load your PLI/VPI application.
For example:
vsim -pli obj1.so -pli obj2.so -gblso obj1.so top

The -gblso argument works in conjunction with the GlobalSharedObjectList variable in the
modelsim.ini file. This variable allows user C code in other shared objects to refer to symbols in
a shared object that has been marked as global. All shared objects marked as global are loaded
by the simulator earlier than any non-global shared objects.

PLI Example
The following example shows a small but complete PLI application for Linux.

1826 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
VPI Example

hello.c:
#include "veriuser.h"
static PLI_INT32 hello()
{
io_printf("Hi there\n");
return 0;
}
s_tfcell veriusertfs[] = {
{usertask, 0, 0, 0, hello, 0, "$hello"},
{0} /* last entry must be 0 */
};
hello.v:
module hello;
initial $hello;
endmodule
Compile the PLI code for a 32-bit Linux Platform:
% gcc -c -I <install_dir>/questasim/include hello.c
% gcc -shared -Bsymbolic -o hello.so hello.o -lc
Compile the Verilog code:
% vlib work
% vlog hello.v
Simulate the design:
vsim -c -pli hello.so hello
# Loading ./hello.so

VPI Example
The following example is a trivial, but complete VPI application. A general VPI example can be
found in <install_dir>/modeltech/examples/verilog/vpi.

ModelSim® SE User's Manual, v10.7 1827

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
DPI Example

hello.c:
#include "vpi_user.h"
static PLI_INT32 hello(PLI_BYTE8 * param)
{
vpi_printf( "Hello world!\n" );
return 0;
}
void RegisterMyTfs( void )
{
s_vpi_systf_data systf_data;
vpiHandle systf_handle;
systf_data.type = vpiSysTask;
systf_data.sysfunctype = vpiSysTask;
systf_data.tfname = "$hello";
systf_data.calltf = hello;
systf_data.compiletf = 0;
systf_data.sizetf = 0;
systf_data.user_data = 0;
systf_handle = vpi_register_systf( &systf_data );
vpi_free_object( systf_handle );
}
void (*vlog_startup_routines[])() = {
RegisterMyTfs,
0
};
hello.v:
module hello;
initial $hello;
endmodule
Compile the Verilog code:
% vlib work
% vlog hello.v
Simulate the design:
% vsim -c -pli hello.sl hello
# Loading work.hello
# Loading ./hello.sl
VSIM 1> run -all
# Hello world!
VSIM 2> quit

DPI Example
The following example is a trivial but complete DPI application. For additional examples, see
the <install_dir>/modeltech/examples/systemverilog/dpi directory.

1828 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
The PLI Callback reason Argument

hello_c.c:
#include "svdpi.h"
#include "dpiheader.h"
int c_task(int i, int *o)
{
printf("Hello from c_task()\n");
verilog_task(i, o); /* Call back into Verilog */
*o = i;
return(0); /* Return success (required by tasks) */
}
hello.v:
module hello_top;
int ret;
export "DPI-C" task verilog_task;
task verilog_task(input int i, output int o);
#10;
$display("Hello from verilog_task()");
endtask
import "DPI-C" context task c_task(input int i, output int o);
initial
begin
c_task(1, ret); // Call the c task named 'c_task()'
end
endmodule
Compile the Verilog code:
% vlib work
% vlog -sv -dpiheader dpiheader.h hello.v hello_c.c
Simulate the design:
% vsim -c hello_top -do "run -all; quit -f"
# Loading work.hello_c
VSIM 1> run -all
# Hello from c_task()
# Hello from verilog_task()
VSIM 2> quit

The PLI Callback reason Argument

The second argument to a PLI callback function is the reason argument. The values of the
various reason constants are defined in the veriuser.h include file. See the IEEE Std 1364 for a
description of the reason constants. The following details relate to ModelSim Verilog, and may
not be obvious in the IEEE Std 1364. Specifically, the simulator passes the reason values to the
misctf callback functions under the following circumstances:
reason_endofcompile

For the completion of loading the design.

reason_finish

For the execution of the $finish system task or the quit command.

reason_startofsave

ModelSim® SE User's Manual, v10.7 1829

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
The PLI Callback reason Argument

For the start of execution of the checkpoint command, but before any of the simulation state
has been saved. This allows the PLI application to prepare for the save, but it will not save
its data with calls to tf_write_save() until it is called with reason_save.

reason_save

For the execution of the checkpoint command. This is when the PLI application must save
its state with calls to tf_write_save().

reason_startofrestart

For the start of execution of the restore command, but before any of the simulation state has
been restored. This allows the PLI application to prepare for the restore, but it will not
restore its state with calls to tf_read_restart() until it is called with reason_restart. The
reason_startofrestart value is passed only for a restore command, and not when the
simulator is invoked with -restore.

reason_restart

For the execution of the restore command. This is when the PLI application must restore its
state with calls to tf_read_restart().

reason_reset

For the execution of the restart command. This is when the PLI application should free its
memory and reset its state. We recommend that all PLI applications reset their internal state
during a restart as the shared library containing the PLI code might not be reloaded. (See the
-keeploaded and -keeploadedrestart arguments to vsim for related information.)

reason_endofreset

For the completion of the restart command, after the simulation state has been reset but
before the design has been reloaded.

reason_interactive

For the execution of the $stop system task or any other time the simulation is interrupted and
waiting for user input.

reason_scope

For the execution of the environment command or selecting a scope in the structure
window. Also for the call to acc_set_interactive_scope() if the callback_flag argument is
non-zero.

reason_paramvc

For the change of value on the system task or function argument.

reason_synch

For the end of time step event scheduled by tf_synchronize().

1830 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
The sizetf Callback Function

reason_rosynch

For the end of time step event scheduled by tf_rosynchronize().

reason_reactivate

For the simulation event scheduled by tf_setdelay().

reason_paramdrc

Not supported in ModelSim Verilog.

reason_force

Not supported in ModelSim Verilog.

reason_release

Not supported in ModelSim Verilog.

reason_disable

Not supported in ModelSim Verilog.

The sizetf Callback Function

A user-defined system function specifies the width of its return value with the sizetf callback
function, and the simulator calls this function while loading the design. The following details on
the sizetf callback function are not found in the IEEE Std 1364:
• If you omit the sizetf function, then a return width of 32 is assumed.
• The sizetf function should return 0 if the system function return value is of Verilog type
"real".
• The sizetf function should return -32 if the system function return value is of Verilog
type "integer".

PLI Object Handles

Many of the object handles returned by the PLI ACC routines are pointers to objects that
naturally exist in the simulation data structures, and the handles to these objects are valid
throughout the simulation, even after the acc_close() routine is called. However, some of the

ModelSim® SE User's Manual, v10.7 1831

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Third Party PLI Applications

objects are created on demand, and the handles to these objects become invalid after acc_close()
is called. The following object types are created on demand in ModelSim Verilog:
accOperator (acc_handle_condition)
accWirePath (acc_handle_path)
accTerminal (acc_handle_terminal, acc_next_cell_load, acc_next_driver, and
acc_next_load)
accPathTerminal (acc_next_input and acc_next_output)
accTchkTerminal (acc_handle_tchkarg1 and acc_handle_tchkarg2)
accPartSelect (acc_handle_conn, acc_handle_pathin, and acc_handle_pathout)

If your PLI application uses these types of objects, then it is important to call acc_close() to free
the memory allocated for these objects when the application is done using them.

If your PLI application places value change callbacks on accRegBit or accTerminal objects, do
not call acc_close() while these callbacks are in effect.

Third Party PLI Applications

Many third party PLI applications come with instructions on using them with ModelSim
Verilog. Even without the instructions, it is still likely that you can get it to work with
ModelSim Verilog as long as the application uses standard PLI routines. The following
guidelines are for preparing a Verilog-XL PLI application to work with ModelSim Verilog.
Generally, a Verilog-XL PLI application comes with a collection of object files and a veriuser.c
file. The veriuser.c file contains the registration information as described above in Registering
PLI Applications. To prepare the application for ModelSim Verilog, you must compile the
veriuser.c file and link it to the object files to create a dynamically loadable object (see
Compiling and Linking C Applications for Interfaces). For example, if you have a veriuser.c
file and a library archive libapp.a file that contains the application's object files, then the
following commands should be used to create a dynamically loadable object for the Linux
operating system:

% gcc -c -I<install_dir>/modeltech/include veriuser.c

% gcc -shared -Bsymbolic -o app.so veriuser.o libapp.a

The PLI application is now ready to be run with ModelSim Verilog. All that is left is to specify
the resulting object file to the simulator for loading using the Veriuser entry in the modesim.ini
file, the -pli simulator argument, or the PLIOBJS environment variable (see Registering PLI
Applications).

Support for VHDL Objects

The PLI ACC routines also provide limited support for VHDL objects in either an all VHDL
design or a mixed VHDL/Verilog design.

1832 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Support for VHDL Objects

The following table lists the VHDL objects for which handles may be obtained and their type
and fulltype constants:
Table E-5. Supported VHDL Objects
Type Fulltype Description
accArchitecture accArchitecture instantiation of an architecture
accArchitecture accEntityVitalLevel0 instantiation of an architecture whose entity is
marked with the attribute VITAL_Level0
accArchitecture accArchVitalLevel0 instantiation of an architecture which is
marked with the attribute VITAL_Level0
accArchitecture accArchVitalLevel1 instantiation of an architecture which is
marked with the attribute VITAL_Level1
accArchitecture accForeignArch instantiation of an architecture which is
marked with the attribute FOREIGN and
which does not contain any VHDL statements
or objects other than ports and generics
accArchitecture accForeignArchMixed instantiation of an architecture which is
marked with the attribute FOREIGN and
which contains some VHDL statements or
objects besides ports and generics
accBlock accBlock block statement
accForLoop accForLoop for loop statement
accForeign accShadow foreign scope created by mti_CreateRegion()
accGenerate accGenerate generate statement
accPackage accPackage package declaration
accSignal accSignal signal declaration

The type and fulltype constants for VHDL objects are defined in the acc_vhdl.h include file. All
of these objects (except signals) are scope objects that define levels of hierarchy in the structure
window. Currently, the PLI ACC interface has no provision for obtaining handles to generics,
types, constants, variables, attributes, subprograms, and processes.

However, some of these objects can be manipulated through the ModelSim VHDL foreign
interface (mti_* routines). See the FLI Reference Manual for more information.

ModelSim® SE User's Manual, v10.7 1833

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
IEEE Std 1364 ACC Routines

IEEE Std 1364 ACC Routines

ModelSim Verilog supports the following ACC routines:

1834 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
IEEE Std 1364 ACC Routines

ModelSim® SE User's Manual, v10.7 1835

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
IEEE Std 1364 ACC Routines

Table E-6. Supported ACC Routines

Routines
acc_append_delays acc_free acc_next
acc_append_pulsere acc_handle_by_name acc_next_bit
acc_close acc_handle_calling_mod_m acc_next_cell
acc_collect acc_handle_condition acc_next_cell_load
acc_compare_handles acc_handle_conn acc_next_child
acc_configure acc_handle_hiconn acc_next_driver
acc_count acc_handle_interactive_scope acc_next_hiconn
acc_fetch_argc acc_handle_loconn acc_next_input
acc_fetch_argv acc_handle_modpath acc_next_load
acc_fetch_attribute acc_handle_notifier acc_next_loconn
acc_fetch_attribute_int acc_handle_object acc_next_modpath
acc_fetch_attribute_str acc_handle_parent acc_next_net
acc_fetch_defname acc_handle_path acc_next_output
acc_fetch_delay_mode acc_handle_pathin acc_next_parameter
acc_fetch_delays acc_handle_pathout acc_next_port
acc_fetch_direction acc_handle_port acc_next_portout
acc_fetch_edge acc_handle_scope acc_next_primitive
acc_fetch_fullname acc_handle_simulated_net acc_next_scope
acc_fetch_fulltype acc_handle_tchk acc_next_specparam
acc_fetch_index acc_handle_tchkarg1 acc_next_tchk
acc_fetch_location acc_handle_tchkarg2 acc_next_terminal
acc_fetch_name acc_handle_terminal acc_next_topmod
acc_fetch_paramtype acc_handle_tfarg acc_object_in_typelist
acc_fetch_paramval acc_handle_itfarg acc_object_of_type
acc_fetch_polarity acc_handle_tfinst acc_product_type
acc_fetch_precision acc_initialize acc_product_version
acc_fetch_pulsere acc_release_object
acc_fetch_range acc_replace_delays
acc_fetch_size acc_replace_pulsere
acc_fetch_tfarg acc_reset_buffer
acc_fetch_itfarg acc_set_interactive_scope
acc_fetch_tfarg_int acc_set_pulsere
acc_fetch_itfarg_int acc_set_scope
acc_fetch_tfarg_str acc_set_value
acc_fetch_itfarg_str acc_vcl_add
1836 ModelSim® SE User's Manual, v10.7
acc_fetch_timescale_info acc_vcl_delete
acc_fetch_type acc_version
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
acc_fetch_type_str
 Verilog Interfaces to C
IEEE Std 1364 TF Routines

acc_fetch_paramval() cannot be used on 64-bit platforms to fetch a string value of a parameter.

Because of this, the function acc_fetch_paramval_str() has been added to the PLI for this use.
acc_fetch_paramval_str() is declared in acc_user.h. It functions in a manner similar to
acc_fetch_paramval() except that it returns a char *. acc_fetch_paramval_str() can be used on
all platforms.

IEEE Std 1364 TF Routines

ModelSim Verilog supports the following TF (task and function) routines;

ModelSim® SE User's Manual, v10.7 1837

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
IEEE Std 1364 TF Routines

1838 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
IEEE Std 1364 TF Routines

Table E-7. Supported TF Routines

Routines
io_mcdprintf tf_getrealtime tf_scale_longdelay
io_printf tf_igetrealtime tf_scale_realdelay
mc_scan_plusargs tf_gettime tf_setdelay
tf_add_long tf_igettime tf_isetdelay
tf_asynchoff tf_gettimeprecision tf_setlongdelay
tf_iasynchoff tf_igettimeprecision tf_isetlongdelay
tf_asynchon tf_gettimeunit tf_setrealdelay
tf_iasynchon tf_igettimeunit tf_isetrealdelay
tf_clearalldelays tf_getworkarea tf_setworkarea
tf_iclearalldelays tf_igetworkarea tf_isetworkarea
tf_compare_long tf_long_to_real tf_sizep
tf_copypvc_flag tf_longtime_tostr tf_isizep
tf_icopypvc_flag tf_message tf_spname
tf_divide_long tf_mipname tf_ispname
tf_dofinish tf_imipname tf_strdelputp
tf_dostop tf_movepvc_flag tf_istrdelputp
tf_error tf_imovepvc_flag tf_strgetp
tf_evaluatep tf_multiply_long tf_istrgetp
tf_ievaluatep tf_nodeinfo tf_strgettime
tf_exprinfo tf_inodeinfo tf_strlongdelputp
tf_iexprinfo tf_nump tf_istrlongdelputp
tf_getcstringp tf_inump tf_strrealdelputp
tf_igetcstringp tf_propagatep tf_istrrealdelputp
tf_getinstance tf_ipropagatep tf_subtract_long
tf_getlongp tf_putlongp tf_synchronize
tf_igetlongp tf_iputlongp tf_isynchronize
tf_getlongtime tf_putp tf_testpvc_flag
tf_igetlongtime tf_iputp tf_itestpvc_flag
tf_getnextlongtime tf_putrealp tf_text
tf_getp tf_iputrealp tf_typep
tf_igetp tf_read_restart tf_itypep
tf_getpchange tf_real_to_long tf_unscale_longdelay
tf_igetpchange tf_rosynchronize tf_unscale_realdelay
tf_getrealp tf_irosynchronize tf_warning
tf_igetrealp tf_write_save
ModelSim® SE User's Manual, v10.7 1839

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
SystemVerilog DPI Access Routines

SystemVerilog DPI Access Routines

ModelSim SystemVerilog supports all routines defined in the "svdpi.h" file defined in the IEEE
Std 1800-2005.

Verilog-XL Compatible Routines

The following PLI routines are not defined in IEEE Std 1364, but ModelSim Verilog provides
them for compatibility with Verilog-XL.
char *acc_decompile_exp(handle condition)

This routine provides similar functionality to the Verilog-XL acc_decompile_expr routine. The
condition argument must be a handle obtained from the acc_handle_condition routine. The
value returned by acc_decompile_exp is the string representation of the condition expression.

char *tf_dumpfilename(void)

This routine returns the name of the VCD file.

void tf_dumpflush(void)

A call to this routine flushes the VCD file buffer (same effect as calling $dumpflush in the
Verilog code).

int tf_getlongsimtime(int *aof_hightime)

This routine gets the current simulation time as a 64-bit integer. The low-order bits are returned
by the routine, while the high-order bits are stored in the aof_hightime argument.

64-bit Support for PLI

The PLI function acc_fetch_paramval() cannot be used on 64-bit platforms to fetch a string
value of a parameter. Because of this, the function acc_fetch_paramval_str() has been added to
the PLI for this use. acc_fetch_paramval_str() is declared in acc_user.h. It functions in a manner
similar to acc_fetch_paramval() except that it returns a char *. acc_fetch_paramval_str() can be
used on all platforms.

Using 64-bit ModelSim with 32-bit Applications

If you have 32-bit PLI/VPI/DPI applications and want to use 64-bit ModelSim, you will need to
port your code to 64 bits by moving from the ILP32 data model to the LP64 data model. To do
this, it is strongly recommended that you consult the 64-bit porting guides for Sun.

1840 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI/VPI Tracing

PLI/VPI Tracing
The foreign interface tracing feature is available for tracing PLI and VPI function calls. Foreign
interface tracing creates two kinds of traces: a human-readable log of what functions were
called, the value of the arguments, and the results returned; and a set of C-language files that can
be used to replay what the foreign interface code did.
The Purpose of Tracing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Invoking a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841

The Purpose of Tracing Files

The purpose of the logfile is to aid you in debugging PLI or VPI code. The primary purpose of
the replay facility is to send the replay files to support for debugging co-simulation problems, or
debugging PLI/VPI problems for which it is impractical to send the PLI/VPI code. We still need
you to send the VHDL/Verilog part of the design to actually execute a replay, but many
problems can be resolved with the trace only.

Invoking a Trace
Context: PLI/VPI debugging
To invoke the trace, call vsim with the -trace_foreign argument.

Syntax
vsim

-trace_foreign <action> [-tag <name>]

Arguments
<action>

Can be either the value 1, 2, or 3. Specifies one of the following actions:

Table E-8. Values for action Argument
Value Operation Result
1 create log only writes a local file called
"mti_trace_<tag>"
2 create replay only writes local files called
"mti_data_<tag>.c",
"mti_init_<tag>.c",
"mti_replay_<tag>.c" and
"mti_top_<tag>.c"

ModelSim® SE User's Manual, v10.7 1841

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Checkpointing and Interface Code

Table E-8. Values for action Argument (cont.)

Value Operation Result
3 create both log and writes all above files
replay
-tag <name>

Used to give distinct file names for multiple traces. Optional.

Examples
vsim -trace_foreign 1 mydesign

Creates a logfile.

vsim -trace_foreign 3 mydesign

Creates both a logfile and a set of replay files.

vsim -trace_foreign 1 -tag 2 mydesign

Creates a logfile with a tag of "2".

The tracing operations will provide tracing during all user foreign code-calls, including PLI/VPI
user tasks and functions (calltf, checktf, sizetf and misctf routines), and Verilog VCL callbacks.

Related Topics
vsim [ModelSim SE Command Reference Manual]
PLI/VPI Tracing

Checkpointing and Interface Code

The checkpoint feature in ModelSim captures the state of PLI/VPI/DPI code.
See The PLI Callback reason Argument for reason arguments that apply to checkpoint/restore

You can use the FLI interface mti_AddDPISaveRestoreCB() to save and restore the states of C
code. This DPI checkpoint/restore support is limited to linux and linux_x86_64 platforms if
there are active DPI threads at the time of creating simulation checkpoint.

You can find an example in the <install_dir>/examples/systemverilog/dpi/checkpoint directory.

Checkpointing Code that Works with Heap Memory

If checkpointing code that works with heap memory, use mti_Malloc() rather than raw malloc()
or new. Any memory allocated with mti_Malloc() is guaranteed to be restored correctly. Any

1842 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
Debugging Interface Application Code

memory allocated with raw malloc() will not be restored correctly, and simulator crashes can
result.

Debugging Interface Application Code

ModelSim offers the optional C Debug feature, which allows you to interactively debug
SystemC/C/C++ source code with the open-source gdb debugger.
See C Debug for details on this debugging tool. If you do not have access to C Debug, continue
reading for instructions on how to attach to an external C debugger.

In order to debug your HDL interface application code in a debugger, you must first:

1. Compile the application code with debugging information (using the -g option) and
without optimizations (for example, do not use the -O option).
2. Load vsim into a debugger.
Even though vsim is stripped, most debuggers will still execute it. You can invoke the
debugger directly on vsimk, the simulation kernel where your application code is loaded
(for example, "ddd `which vsimk`"), or you can attach the debugger to an already
running vsim process. In the second case, you must attach to the PID for vsimk, and you
must specify the full path to the vsimk executable (for example, "gdb
<modelsim_install_directory>/<platform>/vsimk 1234").
On Linux systems you can use either ${MTI_HOME}/${PLATFORM}/external/gdb or
ddd --debugger ${MTI_HOME}/${PLATFORM}/external/gdb.
3. Set an entry point using breakpoint.
Since initially the debugger recognizes only vsim's HDL interface function symbols,
when invoking the debugger directly on vsim you need to place a breakpoint in the first
HDL interface function that is called by your application code. An easy way to set an
entry point is to put a call to acc_product_version() as the first executable statement in
your application code. Then, after vsim has been loaded into the debugger, set a
breakpoint in this function. Once you have set the breakpoint, run vsim with the usual
arguments.
When the breakpoint is reached, the shared library containing your application code has
been loaded.
4. In some debuggers, you must use the share command to load the application's symbols.
At this point all of the application's symbols should be visible. You can now set breakpoints in
and single step through your application code.

Related Topics
vsim [ModelSim SE Command Reference Manual]

ModelSim® SE User's Manual, v10.7 1843

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
Debugging Interface Application Code

C Debug
PLI/VPI Tracing

1844 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix F
System Initialization

ModelSim goes through numerous steps as it initializes the system during startup. It accesses
various files and environment variables to determine library mappings, configure the GUI,
check licensing, and so forth.
Files Accessed During Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1848

Files Accessed During Startup

When you invoke ModelSim, it reads several files in file system and configuration environment.
Table F-1 lists the files that are read during startup. They are listed in the order in which they are
accessed.
Table F-1. Files That ModelSim Accesses During Startup
File Description
modelsim.ini Contains initial tool settings; see modelsim.ini
Variables for specific details on the modelsim.ini file
and Initialization Sequence for the search precedence
location map file Used by ModelSim tools to find source files based on
easily reallocated "soft" paths; default file name is
mgc_location_map
pref.tcl Contains defaults for fonts, colors, prompts, window
positions, and other simulator window characteristics
.modelsim (UNIX) or Contains last working directory, project file, printer
Windows registry defaults, and other user-customized GUI
characteristics
modelsim.tcl Contains user-customized settings for fonts, colors,
prompts, other GUI characteristics; maintained for
backwards compatibility with older versions (refer to
The modelsim.tcl File in the GUI Reference Manual.)
<project_name>.mpf If available, loads last project file which is specified in
the registry (Windows) or $(HOME)/.modelsim
(UNIX); see What are Projects? for details on project
settings

ModelSim® SE User's Manual, v10.7 1845

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Initialization Sequence

Initialization Sequence
The numberd items listed below describe the initialization sequence for ModelSim. The
sequence includes a number of conditional structures, the results of which are determined by the
existence of certain files and the current settings of environment variables.
Names that appear in uppercase denote environment variables (except MTI_LIB_DIR which is
a Tcl variable). Instances of $(NAME) denote paths that are determined by an environment
variable (except $(MTI_LIB_DIR) which is determined by a Tcl variable).

1. Determines the path to the executable directory (../modeltech/<platform>). Sets

MODEL_TECH to this path, unless MODEL_TECH_OVERRIDE exists, in which case
MODEL_TECH is set to the same value as MODEL_TECH_OVERRIDE.
Environment Variables used: MODEL_TECH, MODEL_TECH_OVERRIDE
2. Finds the modelsim.ini file by evaluating the following conditions:
o If the -modelsimini option is used, then the file path specified is used if it exists; else
o use $MODELSIM (which specifies the directory location and name of a
modelsim.ini file) if it exists; else
o use $(MGC_WD)/modelsim.ini; else
o use ./modelsim.ini; else
o use $(MODEL_TECH)/modelsim.ini; else
o use $(MODEL_TECH)/../modelsim.ini; else
o use $(MGC_HOME)/lib/modelsim.ini; else
o set path to ./modelsim.ini even though the file does not exist
Environment Variables used: MODELSIM, MGC_WD, MGC_HOME
You can determine which modelsim.ini file was used by executing the where command.
3. Reads various variables from the [vsim] section of the modelsim.ini file. See
modelsim.ini Variables for more details.
4. Parses any command line arguments that were included when you started ModelSim and
reports any problems.
5. Defines the following environment variables:
o use MODEL_TECH_TCL if it exists; else
o set MODEL_TECH_TCL=$(MODEL_TECH)/../tcl
o set TCL_LIBRARY=$(MODEL_TECH_TCL)/tcl8.4
o set TK_LIBRARY=$(MODEL_TECH_TCL)/tk8.4

1846 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Initialization Sequence

o set ITCL_LIBRARY=$(MODEL_TECH_TCL)/itcl3.0
o set ITK_LIBRARY=$(MODEL_TECH_TCL)/itk3.0
o set VSIM_LIBRARY=$(MODEL_TECH_TCL)/vsim
Environment Variables used: MODEL_TECH_TCL, TCL_LIBRARY, TK_LIBRARY,
MODEL_TECH, ITCL_LIBRARY, ITK_LIBRARY, VSIM_LIBRARY
6. Initializes the simulator’s Tcl interpreter.
7. Checks for a valid license (a license is not checked out unless specified by a
modelsim.ini setting or command line option).
8. The next four steps relate to initializing the graphical user interface.
9. Sets Tcl variable MTI_LIB_DIR=$(MODEL_TECH_TCL)
Environment Variables used: MTI_LIB_DIR, MODEL_TECH_TCL
10. Loads $(MTI_LIB_DIR)/vsim/pref.tcl.
Environment Variables used: MTI_LIB_DIR
11. Loads GUI preferences, project file, and so forth, from the registry (Windows) or
$(HOME)/.modelsim (Linux).
Environment Variables used: HOME
12. Searches for the modelsim.tcl file by evaluating the following conditions:
o use MODELSIM_TCL environment variable if it exists (if MODELSIM_TCL is a
list of files, each file is loaded in the order that it appears in the list); else
o use ./modelsim.tcl; else
o use $(HOME)/modelsim.tcl if it exists
Environment Variables used: HOME, MODEL_TECH_TCL
That completes the initialization sequence. Also note the following about the modelsim.ini file:

• When you change the working directory within ModelSim, it reads the [library], [vcom],
and [vlog] sections of the local modelsim.ini file. When you make changes in the
compiler or simulator options dialog box or use the vmap command, ModelSim updates
the appropriate sections of the file.
• The pref.tcl file references the default .ini file by using the [GetPrivateProfileString] Tcl
command. The .ini file that is read will be the default file defined at the time pref.tcl is
loaded.

ModelSim® SE User's Manual, v10.7 1847

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Environment Variables

Environment Variables
When you install ModelSim, the installation process creates and reads several environment
variables for the operating system of your computer. Most of these variables have default
values, which you can change to customize ModelSim operation.
Expansion of Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1848
Setting Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849
Creating Environment Variables in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854
Library Mapping with Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
Referencing Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
Removal of Temporary Files (VSOUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856

Expansion of Environment Variables

ModelSim shell commands vcom, vlog, vsim, and vmap, do not expand environment variables
in filename arguments and options. Instead, you should expand variables in the shell window in
the usual manner before running these ModelSim commands. The -f switch that most of these
commands support performs environment variable expansion throughout the file.
Environment variable expansion is still performed in the following places:

• Pathname and other values in the modelsim.ini file

• Strings used as file pathnames in VHDL and Verilog
• VHDL Foreign attributes
• The PLIOBJS environment variable may contain a path that has an environment
variable.
• Verilog `uselib file and dir directives
• Anywhere in the contents of a -f file
The recommended method for using flexible pathnames is to make use of the MGC Location
Map system (see Using Location Mapping). When this is used, then pathnames stored in
libraries and project files (.mpf) will be converted to logical pathnames.

If a file or path name contains the dollar sign character ($), and must be used in one of the places
listed above that accepts environment variables, then the explicit dollar sign must be escaped by
using a double dollar sign ($$).

Related Topics
Creating Environment Variables in Windows
edit [ModelSim SE Command Reference Manual]

1848 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Setting Environment Variables

Location Mapping
modelsim.ini Variables
vlog [ModelSim SE Command Reference Manual]
Setting Environment Variables

Setting Environment Variables

Before compiling or simulating, you can specify values for a variety of environment variables to
provide the functions described below.
You set the variables according the operating system of your computer, as follows:

• Windows — use the System control panel, refer to “Creating Environment Variables in
Windows” for more information.
• Linux — typically, by modifying the .login script in a shell window.

Tip
The LM_LICENSE_FILE variable requires a value; all other variables are optional.

DISABLE_ELAB_DEBUG
The DISABLE_ELAB_DEBUG environment variable, if set, disables vsim elaboration error
debugging capabilities using the find insource and typespec commands.

DOPATH
The toolset uses the DOPATH environment variable to search for DO files. DOPATH consists
of a colon-separated (semi-colon for Windows) list of paths to directories. You can override this
environment variable with the DOPATH Tcl preference variable.

The DOPATH environment variable is not accessible when you invoke vsim from a UNIX shell
or from a Windows command prompt. It is accessible once ModelSim or vsim is invoked. If you
need to invoke from a shell or command line and use the DOPATH environment variable, use
the following syntax:

vsim -do "do <dofile_name>" <design_unit>

DP_INIFILE
The DP_INIFILE environment variable points to a file that contains preference settings for the
Source window. By default, this file is created in your $HOME directory. You should only set
this variable to a different location if your $HOME directory does not exist or is not writable.

ModelSim® SE User's Manual, v10.7 1849

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Setting Environment Variables

EDITOR
The EDITOR environment variable specifies the editor to invoke with the edit command

From the Windows platform, you could set this variable from within the Transcript window
with the following command:

set PrefMain(Editor) {c:/Program Files/Windows NT/Accessories/wordpad.exe}

where you would replace the path with that of your desired text editor. The braces ( {} ) are
required because of the spaces in the pathname

HOME
The toolset uses the HOME environment variable to look for an optional graphical preference
file (see Saving GUI Preferences in an Alternate Location in the GUI Reference Manual) and
optional location map file (see Location Mapping and MGC_LOCATION_MAP). If $HOME is
not present in the environment, then the toolset will revert to using the current working
directory (./). Refer to modelsim.ini Variables for additional information.

ITCL_LIBRARY
Identifies the pathname of the [incr]Tcl library; set by ModelSim to the same path as
MODEL_TECH_TCL; must point to libraries supplied by Mentor Graphics.

ITK_LIBRARY
Identifies the pathname of the [incr]Tk library; set by ModelSim to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Mentor Graphics.

LD_LIBRARY_PATH
A UNIX shell environment variable setting the search directories for shared libraries. It
instructs the OS where to search for the shared libraries for FLI/PLI/VPI/DPI. This variable is
used for both 32-bit and 64-bit shared libraries on Linux systems.

LD_LIBRARY_PATH_32
A UNIX shell environment variable setting the search directories for shared libraries. It
instructs the OS where to search for the shared libraries for FLI/PLI/VPI/DPI. This variable is
used only for 32-bit shared libraries on Linux systems.

LD_LIBRARY_PATH_64
A UNIX shell environment variable setting the search directories for shared libraries. It
instructs the OS where to search for the shared libraries for FLI/PLI/VPI/DPI. This variable is
used only for 64-bit shared libraries on Linux systems.

1850 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Setting Environment Variables

LM_LICENSE_FILE
The toolset’s file manager uses the LM_LICENSE_FILE environment variable to find the
location of the license file. The argument may be a colon-separated (semi-colon for Windows)
set of paths, including paths to other vendor license files. The environment variable is required.

MGC_AMS_HOME
Specifies whether vcom adds the declaration of REAL_VECTOR to the STANDARD package.
This is useful for designers using VHDL-AMS to test digital parts of their model.

MGC_HOME
Identifies the pathname of the Mentor product suite.

MGC_LOCATION_MAP
The toolset uses the MGC_LOCATION_MAP environment variable to find source files based
on easily reallocated “soft” paths.

MGC_WD
Identifies the Mentor Graphics working directory. This variable is used in the initialization
sequence.

MODEL_TECH
Do not set this variable. The toolset automatically sets the MODEL_TECH environment
variable to the directory in which the binary executable resides.

MODEL_TECH_OVERRIDE
Provides an alternative directory path for the binary executables. Upon initialization, the
product sets MODEL_TECH to this path, if set.

MODEL_TECH_TCL
Specifies the directory location of Tcl libraries for Tcl/Tk and vsim, and may also be used to
specify a startup DO file. This variable defaults to <installDIR>/tcl, however you may set it to
an alternate path.

MODELSIM
The toolset uses the MODELSIM environment variable to find the modelsim.ini file. The
argument consists of a path including the file name.

An alternative use of this variable is to set it to the path of a project file (<Project_Root_Dir>/
<Project_Name>.mpf). This allows you to use project settings with command line tools.

ModelSim® SE User's Manual, v10.7 1851

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Setting Environment Variables

However, if you do this, the .mpf file will replace modelsim.ini as the initialization file for all
tools.

MODELSIM_PREFERENCES
The MODELSIM_PREFERENCES environment variable specifies the location to store user
interface preferences. Setting this variable with the path of a file instructs the toolset to use this
file instead of the default location (your HOME directory in UNIX or in the registry in
Windows). The file does not need to exist beforehand, the toolset will initialize it. Also, if this
file is read-only, the toolset will not update or otherwise modify the file. This variable may
contain a relative pathname – in which case the file will be relative to the working directory at
the time ModelSim is started.

MODELSIM_TCL
identifies the pathname to a user preference file (for example, C:\questasim\modelsim.tcl); can
be a list of file pathnames, separated by semicolons (Windows) or colons (UNIX); note that user
preferences are now stored in the .modelsim file (Unix) or registry (Windows); QuestaSim will
still read this environment variable but it will then save all the settings to the .modelsim file
when you exit ModelSim.

MTI_COSIM_TRACE
The MTI_COSIM_TRACE environment variable creates an mti_trace_cosim file containing
debugging information about FLI/PLI/VPI function calls. You should set this variable to any
value before invoking the simulator.

MTI_LIB_DIR
Identifies the path to all Tcl libraries installed with ModelSim.

MTI_LIBERTY_PATH
Identifies the pathname of the Liberty library containing Liberty logic cell definitions. Refer to
Liberty Library Models for more information about the Liberty library modeling standard.

MTI_TF_LIMIT
The MTI_TF_LIMIT environment variable limits the size of the VSOUT temp file (generated
by the toolset’s kernel). Set the argument of this variable to the size of k-bytes

The environment variable TMPDIR controls the location of this file, while STDOUT controls
the name. The default setting is 10, and a value of 0 specifies that there is no limit. This variable
does not control the size of the transcript file.

1852 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Setting Environment Variables

MTI_RELEASE_ON_SUSPEND
The MTI_RELEASE_ON_SUSPEND environment variable allows you to turn off or modify
the delay for the functionality of releasing all licenses when operation is suspended. The default
setting is 10 (in seconds), which means that if you do not set this variable your licenses will be
released 10 seconds after your run is suspended. If you set this environment variable with an
argument of 0 (zero) ModelSim will not release the licenses after being suspended. You can
change the default length of time (number of seconds) by setting this environment variable to an
integer greater than 0 (zero).

MTI_USELIB_DIR
The MTI_USELIB_DIR environment variable specifies the directory into which object libraries
are compiled when using the -compile_uselibs argument to the vlog command

MTI_VCO_MODE
The MTI_VCO_MODE environment variable specifies which version of the toolset to use on
platforms that support both 32- and 64-bit versions when the executables are invoked from the
modeltech/bin directory by a Unix shell command (using full path specification or PATH
search). Acceptable values are either "32" or "64" (do not include quotes). If you do not set this
variable, the default is to use 32-bit mode, even on 64-bit machines.

NOMMAP
When set to 1, the NOMMAP environment variable disables memory mapping in the toolset.
You should only use this variable when running on Linux 7.1 because it will decrease the speed
with which ModelSim reads files.

PLIOBJS
The toolset uses the PLIOBJS environment variable to search for PLI object files for loading.
The argument consists of a space-separated list of file or path names

STDOUT
The argument to the STDOUT environment variable specifies a filename to which the simulator
saves the VSOUT temp file information. Typically this information is deleted when the
simulator exits. The location for this file is set with the TMPDIR variable, which allows you to
find and delete the file in the event of a crash, because an unnamed VSOUT file is not deleted
after a crash.

TCL_LIBRARY
Identifies the pathname of the Tcl library; set by ModelSim to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Mentor Graphics.

ModelSim® SE User's Manual, v10.7 1853

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Creating Environment Variables in Windows

TK_LIBRARY
Identifies the pathname of the Tk library; set by ModelSim to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Mentor Graphics.

TMP
(Windows environments) The TMP environment variable specifies the path to a generated file
(VSOUT) containing all stdout from the simulation kernel.

TMPDIR
(UNIX environments) The TMPDIR environment variable specifies the path to a generated file
(VSOUT) containing all stdout from the simulation kernel. The priority for temporary file and
directory creation is as follows:

• $TMPDIR — if defined
• /var/tmp — if available
• /tmp — if available

VSIM_LIBRARY
Identifies the pathname of the Tcl files that are used by ModelSim; set by ModelSim to the same
pathname as MODEL_TECH_TCL; must point to libraries supplied by Mentor Graphics.

Creating Environment Variables in Windows

In addition to the predefined variables shown above, you can define your own environment
variables. This example shows a user-defined library path variable that you can reference by
using the vmap command to add library mapping to the modelsim.ini file.
Procedure
1. From your desktop, right-click your My Computer icon and select Properties
2. In the System Properties dialog box, select the Advanced tab
3. Click Environment Variables
4. In the Environment Variables dialog box and User variables for <user> pane, select
New:
5. In the New User Variable dialog box, add the new variable with this data
Variable name: MY_PATH
Variable value:\temp\work

6. OK (New User Variable, Environment Variable, and System Properties dialog boxes)

1854 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Library Mapping with Environment Variables

Library Mapping with Environment Variables

Once you have set the MY_PATH variable is set, you can use it with the vmap command to add
library mappings to the current modelsim.ini file.

Table F-2. Add Library Mappings to modelsim.ini File

Prompt Type Command Result added to modelsim.ini
DOS prompt vmap MY_VITAL %MY_PATH% MY_VITAL = c:\temp\work
ModelSim or vmap MY_VITAL \$MY_PATH1 MY_VITAL = $MY_PATH
vsim prompt or vmap MY_VITAL {$MY_PATH}
1. The dollar sign ($) character is Tcl syntax that indicates a variable. The backslash (\) character is an
escape character that prevents the variable from being evaluated during the execution of vmap.

You can easily add additional hierarchy to the path with an environment variable. For example:

vmap MORE_VITAL %MY_PATH%\more_path\and_more_path

vmap MORE_VITAL \$MY_PATH\more_path\and_more_path

Use braces ({}) for cases where the path contains multiple items that need to be escaped, such as
spaces in the pathname or backslash characters. For example:

vmap celllib {$LIB_INSTALL_PATH/Documents And Settings/All/celllib}

Related Topics
Setting Environment Variables

Referencing Environment Variables

There are two ways you can reference environment variables within ModelSim.
Environment variables are allowed in a FILE variable being opened in VHDL. For example,

use std.textio.all;
entity test is end;
architecture only of test is
begin
process
FILE in_file : text is in "$ENV_VAR_NAME";
begin
wait;
end process;
end;

ModelSim® SE User's Manual, v10.7 1855

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Removal of Temporary Files (VSOUT)

Environment variables may also be referenced from the ModelSim command line or in DO files
using the Tcl env array mechanism. For example:

echo "$env(ENV_VAR_NAME)"

Note
Environment variable expansion does not occur in files that are referenced via the -f
argument to vcom, vlog, or vsim.

Removal of Temporary Files (VSOUT)

The temporary (temp) file named VSOUT is the communication mechanism between the
simulator kernel and the Graphical User Interface.
In normal circumstances, this temp file is deleted when the simulator exits. If ModelSim
crashes, however, you need to delete the temp file manually. If you specify the location of the
temp file with TMPDIR, you can locate the file more easily for deletion.

1856 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix G
Third-Party Model Support

This appendix provides information about using ModelSim with the Synopsys SmartModels
and Synopsys hardware modeling.
Synopsys SmartModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1867
Synopsys Hardware Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1868
VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869
hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870

ModelSim® SE User's Manual, v10.7 1857

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
Synopsys SmartModels

Synopsys SmartModels
You can use the Synopsys SWIFT-based SmartModel library with ModelSim. The SmartModel
library is a collection of behavioral models supplied in binary form with a procedural interface
that is accessed by the simulator.
This section only describes the specifics of using SmartModels with ModelSim.

Note
A 32-bit SmartModel will not run with a 64-bit version of the simulator. When trying to
load the operating system specific 32-bit library into the 64-bit executable, the pointer sizes
will be incorrect.

VHDL SmartModel Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859

Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1867

1858 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
VHDL SmartModel Interface

VHDL SmartModel Interface

ModelSim VHDL interfaces to a SmartModel through a foreign architecture. The foreign
architecture contains a foreign attribute string that associates a specific SmartModel with the
architecture. On elaboration of the foreign architecture, the simulator automatically loads the
SmartModel library software and establishes communication with the specific SmartModel.
Enabling the VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Creating Foreign Architectures with sm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1860
sm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1861
SmartModel Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863
Command Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
SmartModel Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865
Memory Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1867

Enabling the VHDL SmartModel Interface

The VHDL SmartModel interface is basically a foreign architecture which contains a foreign
attribute string which associates the SmartModel with the architecture. To enable the
SmartModel interface you must follow the steps outlined in this section.
Procedure
1. Set the LMC_HOME environment variable to the root of the SmartModel library
installation directory. Consult SmartModel documentation for details.
2. Uncomment the appropriate libswift entry in the modelsim.ini file for your operating
system.
• libswift — This variable points to the dynamic link library software that accesses the
SmartModels.
3. If you are running the Windows operating system, you must also comment out the
default libsm entry (precede the line with a semicolon (;)) and uncomment the libsm
entry for the Windows operating system.
• libsm — This variable points to the dynamic link library that interfaces the foreign
architecture to the SmartModel software.
By default, the libsm entry points to the libsm.sl supplied in the ModelSim
installation directory indicated by the MODEL_TECH environment variable.
ModelSim automatically sets the MODEL_TECH environment variable to the
appropriate directory containing the executables and binaries for the current
operating system.
4. The libswift and libsm entries are found under the [lmc] section of the modelsim.ini file
located in the ModelSim installation directory.

ModelSim® SE User's Manual, v10.7 1859

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
VHDL SmartModel Interface

Creating Foreign Architectures with sm_entity

The sm_entity tool automatically creates entities and foreign architectures for SmartModels.
The flow for utilizing sm_entity in the creation of the interface is outlined here.
Procedure
1. The entity and foreign architecture are created when you run the sm_entity tool.
By default, the sm_entity tool writes an entity and foreign architecture to stdout, but you
can redirect it to a file with the following syntax
sm_entity -all > sml.vhd

2. Compile the entity and foreign architecture into a library named lmc.
For example, the following commands compile the entity and foreign architecture:
vlib lmc
vcom -work lmc sml.vhd

3. Generate a component declaration.

You will need to generate a component declaration for the SmartModels so that you can
instantiate the them in your VHDL design. Add these component declarations to a
package named sml (for example), and compile the package into the lmc library:
sm_entity -all -c -xe -xa > smlcomp.vhd

4. Create a package of SmartModel component declarations.

Edit the resulting smlcomp.vhd file to turn it into a package as follows:
library ieee;
use ieee.std_logic_1164.all;
package sml is
<component declarations go here>
end sml;

5. Compile the package into the lmc library:

vcom -work lmc smlcomp.vhd

6. Reference the SmartModels in your design.

Add the following library and use clauses to your code:
library lmc;
use lmc.sml.all;

1860 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
VHDL SmartModel Interface

sm_entity Syntax
Context: Synopsys SmartModel Interfaces
The syntax for sm_entity is as follows.
Syntax
sm_entity [-] [-xe] [-xa] [-c] [-all] [-v] [-93] [-modelsimini <ini_filepath>] [<SmartModelName>...]

Arguments
• -
Read SmartModel names from standard input.
• -xe
Do not generate entity declarations.
• -xa
Do not generate architecture bodies.
• -c
Generate component declarations.
• -all
Select all models installed in the SmartModel library.
• -v
Display progress messages.
• -93
Use extended identifiers where needed.
• -modelsimini <ini_filepath>
Load an alternate initialization file that replaces the current initialization file. Overrides the
file path specified in the MODELSIM environment variable. Specify either an absolute or
relative path the initialization file. On Windows systems the path separator should be a
forward slash (/).
• <SmartModelName>
Name of a SmartModel.
Examples
The following is an example of an entity and foreign architecture created by sm_entity for the
cy7c285 SmartModel.

ModelSim® SE User's Manual, v10.7 1861

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
VHDL SmartModel Interface

library ieee;
use ieee.std_logic_1164.all;

entity cy7c285 is
generic (TimingVersion : STRING := "CY7C285-65";
DelayRange : STRING := "Max";
MemoryFile : STRING := "memory" );
port ( A0 : in std_logic;
A1 : in std_logic;
A2 : in std_logic;
A3 : in std_logic;
A4 : in std_logic;
A5 : in std_logic;
A6 : in std_logic;
A7 : in std_logic;
A8 : in std_logic;
A9 : in std_logic;
A10 : in std_logic;
A11 : in std_logic;
A12 : in std_logic;
A13 : in std_logic;
A14 : in std_logic;
A15 : in std_logic;
CS : in std_logic;
O0 : out std_logic;
O1 : out std_logic;
O2 : out std_logic;
O3 : out std_logic;
O4 : out std_logic;
O5 : out std_logic;
O6 : out std_logic;
O7 : out std_logic;
WAIT_PORT : inout std_logic );
end;
architecture SmartModel of cy7c285 is
attribute FOREIGN : STRING;
attribute FOREIGN of SmartModel : architecture is
"sm_init $MODEL_TECH/libsm.sl ; cy7c285";
begin
end SmartModel;

Based on the above example, the following are details about the entity:

• The entity name is the SmartModel name.

• The port names are the same as the SmartModel port names (these names must not be
changed). If the SmartModel port name is not a valid VHDL identifier, then sm_entity
automatically converts it to a valid name. If sm_entity is invoked with the -93 option,
then the identifier is converted to an extended identifier, and the resulting entity must
also be compiled with the -93 option. If the -93 option had been specified in the example
above, then WAIT would have been converted to \WAIT\. Note that in this example the
port WAIT was converted to WAIT_PORT because wait is a VHDL reserved word.

1862 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
VHDL SmartModel Interface

• The port types are std_logic. This data type supports the full range of SmartModel logic
states.
• The DelayRange, TimingVersion, and MemoryFile generics represent the SmartModel
attributes of the same name. Sm_entity creates a generic for each attribute of the
particular SmartModel. The default generic value is the default attribute value that the
SmartModel has supplied to sm_entity.
Based on the above example, the following are details about the architecture:

• The first part of the foreign attribute string (sm_init) is the same for all SmartModels.
• The second part ($MODEL_TECH/libsm.sl) is taken from the libsm entry in the
initialization file, modelsim.ini.
• The third part (cy7c285) is the SmartModel name. This name correlates the architecture
with the SmartModel at elaboration.

SmartModel Vector Ports

The entities generated by sm_entity only contain single-bit ports, never vectored ports. This is
necessary because ModelSim correlates entity ports with the SmartModel SWIFT interface by
name. However, for ease of use in component instantiations, you can create a custom
component declaration and component specification that groups ports into vectors. You can also
rename and reorder the ports in the component declaration. You can also reorder the ports in the
entity declaration, but you cannot rename them.

ModelSim® SE User's Manual, v10.7 1863

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
VHDL SmartModel Interface

The following is an example component declaration and specification that groups the address
and data ports of the CY7C285 SmartModel:

component cy7c285
generic ( TimingVersion : STRING := "CY7C285-65";
DelayRange : STRING := "Max";
MemoryFile : STRING := "memory" );
port ( A : in std_logic_vector (15 downto 0);
CS : in std_logic;
O : out std_logic_vector (7 downto 0);
WAIT_PORT : inout std_logic );
end component;

for all: cy7c285

use entity work.cy7c285
port map (A0 => A(0),
A1 => A(1),
A2 => A(2),
A3 => A(3),
A4 => A(4),
A5 => A(5),
A6 => A(6),
A7 => A(7),
A8 => A(8),
A9 => A(9),
A10 => A(10),
A11 => A(11),
A12 => A(12),
A13 => A(13),
A14 => A(14),
A15 => A(15),
CS => CS,
O0 => O(0),
O1 => O(1),
O2 => O(2),
O3 => O(3),
O4 => O(4),
O5 => O(5),
O6 => O(6),
O7 => O(7),
WAIT_PORT => WAIT_PORT );

Command Channel
The command channel lets you invoke SmartModel specific commands. ModelSim provides
access to the Command Channel from the command line.
The form of a SmartModel command is:

lmc {<instance_name> | -all} "<SmartModel command>"

1864 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
VHDL SmartModel Interface

• instance_name — is either a full hierarchical name or a relative name of a SmartModel

instance. A relative name is relative to the current environment setting (see environment
command). For example, to turn timing checks off for SmartModel /top/u1:
lmc /top/u1 "SetConstraints Off"

• -all — applies the command to all SmartModel instances. For example, to turn timing
checks off for all SmartModel instances:
lmc -all "SetConstraints Off"

There are also some SmartModel commands that apply globally to the current simulation
session rather than to models. The form of a SmartModel session command is:

lmcsession "<SmartModel session command>"

SmartModel Windows
Some models in the SmartModel library provide access to internal registers with a feature called
SmartModel Windows. The simulator interface to this feature is described below.
Window names that are not valid VHDL or Verilog identifiers are converted to VHDL extended
identifiers. For example, with a window named z1I10.GSR.OR, the tool treats the name as \
z1I10.GSR.OR\ (for all commands including lmcwin, add wave, and examine). You must then
use that name in all commands. For example:

add wave /top/swift_model/\z1I10.GSR.OR\

Extended identifiers are case-sensitive.

ReportStatus
The ReportStatus command displays model information, including the names of window
registers.

For example:

lmc /top/u1 ReportStatus

SmartModel Windows description:

WA "Read-Only (Read Only)"

WB "1-bit"
WC "64-bit"

This model contains window registers named wa, wb, and wc. These names can be used in
subsequent window (lmcwin) commands.

ModelSim® SE User's Manual, v10.7 1865

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
VHDL SmartModel Interface

SmartModel lmcwin Commands

Each of the following commands requires a window instance argument that identifies a specific
model instance and window name. For example, /top/u1/wa refers to window wa in model
instance /top/u1.

• lmcwin read — displays the current value of a window.

lmcwin read <window_instance> [-<radix>]

The optional radix argument is -binary, -decimal, or -hexadecimal (these names can be
abbreviated). The default is to display the value using the std_logic characters. For
example, the following command displays the 64-bit window wc in hexadecimal:
lmcwin read /top/u1/wc -h

• lmcwin write — writes a value into a window.

lmcwin write <window_instance> <value>

The format of the value argument is the same as used in other simulator commands that
take value arguments. For example, to write 1 to window wb, and all 1’s to window wc:
lmcwin write /top/u1/wb 1
lmcwin write /top/u1/wc X"FFFFFFFFFFFFFFFF"

• lmcwin enable — enables continuous monitoring of a window.

lmcwin enable <window_instance>

The specified window is added to the model instance as a signal (with the same name as
the window) of type std_logic or std_logic_vector. This signal's values can then be
referenced in simulator commands that read signal values, such as the add list command
shown below. The window signal is continuously updated to reflect the value in the
model. For example, to list window wa:
lmcwin enable /top/u1/wa
add list /top/u1/wa

• lmcwin disable — disables continuous monitoring of a window.

lmcwin disable <window_instance>

The window signal is not deleted, but it no longer is updated when the model’s window
register changes value. For example, to disable continuous monitoring of window wa:
lmcwin disable /top/u1/wa

• lmcwin release — disables the effect of a previous lmcwin write command on a window
net.
lmcwin release <window_instance>

Some windows are actually nets, and the lmcwin write command behaves more like a
continuous force on the net.

1866 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
Verilog SmartModel Interface

Memory Arrays
A memory model usually makes the entire register array available as a window. In this case, the
window commands operate only on a single element at a time. The element is selected as an
array reference in the window instance specification. For example, to read element 5 from the
window memory mem:
lmcwin read /top/u2/mem(5)

Omitting the element specification defaults to element 0. Also, continuous monitoring is limited
to a single array element. The associated window signal is updated with the most recently
enabled element for continuous monitoring.

Verilog SmartModel Interface

The SmartModel library provides an optional library of Verilog modules and a PLI application
that communicates between a simulator's PLI and the SWIFT simulator interface.

ModelSim® SE User's Manual, v10.7 1867

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
Synopsys Hardware Models

Synopsys Hardware Models

A hardware model allows simulation of a device using the actual silicon installed as a hardware
model. The hardware modeling system is a network resource with a procedural interface that is
accessed by the simulator.
This section only describes the specifics of using hardware models with ModelSim.

VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869

hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870

1868 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
VHDL Hardware Model Interface

VHDL Hardware Model Interface

The simulator interfaces to a hardware model through a foreign architecture. The foreign
architecture contains a foreign attribute string that associates a specific hardware model with the
architecture. On elaboration of the foreign architecture, the simulator automatically loads the
hardware modeler software and establishes communication with the specific hardware model.
Hardware Model Interface Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869

Hardware Model Interface Specifics

The simulator locates the hardware modeler interface software based on entries in the
modelsim.ini initialization file. The simulator and the hm_entity tool (for creating foreign
architectures) both depend on these entries being set correctly.
These entries are found under the [lmc] section of the default modelsim.ini file located in the
ModelSim installation directory.

The simulator automatically loads both the libhm and libsfi libraries when it elaborates a
hardware model foreign architecture.

• libhm — This variable points to the dynamic link library that interfaces the foreign
architecture to the hardware modeler software.
By default, libhm points to the libhm.sl supplied in the installation directory indicated by
the MODEL_TECH environment variable. The tool automatically sets the
MODEL_TECH environment variable to the appropriate directory containing the
executables and binaries for the current operating system. If you are running the
Windows operating system, then you must comment out the default libhm entry
(precede the line with the “;” character) and uncomment the libhm entry for the
Windows operating system.
• libsfi — This variable points to the dynamic link library software that accesses the
hardware modeler.
Uncomment the appropriate libsfi setting for your operating system, and replace
<sfi_dir> with the path to the hardware modeler software installation directory.
In addition, you must set the LM_LIB and LM_DIR environment variables as described in
Synopsys hardware modeling documentation.

ModelSim® SE User's Manual, v10.7 1869

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
hm_entity Tool

hm_entity Tool
The hm_entity tool creates entities and foreign architectures for hardware models.
Creating Foreign Architectures with hm_entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870
hm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1871
Hardware Model Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873
Hardware Model Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1874

Creating Foreign Architectures with hm_entity

The hm_entity tool automatically creates entities and foreign architectures for hardware models.
Procedure
1. Create the entity and foreign architecture using the hm_entity tool.
By default, hm_entity writes the entity and foreign architecture to stdout, but you can
redirect it to a file with the following syntax:
hm_entity LMTEST.MDL > lmtest.vhd

2. Compile the entity and foreign architecture into a library named lmc.
For example, the following commands compile the entity and foreign architecture:
vlib lmc
vcom -work lmc lmtest.vhd

3. Generate a component declaration.

You will need to generate a component declaration so that you can instantiate the
hardware model in your VHDL design. If you have multiple hardware models, you may
want to add all of their component declarations to a package so that you can easily
reference them in your design. The following command writes the component
declaration to stdout for the LMTEST hardware model.
% hm_entity -c -xe -xa LMTEST.MDL

4. Place the component declaration into your design.

Paste the resulting component declaration into the appropriate place in your design or
into a package.

1870 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
hm_entity Tool

hm_entity Syntax
The hm_entity tool automatically creates entities and foreign architectures for hardware models.
Syntax
hm_entity [-xe] [-xa] [-c] [-93] [-modelsimini <ini_filepath>] <shell
software filename>

Arguments
• -xe
Do not generate entity declarations.
• -xa
Do not generate architecture bodies.
• -c
Generate component declarations.
• -93
Use extended identifiers where needed.
• -modelsimini <ini_filepath>
Load an alternate initialization file that replaces the current initialization file. Overrides the
file path specified in the MODELSIM environment variable. Specify either an absolute or
relative path the initialization file. On Windows systems the path separator should be a
forward slash (/).
• <shell software filename>
Hardware model shell software filename.

ModelSim® SE User's Manual, v10.7 1871

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
hm_entity Tool

Examples
The following is an example of the entity and foreign architecture created by hm_entity for the
CY7C285 hardware model:

library ieee;
use ieee.std_logic_1164.all;

entity cy7c285 is
generic ( DelayRange : STRING := "Max" );
port ( A0 : in std_logic;
A1 : in std_logic;
A2 : in std_logic;
A3 : in std_logic;
A4 : in std_logic;
A5 : in std_logic;
A6 : in std_logic;
A7 : in std_logic;
A8 : in std_logic;
A9 : in std_logic;
A10 : in std_logic;
A11 : in std_logic;
A12 : in std_logic;
A13 : in std_logic;
A14 : in std_logic;
A15 : in std_logic;
CS : in std_logic;
O0 : out std_logic;
O1 : out std_logic;
O2 : out std_logic;
O3 : out std_logic;
O4 : out std_logic;
O5 : out std_logic;
O6 : out std_logic;
O7 : out std_logic;
W : inout std_logic );
end;
architecture Hardware of cy7c285 is
attribute FOREIGN : STRING;
attribute FOREIGN of Hardware : architecture is
"hm_init $MODEL_TECH/libhm.sl ; CY7C285.MDL";
begin
end Hardware;

Based on the above example, the following are details about the entity:

• The entity name is the hardware model name (you can manually change this name if you
like).
• The port names are the same as the hardware model port names (these names must not
be changed). If the hardware model port name is not a valid VHDL identifier, then
hm_entity issues an error message. If hm_entity is invoked with the -93 option, then the
identifier is converted to an extended identifier, and the resulting entity must also be
compiled with the -93 option. Another option is to create a pin-name mapping file.

1872 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
hm_entity Tool

• The port types are std_logic. This data type supports the full range of hardware model
logic states.
• The DelayRange generic selects minimum, typical, or maximum delay values. Valid
values are “min”, “typ”, or “max” (the strings are not case-sensitive). The default is
“max”.
Based on the above example, the following are details about the architecture:

• The first part of the foreign attribute string (hm_init) is the same for all hardware
models.
• The second part ($MODEL_TECH/libhm.sl) is taken from the libhm entry in the
initialization file, modelsim.ini.
• The third part (CY7C285.MDL) is the shell software filename. This name correlates the
architecture with the hardware model at elaboration.

Hardware Model Vector Ports

The entities generated by hm_entity only contain single-bit ports, never vectored ports.
However, for ease of use in component instantiations, you may want to create a custom
component declaration and component specification that groups ports into vectors. You can also
rename and reorder the ports in the component declaration. You can also reorder the ports in the
entity declaration, but you can not rename them!

ModelSim® SE User's Manual, v10.7 1873

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
hm_entity Tool

The following is an example component declaration and specification that groups the address
and data ports of the CY7C285 hardware model:

component cy7c285
generic ( DelayRange : STRING := "Max");
port ( A : in std_logic_vector (15 downto 0);
CS : in std_logic;
O : out std_logic_vector (7 downto 0);
WAIT_PORT : inout std_logic );
end component;
for all: cy7c285
use entity work.cy7c285
port map (A0 => A(0),
A1 => A(1),
A2 => A(2),
A3 => A(3),
A4 => A(4),
A5 => A(5),
A6 => A(6),
A7 => A(7),
A8 => A(8),
A9 => A(9),
A10 => A(10),
A11 => A(11),
A12 => A(12),
A13 => A(13),
A14 => A(14),
A15 => A(15),
CS => CS,
O0 => O(0),
O1 => O(1),
O2 => O(2),
O3 => O(3),
O4 => O(4),
O5 => O(5),
O6 => O(6),
O7 => O(7),
WAIT_PORT => W );

Hardware Model Commands

The following simulator commands are available for hardware models.
• Enable/disable test vector logging for the specified hardware model.
lm_vectors on|off <instance_name> [<filename>]

• Enable/disable timing measurement for the specified hardware model.

lm_measure_timing on|off <instance_name> [<filename>]

• Enable/disable timing checks for the specified hardware model.

lm_timing_checks on|off <instance_name>

1874 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Model Support
hm_entity Tool

• Enable/disable pattern looping for the specified hardware model.

lm_loop_patterns on|off <instance_name>

• Enable/disable unknown propagation for the specified hardware model.

lm_unknowns on|off <instance_name>

ModelSim® SE User's Manual, v10.7 1875

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Third-Party Model Support
hm_entity Tool

1876 ModelSim® SE User's Manual, v10.7

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Index

EnableSVCoverpointExprVariable, 1486
Index

— Symbols — EnableTypeOf, 1487

.bsm file, 793, 826 EnumBaseInit, 1488
.ini control variables error, 1489
AcceptLowerCasePragmasOnly, 1410 ErrorFile, 1490
AssertFile, 1416 Explicit, 1491
Coverage, 1445 ExtendedToggleMode, 1492
CoverageShortCircuit, 1462 Fatal, 1493
CoverAtLeast, 1446 FecCountLimit, 1494
CoverCells, 1447 FlateLibPageDeletePercentage, 1498
CoverClkOptBuiltins, 1448 FlateLibPageDeleteThreshold, 1499
CoverDeglitchOn, 1450 FlatLibPageSize, 1497
CoverDeglitchPeriod, 1451 floatfixlib, 1500
CoverEnable, 1452 ForceSigNextIter, 1501
CoverExcludeDefault, 1453 ForceUnsignedIntegerToVhdlInteger,
CoverFEC, 1454 1502
CoverLimit, 1455 FsmImplicitTrans, 1503
CoverLog, 1456 FsmResetTrans, 1504
CoverOpt, 1458 FsmSingle, 1505, 1701
CoverREC, 1459 FsmXAssign, 1506
CoverSub, 1463 GCThreshold, 1507
CoverThreadLimit, 1464 GCThresholdClassDebug, 1508
CoverThreadLimitAction, 1465 GenerateFormat, 1509
CoverWeight, 1466 GenerateLoopIterationMax, 1510
CppOptions, 1468 GenerateRecursionDepthMax, 1511
CppPath, 1467, 1469 GenerousIdentifierParsing, 1512
CreateDirForFileAccess, 1470 GlobalSharedObjectList, 1513, 1514
CvgZWNoCollect, 1472 Hazard, 1515
DatasetSeparator, 1473 ieee, 1516
DefaultForceKind, 1474 IgnoreError, 1517
DefaultLibType, 1475 IgnoreFailure, 1518
DefaultRadix, 1476 IgnoreNote, 1519
DefaultRadixFlags, 1477 IgnorePragmaPrefix, 1520
DefaultRestartOptions, 1478 ignoreStandardRealVector, 1521
DelayFileOpen, 1479 IgnoreSVAError, 1522
displaymsgmode, 1480 IgnoreSVAFatal, 1523
DpiCppPath, 1481 IgnoreSVAInfo, 1524
DpiOutOfTheBlue, 1482 IgnoreSVAWarning, 1525
DumpportsCollapse, 1483 IgnoreVitalErrors, 1526
EmbeddedPsl, 1484 IgnoreWarning, 1527

ModelSim® SE User's Manual, v10.7 1877

 ImmediateContinuousAssign, 1528 OnFinish, 1573
IncludeRecursionDepthMax, 1529 OnFinishPendingAssert, 1574
InitOutCompositeParam, 1530 Optimize_1164, 1575
IterationLimit, 1531 osvvm, 1576
LargeObjectSilent, 1532 ParallelJobs, 1577
LargeObjectSize, 1533 PedanticErrors, 1579
LibrarySearchPath, 1534 PliCompatDefault, 1580
License, 1535 PreserveCase, 1581
MaxReportRhsCrossProducts, 1536 PrintSimStats, 1582
MaxReportRhsSVCrossProducts, 1537 PrintSVPackageLoadingAttribute, 1583
MaxSVCoverpointBinsDesign, 1538 Protect, 1584
MaxSVCoverpointBinsInst, 1539 PslInfinityThreshold, 1586
MaxSVCrossBinsDesign, 1540 PslOneAttempt, 1585
MaxSVCrossBinsInst, 1541 Quiet, 1587
MessageFormat, 1542 RequireConfigForAllDefaultBinding,
MessageFormatBreak, 1543 1588
MessageFormatBreakLine, 1544 Resolution, 1589
MessageFormatError, 1545 RunLength, 1590
MessageFormatFail, 1546 ScalarOpts, 1592
MessageFormatFatal, 1547 SccomLogfile, 1593
MessageFormatNote, 1548 SccomVerbose, 1594
MessageFormatWarning, 1549 ScEnableScSignalWriteCheck, 1595
MixedAnsiPorts, 1550 ScMainStackSize, 1597
modelsim_lib, 1551 ScShowIeeeDeprecationWarnings, 1599
MsgLimitCount, 1552 ScStackSize, 1598
msgmode, 1553 ScTimeUnit, 1600
mtiAvm, 1554 ScvPhaseRelationName, 1601
mtiOvm, 1555 SeparateConfigLibrary, 1602
mtiPA, 1556 Show_BadOptionWarning, 1603
mtiUPF, 1557 Show_Lint, 1604
mtiUvm, 1558 Show_PslChecksWarnings, 1605
MultiFileCompilationUnit, 1559 Show_source, 1606
MvcHome, 1560 Show_VitalChecksWarning, 1607
NoCaseStaticError, 1561 Show_Warning1, 1608
NoDebug, 1562 Show_Warning2, 1609
NoDef erSubpgmCheck, 1563 Show_Warning3, 1610
NoIndexCheck, 1564 Show_Warning4, 1611
NoOthersStaticError, 1565 Show_Warning5, 1612
NoRangeCheck, 1566 ShowConstantImmediateAsserts, 1613
note, 1567 ShowFunctions, 1614
NoVital, 1568 ShowUnassociatedScNameWarning, 1615
NoVitalCheck, 1569 ShowUndebuggableScTypeWarning, 1616
NumericStdNoWarnings, 1570 ShutdownFile, 1617
OldVHDLConfigurationVisibility, 1571 SignalForceFunctionUseDefaultRadix,
OldVhdlForGenNames, 1572 1618

1878 ModelSim® SE User's Manual, v10.7

 SignalSpyPathSeparator, 1619 SVCoverpointExprVariablePrefix, 1664
SimulateAssumeDirectives, 1620 SVCoverpointWildCardBinValueSizeWar
SimulateImmedAsserts, 1621 n, 1665
SimulatePSL, 1622 SVCrossNumPrintMissing, 1666
SimulateSVA, 1623 SVCrossNumPrintMissingDefault, 1667
SmartDbgSym, 1624 SVFileExtensions, 1671
SolveACTMaxOps, 1625 Svlog, 1672
SolveACTMaxTests, 1626 SVPrettyPrintFlags, 1673
SolveACTRetryCount, 1627 SyncCompilerFiles, 1676
SolveArrayResizeMax, 1628 synopsys, 1675
SolveEngine, 1630 ToggleCountLimit, 1677
SolveFailDebug, 1631 ToggleDeglitchPeriod, 1678
SolveFailDebugMaxSet, 1632 ToggleFixedSizeArray, 1679
SolveFailSeverity, 1633 ToggleMaxFixedSizeArray, 1680
SolveGraphMaxEval, 1634 ToggleMaxIntValues, 1681
SolveGraphMaxSize, 1635 ToggleMaxRealValues, 1682
SolveIgnoreOverflow, 1636 ToggleNoIntegers, 1683
SolveRev, 1637 TogglePackedAsVec, 1684
SolveTimeout, 1638 TogglePortsOnly, 1685
SparseMemThreshhold, 1639 ToggleVHDLRecords, 1686
StackTraceDepth, 1640 ToggleVlogEnumBits, 1687
Startup, 1641 ToggleVlogIntegers, 1688
std, 1644 ToggleVlogReal, 1689
std_developerskit, 1645 ToggleWidthLimit, 1690
StdArithNoWarnings, 1646 TranscriptFile, 1691
support, 1709 UCDBFilename, 1692
suppress, 1647 UCDBTestStatusMessageFilter, 1693
SuppressFileTypeReg, 1648 UnattemptedImmediateAssertions, 1694
Sv_Seed, 1649 UnbufferedOutput, 1695
sv_std, 1650 UndefSyms, 1696
SVAPrintOnlyUserMessage, 1651 UpCase, 1697
SVCovergroupGetInstCoverageDefault, UserTimeUnit, 1698
1652 UseScv, 1699
SVCovergroupGoal, 1653 UseSVCrossNumPrintMissing, 1700
SVCovergroupGoalDefault, 1654 UVMControl, 1702
SVCovergroupMergeInstancesDefault, verilog, 1703
1655 Veriuser, 1704
SVCovergroupPerInstanceDefault, 1656 VHDL93, 1705
SVCovergroupSampleInfo, 1657 VhdlSeparatePduPackage, 1706
SVCovergroupStrobe, 1658 VhdlVariableLogging, 1707
SVCovergroupStrobeDefault, 1659 vital2000, 1708
SVCovergroupTypeGoal, 1660 WarnConstantChange, 1710
SVCovergroupTypeGoalDefault, 1661 warning, 1711
SVCovergroupZWNoCollect, 1662 WaveSignalNameWidth, 1712
SVCoverpointAutoBinMax, 1663 WildcardFilter, 1713

ModelSim® SE User's Manual, v10.7 1879

 WildcardSizeThreshold, 1714 $sdf_annotate system task, 1317
WildcardSizeThresholdVerbose, 1715 $sdf_done, 317
WLFCacheSize, 1716 $signal_force, 1276
WLFCollapseMode, 1717 $signal_release, 1278
WLFCompress, 1718 $typename, 304
WLFDeleteOnQuit, 1719 $unit scope, visibility in SV declarations, 254
WLFFileLock, 1720
WLFFilename, 1721 — Numerics —
WLFOptimize, 1722 1076, IEEE Std, 77
WLFSaveAllRegions, 1723 differences between versions, 199
WLFSimCacheSize, 1724 1364, IEEE Std, 78, 242, 337, 1133
WLFSizeLimit, 1725 1364-2005
WLFTimeLimit, 1726 IEEE std, 81, 1322
WLFUpdateInterval, 1727 2-state toggle coverage, 928
WLFUseThreads, 1728 3-state toggle coverage, 928
.ini VHDL compiler control variables 64-bit platforms
ShowConstantImmediateAsserts, 1613 choosing over 32-bit, 1853
.modelsim file 64-bit time
in initialization sequence, 1847 now variable, 1365
purpose, 1845 Tcl time commands, 1369
.mpf file, 152 64-bit vsim, using with 32-bit FLI apps, 1840
loading from the command line, 171 —A—
order of access during startup, 1845 ACC routines, 1834
.so, shared object file accelerated packages, 188
loading PLI/VPI/DPI C applications, 1818 AcceptLowerCasePragmasOnly .ini file
loading PLI/VPI/DPI C++ applications, variable, 1410
1822 access
‘endprotect compiler directive, 111, 328 limitations in mixed designs, 459
‘protect compiler directive, 111, 328 AccessObjDebug, 1411
#, comment character, 1357 ACT, 1130, 1136
+acc option, design object visibility, 147 Actions
+protect assertions, 1020
compile for encryption actions
Compile atv window, 1083
with +protect, 91 Active driver
$clog2, 307 path details, 787, 872
$coverage_save, 307 active thread monitor, 1073
$coverage_save system function, 310 Active time indicator
$disable_signal_spy, 1263 schematic
$enable_signal_spy, 1265 Schematic
$finish active time indicator, 783, 814
behavior, customizing, 1573 Adaptive Exclusion, 959, 960
$init_signal_driver, 1266 Add cursor
$init_signal_spy, 1271 to Wave window, 674
$load_coverage_db(), using, 1126 add PSL files, 170

1880 ModelSim® SE User's Manual, v10.7

aggregates, SystemC, 425 assertion thread viewing
Algorithm actions, 1083
negative timing constraint, 284 annotating local variables, 1088
alias name, definition, 936 enable, 1068
alias toggle nodes expression hierarchy, 1086
-coveranalysis option, 937 expression pane, 1079
aliases and mixed-language boundary of multiple clocks, 1084
instances, 936 navigating atv window, 1078
Analysis open
root thread from Assertions pane, 1075
assertions, 1085, 1086 from menu bar, 1075
Analyze from Message Viewer, 1076
class types, 369 from Wave window, 1076
annotate thread state, 1087
local variables, 1088 thread viewer pane, 1079
Annotating time in thread viewer pane, 1080
schematic window, 790 Assertions
annotating differences, wave compare, 757 break severity, 1398
API, 242 filtering, 1114
api_version in error message, 452 memory usage, 1254
Application programming interface (API), 242 save, 1120
argc simulator state variable, 1364 assertions
arguments active thread monitor, 1073
passing to a DO file, 1374 analyzing failures, 1072
arguments, accessing commandl-line, 445 analyzing in the GUI, 1031
argv simulator state variable, 1364 binding, 460, 1013
Arithmetic Constraint Technology (ACT), break severity, 1018
1130, 1136 clockdeclarations, 1056
arithmetic package warnings, disabling, 1734 coding guidelines, 1009
array compare, 1041
random dynamic compiling and simulating, 1061
size constraints, 1134, 1628 concurrent, 1008
array of sc_signal, 425 configuring, 1014
assert debug, 1072 cumulative threads, 1034
replicator parameters, 1074 deferred, 1063
-assertdebug, 1067 during elab/optimize, 1061
AssertFile .ini file variable, 1416 embedded assertions, 1048
assertion enable, 1015
counts, 1025 enable pass/fail logging, 1018
Assertion debugging external file, contained in, 1052
using -assertdebug, 1067 file and line number, 1542
assertion directives filter thread start times, 1075
names, 1012 immediate, 1008
assertion fail messages, 1068 deferred, 1063
assertion profile command, 1033 inline, 1048

ModelSim® SE User's Manual, v10.7 1881

 library and use clauses, 1054 thread state, 1087
limitations, 1062 view multiple clocks, 1084
memory profiling ATV log command, 1068
enabling, 1016 atv window
message display, 1398 actions, 1083
message logging, 1017 annotating local variables, 1088
messages expression hierarchy, 1086
alternate output file, 1045 expression pane, 1079
turning off, 1735 multiple clocks, 1084
multiclocked properties, 1057 navigating, 1078
performance profiling thread state, 1087
enabling, 1016 thread viewer pane, 1079
recompile after changes, 1062 thread viewer pane pane, 1079
reporting, 1044 time in thread viewer pane pane, 1080
save, 1070 auto exclusion
set actions, 1020 fsm transitions, 943
set fail limits, 1019 auto find bp command, 1215
setting format of messages, 1542 auto step mode, C Debug, 1216
simulating, 1025 Autofill text entry
SystemVerilog, 1008 find, 1240
thread state, 1087 automatic saving of UCDB, 1154
unclocked properties, 1056 automatically save coverage, 901
view in Analysis window, 1031 automating testbench, 1129
viewing in Wave window, 1034
warnings, locating, 1542 —B—
Assertions browser bad magic number error message, 651
display options, 1038 base (radix)
Assume directives Wave window, 705
processing, 1013 batch-mode simulations, 73
assume directives BDD, 1130
SimulateAssumeDirectives .ini variable, Binary Decision Diagram (BDD), 1130
1620 bind
Asymmetric encryption, 114, 115 allowed bindings, 461
AtLeast counts, PSL hierarchical references, 463
configuring cover directives restrictions, 461
AtLeast counts, 1023 to VHDL enumerated types, 464
attribute what can be bound, 460
definition of, 568 bind construct
ATV limitations for SystemC, 391, 470
highlighting SystemC binding
root thread analysis, 1085, 1086 to Verilog/SV design unit, 391
sub-expression failures, 1083 SystemVerilog, 460, 1013
atv actions bind statement
expand/contract hierarchy, 1086 in compilation unit scope, 468
hover mouse syntax, 461
binding, VHDL

1882 ModelSim® SE User's Manual, v10.7

 default, 204 C++ applications
bins compiling and linking, 1822
names and unions, 1102 cancelling scheduled events, performance, 231
bitwise format, 757 canonical name, definition, 936
black-boxing capacity analysis, 1244
blocking assignments, 272 Capplications
bookmarks compiling and linking, 1818
Wave window, 691 debugging, 1209
Boolean Case sensitivity
failed expression, 1079 for VHDL and Verilog, 193, 247, 457
bound block case sensitivity
hierarchical references, 463 named port associations, 511
Break Case statements
on assertion, 1398 exclude allfalse branch, 947
Break severity Causality
assertions, 1398 in schematic, 781
break severity Causality trace
for assertions, 1018 path times bar, 885
Breakpoints Causality traceback, 863
Ccode, 1212 active driver path details, 787, 872
command execution, 856 create database, 863
conditional, 357, 855 from command line, 866
edit, 739, 742 from GUI, 869
Run Until Here, 860 from Objects or Schematic window, 874
saving/restoring, 743 from Source window, 873
setting automatically in C code, 1216 from specific time, 880
SystemC constructor/destructor, 421 from Wave window, 870
unavailable with vopt, 132 multiple drivers, 881
buffered/unbuffered output, 1695 post-sim debug, 868
Buffers set report destination, 866
in schematic, 775 setting preferences, 888
busses to all possible drivers, 879
RTL-level, reconstructing, 663 to driving process, 875
user-defined, 728 to root cause, 877
buswise format, 757 trace cursor, 872
trace to seq process, 870
—C— viewing path details
C Debug, 1209 in Schematic window, 884
auto find bp, 1215 in Wave window, 885
auto step mode, 1216 causality, tracing in Dataflow window, 820
debugging functions during elaboration, Cause
1219 show, 863, 868, 869, 870
debugging functions when exiting, 1222 cdbg_wait_for_starting command, 1212
function entry points, finding, 1215 CDebug
initialization mode, 1219 registered function calls, identifying, 1216
Stop on quit mode, 1222

ModelSim® SE User's Manual, v10.7 1883

 running from a DO file, 1212 Class Type
cell libraries, 293 find path and name, 363
change command finding all instances, 364
modifying local variables, 299 Class Type Inheritance
chasingX, 787, 821 find, 367
-check_synthesis argument Class Types
warning message, 1749 analyzing, 369
checkpoint/restore Class Variable
checkpointing a running simulation, 558 casting to specific type, 355
foreign C code and heap memory, 558 classinfo commands, 363
cin support, SystemC, 441 cleanup
Class calling functions, 361 SystemC state-based code, 412
Class Debug clean-up of SystemC state-based code, 412
enabling, 339 CLI commands for debugging transactions,
class debugging, 339 611
garbage collector, 1507, 1508 Click and sprout
GCThreshold .ini variable, 1507 schematic window
GCThresholdClassDebug .ini variable, incremental view, 766
1508 clock cycles
Class Graph Window, 345 display in timeline, 701
Class instance Clock declarations, 1056
properties, 360 clock declarations
values, 360 restrictions, 1057
Class Instance Garbage Collection, 370 clocked comparison, 753
Class Instance Identifier, 340 clocks
Class Instance Properties, 360 assertions, 1084
Class Instance Values, 360 Code Coverage
Class Instances Window, 348 $coverage_save system function, 310
Class Objects, 357 condition coverage, 893
Class objects enabling with vsim, 898
view in Wave window, 342, 722 excluding lines/files, 945
class objects exclusion filter files
breakpoints, 357 used in multiple simulation runs, 973
in Wave window, 350, 722 expression coverage, 893, 916
logging, 341 FSM coverage, 893
viewing, 343 Main window coverage data, 905
class of sc_signal, 425 pragma exclusions, 950, 969
Class Path Expression Syntax, 354 reports, 981
Class Path Expression Values, 355 toggle coverage, 893
Class Path Expressions, 357 toggle coverage in Signals window, 928
Class path expressions, 354 Code coverage
add to Wave, 355 SystemVerilog class, 893
syntax, 354 code coverage
values, 355 and op timization, 990
Class Tree Window, 345 branch coverage, 893

1884 ModelSim® SE User's Manual, v10.7

 condition coverage, 916 tolerance, 756
design is not fully covered, 990 values, 757
see alsoCoverage wave window display, 756
statement coverage, 893 compare by region, 751
code coverage, elaboration time, 895 compare commands, 747
Code preview compare signal, virtual
in schematic window, 769 restrictions, 728
code profiling, 1227 compare simulations, 647
Coding compil ing
assertion guidelines, 1009 properties, in projects, 168
collapsing ports, and coverage reporting, 986 compilation
collapsing time and delta steps, 660 multi-file issues (SystemVerilog), 254
Color SDF files, 1312
for traces, 817 compilation unit scope, 254
colors, setting of coverage numbers, 1183 Compile
Combine Selected Signals dialog box, 715 encryption
combining signals, busses, 728 ‘include, 87
Command line VHDL, 192
initiating causality traceback, 866 compile
command-line arguments, accessing, 445 projects
command-line mode, 69 add PSL files, 170
commands SystemC
event watching in DO file, 1374 reducing non-debug compile time, 396
system, 1362 Compile directive
vcd2wlf, 1346 encryption
VSIM Tcl commands, 1368 ‘include, 87
comment character compile order
Tcl and DO files, 1357 auto generate, 159
Commonly Used modelsim.ini Variables, 1732 changing, 158
compare SystemVerilog packages, 250
add signals, 751 Compiler Control Variable
adding regions, 751 SystemC
assertions, 1041 CppPath, 1467, 1469
by signal, 751 SccomLogfile, 1593
clocked, 753 SccomVerbose, 1594
difference markers, 756 ScvPhaseRelationName, 1601
displayed in list window, 758 UseScv, 1699
icons, 757 Compiler Control Variables
options, 754 Verilog
pathnames, 756 AcceptLowerCasePragmasOnly, 1410
reference dataset, 749 CoverCells, 1447
reference region, 751 EnableSVCoverpointExprVariablel,
tab, 750 1486
test dataset, 749 ExtendedToggleMode, 1492
timing differences, 756 GenerateLoopIterationMax, 1510

ModelSim® SE User's Manual, v10.7 1885

 GenerateRecursionDepthMax, 1511 Show_VitalChecksWarning, 1607
Hazard, 1515 Show_Warning1, 1608
LibrarySearchPath, 1534 Show_Warning2, 1609
MultiFileCompilationUnit, 1559 Show_Warning3, 1610
Protect, 1584 Show_Warning4, 1611
Quiet, 1587 Show_Warning5, 1612
Show_BadOptionWarning, 1603 VHDL93, 1705
Show_Lint, 1604 compiler directives, 327
Show_PslChecksWarnings, 1605 IEEE Std 1364-2000, 328
SparseMemThreshhold, 1639 XL compatible compiler directives, 330
SVCovergroupGoalDefault, 1654 Compiling
SVCovergroupPerInstanceDefault, libraries
1656 with -smartdbgsym option, 177
SVCovergroupSampleInfo, 1657 compiling
SVCovergroupStrobeDefault, 1659 changing order in the GUI, 158
SVCovergroupTypeGoalDefault, 1661 gensrc errors during, 450
SVCoverpointExprVariablePrefix, grouping files, 159
1664 order, changing in projects, 158
SVCoverpointWildCardBinValueSize overview, 65
Warn, 1665 range checking in VHDL, 195
SVCrossNumPrintMissingDefault, SystemC, 394
1667 converting sc_main(), 436
UpCase, 1697 exporting top level module, 395
vlog95compat, 1709 for source level debug, 396
VHDL, 1492 invoking sccom, 395
CoverageShortCircuit, 1462 linking the compiled source, 411
CoverFEC, 1454 modifying source code, 436
CoverREC, 1459 replacing sc_start(), 436
CoverSub, 1463 using sccom vs. raw C++ compiler, 399
EmbeddedPsl, 1484 Verilog, 246
Explicit, 1491 incremental compilation, 249
IgnoreVitalErrors, 1526 XL compatible options, 256
NoCaseStaticError, 1561 XL’uselib compiler directive, 257
NoDebug, 1562 VHDL, 192
NoIndexCheck, 1564 VITAL packages, 216
NoOthersStaticError, 1565 compiling C code, gcc, 1820
NoRangeCheckr, 1566 component
NoVital, 1568 disabling default binding, 205, 1588
NoVitalCheck, 1569 component declaration
Optimize_1164, 1575 generating SystemC from Verilog or
PedanticErrors, 1579 VHDL, 538
RequireConfigForAllDefaultBinding, generating VHDL from Verilog, 505
1588 vgencomp for SystemC, 538
ScalarOpts, 1592 vgencomp for VHDL, 505
Show_source, 1606 component, default binding rules, 204

1886 ModelSim® SE User's Manual, v10.7

Compressing files Cover directives
VCD tasks, 1342 cumulative threads, 1034
concurrent assertions, 1008 filtering, 1114
configuration memory usage, 1254
Verilog, support, 518 save, 1070, 1120
configuration simulator state variable, 1364 viewing in Wave window, 1034
configurations cover directives, 1044
instantiation in mixed designs, 504 active thread monitor, 1073
Verilog, 260 analyzing in the GUI, 1031
Configure AtLeast counts, 1023
encryption envelope, 83 change default configuration, 1021
confusing toggle numbers, 937 count mode, 1039
connectivity, exploring, 773, 814 limiting, 1024
Constants SystemVerilog
VHDL, 513 cover directives, 1064
Constrained random viewing in Wave window, 1034
initial seed value, 311 weighting, 1023
Constrained random stimulus, 1129 cover directives browser
constrained random stimulus display options, 1039
constraints, 1131 Coverage
Constrained random tests during optimization, 897
enabling/disabling, 1138 coverage
inheriting constraints, 1137 auto exclusions
rand and randc modifiers, 1131 fsm transitions, 943
Constraint algorithm auto-save, 901
negative timing checks, 284 data, automatic saving of, 1154
Constraint solver editing UCDB, 1172
set to previous release, 1139 enable FSMs, 994
constraint solver, 1129 fsm exclusions, 968
constraints fsm states, 993
random dynamic array size, 1134, 1628 fsm transitions, 993
construction parameters, SystemC, 446 missing expression, 917
Constructor ranking most effective tests, 1190
breakpoint, 421 setting default mode, 987
context menus UCDB, 1144
Library tab, 178 Coverage .ini file variable, 1445
control function, SystemC, 473 coverage calculation for toggles, 935
control_foreign_signal() function, 459 Coverage exclude
Convergence allfalse branch in case stmt, 947
delay solution, 284 Coverage exclusion pragmas
convert real to time, 220 fsm, 969
convert time to real, 219 coverage numbers
converting to a module, 436 setting color of, 1183
counts coverage numbers, mismatching, 851
assertion, 1025 coverage reports, 981

ModelSim® SE User's Manual, v10.7 1887

 default mode, 987 current exclusions
ensuring all signals appear, 986 pragmas, 950
HML format, 988 Cursor
xml format, 988 add, 674
coverage toggle_ignore pragma, 965 Cursors
CoverageShortCircuit .ini file var iable, 1462 linking, 676
CoverAtLeast .ini file variable, 1446 sync all active, 676
CoverCells .ini file variable, 1447 cursors
CoverClkOptBuiltins.ini file variable, 1448 adding, deleting, locking, naming, 672
CoverDeglitchOn .ini file variable, 1450 link to Dataflow window, 798, 831
CoverDeglitchPeriod .ini file variable, 1451 measuring time with, 675
CoverEnable .ini file variable, 1452 saving waveforms between, 720
CoverExcludeDefault .ini file variable, 1453 trace events with, 820
CoverFEC .ini file variable, 1454 Wave window, 675, 720
covergroup types Custom color
reporting, 1112 for trace, 818
Covergroups CvgZWNoCollect .ini file variable, 1472
add/modify filter, 1115
create filter, 1114 —D—
filter data, 1113 daemon
filtering, 1114 JobSpy, 1282
covergroups Data query
configuring, 1091 $typename function, 304
Covergroups window, 1107 Database
CoverLimit .ini file variable, 1455 for causality tracing, 863
CoverLog .ini file variable, 1456 database
CoverOpt .ini file variable, 1458 post-sim debug, 763, 809
CoverREC .ini file variable, 1459 Dataflow
CoverSub .ini file variable, 1463 post-sim debug database
CoverThreadLimit .ini file variable, 1464 create, 809
CoverThreadLimitAction .ini file, 1465 post-sim debug flow, 809
CoverWeight .ini file variable, 1466 sprout limit readers, 816
covreport.xsl, 988 Dataflow window, 805
CppOptions .ini file variable, 1468 pan, 801
CppPath .ini file variable, 1467, 1469 see alsowindows, Dataflow window
Create database zoom, 801
for causality tracing, 863 dataflow.bsm file, 793, 826
create debug, 763 Dataset Browser, 659
create debug database, 809 Dataset Snapshot, 649
Create Patter Wizard, 1299 datasets, 647
CreateDirForFileAccess .ini file variable, 1470 managing, 659
Creating do file, 718, 743 opening, 654
Cumulative Threads prevent dataset prefix display, 660
assertions, 1034 reference, 749
cover directives, 1034 test, 749
view structure, 656

1888 ModelSim® SE User's Manual, v10.7

 visibility, 657 as a simulator state variable, 1364
DatasetSeparator .ini file variable, 1473 dependent design units, 193
Debug Deprecated encryption keys, 120
class, 339 design library
debug database creating, 176
create, 763, 809 logical name, assigning, 180
debug flow mapping search rules, 180
post-simulation, 764, 809 resource type, 174
debuggable SystemC objects, 417 VHDL design units, 192
Debugging working type, 174
randomize() failures, 1134 design object visibility, +acc, 147
debugging design optimization with vopt, 121
assertion failures, 1072 design portability and SystemC, 397
Ccode, 1209 Design Unit signature checking, 1170
null value, 276 design units, 174
SIGSEGV, 275 Destructor
SystemC channels and variables, 431 breakpoint, 421
debugging the design, overview, 68 DEVICE
Defa ultRadixFlags .ini file variable, 1477 matching to specify path delays, 1320
default binding dialogs
disabling, 205, 1588 Runtime Options, 1395
default binding rules, 204 Direct Programming Interface, 1793
default clock Direct programming interface (DPI), 242
in assertions, 1056 directives
default coverage mode, setting, 987 PSL
Default editor, changing, 1850 in procedural blocks, 1047
default SystemC parameter values, overriding, directories
446 moving libraries, 182
DefaultForceKind .ini file variable, 1474 disable_signal_spy, 1263
DefaultLibType .ini file variable, 1475 Display mode
DefaultRadix .ini file variable, 1476 expanded time, 686
DefaultRestartOptions .ini file variable, 1478 display mode
DefaultRestartOptions variable, 1735 recursive
Deferredassertions, 1063 display mode
delay show all contexts, 1038
delta delays, 205 Display options
modes for Verilog models, 294 assertions browser, 1038
Delay solu tion convergence, 284 display options
DelayFileOpen .ini file variable, 1479 cover directives browser, 1039
deleting library contents, 178 display preferences
delta collapsing, 660 Wave window, 700
delta simulator state variable, 1364 displaymsgmode .ini file variable, 1480
deltas distributed delay mode, 297
explained, 205 dividers
referencing simulator iteration Wave window, 707

ModelSim® SE User's Manual, v10.7 1889

DLL files, loading, 1818, 1822 editing UCDBs, 1172
DO files EDITOR environment variable, 1850
executing at startup, 1641, 1851 editor, default, changing, 1850
parameters elab_defer_fli argument, 565
as a simulator state variable (n), 1364 elaboration file
passing, 1374 creating, 563
total number passed, 1364 loading, 563
parameters, passing to, 1374 modifying stimulus, 563
startup scripts, 1734 simulating with PLI or FLI models, 565
vsim command arguments elaboration, and code coverage, 895
list of, 1364 embedded wave viewer, 780, 818
DO files (macros) EmbeddedPsl .ini file variable, 1484
error handling, 1379 EMPTY, 1370
Tcl source command, 1379 empty port name warning, 1748
DOPATH environment variable, 1849 Enable
DPI, 242 assertion thread viewing, 1068
and qverilog command, 1802 assertions, 1015
export TFs, 1748 enable_signal_spy, 1265
missing DPI import function, 1804 EnableSVCoverpointExprVariable .ini file
optimizing import call performance, 1805 variable, 1486
registering applications, 1799 EnableTypeOf .ini file variable, 1487
use flow, 1801 Encoding
DPI access routines, 1840 methods, 114
DPI export TFs, 1748 encrypt
DPI/VPI/PLI, 1793 IP code
DpiCppPath .ini file variable, 1481 pulblic keys, 116
DpiOutOfTheBlue .ini file variable, 1482 undefined macros, 95
Driver vendor-defined macros, 97
path details, 787, 872 IP source code, 81
Drivers usage models, 95
multiple, 881 protect pragmas, 95
drivers vencrypt utility, 95
Dataflow Window, 814 vencrypt command
show in Dataflow window, 735 header file, 97, 102
Wave window, 735 vlog +protect, 111
dumpports tasks, VCD files, 1340 encrypting IP code
DumpportsCollapse .ini file variable, 1483 vencrypt utility, 95
DUsig, 1170 Encryption
dynamic array, 1134, 1628 asymmetric, 114, 115
dynamic module array compile with +protect, 91
SystemC, 426 configuring envelope, 83
creating envelope, 83
—E— default asymmetric method for Questa, 115
edit default symmetric method for Questa, 115
breakpoints, 739, 742 deprecated keys, 120
Editing the modelsim.ini file, 1393

1890 ModelSim® SE User's Manual, v10.7

 envelopes error
how they work, 115 can’t locate C compiler, 1748
for multiple simulators error .ini file variable, 1489
Encryption ErrorFile .ini file variable, 1490
portable, 89 errors
language-specific usage, 94 "api_version"in, 452
methods, 114 bad magic number, 651
proprietary compile directives, 110 DPI missing import function, 1804
protection expressions, 86 getting more information, 1743
unsupported, 87 libswift entry not found, 1751
raw, 115 multiple definition, 450
runtime model, 92 out-of-line function, 453
symmetric, 114 severity level, changing, 1743
usage models for VHDL, 101 SystemC loading, 450
using ‘include, 87 SystemVerilog, missing declaration, 1559
using Mentor Graphics public key, 117 Tcl_init error, 1749
vlog +protect, 98 void function, 453
encryption VSIM license lost, 1751
‘protect compiler directive, 111, 328 zero-delay iteration loop, 1751
securing pre-compiled libraries, 111 escaped identifiers, 291, 510
Encryption and Encoding methods, 114 Tcl considerations, 291
end_of_construction() function, 445 EVCD files
end_of_simulation() function, 445 exporting, 1305
ENDFILE function, 213 importing, 1306
ENDLINE function, 212 event order
endpoints in optimized designs, 150
in HDL code, 1057 in Verilog simulation, 270
entities event queues, 270
default binding rules, 204 Event traceback
disabling default binding, 205, 1588 toolbar button, 869
entity simulator state variable, 1364 using schematic window, 781
EnumBaseInit .ini file variable, 1488 event watching commands, placement of, 1374
environment variables, 1848 events, tracing, 820
expansion, 1848 examine command
referencing from command line, 1856 expanded time, 688
referencing with VHDL FILE variable, Exclude
1856 toggle nodes, 965
setting, 1849 Exclude allfalse
setting in Windows, 1854 in case statements, 947
TranscriptFile, specifying location of, 1691 Exclusion
used in Solaris linking for FLI, 1818, 1823 adaptive, 959, 960
used in Solaris linking for transitive, 1118
PLI/VPI/DPI/FLI, 1850 exclusion filter files
using with location mapping, 1738 used in multiple simulation runs, 973
variable substitution using Tcl, 1362 Exclusion pragma syntax

ModelSim® SE User's Manual, v10.7 1891

 multiline, 956 expression hierarchy
Exclusion pragmas atv window, 1086
for FSM expression pane, 1079
simultaneous behavior, 972 atv window, 1079
simultaneous behavior - toggles, 966 Expressions
Exclusions reporting non-testable terms, 918
pragmas expressions
fsm, 969 missing coverage, cause, 917
exclusions extended identifiers
lines and files, 945 in mixed designs, 505, 538
exit codes, 1746 Extended system tasks
exiting tool on sc_stop or $finish, 1573 Verilog, 323
exiting tool, customizing, 1573 extended toggles, conversion of, 934
Exlude ExtendedToggleMode .ini file variable, 1492
toggle node transitions, 965
expand —F—
environment variables, 1848 Failed boolean
expand net, 773, 814 ATV window, 1079
Expanded Time Fatal .ini file variable, 1493
customizing Wave window, 685 Fatal error
examine command, 688 SIGSEGV, 276
expanding/collapsing sim time, 687 FecCountLimit .ini file variable, 1494
with commands, 688 FIFOs, viewing SystemC, 427
with menu selections, 688 fil ters
with toolbar buttons, 688 for Code Coverage
in Wave, 680 used in multiple simulation runs, 973
recording, 681 File compression
searchlog command, 688 VCD tasks, 1342
seetime command, 689 file compression
selecting display mode, 686 SDF files, 1310
with command, 687 file I/O
with menus, 686 TextIO package, 209
with toolbar buttons, 686 file-line breakpoints
switching time mode, 687 edit, 742
terminology, 680 files
viewing in Wave window, 682 .modelsim, 1845
Explicit .ini file variable, 1491 files, grouping for compile, 159
export TFs, in DPI, 1748 Filter
Exporting SystemC modules add/modify
to Verilog, 526 for covergroups, 1115
exporting SystemC modules assertion thread start times, 1075
to VHDL, 539 assertions/cover directives, 1114
exporting top SystemC module, 395 covergroups, 1113
Expression Builder, 695 create
saving expressions to Tcl variable, 697 for cover directives, 1114
setup

1892 ModelSim® SE User's Manual, v10.7

 for assertions/cover directives, Format
covergroups, 1114 saving/restoring, 718
filtering data in UCDB, 1203 format file, 716
Find Wave window, 716
class type FPGA libraries, importing, 189
path and name, 363 FSM
class type inheritance, 367 coverage exclusions, 969
prefill text entry field, 1240 view current state, 996
stop, 694 fsm transitions
Find instances auto exclusions, 943
class type, 364 FsmImplicitTrans .ini file variable, 1503
Finite State Machines FsmResetTrans .ini file variable, 1504
coverage exclusions, 968 FsmSingle .ini file variable, 1505, 1701
enable coverage, 994 FsmXAssign .ini file variable, 1506
enable recognition, 994 function calls, identifying with C Debug, 1216
recognition reporting, 1001, 1002 Functional Coverage
state coverage, 993 reports
transition coverage, 993 with timestamps, 1112
fixed-point types, in SystemC Functional coverage
compiling for support, 441 controlling optimization, 1092
construction parameters for, 447 html report, 1112
FlateLibPageDeletePercentage .ini file reporting, 1110
variable, 1498 text report, 1110
FlateLibPageDeleteThreshold .ini file variable, white box testing, 1089
1499 functional coverage
FlatLibPageSize .ini file variable, 1497 aggregation in Structure view, 1150
FLI, 203 calculating metrics, 1094
debugging, 1209 reporting
floatfixlib .ini file variable, 1500 covergroup type objects, 1112
Folded instance viewing statistics in the GUI, 1107
schematic, 777 functions
folders, in projects, 166 SystemC
forall keyword, 1074 control, 473
force command observe, 473
defaults, 1735 unsupported, 440
ForceSigNextIter .ini file variable, 1501 virtual, 663
ForceUnsignedIntegerToVhdlInteger .ini file
variable, 1502 —G—
foreign language interface, 203 -g C++ compiler option, 418
foreign model loading g++, alternate installations, 396
SmartModels, 1859 Gate-level
foreign module declaration metastability, 297
Ver ilog e xample, 520 generate statements, Veilog, 262
VHDL example, 532 GenerateFormat .ini file variable, 1509
foreign module declaration, SystemC, 519 GenerateLoopIterationMax .ini file variable,
1510

ModelSim® SE User's Manual, v10.7 1893

GenerateRecursionDepthMax .ini variable, supported objects, 462
1511 SystemC/mixed-HDL designs, 473
generic support SystemVerilog, 472
SC instantiating VHDL, 532 hierarchy
generics driving signals in, 1266
passing to sc_foreign_module (VHDL), forcing signals in, 218, 1276
532 referencing signals in, 218, 1271
SystemC instantiating VHDL, 532 releasing signals in, 219, 1278
VHDL, 481 Highlight trace, 817
generics, integer Highlighting
passing as template arguments, 534 assertion thread
generics, integer and non-integer root thread analysis, 1085, 1086
passing as constructor arguments, 532 Highlights
GenerousIdentifierParsing .ini file variable, in Source window, 845
1512 hm_entity, 1870
get_resolution() VHDL function, 217 HOLD
Global signal radix, 706 matching to Verilog, 1320
global visibility HOME environment variable, 1850
PLI/FLI shared objects, 1826 HTML format
GLOBALPATHPULSE coverage reports, 988
matching to specify path delays, 1319 HTML report
GlobalSharedObjectList .ini file variable, 1513 functional coverage, 1112
GlobalSharedObjectsList .ini file variable,
1514 —I—
graphic interface, 665, 761, 805, 835 I/O
Grid Engine TextIO package, 209
JobSpy integration, 1291 identifiers
grouping files for compile, 159 escaped, 291, 510
groups ieee .ini file variable, 1516
in wave window, 709 IEEE libraries, 188
GUI_expression_format IEEE Std 1076, 77
GUI expression builder, 695 differences between versions, 199
Guidelines IEEE Std 1364, 78, 242, 337, 1133
for coding assertions, 1009 IEEE Std 1364-2005, 81, 1322
ignoredusig, 1170
—H— IgnoreError .ini file variable, 1517
hardware model interface, 1869 IgnoreFailure .ini file variable, 1518
Hazard .ini file variable, 1515 IgnoreNote .ini file variable, 1519
hazards IgnorePragmaPrefix .ini file variable, 1520
limitations on detection, 275 ignoreStandardRealVector .ini file variable
HDL sub-expressions .ini compiler control variables
failures in ATV window, 1083 ignoreStandardRealVector, 1521
Hierarchical access IgnoreSVAError .ini file variable, 1522
mixed-language, 459 IgnoreSVAFatal .ini file variable, 1523
Hierarchical references, 458 IgnoreSVAInfo .ini file variable, 1524
bind, 463 IgnoreSVAWarning .ini file variable, 1525

1894 ModelSim® SE User's Manual, v10.7

IgnoreVitalErrors .ini file variable, 1526 instantiation in SystemC-VHDL design
IgnoreWarning .ini file variable, 1527 VHDL from SystemC, 530
immediate assertions, 1008, 1694 instantiation in VHDL-SystemC design
break severity, 1398 SystemC from VHDL, 537
configuring in GUI, 1017 INTERCONNECT
deferred, 1063 matching to input ports, 1319
message logging, 1522 interconnect delays, 1326
ImmediateContinuousAssign .ini file variable, Inverters
1528 in schematic, 775
importing EVCD files, waveform editor, 1306 IOPATH
importing FPGA libraries, 189 matching to specify path delays, 1319
IncludeRecursionDepthMax .ini file variable, IP code
1529 encrypt, 81
incremental compilation public keys, 116
automatic, 251 undefined macros, 95
manual, 251 vendor-defined macros, 97
with Verilog, 249 encryption us age models, 101
Incremental view encryption usage models, 95
click and sprout, 766 using protect pragmas, 95
schematic window vencrypt usage models, 95
adding objects, 771 iteration_limit, infini te zero-delay loops, 207
index checking, 195 IterationLimit .ini file variable, 1531
Inheriting constraints, 1137
init_signal_driver, 1266 —J—
init_signal_spy, 218, 1271 JobSpy
init_usertfs function, 1222, 1796 daemon, 1282
Initial random seed value, 311 —K—
initialization of SystemC state-based code, 412 keywords
initialization sequence, 1846 SystemVe rilog, 247
InitOutCompositeParam .ini file variable, 1530
inline assertions —L—
PSL, 1048 Language Reference Manual (LRM), 77, 243
inlining language versions, VHDL, 199
VHDL subprograms, 196 LargeObjectSilent .ini file variable, 1532
input ports LargeObjectSize .ini file variable, 1533
matching to INTERCONNECT, 1319 Liberty Cell Libraries,optimizing, 143
matching to PORT, 1319 Libraries
Instance compile
folded/unfolded, 777 with -smartdbgsym option, 177
instantiation in mixed-language design mapping
Verilog from VHDL, 504 from the GUI, 180
VHDL from Verilog, 509 libraries
instantiation in SystemC-Verilog design creating, 176
SystemC from Verilog, 526 design libraries, creating, 176
Verilog from SystemC, 518 design library types, 174

ModelSim® SE User's Manual, v10.7 1895

 design units, 174 LM_LICENSE_FILE environment variable,
group use, setting up, 182 1851
IEEE, 188 loading the design, overview, 67
importing FPGA libraries, 189 Local variables
mapping print to Transcript, 1068
from the command line, 181 local variables
hierarchically, 1733 annotating, 1088
search rules, 180 modifying with change command, 299
modelsim_lib, 217 location maps, referencing source files, 1738
moving, 182 locations maps
naming, 180 specifying source files with, 1738
others clause, 182 lock message, 1748
predefined, 187 locking cursors, 672
refreshing library images, 188 log file
resource libraries, 174 overview, 647
std library, 187 see alsoWLF files, 647
Synopsys, 188 Log local variables, 1068
Verilog, 479, 1349 Logic Modeling
VHDL library clause, 187 SmartModel
working libraries, 174 command channel, 1864
working vs resource, 63 SmartModel Windows
working with contents of, 178 lmcwin commands, 1865
library map file, Verilog configurations, 260 memory arrays, 1867
library mapping, overview, 63 long simulations
library maps, Verilog 2001, 260 saving at intervals, 649
Library search rules, 184 LRM, 77, 243
library simulator state variable, 1364 LSF
library, definition, 62 JobSpy integration, 1291
LibrarySearchPath .ini file variable, 1534
libsm, 1859 —M—
libswift, 1859 MacroNestingLevel simulator state variable,
entry not found error, 1751 1364
License .ini file variable, 1535 macros (DO files)
licensing depth of nesting, simulator state variable,
License variable in .ini file, 1535 1364
limit toggle coverage, 940 error handling, 1379
Limitations malloc()
PSL, 1062 checkpointing foreign C code, 558
Limiting WLF file, 654 mapping
Link cursors, 676 data types, 476
linking SystemC source, 411 libraries
List window from the command line, 181
virtual interfaces, 725 hierarchically, 1733
waveform comparison, 758 symbols
Dataflow window, 793, 826
SystemC in mixed designs, 502

1896 ModelSim® SE User's Manual, v10.7

 SystemC to Verilog, 496 assertions, 1254
SystemC to VHDL, 502 cover directives, 1254
Verilog states in mixed designs, 479 merge
Verilog states in SystemC designs, 495 being skipped, 1170
Verilog to SytemC, port and data types, 495 master, 1168
Verilog to VHDL data types, 476 test-associated, 1175
VHDL to SystemC, 487 merged UCDB, ranking of, 1189
VHDL to Verilog data types, 480 merging
mapping signals, waveform editor, 1306 results from multiple simulation runs, 973
master merge, 1168 message logging
Math function assertions, 1017
$clog2, 307 message system, 1742
math_complex package, 188 MessageFormat .ini file variable, 1542
math_real package, 188 MessageFormatBreak .ini file variable, 1543
MaxReportRhsCrossProducts .ini file variable, MessageFormatBreakLine .ini file variable,
1536 1544
MaxReportRhsSVCrossProducts .ini file MessageFormatError .ini file variable, 1545
variable, 1537 MessageFormatFail .ini file variable, 1546
MaxSVCoverpointBinsDesign .ini file MessageFormatFatal .ini file variable, 1547
variable, 1538 MessageFormatNote .ini file variable, 1548
MaxSVCoverpointBinsInst .ini file variable, MessageFormatWarning .ini file variable, 1549
1539 messages, 1742
MaxSVCrossBinsDesign .ini file varable, 1540 assertion failures, 1068
MaxSVCrossBinsInst .ini file variable, 1541 bad magic number, 651
mc_scan_plusargs() empty port name warning, 1748
using with an elaboration file, 565 exit codes, 1746
Memories getting more information, 1743
save to WLF file, 651 lock message, 1748
memories long description, 1743
initial value, 263 metavalue detected, 1749
seed generation report, 265 redirecting, 1691
sparse memory modeling, 332 sensitivity list warning, 1749
memory suppressing warnings from arithmetic
capacity analysis, 1244 packages, 1734
modeling in VHDL, 221 Tcl_init error, 1749
memory allocation too few port connections, 1750
checkpointing foreign C code, 558 turning off assertion messages, 1735
memory allocation profiler, 1230 VSIM license lost, 1751
memory leak, cancelling scheduled events, 231 warning, suppressing, 1744
memory leaks and transaction handles, 596 Metastability
Memory profile data approximating for Verilog, 297
viewing PSL, 1033 metavalue detected warning, 1749
Memory profiling MFCU, 254
assertions/cover directives, 1016 MGC_LOCATION_MAP env variable, 1738
Memory usage MGC_LOCATION_MAP variable, 1851

ModelSim® SE User's Manual, v10.7 1897

MinGW gcc, 1820, 1824 mti_cosim_trace environment variable, 1852
mismatching coverage numbers, 851 mti_inhibit_inline attribute, 196
missing DPI import function, 1804 MTI_SYSTEMC macro, 397
missing expression coverage, 917 MTI_TF_LIMIT environment variable, 1852
MixedAnsiPorts .ini file variable, 1550 MTI_VCO_MODE environment variable,
MIxed-language 1853
optimizing DPI import call performance, mtiAvm .ini file variable, 1554
1805 mtiOvm .ini file variable, 1555
Mixed-language mtiPA .ini file variable, 1556
hierarchical references, 458 mtiUPF .ini file variable, 1557
mixed-language simulation mtiUvm .ini file variable, 1558
access limitations, 459 multi file compilation unit (MFCU), 254
MOD ELSIM_PREFERENCES variable, 1852 multi-bit signals
mode, setting default coverage, 987 expression coverage, 917
MODEL_TECH environment variable, 1851 multiclocked assertions, 1057
MODEL_TECH_TCL environment variable, multi-file compilation issues, SystemVerilog,
1851 254
modeling memory in VHDL, 221 MultiFileCompilationUnit .ini file variable,
MODELSIM environment variable, 1851 1559
modelsim_lib, 217 Multiple drivers, 881
modelsim_lib .ini file variable, 1551 Multiple simulations, 647
modelsim.ini multiple test data records, troubleshooting,
default to VHDL93, 1736 1169
delay file opening with, 1736 MvcHome .ini file variable, 1560
editing,, 1393
environment variables in, 1732 —N—
force command default, setting, 1735 n simulator state variable, 1364
found by the tool, 1846 Name field
hierarchical library mapping, 1733 Project tab, 162
opening VHDL files, 1736 name visibility in Verilog generates, 262
restart command defaults, setting, 1735 naming optimized designs, 123
transcript file created from, 1733 navigating
turning off arithmetic package warnings, atv window, 1078
1734 Negative timing
turning off assertion messages, 1735 algorithm for calculating delays, 279
modes of operation, 69 check limits, 279
Modified field, Project tab, 162 constraint algorithm, 284
modify delay solution convergence, 284
breakpoints, 742 syntax for $recrem, 282
modifying local variables, 299 syntax for $setuphold, 280
modifying UCDB data, 1172 using delayed inputs for checks, 288
modules Negative timing checks, 278
with unnamed ports, 507 nets
MsgLimitCount .ini file variable, 1552 Dataflow window, displaying in, 805
msgmode .ini file variable, 1553 values of
saving as binary log file, 647

1898 ModelSim® SE User's Manual, v10.7

new function control with UCDB file, 1092
initialize SV object handle, 275 specifying coverage, 897
Nlview widget Symlib format, 794, 828 Optimization Configurations, 164
NoCaseStaticError .ini file variable, 1561 optimizations
NOCHANGE design object visibility, 147
matching to Verilog, 1322 event order issues, 150
NoDebug .ini file variable, 1562 timing checks, 150
NoDeferSubpgmCheck .ini file variable, 1563 Verilog designs, 121, 623
NoIndexCheck .ini file variable, 1564 VHDL subprogram inlining, 196
NOMMAP environment variable, 1853 Optimize_1164 .ini file variable, 1575
non-blocking assignments, 272 optimized designs
Non-synthesizable, 761 naming, 123
Non-testable terms of expressions, 918 optimized designs, unnamed, 125
NoOthersStaticError .ini file variable, 1565 order of events
NoRangeCheck .ini file variable, 1566 in optimized designs, 150
note .ini file variable, 1567 ordering files for compile, 158
NoVital .ini file variable, 1568 organizing projects with folders, 166
NoVitalCheck .ini file variable, 1569 OSCI simulator, differences with vsim, 439
Now simulator state variable, 1364 osvvm .ini file variable, 1576
now simulator state variable, 1364 Others clause
null value libraries, 182
debugging, 276 Override
numeric_bit package, 188 with toggle add, 939
numeric_std package, 188
disabling warning messages, 1735 —P—
NumericStdNoWarnings .ini file variable, packages
1570 standard, 187
textio, 187
—O— util, 217
object VITAL 1995, 214
defined, 77 VITAL 2000, 214
Object handle page setup
initialize with new function, 275 Dataflow window, 798, 833
objects pan, Dataflow window, 801
virtual, 662 parallel transaction
objects, viewable SystemC, 417 definition of, 569
observe function, SystemC, 473 ParallelJobs .ini file variable, 1577
observe_foreign_signal() function, 459 parameter support
OldVHDLConfigurationVisibility .ini file SC instantiating Verilog, 520
variable, 1571 SystemC instantiating Verilog, 520
OldVhdlForGenNames .ini file variable, 1572 Verilog instantiating SC, 526
OnFinish .ini file variable, 1573 Verilog instantiating SystemC, 526
OnFinishPendingAssert .ini file variable, 1574 parameters
operating systems supported,See Installation making optional, 1375
Guide passing from Verilog to SC, 527
Optimization

ModelSim® SE User's Manual, v10.7 1899

 passing to sc_foreign_module (Verilog), debugging, 1209
521 tracing, 1841
using with DO files, 1374 PLI/VPI/DPI, 1793
parameters (Verilog to SC) registering DPIapplications, 1799
passing as constructor arguments, 521 specifying the DPI file to load, 1825
passing integer as template arguments, 523 PliCompatDefault .ini file variable, 1580
path delay mode, 297 PLIOBJS environment variable, 1797, 1853
path delays,matching to DEVICE statements, PORT
1320 matching to input ports, 1319
path delays,matching to port collapsing, toggle coverage, 986
GLOBALPATHPULSE statements, Port driver data, capturing, 1346
1319 ports, unnamed, in mixed designs, 507
path delays,matching to IOPATH statements, ports, VHDL and Verilog, 478
1319 Postscript
path delays,matching to PATHPULSE saving a waveform in, 718
statements, 1319 saving the Dataflow display in, 798, 832
Path times bar Post-sim debug
causality trace, 885 causality tracing, 868
pathnames post-sim debug flow, 764, 809
comparisons, 756 Power Aware
hiding in Wave window, 700 in the schematic window, 791
PATHPULSE Pragma
matching to specify path delays, 1319 FSM exclusion
PDU, 123, 134, 136, 137, 138, 140 simultaneous behavior, 972
PedanticErrors .ini file variable, 1579 toggle exclusion
performance simultaneous behavior, 966
cancelling scheduled events, 231 Pragma syntax
improving for Verilog simulations, 121, multiline exclusion, 956
623 pragmas, 950
Performance profiling protecting IP code, 95
assertions/cover directives, 1016 precision
PERIOD in timescale directive, 267
matching to Verilog, 1322 simulator resolution, 267
phase transaction precision, simulator resolution, 471
definition of, 569 PrefCoverage(DefaultCoverageMode), 987
platforms PrefCoverage(pref_InitFilterFrom), 950
choosing 32- versus 64-bit, 1853 preference variables
platforms supported,See Installation Guide .ini files, located in, 1400
PLI preferences
design object visibility and auto +acc, 147 Wave window display, 700
loading shared objects with global symbol Prefill text entry
visibility, 1826 find, 1240
specifying which apps to load, 1797 Preoptimized Design Unit, 134
Veri user entry, 1797 Preoptimized Design Unit (PDU), 123, 134,
PLI/VPI, 337 136, 140

1900 ModelSim® SE User's Manual, v10.7

 Verilog, 137 projects, 151
VHDL, 138 accessing from the command line, 171
PreserveCase .ini file variable, 1581 adding files to, 156
preserving case of VHDL identifiers, 1581 benefits, 152
primitives, symbols in Dataflow window, 793, compile order, 158
826 changing, 158
printing compiler properties in, 168
Dataflow window display, 798, 832 compiling files, 157
waveforms in the Wave window, 718 creating, 154
printing simulation stats, 1582 creating simulation configurations, 163
PrintSimStats .ini file variable, 1582 folders in, 166
PrintSVPackageLoadingAttribute .ini file grouping files in, 159
variable, 1583 loading a design, 160
Procedural blocks MODELSIM environment variable, 1851
PSL directives, 1047 overview, 152
Profile data Proprietary compile directives
memory usage encryption, 110
assertions, 1033 protect
cover directives, 1033 source code, 81
profile report command, 1240 Protect .ini file variable, 1584
Profiler, 1227 protect pragmas
%parent fields, 1235 encrypting IP code, 95
clear profile data, 1231 protected types, 222
enabling statistical sampling, 1231 Protection expressions, 86
getting started, 1230 PSL
handling large files, 1230 assertion debug, 1067
Hierarchical View, 1234 assertion messages
interpreting data, 1232 alternate output file, 1045
memory allocation, 1230 assertions
memory allocation profiling, 1231 embedded, 1048
profile report command, 1240 in external file, 1052
Profile Report dialog, 1240 inline, 1048
Ranked View, 1233 library and use clauses, 1054
report option, 1240 reporting, 1044
results, viewing, 1233 view in Analysis window, 1031
statistical sampling, 1229 viewing in Wave window, 1034
Structural View, 1236 clock declarations
viewing profile details, 1237 default clock, 1056
Profiling multi-clocked properties, 1057
assertions/cover directives, 1016 partially clocked, 1056
Programming Language Interface, 337, 1793 restrictions, 1057
project tab clockdeclarations
sorting, 163 unclocked properties, 1056
project window compiling
information in, 162 elaboration/optimization, 1061

ModelSim® SE User's Manual, v10.7 1901

 embedded assertions, 1061 supported types, 1132
external assertions, 1061 Random constraints
recompile after changes, 1062 stability across versions, 1139
configuring assertions, 1014 random dynamic array, 1134, 1628
enable pass/fail logging, 1018 random number generator
set actions, 1020 seeding, 1140
set fail limits, 1019 Random stimulus
configuring cover directives constrained, 1129
change default configuration, 1021 random stimulus
limiting, 1024 constraints, 1131
weighting, 1023 randomize, 1132
cover directives randomize() failures
count mode, 1039 debugging, 1134
endpoints range checking, 195
in HDL code, 1057 rank most effective tests, 1190
limitations, 1062 ranked results
replicator parameters, 1074 differences, 1189
simulating assertions, 1025 ranking
PSL assertions most effective tests, 1190
clock declarations, 1056 ranking a merged UCDB, 1189
compiling and simulating, 1061 Raw encryption, 115
PSL directives Readers
in procedural blocks, 1047 sprout limit in dataflow, 816
PslInfinityThreshold .ini file variable, 1586 readers and drivers, 773, 814
PslOneAttempt .ini file variable, 1585 real type, converting to time, 220
Public encryption key, 117 Recall breakpoints, 743
Public encryption keys, 116 reconstruct RTL-level design busses, 663
Recording
—Q— expanded time, 681
Quiet .ini file variable, 1587 RECOVERY
qverilog matching to Verilog, 1321
one-step flow, 246 RECREM
qverilog command matching to Verilog, 1321
DPI support, 1802 Recursive display mode, 1038
—R— redirecting messages, TranscriptFile, 1691
race condition, problems with event order, 270 Redundant buffers
Radix in schematic, 775
DefaultRadixFlags .ini variable, 1477 Redundant inverters
set globally, 706 in schematic, 775
radix reference region, 751
SystemVerilog types, 705 refreshing library images, 188
Wave window, 705 regions
rand virtual, 664
SystemVerilog class modifier, 1131 registered function calls, 1216
randc registers

1902 ModelSim® SE User's Manual, v10.7

 initial value, 263 Root cause, 877
seed generation report, 265 Root thread analysis
values of assertions, 1085, 1086
saving as binary log file, 647 RTL-level design busses
REMOVAL reconstructing, 663
matching to Verilog, 1321 RunLength .ini file variable, 1590
renaming items in UCDB, 1172 Runtime
replicator parameters, 1074 encryption, 92
Reporting Runtime Options dialog, 1395
causality trace, 866
reporting, 1044 —S—
code coverage, 981 Save
Reports assertions, 1070, 1120
funct ional coverage cover directives, 1070, 1120
text, 1110 schematic, 790
functional coverage, 1110 Saving
html, 1112 window format, 718
reports saving
fsm recognition, 1001, 1002 simulation options in a project, 163
RequireConfigForAllDefaultBinding .ini file waveforms, 647
variable, 1588 saving coverage, automatic, 901
resolution sc_argc() function, 445
in SystemC simulation, 412 sc_argv() function, 446
mixed designs, 471 sc_clock() functions, moving, 436
returning as a real, 217 sc_cycle() function, 440
truncated value, 413 sc_fifo, 427
truncated values, 269, 412, 1369 sc_fix and sc_ufix, 446
verilog simulation, 267 sc_fixed and sc_ufixed, 446
VHDL simulation, 203 sc_foreign_module, 531
Resolution .ini file variable, 1589 sc_foreign_module (Verilog)
resolution simulator state variable, 1364 and parameters, 521
Resolving VCD values, 1348 sc_foreign_module (VHDL)
when force cmd used, 1348 and generics, 532
resource libraries sc_main(), 436
specifying, 184, 187 sc_main() function, 384
restart command sc_main() function, converting, 436
defaults, 1735 SC_MODULE_EXPORT macro, 395
Restore sc_signal() functions, moving, 436
breakpoints, 743 sc_signed and sc_unsigned, 446
schematic, 790 sc_start() function, 440
Restoring sc_start() function, replacing in SystemC, 440
window format, 718 sc_start(), replacing, 436
results, saving simulations, 647 sc_stop()
return to VSIM prompt on sc_stop or $finish, behavior of, 447
1573 behavior, customizing, 1573
ScalarOpts .ini file variable, 1592

ModelSim® SE User's Manual, v10.7 1903

sccom $sdf_annotate system task, 1317
using sccom vs. raw C++ compiler, 399 optional conditions, 1325
sccom -link command, 412, 539 optional edge specifications, 1324
SccomLogfile .ini file variable, 1593 rounded timing values, 1325
SccomVerbose .ini file variable, 1594 SDF to Verilog construct matching,
ScEnableScSignalWriteCheck .ini variable, 1319
1595 VHDL
scgenmod, using, 519, 530 resolving errors, 1314
Schematic SDF to VHDL generic matching, 1314
click and sprout, 766 SDF annotate
code preview, 769 $sdf_annotate system task, 1317
display power information, 791 SDF annotation
folding/unfolding instances, 777 matching single timing check, 1329
post-sim debug database SDF DEVICE
create, 763 matching to Verilog constructs, 1320
post-sim debug flow, 764 SDF GLOBALPATHPULSE
save and restore, 790 matching to Verilog constructs, 1319
show drivers/readers, 773 SDF HOLD
tooltip, 769 matching to Verilog constructs, 1320
views, 766 SDF INTERCONNECT
Schematic window, 761 matching to Verilog constructs, 1319
add objects to incr view, 771 SDF IOPATH
annotate, 790 matching to Verilog constructs, 1319
display redundant buffers, 775 SDF NOCHANGE
display redundant inverters, 775 matching to Verilog constructs, 1322
path times bar, 885 SDF PATHPULSE
show causality path, 884 matching to Verilog constructs, 1319
sticky note, 790 SDF PERIOD
synthesizable parts of design, 761 matching to Verilog constructs, 1322
ScMainStackSize .ini file variable, 1597 SDF PORT
ScShowIeeeDeprecationWarnings .ini matching to Verilog constructs, 1319
variable, 1599 SDF RECOVERY
ScStackSize .ini file variable, 1598 matching to Verilog constructs, 1321
ScTimeUnit .ini file variable, 1600 SDF RECREM
ScvPhaseRelationName .ini variable, 1601 matching to Verilog constructs, 1321
SDF, 148, 200 SDF REMOVAL
compiled SDF, 1312 matching to Verilog constructs, 1321
disabling timing checks, 1326 SDF SETUPHOLD
errors and warnings, 1311 matching to Verilog constructs, 1320
instance specification, 1310 SDF SKEW
interconnect delays, 1326 matching to Verilog constructs, 1321
mixed VHDL and Verilog designs, 1326 SDF WIDTH
specification with the GUI, 1310 matching to Verilog constructs, 1321
troubleshooting, 1328 Search
Verilog prefill text entry field, 1240

1904 ModelSim® SE User's Manual, v10.7

 stop, 694 in Schematic window, 884
Search rules in Wave window, 885
libraries, 184 multiple drivers, 881
searching set report destination, 866
Expression Builder, 695 setting preferences
Verilog libraries, 510 Preferences
searchlog command causality traceback, 888
expanded time, 688 trace cursor, 872
seeding random number generator, 1140 Show driver, 875
seetime command Show drivers
expanded time, 689 control bar, 871, 876
sensitivity list warning, 1749 show drivers
SeparateConfigLibrary .ini file variable, 1602 Dataflow window, 814
SETUP Wave window, 735
matching to Verilog, 1320 Show drivers/readers
SETUPHOLD schematic, 773
matching to Verilog, 1320 Show root cause, 877
Severity Show_BadOptionWarning .ini file variable,
break on assertions, 1398 1603
severity Show_Lint .ini file variable, 1604
break on assertion, 1018 Show_PslChecksWarnings .ini file variable,
severity, changing level for errors, 1743 1605
SFCU, 254 Show_source .ini file variable, 1606
Share Show_VitalChecksWarning .ini file variable,
user-defined types, 512 1607
shared library Show_Warning1 .ini file variable, 1608
building in SystemC, 412 Show_Warning2 .ini file variable, 1609
shared objects Show_Warning3 .ini file variable, 1610
loading FLI applications Show_Warning4 .ini file variable, 1611
see FLI Reference manual Show_Warning5 .ini file variable, 1612
loading PLI/VPI/DPI C applications, 1818 ShowConstantImm ediateAsserts .ini file
loading PLI/VPI/DPI C++ applications, variable, 1613
1822 ShowFunctions .ini file variable, 1614
loading with global symbol visibility, 1826 ShowUnassociatedScNameWarning .ini file
Show all possible drivers variable, 1615
Drivers ShowUndebuggableScTypeWarning .ini file
show all possible, 879 variable, 1616
Show cause, 863, 868, 870 ShutdownFile .ini file variable, 1617
active driver path details, 787, 872 Signal
from command line, 866 create virtual, 731
from GUI, 869 Virtual Signal Builder, 731
from Objects or Schematic window, 874 signal breakpoints
from Source window, 873 edit, 739
from specific time, 880 signal groups
from Wave window, 870 in wave window, 709

ModelSim® SE User's Manual, v10.7 1905

signal interaction compilers, 457
Verilog and SystemC, 487 libraries, 457
Signal radix resolution limit in, 471
set globally, 706 mixed Verilog and SystemC designs
Signal Segmentation Violations channel and port type mapping, 487
debugging, 275 Verilog port direction, 495
Signal Spy, 218, 1271 Verilog state mapping, 495
disable, 1263 mixed Verilog and VHDL designs
enable, 1265 Verilog parameters, 478
using in PSL assertions, 1054 Verilog state mapping, 479
signal_force, 218, 1276 VHDL and Verilog ports, 478
signal_release, 219, 1278 VHDL generics, 481
SignalForceFunctionUseDefaultRadix .ini file mixed VHDL and SystemC designs
variable, 1618 SystemC state mapping, 502
signals VHDL port direction, 501
combining into a user-defined bus, 728 VHDL port type mapping, 497
Dataflow window, displaying in, 805 VHDL sc_signal data type mapping,
driving in the hierarchy, 1266 498
hierarchy saving dataflow display as a Postscript file,
driving in, 1266 798, 832
referencing in, 218, 1271 saving options in a project, 163
releasing anywhere in, 1278 saving simulations, 647
releasing in, 219, 1278 saving waveform as a Postscript file, 718
transitions, searching for, 690 SystemC, 379, 412
values of usage flow for SystemC only, 384
forcing anywhere in the hierarchy, 218, Verilog, 266
1276 delay modes, 294
saving as binary log file, 647 hazard detection, 274
virtual, 662 optimizing performance, 121, 623
SignalSpyPathSeparator .ini file variable, 1619 resolution limit, 267
SIGSEGV XL compatible simulator options, 289
fatal error message, 276 VHDL, 197
SIGSEGV error, 275 VITAL packages, 216
SimulateAssumeDirectives .ini file variable, simulating the design, overview, 67
1620 simulation
SimulateImmedAsserts .ini file variable, 1621 basic steps for, 61
SimulatePSL .ini file variable, 1622 time, current, 1364
SimulateSVA .ini file variable, 1623 Simulation Configuration
simulating creating, 163
batch mode, 69 simulations
command-line mode, 69 event order in, 270
comparing simulations, 647 saving results, 647
default run length, 1397 saving results at intervals, 649
iteration limit, 1397 Simulator Control Variables
mixed language designs SystemVerilog

1906 ModelSim® SE User's Manual, v10.7

 SVAPrintOnlyUserMessage, 1651 SolveRev .ini file variable, 1637
UndefSyms, 1696 SolveTimeout .ini file variable, 1638
simulator resolution Source annotation
mixed designs, 471 Annotation, 840
returning as a real, 217 source annotation, 840
SystemC, 412 source code mismatches
Verilog, 267 bypassing warning, 1170
VHDL, 203 Source code pragmas, 969
simulator state variables, 1364 source code pragmas, 950
simulator, difference from OSCI, 439 source code, security, 111, 328
Simultaneous behavior source files
of FSM pragmas, 972 Debug, 840
of toggle pragmas, 966 source files, referencing with location maps,
single file compilation unit (SFCU), 254 1738
sizetf callback function, 1831 source files, specifying with location maps,
SKEW 1738
matching to Verilog, 1321 source libraries
sm_entity, 1860 arguments supporting, 256
SmartDbgSym .ini file variable, 1624 Source window, 835
SmartModels clear highlights, 845
creating foreign architectures with Run Until Here, 860
sm_entity, 1860 show drivers control bar, 871, 876
invoking SmartModel specific commands, source-level debug
1864 SystemC, enabling, 418
linking to, 1859 sparse memory modeling, 332
lmcwin commands, 1865 SparseMemThreshhold .ini file variable, 1639
memory arrays, 1867 specify path delays
Verilog interface, 1867 matching to DEVICE construct, 1320
VHDL interface, 1859 matching to GLOBALPATHPULSE
so, shared object file construct, 1319
loading PLI/VPI/DPI C applications, 1818 matching to IOPATH statements, 1319
loading PLI/VPI/DPI C++ applications, matching to PATHPULSE construct, 1319
1822 Sprout limit
SolveACTMaxOps .ini file variable, 1625 readers in dataflow, 816
SolveACTMaxTests .ini file variable, 1626 Stability
SolveACTRetryCount .ini file variable, 1627 across versions, 1139
SolveArrayResizeMax .ini file variable, 1628 StackTraceDepth .ini file variable, 1640
SolveEngine .ini file variable, 1630 Standard Delay Format (SDF), 148, 200
SolveFailDebug .ini file variable, 1631 standards supported, 77
SolveFailDebugMaxSet .ini file variable, 1632 start_of_simulation() function, 445
SolveFailSeverity .ini file variable, 1633 Startup
SolveGraphMaxEval .ini file variable, 1634 DO file in the modelsim.ini file, 1641
SolveGraphMaxSize .ini file variable, 1635 startup
SolveIgnoreOverflow .ini file variable, 1636 DO files, 1734
solver failures, 1138 files accessed during, 1845

ModelSim® SE User's Manual, v10.7 1907

 scripts, 1734 -sv_seed, 1140
startup macro in command-line mode, 70 Sv_Seed .ini variable, 1649
using a startup file, 1734 sv_std .ini file variable, 1650
Startup .ini file variable, 1641 SVA
State machines viewing in Wave window, 1034
view current state, 996 SVAPrintOnlyUserMessage .ini file variable,
state variables, 1364 1651
statement coverage SVCovergroupGetInstCoverageDefault .ini
count for "for" loops, 909 file variable, 1652
statistical sampling profiler, 1229 SVCovergroupGoal .ini file variable, 1653
statistics, toggle SVCovergroupGoalDefault .ini file variable,
confusing, 937 1654
Status field SVCovergroupMergeInstancesDefault .ini file
Project tab, 162 variable, 1655
std .ini file variable, 1644 SVCovergroupPerInstanceDefault .ini file
std_arith package variable, 1656
disabling warning messages, 1735 SVCovergroupSampleInfo .ini file variable,
std_developerskit .ini file variable, 1645 1657
STD_INPUT, 210 SVCovergroupStrobe .ini file variable, 1658
std_logic_arith package, 188 SVCovergroupStrobeDefault .ini file variable,
std_logic_signed package, 188 1659
std_logic_textio, 188 SVCovergroupTypeGoal .ini file variable,
std_logic_unsigned package, 188 1660
STD_OUTPUT, 210 SVCovergroupTypeGoalDefault .ini file
StdArithNoWarnings .ini file variable, 1646 variable, 1661
STDOUT environment variable, 1853 SVCovergroupZWNoCollectl .ini file variable,
steps for simulation, overview, 61 1662
Sticky note SVCoverpointAutoBinMax .ini file variable,
schematic window, 790 1663
Stimulus SVCoverpointExprVariablePrefix .ini file
constrained random, 1129 variable, 1664
stimulus SVCoverpointWildCardBinValueSizeWarn
modifying for elaboration file, 563 .ini file variable, 1665
Stop wave drawing, 694 SVCrossNumPrintMissing .ini file variable,
stripping levels in UCDB, 1172 1666
struct of sc_signal, 425 SVCrossNumPrintMissingDefault .ini file
structure, 550 variable, 1667
subprogram inlining, 196 SVFileExtensions .ini file variable, 1671
subprogram write is ambiguous error, fixing, Svlog .ini file variable, 1672
211 SVPrettyPrintFlags .ini file variable, 1673
substreams symbol mapping
definition of, 569 Dataflow window, 793, 826
suppress .ini file variable, 1647 symbolic link to design libraries (UNIX), 182
SuppressFileTypeReg .ini file variable, 1648 Symmetric encryption, 114
suspsended thread, 1214 Sync active cursors, 676

1908 ModelSim® SE User's Manual, v10.7

SyncCompilerFiles .ini file variable, 1676 generic support, instantiating VHDL, 532
Synopsis hardware modeler, 1869 hierarchical references in mixed designs,
synopsys .ini file variable, 1675 473
Synopsys libraries, 188 instantiation criteria in Verilog design, 526
synthesis instantiation criteria in VHDL design, 537
rule compliance checking, 1463, 1484 linking the compiled source, 411
Synthesizable, 761 maintaining design portability, 397
System calls mapping states in mixed designs, 502
VCD, 1340 VHDL, 502
system calls memories, viewing, 427
SystemVerilog observe function, 473
system tasks and functions, 299 parameter support, Verilog instances, 520
system commands, 1362 prim channel aggregates, 425
System functions reducing non-debug compile time, 396
$coverage_save, 307 replacing sc_start(), 436
System tasks sc_clock(), moving to SC_CTOR, 436
proprietary, 309 sc_fifo, 427
VCD, 1340 sc_signal(), moving to SC_CTOR, 436
system tasks signals, viewing global and static, 425
Verilog-XL compatible, 321 simulating, 412
System tasks and functions source code, modifying for vsim, 436
SystemVerilog, 299 stack space for threads, 450
SystemC state-based code, initializing and cleanup,
aggregates of signals/ports, 425 412
calling member import functions in SC troubleshooting, 450
scope, 546 unsupported features, 443
cin support, 441 unsupported functions, 440
compiling for source level debug, 396 user defined signals and ports, viewable,
compiling optimized code, 396 417
component declaration for instantiation, viewable objects, 417
538 viewable types, 416
construction parameters, 446 viewable/debuggable objects, 417
constructor/destructor breakpoints, 421 viewing FIFOs, 427
control function, 473 virtual functions, 414
converting sc_main(), 436 SystemC binding
converting sc_main() to a module, 436 to Verilog/SV design unit, 391, 460, 1013
debugging of channels and variables, 431 SystemC modules
declaring/calling member import functions exporting for use in Verilog, 526
in SV, 546 exporting for use in VHDL, 539
dynamic module array, 426 SystemVerilog
experimental features, 444 assertions, 1008
exporting sc_main, example, 437 concurrent, 1008
exporting top level module, 395 immediate, 1008
fixed-point types, 446 reporting, 1044
foreign module declaration, 519 class debugging, 339

ModelSim® SE User's Manual, v10.7 1909

 configuring assertions, 1014 substitution, 1362
set actions, 1020 VSIM Tcl commands, 1368
set fail limits, 1019 with escaped identifiers, 291
configuring cover directives Tcl_init error message, 1749
AtLeast counts, 1023 temp files, VSOUT, 1856
limiting, 1024 template arguments
weighting, 1023 passing integer generics as, 534
cover directives passing integer parameters as, 523
count mode, 1039 terminology
hierarchical references, 472 for expanded time, 680
keyword considerations, 247 test data records, unique, 1169
multi-file compilation, 254 test-associated merge, 1175
object handle testbench
initialize with new function, 275 automating, 1129
random number generator, 1140 text and command syntax, 79
randomize, 1132 Text report
system functions functional coverage, 1110
$coverage save, 307 TEXTIO
virtual interface, 725 buffer, flushing, 213
SystemVerilog bind TextIO package
limitations for SystemC, 391, 470 alternative I/O files, 213
SystemVerilog classes containing hexadecimal numbers, 212
call command, 361 dangling pointers, 212
Class Instnaces Window, 348 ENDFILE function, 213
classinfo command, 363 ENDLINE function, 212
conditional breakpoints, 357 file declaration, 209
constrained random tests, 1131 implementation issues, 210
view in Wave window, 342, 350, 722 providing stimulus, 213
SystemVerilog DPI standard input, 210
specifying the DPI file to load, 1825 standard output, 210
SystemVerilog math functions WRITE procedure, 211
$clog2, 307 WRITE_STRING procedure, 212
SystemVerilog tasks&functions TF routines, 1837
$typename data query, 304 TFMPC
SystemVerilog types explanation, 1750
radix, 705 thread
debugging, 1214
—T— thread viewer pane, 1079
Tcl atv window, 1079
command separator, 1360 understanding time, 1080
command substitution, 1360 threads
command syntax, 1355 assertions, 1073
evaluation order, 1361 cover directives, 1073
relational expression evaluation, 1361 time
time commands, 1369
variable

1910 ModelSim® SE User's Manual, v10.7

 current simulation time as a simulator Toggle coverage
statevariable, 1364 excluding node transitions, 965
measuring in Wave window, 675 excluding nodes, 965
resolution in SystemC, 412 toggle coverage, 928
time resolution as a simulator state 2-state, 928
variable, 1365 3-state, 928
truncated values, 269, 412, 1369 count limit, 1677
time collapsing, 660 deglitch period, 1678
Time mode switching excluding bus bits, 965
expanded time, 687 excluding enum signals, 967
time resolution extended and regular, coverage
in mixed designs, 471 computation, 935
in Verilog, 267 limiting, 940
in VHDL, 203 max VHDL integer values, 1679, 1680,
Time stamps 1681
func coverage, 1112 port collapsing, 986
time type reporting, duplication of elements, 987
converting to real, 219 reporting, ordering of nodes, 987
in mixed designs, 481 Verilog/SV supported data types, 930
time unit viewing in Signals window, 928
in SystemC, 412 toggle coverage, and performance, 929
timeline Toggle node transitions
display clock cycles, 701 exlcude from coverage, 965
timescale directive warning toggle numbers, confusing, 937
investigating, 267 toggle reporting
Timestamp aliases and mixed-language boundary, 936
func coverage reports, 1112 toggle, extended
timing conversion of, 934
differences shown by comparison, 756 ToggleCountLimit .ini file variable, 1677
disabling checks, 1326 ToggleDeglitchPeriod .ini file variable, 1678
in optimized designs, 150 ToggleFixedSizeArray .ini file variable, 1679
Timing checks ToggleMaxFixedSizeArray .ini file variable,
delay solution convergence, 284 1680
negative ToggleMaxIntValues .ini file variable, 1681
constraint algorithm, 284 ToggleMaxRealValues .ini file variable, 1682
syntax for $recrem, 282 ToggleNoIntegers .ini file variable, 1683
syntax for $setuphold, 280 TogglePackedAsVec .ini file variable, 1684
using delayed inputs for checks, 288 TogglePortsOnly .ini file variable, 1685
negative check limits, 279 ToggleVHDLRecords .ini file variable, 1686
TMPDIR environment variable, 1854 ToggleVlogEnumBits .ini file variable, 1687
to_real VHDL function, 219 ToggleVlogIntegers .ini file variable, 1688
to_time VHDL function, 220 ToggleVlogReal .ini file variable, 1689
Toggle add ToggleWidthLimit .ini file variable, 1690
override +cover=tx, 939 tolerance
toggle counts, understanding, 934 leading edge, 756

ModelSim® SE User's Manual, v10.7 1911

 trailing edge, 756 TranscriptFile .ini file variable, 1691
too few port connections, explanation, 1750 Transitive Cross Exclusion, 1118
tool structure, 59 troubleshooting
Toolbar buttons DPI, missing import funtion, 1804
event traceback, 869 multiple test data records, 1169
Tooltip SystemC, 450
schematic, 769 unexplained behaviors, SystemC, 450
trace cursor, 872 TSSI
Tracing in VCD files, 1346
causality, 863, 872 type
active driver path details, 787, 872 converting real to time, 220
create database, 863 converting time to real, 219
from command line, 866 Type field, Project tab, 162
from GU, 869 type-based coverage
from Objects or Schematic window, constructor parameters, 1101
874 Types
from Source window, 873 sharing user-defined, 512
from specific time, 880 types
from Wave window, 870 virtual, 664
multiple drivers, 881 types, fixed-point in SystemC, 441
post-sim debug, 868 types, viewable SystemC, 416
set report destination, 866
setting preferences, 888 —U—
to all possible drivers, 879 UCDB, 1144
to driving process, 875 automatic saving of, 1154
to first seq process, 870 controlling optimization, 1092
to root cause, 877 editing, 1172
viewing path details loading into current simulation
in Schematic window, 884 $load_coverage_db() function, 1126
in Wave window, 885 modifying contents, 1172
events stripping and adding levels, 1172
schematic, 781 UCDB filtering, 1203
tracing UCDBFilename .ini file variable, 1692
events, 820 UCDBTestStatusMessageFilter .ini file
source of unknown, 787, 821 variable, 1693
transaction UDP, 184, 186, 247, 250, 263, 266, 294
definition of, 568 user defined primitive, 252
transaction handles and memory leaks, 596 UnattemptedImmediateAssertions .ini file
transactions variable, 1694
CLI commands for debugging, 611 UnbufferedOutput .ini file variable, 1695
parallel, 569 unclocked
phase, 569 assertion properties, 1056
transcript undefined symbol, error, 450
disable file creation, 1734 UndefSyms .ini file variable, 1696
file name, specifed in modelsim.ini, 1733 unexplained behavior during simulation, 450
unexplained simulation behavior, 450

1912 ModelSim® SE User's Manual, v10.7

unfolded instance resolution, 1364
schematic, 777 simulation time, 1364
ungrouping values of
in wave window, 713 saving as binary log file, 647
unit delay mode, 297 VCD files
unknowns, tracing, 787, 821 capturing port driver data, 1346
unnamed designs, 125 case sensitivity, 1335
unnamed ports, in mixed designs, 507 creating, 1334
unsupported functions in SystemC, 440 dumpports tasks, 1340
UpCase .ini file variable, 1697 exporting created waveforms, 1305
usage models from VHDL source to VCD output, 1343
encrypting IP code, 95 stimulus, using as, 1336
vencrypt utility, 95 supported TSSI states, 1346
use clause, specifying a library, 187 translate into WLF, 1346
use flow VCD system tasks, 1340
Code Coverage, 895 VCD values
DPI, 1801 resolving, 1348
SystemC-only designs, 384 when force cmd used, 1348
user-defined bus, 662, 728 vcd2wlf command, 1346
user-defined primitive (UDP), 184, 186, 247, vencrypt command
250, 263, 266, 294 header file, 97, 102
User-defined types Verification
sharing, 512 with constrained random stimulus, 1129
UserTimeUnit .ini file variable, 1698 Verilog
UseScv .ini file variable, 1699 ACC routines, 1834
UseSVCrossNumPrintMissing .ini file approximating metastability, 297
variable, 1700 capturing port driver data with -dumpports,
util package, 217 1346
UVM-Aware debug case sensitivity, 247, 457
UVMControl .ini file variable, 1702 cell libraries, 293
UVMControl .ini file variable, 1702 compiler directives, 327
compiling and linking PLI C applications,
—V— 1818
variables compiling and linking PLI C++
editing,, 1393 applications, 1822
environment, 1848 compiling design units, 246
expanding environment variables, 1848 compiling with XL ’uselib compiler
LM_LICENSE_FILE, 1851 directive, 257
modelsim.ini, 1400 component declaration, 505
reading from the .ini file, 1365 configuration support, 518
setting environment variables, 1849 configurations, 260
setting for the ini file, 1366 DPI access routines, 1840
simulator state variables event order in simulation, 270
iteration number, 1364 extended system tasks, 323
name of entity or module as a variable, force and release, 289
1364

ModelSim® SE User's Manual, v10.7 1913

 generate statements, 262 Verilog/SV supported data types
instantiation criteria in mixed-language for toggle coverage, 930
design, 504 Verilog-XL
instantiation criteria in SystemC design, compatibility with, 241, 1090
518 Veriuser .ini file variable, 1704, 1797
instantiation of VHDL design units, 509 Veriuser, specifying PLI applications, 1797
mapping states in mixed designs, 479 veriuser.c file, 1832
mapping states in SystemC designs, 495 Version compaitbility
parameter support, instantiating SystemC, constraint solver, 1139
526 Version compatibility
parameters, 478 constraint solver, 1139
port direction, 495 VHDL
resource libraries, 184 .ini compiler control variables
sdf_annotate system task, 1317 ShowConstantImmediateAsserts, 1613
simulating, 266 access type, 232
delay modes, 294 binding
XL compatible options, 289 disabling, 205, 1588
simulation hazard detection, 274 RequireConfigForAllDefaultBinding
simulation resolution limit, 267 .ini variable, 205, 1588
SmartModel interface, 1867 binding to Verilog/SV design unit, 460,
standards, 77 1013
system tasks and functions, 299 case sensitivity, 193, 457
TF routines, 1837 compile, 192
to SystemC, channel and port type compiling design units, 192
mapping, 487 constants, 513
XL compatible compiler options, 256 creating a design library, 192
XL compatible routines, 1840 debugging access objects, 232
XL compatible system tasks, 321 delay file opening, 1736
verilog .ini file variable, 1703 dependency checking, 193
Verilog 2001 encryption, 101
disabling support, 1709 file opening delay, 1736
Verilog PLI/VP/DPII foreign language interface, 203
registering VPI applications, 1797 hardware model interface, 1869
Verilog PLI/VPI instantiation criteria in SystemC design,
64-bit support in the PLI, 1840 530
debugging PLI/VPI code, 1841 instantiation from Verilog, 509
Verilog PLI/VPI/DPI instantiation of Verilog, 476
compiling and linking PLI/VPI C++ language versions, 199
applications, 1822 library clause, 187
compiling and linking PLI/VPI/CPI C logging access objects, 232
applications, 1818 object support in PLI, 1832
PLI callback reason argument, 1829 optimizations
PLI support for VHDL objects, 1832 inlining, 196
registering PLI applications, 1796 port direction, 501
specifying the PLI/VPI file to load, 1825 port type mapping, 497

1914 ModelSim® SE User's Manual, v10.7

 resource libraries, 187 virtual save command, 663
sc_signal data type mapping, 498 Virtual signal
simulating, 197 create, 731
SmartModel interface, 1859 Virtual Signal Builder, 731
standards, 77 virtual signal command, 663
timing check disabling, 197 virtual signals
variables reconstruct RTL-level design busses, 663
logging, 1707 reconstruct the original RTL hierarchy, 663
viewing, 1707 virtual hide command, 663
VITAL package, 188 visibility
VHDL utilities, 217, 218, 1271 column in structure tab, 657
get_resolution(), 217 design object and +acc, 147
to_real(), 219 design object and vopt, 121
to_time(), 220 of declarations in $unit, 254
VHDL-1987, compilation problems, 199 VITAL, 200
VHDL-1993 compiling and simulating with accelerated
enabling support for, 1705 VITAL packages, 216
VHDL-2002 compliance warnings, 215
enabling support for, 1705 disabling optimizations for debugging, 216
VHDL-2008 specification and source code, 214
package STANDARD VITAL packages, 215
REAL_VECTOR, 1521 vital2000 .ini file variable, 1708
VHDL93 .ini file variable, 1705 vl_logic, 1349
VhdlSeparatePduPackage .ini file variable, vlog command
1706 +protect argument, 98, 111
VhdlVariableLogging .ini file variable, 1707 vlog95compat, 1709
view assertion failures, 1072 vlog95compat .ini file variable, 1709
viewing Vopt
library contents, 178 suppress warning messages, 1745
waveforms, 647 vopt
viewing FIFOs, 427 and breakpoints, 132
Views vopt command, 121, 623
schematic, 766 Vopt Control Variables
virtual compare signal, restrictions, 728 ParallelJobs, 1577
virtual functions in SystemC, 414 VPI, registering applications, 1797
virtual hide command, 663 VPI/PLI, 337
virtual interface, 725 VPI/PLI/DPI, 1793
virtual objects, 662 compiling and linking C applications, 1818
virtual functions, 663 compiling and linking C++ applications,
virtual regions, 664 1822
virtual signals, 662 VSIM license lost, 1751
virtual types, 664 VSIM prompt, returning to, 1573
virtual region command, 664 vsim, differences with OSCI simulator, 439
virtual regions VSOUT temp file, 1856
reconstruct RTL hierarchy, 664

ModelSim® SE User's Manual, v10.7 1915

—W— cursor linking, 676
WarnConstantChange .ini file variable, 1710 customizing for expanded time, 685
warning .ini file variable, 1711 expanded time viewing, 680, 682
warning #6820, 1170 in the Dataflow window, 780, 818
warning 6820, 1170 saving layout, 716
warning message see alsowindows, Wave window
6846, 1169 show causality, 885
warnings sync active cursors, 676
disabling at time 0, 1735 timeline
empty port name, 1748 display clock cycles, 701
exit codes, 1746 values column, 757
getting more information, 1743 view SV class objects, 342, 722
messages, long description, 1743 virtual interfaces, 725
metavalue detected, 1749 Virtual Signal Builder, 731
multiple test data records, 1169 Waveform Compare
severity level, changing, 1743 adding clocks, 752
suppressing VCOM warning messages, adding regions, 751
1744 adding signals, 751
suppressing VLOG warning messages, annotating differences, 757
1745 clocked comparison, 753, 754
suppressing VOPT warning messages, compare by region, 751
1745 compare by signal, 751
suppressing VSIM warning messages, compare options, 754
1746 compare tab, 750
Tcl initialization error 2, 1749 comparison commands, 747
too few port connections, 1750 comparison method, 753
turning off warnings from arithmetic differences in text format, 758
packages, 1734 flattened designs, 759
waiting for lock, 1748 hierarchical designs, 759
Wave drawing icons, 757
stop, 694 initiating with GUI, 749
wave groups, 709 introduction, 744
add items to existing, 713 leading edge tolerance, 756
creating, 710 list window display, 758
deleting, 713 mixed-language support, 744
drag from Wave to List, 714 pathnames, 756
drag from Wave to Transcript, 714 reference dataset, 749
removing items from existing, 713 reference region, 751
ungrouping, 713 saving and reloading, 759
Wave Log Format (WLF) file, 647 setup options, 746
wave log format (WLF) file signals with different names, 747
see alsoWLF files test dataset, 749
wave viewer, Dataflow window, 780, 818 timing differences, 756
Wave window, 667 trailing edge tolerance, 756
compare waveforms, 756 using comparison wizard, 746

1916 ModelSim® SE User's Manual, v10.7

 using the GUI, 747 saving memories to, 651
values column, 757 WLF file parameters
wave window display, 756 cache size, 653
Waveform Comparison collapse mode, 653
created waveforms, using with, 1307 compression, 653
difference markers, 756 delete on quit, 653
waveform editor filename, 653
editing waveforms, 1300 indexing, 653
mapping signals, 1306 optimization, 653
saving stimulus files, 1305 overview, 652
simulating, 1304 size limit, 653
Waveform Compare, using with, 1307 WLF files
waveform logfile collapsing events, 660
overview, 647 optimizing waveform viewing, 1722
see alsoWLF files saving, 649
waveforms, 647 saving at intervals, 649
optimize viewing of, 1722 WLFCacheSize .ini file variable, 1716
saving between cursors, 720 WLFCollapseMode .ini file variable, 1717
WaveSignalNameWidth .ini file variable, 1712 WLFCompress .ini variable, 1718
White box testing WLFDeleteOnQuit .ini variable, 1719
functional coverage, 1089 WLFFileLock .ini file variable, 1720
WIDTH WLFFilename .ini file variable, 1721
matching to Verilog, 1321 WLFOptimize .ini file variable, 1722
WildcardFilter .ini file variable, 1713 WLFSaveAllRegions .ini file variable, 1723
WildcardSizeThreshold .ini file variable, 1714 WLFSimCacheSize .ini variable, 1724
WildcardSizeThresholdVerbose .ini file WLFSizeLimit .ini variable, 1725
variable, 1715 WLFTimeLimit .ini variable, 1726
Window format WLFUpdateInterval .ini variable, 1727
saving/restoring, 718 WLFUseThreads .ini file variable, 1728
windows work library, 176
Dataflow window, 805 creating, 176
zooming, 801 write format restart, 718, 743
Source window, 835 WRITE procedure, problems with, 211
Run Until Here, 860
Wave window, 667 —X—
adding HDL items to, 669 X
cursor measurements, 675 tracing unknowns, 787, 821
display preferences, 700 xml format
display range (zoom), changing, 690 coverage reports, 988
format file, saving, 716 —Z—
path elements, changing, 1712 zero delay elements, 205
time cursors, 675 zero delay mode, 297
zooming, 690 zero-delay error, 1751
WLF file zero-delay loop, infinite, 207
limiting, 654 zero-delay oscillation, 207

ModelSim® SE User's Manual, v10.7 1917

zero-delay race condition, 270
zoom
Dataflow window, 801
saving range with bookmarks, 691

1918 ModelSim® SE User's Manual, v10.7

 Third-Party Information
This section provides information on third-party software that may be included in this product, including any additional
license terms.

• Third-Party Software for Questa and ModelSim Products

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula

IMPORTANT INFORMATION

USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.

1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.

1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.

3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.

3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.

3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.

4. RESTRICTIONS ON USE.

4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.

4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.

4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.

4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.

4.5. The provisions of this Section 4 shall survive the termination of this Agreement.

5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.

6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
 (including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.

7. LIMITED WARRANTY.

7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”

7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.

9. THIRD PARTY CLAIMS.

9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.

9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.

9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.

10. INFRINGEMENT.

10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.

10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.

10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.

10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
 SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.

11. TERMINATION AND EFFECT OF TERMINATION.

11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.

11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.

12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.

13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.

14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.

15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.

16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.

17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.

18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.

Rev. 170330, Part No. 270941