SIEMENS EDA

Questa® SIM User's

Manual
Including Support for
Questa Base
Software Version 2023.4
Document Revision 8.4
Unpublished work. © 2023 Siemens

This Documentation contains trade secrets or otherwise confidential information owned by Siemens Industry
Software Inc. or its affiliates (collectively, “Siemens”), or its licensors. Access to and use of this Documentation is
strictly limited as set forth in Customer’s applicable agreement(s) with Siemens. This Documentation may not be
copied, distributed, or otherwise disclosed by Customer without the express written permission of Siemens, and may
not be used in any way not expressly authorized by Siemens.

This Documentation is for information and instruction purposes. Siemens reserves the right to make changes in
specifications and other information contained in this Documentation without prior notice, and the reader should, in
all cases, consult Siemens to determine whether any changes have been made.

No representation or other affirmation of fact contained in this Documentation shall be deemed to be a warranty or
give rise to any liability of Siemens whatsoever.

If you have a signed license agreement with Siemens for the product with which this Documentation will be used,
your use of this Documentation is subject to the scope of license and the software protection and security provisions
of that agreement. If you do not have such a signed license agreement, your use is subject to the Siemens Universal
Customer Agreement, which may be viewed at https://www.sw.siemens.com/en-US/sw-terms/base/uca/, as
supplemented by the product specific terms which may be viewed at https://www.sw.siemens.com/en-US/sw-
terms/supplements/.

SIEMENS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS DOCUMENTATION INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. SIEMENS SHALL NOT BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, LOST DATA OR
PROFITS, EVEN IF SUCH DAMAGES WERE FORESEEABLE, ARISING OUT OF OR RELATED TO THIS
DOCUMENTATION OR THE INFORMATION CONTAINED IN IT, EVEN IF SIEMENS HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

TRADEMARKS: The trademarks, logos, and service marks (collectively, "Marks") used herein are the property of
Siemens or other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the
owner of the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a
source of a product, but is intended to indicate a product from, or associated with, a particular third party. A list of
Siemens' Marks may be viewed at: www.plm.automation.siemens.com/global/en/legal/trademarks.html. 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.

About Siemens Digital Industries Software

Siemens Digital Industries Software is a global leader in the growing field of product lifecycle management (PLM),
manufacturing operations management (MOM), and electronic design automation (EDA) software, hardware, and
services. Siemens works with more than 100,000 customers, leading the digitalization of their planning and
manufacturing processes. At Siemens Digital Industries Software, we blur the boundaries between industry domains
by integrating the virtual and physical, hardware and software, design and manufacturing worlds. With the rapid
pace of innovation, digitalization is no longer tomorrow’s idea. We take what the future promises tomorrow and make
it real for our customers today. Where today meets tomorrow. Our culture encourages creativity, welcomes fresh
thinking and focuses on growth, so our people, our business, and our customers can achieve their full potential.

Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
 Revision History ISO-26262

Revision Changes Status/

Date
8.4 Modifications to improve the readability and Released
comprehension of the content. Approved by Matt Laney. October 2023
All technical enhancements, changes, and fixes listed in
the Release Notes are reflected in this document.
Approved by Tim Peeke.
8.3 Modifications to improve the readability and Released
comprehension of the content. Approved by Matt Laney. July 2023
All technical enhancements, changes, and fixes listed in
the Release Notes are reflected in this document.
Approved by Tim Peeke.
8.2 Modifications to improve the readability and Released
comprehension of the content. Approved by Matt Laney. April 2023
All technical enhancements, changes, and fixes listed in
the Release Notes are reflected in this document.
Approved by Tim Peeke.
8.1 Modifications to improve the readability and Released
comprehension of the content. Approved by Matt Laney. March 2023
All technical enhancements, changes, and fixes listed in
the Release Notes are reflected in this document.
Approved by Tim Peeke.

Author: In-house procedures and working practices require multiple authors for documents. All
associated authors for each topic within this document are tracked within the Siemens
documentation source. For specific topic authors, contact the Siemens Digital Industries
Software documentation department.

Revision History: Released documents include a revision history of up to four revisions. For
earlier revision history, refer to earlier releases of documentation on Support Center.

Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
4 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Table of Contents

Revision History ISO-26262

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

Chapter 2
Optimizing Designs with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Questa Dumping and Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Three-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The -O Optimization Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Inlined Modules and the Implications of Coverage Settings . . . . . . . . . . . . . . . . . . . . . . . 94

Questa® SIM User's Manual, v2023.4 5

 Table of Contents

Preservation of Object Visibility for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Conflicts in Accessibility When Using Both +acc and +noacc . . . . . . . . . . . . . . . . . . . . . 96
Negation Arguments and Resolution with vopt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Priorities for Resolving Conflicting Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Using an External File to Control Visibility Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Creating Specialized Designs for Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . 99
Increase Visibility to Retain Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Optimization of Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Preoptimizing Regions of Your Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Simulating Designs with Multiple Test Benches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Extracting Visibility Requirements for PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Using Configurations with Preoptimized Verilog Design Units . . . . . . . . . . . . . . . . . . . . 105
Using Configurations with Preoptimized VHDL Design Units . . . . . . . . . . . . . . . . . . . . . 107
Resolving Preoptimized Design Unit Loading Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Alternate Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Creating Locked Libraries for Multiple-User Simulation Environments . . . . . . . . . . . . . . 111
Optimizing Liberty Cell Libraries for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Preserving Design Visibility with the Learn Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Controlling Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Optimization Considerations for Verilog Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Design Object Visibility for Designs with PLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Optimization on Designs Containing SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Reports for Gate-Level Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Optimization of Precompiled Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Event Order and Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Timing Checks in Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Net Connectivity Tracing and VPI Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chapter 3
Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
What are the Benefits of Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Project Conversion Between Simulator Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Getting Started with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Open a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Simulate a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
The Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Creating a Simulation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Organizing Projects with Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Adding a Project Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Set File Properties and Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
File Compilation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6 Questa® SIM User's Manual, v2023.4

Table of Contents

Convert Pathnames to Softnames for Location Mapping. . . . . . . . . . . . . . . . . . . . . . . . . 142

Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Access Projects from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 4
Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
QuestaSIM Library Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Design Unit Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Working Library Versus Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Working with Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Creating a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Library Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Library Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Map a Logical Name to a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Mapping a Library with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Mapping a Library from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Manual Mapping of the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Move a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Setting Up Libraries for Group Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Verilog Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Library Search Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Handling Sub-Modules with the Same Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
The LibrarySearchPath Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
VHDL Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Predefined Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Alternate IEEE Libraries Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Regenerating Your Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Importing FPGA Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Protecting Your Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Chapter 5
VHDL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Basic VHDL Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Compilation and Simulation of VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Creating a Design Library for VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Compilation of a VHDL Design—the vcom Command . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Simulation of a VHDL Design—the vsim Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Usage Characteristics and Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Differences Between Supported Versions of the VHDL Standard. . . . . . . . . . . . . . . . . . . 171
Naming Behavior of VHDL for Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Foreign Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Simulator Resolution Limit for VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Default Binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Delta Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
The TextIO Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Syntax for File Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
STD_INPUT and STD_OUTPUT Within Questa SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
TextIO Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Questa® SIM User's Manual, v2023.4 7

 Table of Contents

Alternative Input/Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

The TEXTIO Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Input Stimulus to a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
VITAL Usage and Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VITAL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VITAL 1995 and 2000 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VITAL Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Compiling and Simulating with Accelerated VITAL Packages . . . . . . . . . . . . . . . . . . . . . 188
Compiler Options for VITAL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
VHDL Utilities Package (util) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Modeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Examples of Different Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Effects on Performance by Canceling Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . 203
VHDL Access Object Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Terminology and Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
VHDL Access Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Default Behavior—Logging and Debugging Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Logging and Debugging Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
The examine and describe Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Chapter 6
Verilog and SystemVerilog Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Standards, Nomenclature, and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Supported Variations in Source Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
for Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Naming Macros with Integers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Basic Verilog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Verilog Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Creating a Working Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Invoking the Verilog Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Verilog Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Parsing SystemVerilog Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Recognizing SystemVerilog Files by File Name Extension . . . . . . . . . . . . . . . . . . . . . . 220
Initializing enum Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Library Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
SystemVerilog Multi-File Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Declarations in Compilation Unit Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Macro Definitions and Compiler Directives in Compilation Unit Scope . . . . . . . . . . . . 226
Verilog-XL Compatible Compiler Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Arguments Supporting Source Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Verilog-XL uselib Compiler Directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Verilog Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Configurations and the Library Named work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Verilog Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Name Visibility in Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Initializing Registers and Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

8 Questa® SIM User's Manual, v2023.4

Table of Contents

Initialization Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Initializing with Specific Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 236
Initializing with Specific Values — Enabled During Optimization. . . . . . . . . . . . . . . . . 236
Initializing with Random Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 237
Initializing with Random Values — Enabled During Optimization . . . . . . . . . . . . . . . . 237
Recording Initialization Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Verilog Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Simulator Resolution Limit (Verilog). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Modules Without Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Multiple Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Choosing the Resolution for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Event Ordering in Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Event Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Controlling Event Queues with Blocking or Non-Blocking Assignments. . . . . . . . . . . . 245
Debugging Event Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Hazard Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Hazard Detection and Optimization Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Signal Segmentation Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
vsim Arguments Related to Timing Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Commands Supporting Negative Timing Check Limits . . . . . . . . . . . . . . . . . . . . . . . . . 252
Negative Timing Constraint Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Using Delayed Inputs for Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Re-evaluation of Zero-Delay Output Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Handling Negative Timing Check Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Force and Release Statements in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Verilog-XL Compatible Simulator Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Using Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Tcl and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Cell Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
SDF Timing Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Delay Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Delay Modes and the Verilog Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Distributed Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Path Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Unit Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Zero Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Approximating Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Troubleshooting Zero Delay Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
SystemVerilog System Tasks and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
LRM System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Using the $typename Data Query Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Using the $coverage_* System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Using the $coverage_save System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Using the $clog2 Math Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Simulator-Specific System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
$coverage_save_mti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
$get_initial_random_seed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
$messagelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Questa® SIM User's Manual, v2023.4 9

 Table of Contents

$psprintf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
$sdf_done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
$stacktrace() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
$wlfdumpvars() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Task and Function Names Without Round Braces ‘()’. . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Verilog-XL Compatible System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Supported Tasks and Functions Mentioned in IEEE Std 1364 . . . . . . . . . . . . . . . . . . . . 296
Supported Tasks and Functions Not Described in IEEE Std 1364 . . . . . . . . . . . . . . . . . 296
Extensions to Supported System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Unsupported Verilog-XL System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
String Class Methods for Matching Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IEEE Std 1364 Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Compiler Directives for vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Verilog-XL Compatible Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Digital Mixed-Signal for Verilog and SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
AMS Standards and Nomenclature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Connectivity Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Real-valued Nets in Verilog (wreal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Resolution Functions for wreal Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Sparse Memory Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Manually Marking Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Automatically Enabling Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Combining Automatic and Manual Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Priority of Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Determining Which Memories Were Implemented as Sparse . . . . . . . . . . . . . . . . . . . . . . 325
Initializing Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Limitations of Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Unmatched Virtual Interface Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Verilog PLI and SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Standards, Nomenclature, and Conventions for VPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Extensions to SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
SystemVerilog Class Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Enabling Class Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
The Class Instance Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Obtaining the CIID with the examine Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Obtaining the CIID With a System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Logging Class Types and Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Working with Class Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Authoritative and Descriptive Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Finding the Class Type Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Viewing Class Types in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Working with Class Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
The Class Instances Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Viewing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
The Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
The Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

10 Questa® SIM User's Manual, v2023.4

Table of Contents

The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

The Call Stack Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Working with Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Class Path Expression Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Adding a Class Path Expression to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Class Path Expression Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Casting a Class Variable to a Specific Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Class Objects vs Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Disabling Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Conditional Breakpoints in Dynamic Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Stepping Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
The Run Until Here Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Class Instance Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Class Instance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The classinfo Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Class Instance Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Default Garbage Collector Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Changing the Garbage Collector Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Running the Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Preparing Your Simulation for OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
OVM-Aware Debugging Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Locating Blocking Calls in the OVM Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Finding Matching Get and Set Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
OVM-Aware Debug Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Globals Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Hierarchy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Components Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Sequence Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
UVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Compiling Your Simulation for UVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Simulating With UVM-Aware Debug Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
UVM Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
UVM Component Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Macros and Expanded Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
UVM Streams, Configuration DB Objects, and Sequences . . . . . . . . . . . . . . . . . . . . . . . 375
Processes Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
UVM Message Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
UVM Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Setting UVM Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Setting a Breakpoint on a Specific UVM Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Setting a Breakpoint on a Function Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Setting a Breakpoint With the UVM Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . 382
UVM Backdoor Read/Write with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
UVM Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
UVM Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Autofindloop and the Autofindloop Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Questa® SIM User's Manual, v2023.4 11

 Table of Contents

Chapter 7
SystemC Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Supported Platforms and Compiler Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Building gcc with Custom Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Usage Flow for SystemC-Only Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Recommendations for using sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Simulating with sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Checkpoint and Restore in a SystemC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Creating Shared Object Files for SystemC Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Binding to Verilog or SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Limitations of Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Distributing SystemC IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Compiling SystemC Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Creating a Design Library for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Exporting All Top-Level SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Invoking the SystemC Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Distributed sccom Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Compiling Optimized and/or Debug Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Specifying an Alternate g++ Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Verifying Compiler Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Maintaining Portability Between OSCI and the Simulator . . . . . . . . . . . . . . . . . . . . . . . . 410
Using sccom in Addition to the Standalone C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . . 411
Rules for sccom Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Rules for Standalone g++ Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Incremental Compilation (Compile of Changed Files Only) . . . . . . . . . . . . . . . . . . . . . . . 412
Issues with C++ Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Templatized SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Organizing Templatized Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Generating SystemC Verification Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
SCV Extensions for User-specified Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Structures and Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Mentor Dynamic Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Named Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Constrained Randomization of the Data Type for Standard Vectors . . . . . . . . . . . . . . . . 423
Randomly Sized Fixed-Max Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Linking the Compiled Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Simulation of SystemC Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Debugging the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Viewable SystemC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Waveform Compare with SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Debugging Source-Level Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Setting Constructor/Destructor Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Setting BPs with Cdebug Init Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Setting BPs with Automated Constructor Breakpoint Flow. . . . . . . . . . . . . . . . . . . . . . . 433
Using Instance Based Breakpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Viewing SystemC Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

12 Questa® SIM User's Manual, v2023.4

Table of Contents

SystemC Object and Type Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Support for Globals and Statics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Support for Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
SystemC Dynamic Module Array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Viewing FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Viewing SystemC Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Properly Recognizing Derived Module Class Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Custom Debugging of SystemC Channels and Variables . . . . . . . . . . . . . . . . . . . . . . . . . 443
Modifying SystemC Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Converting sc_main() to a Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Replacing sc_start() Function with Run Command and Options . . . . . . . . . . . . . . . . . . . . 448
Removing Calls to sc_initialize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Code Modification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Differences Between the Simulator and OSCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
OSCI 2.3.2 Feature Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Support for OSCI TLM Library in SystemC-2.3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Features Not Supported in SystemC-2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Backwards Compatibility Issues with SystemC-2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Troubleshooting SystemC Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Unexplained Behaviors During Loading or Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Errors During Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Chapter 8
Mixed-Language Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Basic Mixed-Language Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Different Compilers with Common Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Hierarchical References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Access Limitations in Mixed-Language Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
The SystemVerilog bind Construct in Mixed-Language Designs . . . . . . . . . . . . . . . . . . . . . 468
Syntax of bind Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Allowed Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Hierarchical References to a VHDL Object from a Verilog/SystemVerilog Scope. . . . . . 470
Mapping of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Optimization with SystemVerilog Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Port Mapping with VHDL and Verilog Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . 472
VHDL Instance Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Limitations to Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Optimizing Mixed Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Simulator Resolution Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Runtime Modeling Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Hierarchical References to SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Hierarchical References In Mixed HDL and SystemC Designs. . . . . . . . . . . . . . . . . . . . . 481
Signal Connections Between Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . . 482
Mapping Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Verilog and SystemVerilog to VHDL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
VHDL To Verilog and SystemVerilog Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings . . . . . . . . . . . 497

Questa® SIM User's Manual, v2023.4 13

 Table of Contents

VHDL and SystemC Signal Interaction and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

VHDL Instantiating Verilog or SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Verilog/SystemVerilog Instantiation Criteria Within VHDL. . . . . . . . . . . . . . . . . . . . . . . 514
Component Declaration for VHDL Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . 514
vgencomp Component Declaration when VHDL Instantiates Verilog . . . . . . . . . . . . . . . 515
Modules with Bidirectional Pass Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Modules with Unnamed Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Verilog or SystemVerilog Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
VHDL Instantiation Criteria Within Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Entity and Architecture Names and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Named Port Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Generic Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Sharing User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Using a Common VHDL Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Using a Common SystemVerilog Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
SystemC Instantiating Verilog or SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Verilog Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
SystemC Foreign Module (Verilog) Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Parameter Support for SystemC Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Verilog or SystemVerilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
SystemC Instantiation Criteria for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Exporting SystemC Modules for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Parameter Support for Verilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
VHDL Instantiation Criteria Within SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
SystemC Foreign Module (VHDL) Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Generic Support for SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
VHDL Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
SystemC Instantiation Criteria for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Component Declaration for VHDL Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . 547
vgencomp Component Declaration when VHDL Instantiates SystemC . . . . . . . . . . . . . . 548
Exporting SystemC Modules for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Passing Generics From VHDL or Verilog Down to SystemC . . . . . . . . . . . . . . . . . . . . . . 549
SystemC Procedural Interface to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
SystemC DPI Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
SystemC Import Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Calling SystemVerilog Export Tasks / Functions from SystemC . . . . . . . . . . . . . . . . . . . 558
SystemC Data Type Support in SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
SystemC Function Prototype Header File (sc_dpiheader.h). . . . . . . . . . . . . . . . . . . . . . . . 561
Support for Multiple SystemVerilog Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
SystemC DPI Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Hierarchical References From Verilog/SystemVerilog to SystemC Objects . . . . . . . . . . . . 563
Port Connections at the SV-VHDL Mixed Language Boundary . . . . . . . . . . . . . . . . . . . . . 569

14 Questa® SIM User's Manual, v2023.4

Table of Contents

Chapter 9
Advanced Simulation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Checkpointing and Restoring Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Checkpoint File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Checkpoint Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Controlling Checkpoint File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
The Difference Between Checkpoint/Restore and Restart . . . . . . . . . . . . . . . . . . . . . . . . . 587
Using Macros with Restart and Checkpoint/Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Checkpointing Foreign C Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Checkpointing a Running Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Simulating with an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Why an Elaboration File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Creating an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Loading an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Modifying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Using PLI or FLI Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
X Propagation in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
RTL X-Optimism Removal by xprop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Controlling X Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
X Propagation Miscellaneous Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
X Propagation Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Limitations and Restrictions on xprop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

Chapter 10
Recording and Viewing Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Transaction Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
What is a Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
About the Source Code for Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
About Transaction Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Viewing Transactions in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Transaction Viewing Commonalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Transaction Objects in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Viewing Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Retroactive Recording and Transaction Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Selecting Transactions or Streams in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . 626
Customizing Transaction Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Customizing Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Customizing Appearance of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Viewing a Transaction in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Viewing a Transaction in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Debugging Transactions with Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Transactions in Designs with Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Transaction Recording Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Transaction Recording Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Names of Streams and Substreams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Stream Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Transaction UIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Attribute Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Questa® SIM User's Manual, v2023.4 15

 Table of Contents

Multiple Uses of the Same Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640

Anonymous Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Relationship in Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
The Life Cycle of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Transaction Handles and Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Transaction Recording Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Recording Transactions in Verilog and VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Verilog Recorded Transaction Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Valid Verilog Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Recording Transactions in SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Initializing SCV and Creating WLF Database Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Transaction Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Recording SCV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
SCV API Code Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
SCV Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
CLI Debugging Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Verilog and VHDL API System Task Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
add_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
add_color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
add_relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
begin_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
create_transaction_stream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
delete_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
end_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
free_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

Chapter 11
Verifying Designs with
Questa Verification IP Library Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
What is Questa Verification IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
What is a Questa Verification IP Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Questa Verification IP Transaction Viewing in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Questa Verification IP Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Arrays in Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Viewing Questa Verification IP Transactions in the Wave Window . . . . . . . . . . . . . . . . . 677
What the Colors Mean in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Appearance of Concurrent Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . 680
Questa Verification IP Arrays in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Color and Questa Verification IP Arrays in Wave Window. . . . . . . . . . . . . . . . . . . . . . . . 682
Viewing Questa Verification IP Transactions in Objects Window . . . . . . . . . . . . . . . . . . 682
Viewing Questa Verification IP Transactions in List Window . . . . . . . . . . . . . . . . . . . . . 684
Questa Verification IP Transaction Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Debugging Using Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Questa Verification IP Transaction Details in Transaction View Window . . . . . . . . . . . . 689
The Transaction View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
The Transaction Stream Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Updating Contents of the Transaction Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

16 Questa® SIM User's Manual, v2023.4

Table of Contents

Chapter 12
Recording Simulation Results With Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Saving a Simulation to a WLF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Saving at Intervals with Dataset Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Saving Memories to the WLF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
WLF File Parameter Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Limiting the WLF File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Opening Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Dataset Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Structure Window Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Managing Multiple Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Managing Multiple Datasets in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Managing Multiple Datasets from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Restricting the Dataset Prefix Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Collapsing Time and Delta Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Virtual Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Virtual Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Virtual Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Virtual Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Virtual Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

Chapter 13
Waveform Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Wave Window Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Objects You Can View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Adding Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Inserting Signals in a Specific Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Adding Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Editing Cursor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Enable Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Additional Mouse Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Expanded Time in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Expanded Time Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 729
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . 731
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Menu Selections for Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Toolbar Selections for Expanded Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Command Selection of Expanded Time Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Questa® SIM User's Manual, v2023.4 17

 Table of Contents

Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Expanding and Collapsing Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Zooming the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Zooming with the Menu, Toolbar and Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Saving Zoom Range and Scroll Position with Bookmarks. . . . . . . . . . . . . . . . . . . . . . . . . 738
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Searching in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Searching for Values or Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Using the Expression Builder for Expression Searches . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Saving an Expression to a Tcl Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Searching for a Particular Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Evaluating Only on Clock Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Filtering the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Formatting the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Setting Wave Window Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Hiding/Showing Path Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Double-Click Behavior in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Setting the Timeline to Count Clock Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Formatting Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Changing Radix (base) for the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Wave Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Creating a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Grouping Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Adding a Group of Contributing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Grouping Signals with the add wave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Grouping Signals with a Keyboard Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Deleting or Ungrouping a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Adding Items to an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Removing Items from an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Composite Signals or Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Creating Composite Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Saving the Window Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Exporting Waveforms from the Wave window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Exporting the Wave Window as a Bitmap Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Saving Waveform Sections for Later Viewing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Saving Waveforms Between Two Cursors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Viewing Saved Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Working With Multiple Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Viewing SystemVerilog Class Objects and Class Path Expressions . . . . . . . . . . . . . . . . . . . 769
Viewing System Verilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Adding Virtual Interface References to the Wave Window. . . . . . . . . . . . . . . . . . . . . . . 773

18 Questa® SIM User's Manual, v2023.4

Table of Contents

Combining Objects into Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

Extracting a Bus Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Using the Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Miscellaneous Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Examining Waveform Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Creating and Managing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Setting Signal Breakpoints with the when Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Setting Signal Breakpoints with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Modifying Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Setting File-Line Breakpoints Using the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Setting File-Line Breakpoints Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Modifying a File-Line Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Waveform Compare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Mixed-Language Waveform Compare Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Using the Comparison Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Comparison Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Comparison Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Setting Up a Comparison with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Reference Dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Test Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Adding Signals, Regions, and Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Adding Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Adding Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Adding Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Continuous Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Viewing Differences in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Annotating Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Compare Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Viewing Differences in Textual Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Saving and Reloading Comparison Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Comparing Hierarchical and Flattened Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

Questa® SIM User's Manual, v2023.4 19

 Table of Contents

Chapter 14
Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Schematic Window Usage Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Live Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Two Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Features of the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Common Tasks for Schematic Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Adding Objects to the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Display a Structural Overview in the Full View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Exploring the Schematic Connectivity of the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Investigating Connectivity Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Limiting the Schematic Display of Readers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Controlling the Schematic Display of Redundant Buffers and Inverters . . . . . . . . . . . . . 821
Tracking Your Path Through the Design with Highlighting . . . . . . . . . . . . . . . . . . . . . . 822
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . 823
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . 833
Finding Objects by Name in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Annotating with Sticky Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Automatically Tracing All Paths Between Two Nets in the Schematic Window . . . . . . . 837
Symbol Mapping in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Schematic Window Graphic Interface FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
What Can I View in the Schematic Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 843
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
How do I Configure Schematic Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

Chapter 15
Debugging with the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Dataflow Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Dataflow Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Live Simulation Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Post-Simulation Debug Flow Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Create the Post-Sim Debug Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Use the Post-Simulation Debug Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Common Tasks for Dataflow Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Add Objects to the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Exploring the Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Analyzing a Scalar Connected to a Wide Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Control the Display of Readers and Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Controlling the Display of Redundant Buffers and Inverters. . . . . . . . . . . . . . . . . . . . . . 863

20 Questa® SIM User's Manual, v2023.4

Table of Contents

Track Your Path Through the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863

Explore Designs with the Embedded Wave Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Tracing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Tracing the Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Finding Objects by Name in the Dataflow Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Automatically Tracing All Paths Between Two Nets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Dataflow Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Symbol Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
User-Defined Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Current vs. Post-Simulation Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Dataflow Window Graphic Interface Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
What Can I View in the Dataflow Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
How is the Dataflow Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . . 876
How Can I Print and Save the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Save a .eps File and Printing the Dataflow Display from UNIX . . . . . . . . . . . . . . . . . . . 878
Print from the Dataflow Display on Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . 878
Configure Page Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
How Do I Configure Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880

Chapter 16
Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Opening Source Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Navigating Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Data and Objects in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Object Values and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Search for Source Code Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Searching for One Instance of a String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Searching for All Instances of a String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Searching for the Original Declaration of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Debugging and Textual Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Hyperlinked Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Code Coverage Data in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Coverage Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Using the Modify Breakpoints Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Deleting Individual Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Deleting Groups of Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902

Questa® SIM User's Manual, v2023.4 21

 Table of Contents

Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904

Setting a Breakpoint For a Specific Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Setting a Breakpoint For a Specified Value of Any Instance. . . . . . . . . . . . . . . . . . . . . . 906
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Source Window Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Setting and Removing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Source Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908

Chapter 17
Using Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Creating a Database for Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Initiating Causality Traceback from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Using the find drivers Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Command Line Options for Setting Report Destination . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Command Line Options for Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Performing Post-simulation Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Initiating Causality Traceback from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Trace to the First Sequential Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Initiating the Trace from the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Initiating the Trace from the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Initiating the Trace from the Objects or Schematics Windows . . . . . . . . . . . . . . . . . . . . 920
Tracing to the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Tracing to the Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Tracing to the Root Cause of an ‘X’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Finding All Possible Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Tracing from a Specific Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Multiple Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Causality Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Causality Traceback Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934

Chapter 18
Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Overview of Code Coverage Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Language and Datatype Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Usage Flow for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Specify Coverage Types for Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Union of Coverage Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Enabling Simulation for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Code Coverage in the UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Code Coverage in the Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Displaying Coverage Summary in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . 953
Unexpected Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Statement Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Branch Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956

22 Questa® SIM User's Manual, v2023.4

Table of Contents

Branch Coverage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956

Case and Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
AllFalse Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Missing Branches in VHDL and Clock Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Condition and Expression Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Focused Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Multibit Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Reporting Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
FEC Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
FEC Report Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
FEC and Short-circuiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Exclusions and FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Legacy FEC Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
VHDL Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Verilog/SV Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Toggle Coverage and Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
VHDL Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Verilog/SV Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Toggle Ports Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Viewing Toggle Coverage Data in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . 979
Toggle Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Specifying Toggle Coverage Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Toggle Using the Main Window Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Limiting Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
What Objects can be Excluded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Enabling Two-Step Exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude True or False Branch of if Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude Implicit (AllFalse) Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude AllFalse Branches in Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Exclude Any/All Coverage Data in a Single File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Exclude Individual Metrics with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Supported Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Verilog vs. VHDL Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
coverage on and coverage off Pragma Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Pragma Usage and Nesting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Adaptive Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
The Adaptive Exclusion DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Generating an Adaptive Exclusion DO File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Toggle Exclusion Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Exclude Nodes from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Toggle Pragma Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014

Questa® SIM User's Manual, v2023.4 23

 Table of Contents

Exclude Bus Bits from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015

Re-enable Toggles Excluded with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Exclude enum Signals from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
FSM Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Exclude FSM with coverage exclude Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
FSM Pragma Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Code Coverage Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Coverconstructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Code Coverage Mode Interaction with Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . 1027
Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Branch Coverage and Numbering of Items in Coverage Report . . . . . . . . . . . . . . . . . . . 1033
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
The toggle report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Using toggle report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Port Collapsing and Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Ordering of Toggle Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
XML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Notes on Coverage and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Interaction of Optimization and Coverage Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040

Chapter 19
Finite State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
FSM Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
FSM Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
FSM Multi-State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Collecting FSM Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Reporting Coverage Metrics for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Viewing FSM Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
FSM Coverage Metrics Available in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Advanced Command Arguments for FSMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Recognized FSM Note. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
FSM Recognition Info Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
FSM Coverage Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061

Chapter 20
Verification with Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Overview of Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066
Assertion Coding Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Using Assert Directive Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070

24 Questa® SIM User's Manual, v2023.4

Table of Contents

SystemVerilog Bind Construct. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071

Processing Assume Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Configuring Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Enabling Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Enabling Memory and Performance Profiling Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Configuring Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Setting Break Severity for Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Enabling/Disabling Assertion Failure and Pass Logging. . . . . . . . . . . . . . . . . . . . . . . . . 1076
Setting Assertion Failure Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Setting Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Changing the Default Configuration of Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . 1079
Other Configuration Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Simulating Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Maintaining Assertion Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Analyzing Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Viewing Assertions in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Viewing Cover Directives in the Cover Directives Window . . . . . . . . . . . . . . . . . . . . . . 1090
Viewing Memory Profile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Viewing Assertions and Cover Directives in the Wave Window . . . . . . . . . . . . . . . . . . 1092
Utilizing GUI Display Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Comparing Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Saving Metrics to the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
Excluding Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Creating Assertion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Using PSL Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Using PSL Directives in Procedural Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Common PSL Assertions Coding Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
Embedding Assertions in Your Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
HDL Code Inside PSL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Writing PSL Assertions in an External File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Sharing a Single .psl File Between VHDL and Verilog Models . . . . . . . . . . . . . . . . . . . 1112
Inserting VHDL library and use Clauses in External PSL Assertion Files . . . . . . . . . . . 1112
PSL Clocked and Unclocked Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Using PSL ended() in HDL Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Compiling and Simulating PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Compiling Embedded PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Compiling an External PSL Assertions File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Applying PSL Assertions During Elaboration/Optimization . . . . . . . . . . . . . . . . . . . . . . 1119
Making Changes to PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
PSL Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Using SVA Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Assertions and Action Blocks in SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Deferred Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
SystemVerilog Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
SVA Usage Flow for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
Using -assertdebug to Debug with Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1125
Viewing Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
Enabling ATV Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126
Enabling and Disabling ATV Recording During Simulation . . . . . . . . . . . . . . . . . . . . . . . 1127

Questa® SIM User's Manual, v2023.4 25

 Table of Contents

Saving Assertion and Cover Directive Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128

Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window . . . . . . 1130
Using the Assertion Active Thread Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Viewing Assertion Threads in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132
Navigating Inside an ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Expression Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Thread Viewer Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Local Variables Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138
Design Objects Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
Actions in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Find Sub-Expression That Caused Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Viewing Multiple Clock Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Expanding and Contracting Expression Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Highlighting a Thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Hovering the Mouse for Thread and Directive Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Annotating Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146

Chapter 21
Verification with Functional Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Functional Coverage Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
Functional Coverage Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Guidelines for Functional Coverage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Controlling Functional Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Functional Coverage Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Predefined Coverage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Predefined Coverage System Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
SystemVerilog Functional Coverage Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
IEEE Std 1800-2009 Option Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Example of Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
SystemVerilog 2009 option.per_instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
SystemVerilog 2009 type_option.merge_instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
SystemVerilog 2009 option.get_inst_coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Legacy Behavior and Option Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Type-Based Coverage With Constructor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Default Type-Based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Projected Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
Testplan Linking and the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162
Functional Coverage Statistics in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
Viewing Functional Coverage Statistics in the Covergroups Window . . . . . . . . . . . . . . . 1163
Functional Coverage Aggregation in Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
Reporting on Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Creating Text Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Creating HTML Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Covergroup Bin Reporting and Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Filtering Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Reporting Via the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Excluding Functional Coverage from the GUI and Reports. . . . . . . . . . . . . . . . . . . . . . . . 1173
Sample Commands for Excluding Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 1173

26 Questa® SIM User's Manual, v2023.4

Table of Contents

Transitive Cross Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174

Hiding Covergroup Instances from GUI and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
Assertion/Cover Directive Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
Covergroup Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
Covergroup in a Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
Canonical String Representation for Coverpoint Bin Value . . . . . . . . . . . . . . . . . . . . . . . 1178
Saving Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Saving For All Simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Saving For The Current Simulation Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Loading a Functional Coverage Database into Simulation . . . . . . . . . . . . . . . . . . . . . . . . 1182
Loading Behavior Related to option.per_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183

Chapter 22
Verification with Constrained
Random Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Verification Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Constraint Solver Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186
Building Constrained Random Test Benches on SystemVerilog Classes . . . . . . . . . . . . . . . 1187
Generating New Random Values with randomize(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188
Attributes Of Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Syntax and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Size Constraints for Random Dynamic Arrays with randomize() . . . . . . . . . . . . . . . . . . 1190
Debugging randomize() Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
Specifying a Solver Engine with solveengine Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Inheriting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Constraint Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
Examining Solver Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
Enabling Solver Profiling and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195
Setting Compatibility with a Previous Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195
Random Number Generator (RNG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
RNG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Seeding the RNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Random Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Analyzing Random Instability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Achieve Random Stability Using set_randstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Enabling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
TCL Variables for Controlling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
RNG Trace Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
RNG Activity With A Fork Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
RNG Activity for a Call to new() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Getting a Call Stack for an RNG Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Automatic Filtering of Set/Reset RNG Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225
Const Cast Expression Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226
Solver Record and Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Solver Record and Replay Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Solver Record and Replay Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229

Questa® SIM User's Manual, v2023.4 27

 Table of Contents

Solver Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230

Chapter 23
Coverage and Verification Management in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Coverage and Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Calculation of Total Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Where to Find Coverage Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Coverage and Simulator Use Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Coverage View Mode and the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Running Tests and Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Collecting and Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Name Selection for Test UCDB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Understanding Stored Test Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Test Attribute Records in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Predefined Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Manage Test Data in UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Matching the Paths of Corresponding Coverage Items . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Merging Using a Master UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Merging In A Multi-User Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Parallel Merge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Requirements for Parallel Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
The Parallel Merge Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Options Used for Building the Merge List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
Distribution of Files into Parallel Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Information Not Perfectly Preserved During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Multiple Test Data Records with Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Merging and Source Code Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 1272
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276
Viewing and Analyzing Verification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Storing User Attributes in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Viewing Test Data in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278

28 Questa® SIM User's Manual, v2023.4

Table of Contents

Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279

Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Customizing the Column Views in Verification Windows . . . . . . . . . . . . . . . . . . . . . . . . 1281
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Ranking Coverage Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Group Ranking of Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Viewing Ranked Test Data in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
Merged Results vs. Rank Report Coverage: Why They Can Differ . . . . . . . . . . . . . . . . 1286
Ranking Most Effective Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Test-Associated vs. Iterative Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
The Generation of Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
Generating ASCII Text Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Generating HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Canonical Toggle Nodes in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
option or type_option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Viewing Bins Hit by Certain Tests in HTML Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Cross Bins in HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Generating Coverage Exclusion Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Filtered Data in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Setting up or Modifying a Filter for UCDB Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Applying a Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Filtering Results by User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Analysis for Late-stage ECO Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306

Chapter 24
C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
Supported Platforms and gdb Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Setting Up C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Running C Debug from a DO File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
Stepping in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Quitting C Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Finding Function Entry Points with Auto Find bp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Identifying All Registered Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Enabling Auto Step Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Auto Find bp Versus Auto Step Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316
Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
Debugging Functions During Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
FLI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318
PLI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319
VPI Functions in Initialization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Completing Design Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
Debugging Functions when Quitting Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321

Questa® SIM User's Manual, v2023.4 29

 Table of Contents

C Debug Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322

Chapter 25
Classic Performance Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325
Introducing Performance Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Profile Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Getting Started with the Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Enabling the Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Collecting Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Turning Profiling Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Running the Profiler on Windows with FLI/PLI/VPI Code . . . . . . . . . . . . . . . . . . . . . . . . 1329
Viewing Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Ranked Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Design Units Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333
Viewing Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Integration with Source Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Reporting Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340
Enabling or Disabling Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341
Levels of Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Coarse-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Fine-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Enabling Fine-Grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344
Consolidated Memory Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344
Opening the Capacity Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Displaying Capacity Data in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Writing a Text-Based Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
Reporting Capacity Analysis Data From a UCDB File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352
Examining Memory Usage for Assertions and Cover Directives. . . . . . . . . . . . . . . . . . . . 1353
Constraint Solver Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354

Chapter 26
Signal Spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355
Signal Spy Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356
Signal Spy Formatting Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357
Signal Spy Supported Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
Signal Spy Unsupported Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
Signal Spy Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
disable_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
enable_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
init_signal_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
init_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
signal_force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1372
signal_release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376

30 Questa® SIM User's Manual, v2023.4

Table of Contents

Chapter 27
Monitoring Simulations with JobSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379
Basic JobSpy Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
Set JOBSPY_DAEMON Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
Start the JobSpy Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
Set the JOBSPY_DAEMON Variable as a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381
Running JobSpy from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Simulation Commands Available to JobSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Running the JobSpy GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Starting Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Invoking Simulation Commands in Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Interactive Job Session Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
View Commands and Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386
Viewing Results During Active Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387
Viewing Waveforms from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387
Licensing and Job Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Checkpointing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Connecting to Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Checkpointing with Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring LSF for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring Flowtracer for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring Grid Engine for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390

Chapter 28
Generating Stimulus with Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Getting Started with the Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Using Waveform Editor Prior to Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Accessing the Create Pattern Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Creating Waveforms with Wave Create Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Editing Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Stretching and Moving Edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Simulating Directly from Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Exporting Waveforms to a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Driving Simulation with the Saved Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Signal Mapping and Importing EVCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Using Waveform Compare with Created Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1405
Saving the Waveform Editor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1405

Chapter 29
Standard Delay Format (SDF) Timing Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407
Specifying SDF Files for Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408
Recommended Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408
Instance Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408
SDF Specification with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409

Questa® SIM User's Manual, v2023.4 31

 Table of Contents

Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409

Compiling SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
Simulating with Compiled SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
VHDL VITAL SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
SDF to VHDL Generic Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Resolving Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Verilog SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
$sdf_annotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416
SDF to Verilog Construct Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
Retain Delay Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
Optional Edge Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
Optional Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Rounded Timing Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
SDF for Mixed VHDL and Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Interconnect Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
Specifying the Wrong Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
Matching a Single Timing Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
Mistaking a Component or Module Name for an Instance Label. . . . . . . . . . . . . . . . . . . . 1429
Forgetting to Specify the Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
Reporting Unannotated Specify Path Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
Failing to Find Matching Specify Module Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432

Chapter 30
Value Change Dump (VCD) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
Creating a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Four-State VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Extended VCD File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
VCD Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
Checkpoint/Restore and Writing VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
Using Extended VCD as Stimulus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
Simulating with Input Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
Replacing Instances with Output Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . 1440
Port Order Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441
VCD Commands and VCD Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
Using VCD Commands with SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Compressing Files with VCD Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
VCD File from Source to Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
VHDL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
VCD Simulator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
VCD to WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Capturing Port Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Resolving Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
Default Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
When force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
Extended Data Type for VHDL (vl_logic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
Ignoring Strength Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452

32 Questa® SIM User's Manual, v2023.4

Table of Contents

VCD for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454

Chapter 31
Tcl and DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455
Tcl Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
Tcl References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
Tcl Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
If Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
set Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
Command Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Command Separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Multiple-Line Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Evaluation Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
Tcl Relational Expression Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
Variable Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
Questa SIM Replacements for Tcl Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
Referencing Simulator State Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468
Special Considerations for the now Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
Reading Variable Values From the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
Setting Variable Values for the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
List Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
Simulator Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
Simulator Tcl Time Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Time Conversion Tcl Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Time Relations Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
Creating DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
Using Parameters with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
Deleting a File from a .do Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
Making Script Parameters Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
Breakpoint Flow Control in Nested DO files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
Useful Commands for Handling Breakpoints and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
Error Action in DO File Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
Using the Tcl Source Command with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
The Tcl Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
The Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
The Chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
Tcl Debugger Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
TclPro Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487

Appendix A
modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
Organization of the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497

Questa® SIM User's Manual, v2023.4 33

 Table of Contents

Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497

Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
AcceptLowerCasePragmaOnly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
AmsStandard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
AssertionCover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
AutoExclusionsDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
BatchTranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
BindAtCompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
BreakOnAssertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
BreakOnMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
CheckPlusargs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
CheckSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
CodeCoverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
CodeLinkAutoLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
CommandHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
common . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
CompilerTempDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
CoverageSaveParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
CoverCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
CoverClkOptBuiltins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557

34 Questa® SIM User's Manual, v2023.4

Table of Contents

CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
CoverExcludeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
CoverOpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
CoverREC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
CoverThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
CoverWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
CppOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
CppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
data_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
DefaultLibType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
DefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
DefaultRestartOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
DpiCppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
DpiCppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
EnableSVCoverpointExprVariable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
EnumBaseInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
ExtendedToggleMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606

Questa® SIM User's Manual, v2023.4 35

 Table of Contents

FlatLibPageDeletePercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
floatfixlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
ForceSigNextIter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
ForceUnsignedIntegerToVHDLInteger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
FsmResetTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
GCThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
GenerateFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
GenerateLoopIterationMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
GenerateRecursionDepthMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
Hazard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
IgnoreFailure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
IgnoreSVAWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
IgnoreWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
InitOutCompositeParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
IterationLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
LargeObjectSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643
License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
MaxReportRhsSVCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
MaxSVCoverpointBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
MaxSVCrossBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
MessageFormatFail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655

36 Questa® SIM User's Manual, v2023.4

Table of Contents

MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
MessageFormatWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
modelsim_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
MsgLimitCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
MultiFileCompilationUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
NoCaseStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
NoRangeCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
NumericStdNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
OnFinishPendingAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
PedanticErrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
RequireConfigForAllDefaultBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
ScMainFinishOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704

Questa® SIM User's Manual, v2023.4 37

 Table of Contents

ScStackSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
Show_Warning1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
Show_Warning2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
Show_Warning3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
Show_Warning4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
Show_Warning5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
SignalForceFunctionUseDefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
SmartDbgSym. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
SolveArrayResizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
SolveBeforeErrorSeverity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
SolveEngineErrorSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
SolveFailDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
SolveFailTestcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
SolveGraphMaxEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1741
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
StackTraceDepth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1745
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
Stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1749
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
StdArithNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754

38 Questa® SIM User's Manual, v2023.4

Table of Contents

sv_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1755
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758
SVCovergroupGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
SVCovergroupPerInstanceDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1761
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
SVCovergroupTypeGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
SVCoverpointAutoBinMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769
SVCoverpointWildCardBinValueSizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1770
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
SvRandExtensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
ToggleMaxRealValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1793
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
ToggleVlogEnumBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799
toolblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1800
TranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
UnattemptedImmediateAssertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809

Questa® SIM User's Manual, v2023.4 39

 Table of Contents

UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
UVMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1813
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
VhdlSeparatePduPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819
WarnConstantChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1821
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
wholefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823
WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824
WildcardSizeThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
WildcardSizeThresholdVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
WLFCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
WLFCollapseMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
WLFDeleteOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1830
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
WLFFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
WLFOptimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1833
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
WLFSimCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
WLFTimeLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1838
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
WrapColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
WrapWSColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
XpropAssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843
Commonly Used modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Common Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Hierarchical Library Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Warnings from Arithmetic Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Restart Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847

40 Questa® SIM User's Manual, v2023.4

Table of Contents

Appendix B
Design Packager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849

Appendix C
Location Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1853
Referencing Source Files with Location Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854
Using Location Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854
Pathname Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
How Location Mapping Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855

Appendix D
Error and Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1857
Message System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
Getting More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Message Severity Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Syntax Error Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Suppression of Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1860
Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862
Miscellaneous Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Error Messages from the sccom Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869
Enforcing Strict 1076 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870

Appendix E
Questa Verification IP Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873
Accessing 60000 Series Error Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1874
Accessing 50000 Series Error Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876
Why Series 50000 Errors Occur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879
Concepts Involved in the Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Transaction Types and Time Queue ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Parents and Children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
Deleted Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
Understanding the ‘Time Queue’ ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
Viewing the Time Queue ID Number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
TQ Id Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887
Understanding ‘Parents’ and ‘Children’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1890
Parent/Child Relationship Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1891
Understanding Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893
Generation/Recognition Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1894
Understanding Deletions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896
Deletion Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896
Understanding Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
Activated Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899

Questa® SIM User's Manual, v2023.4 41

 Table of Contents

Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1901

Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1902
Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903
Understanding Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1904
Understanding the Volatile Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Volatile Clause Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Understanding Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907
Activity Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907
Understanding ‘Throw’ and ‘Catch’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1908
Throw and Catch Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1908
Understanding TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
WLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
WLM-connected and TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910

Appendix F
Verilog Interfaces to C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914
GCC Compiler Support for use with C Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915
Registering PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916
Registering VPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917
Registering DPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1919
DPI Use Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1921
DPI and the vlog Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1922
Deprecated Legacy DPI Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923
When Your DPI Export Function is Not Getting Called . . . . . . . . . . . . . . . . . . . . . . . . . . 1923
Troubleshooting a Missing DPI Import Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1924
Simplified Import of Library Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1924
Optimizing DPI Import Call Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925
DPI Arguments of Parameterized Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925
Making Verilog Function Calls from non-DPI C Models . . . . . . . . . . . . . . . . . . . . . . . . . 1926
Calling C/C++ Functions Defined in PLI Shared Objects from DPI Code . . . . . . . . . . . . 1926
PLI Catalog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1928
PLI Catalog (PCAT) Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
PCAT File for Controlling Access Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
PCAT File with PLI Autocompile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
PLI Catalog File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1931
PLI Catalog Use Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1935
Using a PCAT File for Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1935
Using a PCAT File with PLI Autocompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936
Compiling and Linking C Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938
For all UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938
Windows Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1939
Linux Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1940
Compiling and Linking C++ Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1942
For PLI/VPI only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1942
Windows Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1943

42 Questa® SIM User's Manual, v2023.4

Table of Contents

Linux Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1944

Specifying Application Files to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
PLI and VPI File Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
DPI File Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
Loading Shared Objects with Global Symbol Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . 1946
PLI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947
VPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947
DPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948
The PLI Callback reason Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949
The sizetf Callback Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1951
PLI Object Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1952
Third Party PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1952
Support for VHDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953
IEEE Std 1364 ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954
IEEE Std 1364 TF Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954
SystemVerilog DPI Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957
Verilog-XL Compatible Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957
64-bit Support for PLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957
PLI/VPI Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
The Purpose of Tracing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Invoking a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Checkpointing and Interface Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1959
Debugging Interface Application Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1960

Appendix G
System Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963
Files Accessed During Startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963
Initialization Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1964
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967
Expansion of Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967
Setting Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1968
Creating Environment Variables in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974
Library Mapping with Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974
Referencing Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1975
Removal of Temporary Files (VSOUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1975

Appendix H
Third-Party Model Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1977
Synopsys SmartModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978
VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Enabling the VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Creating Foreign Architectures with sm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
sm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1981
SmartModel Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Command Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1984
SmartModel Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1985
Memory Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987
Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987

Questa® SIM User's Manual, v2023.4 43

 Table of Contents

Synopsys Hardware Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1988

VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1989
Hardware Model Interface Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1989
hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1990
Creating Foreign Architectures with hm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1990
hm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1991
Hardware Model Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993
Hardware Model Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994
Third-Party Information

44 Questa® SIM User's Manual, v2023.4

 List of Figures

Figure 1-1. Operational Structure and Flow of Questa SIM . . . . . . . . . . . . . . . . . . . . . . . . . 62

Figure 1-2. Work Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 1-3. Compiled Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 3-1. Create Project Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 3-2. Project Window Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 3-3. Add items to the Project Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 3-4. Create Project File Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 3-5. Add file to Project Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 3-6. Click Plus Sign to Show Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 3-7. Setting Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 3-8. Grouping Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 3-9. Add Simulation Configuration Dialog Box — Design Tab . . . . . . . . . . . . . . . . 133
Figure 3-10. Structure Window with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 3-11. Project Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figure 3-12. Add Simulation Configuration Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 3-13. Simulation Configuration in the Project Window. . . . . . . . . . . . . . . . . . . . . . . 137
Figure 3-14. Add Folder Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Figure 3-15. Specifying a Project Folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Figure 3-16. Project Compiler Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Figure 3-17. Specifying File Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Figure 3-18. Project Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Figure 4-1. Creating a New Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 4-2. The Library Window—Design Unit Information in the Workspace . . . . . . . . . 150
Figure 4-3. Edit Library Mapping Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 4-4. Sub-Modules with the Same Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figure 4-5. Import Library Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 5-1. VHDL Delta Delay Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 6-1. Fatal Signal Segmentation Violation (SIGSEGV) . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 6-2. Current Process Where Error Occurred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 6-3. Blue Arrow Indicating Where Code Stopped Executing . . . . . . . . . . . . . . . . . . 249
Figure 6-4. Null Values in the Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure 6-5. Classes in the Class Tree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Figure 6-6. Class in the Class Graph Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Figure 6-7. Classes in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Figure 6-8. The Class Instances Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure 6-9. Placing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Figure 6-10. Class Information Popup in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 342
Figure 6-11. Class Viewing in the Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Figure 6-12. Class Path Expressions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 346
Figure 6-13. /top/a Cast as c1 and c1prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Questa® SIM User's Manual, v2023.4 45

 List of Figures

Figure 6-14. Casting c1 to c1prime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Figure 6-15. Extensions for a Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Figure 6-16. Garbage Collector Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Figure 6-17. Structure Window Showing UVM Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . 374
Figure 6-18. Expanded UVM Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Figure 6-19. UVM Details Window Stream Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Figure 6-20. UVM Details Window ConfigDB Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Figure 6-21. UVM Details Window Sequence Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Figure 6-22. Processes Window Hierarchy Mode with UVM Components . . . . . . . . . . . . . 377
Figure 6-23. UVM Message Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Figure 6-24. UVM Transaction Streams in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 380
Figure 7-1. SystemC Objects in GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Figure 7-2. Breakpoint in SystemC Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Figure 7-3. Setting the Allow lib step Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Figure 7-4. SystemC Objects and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Figure 7-5. Aggregate Data Displayed in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Figure 10-1. Transaction Anatomy in Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Figure 10-2. Transaction Stream in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Figure 10-3. Viewing Transactions and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Figure 10-4. Concurrent Parallel Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Figure 10-5. Transaction in Wave Window - Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Figure 10-6. Transaction Stream Properties Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Figure 10-7. Transaction-Stream Properties Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Figure 10-8. Transactions in List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Figure 10-9. Transactions in Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Figure 10-10. Recording Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Figure 11-1. Questa Verification IP Transaction at Different Levels of Abstraction . . . . . . 672
Figure 11-2. Arrays in Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Figure 11-3. Questa Verification IP Transactions in Wave Window . . . . . . . . . . . . . . . . . . 679
Figure 11-4. Concurrent Transactions Overlapping in Wave Window . . . . . . . . . . . . . . . . . 681
Figure 11-5. Questa Verification IP Array (2X2) in Wave Window. . . . . . . . . . . . . . . . . . . 681
Figure 11-6. Color of Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Figure 11-7. Questa Verification IP Objects in Objects Window . . . . . . . . . . . . . . . . . . . . . 683
Figure 11-8. Questa Verification IP Objects in List Window . . . . . . . . . . . . . . . . . . . . . . . . 684
Figure 11-9. Viewing Questa Verification IP Relationships . . . . . . . . . . . . . . . . . . . . . . . . . 687
Figure 11-10. Transaction Window - Data Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Figure 11-11. Transaction Window - Relations Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Figure 12-1. Displaying Two Datasets in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 696
Figure 12-2. Dataset Snapshot Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Figure 12-3. Open Dataset Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Figure 12-4. Structure Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Figure 12-5. The Dataset Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Figure 12-6. Virtual Objects Indicated by Orange Diamond. . . . . . . . . . . . . . . . . . . . . . . . . 710
Figure 13-1. The Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Figure 13-2. Insertion Point Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

46 Questa® SIM User's Manual, v2023.4

List of Figures

Figure 13-3. Grid and Timeline Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Figure 13-4. Original Names of Wave Window Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Figure 13-5. Sync All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Figure 13-6. Cursor Linking Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Figure 13-7. Configure Cursor Links Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Figure 13-8. Waveform Pane with Collapsed Event and Delta Time . . . . . . . . . . . . . . . . . . 729
Figure 13-9. Waveform Pane with Expanded Time at a Specific Time . . . . . . . . . . . . . . . . 730
Figure 13-10. Waveform Pane with Event Not Logged . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Figure 13-11. Waveform Pane with Expanded Time Over a Time Range . . . . . . . . . . . . . . 731
Figure 13-12. New Bookmark Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Figure 13-13. Wave Signal Search Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Figure 13-14. Expression Builder Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Figure 13-15. Selecting Signals for Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Figure 13-16. Display Tab of the Wave Window Preferences Dialog Box. . . . . . . . . . . . . . 747
Figure 13-17. Grid and Timeline Tab of Wave Window Preferences Dialog Box . . . . . . . . 749
Figure 13-18. Clock Cycles in Timeline of Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 750
Figure 13-19. Wave Format Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Figure 13-20. Format Tab of Wave Properties Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Figure 13-21. Changing Signal Radix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Figure 13-22. Global Signal Radix Dialog in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 753
Figure 13-23. Separate Signals with Wave Window Dividers . . . . . . . . . . . . . . . . . . . . . . . 754
Figure 13-24. Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Figure 13-25. Wave Groups Denoted by Red Diamond . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Figure 13-26. Contributing Signals Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Figure 13-27. Save Format Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Figure 13-28. Waveform Save Between Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Figure 13-29. Wave Filter Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Figure 13-30. Wave Filter Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Figure 13-31. Adding Class Objects in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . 770
Figure 13-32. Class Information Popup in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 771
Figure 13-33. Virtual Interface Objects Added to Wave Window . . . . . . . . . . . . . . . . . . . . 774
Figure 13-34. Signals Combined to Create Virtual Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Figure 13-35. Wave Extract/Pad Bus Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Figure 13-36. Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Figure 13-37. Virtual Signal Builder Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Figure 13-38. Creating a Virtual Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Figure 13-39. Virtual Signal in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Figure 13-40. Modifying the Breakpoints Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Figure 13-41. Signal Breakpoint Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Figure 13-42. Breakpoints in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Figure 13-43. File Breakpoint Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Figure 13-44. Waveform Comparison Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Figure 13-45. Start Comparison Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Figure 13-46. Compare Tab in the Workspace Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
Figure 13-47. Structure Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797

Questa® SIM User's Manual, v2023.4 47

 List of Figures

Figure 13-48. Add Comparison by Region Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

Figure 13-49. Comparison Methods Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Figure 13-50. Adding a Clock for a Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Figure 13-51. Waveform Comparison Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Figure 13-52. Viewing Waveform Differences in the Wave Window . . . . . . . . . . . . . . . . . 802
Figure 13-53. Waveform Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Figure 13-54. Reloading and Redisplaying Compare Differences . . . . . . . . . . . . . . . . . . . . 805
Figure 14-1. Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Figure 14-2. Schematic View Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Figure 14-3. Schematic Add to Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Figure 14-4. Colors Help Identify Architectures, Modules, and Processes. . . . . . . . . . . . . . 814
Figure 14-5. Show Incremental View Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Figure 14-6. Hover Mouse for Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Figure 14-7. Code Preview Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Figure 14-8. The Follow Box in the Full View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Figure 14-9. Left-Pointing Mouse Arrow Indicates Drivers . . . . . . . . . . . . . . . . . . . . . . . . . 819
Figure 14-10. Double-Headed Arrow Indicates Inout with Drivers and Readers . . . . . . . . . 820
Figure 14-11. Change Schematic Preference Value Dialog Box. . . . . . . . . . . . . . . . . . . . . . 821
Figure 14-12. Redundant Buffers and Inverters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Figure 14-13. Highlight Selected Trace with Custom Color . . . . . . . . . . . . . . . . . . . . . . . . . 822
Figure 14-14. Folded Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Figure 14-15. Unfolded Instance Not Showing Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Figure 14-16. Unfolded Instance with All Contents Displayed. . . . . . . . . . . . . . . . . . . . . . . 824
Figure 14-17. Abstract Blocks Identified with Unique Number . . . . . . . . . . . . . . . . . . . . . . 825
Figure 14-18. Wave Viewer Displays Inputs and Outputs of Selected Process . . . . . . . . . . 827
Figure 14-19. Event Traceback Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Figure 14-20. CurrentTime Label in Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Figure 14-21. Enter Current Time Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Figure 14-22. Signals for Selected Process in Embedded Wave Viewer . . . . . . . . . . . . . . . 830
Figure 14-23. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Figure 14-24. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . 831
Figure 14-25. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Figure 14-26. Active Driver Path Details for the q Signal . . . . . . . . . . . . . . . . . . . . . . . . . . 832
Figure 14-27. Click Schematic Window Button to View Path Details . . . . . . . . . . . . . . . . . 832
Figure 14-28. Path to Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Figure 14-29. Unknown States Shown as Red Lines in Wave Window . . . . . . . . . . . . . . . . 834
Figure 14-30. Event Traceback Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Figure 14-31. Find Toolbar for Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Figure 14-32. Adding a Sticky Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Figure 14-33. Schematic: Point-to-Point Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Figure 14-34. The Print Postscript Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Figure 14-35. The Schematic Page Setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Figure 14-36. Configuring Incremental View Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Figure 14-37. Display Options in Right-Click Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Figure 14-38. Keyboard Shortcut Table in the Schematic Window . . . . . . . . . . . . . . . . . . . 849

48 Questa® SIM User's Manual, v2023.4

List of Figures

Figure 15-1. The Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852

Figure 15-2. Dataflow Debugging Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Figure 15-3. Dot Indicates Input in Process Sensitivity List . . . . . . . . . . . . . . . . . . . . . . . . . 858
Figure 15-4. CurrentTime Label in Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Figure 15-5. Controlling Display of Redundant Buffers and Inverters . . . . . . . . . . . . . . . . 863
Figure 15-6. Green Highlighting Shows Your Path Through the Design . . . . . . . . . . . . . . . 863
Figure 15-7. Highlight Selected Trace with Custom Color . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Figure 15-8. Wave Viewer Displays Inputs and Outputs of Selected Process . . . . . . . . . . . 865
Figure 15-9. Unknown States Shown as Red Lines in Wave Window . . . . . . . . . . . . . . . . . 867
Figure 15-10. Dataflow: Point-to-Point Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Figure 15-11. The Print Postscript Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Figure 15-12. The Print Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Figure 15-13. The Page Setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Figure 15-14. Dataflow Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
Figure 16-1. Setting Context from Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Figure 16-2. Examine Window Pop Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Figure 16-3. Source Annotation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Figure 16-4. Current Time Label in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Figure 16-5. Enter an Event Time Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Figure 16-6. Bookmark All Instances of a Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Figure 16-7. Popup Menu Choices for Textual Dataflow Information . . . . . . . . . . . . . . . . . 892
Figure 16-8. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Figure 16-9. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . . 893
Figure 16-10. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Figure 16-11. List Menu with All Three Viewing Options On . . . . . . . . . . . . . . . . . . . . . . . 894
Figure 16-12. Click Any Driver to Display It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Figure 16-13. Source Readers Dialog Displays All Signal Readers . . . . . . . . . . . . . . . . . . . 895
Figure 16-14. Coverage in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Figure 16-15. Breakpoint in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Figure 16-16. Editing Existing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Figure 16-17. Source Code for source.sv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Figure 17-1. Event Traceback Toolbar Button Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Figure 17-2. Cause is Highlighted in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Figure 17-3. Click to Show Drivers Control Bar to See Driver(s) . . . . . . . . . . . . . . . . . . . . 917
Figure 17-4. Active Driver Path Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Figure 17-5. Active Cursor Show Time of Causal Process . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Figure 17-6. Causal Process Highlighted in Structure Window . . . . . . . . . . . . . . . . . . . . . . 919
Figure 17-7. Causal Signal Highlighted in the Objects Window . . . . . . . . . . . . . . . . . . . . . 919
Figure 17-8. Time Indicator in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Figure 17-9. Enter an Event Time Value for Causality Tracing . . . . . . . . . . . . . . . . . . . . . . 920
Figure 17-10. Source Window - Show Drivers Control Bar . . . . . . . . . . . . . . . . . . . . . . . . . 922
Figure 17-11. Selecting Show Driver from Show Cause Drop-Down Menu . . . . . . . . . . . . 922
Figure 17-12. Right-click Menu – Show Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Figure 17-13. Details of the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Figure 17-14. Trace Event to Root Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924

Questa® SIM User's Manual, v2023.4 49

 List of Figures

Figure 17-15. Root Cause Highlighted in Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . 924

Figure 17-16. Show X Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Figure 17-17. Show All Possible Drivers Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Figure 17-18. Possible Drivers in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Figure 17-19. Selecting a Specific Time for a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Figure 17-20. Enter Value Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Figure 17-21. Show Drivers Control Bar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Figure 17-22. Multiple Drivers in the Show Drivers Control Bar. . . . . . . . . . . . . . . . . . . . . 928
Figure 17-23. History Button Displays Past Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Figure 17-24. List Menu with All Three Viewing Options On . . . . . . . . . . . . . . . . . . . . . . . 929
Figure 17-25. Click Any Driver to Display It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Figure 17-26. View Path Details Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Figure 17-27. Causality Path Details in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . 931
Figure 17-28. Time 810 Selected in Path Times Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Figure 17-29. Causality Path Details in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . 933
Figure 17-30. Causality Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Figure 18-1. Enabling Code Coverage in the Start Simulation Dialog . . . . . . . . . . . . . . . . . 943
Figure 18-2. Selecting Code Coverage Analysis Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Figure 18-3. Coverage Summary Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Figure 18-4. Summary Begins Each Coverage Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Figure 18-5. Multibit Expression Text Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Figure 18-6. Multibit Expression HTML Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Figure 18-7. Toggle Coverage Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Figure 18-8. Toggle Coverage Data in the Objects Window. . . . . . . . . . . . . . . . . . . . . . . . . 980
Figure 18-9. Empty Pending Exclusions Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Figure 18-10. Populated Pending Exclusions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Figure 18-11. Selecting a Pending Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Figure 18-12. Adaptive Exclusion Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Figure 18-13. Exclude Individual Transitions in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Figure 18-14. Sample Toggle Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Figure 20-1. Assertion Matches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Figure 20-2. Configure Assertions Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Figure 20-3. Assertion Enable Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
Figure 20-4. Selecting Profile On from Capacity Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Figure 20-5. Selecting Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Figure 20-6. Setting Immediate Assertion Break Severity . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Figure 20-7. Enabling/Disabling Failure or Pass Logging . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Figure 20-8. Setting Assertion Failure Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Figure 20-9. Set Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Figure 20-10. Configure Selected Cover Directives Dialog . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Figure 20-11. Failure Counts in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
Figure 20-12. Assertion Failures Indicated by Red Triangles . . . . . . . . . . . . . . . . . . . . . . . . 1085
Figure 20-13. Assertion Counts in the Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Figure 20-14. Enable Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086
Figure 20-15. Assertion Indicators When -assertdebug is Used . . . . . . . . . . . . . . . . . . . . . . 1087

50 Questa® SIM User's Manual, v2023.4

List of Figures

Figure 20-16. Counts Columns in Assertions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088

Figure 20-17. SystemVerilog Assertions in the Assertions Window . . . . . . . . . . . . . . . . . . 1089
Figure 20-18. Assertion Failures Appear in Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Figure 20-19. PSL Cover Directives in the Cover Directives Window. . . . . . . . . . . . . . . . . 1091
Figure 20-20. SystemVerilog Assert and Cover Directives in the Wave Window . . . . . . . . 1093
Figure 20-21. PSL Assert and Cover Directives in the Wave Window. . . . . . . . . . . . . . . . . 1094
Figure 20-22. Antecedent Matches Indicated by Yellow Triangle . . . . . . . . . . . . . . . . . . . . 1095
Figure 20-23. Hierarchy Display Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Figure 20-24. Viewing Cover Directive Waveforms in Count Mode . . . . . . . . . . . . . . . . . . 1097
Figure 20-25. Assertions Report Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Figure 20-26. Usage Flow for PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Figure 20-27. Usage Flow for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Figure 20-28. Enable Assertion Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
Figure 20-29. Enable ATV Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
Figure 20-30. Assertion Debug Pane in Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Figure 20-31. The ActiveCount Object in the Wave Window - SystemVerilog . . . . . . . . . . 1132
Figure 20-32. Selecting Assertion Thread Start Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Figure 20-33. Opening ATV from the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134
Figure 20-34. Opening ATV from the Message Viewer Window. . . . . . . . . . . . . . . . . . . . . 1135
Figure 20-35. ATV Panes - SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Figure 20-36. Failed Expressions Highlighted Red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Figure 20-37. Values of Local Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
Figure 20-38. View Thread at 150 ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Figure 20-39. ATV Window Shows Where Boolean Sub-Expression Failed. . . . . . . . . . . . 1142
Figure 20-40. ATV Window Displays All Clock Expressions . . . . . . . . . . . . . . . . . . . . . . . 1143
Figure 20-41. Root Thread Analysis of a Directive Failure . . . . . . . . . . . . . . . . . . . . . . . . . 1144
Figure 20-42. Root Thread Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Figure 20-43. ATV Mouse Hover Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Figure 20-44. ATV Mouse Hover Information - SystemVerilog . . . . . . . . . . . . . . . . . . . . . 1146
Figure 20-45. Local Variables Annotation in Thread Viewer Pane . . . . . . . . . . . . . . . . . . . 1146
Figure 21-1. SystemVerilog Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
Figure 21-2. Turning off Collection for a Coverpoint Using option.no_collect . . . . . . . . . . 1150
Figure 21-3. Functional Coverage Statistics in Covergroups Window . . . . . . . . . . . . . . . . . 1163
Figure 21-4. Creating Functional Coverage Text Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 1166
Figure 21-5. Filter Setup Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Figure 21-6. Create Filter Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Figure 21-7. Add-Modify Select Criteria Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Figure 21-8. Copy and Rename Filter Dialog Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Figure 21-9. Sample Output From vcover report Command. . . . . . . . . . . . . . . . . . . . . . . . . 1171
Figure 21-10. Hierarchical Instance Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Figure 21-11. Hierarchical Design Unit Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Figure 23-1. Verification of a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
Figure 23-2. Aggregated Coverage Data in the Structure Window. . . . . . . . . . . . . . . . . . . . 1241
Figure 23-3. Command Setup Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Figure 23-4. File Merge Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257

Questa® SIM User's Manual, v2023.4 51

 List of Figures

Figure 23-5. Example of File Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263

Figure 23-6. original.ucdb, dut.ucdb and tb.ucdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
Figure 23-7. Test Data in Verification Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Figure 23-8. Differing Merge and Rank Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Figure 23-9. Coverage Report Text Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Figure 23-10. Coverage HTML Report Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Figure 23-11. HTML Coverage Report Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293
Figure 23-12. Instance Coverage Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
Figure 23-13. Exclusion Comment Displays as Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
Figure 23-14. Hyperlinked Bins in the Hits Column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298
Figure 23-15. Test-Bins-Hit-Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Figure 23-16. HTML Coverage Report Cross Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
Figure 23-17. Coverage Exclusion Report Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1301
Figure 23-18. Filtering Displayed UCDB Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Figure 23-19. Filtering on User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Figure 24-1. Specifying Path in C Debug setup Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Figure 24-2. Setting Breakpoints in Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Figure 24-3. Right Click Pop-up Menu on Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Figure 24-4. Simulation Stopped at Breakpoint on PLI Task . . . . . . . . . . . . . . . . . . . . . . . . 1315
Figure 24-5. Stepping into Next File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316
Figure 24-6. Function Pointer to Foreign Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
Figure 24-7. Highlighted Line in Associated File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318
Figure 24-8. Stop on quit Button in C Debug Setup Dialog Box . . . . . . . . . . . . . . . . . . . . . 1321
Figure 25-1. Status Bar: Profile Samples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Figure 25-2. Ranked Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Figure 25-3. Design Units Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Figure 25-4. Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1332
Figure 25-5. Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333
Figure 25-6. Expand and Collapse Selections in Popup Menu . . . . . . . . . . . . . . . . . . . . . . . 1333
Figure 25-7. Profile Details Window: Function Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Figure 25-8. Profile Details Window: Instance Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Figure 25-9. Profile Details Window: Callers and Callees . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Figure 25-10. Accessing Source from Profile Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Figure 25-11. Profile Report Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338
Figure 25-12. Profile Report Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339
Figure 25-13. The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Figure 25-14. Displaying Capacity Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . 1347
Figure 27-1. JobSpy Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Figure 27-2. Job Manager View Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387
Figure 28-1. Waveform Editor: Library Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Figure 28-2. Results of Create Wave Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Figure 28-3. Opening Waveform Editor from Objects Windows . . . . . . . . . . . . . . . . . . . . . 1396
Figure 28-4. Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Figure 28-5. Wave Edit Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Figure 28-6. Manipulating Waveforms with the Wave Edit Toolbar and Cursors . . . . . . . . 1401

52 Questa® SIM User's Manual, v2023.4

List of Figures

Figure 28-7. Export Waveform Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403

Figure 28-8. Evcd Import Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Figure 29-1. SDF Tab in Start Simulation Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Figure 31-1. Breakpoint Flow Control in Nested DO Files. . . . . . . . . . . . . . . . . . . . . . . . . . 1480
Figure 31-2. Tcl Debugger for vsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
Figure 31-3. TDebug Choose Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
Figure 31-4. Setting a Breakpoint in the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
Figure 31-5. Variables Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
Figure A-1. Runtime Options Dialog: Defaults Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1500
Figure A-2. Runtime Options Dialog Box: Message Severity Tab . . . . . . . . . . . . . . . . . . . . 1501
Figure A-3. Runtime Options Dialog Box: WLF Files Tab . . . . . . . . . . . . . . . . . . . . . . . . . 1502
Figure E-1. InfoHub for QVIP Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1875
Figure E-2. QVIP API Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876
Figure E-3. Select Assertions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876
Figure E-4. QVIP Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1877
Figure E-5. Base QVIP Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1878
Figure E-6. Select Errors from QVIP Fundamentals List . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879
Figure E-7. Questa Verification IP Transactions in Wave Window . . . . . . . . . . . . . . . . . . . 1882
Figure E-8. Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
Figure E-9. Questa Verification IP Transaction at Different Levels of Abstraction . . . . . . . 1890
Figure E-10. Generation of Children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893
Figure E-11. Recognition into Parents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893
Figure E-12. Activate MVC_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1898
Figure E-13. Activating MVC_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1898
Figure E-14. Activates MVC_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899
Figure E-15. Send MVC_Message or MVC_Stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1900
Figure E-16. Sending MVC_Message or MVC_Stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1900
Figure E-17. Sent MVC_Message or MVC_Stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1901
Figure E-18. Receive MVC_transaction, MVC_Message or MVC_Stripe. . . . . . . . . . . . . . 1901
Figure E-19. Receiving MVC_transaction, MVC_Message or MVC_Stripe . . . . . . . . . . . . 1902
Figure E-20. Received MVC_Transaction, MVC_Message or MVC_Stripe . . . . . . . . . . . . 1902
Figure E-21. MVC_Transaction and MVC_Message Start and End Times . . . . . . . . . . . . . 1905
Figure E-22. MVC_Stripe Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1905
Figure F-1. DPI Use Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1921

Questa® SIM User's Manual, v2023.4 53

 List of Figures

54 Questa® SIM User's Manual, v2023.4

 List of Tables

Table 1-1. General Modes for Questa SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Table 1-2. Possible Definitions of an Object, by Language . . . . . . . . . . . . . . . . . . . . . . . . . 80
Table 1-3. Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Table 1-4. Deprecated Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 2-1. QIS Debug and Visibility Comparison with +acc . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 2-2. QIS Flow Use Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 5-1. Using the examine Command to Obtain VHDL Integer Data . . . . . . . . . . . . . . 209
Table 5-2. Using the examine Command to Obtain VHDL String Data . . . . . . . . . . . . . . . 210
Table 5-3. Using the examine Command to Obtain VHDL Record Data . . . . . . . . . . . . . . 210
Table 6-1. Evaluation 1 of always Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Table 6-2. Evaluation 2 of always Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Table 6-3. Utility System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Table 6-4. Utility System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Table 6-5. Utility System Math Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Table 6-6. Utility System Elaboration Tasks and Coverage Functions . . . . . . . . . . . . . . . . 275
Table 6-7. Utility System Severity and Assertion Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Table 6-8. Utility System Analysis Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Table 6-9. Input/Output System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Table 6-10. Input/Output System Memory and Argument Tasks . . . . . . . . . . . . . . . . . . . . 277
Table 6-11. Input/Output System File I/O Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Table 6-12. Other System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Table 6-13. Resolution Functions for wreal Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Table 6-14. Stepping Within the Current Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Table 6-15. Garbage Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Table 6-16. CLI Garbage Collector Commands and INI Variables . . . . . . . . . . . . . . . . . . . 362
Table 6-17. UVM Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Table 7-1. Supported Platforms for SystemC-2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Table 7-2. Specifying SystemC Platform and Compiler Version . . . . . . . . . . . . . . . . . . . . . 394
Table 7-3. Custom gcc Platform Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Table 7-4. Generated Extensions for Each Object Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Table 7-5. Time Unit and Simulator Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Table 7-6. Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Table 7-7. Mixed-language Compares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Table 7-8. Simple Conversion: sc_main to Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Table 7-9. Using sc_main and Signal Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Table 7-10. Modifications Using SCV Transaction Database . . . . . . . . . . . . . . . . . . . . . . . 451
Table 8-1. VHDL Types Mapped To SystemVerilog Port Vectors . . . . . . . . . . . . . . . . . . . 472
Table 8-2. SystemVerilog-to-VHDL Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Table 8-3. Verilog Parameter to VHDL Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Table 8-4. Verilog States Mapped to std_logic and bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

Questa® SIM User's Manual, v2023.4 55

 List of Tables

Table 8-5. VHDL to SystemVerilog Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Table 8-6. VHDL Generics to Verilog Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Table 8-7. Mapping VHDL bit to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Table 8-8. Mapping VHDL std_logic Type to Verilog States . . . . . . . . . . . . . . . . . . . . . . . 490
Table 8-9. Supported Types in SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Table 8-10. Supported Types in VHDL Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Table 8-11. Mapping Literals from VHDL to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . 491
Table 8-12. Mapping Table for Verilog-style Declarations . . . . . . . . . . . . . . . . . . . . . . . . . 493
Table 8-13. Mapping Table for SystemVerilog-style Declarations . . . . . . . . . . . . . . . . . . . 494
Table 8-14. Channel and Port Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Table 8-15. Data Type Mapping – SystemC to Verilog or SystemVerilog . . . . . . . . . . . . . 499
Table 8-16. Data Type Mapping – Verilog or SystemVerilog to SystemC . . . . . . . . . . . . . 501
Table 8-17. Mapping Verilog Port Directions to SystemC . . . . . . . . . . . . . . . . . . . . . . . . . 505
Table 8-18. Mapping Verilog States to SystemC States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Table 8-19. Mapping SystemC bool to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Table 8-20. Mapping SystemC sc_bit to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Table 8-21. Mapping SystemC sc_logic to Verilog States . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Table 8-22. SystemC Port Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Table 8-23. Mapping Between SystemC sc_signal and VHDL Types . . . . . . . . . . . . . . . . . 508
Table 8-24. Mapping VHDL Port Directions to SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Table 8-25. Mapping VHDL std_logic States to SystemC States . . . . . . . . . . . . . . . . . . . . 512
Table 8-26. Mapping SystemC bool to VHDL Boolean States . . . . . . . . . . . . . . . . . . . . . . 512
Table 8-27. Mapping SystemC sc_bit to VHDL bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Table 8-28. Mapping SystemC sc_logic to VHDL std_logic . . . . . . . . . . . . . . . . . . . . . . . . 512
Table 8-29. Mapping Literals from VHDL to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . 523
Table 8-30. Supported Types Inside VHDL Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Table 8-31. Supported Types Inside SystemVerilog Structure . . . . . . . . . . . . . . . . . . . . . . 525
Table 8-32. SystemC Types as Represented in SystemVerilog . . . . . . . . . . . . . . . . . . . . . . 559
Table 8-33. Channel and Port Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Table 8-34. Data Type Mapping - SystemC to Verilog or SystemVerilog . . . . . . . . . . . . . 565
Table 8-35. Data Type Mapping Verilog or SystemVerilog to SystemC . . . . . . . . . . . . . . . 568
Table 8-36. Language Port Types and Their Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 572
Table 9-1. Checkpoint and Restore Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Table 9-2. X propagation Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Table 9-3. If-else - Outputs with pass and resolve xprop Settings . . . . . . . . . . . . . . . . . . . . 607
Table 9-4. Latch - Outputs with pass and resolve xprop Settings . . . . . . . . . . . . . . . . . . . . 607
Table 9-5. Array-Index - Outputs with resolve xprop Setting . . . . . . . . . . . . . . . . . . . . . . . 607
Table 9-6. assign mux - Outputs with pass and resolve xprop Setting . . . . . . . . . . . . . . . . . 608
Table 9-7. Case Statements - Outputs with pass and resolve xprop Settings . . . . . . . . . . . . 608
Table 10-1. System Tasks and API for Recording Transactions . . . . . . . . . . . . . . . . . . . . . 635
Table 11-1. Questa Verification IP Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Table 11-2. Questa Verification IP Colors and Causation . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Table 12-1. WLF File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Table 12-2. Structure Tab Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Table 12-3. vsim Arguments for Collapsing Time and Delta Steps . . . . . . . . . . . . . . . . . . . 708

56 Questa® SIM User's Manual, v2023.4

List of Tables

Table 13-1. Add Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717

Table 13-2. Actions for Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Table 13-3. Find Previous and Next Transition Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Table 13-4. Two Cursor Zoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Table 13-5. Recording Delta and Event Time Information . . . . . . . . . . . . . . . . . . . . . . . . . 728
Table 13-6. Menu Selections for Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . 733
Table 13-7. Actions for Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Table 13-8. Mixed-Language Waveform Compares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Table 14-1. Code Preview Toolbar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Table 14-2. Icon and Menu Selections for Exploring Design Connectivity . . . . . . . . . . . . . 820
Table 14-3. Schematic Window Links to Other Windows and Panes . . . . . . . . . . . . . . . . . 843
Table 14-4. Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Table 15-1. Icon and Menu Selections for Exploring Design Connectivity . . . . . . . . . . . . . 860
Table 15-2. Dataflow Window Links to Other Windows and Panes . . . . . . . . . . . . . . . . . . 876
Table 16-1. Open a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Table 17-1. Setting Causality Traceback Report Destination . . . . . . . . . . . . . . . . . . . . . . . . 913
Table 17-2. Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Table 18-1. Code Coverage in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Table 18-2. Operators with Their Non-Masking States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Table 18-3. Auto-Exclusion Reason Codes in Coverage Reports . . . . . . . . . . . . . . . . . . . . 990
Table 18-4. Coverconstruct Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Table 19-1. Commands Used for FSM Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . 1049
Table 19-2. Commands Used to Capture FSM Debug Information . . . . . . . . . . . . . . . . . . . 1053
Table 19-3. FSM Coverage Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Table 19-4. Additional FSM-Related Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Table 19-5. Recognized FSM Note Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
Table 19-6. FSM Recognition Info Note Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
Table 20-1. Graphic Elements for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1095
Table 21-1. Questa SIM and SystemVerilog IEEE 1800-2009 Options . . . . . . . . . . . . . . . 1152
Table 21-2. Option Settings and Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Table 21-3. Which Form of Canonical Naming is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179
Table 22-1. Attributes Usable with randomize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Table 22-2. RNG Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
Table 22-3. Solver Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Table 23-1. Coverage Calculation for Each Coverage Type . . . . . . . . . . . . . . . . . . . . . . . . 1238
Table 23-2. Coverage Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Table 23-3. Predefined Fields in UCDB Test Attribute Record . . . . . . . . . . . . . . . . . . . . . . 1251
Table 23-4. Modes for Parallel Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Table 23-5. Merge List Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
Table 24-1. Simulation Stepping Options in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1312
Table 24-2. Command Reference for C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322
Table 25-1. Commands for Enabling and Viewing Capacity Analysis . . . . . . . . . . . . . . . . 1341
Table 26-1. Signal Spy Reference Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356
Table 27-1. Simulation Commands You can Issue from JobSpy . . . . . . . . . . . . . . . . . . . . . 1382
Table 28-1. Signal Attributes in Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397

Questa® SIM User's Manual, v2023.4 57

 List of Tables

Table 28-2. Waveform Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399

Table 28-3. Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
Table 28-4. Wave Editor Mouse/Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Table 28-5. Formats for Saving Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403
Table 28-6. Examples for Loading a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Table 29-1. Matching SDF to VHDL Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Table 29-2. Matching SDF IOPATH to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
Table 29-3. Matching SDF INTERCONNECT and PORT to Verilog . . . . . . . . . . . . . . . . 1418
Table 29-4. Matching SDF PATHPULSE and GLOBALPATHPULSE to Verilog . . . . . . 1418
Table 29-5. Matching SDF DEVICE to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
Table 29-6. Matching SDF SETUP to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
Table 29-7. Matching SDF HOLD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
Table 29-8. Matching SDF SETUPHOLD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
Table 29-9. Matching SDF RECOVERY to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Table 29-10. Matching SDF REMOVAL to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Table 29-11. Matching SDF RECREM to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Table 29-12. Matching SDF SKEW to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Table 29-13. Matching SDF WIDTH to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Table 29-14. Matching SDF PERIOD to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
Table 29-15. Matching SDF NOCHANGE to Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421
Table 29-16. RETAIN Delay Usage (default) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
Table 29-17. RETAIN Delay Usage (with +vlog_retain_same2same_on) . . . . . . . . . . . . . 1422
Table 29-18. Matching Verilog Timing Checks to SDF SETUP . . . . . . . . . . . . . . . . . . . . . 1423
Table 29-19. SDF Data May Be More Accurate Than Model . . . . . . . . . . . . . . . . . . . . . . . 1423
Table 29-20. Matching Explicit Verilog Edge Transitions to Verilog . . . . . . . . . . . . . . . . . 1423
Table 29-21. SDF Timing Check Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Table 29-22. SDF Path Delay Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Table 29-23. Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
Table 30-1. VCD Commands and SystemTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
Table 30-2. VCD Dumpport Commands and System Tasks . . . . . . . . . . . . . . . . . . . . . . . . 1442
Table 30-3. VCD Commands and System Tasks for Multiple VCD Files . . . . . . . . . . . . . . 1442
Table 30-4. SystemC Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Table 30-5. Driver States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Table 30-6. State When Direction is Unknown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Table 30-7. Driver Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
Table 30-8. VCD Values When Force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
Table 30-9. Values for file_format Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
Table 30-10. Sample Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
Table 31-1. Tcl Backslash Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
Table 31-2. Changes to Questa SIM Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
Table 31-3. Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
Table 31-4. Tcl List Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
Table 31-5. Tcl Time Conversion Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Table 31-6. Tcl Time Relation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Table 31-7. Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473

58 Questa® SIM User's Manual, v2023.4

List of Tables

Table 31-8. Commands for Handling Breakpoints and Errors in DO scripts . . . . . . . . . . . . 1481
Table 31-9. Tcl Debug States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
Table A-1. Commands for Overriding the Default Initialization File . . . . . . . . . . . . . . . . . 1499
Table A-2. Runtime Option Dialog: Defaults Tab Contents . . . . . . . . . . . . . . . . . . . . . . . . 1500
Table A-3. Runtime Option Dialog: Message Severity Tab Contents . . . . . . . . . . . . . . . . . 1502
Table A-4. Runtime Option Dialog: WLF Files Tab Contents . . . . . . . . . . . . . . . . . . . . . . . 1503
Table A-5. License Variable: License Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
Table A-6. MessageFormat Variable: Accepted Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
Table D-1. Severity Level Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
Table D-2. Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863
Table E-1. TQ_Id Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887
Table E-2. Parent/Child Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1891
Table E-3. Generation/Recognition Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . 1894
Table E-4. Deletion Related Series 50000 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896
Table E-5. Communication Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903
Table E-6. Volatile Clause Related Series 50000 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Table E-7. Activity Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907
Table E-8. Throw/Catch Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1908
Table E-9. TLM/WLM Related Series 50000 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1911
Table F-1. VPI Compatibility Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914
Table F-2. PCAT File — Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1931
Table F-3. PLI_Linkage Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1932
Table F-4. vsim Arguments for DPI Application Using External Compilation Flows . . . . 1945
Table F-5. Supported VHDL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953
Table F-6. Supported ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954
Table F-7. Supported TF Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1956
Table F-8. Values for action Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Table G-1. Files That Questa SIM Accesses During Startup . . . . . . . . . . . . . . . . . . . . . . . . 1963
Table G-2. Add Library Mappings to modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974

Questa® SIM User's Manual, v2023.4 59

 List of Tables

60 Questa® SIM User's Manual, v2023.4

 Chapter 1
Introduction

Questa SIM provides you with a simulation, debug, and verification platform for validating
FPGA and SoC designs.
For information on operating systems and platforms Questa SIM supports, see the Installation
and Licensing Guide.

Operational Structure and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Basic Steps for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
General Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Default stdout Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Definition of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Standards Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Command Line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Deprecated Features, Commands, and Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Operational Structure and Flow

You verify a design with Questa SIM using commands that provide a structure and flow as
shown in the figure.

Questa® SIM User's Manual, v2023.4 61

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

62 Questa® SIM User's Manual, v2023.4

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

Questa SIM requires specific files and libraries you must supply before performing a
simulation.
Files and Map Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 1 — Create Work and Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Step 2 — Compile the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 3 — Optimize the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 4— Load the Design for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 5 — Simulate the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Step 6 — Debug the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Questa® SIM User's Manual, v2023.4 63

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

Questa SIM must have access to certain files related to your design.
These files include the following:

• Design files (VHDL, Verilog, and/or SystemC), including stimulus for the design.
• Libraries, both working and resource.
• The modelsim.ini file, which the tool automatically creates when you issue the library
mapping command.
What is a Library?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Resource Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Mapping the Logical Work to the Physical Work Directory. . . . . . . . . . . . . . . . . . . . . . 65

What is a Library?
A library is a location on your file system that contains data to be used for simulation.
Questa SIM relies on and can manipulate the data in one or more libraries for simulation. A
library also helps to streamline simulation invocation.
Questa SIM uses the following 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 static, serving as a parts source for your design. You can create
your own resource libraries, or the libraries 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, Questa SIM 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

64 Questa® SIM User's Manual, v2023.4

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

module in a given library, Questa SIM recompiles only that module, rather than all modules in
the design.

Related Topics
Working Library Versus Resource Libraries
Library Window Contents
Working with Design 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 Questa SIM 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, Questa SIM can find libraries in your current directory (assuming they have the
right name), but for the tool 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.

Questa® SIM User's Manual, v2023.4 65

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

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}

Prerequisites
• Know the paths to the directories that contain your design files and resource libraries.
• Start Questa SIM.
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 a 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).

66 Questa® SIM User's Manual, v2023.4

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

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

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.

Questa® SIM User's Manual, v2023.4 67

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

Procedure
Depending on the language used to create your design, use one of the following Questa SIM
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 Questa SIM 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. Compiled Design

68 Questa® SIM User's Manual, v2023.4

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

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. Questa SIM 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.
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”.

Questa® SIM User's Manual, v2023.4 69

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Step 5 — Simulate 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
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 Questa SIM interactive commands. For example, force and bp.
• VCD files / commands.
Refer to “Creating a VCD File” and “Using Extended VCD as Stimulus.”

70 Questa® SIM User's Manual, v2023.4

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

• 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 Questa SIM GUI.
Procedure
Use any or all of the following commands to begin interactively debugging your simulation:

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

Questa® SIM User's Manual, v2023.4 71

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 Questa SIM: GUI mode,
command line mode, and batch mode.
The Questa SIM User’s Manual focuses primarily on the graphical user interface (GUI) mode
of operation—interacting with your simulation by working in the Questa SIM desktop with
windows, menus, and dialog boxes. However, Questa SIM also has a command line mode and
batch mode for compiling and simulating a design.
Table 1-1. General Modes for Questa SIM
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 using the -c argument of the vsim command:
vsim -c

This mode is non-interactive and displays 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 using the -b argument of the vsim command:
Simulation vsim -b

This mode invokes using a batch script. It is non-interactive and

displays no GUI or command line. Most commands and command
options are supported for use in the script.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Batch Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

72 Questa® SIM User's Manual, v2023.4

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 shell 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 shell and Windows
environments.

Startup Variable Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Here-Document Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
I/O Redirection Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Basic Command Line Editing and Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Supported Commands for Command Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Startup Variable Flow

In command line mode, Questa SIM 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.
If you invoke vsim from within a vsim invocation, some arguments are ignored because it is too
late for them to be applied. Arguments that are ignored include the following:
-batch -dpicpppath -mc2
-c -elab_cont -mvchome
-cppinstall -geometry -name
-cpppath -gui -sync
-colormap -i -visual
-display -lic_*
-dpicppinstall -load_elab

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 of the project
file (<Project_Root_Dir>/<Project_Name>.mpf).

Questa® SIM User's Manual, v2023.4 73

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

Related Topics
Startup

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

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

74 Questa® SIM User's Manual, v2023.4

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

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.

You should rename a transcript file that you intend to use as a DO file. If you do not rename the
file, Questa SIM 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

Basic Command Line Editing and Navigation

Command line mode enables basic command line editing and navigation techniques that you
may be familiar with from other command line environments.
These editing and navigation techniques include the following:

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

Questa® SIM User's Manual, v2023.4 75

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

Batch Mode Simulation

Batch Mode is an operational mode to perform simulations without invoking the GUI.
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.

The commands 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:

• vsim -batch — Enable batch mode for individual simulations with the -batch argument.
• BatchMode modelsim.ini variable — Enable this variable to turn on batch mode for all
your simulations. If you set this variable to 0 (default), vsim runs as if you specified the
vsim -i option. Transcript data goes to stdout by default. 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 Batch Mode variable, vsim
bypasses the variable if you specify the -batch, -c, -gui, or -i options to vsim.

Saving Batch Mode Simulation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Simulator Control Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Saving Batch Mode Simulation Data

Capture simulation data during batch mode for post-simulation analysis.

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

76 Questa® SIM User's Manual, v2023.4

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

Procedure
1. Determine how you want to view or save the transcript information.

If you want to ... Do the following:

Send tool output and your code output to This is the default behavior.
stdout vsim -batch …
Send tool output to a log file Add the following arguments to your vsim command
line:
vsim -batch -nostdout -logfile filename …
Redirect the tool output and your code Use file redirection with your vsim command line:
output to an external file vsim -batch … > filename
Send the tool output and your code Add the following arguments to your vsim command
output to stdout and tool output to a log line:
file (not recommended) vsim -batch -logfile filename …
Always send output to a logfile without Enable the BatchTranscriptFile modelsim.ini
command line arguments variable

2. Determine how you want vsim to generate the transcript information.

If you want the information to be ... Do the following:

Unbuffered, showing immediate results Add the -syncio argument to your vsim command
line.
Buffered, thus not available until the Add the -nosyncio argument to your vsim command
buffer is full or the simulation is line.
complete

Simulator Control Variables

Control the batch-mode simulation using modelsim.ini variables and Tcl variables.
Available modelsim.ini variables are as follows:
AccessObjDebug IgnoreSVAError StdArithNoWarnings
BreakOnAssertion IgnoreSVAFatal UserTimeUnit
CheckpointCompressMode IgnoreSVAInfo PrintSimStats
ClassDebug IgnoreSVAWarning WildcardFilter
DefaultForceKind IgnoreWarning WLFCompress
DefaultRadix IterationLimit WLFFilename

Questa® SIM User's Manual, v2023.4 77

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

DelayFileOpen NoQuitOnFinish WLFMCL

ForceSigNextIter NumericStdNoWarnings WLFOptimize
GCThreshold OnBreakDefaultAction WLFSizeLimit
IgnoreError OnErrorDefaultAction WLFTimeLimit
IgnoreFailure PathSeparator WLFUseThreads
IgnoreNote RunLength
Available Tcl variables are as follows:
now library architecture
delta entity resolution

Related Topics
modelsim.ini Variables

78 Questa® SIM User's Manual, v2023.4

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

Tool Statistics Messages

Each time you enter a command, the tool prints and sends this information to the Transcript
window and/or a logfile.
The tool displays the data similarly 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.

Questa® SIM User's Manual, v2023.4 79

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

Questa SIM supports the following standards:

• VHDL
o IEEE Std 1076-2008, IEEE Standard VHDL Language Reference Manual.
Questa SIM 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
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

80 Questa® SIM User's Manual, v2023.4

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

o IEEE Std 1076.2-1996, Standard VHDL Mathematical Packages

Any design developed with Questa SIM is compatible with any other VHDL system that
is compliant with the 1076 specifications.
• Verilog/SystemVerilog
o IEEE Std 1800-2017. IEEE Standard for SystemVerilog -- Unified Hardware
Design, Specification, and Verification Language
Questa SIM 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
Questa SIM 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.

Command Line Help

The QuestaSim commands vlog, vopt, vsim, vcom, vlib, visualizer, and sccom have built in
help on their arguments. Each command uses the same -help syntax.
The -help syntax is:

-help [all | category | <option> | <command-line> | <category_list>]

Questa® SIM User's Manual, v2023.4 81

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

• all — Display the entire arguments of the command by category.

• category — Lists all the categories of arguments.
• <option> — The specific argument to obtain help on.
• <category_list> — List all the arguments within a category.
For example, return the help summary for the vsim argument --lineinfo

vsim -help -lineinfo

List all the categories of vopt arguments.

vopt -help category

List all the vsim arguments just for the debug category.

vsim -help debug

Text Conventions
This manual uses a set of textual conventions.

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 Questa SIM (such as
DO, WLF, INI, MPF, PDF.)

82 Questa® SIM User's Manual, v2023.4

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

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, Siemens
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.)
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.

Questa® SIM User's Manual, v2023.4 83

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

84 Questa® SIM User's Manual, v2023.4

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

Questa SIM, 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.

The command you use to perform global optimizations in Questa SIM 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 vopt in the Reference Manual.

Questa Dumping and Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Optimization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Preservation of Object Visibility for Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Negation Arguments and Resolution with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Optimization of Parameters and Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Preoptimizing Regions of Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Alternate Optimization Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Preserving Design Visibility with the Learn Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Controlling Optimization from the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Optimization Considerations for Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Net Connectivity Tracing and VPI Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Questa Dumping and Visibility

The Questa Information System (QIS) enables full vopt simulations while providing debug or
visibility capabilities.
QIS eliminates the need to use the +acc argument with vopt for debug and visibility clients like
QWave dumping (Visualizer), VPI and so on. This provides the following advantages:

• Performance gain of full vopt.

• Identical behavior between full vopt and debug simulations.
• Complete file or line information in vsim fatal messages, infinite loop detection, and the
profiler.

Questa® SIM User's Manual, v2023.4 85

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

• Hierarchy visibility in the profiler and infinite loop detection.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

When using QIS, change the optimization options depending on usage and debug or visibility
capabilities.

• Debug — QIS provides design-wide capability to generate debug databases (for

example, Visualizer QWave, VCD, SAIF).
• Visibility — QIS provides access to specific signals or hierarchies of the design. This is
intended for targeted access (Tcl commands, UVM backdoor, Signal Spy, PLI/VPI/
FLI).

Enabling QIS Debug and Visibility

Enable QIS by using the following vopt arguments depending on what you want to do:

• -access
• -cellaccess
• -debug
Table 2-1 provides corresponding vopt and vsim arguments for QIS compared to +acc.
Table 2-1. QIS Debug and Visibility Comparison with +acc
+acc QIS Debug QIS Visibility
+acc=npr -debug vopt -access=rw+/.
+acc=c -debug,cell vopt -cellaccess=rw+/.
+acc -debug,cell vopt -access=rw+/. -cellaccess=rw+/.
+acc+/top/inst -debug vopt -access=rw+/top/inst
+acc=c+cellname -debug,cell vopt -cellaccess=rw+cellname
FSDB: +acc=npr not applicable vopt -access=r+/. -cellaccess=r+/.

Note that “rw” in the QIS Visibility Column of Table 2-1 means both read and write visibility is
needed for signals. Siemens recommends using “r” only if the clients do not need write access
to the signals. For example, the FSDB dumper needs only vpi read visibility; consequently, for
FSDB dumping, use “r” only with -access and -cellaccess arguments.

If you compile your design (or part of your design) with vopt -access or vopt -cellaccess,
Questa SIM uses only the visibility provided by the -access/-cellaccess options. It will not use
+acc visibility.

86 Questa® SIM User's Manual, v2023.4

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

For QWave logging, the logging level in vsim depends on the “vsim -qwavedb” option as
follows:

• For optimal performance, use “vsim -qwavedb =+signal”

• To enable cell logging with Visualizer, use “vsim -qwavedb=+cell”
• For full logging, use “vsim -qwavedb=+signal+memory+assertion+cell+class”

QIS Debug and Visibility Usage

Table 2-2 provides details about QIS use and options.
Table 2-2. QIS Flow Use Options
Flow/Argument Use
vopt -debug • Generating debug databases:
• QWAVE
• VCD
• SAIF
• No cell internals logged.
• No support for WLF.
vopt -debug,cell Same as -debug with extra logging for cell internals.
vopt debug,events Provides features for Visualizer events/deltas
debugging for Verilog/VHDL.
vopt -debug,livesim Provides features for Visualizer LiveSim debugging
(breakpoint and assertions).
vopt -access=r+<instance/module> Provides read visibility to signals or scopes:
• FSDB dumping
• PDU
• PLI/VPI/FLI
• Tcl commands
• Signal Spy
• UVM
vopt -access=w+<instance/module> Provides write visibility to signals or scopes:
• PDU
• PLI/VPI/FLI
• Signal Spy
• Tcl commands
• UVM
Note: The access=w argument impacts
performance and should be used only on
needed signals if possible.

Questa® SIM User's Manual, v2023.4 87

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

Table 2-2. QIS Flow Use Options (cont.)

Flow/Argument Use
vopt -cellaccess=r+<instance/module> Provides read visibility to cells’ internals. Used with
-access=r+ to give read visibility to both RTL
modules and cells.
vopt -cellaccess=w+<instance/module> Provides write visibility to cells’ internals. The
-access=rw+ argument can be used to document the
intent of both read and write access.
Note: The cellaccess=w argument impacts
performance and should be used only on needed
signals if possible.
Note: Write access is necessary for accurate net
connectivity tracing.

Cell Dumping Examples

The following examples illustrate using vopt for cell dumping.

Example 1
To dump ports of cells you need to add “-debug” to the vopt command and “-qwavedb=+signal”
to the vsim command.

vopt top -o opt -debug +designfile

vsim opt -qwavedb=+signal -do "run -all; quit -f"

Example 2
To dump cell internals to qwavedb you need to add “-debug,cell” to the vopt command and
“-qwavedb=+cells+signal” tot the vsim command.

vopt top -o opt -debug,cell +designfile

vsim opt -qwavedb=+cells+signal -do "run -all; quit -f"

Transcript Logging of All Forces/Releases

The -printforces argument for the vsim command enables transcript logging of all forces/
releases. Information reported in the transcript includes:

• The time that the force occurs (which, with delay, may be later then the time the force is
applied)
• The full path name of the object (if available)
• The value of the force
• The type of force (deposit, drive, freeze, release - if applicable)

88 Questa® SIM User's Manual, v2023.4

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

• The source of the force: FLI, Signal Spy, SystemC, SystemVerilog, VPI, TCL from the
VSIM prompt, TCL from a .do file, UVM (if available)
• The source file of the force (if available)
• The source file line number of the force (if available)
The transcript message displays the forces/releases information as a “Note” in the following
format:

# ** Note: (vsim-16110) Time <Time> : <SourceType>

<FileName>(<FileLineNumber>) <force/release> (<Force Type>) on
<SignalName> <Value>

For example:

# ** Note: (vsim-16110) Time 5 ns : verilog src/pdu/tb.sv(76) force on /top/bot/b

0101
# ** Note: (vsim-16110) Time 11 ns : fli force (deposit) on /top/vh1/bit_in 1
# ** Note: (vsim-16110) Time 11 ns : vpi release on /top/bot/b

# ** Note: (vsim-16110) Time 30 ns : tcl force (deposit) on /top/m/i 1

# ** Note: (vsim-16110) Time 50 ns : tcl force (freeze) on /top/m/b/io 1
# ** Note: (vsim-16110) Time 50 ns : tcl force (freeze) on /top/m/b/o 1

# ** Note: (vsim-16110) Time 50 ns : signal_force src/pdu_accessrw/tb.v(10) force

(freeze) on /tb/top/clk 1
# ** Note: (vsim-16110) Time 50 ns : signal_force src/pdu_accessrw/tb.v(9) force
(freeze) on /tb/top/clk 0
# ** Note: (vsim-16110) Time 60 ns : signal_force src/pdu_accessrw/tb.v(10) force
(freeze) on /tb/top/clk 1
# ** Note: (vsim-16110) Time 60 ns : signal_force src/pdu_accessrw/tb.v(9) force
(freeze) on /tb/top/clk 0

# ** Note: (vsim-16110) Time 90 ns : fli src/test01/tb.vhd force (deposit) on /tb/

dut/sig1 0

Questa® SIM User's Manual, v2023.4 89

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Two-Step Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The -O Optimization Control Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Inlined Modules and the Implications of Coverage Settings . . . . . . . . . . . . . . . . . . . . . . 94

Three-Step Flow
The three-step flow includes using the vopt command, which provides you with the most
control over the optimization process.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

The steps for this flow consist of the following Questa SIM 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.

90 Questa® SIM User's Manual, v2023.4

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 Questa SIM, 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 the +acc argument to the
vopt command. 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.”

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 (\).

Incremental Compilation of Named Designs

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

Questa® SIM User's Manual, v2023.4 91

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

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.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

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

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

2. Simulate — The vsim command performs the following actions:
a. Load — Runs in the background when the tool 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 the vsim command on the optimized design unit.
Because the tool calls the vopt command implicitly when using the two-step flow, Questa SIM
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. Increase this limit by using the -unnamed_designs argument with the vlib
command. Because the vsim command manages unnamed_designs, do not name an optimized
design using the -o argument in the -voptargs specification. For example,
vsim mydesign -voptargs="-o myoptdesign" generates an error message.

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

Preserving Object Visibility in the Two-Step Flow

With the two-step flow, use the -voptargs argument with the vsim command to preserve object
visibility and pass the arguments to the automatic invocation of vopt.

92 Questa® SIM User's Manual, v2023.4

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

The following examples demonstrate passing 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 vopt Three-Step and Two-Step flows are the primary usage models for Questa SIM
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.

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.

Questa® SIM User's Manual, v2023.4 93

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

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.

94 Questa® SIM User's Manual, v2023.4

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, preserve object visibility by using any of the various arguments to the
vopt command. These vopt arguments specify which objects remain accessible for the
simulation.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

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 +acc+mod1 mydesign -o mydesign_opt

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

vopt +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 +acc=npr3+top.netlist1 mydesign -o mydesign_opt

The following examples demonstrate more vopt +acc usage. In the Verilog environment
examples, the PathSeparator variable is set to a period (.):

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

vopt +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 +acc=p+top.netlist2. mydesign -o mydesign_opt

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

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

Questa® SIM User's Manual, v2023.4 95

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 line numbers and registers within a specific module and all
children in that module by adding a period (.) after the module name:
vopt +acc=lr+mod1. mydesign -o mydesign_opt

• 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 preserve access to “mod1a”, “mod2a”, “mod3a”, and so on.

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

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

96 Questa® SIM User's Manual, v2023.4

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

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

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

Questa® SIM User's Manual, v2023.4 97

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

Priorities for Resolving Conflicting Control

Arguments
When you use vopt commands containing both +<command> and +no<command> arguments,
Questa SIM applies resolution techniques for any conflicts that result.
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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

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

98 Questa® SIM User's Manual, v2023.4

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

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.

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

QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.
When you are running Questa SIM 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.

Questa® SIM User's Manual, v2023.4 99

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

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). Questa SIM 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, Questa SIM 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 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.
• Float — You can specify that parameters and generics should remain floating by using
the -floatparameters or -floatgenerics arguments, respectively, to the vopt command.
Questa SIM 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, Questa SIM

100 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 101

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

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, Questa SIM 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.

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, Questa SIM 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, Questa SIM 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.

102 Questa® SIM User's Manual, v2023.4

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

Simulating Designs with Multiple Test Benches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Extracting Visibility Requirements for PDUs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Using Configurations with Preoptimized Verilog Design Units . . . . . . . . . . . . . . . . . . . 105
Using Configurations with Preoptimized VHDL Design Units . . . . . . . . . . . . . . . . . . . . 107
Resolving Preoptimized Design Unit Loading Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Simulating Designs with Multiple Test Benches

When using multiple test benches to simulate a design, you typically use vopt -pdu to optimize
each design under test (DUT) 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
DUT.
The following steps demonstrate how to simulate and optimize Verilog test benches and DUTs.

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.

Questa® SIM User's Manual, v2023.4 103

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

vopt tb -o opt_tb

6. Simulate the first test bench.

vsim -c opt_tb -do sim.do

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.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

Prerequisites
• In order to maintain necessary visibility, run the vopt command with appropriate
-pduspec values and an acc file that contains all hierarchical references. In some
scenarios, you may need to run vsim -learn as well.
Refer to “Preserving Design Visibility with the Learn Flow” for more information.
Procedure
1. Compile your design:
vlog *.sv

2. (Optional) 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 step will create the file mylearn.acc.

104 Questa® SIM User's Manual, v2023.4

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

This step is required only when there are indirect hierarchical references used inside the
PDU, through PLI, VPI, or CLI commands. If there are direct language hierarchical
references used inside PDU, this step can be skipped.
3. Create the PDU visibility file, dut1.acc, using compiled top. If the mylearn.acc file is
generated by -learn in Step 2, specify that file here as well.
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 that references the visibility requirements generated in Step 3:
vopt -pdu -o dut1_pdu dut1 -f dut1.acc

5. Optimize the top-level design.

vopt -o top_opt top

If step 2 was run, you may want to include mylearn.acc for any visibility requirement
outside dut1
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

Questa® SIM User's Manual, v2023.4 105

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

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

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

106 Questa® SIM User's Manual, v2023.4

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

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;

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;

Questa® SIM User's Manual, v2023.4 107

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

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;

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"

108 Questa® SIM User's Manual, v2023.4

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

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)

# ** 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 Questa SIM.
• 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.

Questa® SIM User's Manual, v2023.4 109

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

• Library Path — Use soft links to resolve these physical links if necessary.

110 Questa® SIM User's Manual, v2023.4

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 Questa SIM simulations, you may find
these alternative variations to be useful in your environment.
Creating Locked Libraries for Multiple-User Simulation Environments . . . . . . . . . . . 111
Optimizing Liberty Cell Libraries for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

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.

Questa® SIM User's Manual, v2023.4 111

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.

112 Questa® SIM User's Manual, v2023.4

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.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

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

Questa® SIM User's Manual, v2023.4 113

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

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

114 Questa® SIM User's Manual, v2023.4

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

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

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.

Questa® SIM User's Manual, v2023.4 115

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Optimization on Designs Containing SDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Reports for Gate-Level Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Optimization of Precompiled Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Event Order and Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Timing Checks in Optimized Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Design Object Visibility for Designs with PLI

Some 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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

In the early stages of design, you can use one or more values to the +acc argument to the vopt
command 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

Note
It is suggested that you disable this automatic behavior, which can negatively affect the
performance of your simulation, with the -no_autoacc argument to vsim or follow the
directions in the section “Manual +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.

116 Questa® SIM User's Manual, v2023.4

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

Manual +acc for Designs with PLI

If you are manually controlling 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.

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.

Questa® SIM User's Manual, v2023.4 117

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

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

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

118 Questa® SIM User's Manual, v2023.4

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

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.

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

Event order dependencies are considered errors and should be corrected. Refer to Event
Ordering in Verilog Designs for more information.

Questa® SIM User's Manual, v2023.4 119

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

Timing Checks in Optimized Designs

When you run a simulation, Questa SIM 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 — Questa SIM 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 — Questa SIM evaluates conditional checks with delayed values, which
complies with the IEEE Std 1364-2005 specification.

Net Connectivity Tracing and VPI Queries

Net connectivity tracing from VPI queries may not be accurate without write access to target
nets.
Net connectivity tracing from VPI queries may not be accurate without write access to target
nets. For example, optimization can assign a common simulated net across a continuous assign,
and if only read access is specified, this can lead to simulated net collapse. You can avoid this
by adding write access to target nets to achieve expected net connectivity from VPI queries.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

Consider a continuous assign that is the only driver of a scalar net x. Net y has its own drivers
which are not shown.

assign x = y;

At any time during simulation, the values of x and y will be the same. The simulator doesn't
need to evaluate both nets for every simulation point, and can choose to hold only one value
during simulation.

Now consider a VPI application that will write or force a value to net x but not y. This action
can't be predicted from the HDL, separates the values of nets x and y, and invalidates the
previous optimization. It is necessary to add write access to net x to enable this write, and force
the simulator to hold these values separately.

Write access is necessary for net connectivity queries in this case, because net connectivity
analysis is based on simulated net connectivity in the kernel model. In the optimized case, x and
y have the same simulated net and all loads on both x and y will be reported, for example, by a

120 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Optimizing Designs with vopt
Net Connectivity Tracing and VPI Queries

vpiLoad query made on either net. Without the optimization, i.e. with write access, the
simulated nets for x and y will be different. The vpiLoad query will not report loads on the y
simulated net when net x is queried.

This is just one example. In general, the necessity for write access depends on the purpose for
which the VPI application is exploring net connectivity. In some cases, the simulated net
optimization might not matter. As a general rule, however, adding write access will probably
yield more intuitive results.

Questa® SIM User's Manual, v2023.4 121

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Optimizing Designs with vopt
Net Connectivity Tracing and VPI Queries

122 Questa® SIM User's Manual, v2023.4

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

Projects simplify the process of compiling and simulating a design and are useful for getting
started with Questa SIM.
What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
What are the Benefits of Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Project Conversion Between Simulator Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Getting Started with Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Open a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Simulate a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
The Project Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Creating a Simulation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Organizing Projects with Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Adding a Project Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Set File Properties and Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
File Compilation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Access Projects from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Questa® SIM User's Manual, v2023.4 123

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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Project Conversion Between Simulator Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

What are the Benefits of Projects?

Projects offer benefits to both new and advanced users.
• Projects simplify interaction with Questa SIM. 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.

124 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 125

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Add Source Files to the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Compile the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Change Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Auto-Generate the Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Grouping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Simulate a Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Open a New Project

To create a new Questa SIM 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 3-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 3-1. Create Project Dialog Box

3. Click OK.

126 Questa® SIM User's Manual, v2023.4

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 3-2)
Figure 3-2. Project Window Detail

and the Add Items to the Project dialog box opens. (Figure 3-3)
Figure 3-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 Questa SIM with a project open, Questa SIM automatically opens that same project
upon startup.
You can open a different or existing project by selecting File > Openand 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.

Questa® SIM User's Manual, v2023.4 127

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 3-4).
Figure 3-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 3-5. Add file to Project Dialog

b. Click OK.

128 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Compile the Files

Results
The files are added to the Project window.

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.

Questa® SIM User's Manual, v2023.4 129

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Projects
Change Compile Order

Figure 3-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, Questa SIM 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.

130 Questa® SIM User's Manual, v2023.4

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 3-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 3-7),
Questa SIM 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.

Questa® SIM User's Manual, v2023.4 131

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

132 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
Simulate a Design

Figure 3-9. Add Simulation Configuration Dialog Box — Design Tab

A new Structure window, named sim, appears that shows the structure of the active simulation
(Figure 3-10).

Figure 3-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 Questa SIM Tutorial for examples.

Questa® SIM User's Manual, v2023.4 133

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 3-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 Questa SIM 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.

134 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 135

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

136 Questa® SIM User's Manual, v2023.4

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 3-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 3-13. Simulation Configuration in the Project Window

Questa® SIM User's Manual, v2023.4 137

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

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

138 Questa® SIM User's Manual, v2023.4

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 3-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 3-16). Use the Place in Folder field to specify a folder.

Figure 3-16. Project Compiler Settings Dialog Box

On Windows platforms, you can also just drag-and-drop a file into a folder.

Questa® SIM User's Manual, v2023.4 139

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Setting Custom Double-click Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

140 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Projects
File Compilation Properties

Figure 3-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, Questa SIM 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.

Questa® SIM User's Manual, v2023.4 141

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 3-18. Project Settings Dialog Box

Convert Pathnames to Softnames for Location Mapping . . . . . . . . . . . . . . . . . . . . . . . . 142

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 3-18), enable
the checkbox for “Convert pathnames to softnames.”

142 Questa® SIM User's Manual, v2023.4

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 3-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 Questa SIM 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).

Questa® SIM User's Manual, v2023.4 143

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.

144 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 4
Design Libraries

VHDL designs are associated with libraries, which are objects that contain compiled design
units. SystemC, Verilog and SystemVerilog designs simulated within Questa SIM are compiled
into libraries as well.
QuestaSIM Library Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Working with Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Verilog Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
VHDL Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Importing FPGA Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Protecting Your Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Questa® SIM User's Manual, v2023.4 145

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Design Libraries
QuestaSIM Library Overview

QuestaSIM Library Overview

A QuestaSim library is a directory or archive that serves as a repository for compiled design
units.
The design units contained in a QuestaSIM library consist of VHDL, SystemC, and
SystemVerilog/Verilog code/constructs.

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Working Library Versus Resource Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

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

146 Questa® SIM User's Manual, v2023.4

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 Questa SIM — 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.

Caution
Do not put any of your files or files from third party vendors into any QuestaSIM working
library. In addition do not rename, edit, or change of the permissions of any QuestaSIM
generated file within a working directory. These actions may cause problems such as clashing
filenames, and problems in the future if any QuestaSIM generated file is updated for improved
features.

Questa® SIM User's Manual, v2023.4 147

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.
Questa SIM implements design libraries as directories, which can have any legal name allowed
by the operating system, with one exception: Questa SIM does not support extended identifiers
for library names.
Creating a Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Library Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Library Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Map a Logical Name to a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Move a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Setting Up Libraries for Group Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

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 Questa SIM graphic interface.
Note
When you create a project, Questa SIM automatically creates a working design library.

Procedure
You can use either of the following methods to create a working design library:

• From the Questa SIM 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 4-1.

148 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Library Size

Figure 4-1. Creating a New Library

Results
When you clickOK, Questa SIM 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 Questa SIM 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 Questa SIM GUI (Figure 4-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.

Questa® SIM User's Manual, v2023.4 149

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.

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 4-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 4-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.
• 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).

150 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Library Window Contents

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

Questa® SIM User's Manual, v2023.4 151

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 Questa SIM library directories. By
default, Questa SIM 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, Questa SIM 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, Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Mapping a Library from the Command Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Manual Mapping of the modelsim.ini File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

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.

152 Questa® SIM User's Manual, v2023.4

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 4-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 Questa SIM.
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

Questa® SIM User's Manual, v2023.4 153

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 Questa SIM 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/questasim/modelsim.ini

You can specify only one others clause in the library section of a given modelsim.ini file.

The “others” clause instructs Questa SIM to look only in the specified modelsim.ini file for a
library. It does not load any other part of the specified file.

154 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 155

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

Handling Sub-Modules with the Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
The LibrarySearchPath Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

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.

156 Questa® SIM User's Manual, v2023.4

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 vlog, 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 4-4.

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

Questa® SIM User's Manual, v2023.4 157

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, Questa SIM 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

158 Questa® SIM User's Manual, v2023.4

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

Alternate IEEE Libraries Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Regenerating Your Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

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.

Questa® SIM User's Manual, v2023.4 159

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

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 Questa SIM).
• ieee — (default) Contains precompiled Synopsys and IEEE arithmetic packages which
have been accelerated for Questa SIM, 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 themodelsim.ini file.

Regenerating Your Design Libraries

Depending on your current Questa SIM 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 Questa SIM. 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.
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 (VHDL or Verilog) Choose Library > Regenerate from the
main menu.
The command line (VHDL) Use vcom with the -refresh argument.

160 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Design Libraries
Importing FPGA Libraries

If you want to update from... Do the following...

The command line (Verilog) Use vlog with the -refresh argument.
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

Importing FPGA Libraries

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

Procedure
1. Select File > Import > Library to open the Import Library Wizard. (Figure 4-5)

Questa® SIM User's Manual, v2023.4 161

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

Figure 4-5. Import Library Wizard

2. Follow the instructions in the wizard to complete the import.

Protecting Your Source Code

The Questa® SIM Encryption User’s Manual 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.
Questa SIM Encryption User’s Manual

162 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 5
VHDL Simulation

Questa SIM enables you to compile, optimize, load, and simulate VHDL designs.
Basic VHDL Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Compilation and Simulation of VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Usage Characteristics and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
The TextIO Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
VITAL Usage and Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VHDL Utilities Package (util) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Modeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
VHDL Access Object Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Basic VHDL Usage

Using a VHDL design with Questa SIM consists of running the vcom, vopt, and vsim
commands to compile, optimize, load, and simulate. Note that you need to be familiar with any
setup requirements for running these commands, such as using the vlib command to create a
design library.
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.

Questa® SIM User's Manual, v2023.4 163

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Compilation of a VHDL Design—the vcom Command . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Simulation of a VHDL Design—the vsim Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

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
Questa SIM compiles one or more VHDL design units with a single invocation of the vcom
command, which functions as the VHDL compiler.
As a default, 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.

164 Questa® SIM User's Manual, v2023.4

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 either manually order the design units yourself on the command line, or you can use
the -autoorder argument. An -autoorder compilation determines the proper order of VHDL
design units independent of the order that you listed the files on the command line. Compilation
proceeds in a scan phase followed by a refresh phase. Without the argument, you must list
VHDL files in their proper compilation order.

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.

Questa® SIM User's Manual, v2023.4 165

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

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.
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 Questa SIM handles uppercase and lowercase names in
default bindings.

1. All VHDL names are case-insensitive, so Questa SIM 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, Questa SIM ignores the VHDL case and
looks first for the name in lowercase. If the lowercase name is present, Questa SIM uses
it.
3. If no lowercase version of the design unit name exists in the library, then Questa SIM
checks the library, ignoring case.
a. If ONE match is found this way, Questa SIM selects that design unit.
b. If NO matches or TWO or more matches are found, Questa SIM does not select
anything.

166 Questa® SIM User's Manual, v2023.4

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

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, Questa SIM looks for
"test" because previous releases always converted identifiers to lowercase.

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

Questa® SIM User's Manual, v2023.4 167

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

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
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 Questa SIM are more restrictive than those specified by the VHDL Language
Reference Manual (LRM). Questa SIM 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 Questa SIM to generate better error messages.

Subprogram Inlining
Questa SIM 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;

168 Questa® SIM User's Manual, v2023.4

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

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.

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 Linux or Windows).
Alternatively, you can use a project to simulate (refer to Getting Started with Projects) or
use the Start Simulation dialog box (choose Simulate > Start Simulation from 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

Questa® SIM User's Manual, v2023.4 169

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

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.

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.

170 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 Questa SIM that are not
explicitly covered by the Language Reference Manual (LRM).
Differences Between Supported Versions of the VHDL Standard . . . . . . . . . . . . . . . . . 171
Naming Behavior of VHDL for Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Foreign Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Simulator Resolution Limit for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Default Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Delta Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

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

Questa® SIM User's Manual, v2023.4 171

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 Questa SIM 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'."

172 Questa® SIM User's Manual, v2023.4

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
Questa SIM 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'.

Questa® SIM User's Manual, v2023.4 173

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 — Questa SIM 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).

174 Questa® SIM User's Manual, v2023.4

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.

All previously-generated scripts using an 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 Questa SIM 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.

Overriding the Default Resolution

To override the default resolution of Questa SIM, 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

Questa® SIM User's Manual, v2023.4 175

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Default Binding

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, Questa SIM 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 Questa SIM 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, Questa SIM searches the currently
visible libraries for an entity with the same name as the component. Questa SIM 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 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,
Questa SIM 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.

176 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Delta Delays

• If a configuration declaration contains library and use clauses, use them.

If none of these methods are successful, Questa SIM 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, Questa SIM 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, Questa SIM 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 Questa SIM 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."
Figure 5-1 illustrates the process for VHDL designs. This process continues until the end of
simulation time.

Questa® SIM User's Manual, v2023.4 177

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Delta Delays

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

During simulation an event on clk occurs (from the test bench). From this event, Questa SIM
performs the "clk2 <= clk" assignment and the process that is sensitive to clk. Before advancing
the simulation time, Questa SIM 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.

178 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
Delta Delays

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, Questa SIM defines
a limit, the “iteration limit", on the number of successive deltas that can occur. When
Questa SIM 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.

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

Questa® SIM User's Manual, v2023.4 179

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
VHDL Simulation
Delta Delays

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.

180 Questa® SIM User's Manual, v2023.4

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

STD_INPUT and STD_OUTPUT Within Questa SIM . . . . . . . . . . . . . . . . . . . . . . . . . . 182
TextIO Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Alternative Input/Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
The TEXTIO Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Input Stimulus to a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

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

Questa® SIM User's Manual, v2023.4 181

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

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

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 Questa SIM, 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

Questa SIM does not fully implement all facets of the TextIO package, which can result in
ambiguous results.

182 Questa® SIM User's Manual, v2023.4

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>/questasim/examples/vhdl/io_utils/io_utils.vhd.

Questa® SIM User's Manual, v2023.4 183

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, Questa SIM supplies hexadecimal routines in the io_utils package,
which is located in the file <install_dir>/questasim/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;

184 Questa® SIM User's Manual, v2023.4

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 Questa SIM installation includes a VHDL test bench as an example. Check for this file in
your installation directory:

<install_dir>/examples/gui/stimulus.vhd

Questa® SIM User's Manual, v2023.4 185

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.

VITAL Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

VITAL 1995 and 2000 Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VITAL Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Compiling and Simulating with Accelerated VITAL Packages . . . . . . . . . . . . . . . . . . . 188
Compiler Options for VITAL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

VITAL Source Code

The Questa SIM 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;

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.

186 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 VHDL Simulation
VITAL Compliance

Questa SIM VITAL built-ins are generally updated as new releases of the VITAL packages
become available.

VITAL Compliance
Questa SIM is compliant with IEEE Std 1076.4-2002, IEEE Standard for VITAL ASIC
Modeling Specification. In addition, Questa SIM 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.

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.

Questa® SIM User's Manual, v2023.4 187

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

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, Questa SIM 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

Compiler Options for VITAL Optimization

The vcom command has several arguments that control and provide feedback on VITAL
optimization.
• -novital

188 Questa® SIM User's Manual, v2023.4

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)

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 Questa SIM commands.
The package is part of the modelsim_lib library, which is located in the /questasim 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

Return Values

Name Type Description

resval real The simulator resolution represented as a
real

Questa® SIM User's Manual, v2023.4 189

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)

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.

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.

190 Questa® SIM User's Manual, v2023.4

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)

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

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

Questa® SIM User's Manual, v2023.4 191

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)

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.

192 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Effects on Performance by Canceling Scheduled Events. . . . . . . . . . . . . . . . . . . . . . . . . 203

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.

Questa® SIM User's Manual, v2023.4 193

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 5-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 5-2 is a package (named conversions) that is included by the memory model in
Example 5-1.
• Example 5-3 is provided for completeness—it shows protected types using VHDL 2002.
Note that using protected types offers no advantage over shared variables.
Example 5-1. Memory Model Using VHDL87 and VHDL93 Architectures

Example functions are provided below in package “conversions.”

194 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 195

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;

196 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 197

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;

198 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 199

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;

-------------------------------------------

200 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 201

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;

202 Questa® SIM User's Manual, v2023.4

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;

Questa® SIM User's Manual, v2023.4 203

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 Questa SIM to log and display dynamic simulation data. You enable this
logging by specifying vsim -accessobjdebug.
When logging a VHDL variable of an access type, Questa SIM 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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

VHDL Access Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Default Behavior—Logging and Debugging Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Logging and Debugging Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
The examine and describe Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

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.

204 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 205

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 Questa SIM 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.
Questa SIM 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).

206 Questa® SIM User's Manual, v2023.4

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 Questa SIM.
• 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

Questa® SIM User's Manual, v2023.4 207

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

208 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 209

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 5-1. Using the examine Command to Obtain VHDL Integer Data (cont.)
Command Value Returned with Value Returned with
Logging Disabled Logging Enabled
(vsim -noaccessobjdebug) (vsim -accessobjdebug)
examine v1.all 5 5
examine @ptr@1 error 5

String
Table 5-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 5-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 5-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.
Table 5-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

210 Questa® SIM User's Manual, v2023.4

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 5-3. Using the examine Command to Obtain VHDL Record Data (cont.)
Command Value Returned with Value Returned with
Logging Disabled Logging Enabled
(vsim -noaccessobjdebug) (vsim -accessobjdebug)
examine v1.all {5, "abcdef"} {5, "abcdef"}
examine v1.f1 5 5
examine v1.all.f1 5 5
examine @ptr@1.f1 error 5

Questa® SIM User's Manual, v2023.4 211

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

212 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 6
Verilog and SystemVerilog Simulation

Introduction to the process of compiling and simulating Verilog and SystemVerilog designs
with Questa SIM.
Standards, Nomenclature, and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Basic Verilog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Verilog Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Cell Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
SystemVerilog System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Digital Mixed-Signal for Verilog and SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Sparse Memory Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Unmatched Virtual Interface Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Verilog PLI and SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
SystemVerilog Class Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
OVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
UVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Autofindloop and the Autofindloop Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Questa® SIM User's Manual, v2023.4 213

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

The SystemVerilog 1800 standard subsumes the IEEE Std 1364 for 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.

Questa SIM implements the SystemVerilog IEEE 1800-2017, 1800-2012, 1800-2009 and 1800-
2005 (SystemVerilog) standards.

The SystemVerilog 1800-2017 standard includes:

• Design specification methods

• An embedded assertions language
• A testbench language that includes a coverage and assertions application programming
interface (API)
• A direct programming interface (DPI).
In this chapter, the following terms apply:

• “Verilog” refers to IEEE Std 1364 for Verilog.

• “Verilog-1995” refers to IEEE Std 1364-1995 for Verilog.
• “Verilog-2001” refers to IEEE Std 1364-2001 for Verilog.
• “Verilog-2005” refers to IEEE Std 1364-2005 for Verilog.
• “SystemVerilog” refers IEEE Std 1800-2017 for SystemVerilog.

Note
The term “Language Reference Manual” (or LRM) refers to the current IEEE
standard for SystemVerilog.

Supported Variations in Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

for Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Naming Macros with Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

214 Questa® SIM User's Manual, v2023.4

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

Supported Variations in Source Code

Questa SIM enables you 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
Questa SIM allows you to use Verilog syntax that omits any or all three specifications of a for
loop — initialization, termination, increment. These allowed omissions are also allowed in C.
Note
If you use this variation, a suppressible warning (2252) is displayed, which you can change
to an error with the vlog -pedanticerrors command.

The following examples show the missing for loop specifications this variation allows:

• 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 compiles macros named with integers in addition to identifiers.

Questa® SIM User's Manual, v2023.4 215

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

The following compiler directives also accept integer names as well as IEEE-1800 Language
Reference Manual macro names:

‘define
‘else
‘elsif
‘endif
‘ifdef
‘undef

You can disable this functionality by specifying vlog -pedanticerrors.

216 Questa® SIM User's Manual, v2023.4

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 include the steps of compiling, optimizing, loading, and simulating.
Generally you perform the steps in the following order:

1. Compile your Verilog code into one or more libraries with the vlog command.
2. (Optional) Elaborate and optimize your design with the vopt command. See
“Optimizing Designs with vopt” on page 85 and “Optimization Considerations for
Verilog Designs” on page 116.
3. Load your design with the vsim command.
4. Simulate the loaded design and debug as needed.
Verilog Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Initializing enum Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Library Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
SystemVerilog Multi-File Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Verilog-XL Compatible Compiler Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Verilog Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Verilog Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Initializing Registers and Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Questa® SIM User's Manual, v2023.4 217

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 with the vlog command, or select Compile > Compile.
Questa SIM provides an alternative flow that combines the compile, optimize, and simulate
phases into one command.

Creating a Working Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Invoking the Verilog Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Verilog Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Parsing SystemVerilog Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Recognizing SystemVerilog Files by File Name Extension . . . . . . . . . . . . . . . . . . . . . . . 220

Creating a Working Library

Before you can compile your design, you must create a library in which to store the compilation
results, which is compatible across all platforms.
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.

Note
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.
Prerequisites
Create a working library.

218 Questa® SIM User's Manual, v2023.4

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
Enter the vlog command or choose Compile > Compile from the main menu to invoke the
Verilog compiler.

As the design compiles, the complier also generates the resulting object code for
modules and user-defined primitives (UDPs) 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 (you can use any combination of suffixes).
Compilation only works on referenced definitions. Compilation does accept compressed
SystemVerilog source files (.gz extension, compressed with zlib).

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.
Verilog compilation parses SystemVerilog keywords when either of the following situations
exists:

• Any file in 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 Questa SIM:

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 Questa SIM to parse
SystemVerilog keywords. In the second example, the -sv argument enables SystemVerilog
features and keywords.

Questa® SIM User's Manual, v2023.4 219

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. However, the addition of new reserved keywords has
the potential to break backward compatibility, especially when using the -sv switch on legacy
Verilog files. Questa SIM recognizes all reserved keywords listed in Table B-1 in Annex B of
IEEE Std 1800-2017.

Older Verilog and SystemVerilog code can use words as identifiers that are now considered
reserved keywords. For example, bit and logic were added in the IEEE Std 1800-2005, so they
may no longer be used as identifiers in SystemVerilog code. To manage which keywords are
recognized as reserved, you can do one of the following to avoid a compilation error:

• Modify the existing identifiers in your code. You can add one or more characters as a
prefix or suffix (such as an underscore: _bit) to the identifier, which causes the identifier
to not be recognized as a reserved keyword.
• Use the SystemVerilog pragmas `begin_keywords and `end_keywords to define regions
where only the older keywords are recognized. See section 22.14 `begin_keywords,
`end_keywords in the IEEE Std 1800-2017.
• Append different file extensions so that Questa SIM recognizes each file extension as
belonging to a different version of the standard using the -svfilesufix command.
• Compile your designs separately with different comparability switches (for example,
-sv05compat).

Recognizing SystemVerilog Files by File Name Extension

If you use the -sv argument with the vlog command, Questa SIM 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, Questa SIM assumes that only files
with the extension .sv, .svh, or .svp are SystemVerilog.

File extensions of include files

If you do not use the -sv argument with vlog when specifying a file that uses an `include
statement to specify an include file, the compilation will ignore the file extension of the include
file and assume the language to be the same as the file containing the `include. For example, if
you do not use the -sv argument:

• If a.v includes b.sv, then b.sv is read as a Verilog file.

• If c.sv includes d.v, then d.v is read as a SystemVerilog file.

220 Questa® SIM User's Manual, v2023.4

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

File extension settings in modelsim.ini

You can define which file extensions indicate SystemVerilog files with the SVFileExtensions
variable in the modelsim.ini file, where the default setting is:

; SVFileExtensions = sv svp svh

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 Questa SIM changes from
one compilation unit to another.

By default, Questa SIM instructs the compiler to treat all SystemVerilog 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

Questa SIM 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:

• Any Verilog source read in is added to the current compilation unit.

• A compilation unit ends at the close of a SystemVerilog file.

Note
Keep all Verilog files in the same compilation unit to maintain backward compatibility with
legacy Verilog designs.

Initializing enum Variables

By default, to initialize enum variables Questa SIM uses the default value of the base type
instead of the leftmost value.

Questa® SIM User's Manual, v2023.4 221

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 can use the following methods to change the default behavior so that Questa SIM sets the
initial value of an enum variable to the left most value:

• Run vlog -enumfirstinit when compiling and run vsim -enumfirstinit when simulating.
• Set EnumBaseInit = 0 in the modelsim.ini file.

Incremental Compilation
Questa SIM supports incremental compilation of Verilog and SystemVerilog designs—there is
no requirement to compile an entire design in one invocation of the compiler.
You are not required to compile your design in any particular order because compilation
resolves all module and UDP instantiations and external hierarchical references when the
simulator loads the design. Two exceptions require stable compile ordering:

• Compiler directives within a individual compilation unit such as `define and `timescale
are subject to compilation order differences.
• SystemVerilog packages must be complied before any direct reference or import.
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 6-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

222 Questa® SIM User's Manual, v2023.4

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

Compile the design incrementally as follows:

vlog testbench.sv
# Top level modules:
# testbench

vlog -sv test1.v

# Top level modules:
# dut

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. When you use the -incr argument, the
compiler automatically determines which modules have changed, and generates 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

If you modify the functionality of the or2 module:

vlog -incr top.v and2.v or2.v

Questa® SIM User's Manual, v2023.4 223

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

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

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 Questa SIM can trace
back to the correct areas of the source code.

Library Usage
You must compile all modules and UDPs in a Verilog design 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

224 Questa® SIM User's Manual, v2023.4

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 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 compilation does not determine instantiation bindings at compile time, you must
instruct the simulator to search your libraries when loading the design. Simulation loads the top-
level modules from the library named work unless you prefix the modules with the <library>.
option. If simulation does not find them in the work library, it searches 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.

Questa® SIM User's Manual, v2023.4 225

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

Questa SIM allows you to compile multiple SystemVerilog files at a time.
Declarations in Compilation Unit Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Macro Definitions and Compiler Directives in Compilation Unit Scope . . . . . . . . . . . . 226

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. It is important to understand how the simulator defines
compilation units 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 SystemVerilog source file
on the command line. 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.
When you use 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 the
vlog -sfcu command.

Macro Definitions and Compiler Directives in Compilation

Unit Scope
According to the SystemVerilog LRM, the visibility of macro definitions and compiler
directives spans the lifetime of a single compilation unit.
By default, this means the definitions of macros and the 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

226 Questa® SIM User's Manual, v2023.4

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

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.

See Declarations in Compilation Unit Scope for instructions on how to control how vlog
handles compilation units.

Note
Compiler directives revert to their default values at the end of a compilation unit.

If you specify a compiler directive as an option to the compiler, it uses this setting for all
compilation units present in the current compilation.

When you are in MFCU mode, despite a unit scope starting in a Verilog file, the simulator will
pull in built-in macros and directives (including, `undefineall, SV_COV_*, mtiTypename*)
upon transition from a Verilog file to a SystemVerilog file.

Questa® SIM User's Manual, v2023.4 227

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 Verilog compiler supports arguments that are equivalent to Verilog-XL arguments,
simplifying the porting of a design to Questa SIM.
+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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Verilog-XL uselib Compiler Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Arguments Supporting Source Libraries

The Verilog compiler provides arguments that support source libraries in the same manner as
Verilog-XL.
Note that source libraries are very different from the libraries that the Questa SIM compiler uses
to store compilation results.

The compiler searches source libraries after compiling the source files on the command line. If
there are any unresolved references to modules or UDPs, then the compiler searches the source
libraries to satisfy them. The modules vlog compiles from source libraries may in turn have
additional unresolved references that trigger another search of the source libraries. The compiler
repeats this process until it resolves all references or until there are no longer any new
unresolved references. The compiler searches source libraries in the order they appear on the
command line.

-v <filename>
-y <directory>
+libext+<suffix>
+librescan
+nolibcell
-R [<simargs>]

Verilog-XL uselib Compiler Directive

The `uselib compiler directive is a method of source library management that you can use as an
alternative to the -v, -y, and +libext compiler arguments. It has the advantage that a design may
reference different modules having the same name.

228 Questa® SIM User's Manual, v2023.4

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

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

Because the `uselib directives are embedded in the Verilog source code, you have 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.

Because the `uselib directive allows a design to reference multiple modules that have the same
name, the source libraries referenced by the `uselib directive must be compiled independently.

You should compile each source library into its own object library. The compilation of the code
containing the `uselib directives records only which object libraries to search for each module
instantiation when the simulator loads the design.

Questa® SIM User's Manual, v2023.4 229

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

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 ignores 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 that you
can define 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, Questa SIM determines the directory into which 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

230 Questa® SIM User's Manual, v2023.4

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 you can instantiate two
different modules that have the same name 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 instantiation 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 can 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. Because srtr.v is compiled after dut.v, the `uselib
directive is still in effect. When srtr loads, it uses 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.

Questa® SIM User's Manual, v2023.4 231

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 support for configurations. Configurations specify how a
design is “assembled” during the elaboration phase of simulation. A configuration consists of
two pieces: the library mapping and the configuration itself. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Configurations and the Library Named work

Questa SIM treats 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.

232 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 233

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

Questa SIM implements the rules for generate statements adopted for Verilog 2005. Most of the
2005 rules are backwards compatible, but there is one key difference related to name visibility.
Name Visibility in Generate Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

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 Questa SIM. 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 Questa SIM, 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 is excluded in the second example.

234 Questa® SIM User's Manual, v2023.4

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.
The vlog, vopt, and vsim commands control initialization of registers and memories with the
following arguments:

• Registers: vlog +initreg, vopt +initreg, and vsim +initreg

• Memories: vlog +initmem, vopt +initmem, and vsim +initmem
You can generate a report of the initial values generated for registers and memories with
+initmem and +initreg.

You can use the +initregNBA and +noinitregNBA arguments to control whether +initreg
settings applied to registers of sequential UDPs are blocking or non-blocking. This can be
useful in cases where continuous assignments overwrite register initialization. The default
+initreg behavior is non-blocking, or +initregNBA.

Initialization Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Initializing with Specific Values — Enabled During Compilation . . . . . . . . . . . . . . . . . 236
Initializing with Specific Values — Enabled During Optimization . . . . . . . . . . . . . . . . 236
Initializing with Random Values — Enabled During Compilation . . . . . . . . . . . . . . . . 237
Initializing with Random Values — Enabled During Optimization . . . . . . . . . . . . . . . . 237
Recording Initialization Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Initialization Concepts
When initializing registers and memories, it is important to understand the concepts of random
stability and sequential UDPs.
• For sequential Random stability — From run to run, it is reasonable to expect that
simulation results will be consistent with the same seed value, even when you recompile
the design or specify different optimization switches.
However, if the design changes in any way, random stability can not be ensured. 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.

Questa® SIM User's Manual, v2023.4 235

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

For Sequential UDPs, the simulator produces repeatable initial values only if the design
is compiled and run with the same vlog, vopt, and vsim settings.
• 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.

Requirements
• Prepare your libraries with vlib and vmap as you would normally.

Initializing with Specific Values — Enabled During

Compilation
You can enable initialization with specific values to occur during compilation.
Procedure
1. Compile the design unit with the +initreg or +initmem arguments to the vlog command.
Refer to the vlog command reference page for descriptions of the following arguments.
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
You can enable initialization with specific values to occur during optimization.
Procedure
1. Compile as you would normally
2. Optimize the design with the +initreg or +initmem arguments to the vopt command.
Refer to the vopt command reference page for a description of the following arguments.
a. Specify which datatypes should be initialized: +{r | b | e | u}.
b. Specify the initialization value: +{0 | 1 | X | Z}.

236 Questa® SIM User's Manual, v2023.4

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

c. Specify design unit name: +<selection>

3. Simulate as you would normally.

Initializing with Random Values — Enabled During

Compilation
You can enable initialization with random values to occur during compilation.
Procedure
1. Compile the design unit with the +initreg or +initmem arguments to the vlog command.
Refer to the vlog command reference page for descriptions of the following arguments.
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> arguments. Refer to the vsim command reference page for a
description of these arguments. The random values will include only 0 or 1.
If no +initreg is present on the vsim command line, the simulation uses a random seed of
0 during initialization.

Initializing with Random Values — Enabled During

Optimization
You can enable initialization with random values to occur during optimization.
Procedure
1. Compile as you would normally
2. Optimize the design with the +initreg or +initmem arguments to the vopt command.
Refer to the vopt command reference page for a description of the following arguments.
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> arguments. Refer to the vsim command reference page for a
description of these arguments. The random values include only 0 or 1.

Questa® SIM User's Manual, v2023.4 237

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

If no +initreg is present on the vsim command line, the simulation uses a random seed of
0 during initialization.

Recording Initialization Values

You can save a report of the seed values generated by the +initmem and +initreg arguments by
specifying the -initreport <filename> argument on the vsim command line.
Refer to vsim -initreport <filename> for more information.

238 Questa® SIM User's Manual, v2023.4

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 you compile it with vlog and, if desired, you
optimize it with vopt. You can then invoke the simulator 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 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.

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

Modules Without Timescale Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Multiple Timescale Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Choosing the Resolution for Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Event Ordering in Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Debugging Event Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Signal Segmentation Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Handling Negative Timing Check Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Force and Release Statements in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Verilog-XL Compatible Simulator Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Using Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

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.

Questa® SIM User's Manual, v2023.4 239

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Modules Without Timescale Directives

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.

You can specify time units and precision 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. The simulator issues an elaboration error in this situation. You should make
sure that all modules having delays also have timescale directives so that the timing of the
design operates as you intend.
You can use the following vsim arguments to suppress elaboration errors or reduce them to
warnings, but you risk improper design behavior and reduced performance.

• Use the vsim +nowarnTSCALE or -suppress arguments to ignore the error.

• Use the -warning argument to reduce the severity to a warning.

-timescale Option
Use the -timescale option 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"

The quotation marks in the example above are required because the argument contains white
space.

240 Questa® SIM User's Manual, v2023.4

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

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)

You can suppress the error, causing vsim to use the simulator time resolution.

Multiple Timescale Directives

A design can have multiple timescale directives. Separately compiled modules can also have
different timescales. The simulator compares the timescale of all of the modules in a design, and
uses the smallest timescale 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 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 simulation handles the delays in the
module in each case:

• -t not set — The delay is rounded to 12.5 as directed by the module’s ‘timescale
directive.

Questa® SIM User's Manual, v2023.4 241

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. The simulator determines the module’s
precision by the `timescale directive. Questa SIM does not override the module’s
precision.
• -t is set to 1 ns — The delay is rounded to 13. The simulator determines the module’s
precision by the -t setting. Questa SIM 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, setting the time precision unnecessarily
small can degrade performance.

242 Questa® SIM User's Manual, v2023.4

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 Questa SIM can process multiple events at a given simulation
time. The Verilog language definition does not provide you control of the processing order of
simultaneous events. Some designs rely on a particular event order, and these designs may
behave differently than you expect.
Event Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Controlling Event Queues with Blocking or Non-Blocking Assignments . . . . . . . . . . . 245

Event Queues
Section 11 of IEEE Std 1364-2005 defines several event queues that determine how 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.
You cannot control event order in the active event queue. Active events are processed in any
order, and new active events are added in any order. The example below illustrates potential
ramifications of this situation.

Assume that these four statements are in the event queue:

• always@(q) p = q;

Questa® SIM User's Manual, v2023.4 243

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

Table 6-1 and Table 6-2 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 6-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 6-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)

244 Questa® SIM User's Manual, v2023.4

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 that you can assign an event to a particular queue.
You do this with 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.)

You should use non-blocking assignments only for outputs of flip-flops. This ensures that
outputs of flip-flops do not change until after all flip-flops have been evaluated. If you attempt
to use non-blocking assignments in combinational logic paths to remove race conditions, you
may only cause more problems.

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

Questa® SIM User's Manual, v2023.4 245

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

In the example above, 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.

246 Questa® SIM User's Manual, v2023.4

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, Questa SIM tries to duplicate Verilog-
XL event ordering to ease the porting of those models to Questa SIM. However, Questa SIM
does not match Verilog-XL event ordering in all cases, and if a model ported to Questa SIM
does not behave as expected, there may be event order dependencies.
Questa SIM helps you track down event order dependencies with the following vlog compiler
arguments: -compat, -hazards, and -keep_delta.

Hazard Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Hazard Detection and Optimization Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

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.
To enable hazard detection you must invoke vlog with the -hazards argument when you compile
your source code, and you must invoke vsim with the -hazards argument when you simulate.

Questa SIM 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. The simulator calls this a READ/WRITE hazard if the simulator
executed the read first.
• WRITE/READ — This hazard is similar to a READ/WRITE hazard except that the
simulator executes the write first.
The simulator 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.

Note
Using the -hazards argument implicitly enables the -compat argument. As a result, using -
hazards may affect your simulation results.

Hazard Detection and Optimization Levels

The optimization level you use in a simulation can have an affect on hazard detection results.
Some optimizations change the read/write operations performed on a variable if the
transformation is determined to produce similar results. Because the hazard detection algorithm

Questa® SIM User's Manual, v2023.4 247

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

cannot determine whether the read/write operations can affect the simulation results, the
optimizations can result in different hazard detection results. Generally, optimizations reduce
the number of false hazards by eliminating unnecessary reads and writes, but optimizations can
produce additional false hazards. The following are some 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.
• 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 code attempts to initialize a property of obj, but obj has not been constructed. The code is
missing the following information:

C obj = new;

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 is nothing to reference. The simulator
sets the variable to the value null and the SIGSEGV fatal error occurs.

248 Questa® SIM User's Manual, v2023.4

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

To debug a SIGSEGV error, first look in the transcript. Figure 6-1 shows an example of a
SIGSEGV error message in the Transcript window.

Figure 6-1. Fatal Signal Segmentation Violation (SIGSEGV)

The Fatal error message identifies the filename and line number of the code violation (in this
example, the file is top.sv and the line number is 19).

Questa SIM sets the active scope to the location of the error. In the Processes window, the
current process is highlighted (Figure 6-2).

Figure 6-2. Current Process Where Error Occurred

Double-click the highlighted process to open a Source window. A blue arrow points to the
statement where the simulation stopped executing (Figure 6-3).

Figure 6-3. Blue Arrow Indicating Where Code Stopped Executing

Next, look for null values in the Questa SIM Locals window (Figure 6-4), which displays data
objects declared in the local (current) scope of the active process.

Questa® SIM User's Manual, v2023.4 249

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 6-4. Null Values in the Locals Window

The null value in Figure 6-4 indicates that the object handle for obj was not properly
constructed with the new operator.

250 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 the chapter “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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Commands Supporting Negative Timing Check Limits . . . . . . . . . . . . . . . . . . . . . . . . . 252
Negative Timing Constraint Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Using Delayed Inputs for Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Re-evaluation of Zero-Delay Output Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

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
argument.
• 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.
• vsim -glsnegtchk <solver_level> — Specifies the negative timing check solver.

Questa® SIM User's Manual, v2023.4 251

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, the simulator 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 to be evaluated
correctly. These timing checks specify delayed versions of the input ports. The delayed versions
are used for functional evaluation. The following sections describe the correct syntax for
$setuphold and $recrem.

$setuphold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
$recrem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Timing Check Syntactical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

252 Questa® SIM User's Manual, v2023.4

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 determines 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. Because $setuphold combines the
functionality of the $setup and $hold system tasks, the reference_event sets the upper bound
event for $setup and the lower bound event for $hold.
• 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:
o First instance — The data_event and the clk_event. Any change to the data signal
within this interval results in a timing violation.
o 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.
• 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.

Questa® SIM User's Manual, v2023.4 253

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.

254 Questa® SIM User's Manual, v2023.4

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 determines 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:
o 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.
o 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.

Questa® SIM User's Manual, v2023.4 255

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 behaves 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 is greater than zero (0). If sum does 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) 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 determines the proper delay values; a negative hold
requires the shifting of your DATA signal, and a negative setup requires the shifting of your
CLOCK. In rare cases, typically due to bad SDF values, the timing check algorithm cannot
create convergence. Use the +ntc_warn argument to the vsim command to enable additional
warning messages.

The LRM does not permit specifying a reference_event or data_event condition using the &&&
operator and also specifying 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” is 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.

256 Questa® SIM User's Manual, v2023.4

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 negative timing constraint algorithm of the simulator looks for 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 changes the timing check limits
to force convergence. Basically, the algorithm sets the smallest negative $setup/$recovery limit.
If a negative $setup/$recovery does not exist, then the algorithm zeros the smallest negative
$hold/$removal limit to zero. After zeroing a negative limit, the delay calculation procedure is
repeated. If the delays do not converge, the algorithm sets another negative limit to zero,
repeating the process until convergence is found.

Example 6-2. Timing Check Example 1

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

Questa® SIM User's Manual, v2023.4 257

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.

Example 6-3. Timing Check Example 2

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

258 Questa® SIM User's Manual, v2023.4

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"

Example 6-4. Timing Check Example 3

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

Questa® SIM User's Manual, v2023.4 259

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:

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

If a timing check in the design was set to zero because a delay solution was not found, a
summary message is 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.

Example 6-5. Timing Check Example 4

Finally consider the case where the RST and D timing check is specified on the posedge RST.

$setuphold(posedge CLK, D, -10, 20, notifier,,, dCLK, dD);

$setuphold(posedge CLK, negedge RST, -30, 45, notifier,,, dCLK, dRST);

260 Questa® SIM User's Manual, v2023.4

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 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, the simulator performs timing checks on inputs specified in the timing check. You
can use the +delayed_timing_checks argument with the vsim command to perform timing
checks on the delayed inputs.
Example timing check:

$setuphold(posedge clk, posedge t, 20, -12, NOTIFIER,,, clk_dly, t_dly);

Questa® SIM User's Manual, v2023.4 261

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

This timing check reports a timing violation when posedge t occurs in the violation region:

When the timing check is 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. The Questa SIM simulator
supports both methods. By default, timing checks are performed on the delayed inputs. You can
disable this behavior with the +no_autodtc switch.

Re-evaluation of Zero-Delay Output Schedules

Minimize the use of zero-delay output schedules of gate-level cells without requiring the use of
the ifnone construct with the vsim -glspath simuconddc argument.
Add the -glspath simuconddc argument/value pair to the vsim command line when:

• You are simulating a full timing gate-level simulation with a cell library containing
conditional timing specifications.
• During simulation, if your timing was not met due to a zero-delay output schedule when
no timing path was active.
This functionality is often useful for combinational cells that have detailed timing, which is not
exhaustively specified. It is also most effective with simple state-dependent paths.

262 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Handling Negative Timing Check Limits

When you add the -glspath simuconddc argument/value pair, the simulator re-evaluates specify
path conditions if the following requirements are met:

• A module’s specify block has state-dependent specify paths with no ifnone timing paths.
• For an output change, no specify path is active due to no conditions being evaluated true.
This would normally result in the output being scheduled with zero-delay.
• More than one input change occurred simultaneously to cause the output to change.
• Due to simultaneous input changes, conditions for the timing paths were not evaluated
true.

Handling Negative Timing Check Limits

You can specify the way the simulator handles negative timing checks, including conditional
negative timing checks, to achieve the best timing results.
By default, the simulator complies with the SystemVerilog IEEE Standard by incrementally
zeroing negative timing check limits in cases where a timing solution can not yet be found.
However, each iteration of this type creates an increasingly pessimistic timing specification.
This behavior is not always useful, especially when dealing with condition dependent timing.
Passing different options to the -glsnegtchk argument to vsim enables you to choose the tool
behavior that best suits your needs. Use the appropriate option when encountering vsim
warnings, such as messages 3004 or 3316, about problems calculating delay net solutions.

• level0 - This option is equivalent to +no_neg_tchk. It disables the negative delay solver,
causing the simulator to zero all negative timing checks. This option is best suited for
cell libraries not written for use with negative timing checks. In this mode, any delayed
net is a copy of its un-delayed version.
• level1- This option is equivalent to -no_risefall_delaynets. It solves rising and falling
edge delays for the same net as one set, calculating a single delay for each delayed net.
• level2 - This option enables the default, LRM-compliant negative timing check solver. It
considers rising and falling edge delays for the same net as two sets, and seeks separate
solutions for rise and fall delays. This option is suitable for designs with unique posedge
and negedge timing check specifications.
• level3 - This option enables you to handle conditional negative timing checks using a
model outside of the SystemVerilog LRM. In this mode, the simulator calculates
separate rise and fall delays for each condition independently. Ideally, only one
condition can be active at one time, but if several conditions are true simultaneously the
simulator will issue a warning and choose the minimum rise and fall delays.
An additional difference between the default behavior and -glsnegtchk level3 is that the
simulator relaxes the LRM requirement that delayed signals must straddle reference
events.

Questa® SIM User's Manual, v2023.4 263

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

Force and Release Statements in Verilog

The SystemVerilog Language Reference Manual IEEE Std 1800-2017, section 10.6.2, states
that the left-hand side of a force statement cannot be a bit-select or part-select.Questa SIM
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 cannot be a variable.

Verilog-XL Compatible Simulator Arguments

The simulator supports several arguments that are equivalent to Verilog-XL arguments make it
easier to port a design to the Questa SIM simulator.
See the vsim command for a description of each argument.

+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

264 Questa® SIM User's Manual, v2023.4

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

the Questa SIM simulator recognizes and maintains Verilog escaped identifier syntax.
All object names inside the simulator appear identical to their names in original HDL source
files.

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 v command line, in a .do
file, or on the vopt command line) should be composed of components with valid escaped
identifier syntax.

The modelsim.ini variable 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, you should use the language-correct escaped identifier syntax 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 .

Tcl and Escaped Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Tcl and Escaped Identifiers

In Tcl, the backslash is one of a number of characters that have a special meaning.
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]. In this example, backslashes are also used to
escape the square brackets ([]), which have a special meaning in Tcl.

Questa® SIM User's Manual, v2023.4 265

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

266 Questa® SIM User's Manual, v2023.4

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
Many ASIC and FPGA vendors’ Verilog cell libraries are compatible with Questa SIM Verilog.
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. Questa SIM Verilog fully implements specify
blocks and timing constraints as defined in IEEE Std 1364 along with some Verilog-XL
compatible extensions.

SDF Timing Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Delay Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Approximating Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Troubleshooting Zero Delay Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

SDF Timing Annotation

Questa SIM Verilog supports timing annotation from Standard Delay Format (SDF) files.

Questa® SIM User's Manual, v2023.4 267

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

Distributed Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Path Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Unit Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Zero Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

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 of the Questa SIM simulator.
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

268 Questa® SIM User's Manual, v2023.4

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 6-6 shows the 2-input AND gate cell using a different compiler directive to apply each
delay mode. In particular, Questa SIM 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 6-6. 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.

Questa® SIM User's Manual, v2023.4 269

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

270 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 271

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Troubleshooting Zero Delay Cells

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.

• -randmetastable[+<subopt>[+<subopt>]] — 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.

Troubleshooting Zero Delay Cells

This topic explains how to resolve racing conditions that you may encounter when moving
between optimized and unoptimized cells with zero delays.
When transitioning from timing simulations where vopt +acc=c was used to enable access to
library cells to simulations with fully optimized cells, changes in process ordering may
introduce extra deltas for fully optimized zero delay cells. While this behavior is within the
SystemVerilog LRM specifications, it can result in racing conditions between optimized and
unoptimized cells with zero delays.

272 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Troubleshooting Zero Delay Cells

To ensure that timing simulation behavior remains consistent between simulations that with un-
optimized and fully optimized cells, specify the -cellimmeval argument to vsim. Note that this
argument is intended for use only when +nospecify is not used with vlog, when specify blocks
have zero delays, and with no SDF annotation.

Questa® SIM User's Manual, v2023.4 273

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

SystemVerilog system tasks and functions are built into the simulator.
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 an interface application
that must be loaded by the simulator.

Questa SIM supports:

• Most SystemVerilog system tasks and functions defined in the SystemVerilog LRM
• Several system tasks and functions that are specific to Questa SIM
• Several non-standard, Verilog-XL system tasks
LRM System Tasks and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Using the $typename Data Query Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Using the $coverage_* System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Using the $coverage_save System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Simulator-Specific System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Task and Function Names Without Round Braces ‘()’ . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Verilog-XL Compatible System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
String Class Methods for Matching Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

LRM System Tasks and Functions

The following system tasks and functions are supported byQuesta SIM and are described more
completely in the Language Reference Manual (LRM) for SystemVerilog.
Note
You can use the change command to modify local variables in Verilog and SystemVerilog
tasks and functions.

Utility System Tasks and Functions

Table 6-3. Utility System Tasks and Functions
Simulator control Simulation time Timescale tasks Data query functions
tasks functions
$finish $realtime $printtimescale $bits
$stop $stime $timeformat $isunbounded

274 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
LRM System Tasks and Functions

Table 6-3. Utility System Tasks and Functions (cont.)

Simulator control Simulation time Timescale tasks Data query functions
tasks functions
$exit $time $typename

Table 6-4. Utility System Functions

Conversion functions Array querying Bit vector system
functions functions
$bitstoreal $dimensions countbits
$bitstoshortreal $left countones
$realtobits $right $onehot
$shortrealtobits $low $onehot0
$itor $high $isunknown
$rtoi $increment
$signed $size
$unsigned
$cast

Table 6-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 6-6. Utility System Elaboration Tasks and Coverage Functions

Elaboration tasks Coverage control
functions
$fatal $coverage_control
$error $coverage_get
$warning $coverage_get_max
$info $coverage merge

Questa® SIM User's Manual, v2023.4 275

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
LRM System Tasks and Functions

Table 6-6. Utility System Elaboration Tasks and Coverage Functions (cont.)
Elaboration tasks Coverage control
functions
$coverage_save
$get_coverage
$load_coverage_db
$set_coverage_db_name

Table 6-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 6-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
$sync$nand$plane

276 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
LRM System Tasks and Functions

Table 6-8. Utility System Analysis Tasks and Functions (cont.)

Probabilistic Stochastic analysis PLA modeling tasks Miscellaneous tasks
distribution tasks and functions and functions
functions
$sync$or$plane
$sync$nor$plane

Input/Output System Tasks and Functions

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

Table 6-10. Input/Output System Memory and Argument Tasks

Memory load tasks Memory dump tasks Command line input
$readmemb $writememb $test$plusargs

Questa® SIM User's Manual, v2023.4 277

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
LRM System Tasks and Functions

Table 6-10. Input/Output System Memory and Argument Tasks (cont.)

Memory load tasks Memory dump tasks Command line input
$readmemh $writememh $value$plusargs

Table 6-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 6-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
$width1
$removal

278 Questa® SIM User's Manual, v2023.4

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 6-12. Other System Tasks and Functions (cont.)

Timing check tasks Random number functions Other functions
$recrem
1. Verilog-XL ignores the threshold argument even though it is part of the Verilog spec.
Questa SIM does not ignore this argument. 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() does not include class, struct and enum
members, nor any class extensions.
You can override this default behavior 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 forms of $typename() output for a parameterized class: vector, which extends
another parametrized class: vector_base, both of which are defined in the module scope:
typename_parameterized_class, are shown in the following:

• $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;}

• $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;}

Questa® SIM User's Manual, v2023.4 279

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

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.

Restrictions and Notes

Tip
The coverage numbers that $coverage_get_max(...) and $coverage_get(...) return will often
not agree with those returned by the simulator’s report functions. This is as designed.

• The coverage numbers reported by the simulator differ from the SystemVerilog system
functions. The numbers in the simulator reports:
o reflect merge/roll-up coverage numbers (that is, nine instances of the same assertion
is reported as 1 assertion). The $coverage_* system functions count each instance
separately (that is, nine 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,
Questa SIM issues an 'unsupported' warning message ignores the system function.
• 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.
• 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.

280 Questa® SIM User's Manual, v2023.4

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

if ($coverage_control(`SV_COV_CHECK, `SV_COV_ASSERTION, `SV_COV_MODULE,

"DUT") == `SV_COV_OK) ...

Questa® SIM User's Manual, v2023.4 281

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() system function is compliant with the SystemVerilog
LRM. Calls to the SystemVerilog $coverage_save() function that worked
inQuesta SIMversions 10.0 and earlier do not work in version 10.1 and higher, and 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 behavior of $coverage_save() following release 10.1 is significantly different from the
original behavior because the original implementation pre-dated the standardization process. If
you are unable to make source changes, you can use the following workaround: use the vsim
-usenonstdcoveragesavesysf argument to replace the implementation of the built-in system
function with the non-standard variant. The action of this argument is global and affects all calls
to $coverage_save(). It is not recommended as a long-term solution.

Using the $clog2 Math Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Using the $clog2 Math Function

The SystemVerilog LRM does not clearly indicate what should happen when the argument for
the $clog2() function contains 'X' or 'Z' values.
The simulator treats any bit position containing an 'X' within a value similar to a '1'. Questa SIM
treats any bit with the value of 'Z' as a '0' in that bit position.

282 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 283

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

There are several system tasks and functions that are specific to Questa SIM, which 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.
$coverage_save_mti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
$get_initial_random_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
$messagelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
$psprintf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
$sdf_done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
$stacktrace() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
$wlfdumpvars() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

284 Questa® SIM User's Manual, v2023.4

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. The batch run typically terminates with the $finish call.
Syntax
$coverage_save_mti(<filename>, [<instancepath>], [<xml_output>]);
Arguments
none
Description
The $coverage_save() system function is defined in SystemVerilog LRM. See Using the
$coverage_save System Function for a brief description. 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>, Questa SIM saves all coverage data in the current design
to the specified file. If you do specify <instancepath>, Questa SIM saves data on that instance,
and all instances below it (recursively), to the specified file.

Setting the [<xml_output>] argument to 1 specifies that the output be saved in XML format.

Questa® SIM User's Manual, v2023.4 285

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
Specify this random seed value by using the -sv_seed argument of the vsimcommand.

Syntax
$get_initial_random_seed;
Arguments
none

286 Questa® SIM User's Manual, v2023.4

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
• <message>
Your message, enclosed in quotation marks ("), using text and specifiers to define the
output.
• <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>.
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.

Questa® SIM User's Manual, v2023.4 287

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

• 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 produces the following output

# Hello: The caller was at test.sv,7
# Hello: The caller was at test.sv,8

Specifiers
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 differs 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, which 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).
• %: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.

288 Questa® SIM User's Manual, v2023.4

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

• %: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:
o Note — This is the default if you do not specify %:S
o Warning
o Error
o Fatal
o Info — The error message system recognizes this as a Note
o 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. Typically, you use the tilde (~) character to specify that this character
is not to be printed.
Examples
• The following $messagelog task:
$messagelog("hello world");

transcripts the message:

hello world

while logging all default attributes, but does not log a category.

Questa® SIM User's Manual, v2023.4 289

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

silently logs the severity level of “Note”, 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).

290 Questa® SIM User's Manual, v2023.4

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(), and is not placed in
the first argument as for $sformat(). Thus, you can use $psprintf() 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

Questa® SIM User's Manual, v2023.4 291

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

292 Questa® SIM User's Manual, v2023.4

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)

Questa® SIM User's Manual, v2023.4 293

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 parentheses “()” following the name to call the task
or function. In Questa SIM 10.3 and later you may use hierarchical task and function names
without parentheses.

294 Questa® SIM User's Manual, v2023.4

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 uses the following rules for interpreting task and function names without
parentheses:

1. Non class tasks/functions (static or non static) are interpreted as a search in the scope of
the function and not a function call.
2. Non-static class methods are treated as a function call.
3. Static class methods are treated as a lookup in the function scope.
4. Once a function call is made for a hierarchical name, all subsequent function names are
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.

Questa® SIM User's Manual, v2023.4 295

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
Questa SIM supports a number of Verilog-XL specific system tasks and functions.
Supported Tasks and Functions Mentioned in IEEE Std 1364 . . . . . . . . . . . . . . . . . . . . 296
Supported Tasks and Functions Not Described in IEEE Std 1364 . . . . . . . . . . . . . . . . . 296
Extensions to Supported System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Unsupported Verilog-XL System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

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
Some system tasks are also provided for compatibility with Verilog-XL, though they are not
described in the IEEE Std 1364.
The $deposit 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
Questa SIM force -deposit command.

$deposit(variable, value);

The $disable_warnings system task instructs the simulator 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, The simulator disables warnings for the entire simulation.

$disable_warnings("<keyword>"[,<module_instance>...]);

Disabling warnings with $disable_warnings does not prevent notifier toggling by default. If you
want to prevent notifier toggling when the $disable_warnings system task is in effect, pass the
-no_notifier_on_disable argument to vsim.

296 Questa® SIM User's Manual, v2023.4

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

The $enable_warnings 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 module instance names. If you do not specify a module_instance, the
simulator enables warnings for the entire simulation.

$enable_warnings("<keyword>"[,<module_instance>...]);

The $system 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("command");

where the return value of the $system function is a 32-bit integer that is set to the exit status
code of the underlying OS process.

$system("ls -l");

Note
There is a known issue in the return value of the $system 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.

The $systemf 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.

$systemf(list_of_args)

Note
There is a known issue in the return value of the $systemf 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.

The $test$plusargs system function tests for the presence of a specific plus argument on the
simulator's command line.

$test$plusargs("plus argument")

Questa® SIM User's Manual, v2023.4 297

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

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

298 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Negative Timing Checks With $setuphold and $recrem . . . . . . . . . . . . . . . . . . . . . . . . . 299

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
Questa SIM Verilog, but have equivalent simulator commands.
The $input system task reads commands from the specified filename. The equivalent simulator
command is do <filename>.

$input("filename")

The $list 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.

$list[(hierarchical_name)]

Questa® SIM User's Manual, v2023.4 299

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

The $reset system task resets the simulation back to its time 0 state. The equivalent simulator
command is restart.

$reset

The $restart 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>.

$restart("filename")

The $save system task saves the current simulation state to the file specified by filename. The
equivalent simulator command is checkpoint <filename>.

$save("filename")

The $scope system task sets the interactive scope to the scope specified by hierarchical_name.
The equivalent simulator command is environment <pathname>.

$scope(hierarchical_name)

The $showscopes system task displays a list of scopes defined in the current interactive scope.
The equivalent simulator command is show.

$showscopes

The $showvars system task displays a list of registers and nets defined in the current interactive
scope. The equivalent simulator command is show.

$showvars

String Class Methods for Matching Patterns

This group of functions are not a part of the SystemVerilog LRM. However, the Questa SIM
simulator supports their use, unless you include 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);

300 Questa® SIM User's Manual, v2023.4

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

results in printing out “8”.

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

Example 6-7. match() 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 Example 6-7, 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 Example 6-7, 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 Example 6-7, the following:

str3 = str.thismatch();

would be assigned the string “CDE”

• backref() — This function returns matched patterns, based on function call in
Example 6-7.

Questa® SIM User's Manual, v2023.4 301

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

backref(integer index);

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.

302 Questa® SIM User's Manual, v2023.4

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
The Questa SIM simulator support of SystemVerilog includes all of the compiler directives
defined in the SystemVerilog LRM, 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, resetting them back to their default
settings (this information is not provided in the SystemVerilog LRM):

`celldefine
‘default_decay_time
`default_nettype
`delay_mode_distributed
`delay_mode_path
`delay_mode_unit
`delay_mode_zero
`protect
`timescale
`unconnected_drive
`uselib

Questa SIM 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Questa® SIM User's Manual, v2023.4 303

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

Compiler Directives for vlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Verilog-XL Compatible Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

IEEE Std 1364 Compiler Directives

The simulator supports SystemVerilog compiler directives, which 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

The `protect/`endprotect vlog directives are specific to the Questa SIM simulator and are not
compatible with other simulators.

`protect and `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. Using these directives behaves exactly
as if using:

vlog -nodebug=ports+pli

except that it applies to selected regions of code rather than the whole file. The directive pair
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. You can deliver this new file to be used as a replacement for the
original source file.

304 Questa® SIM User's Manual, v2023.4

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

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. Further, the vendor would compile this file with
vlog +protect encrypt.v to produce a new file named encrypt.vp. Anyone can then 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.

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.

You cannot nest `protect and `endprotect directives.

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

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 tasks.v, called
params.vp and tasks.vp. You may then copy these encrypted files out of the work directory to

Questa® SIM User's Manual, v2023.4 305

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

more convenient locations. These encrypted files can be included within your design files; for
example:

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

Though other simulators have a `protect directive, the algorithm Questa SIM 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 Questa SIM, you could not
simulate it elsewhere.

Verilog-XL Compatible Compiler Directives

The Questa SIM simulator supports a number of compiler directives that are compatible 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 Questa SIM Verilog.
Many of these directives are irrelevant to Questa SIM Verilog, but may appear in code being
ported from Verilog-XL.

306 Questa® SIM User's Manual, v2023.4

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 Questa SIM
Verilog. These are not implemented in Questa SIM Verilog, and any code containing these
directives may behave differently in Questa SIM Verilog than in Verilog-XL.

`default_trireg_strength
`signed
`unsigned

Questa® SIM User's Manual, v2023.4 307

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Digital Mixed-Signal for Verilog and SystemVerilog

Digital Mixed-Signal for Verilog and

SystemVerilog
Questa SIM simulation allows you to model digital mixed-signal (DMS) behavior by
supporting the constructs for modeling real numbers provided by both Verilog-AMS and
SystemVerilog.
If a model has a variable declared as type real, you must use a real-valued connection to
transport its value to other models in the design. However, Verilog-AMS and SystemVerilog
differ in how they support real-valued connections.

Verilog-AMS supports a net type called wreal (for connections such as nets, wires, ports) and a
data type called real (for variables). The net type of wreal can accept a real value, which can
represent physical connection between structural entities. Like wires, a wreal net may have
multiple drivers. Unlike wires, the drivers of wreal nets are real numbers rather than logic
levels. You can assign a real value directly to a wreal net, or you can declare a real variable and
assign it to the wreal net. You enable declarations of wreal net type by using the -ams argument
to the vlog command.

SystemVerilog supports the use of wreal nets and real variables, and it also supports user-
defined net (UDN), which enables to define more elaborate real number modeling (RNM). Real
number modeling is the process of modeling an analog circuit’s behavior as a digital model that
when run with a digital event-based simulator greatly increases the performance with an
acceptable level of accuracy. RNM can detect various design errors such as incorrect use of
register bits, clock phase and frequency mismatch, activity during power up, down, and reset,
mismatch in the bias, and incorrect connections.

Real number modeling and the wreal net type in Verilog and SystemVerilog are Questa SIM
options that require the following additional license features:

• svrnm — Allows nettype, interconnect, real-valued covergroups, and real-valued

constraints.
• svwreal — Allows wreal and the nettype equivalents defined in mgc_rnm_pkg.
Refer to the Questa SIM Installation and Licensing Guide for more information on license
features. For information on how to obtain licensing options, visit the Siemens Support Center
web page:

https://support.siemens.com

In particular, support for the wreal net type involves a variety of issues related to analog and
digital signals and data that appear on design connections. This section identifies issues related
to connectivity as it is described in the Verilog family of languages. Specifically, problems arise
from different semantic meanings applied to the same word ("wire") in different standards, and
from ascribing a well-defined semantic meaning to a common word (net, wire, interconnect) in
a standard, which differs from the common colloquial understanding.

308 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
AMS Standards and Nomenclature

Questa SIM implements the following extensions to SystemVerilog for real number modeling
with wreal and for the support of Verilog-AMS netlisters:

• Real number modeling and explicit connectivity of real number models using wreal,
which is a built-in net type. Declarations of wreal net type require the vlog -ams
argument.
• The ability to convert wire objects that are used as structural wires in the sense of
Verilog-AMS, into typeless interconnect nets with the SystemVerilog semantic. You
enable this connection typing by using the -rnmautointerconnect argument to the vopt
command.
• A global resolution function for conflicting values on wreal nets. You enable this
resolution function by using the -wreal_resolution argument to the vsim command.

Note
It is not possible to save or checkpoint a Questa SIM simulation that contains wreal
declarations.

AMS Standards and Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Connectivity Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Real-valued Nets in Verilog (wreal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

AMS Standards and Nomenclature

Verilog-AMS HDL is derived from IEEE Std 1364-2005. The definition and semantics of
Verilog-AMS are provided by Accellera Systems Initiative in the Verilog-AMS Language
Reference Manual.

Standards
Verilog-AMS lets designers of analog and mixed-signal systems and integrated circuits create
and use modules that encapsulate high-level behavioral descriptions, as well as structural
descriptions of systems and components. A designer can describe the behavior of each module
mathematically in terms of its ports and external parameters applied to the module. The
structure of each component can be described in terms of interconnected sub-components.

These descriptions can be used in many disciplines such as electrical, mechanical, fluid
dynamics, and thermodynamics.

A standard can be a ratified industry standard, such as those endorsed by IEEE or Accellera, or
it can be a de-facto standard, meaning an implementation that has become so widely used that it

Questa® SIM User's Manual, v2023.4 309

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
AMS Standards and Nomenclature

has become equivalent to an endorsed standard in its influence on the industry. In the context of
AMS behavior supported by Questa SIM, the following standards are considered:

• Verilog (last version IEEE Std 1364-2005)

• Verilog-AMS 2.4 (superset of Verilog 2005 with AMS-specific extensions)
• wreal extensions to Verilog-AMS (as donated by Cadence to the Accellera Systems
Initiative)
• SystemVerilog IEEE Std 1800-2017

Product support for Verilog family of languages

It is common for a design to combine contributions from multiple teams that use different flows
and even combinations of products and tools from multiple vendors. This causes designs and
verification environments to depend on interoperability between multiple standards. For
purposes of this discussion, the standards under consideration are Verilog-AMS and
SystemVerilog as extended by the donations made to the Accellera Systems Initiative.

Analog or AMS designs that use real number models based on wreal net types often combine
test benches written in SystemVerilog with a DUT consisting of modules written with both
Verilog-AMS (wreal and structural wire) and SystemVerilog or its Verilog subset. To support
this situation, vendors have developed proprietary extensions to handle these types of
combinations.

Nomenclature Complications
Support for modeling AMS connectivity in the Verilog family of languages is complicated by
the terminology historically associated with design connections and topology.

These issues are essentially problems created by different semantic meanings given to the same
word ("wire") in different standards and by the use of common words (net, wire, interconnect)
in a standard that have been assigned a formal meaning that differs from everyday usage.

This particular context is the verification of mixed-signal semiconductor designs that use real
number modeling for analog components, which includes technical issues associated with using
the Verilog HDL family constructs wreal, wire, and interconnect.

Connectivity Terms
In electronic design, the word "wire" is used as an informal term to describe a connection
between pins (analog/SPICE terminology) or ports (digital/HDL terminology) of modules in a
system of connected components. Ideally, when information (signal, data) appears on one end
of a wire, it is instantly available to be observed at the other end without change. Of course,
behavior is less ideal in the physical world, but these non-ideal complications (such as delay and
distortion) are typically introduced at a lower level of abstraction.

310 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Connectivity Modeling

Further, connections throughout a design exist beyond just to two ends of a wire—HDLs allow
connections of many component pins/ports. Such a multitude of connections among many
components is informally referred to as a "net" or "interconnect."

In analog (SPICE) modeling and simulation, when multiple physical wires are connected, the
point of the connection is often called a "node, " where the word node can mean the entire net.

Signal Type
Real-life signals in systems implemented from electrical components exist at the analog
physical level and are modeled by voltages and currents (as in SPICE or AMS hardware
description languages). At higher levels of abstraction, the details of voltages and currents are
ignored, and simpler modeling representations are used. In HDLs, the signal information that is
carried by the connectivity objects can be represented by many different data types. In Verilog,
the most commonly encountered ones are 4-state logic and real numbers. More detailed
descriptions use signal abstractions that can carry multiple specifications of data—typically a
struct in a user-defined nettype.

From the Verilog-AMS standard, a wreal net represents a real-valued physical connection
between structural entities that does not store its value. A wreal net can be used for real-valued
nets driven by a single driver, such as a continuous assignment. If no driver is connected to a
wreal net, its value is real zero (0.0). Whereas digital nets have an initial value of ‘Z’ (a 4-state
logic value), wreal nets have an initial value of 0.0.

Behavior Modeling and Resolution of Multiple Signals

Using an HDL, the behavior of a component is modeled by describing the relationship between
the signal values at the component’s pins/ports. Verilog also has built-in behavior modeling that
includes resolution rules for determining what digital value will appear on the wire at the
component output when multiple signal values are driven onto that wire. These resolution rules
go beyond just transporting a signal value from one place to another, which means a wire can
also model behavior.

Connectivity Modeling
Modeling connectivity in an analog mixed-signal design entails several issues to be considered.

Variables versus connections

If a model has a variable declared as type real, you must use a real-valued connection to
transport its value to other models in the design. However, using a real-valued connection
depends on different characteristics provided by Verilog-AMS and SystemVerilog.

Questa® SIM User's Manual, v2023.4 311

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Connectivity Modeling

Structural versus Behavioral Wire

When a wire object appears only in statements (as a structural construct), that object is referred
to as a “structural wire.” Any other use of a wire object is referred to as a “behavioral wire.”
This concept of structural vs. behavioral wire (although not the specific terminology) appears
only in the Verilog-AMS standard; it does not appear in the SystemVerilog standard.

A common case of a behavioral wire is one that is accessed (written or read) in the behavioral
code of a module, but the module includes a wire that is declared (as a port or a local object) but
is not used at all.

Verilog-AMS wire object

Verilog-AMS 2.0 introduced a net that can carry real values (declared as wreal). In order to
allow connectivity of models that rely on wreal, the wire object semantic has been extended by
Verilog-AMS so that a wire, declared either explicitly or implicitly, can carry either a 4-state
logic value (0, 1, X, Z) or a real value, depending on what is connected to that wire. A structural
wire is an object that carries either a logic or a real value—just one value, with the same type
during the entire simulation. Verilog AMS addresses the problem of converting between the
logic and real values.

SystemVerilog Interconnect
The SystemVerilog LRM establishes two important concepts for modeling connectivity:

• User-Defined Nettype (UDN) — UDN allows a definition of a net type that consists of
the following:
o User Defined Type (UDT) — It is a SystemVerilog type that contains the following:
• 2 or 4-state integral type including packed array, packed structure, and union
• Real or shortreal
• Fixed-size unpacked array, unpacked union, or structure of a valid type
o User Defined Resolution function (UDR) — It is a SystemVerilog function that
resolves multiple drivers on the same net, and has a specific signature.
A UDR signature consists of the following:
• Input — Single input dynamic array of the UDN type
• Output — Return type of the UDN type that represents the resolved value of the
net
UDR is optional, and a UDN without a UDR must not have multiple drivers.
A UDN is a significant extension of the wreal net type. In order to allow connectivity of
models that rely on UDNs, a more generic connectivity mechanism is needed—the
interconnect object.

312 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Connectivity Modeling

• The interconnect net — An interconnect object is a typeless net that can be used only to
express connections; it cannot be used to express behavior.

Verilog-AMS wire versus SystemVerilog interconnect

A Verilog-AMS wire and a SystemVerilog interconnect provide different ways to implement
AMS connectivity. There are two important differences between these two approaches:

• Verilog-AMS wire can carry logic or real values, whereas interconnect can carry any
type, including built-in types and the types defined in a UDN. Thus, a Verilog-AMS
structural wire object can be accessed by a hierarchical reference in a test bench and its
type is known after elaboration.
• SystemVerilog interconnect is an object that cannot take on the type of behavioral
objects that it is connected to (unlike a Verilog-AMS structural wire). Thus, a
SystemVerilog interconnect object cannot be used in any behavioral read or write
access, including using a hierarchical reference.

Hierarchical referencing (test bench versus DUT)

Hierarchy is used in descriptions of systems, designs, and components to decompose a large
problem into smaller, more manageable subproblems. When hierarchy is introduced, a single
point where components are connected in a flat description becomes a collection of such points,
which often introduces different names at levels of hierarchy.

Another consequence of the distinction between using wire and interconnect is that a test bench
that relies on the Verilog-AMS rules of a structural wire cannot be compiled nor optimized
independently of the DUT. This is because a hierarchical reference from the test bench could
turn up to have, after elaboration, either logic or real type. Further, because when using Verilog,
it is difficult to identify the type of a hierarchical reference from its context, the compiler cannot
determine the verification engineer’s intention. This is even if the user “knows” that the
hierarchical reference will “always” end up to be the type (such as logic) unequivocally
associated with a wire net in SystemVerilog.

The rules of SystemVerilog interconnect enable much more efficiency in the independent
compilation, optimization, and even partial elaboration of the test bench and the DUT than with
Verilog.

If you use the Cadence AMS netlister with a design that contains models that use real numbers
to represent the behavior of an analog component, a practical problem arises. The netlister relies
on the concept of Verilog-AMS structural wire, which, according to the Verilog-AMS standard
and the Cadence wreal extensions, is capable of carrying signals that are either logic (0,1,X,Z)
or real numbers (but not both). The netlister generates modules from schematics for structure.
The netlisted modules use only Verilog implicit net declarations, meaning that the ports and
nets are not declared in the module. Because of the default rules of all Verilog languages, such
objects are implictly declared as wire objects, and when used with a product compliant with
Verilog-AMS, those wires can connect either logic (behavioral wire) or real (wreal) models.

Questa® SIM User's Manual, v2023.4 313

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Connectivity Modeling

Boundary Elements
The boundary elements connect two signals of different net-types or domains. They are also
referred as adapters, connect modules, and interface elements. In case of RNM modeling, the
boundary elements connects digital wreal signals to digital logic signals.

The tool supports the following:

• Insertion between wreal and logic only

• Parameterized R2L (Real to Logic), L2R (Logic to Real), and RL_bidir (Bidirectional
Real to Logic)
The tool does not support merging of boundary elements based on the design topology.

The boundary elements have the following parameters:

• vsup — A L2R parameter that represents the real value equivalent to logic 1. It is also
used to calculate other R2L parameters. The default value is 1.8.
• vsuplow — A L2R parameter that represents the real value equivalent to logic 0. It is
also used to calculate other R2L parameters. The default value is 0.
• vthi — A R2L parameter that represents the threshold that decides when a digital signal
should change from 0 to 1.
The tool calculates vthi as follows:
vthi = thiratio*vsup + (1-thiratio)*vsuplow

The default value of vthi is calculated using the default values of vsup (1.8), vsuplow
(0), and thiratio (2/3):
Default vthi = 2/3*1.8 + (1/3)*0 = 1.2

• vtlo — A R2L parameter that represents the threshold that decides when a digital signal
should change from 1 to 0.
The tool calculates vtlo as follows:
vtlo = tloratio*vsup + (1-tloratio)*vsuplow

The default value of vtlo is calculated using the default values of vsup (1.8), vsuplow
(0), and tloratio (1/3):
Default vtlo = 1/3*1.8 + (2/3)*0 = 0.6

• thiratio — A R2L parameter that represents the ratio between vthi-vsuplow and vsup-
vsuplow. It is used to calculate vthi. The default value is 2/3.
• tloratio — A R2L parameter that represents the ratio between vtlo-vsuplow and vsup-
vsuplow. It is used to calculate vtlo. The default value is 1/3.

314 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Connectivity Modeling

• txdel — A R2L parameter that delays the transfer of the X-state from the real side to the
logic side. The default value is -1, which means an infinite delay, and the tool never
displays the X-state.

Practical Differences in Porting Between NCSim and Questa SIM

As noted under Standards, AMS designs with real-number models that use wreal indicate an
effort to combine test benches written in SystemVerilog with a DUT that has modules written in
a combination of Verilog-AMS and SystemVerilog or its Verilog subset. Vendors have
developed proprietary extensions to accommodate these kinds of combinations.

The extension that Questa SIM implements to support the use of AMS netlisters with
SystemVerilog-based test benches and DUTs differs from extensions used by the AMS
netlitsters of other vendors. This difference in interpretation leads to some porting problems.

• Other vendors implement extensions for connectivity that rely on the older Verilog-
AMS standard. This implementation allows a hierarchical reference in a test bench to a
Verilog-AMS structural wire. It is not known how such a reference is interpreted when
the structural wire becomes either a wire or wreal depending on what is connected to it
in the DUT.
• Questa SIM implements the extensions using the more modern SystemVerilog concept
of interconnect. When a structural wire is converted to a SystemVerilog interconnect,
this implementation (based on SystemVerilog rules) does not permit use of a
hierarchical reference to such an object.

Workarounds
There are several possible workarounds to the discrepancies between these implementations:

• Instead of using a hierarchical reference to a structural wire in a connectivity module

high in the hierarchy, refer instead to the behavioral wire in one of the models.
• Instead of using a hierarchical reference, use a checker module with an explicit port
type, and bind it into the connectivity module.
• Instead of using the structural wire in a module, explicitly type the appropriate objects as
either a wire (and do not convert it to interconnect) or a wreal.

Questa® SIM User's Manual, v2023.4 315

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Real-valued Nets in Verilog (wreal)

Real-valued Nets in Verilog (wreal)

Nets and ports of type wreal, and arrays of wreal are supported for SystemVerilog. The net data
type of wreal represents a real-valued connection between structural entities—driver values on
wreal nets are real numbers (as opposed to logic levels on wires). Like wires, a wreal net may
have multiple drivers.
Tip
For a full definition of the wreal net data type, refer to The Verilog-AMS Language
Reference Manual, Analog & Mixed-Signal Extensions to Verilog HDL, v2.4.0 from
Accellera Organization, Inc. 2014.

In addition to real values, wreal can take on two additional states: ‘wrealXState and
‘wrealZState. The value of ‘wrealZState represents a high-impedance disconnection, while
‘wrealXState indicates that the value is unknown. You can declare a variable port of type real
only in SystemVerilog, not in Verilog-AMS. A wreal and a real can connect through a port
connection.

Resolution Functions for wreal Drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Resolution Functions for wreal Drivers

To determine the effective value of multiple real values on a wreal net, Questa SIM passes
wreal drivers on a network through a resolution function. You can select which function is used
by specifying a value for the -wreal_resolution argument of the vsim command.
Table 6-13 lists the resolution functions supported for resolving driver conflicts on a wreal net..
Table 6-13. Resolution Functions for wreal Drivers
Resolution Function Description
default Single active driver only, support for Z state
4state Similar to Verilog 4-State resolution for
digital nets
sum Resolves to a summation of all the driver
values
avg Resolves to the average of all the driver
values
min Resolves to the smallest value of all the
driver values
max Resolves to the greatest value of all the
driver values

316 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Examples

The following example shows the syntax for the vsim command selecting sum as the resolution
function for wreal when multiple drivers are connected to the same net:

vsim -wreal_resolution sum

In SystemVerilog, The Questa SIM simulator supports connecting a user-defined real nettype
when connecting to a wreal net by providing a built-in package (mgc_rnm_pkg.sv) that defines
resolution functions that correspond to those listed in Table 6-13 for multiple signals on wreal
nets:

package mgc_rnm_pkg;
nettype real wreal1driver with MGC_res_wreal1driver;
nettype real wreal4state with MGC_res_wreal4state;
nettype real wrealmin with MGC_res_wrealmin;
nettype real wrealmax with MGC_res_wrealmax;
nettype real wrealsum with MGC_res_wrealsum;
nettype real wrealavg with MGC_res_wrealavg;
endpackage : mgc_rnm_pkg

Examples
The tool supports real datatype, user-defined nettypes, and user-defined resolution functions.
Also, the tool supports treating the wire type as interconnect type and has a built-in package,
mgc_rnm_pkg.sv.

Declaring Nets as wire and as wreal

When using a wire declared as wreal with the full extensions donated to the Accellera Systems
Initiative, the connection is an abstract construct. This type of wire can accept logic or real data.

The following module declares four wires. It reads data from one (a), writes data to another (b),
and instantiates another (c), and ignores another (d).

module top;
wire a, b, c, d;
initial $display (a);
assign b=1;
x inst1 (c)
endmodule

Using the vopt - rnmautointerconnect command means the compiler interprets the wires as
SystemVerilog interconnects. That is, the compiler converts wire objects used as structural
wires (per Verilog-AMS) into the typeless interconnect nets (per the SystemVerilog semantic).

You can then define a simulation module for x in either of two ways—

• The wire assumes the characteristics of interconnect nettype supported by

SystemVerilog
module x (wire z);

Questa® SIM User's Manual, v2023.4 317

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Examples

• The wire assumes the characteristics wreal type supported by Verilog-AMS.

module x (wreal z);

Hierarchical Availability
This example demonstrates the following:

• The ‘default_netlister pragma specifies that all nets are to be netlisted as wire type,
unless otherwise specified.
• The module mid declares two input ports (a, b) and one output port (c). It also has three
child instances that declare these three ports as wires, two additional wires that assume
the default type (d, e), and an interconnect wire (f).
• The module top defines an instance of the mid and attempts to display an instance of the
interconnect wire (f) as a hierarchical reference.
• Three instantiations of child3 (from mid), each of which shows a different method of
specifying a resolution function for f.
‘default_netlister; wire
module mid (input a, b output c);
child1 i1 (a, d, e);
child2 i2 (c, e, f);
child3 i3 (f);
endmodule;

module top;
i11 mid(x, a, b);
initial $display(i1.f);
endmodule

// The following modules instantiate child3 from mid,

// using different resolution functions:
module child3 (wire x)
module child3 (wreal x)
module child3 (wrealsum x)

Using the Real Datatype, User-defined Nettypes, and User-defined

Resolution Functions
In the following example, sig0 is the real datatype, mywrealavg is the user-defined nettype, and
avg_func is the user-defined resolution function.

318 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Examples

`timescale 1ns/1ps
module top;
nettype real mywrealavg with avg_func;
function automatic real avg_func (input real driver[]);
real sum;
sum = 0.0;
avg_func = 0;
foreach (driver[i]) begin
sum += driver[i];
end
avg_func = sum/driver.size();
endfunction real
sig0;
mywrealavg sig1;
assign sig1 = sig0;
assign sig1 = 1.2;
initial begin
sig0 = 0.5;
#1;
$display ("The value of sig1 is %g", sig1);
$finish;
end
endmodule

The tool displays the following, which is the average of sig0 and sig1:

The value of sig1 is 0.85

Using the mgc_rnm_pkg Package

The mgc_rnm_pkg package is a built-in package that contains various UDR functions. The
following module demonstrates various options available in the package.

Questa® SIM User's Manual, v2023.4 319

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Examples

`timescale 1ns/1ps
import mgc_rnm_pkg::*;
module top;
wreal1driver sig1;
assign sig1 = 1.14;
assign sig1 = `wrealZState;
wreal1driver sig2;
assign sig2 = 1.14;
assign sig2 = 2.11;
wreal1driver sig3;
assign sig3 = 1.14;
assign sig3 = 1.14;
wreal4state sig4;
assign sig4 = 1.14;
assign sig4 = `wrealZState;
wreal4state sig5;
assign sig5 = 1.14;
assign sig5 = 2.11;
wreal4state sig6;
assign sig6 = 1.14;
assign sig6 = 1.14;
wrealmin sig7;
assign sig7 = 1.14;
assign sig7 = 2.11;
wrealmax sig8;
assign sig8 = 1.14;
assign sig8 = 2.11;
wrealsum sig9;
assign sig9 = 1.14;
assign sig9 = 2.11;
wrealavg sig10;
assign sig10 = 1.14;
assign sig10 = 2.11;

initial begin
#1;
$display ("sig1=%g", sig1);
$display ("sig2=%g", sig2);
$display ("sig3=%g", sig3);
$display ("sig4=%g", sig4);
$display ("sig5=%g", sig5);
$display ("sig6=%g", sig6);
$display ("sig7=%g", sig7);
$display ("sig8=%g", sig8);
$display ("sig9=%g", sig9);
$display ("sig10=%g", sig10);
end
endmodule

320 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Examples

The tool displays the following results:

# sig1=1.14
# sig2=X
# sig3=X
# sig4=1.14
# sig5=X
# sig6=1.14
# sig7=1.14
# sig8=2.11
# sig9=3.25
# sig10=1.625

Inserting the Boundary Elements Automatically

Use the vopt –rnm command to automatically insert the boundary elements that connects a real
net to a logic net.

In the following example, the tool insets boundary elements between the real net, top.sig1w and
the logic net, top.u_child.sig2.

`timescale 1ns/1ps
import mgc_rnm_pkg::*;
module top;
real sig1;
integer up;
wreal1driver sig1w;
assign sig1w=sig1;
child u_child (sig1w);
always #0.1 begin
if (up==1) sig1=sig1+0.01;
if (up==0) sig1=sig1-0.01;
end always #20 up=1-up;
initial begin
up=1;
sig1=0;
#200;
$finish;
end
endmodule
module child (sig2);
input sig2;
logic sig2;
integer count;
always @(edge sig2) begin
count=count+1;
end
initial begin
count=0;
#100;
$display("count=%g", count);
end
endmodule

Questa® SIM User's Manual, v2023.4 321

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Examples

The tool inserts the following R2L boundary

element:

Note
To define the parameters for Real to Logic, Logic to Real, and bidirectional Real to Logic
boundary elements, use the -rnmconfigfile <config_filename> argument of the vopt
command.

322 Questa® SIM User's Manual, v2023.4

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 Questa SIM
dynamically allocates memory for the accessed addresses during simulation.
Sparse memories are more efficient in terms of memory consumption, but access time to sparse
memory elements during simulation is slower. Thus, sparse memory modeling should be used
only on memories that do not have many active addresses.

Most operations are available for sparse memories and non-sparse memories alike. You do not
need to know whether a memory is sparse or not, except in the certain cases.

Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Priority of Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Determining Which Memories Were Implemented as Sparse . . . . . . . . . . . . . . . . . . . . 325
Initializing Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Limitations of Sparse Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Questa® SIM User's Manual, v2023.4 323

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

You can also enable sparse memories automatically by setting the SparseMemThreshold
variable in the modelsim.ini file

Manually Marking Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Automatically Enabling Sparse Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Combining Automatic and Manual Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

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

324 Questa® SIM User's Manual, v2023.4

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

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

The Questa SIM simulator labels memories as sparse or not sparse according to 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.
Prerequisites
• 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-dimensional SystemVerilog memory, which is not
supported. In that case, the simulation will function correctly, but the simulator 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.

Questa® SIM User's Manual, v2023.4 325

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

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.

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 Questa SIM 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).

326 Questa® SIM User's Manual, v2023.4

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

Unmatched Virtual Interface Declarations

The SystemVerilog LRM does not address the relationship between interfaces as design
elements and virtual interfaces as types. The Questa SIM flow allows 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
simulation through such a virtual interface, an error results due to dereferencing a null virtual
interface.

Situations exist 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 the simulator’s overall elaboration and simulation flow, it is not possible for Questa SIM
to determine whether such type references will actually be exercised during simulation. For
these cases, the following argument enables vsim to elaborate the design:

vsim -permit_unmatched_virtual_intf

Tip
When using the -permit_unmatched_virtual_intf argument, ensure that no simulation time
operations occur through unmatched virtual interfaces.

Questa® SIM User's Manual, v2023.4 327

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

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Extensions to SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Standards, Nomenclature, and Conventions for VPI

Questa SIM support of the Verilog VPI is based on the SystemVerilog LRM.
For release-specific information on currently supported implementation, refer to the following
text file located in the installation directory: <install_dir>/docs/technotes/Verilog_VPI.note

Note
Questa SIM does not support user asynchronous Pthreads making DPI export calls. User
asynchronous Pthreads are supported as long as they do not directly interact with the
simulator kernel through PLI/VPI/DPI/SystemC. The direct interaction with simulator kernel
must be restricted to the standard simulator callbacks or SystemVerilog/SystemC processes.

Extensions to SystemVerilog DPI

The Questa SIMsimulator supports various extensions to the SystemVerilog DPI.
• SystemVerilog DPI extension to support automatic DPI import tasks and functions.
You can specify the automatic lifetime qualifier to a DPI import declaration so that the
DPI import task or function can be reentrant.

328 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 of import functions:

import DPI-C cfoo = task automatic foo(input int p1);
import DPI-C context function automatic int foo (input int p1);

Questa® SIM User's Manual, v2023.4 329

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. The Questa SIM debug environment 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

The Class Instance Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Logging Class Types and Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Working with Class Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Working with Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Working with Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Conditional Breakpoints in Dynamic Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Stepping Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
The Run Until Here Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Class Instance Garbage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Enabling Class Debug

You can enable visibility of class instances in your design in two ways.
Procedure
Use either of the following methods:

• Use the vsim command with the -classdebug argument.

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

330 Questa® SIM User's Manual, v2023.4

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.

You can use the class type name alone in the CIID if the class type name is unique in the design.
If the class type name is not unique, the full path to the type declaration is necessary.

You can use the CIID in commands such as examine, describe, add wave, and 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

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

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

You can use the built in system function $get_id_from_handle( class_ref ) to obtain the string
representing the class instance id for the specified class reference.

Questa® SIM User's Manual, v2023.4 331

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

Procedure
Add the $get_id_from_handle( class_ref ) function to your design to return the CIID of the
class item referenced by var.

myclass var;
initial begin
#10
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.
• 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.
• 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.

• 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.
• Log a Class Path Expression. Refer to Working with Class Path Expressions for more
information.

332 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Finding the Class Type Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Viewing Class Types in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

Questa® SIM User's Manual, v2023.4 333

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

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Descriptive Class Type Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Authoritative Class Type Names

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.
Authoritative names offer a short, well-formed name for a parameterized class specialization.
Authoritative names end with "__n" where 'n' is an integer. For example:

/pkg::mypclass__6.

Descriptive Class Type Names

Descriptive names more closely resemble the class definition, can be very long and difficult to
read and parse.
Descriptive names are used in error messages and are shown in some places in the GUI such as
in the class tree window. For example:

/pkg::mypclass #( class inputclass, 128, class report__2 ).

The classinfo descriptive command translates an authoritative name to a descriptive name. For
example:

classinfo descriptive /pkg::mypclass__6

returns:

# 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> can be specified using the specific class type name or any path that resolves
to the class type.

334 Questa® SIM User's Manual, v2023.4

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

For example: @packet@134 can 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”:

classinfo types -n *foo*

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

Questa® SIM User's Manual, v2023.4 335

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
The Class Graph Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
The Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

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 6-5)

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

336 Questa® SIM User's Manual, v2023.4

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

You can organize by extended class (default) or by base class. Figure 6-6shows an example of
using this window to display all the relationships among the classes in your design.

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

Questa® SIM User's Manual, v2023.4 337

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 6-7. Classes in the Structure Window

338 Questa® SIM User's Manual, v2023.4

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 use the Class Instances window, the classinfo report, or the classinfo instances
command to see how many instances have been created. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Viewing Class Instances in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
The Locals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
The Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
The Capacity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
The Call Stack Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

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 choosing View > Class Browser > Class
Instancesfrom the main menu or by specifying view classinstances on the command line.
(Figure 6-8)

Questa® SIM User's Manual, v2023.4 339

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 6-8. The Class Instances Window

You must enable the class debug feature to use the Class Instances window. Refer to Enabling
Class Debug for more information.

The Class Instances window is dynamically populated when you select 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 choosing File > Environment > Fix to Current Context when
the Class Instances window is active. from the main menu

340 Questa® SIM User's Manual, v2023.4

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

There is a suggested workflow for logging SystemVerilog class objects in the Wave window.

Workflow
1. Log the class objects you are interested in viewing (refer to Logging Class Types and
Class Instances for more information)
2. In the Structure Window, select a design unit or testbench System Verilog class type 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 6-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.

Questa® SIM User's Manual, v2023.4 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 Instances

Figure 6-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 6-10).

Figure 6-10. Class Information Popup in the Wave Window

342 Questa® SIM User's Manual, v2023.4

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.

The Watch Window

The Watch window displays signal or variable values at the current simulation time. It enables
you to 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 6-11).

Figure 6-11. Class Viewing in the Watch Window

Refer to Watch Window in the GUI Reference Manual for more information.

Questa® SIM User's Manual, v2023.4 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 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.
Questa SIM 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 enables you to view 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.

344 Questa® SIM User's Manual, v2023.4

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.
• can be added to the Wave window.
• can be expanded inline in the Wave window without having to add class objects to the
Wave window individually.
• can 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Adding a Class Path Expression to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Class Path Expression Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Casting a Class Variable to a Specific Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Class Objects vs Class Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Disabling Class Path Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

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

Questa® SIM User's Manual, v2023.4 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 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 can have one of several possible values.
• The expression can have a standard value of the type of the leaf element in the
expression.
• The expression can have a value of ‘Null’ if the leaf element is a class reference and its
value is null.
• The expression can have a value of ‘Does Not Exist’ if 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 6-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.

346 Questa® SIM User's Manual, v2023.4

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 6-13. /top/a Cast as c1 and c1prime

Procedure
1. Right-click (RMB) the class variable waveform to display a popup menu and choose
Cast to.
2. Right-click over the name/value of the class reference in the Pathnames or the Values
Pane of the Wave window to open a popup menu.
3. Choose Cast to > <class_type>. The current value will have check mark next to it.
(Figure 6-14)

Questa® SIM User's Manual, v2023.4 347

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

Figure 6-14. Casting c1 to c1prime

Class Objects vs Class Path Expressions

By default, the user interface interprets paths that include class references as path expressions.
There are cases where the interpreted object is what is desired and not the path expression.
For example,

add wave /top/myref.prop

adds the class path expression to the wave window. The expression is 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

adds the current 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 disables the interpretations of
all class path expressions. This is equivalent to the behavior in version 10.2 and earlier.

Conditional Breakpoints in Dynamic Code

Set a breakpoint or a conditional breakpoint at any place in your source code.

348 Questa® SIM User's Manual, v2023.4

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

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,
which 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
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)}{
stop
} else {
run -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.

Questa® SIM User's Manual, v2023.4 349

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

For example:
Table 6-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.

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 runs from the current simulation time and
stops on the specified line of code.
The simulator stops at the specified time, unless:

• It encounters a breakpoint.
• The Run Length preference variable causes the simulation run to stop.
• It 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.

350 Questa® SIM User's Manual, v2023.4

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

You can enter commands on the command line in the Transcript window to interact with class
instances.
This allows you to work with data for class types, their scopes, paths, names, and related
information. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Class Instance Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Calling Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
The classinfo Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

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

Questa® SIM User's Manual, v2023.4 351

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

describe @questa_messagelogger_report_server@1

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 and class functions directly from the
Vsim command line in live simulation mode and Verilog interface system tasks and system
functions.
Function return values are returned to the Transcript window as a Tcl string, where is it returns
the class instance ID when a function returns a class reference.

352 Questa® SIM User's Manual, v2023.4

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

Call a static function or a static 0 time task from the command line, for example:

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

Questa® SIM User's Manual, v2023.4 353

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Determining the Current State of a Class Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Finding All Instances of a Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Reporting Statistics for All Class Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Reporting Class Instance Statistics for a Simulation Run . . . . . . . . . . . . . . . . . . . . . . . . 357
Reporting Active References to a Class Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Finding Class Type Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Listing Classes Derived or Extended From a Class Type . . . . . . . . . . . . . . . . . . . . . . . . 358
Analyzing Class Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

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

which returns:
# Class /std::mailbox::mailbox__1 maps to mailbox #(class uvm_phase)

354 Questa® SIM User's Manual, v2023.4

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

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>

Results
Examples
• Verify the existence of the class instance @mem_item@87
classinfo find @mem_item@87

which returns:
# @mem_item@87 exists

or
# @mem_item@87 not yet created

or
# @mem_item@87 has been destroyed

Finding All Instances of a Class Type

The classinfo instances command reports the list of existing class instances for a specific class
type. This can be useful in determining what class instances to log or examine. It can also help
in debugging problems resulting from class instances not being cleaned up as they should be
and causing 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.
classinfo instances mem_item

Questa® SIM User's Manual, v2023.4 355

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

which 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

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

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

356 Questa® SIM User's Manual, v2023.4

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

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

Reporting Active References to a Class Instance

The classinfo trace command displays the active references to the specified class instance. This
is 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
can lead to uncovering bugs in managing these class references, which can lead to large
memory savings.
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

Questa® SIM User's Manual, v2023.4 357

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

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 shows all of
the super classes of a class type, back to its 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

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,
is a 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 6-15). 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.

358 Questa® SIM User's Manual, v2023.4

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

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

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.

Questa® SIM User's Manual, v2023.4 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

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

360 Questa® SIM User's Manual, v2023.4

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, it creates and destroys class instances and stores the data 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Changing the Garbage Collector Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Running the Garbage Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Default Garbage Collector Settings

Automatic execution of the garbage collector is dependent upon how your design is simulated.

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

Questa® SIM User's Manual, v2023.4 361

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 6-16. CLI Garbage Collector Commands and INI Variables
Action Commands INI Variable INI Variable
Set Memory gc configure “GCThreshold” on page 1616 or vsim
Threshold -threshold <value> “GCThresholdClassDebug” on -gcthreshold <value>
page 1617
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, choose Tools > Garbage
Collector > Configure from the main menu to open the dialog box (Figure 6-16).
Figure 6-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.

362 Questa® SIM User's Manual, v2023.4

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

Running the Garbage Collector

You can run the garbage collector at any time.
Procedure
Enter gc run at the command line.

Questa® SIM User's Manual, v2023.4 363

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
OVM-Aware Debugging Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
OVM-Aware Debug Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

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. Compile — 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/

364 Questa® SIM User's Manual, v2023.4

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. Optimize — You can explicitly or implicitly run vopt. There are no special settings to
enable OVM-Aware debugging.
3. Elaborate — 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. Prepare for Debug — 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 item.
5. Simulate — 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.

Questa® SIM User's Manual, v2023.4 365

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Finding Matching Get and Set Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

Locating Blocking Calls in the OVM Hierarchy

If your OVM environment is in a state 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 that the
element is 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.

366 Questa® SIM User's Manual, v2023.4

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 so that your OVM Hierarchy window
highlights 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.

Questa® SIM User's Manual, v2023.4 367

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 change as you advance through the simulation.
OVM Globals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Hierarchy Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Components Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
OVM Sequence Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

OVM Globals Window

Display this window by choosing the View > OVM > OVM Globals menu item.
The OVM Globals window contains information that is not specific to an OVM component.
Specifically it contains information about phases, barriers and blockers.
• 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

Display this window by choosing the View > OVM > OVM Hierarchy menu item.
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.

OVM Components Window

Display this window by selecting right-clicking on a component in the OVM Hierarchy window
and selecting “View Component Details”.
The OVM Components window contains information about the specific component.
• Get Configurations — and where they are set from.

368 Questa® SIM User's Manual, v2023.4

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

• Set Configurations — and where they are used.

• Stop Request information

OVM Sequence Window

Right-click a sequence in the OVM Hierarchy window, and select View Sequence Details to
display the OVM Sequence window.
The OVM Sequence window contains textual information about the selected sequence and its
current state.

Questa® SIM User's Manual, v2023.4 369

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM-Aware Debug

UVM-Aware Debug
UVM-Aware Debug provides information at the UVM abstraction level that connects you to the
UVM base-class library.
The Questa SIM installation tree includes the latest qualified, pre-compiled version of the
Accellera UVM package library. It also contains a pre-compiled DPI library necessary for
UVM integration intoQuesta SIM, as well as a UVM debugging package called
questa_uvm_pkg that is specific to Questa SIM. These three pieces work together to provide
both standard UVM support plus theQuesta SIM capabilities of UVM-Aware debugging.

Compiling Your Simulation for UVM-Aware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Simulating With UVM-Aware Debug Enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
UVM Information in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
UVM Transaction Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Setting UVM Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
UVM Backdoor Read/Write with vopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
UVM Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
UVM Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Compiling Your Simulation for UVM-Aware Debug

This section describes the steps you must take to compile the UVM libraries and the UVM-
Aware Debug features together with your UVM testbench.
Prerequisites
• Your UVM Source Code — Your SystemVerilog source code based on the Universal
Verification Methodology (UVM) v1.1 or greater. Refer to
http://verificationacademy.com/topics/verification-methodology
for more details.
• Compilation — The most recent UVM library comes pre-compiled with each
Questa SIM installation. It is highly recommended that you use the pre-compiled
libraries supplied in the Questa SIM install tree because it minimizes potential errors
during compilation and simulation startup, and it enables you to use the built-in UVM-
Aware Debug capability without any additional compilation overhead.
Procedure
Compiling UVM libraries.

370 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Compiling Your Simulation for UVM-Aware Debug

• To use the pre-compiled libraries, your UVM source needs to import the uvm_pkg.
The UVM source is then automatically imported when you compile your UVM
source with a command similar to:
vlog <my_uvm>.sv

• If you must use a UVM library that is not part of the Questa SIM installation, then
there are a variety of ways to compile it. One flow is outlined below. You will need
to compile the UVM source library and UVM DPI, the Questa SIM UVM-Aware
library, and your UVM testbench source files using the +incdir+ argument to vlog.
For example:
setenv UVM_HOME /absolute/path/to/appropriate/dir
setenv QUESTA_UVM_HOME /<questa_install_dir>/verilog_src/ \
questa_uvm_pkg-1.2
vlog +incdir+$(UVM_HOME)/src $(UVM_HOME)/src/uvm_pkg.sv \
$(UVM_HOME)/src/dpi/uvm_dpi.cc -ccflags -DQUESTA
vlog +incdir+$(UVM_HOME)/src +incdir+$(QUESTA_UVM_HOME)/src \
$(QUESTA_UVM_HOME)/src/questa_uvm_pkg.sv
vlog +incdir+$(UVM_HOME)/<path>/<uvm_design_source>

Code Description
Define the $UVM_HOME environment variable to the location of the UVM
kit.
Define the $QUESTA_UVM_HOME variable to the location of
questa_uvm_pkg.sv
Compile the UVM kit
Compile the Questa SIM UVM-Aware library
Compile the UVM testbench source files

If you need to compile the UVM package locally and increase the size of the UVM
register, you need to add the following arguments:
o vlog -ccflags “-DQUESTA” — Defines the C macro QUESTA.
o vlog -ccwarn off — Suppresses warnings.
o +UVM_REG_DATA_WIDTH=<n> — Increases UVM register size.
For example:
vlib lib_UVM

Questa® SIM User's Manual, v2023.4 371

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Simulating With UVM-Aware Debug Enabled

vlog -work lib_UVM +define+UVM_REG_DATA_WIDTH=128 \

-ccflags "-DQUESTA" -ccwarn off \
+incdir+${UVM_HOME}/src \
${UVM_HOME}/src/uvm_pkg.sv \
${UVM_HOME}/src/dpi/uvm_dpi.cc \
${QUESTA_HOME}/verilog_src/questa_uvm_pkg-1.2/src/questa_uvm_pkg.sv

Note
If you change the version of UVM you are using, you will need to recompile the
questa_uvm_pkg.

Simulating With UVM-Aware Debug Enabled

At design elaboration time, the simulator automatically detects the use of the uvm_pkg in your
source code, and automatically pulls in the UVM DPI library and the questa_uvm_pkg. No
special options are required. By default, the simulator pulls in UVM component hierarchy
information to populate the Structure window. The simulation results do not change due to
randomization issues, whether UVM debugging is turned on or off. The simulation results
match between debug and non-debug mode.
After design elaboration is complete you will see an empty “uvm_root” component in the
Structure window. Since UVM elaboration does not occur until time 0, you must execute a run
command to populate the Structure window with the UVM component hierarchy. You can
execute a “run 0” to visualize the UVM testbench components before simulating your design.

Besides the Structure window population and the random stability functionality, UVM-Aware
debug has other available features. These are all controlled with the vsim switch -uvmcontrol. In
Questa SIM these include: Message Viewer display of UVM messages, Wave window viewing
of UVM transactions, and automatic transaction logging of sequences.

Questa SIM UVM-aware debug tries not to adversely impact simulation performance, so the
default UVM debug setting is -uvmcontrol=struct, as described below. You can use the “all”
option to enable all features of the questa_uvm_pkg, but doing so may enable unnecessary
functionality. You can use any of the following UVM-Aware arguments to enable and disable
features of vsim -uvmcontrol:

Arguments may be specified as multiple instances of -uvmcontrol. Multiple arguments are

specified as a comma separated list without spaces.

• all — Enables all UVM-Aware functionality and debug options except disable and
verbose. You must specify verbose separately.
• certe — Enables the integration of the elaborated design in the Certe tool. Disables
Certe features when specified as -certe.
• disable — Prevents the UVM-Aware debug package from being loaded. Changes the
results of randomized values in the simulator.

372 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Simulating With UVM-Aware Debug Enabled

• msglog — Enables messages logged in UVM to be integrated into the Message Viewer
window. You must also enable WLF message logging by specifying tran or wlf with
vsim -msgmode. Disables message logging when specified as -msglog
• 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.
• 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.
• trlog — Causes the Questa specific implementation of the UVM Recorder interface to
be used to record transactions. When the UVM automatically records sequences or
sequence items, they are recorded in the WLF file. These recorded transactions are then
available to view in the Wave window. Transaction logging is off by default, and can be
turned off explicitly by using '-trlog'.
• verbose — Sends UVM debug package information to the transcript. Does not affect
functionality. Must be specified separately.
For more information on the -uvmcontrol argument, refer to the vsim command description in
the Reference Manual.

If you enable UVM message logging integration (via the vsim the -uvmcontrol=all or
uvmcontrol=msglog option) you should also enable the Message Viewing functionality with the
-msgmode option, since the default behavior is for messages to only appear in the transcript
window. Set -msgmode to either “wlf” or “both” to have messages populate the Message
Viewer window.

Note
A useful, related feature is vsim -classdebug. Among other things, it allows class handles to
be used on the command line to examine class contents, and populates the Class Instance
browser. For more information on the -classdebug argument, refer to the vsim command
description in the Reference Manual.

In summary, the fullest UVM-aware debug flow is available if you invoke vsim with the
following arguments:

vsim -classdebug -msgmode both -uvmcontrol=all \

<Design_Name>

You can set these vsim arguments as your default settings by adding them to the [vsim] section
of the modelsim.ini file. For example:

[vsim]
ClassDebug = 1
msgmode = both
UVMControl = struct,msglog,trlog

Questa® SIM User's Manual, v2023.4 373

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Information in the GUI

UVM Information in the GUI

You can view UVM design units, component hierarchy, configuration database objects, and
transaction streams in the GUI.
UVM Component Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Macros and Expanded Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
UVM Streams, Configuration DB Objects, and Sequences . . . . . . . . . . . . . . . . . . . . . . . 375
Processes Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
UVM Message Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

UVM Component Hierarchy

The Structure window provides you with a hierarchical view of all UVM design components in
your design.
Figure 6-17. Structure Window Showing UVM Hierarchy

The red stars in Figure 6-17 indicate design elements created after you elaborate by entering
run 0 on the command line. You can explore the UVM components in your design and drag and
drop the design units into the Objects window, Wave window, Watch window, and more. Refer
to SystemVerilog Class Debugging for more information about viewing class objects.

Macros and Expanded Macros

You can view macros and expanded macros once your simulation has loaded by opening a
source file and hovering your cursor over a declaration in the source code.

374 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
UVM Information in the GUI

Figure 6-18 shows an example of hovering the cursor over a declaration (Line 35) and viewing
a macro.

Figure 6-18. Expanded UVM Macro

UVM Streams, Configuration DB Objects, and Sequences

The UVM Details window displays information about UVM objects you select in the Structure
window.
Figure 6-19 shows an example of Stream mode, which displays any existing transaction streams
that exist at or below the UVM component hierarchy you selected in the Structure window. You
can drag UVM stream objects into the Wave window.

Figure 6-19. UVM Details Window Stream Mode

Questa® SIM User's Manual, v2023.4 375

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Information in the GUI

Figure 6-20 shows an example of ConfigDB mode, which displays any configuration database
items that are accessible to the UVM component you selected in the Structure window. It
displays the value, the type, and whether the configuration item is written to, or read. All of the
configuration database items are listed when you select the uvm_root component. You can use
this window to help debug testbench name mismatches which can cause failure of the testbench.

Figure 6-20. UVM Details Window ConfigDB Mode

Figure 6-21 shows an example of the Processes window displaying hierarchy mode, includeing
a list of sequencers and the active sequences running under them for the currently selected
UVM hierarchy.

Figure 6-21. UVM Details Window Sequence Mode

Processes Window
You can use the Processes window to display a class instance ID and UVM components with
the UVM full name as well as the full path.
Figure 6-22 shows an example of the Processes window displaying hierarchy mode.

376 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
UVM Information in the GUI

Figure 6-22. Processes Window Hierarchy Mode with UVM Components

UVM Message Viewing

You can access, organize and analyze any UVM_INFO messages (shown in Questa SIM as
Notes), Warnings, Errors, or other elaboration and runtime messages during the simulation run.
Figure 6-23 shows an example of several UVM_INFO messages.

Figure 6-23. UVM Message Viewing

Refer to Message Viewer Window in the GUI Reference Manual for more information about
working with objects in the Message Viewer window.

Questa® SIM User's Manual, v2023.4 377

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Transaction Recording

UVM Transaction Recording

The UVM has the capability to automatically record transactions. The automation records a
sequence execution as a transaction, and records a sequence item as a transaction. The execution
of the sequence body() is the recorded transaction for a sequence, and the start_item/finish_item
pair is the recorded transaction for a sequence item. If the body of a sequence consumes no time,
then a zero time transaction is recorded. If the start_item/finish_item pair consumes no time,
then a zero time transaction is recorded.
After a UVM transaction has been recorded, you can view it in the Wave window.

Prerequisites
• The UVM transaction recording automation is implemented in two layers. Both layers
must be enabled in order for transactions to be recorded and viewable in the wave
window.
The first layer is the UVM itself. It will automatically call a user defined function named
'do_record' for the sequence or sequence_item. Do_record should be implemented to
record the interesting attributes for the sequence or sequence_item.
For example, you can use the UVM/OVM built-in ‘uvm_record_attribute() macro in
your transactions:
function void do_record(uvm_recorder recorder);
super.do_record(recorder);

`uvm_record_attribute(recorder.tr_handle, "id", id);

`uvm_record_attribute(recorder.tr_handle, "delay", delay);
endfunction

Refer to “Macros and Expanded Macros” for information about viewing macros and
expanded macros in your source code.
The second layer is the Questa SIM specific layer which implements the actual
recording into the WLF file. Turn on “recording_detail” in your source.
For example:
uvm_config_db#(int)::set(null, "*", "recording_detail", 1);

Note
This setting is normally set before the UVM component hierarchy is constructed.
For example, in the top level of the testbench, before calling run_test(). The
recording_detail is a configuration variable which is built in to the UVM. It adheres to
all the usual config variable rules.

Procedure
1. Load your design
vsim -classdebug -msgmode both -uvmcontrol=all

378 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
UVM Transaction Recording

• -classdebug enables visibility into class instances.

• -msgmode both outputs messages to both the transcript and the WLF file.
• -uvmcontrol=all enables all UVM-Aware functionality and debug options.
2. Elaborate your design to create the dynamically-allocated UVM components.
run 0

3. Open the UVM Details window by selecting View > UVM Details or by entering view
uvm details on the command line. Then select the UVM component that contains the
streams you want to view. The transaction streams are automatically loaded into the
UVM Details window.
4. Drag and drop the transaction streams you want to view from the UVM Details window
into the Wave window or choose Add > Wave to add the transaction stream to the
Wave window. Run the simulation and view the results in the Wave window
(Figure 6-24).

Questa® SIM User's Manual, v2023.4 379

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Transaction Recording

Figure 6-24. UVM Transaction Streams in Wave Window

380 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Setting UVM Breakpoints

Setting UVM Breakpoints

You can set breakpoints on UVM instances and function entrances.
Setting a Breakpoint on a Specific UVM Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Setting a Breakpoint on a Function Entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Setting a Breakpoint With the UVM Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Setting a Breakpoint on a Specific UVM Instance

The bp command accepts UVM-style instance names for setting source breakpoints for class
instances in a UVM hierarchy. You control this when the -inst <instance_name> argument is
preceded by a -uvm argument.
Procedure
Enter the bp command using the -uvm and -inst arguments in the proper order.

bp <filename> <line_number> -uvm -inst

Examples
The following command breaks the simulation run on line 104 of file envA.sv.

bp envA.sv 104 -uvm -inst uvm_test_top.e1.a

The simulation breaks on line 104 if the 'this' pointer was representing the UVM component
"uvm_test_top.e1.a" as determined by a UVM get_full_name() function call.

Setting a Breakpoint on a Function Entry

The bp in command accepts function and task names to support a “stop in function entrance”
capability. This allows you to set a breakpoint without needing the precise file and line number
of a given function. The bp command places a breakpoint on the first executable line of the
specified task or function.
Procedure
Enter the bp in command with a function or task name.

bp in <function_name>

Examples
bp in /uvm_pkg::uvm_component::set_config_int -cond {this == @myunit@1}
bp in /mem_agent_pkg::mem_seq5::body

Questa® SIM User's Manual, v2023.4 381

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Backdoor Read/Write with vopt

Setting a Breakpoint With the UVM Details Window

Questa SIM allows you to set a breakpoint on a UVM Hierarchical instance by right-clicking a
sequence in the Sequence mode of the UVM Details window.
Procedure
1. Right-click a sequence in the Sequence mode of the UVM Details window.
2. Choose Break in Body for this instance or Break in Body for any instance from the
right-click popup menu.

UVM Backdoor Read/Write with vopt

QuestaSIM through the vopt command can automatically detect the objects requiring access for
UVM backdoor read/write. The paths are identified based on the UVM code written for the
register access layer.
The vopt option -uvmaccess automatically identifies objects which require access at vsim run
time. Vopt internally enables access flow, and objects will be marked with read/write access.

The vopt command has these options:

• -uvmaccess[+scope]. Enables access flow and automatically detects objects needing rw

access. The +scope enables access on all the objects in the scopes identified in UVM
code when names of the objects are not statically available.
• -uvmaccesspath=<path>. Option to provide prefix path under which UVM paths will be
checked
• -uvmaccessrange=<int>,<int>. Option to specify integer values in case uvm code does
not provide static values
• -uvmaccesslogfile=<filepath>. Specify the path of the file where collected information
can be dumped to see which paths are getting identified.
• -uvmaccesseffort=<low/high>. Extraction features provided with effort level. The effort
level is high by default.
The following provides a number of examples. An example vopt command line:

vopt -uvmaccess -o my test

382 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
UVM Backdoor Read/Write with vopt

Following is an example of UVM code where paths are specified:

class js_test extends uvm_test;

js_block rm;
js_seq seq;
`uvm_component_utils(js_test)
function new(string name = "js_test", uvm_component parent=null);
super.new(name, parent);
endfunction
function void build_phase(uvm_phase phase);
rm = js_block::type_id::create("rm");
rm.set_hdl_path_root("test.DUT");
rm.build();
rm.lock_model();
endfunction : build_phase

class js_block extends uvm_reg_block;

`uvm_object_utils(js_block)
rand js_reg regA;
uvm_reg_map bus_map;
function new(string name = "js_block");
super.new(name, UVM_NO_COVERAGE);
endfunction
virtual function void build();
regA = js_reg::type_id::create("regA");
regA.configure(this,null,"registerA[255:0]");
regA.build();
bus_map = create_map("bus_map", 'h0, data_size/8, UVM_LITTLE_ENDIAN);
default_map = bus_map;
us_map.add_reg(regA, 'h00000900, "RW");
lock_model();
endfunction
endclass

The calls shown in the italic in the example above are some of the examples where paths are
specified in UVM code. These types of calls are used to extract path information with this
option.

The option -uvmaccesspath can be used to specify a path under which UVM registers or other
paths will be searched. The path specified in this option like setting hdl path root using
set_hdl_path_root() call. This option can be used in case user code does not have complete
register hierarchy.

Take the following command line example:

vopt -uvmaccess -uvmaccesspath=/test/DUT -o my test

The option -uvmaccessrange can be used to specify integer range for creating paths when
integer value is not known at vopt time. A default range of 0,7 is used. But this range can be
changed by the user. This range is also used for unrolling for loops when range of values in for
loops is not known.

Questa® SIM User's Manual, v2023.4 383

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Backdoor Read/Write with vopt

Here is an example:

class c1:
task mytask( ;
begin
bit tmp ;
bit [3:0] tmp4 ;
int ret ;
string str ;
string str1 ;

int sel = top.dut.mid.sel;

str1 = $sformatf("%s%0d", "reg_s_", sel) ;
str = $psprintf("/top/dut/%s", str1);
if (uvm_hdl_check_path(str)) begin
ret = uvm_hdl_read(str, tmp) ;
if (ret == 1) $display("@%0t %s = %b", $time, str, tmp) ;end

In the previous example, value of sel is coming through an a hier ref so it is not known within
the task. The default values of 0 to 7 are used in this case to find the path for
uvm_hdl_check_path() call. This range can be changed using the option -uvmaccessrange.

vopt -uvmaccess -uvmaccessrange=0,15 -o my test

The option -uvmaccesslogfile can be used to dump a file where verbose information is provided
about the paths in the register model. It also provides information which paths were present in
the design and which ones were not found.

vopt -uvmaccess -uvmaccesslogfile=myfile.txt -o my test

In the command line below:

vopt -uvmaccess -uvmaccessseffort=low -o my top

This command disables analysis of code in the initial block as shown in the example below:

module hdl_top;
import uvm_pkg::*;
`include "uvm_macros.svh"
bit clock;
simple_if inf (.clk(clock));
uvm_status_e status;
initialbegin
bit [7:0] rd_val = 0;
#50; // get between updates to q
inf.mp_master.valid=6;
if (!uvm_hdl_read("inf.mp_master.valid",rd_val))
`uvm_error("inf.mp_master.valid", "uvm_hdl_read returned FALSE")
end
endmodule

This option sets access on all the objects in the scopes which do not have static register names:

vopt -uvmaccess+scope -o my top

384 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
UVM Commands

string name = register_names[i];

d_hdl_path('{'{$sformatf("dspw.accum_%0s[%0d]%s",
name.substr(3,3).tolower(), ctxt, width), -1, -1}}, ctxt_no);

In the previous code, register names cannot be constructed due to a function call. But the scope
name for the register is known. As a result the access will be set on all the objects in scope
dspw.

UVM Commands
Questa SIM provides a number of commands for use with UVM test benches.

Table 6-17. UVM Commands

Command Shortcut Description
uvm call Calls a UVM SV function - default sub-command.
uvm configtracing uvm ct Enables or disables printing of configuration database
reads and writes to the transcript as they occur.
uvm displayobjections uvm do Displays current objections.
uvm handle Returns simulation handle (class instance identifier or
CIID) of an object.
uvm help Prints the list of uvm sub-commands.
uvm mapmode uvm mm Sets the uvm command path mapping mode (default is
uvm-style).
uvm printconfig uvm pc Prints the global component-level configuration data.
uvm printfactory uvm pg Prints the global factory information.
uvm printstreams uvmm ps Prints a list of transaction streams for a specified
hierarchy.
uvm printtopology uvm pt Prints the global topology structure.
uvm setverbosity uvm sv Sets the uvm reporter verbosity level.
uvm simpath uvm sp Maps the path of a UVM hierarchical component to a
simulator /uvm_root context hierarchy string.
uvm traceobjections uvm to Enables objection tracing
uvm uvmpath uvm up Returns a UVM component path given a simulator /
uvm_root path

UVM Object Paths

Many of the uvm sub-commands accept UVM object paths as parameters. A UVM object path
is a hierarchical path to an initialized UVM SV class object.

Questa® SIM User's Manual, v2023.4 385

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
UVM Framework

If vsim has been started with the -classdebug switch, a path can be specified by using the class
instance id string; for example, "@my_class@3".

Also, a UVM object can be referenced by its' UVM hierarchical path that has been registered
when the class was allocated via the UVM create() method. This is the path returned from a
UVM get_full_name() function call. This is referred to as a "UVM path".

For example:

uvm_test_top.middle.bottom0.my_obj

A UVM object can be referenced by the hierarchical path the simulator maps the UVM object
into within the sim:/uvm_root context (where the simulator collects all of the dynamically-
allocated UVM components). This hierarchical simulation path is similar to a UVM path,
except that path delimiters match the simulator's path delimiter settings, and some component
names may be slightly changed to use Verilog escaped identifiers if the component names do
not conform to Verilog naming rules. This type of path is referred to as a “simulation path”. For
example, a simulation path would look like:

sim:/uvm_root/uvm_test_top/middle/bottom0.my_obj

Any sub-command that accepts a UVM object handle parameter always looks first into the
current context to find that object. If the object does not exist in the current context, then the
parameter string is parsed to determine if it contains a hierarchy specification as described
above. In all cases, it will first check to see if the path is a class instance id string. If it is not,
then by default it will scan the path as a UVM-style path name. The default can be changed to
be simulation-style path names with the uvm mapmode command. Finally, even when the path
name mapping mode is in the default UVM-style mode, it still can accept simulation-style paths
if they start with a "sim:/uvm_root" prefix.

UVM Framework
Your installation of Questa SIM includes the UVM Framework, which provides a code base
that you can use to implement a UVM verification infrastructure, interconnect, and operation
environment.
The UVM Framework enables your verification team to develop an operational UVM-based
simulation environment, which allows them to focus on verifying product features. The
environment could include creating prediction models and defining coverage models.

The UVM Framework installation and its Users Guide are located in the Questa SIM
installation under the <install_dir>/examples/UVM_Framework/ directory.

386 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

The learning curve of UVM testbenches may limit a product team from realizing the
productivity and quality benefits of using advanced verification. Fortunately, UVM Framework
allows teams new to UVM to be productive from the beginning by:

• Providing a jump-start for learning UVM and building UVM verification environments.
• Defining an architecture and reuse methodology.
UVM Framework is a model reuse methodology, which experienced UVM teams can leverage.
It supports component-level verification reuse across projects and environment reuse from
block through chip to system-level simulation.

For standard protocols, UVM Framework automatically integrates interfaces from the Questa
VIP library. This integration uses the Questa VIP Configurator, which allows users to
graphically select and configure their VIP and then generate UVM Framework-based code. For
custom protocols the UVM Framework code generator creates the base code for a complete
interface package.

UVM Framework and its examples run in pure simulation as well as simulation with Veloce
acceleration. Code generators provided by the UVM Framework create interfaces,
environments, and testbenches that run on Veloce without modification.

Makefiles within the UVM Framework examples and its generated code support the use of
Siemens Visualizer. A simple command line argument ensures the proper settings for advanced
debug features for RTL designs and UVM.

UVM Framework demonstrates the use of Questa Verification Management, VRM and inFact.
Integration of these technologies accelerates coverage closure through stimulus creation,
regression management, and coverage analysis.

Autofindloop and the Autofindloop Report

When a simulation enters a zero delay loop, and the iteration count exceeds the iteration limit
setting, autofindloop (vsim –autofindloop) attempts to detect the loop and to create a report
describing it. When possible, the report identifies the active processes and event and signal
activity.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

Design content, optimization, and design visibility can have an impact on the content and detail
of the reported results. For behavioral designs, the best practice is to preserve line numbers with
+acc=l. For gate-level designs, having net visibility can provide additional information allowing
primitive process drivers to be identified.

Questa® SIM User's Manual, v2023.4 387

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

The autofindloop feature is implemented in the simulation kernel. It has no overhead associated
with it until it reaches the iteration limit. Exceeding the limit causes a process trace to be
performed until either the loop is identified, the simulation escapes the execution loop, or a
findloop step limit is exceeded. You can modify the default findloop step limit of 500 by setting
the MTI_FINDLOOP_STEP_LIMIT environment variable before invoking vsim.

The autofindloop report includes the following information:

• Active processes – Processes activated for evaluation.

• Wakeup Events – Events scheduled with a distributed delay.
• Wakeup Event Master Processes – Active processes that are members of a wakeup
activation block.
• Signal activity:
o Driving nets – Nets that are driven by an associated process.
o Signal – Nets that are activated due to a value change during loop execution.
Wakeup events that appear in the zero delay loop are zero delay events. Any non-zero delay
event that appears in the loop output is denoted as special, and terminates the loop analysis. This
action indicates that the simulation iteration limit is not large enough for the design.

The report uses indentation to associate information for display with the active processes. An
indented block can include the source file, the line number, and the driving nets.The report also
uses indentation to indicate the importance of loop activity; events and processes appear
leftmost in the output, and signal activity is indented further to denote reduced importance.

The autofindloop feature has some limitations, including:

• Vopt optimizations can affect the quality of the autofindloop output.

• There is no causality tracing to refine the reported loop activity.
• autofindloop does not require or use a generated QFD debug database.

388 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

Examples
The following design has a zero delay loop which is caused by Tvco_4 having an initial value of
0:

1 `timescale 1 ps / 1 ps
2
3 module top;
4
5 wire o;
6 reg some_clk, clk2;
7 real Tvco_4 = 1 / 4;
8
9 initial begin
10 $monitor ($time, " : %b %g", o , Tvco_4);
11 #0 clk2 = 0;
12 #10 some_clk = 0;
13 end
14
15 dut d1(clk2, o );
16 always @ (clk2)
17 #(Tvco_4) some_clk = clk2;
18
19 always @ (some_clk)
20 #(Tvco_4) clk2 = ~clk2;
21
22 endmodule
23
24 module dut (input i, output y);
25
26 mycell u1 (i, y);
27
28 endmodule
29
30 module mycell (input i, output o);
31
32 buf b (o, i);
33
34 endmodule

The following report shows the autofindloop output for this design when simulated with full
visibility (+acc). Note that this output optimizes the dut and u1 instances into a continuous
assignment, and denotes the implicit wire connection to clk2. The process associated with

Questa® SIM User's Manual, v2023.4 389

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

$monitor is not activated, because of its lower priority and the activation mechanism used by
unoptimized system tasks:

############# Autofindloop Analysis ###############

############# Loop found at time 0 ns ###############
# Active process: /top/#ALWAYS#19 @ sub-iteration 0
# Source: test.v:19
# Wakeup process: /top/#ALWAYS#19 @ sub-iteration 1
# Source: test.v:19
# Active process: /top/#IMPLICIT-WIRE(clk2)#15 @ sub-iteration 2
# Source: test.v:15
# Wakeup process: /top/#ALWAYS#16 @ sub-iteration 3
# Source: test.v:16
# Active process: /top/#ALWAYS#19 @ sub-iteration 4
# Source: test.v:19
################# END OF LOOP #################
# ** Error (suppressible): (vsim-3601) Iteration limit 10000000 reached at
time 0 ns.

The following report shows the autofindloop output for the same design, with optimizations and
preserved line numbers (+acc=l). Native code optimizations implement the $monitor system
task in this case. Also, optimizations cause the native code implementation of the dut and u1
instances, and the use of wakeup events arrays for process delays:

############# Autofindloop Analysis ###############

############# Loop found at time 0 ns ###############
# Active process: /top/#ALWAYS#19 @ sub-iteration 0
# Source: test.v:19
# Wakeup Event Array : @ sub-iteration 1
# Member process: /top/#ALWAYS#19 @ sub-iteration 1
# Source: test.v:19
# Active process: /top/#ALWAYS#16 @ sub-iteration 2
# Source: test.v:16
# Active process: Native Verilog Function @ sub-iteration 2
# Source: test.v:10
# Wakeup process: Native Verilog Function @ sub-iteration 3
# Source: test.v:0
# Wakeup Event Array : @ sub-iteration 3
# Member process: /top/#ALWAYS#16 @ sub-iteration 3
# Source: test.v:16
# Active process: /top/#ALWAYS#19 @ sub-iteration 4
# Source: test.v:19
################# END OF LOOP #################
# ** Error (suppressible): (vsim-3601) Iteration limit 10000000 reached at
time 0 ns.

The following report shows the autofindloop output for the same design fully optimized (no acc
settings).

390 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

############# Autofindloop Analysis ###############

############# Loop found at time 0 ns ###############
# Active process: Native Verilog @ sub-iteration 0
# Source: test.v:0
# Wakeup Event Array : @ sub-iteration 1
# Member process: Native Verilog @ sub-iteration 1
# Source: test.v:0
# Active process: Native Verilog @ sub-iteration 2
# Source: test.v:0
# Active process: Native Verilog Function @ sub-iteration 2
# Source: test.v:0
# Wakeup process: Native Verilog Function @ sub-iteration 3
# Source: test.v:0
# Wakeup Event Array : @ sub-iteration 3
# Member process: Native Verilog @ sub-iteration 3
# Source: test.v:0
# Active process: Native Verilog @ sub-iteration 4
# Source: test.v:0
################# END OF LOOP #################
# ** Error (suppressible): (vsim-3601) Iteration limit 10000000 reached at
time 0 ns.

The following portion of a report shows the autofindloop output for a gate-level design with net
and line visibility (+acc=nl). In the case of gate-level designs, active processes can map to gate
primitive instances. Net visibility then provides driving net names and values, and also provides
additional signal activity to offer additional context to the loop activity:

# Active process: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/ms_imqb @ sub-iteration

2
# Source: f.v:102
# Driving net: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/mq_b to St1
# Active process: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/ms_imqb @ sub-iteration
3
# Source: f.v:102
# Driving net: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/mq_b to St1
# Signal: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/q_b @ sub-iteration 3 at Value
St1 (f.v:17)
# Signal: /MBIST_uSRAM_tb/E1/u0/iaddra_0_/mq_b @ sub-iteration 3 at
Value St1 (f.v:17)

Note
Line number information for gate primitives currently references their parent instance.

Questa® SIM User's Manual, v2023.4 391

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog and SystemVerilog Simulation
Autofindloop and the Autofindloop Report

392 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 7
SystemC Simulation

This chapter describes how to compile and simulate SystemC designs with the Questa SIM
simulator. The simulator implements the SystemC language based on the Open SystemC
Initiative (OSCI) proof-of-concept SystemC simulator. The default supported version of
SystemC is the IEEE 1666-2011 standard, SystemC-2.3.2. Release 2.3.2 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.
In addition to the functionality described in the OSCI specification, Questa SIM 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).
• Support for the Accellera SystemC Verification Library (SCV-2.0.0) for both SystemC-
2.3.2.
Supported Platforms and Compiler Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Usage Flow for SystemC-Only Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Creating Shared Object Files for SystemC Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Binding to Verilog or SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Distributing SystemC IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Compiling SystemC Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Linking the Compiled Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Simulation of SystemC Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Debugging the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
SystemC Object and Type Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Modifying SystemC Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Code Modification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Differences Between the Simulator and OSCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
OSCI 2.3.2 Feature Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Troubleshooting SystemC Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Questa® SIM User's Manual, v2023.4 393

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 Questa SIM supported platforms.
One subset of supported platforms exists for SystemC-2.3.2 (Table 7-1).
Table 7-1. Supported Platforms for SystemC-2.3.2
Platform/OS Supported compiler versions1 32-bit 64-bit TLM
linux, linux_x86_64 gcc-10.3.0 yes yes 2.0.2
gcc-7.4.0
VCO is linux (32-bit binary)
VCO is linux_x86_64 (64-bit binary)
linux_aarch64 gcc-10.3.0gcc-7.4.0VCO is linux_aarch64 N/A yes 2.0.2
Windows2 gcc 7.4.0 — VCO is win32 yes no 2.0.2
gcc 7.4.0 — VCO is win64 no yes 2.0.2
1. Header files location: <path to questa install tree>/include/systemc/sc
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 7-2 shows how to specify a SystemC kernel (2.3.2) and a compiler version using the
sccom, vopt, and vsim commands with the -cppinstall option.
Table 7-2. Specifying SystemC Platform and Compiler Version
Command SystemC kernel/compiler version
sccom/vopt/vsim (No options - default) Linux: SC-2.3.2 / gcc-10.3.0
Windows: SC-2.3.2 / gcc-7.4.0
sccom/vopt/vsim -cppinstall 7.4.0 SC-2.3.2 / gcc-7.4.0

Building gcc with Custom Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Building gcc with Custom Configuration Options

The gcc configuration for Questa SIM has been qualified only for default options. If you use
advanced gcc configuration options, Questa SIM may not work with those options.
To use a custom gcc build, set the CppPath variable in the modelsim.ini file. This variable
specifies the pathname to the compiler binary you intend to use.

394 Questa® SIM User's Manual, v2023.4

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

When using a custom gcc, Questa SIM 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 7-3. Custom gcc Platform Requirements
Platform Mandatory configuration options
Linux none
Win32 GCC:
(MinGW) --disable-sjlj-exceptions
--with-dwarf2
--with-gnu-as
--with-gnu-ld
MinGW:--with-default-msvcrt=ucrt
Win64 GCC:
(MinGW) --disable-sjlj-exceptions
--enable-frame-pointer
--with-gnu-as
--with-gnu-ld
MinGW:
--with-default-msvcrt=ucrt

• The option --with-default-msvcrt=ucrt is required for MinGW C runtime/headers build.

This is required to ensure compatibility with Questa that is built using the new Microsoft
C runtime UCRT.
• 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>

By default Questa SIM also uses the following options when configuring built-in gcc:

• --disable-nls
• --enable-languages=c,c++

Questa® SIM User's Manual, v2023.4 395

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

These are not mandatory, but they do reduce the size of the gcc installation.

396 Questa® SIM User's Manual, v2023.4

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

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

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.
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.
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.
4. Perform a final link of the C++ source using sccom -link. 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 Questa SIM vsim command.
6. Run the simulation using the run command, which you enter at the VSIM> command
prompt.
7. Debug the design using Questa SIM GUI features, including the Source and Wave
windows.
Recommendations for using sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Simulating with sc_main at the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Checkpoint and Restore in a SystemC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Recommendations for using sc_main at the Top

Level
Generally, your design should include sc_main() at the top level in order for Questa SIM to run
the SystemC/C++ source code. Questa SIM 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().

Questa® SIM User's Manual, v2023.4 397

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

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

• Questa SIM 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 Questa SIM prompt and the sc_start() call
does not proceed unless an appropriate run command is issued from the Questa SIM
prompt. sc_start() always yields to Questa SIM 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.

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

398 Questa® SIM User's Manual, v2023.4

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

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 Questa SIM 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
Questa SIM simulation kernel before calling any delete and before returning from
sc_main. In Questa SIM, sc_start(-1) gives control to the Questa SIM 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.

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

Questa® SIM User's Manual, v2023.4 399

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

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.
Questa SIM 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). Questa SIM treats sc_initialize() as
sc_start(SC_ZERO_TIME).
• Questa SIM 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 Questa SIM. 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 Questa SIM.

400 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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(). Questa SIM 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, Questa SIM
will issue one or more warning messages to indicate that allowing checkpoint and restore is not
expected usage—Questa SIM 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.

Questa® SIM User's Manual, v2023.4 401

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), Questa SIM 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: There is a common SystemC file – common.cpp – that is used
in all tests. There are also test-specific SystemC files – test1.cpp, test2.cpp, and so on. The
following example procedure shows how to manage the tests and common code.

Prerequisites
• Must be running Questa SIM.
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

402 Questa® SIM User's Manual, v2023.4

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 -work test1
sccom -link -libshared common -work test2

• -libshared specifies the location of the intermediate shared object

• -work specifies the location of the final systemc.so
7. Run the tests:
vopt -work test1 top -o opt
vsim -lib test1 opt
vopt -work test2 top -o opt
vsim -lib test2 opt

Questa® SIM User's Manual, v2023.4 403

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.
Limitations of Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

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 Questa SIM 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>
sccom <options> <source files>
sccom -archive <archive_file_name>

404 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Distributing SystemC IP

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.
The Questa SIM SystemC libraries may contain third-party software, including open source
software. If you distribute your SystemC IP to others, you are required to meet the licensing
terms of the third-party software included in the Questa SIM SystemC libraries, as well as the

Questa® SIM User's Manual, v2023.4 405

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
SystemC Simulation
Distributing SystemC IP

licensing terms provided to you by Siemens EDA. Should you have further questions about
your obligations, please seek legal advice.

406 Questa® SIM User's Manual, v2023.4

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 sccomcommand)
• Run SystemC linker (the sccom -link command argument)
Creating a Design Library for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Exporting All Top-Level SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Invoking the SystemC Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Distributed sccom Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Compiling Optimized and/or Debug Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Specifying an Alternate g++ Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Verifying Compiler Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Maintaining Portability Between OSCI and the Simulator. . . . . . . . . . . . . . . . . . . . . . . 410
Using sccom in Addition to the Standalone C++ Compiler . . . . . . . . . . . . . . . . . . . . . . . 411
Incremental Compilation (Compile of Changed Files Only) . . . . . . . . . . . . . . . . . . . . . . 412
Issues with C++ Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
SCV Extensions for User-specified Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Mentor Dynamic Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

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.

Questa® SIM User's Manual, v2023.4 407

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 Questa SIM. 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
Questa SIM.
• 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

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

Distributed sccom Compilation

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

408 Questa® SIM User's Manual, v2023.4

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

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.

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 Questa SIM. To
compile your SystemC code for source level debugging in Questa SIM, 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 Questa SIM simulation database,
you can save compilation time by running sccom with the -nodebug argument. This bypasses
the parser which creates the Questa SIM 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.

Specifying an Alternate g++ Installation

Siemens EDA recommends using the version of g++ that is shipped with Questa SIM 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-10.3.0/bin, then you would set the variable as follows:

CppPath /u/abc/gcc-10.3.0/bin/g++

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

Questa® SIM User's Manual, v2023.4 409

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

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 Questa SIM and the OSCI proof-of-concept SystemC
simulator, you can use the MTI_SYSTEMC macro to execute the Questa SIM specific code in
your design only when running Questa SIM. 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 Questa SIM 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);

sc_start(100, SC_NS);
}
#endif

410 Questa® SIM User's Manual, v2023.4

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 Standalone C++ Compiler

Using sccom in Addition to the Standalone 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 a
standalone compiler like gcc 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Rules for Standalone g++ Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Rules for sccom Use

The rules governing when and how you must use sccom are as follows.
• You should compile all SystemC code with sccom.
• You must compile using sccom for the top-level, for mixed-language access (anywhere
there is a language boundary) or for debugging (waveform logging, Tcl command
interaction).
• When using sccom, you should not use the -l 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 standalone compiler to compile C/C++ functionality into archives or
shared objects, you must then link your design using the -L and -l options with sccom
-link. 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.

Rules for Standalone g++ Use

You can use the standalone g++ compiler to help with migration from a non-Questa SIM
environment, like OSCI-SystemC where existing make files using g++ already exist, or for
creating compile scripts that have to work with and without Questa SIM.
The -fPIC option to g++ should be used during compilation with sccom.

For C++ code, you must use the built-in g++ delivered with Questa SIM, or (if using a custom
g++) use the one you built and specified with the CppInstall variable in the modelsim.ini file.

Questa® SIM User's Manual, v2023.4 411

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)

Otherwise binary incompatibilities may arise between code compiled by sccom and code
compiled by the standalone compiler.

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 Questa SIM 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
Questa SIM 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) or changes to
comments. Except for 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 Questa SIM 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 ... sccom DEV compiler 2003.05 Mar 2 2008
Exported modules:
top
% sccom -incr -link
Model Technology ModelSim ... 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 ... sccom DEV compiler 2003.05 Mar 2 2008

412 Questa® SIM User's Manual, v2023.4

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)

-- Skipping file and2.cpp

-- Skipping file or2.cpp

Exported modules:
top

% sccom -incr -link

Model Technology ModelSim ... sccom DEV compiler 2003.05 Mar 2 2008

3. Link again without actually changing any file.

% sccom -incr -link
Model Technology ModelSim ... 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.
Questa SIM 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 Questa SIM to recompile the source file.
• If a design file consists of more than one SystemC module, changing even one module
causes Questa SIM 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).

Questa® SIM User's Manual, v2023.4 413

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

Organizing Templatized Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Generating SystemC Verification Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

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

414 Questa® SIM User's Manual, v2023.4

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;

Questa® SIM User's Manual, v2023.4 415

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.

416 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 417

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Enums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

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

418 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 419

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

420 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Constrained Randomization of the Data Type for Standard Vectors . . . . . . . . . . . . . . 423
Randomly Sized Fixed-Max Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

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

Questa® SIM User's Manual, v2023.4 421

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.

422 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 423

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

424 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 7-5. 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 or
time unit your SystemC source 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 sc_set_time_resolution()
and your delays get function or
truncated, set the GUI: Simulate > Start
resolution smaller; this Simulation > Resolution
value must be less than
or equal to the
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.

Questa® SIM User's Manual, v2023.4 425

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.
• end_of_simulation () — Called before ending the current simulation session.

426 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 427

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 Questa SIM, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Viewable SystemC Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Waveform Compare with SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Debugging Source-Level Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Setting Constructor/Destructor Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

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

428 Questa® SIM User's Manual, v2023.4

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

Note
The SystemC local variables will be viewable from the "view locals" window in Visualizer
GUI.

Questa® SIM User's Manual, v2023.4 429

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

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

430 Questa® SIM User's Manual, v2023.4

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

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.

The source code debugger, C Debug, is automatically invoked when the design is compiled for
debug in this way.

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

Questa® SIM User's Manual, v2023.4 431

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

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.

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

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

432 Questa® SIM User's Manual, v2023.4

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

Setting BPs with Automated Constructor Breakpoint Flow . . . . . . . . . . . . . . . . . . . . . . 433
Using Instance Based Breakpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Viewing SystemC Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

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.

Questa SIM 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 Questa SIM 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 Questa SIM icon in Windows.

Questa® SIM User's Manual, v2023.4 433

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

If the Welcome to Questa SIM dialog appears, click Close.

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. Questa SIM 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 Questa SIM keeps all the
breakpoints enabled even after design is loaded.
Results
When you set a destructor breakpoint, Questa SIM 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 Questa SIM. 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, Questa SIM
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>

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

434 Questa® SIM User's Manual, v2023.4

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 7-4. SystemC Objects and Processes

Questa® SIM User's Manual, v2023.4 435

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 Questa SIM displays certain objects and types, as
they may differ from other simulators.
Support for Globals and Statics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Support for Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
SystemC Dynamic Module Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Viewing FIFOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Viewing SystemC Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Properly Recognizing Derived Module Class Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Custom Debugging of SystemC Channels and Variables . . . . . . . . . . . . . . . . . . . . . . . . 443

Support for Globals and Statics

Context: Debugging
Globals and statics are supported for Questa SIM 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

436 Questa® SIM User's Manual, v2023.4

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

Questa SIM translates C++ scopes into a hierarchical arrangement. Because globals and statics
exist at a level above its scope, Questa SIM must add a top level, sc_root, to all global and static
signals. Thus, to view these static or global signals in Questa SIM, 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
Questa SIM 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. Questa SIM shows one signal - object "a" - in both cases.

The following aggregate would appear in the Wave window as shown in Figure 7-5:

sc_signal <float> fbus [6];

Questa® SIM User's Manual, v2023.4 437

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 7-5. Aggregate Data Displayed in Wave Window

SystemC Dynamic Module Array

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

438 Questa® SIM User's Manual, v2023.4

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 Questa SIM, 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

Questa® SIM User's Manual, v2023.4 439

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 Questa SIM 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,
Questa SIM 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 7-7.

440 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 441

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.

442 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 443

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 Questa SIM 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 Questa SIM 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, Questa SIM 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’)

444 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 445

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 7-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 7-8 for more details on the registration
and callback mechanism for such objects.

446 Questa® SIM User's Manual, v2023.4

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 Questa SIM.
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 Questa SIM, 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 7-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 Questa SIM.
Questa SIM 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 7-8 above.

Questa® SIM User's Manual, v2023.4 447

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.
Converting sc_main() to a Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Replacing sc_start() Function with Run Command and Options . . . . . . . . . . . . . . . . . . 448
Removing Calls to sc_initialize() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Converting sc_main() to a Module

If your design does not have sc_main() at the top level, in order for Questa SIM 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
Questa SIM 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 449.

Removing Calls to sc_initialize()

vsim calls sc_initialize() by default at the end of elaboration, so calls to sc_initialize() are
unnecessary.

448 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
Code Modification Examples

Code Modification Examples

You can modify sc_main in a number of ways, which are demonstrated in the examples in this
section.
Example 7-9. Converting sc_main to a Module

Table 7-8 shows a simple example of how to convert sc_main to a module that you can
elaborate with the vsim command.
Table 7-8. 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 7-10. Using sc_main and Signal Assignments

Table 7-9 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 Questa SIM.

Questa® SIM User's Manual, v2023.4 449

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 7-9. 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);

450 Questa® SIM User's Manual, v2023.4

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 7-11. Using an SCV Transaction Database

Table 7-10 shows a conversion that modifies a design using an SCV transaction database.
Questa SIM requires that you create the transaction database before calling the constructors on
the design subelements.
Table 7-10. Modifications Using SCV Transaction Database
Original OSCI code # 3 (partial) Modified Questa SIM 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

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

Questa® SIM User's Manual, v2023.4 451

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 Questa SIM is equivalent to sc_start(). In the SystemC simulator,
sc_start() runs the simulation for the duration of time specified by its argument. In
Questa SIM 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 Questa SIM.
• 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 Questa SIM'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 Questa SIM returns:

sc_main.top_i.b1

• With the IEEE 1666-2011 std, OSCI introduced a new sc_starvation_policy

SC_EXIT_ON_STARVATION. Questa SIM does not support the
SC_EXIT_ON_STARVATION_POLICY. Questa SIM 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. Questa SIM
does not issue this warning.

452 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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
Questa SIM 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 Questa SIM 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
Questa SIM 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.

Questa® SIM User's Manual, v2023.4 453

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

454 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 SystemC Simulation
OSCI 2.3.2 Feature Implementation Details

OSCI 2.3.2 Feature Implementation Details

The implementation details related to OSCI SystemC 2.3.2 release are provided in this section.
Support for OSCI TLM Library in SystemC-2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Features Not Supported in SystemC-2.3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Backwards Compatibility Issues with SystemC-2.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Support for OSCI TLM Library in SystemC-2.3.2

OSCI SystemC 2.3.2 release has an integrated TLM implementation (not distributed as a
separate release). If you are using TLM implementation not supplied with SystemC 2.3.2
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.2.
The various bind() functions for ports and exports are virtual as of IEEE 1666-2011 SystemC
LRM. This leads to an incompatibility with a TLM release than is older than 2.0.2 release. To
use SystemC 2.3.2 together with a TLM release older than the 2.0.2 release, define
SC_DISABLE_VIRTUAL_BIND during the build of the simulator and before including
systemc.h.

The simulator includes the header files and examples 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. You cannot debug TLM objects, 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.2

Several SystemC-2.3.2 features are not supported with the Questa SIM simulator.
• With the IEEE 1666-2011 standard OSCI introduced a new sc_starvation_policy.
SC_EXIT_ON_STARVATION. Questa SIM does not support the
SC_EXIT_ON_STARVATION sc_starvation_policy. Questa SIM 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. Questa SIM
will not issue this warning

Questa® SIM User's Manual, v2023.4 455

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

Experimental Features in 2.3.1

SystemC-2.3.1 introduced 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
Questa SIM. 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.2
Several backwards compatibility issues exist between SystemC 2.3.2 and SystemC 2.3.0.

New Features in 2.3.2

• Added new sc_time::from_string functions and the sc_time_tuple class:
With sc_time::from_string, it is now possible to create time objects from string
representations, such as configuration files:
sc_time( double v, const char* unit );
static sc_time from_string(const char* v);

To simplify the reverse direction, a new class sc_time_tuple is introduced, providing

separate access to the value and the unit of the time object:
class sc_time_tuple {
// ...
value_type value() const; // normalized value (wrt. unit)
sc_time_unit unit() const; // normalized unit
const char * unit_symbol() const;
};
sc_time tuple tt = sc_time(10000, SC_NS);
tt.value() == 10 tt.unit() == SC_US

• Added the common signal base class sc_signal_channel.

456 Questa® SIM User's Manual, v2023.4

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

The new base class for all signal channels reduces the code duplication in the template-
based signal implementations.
• Added support for SC_SIGNAL_WRITE_CHECK=CONFLICT.
Instead of disabling all runtime signal write checks via the environment setting
SC_SIGNAL_WRITE_CHECK=DISABLE, setting the variable to
SC_SIGNAL_WRITE_CHECK=CONFLICT allows detecting conflicting writes to a
signal within a single evaluation phase
• Promoted SC_DEFAULT_*_ACTIONS to enum constants.Previously, the
SC_DEFAULT_(INFO,WARNING,ERROR,FATAL)_ACTIONS were defined as
macros. In this release, they are moved into the actions enumeration as constants.
• Call report handler for exceptions caught outside of sc_main.
With two new functions added to the sc_report_handler:
static sc_actions get_catch_actions();
static sc_actions set_catch_actions(sc_actions);

and the new

SC_DEFAULT_CATCH_ACTIONS = SC_DISPLAY

it is now possible to externally influence the handling of exceptions caught outside of

sc_main.
• Improved conversion from bitvector element references to bool.
Elements of a sc_bv can now be used in an boolean context (requires C++11, refer to the
release notes for SystemC 2.3.2). This enables the following coding style:
sc_bv<8> mybits;
// ...
if( mybits[0] ) // no longer a compiler error here!
/* do something */ ;

For logic vectors, the bit-references still need to be converted to bool explicitly. For
example, via the to_bool() function.
• Support for scoped names in VCD trace files
In VCD trace files, traced variables are now automatically grouped in hierarchical
scopes (according to the period (.) separators in the trace names).

Incompatibilities Between 2.3.2 and 2.3.1

• The non-standard functions interface_count() and if_typename() in the sc_port_base
class have been marked as private.
• The non-standard macros WAIT, WAITN and WAIT_UNTIL have been renamed to
SC_WAIT, SC_WAITN, and SC_WAIT_UNTIL..

Questa® SIM User's Manual, v2023.4 457

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

• The non-standard macros SCAST, CCAST, and RCAST have been removed.
• The non-standard, 32-bit implementation of sc_(u)int has been removed.
• The include file sc_iostream.h has been removed. If the design uses stringstream
functions that needs header file “sstream”, you must pass the -
DSC_INCLUDE_EXTRA_STD_HEADERS argument to the sccom invocation.
• The never-notified event m_never_notified has been removed and replaced with
sc_event::none.
• A new class sc_type_index (with C++11 just a typedef to std::type_index) is introduced,
which helps writing RTTI-related code. This new type is used by two new inspection
functions added to sc_port_base, and sc_export_base, respectively (implemented in their
corresponding template classes) to query the RTTI information of the interface types:
virtual sc_type_index sc_port_base::get_interface_type() const =
0;virtual sc_type_index sc_export_base::get_interface_type() const
= 0;

• The VCD format supports tracing of time and event variables by default. Added new
overloads to sc_trace and a corresponding implementation for VCD:
void sc_trace( sc_trace_file* tf, const sc_time&, const std::string&
);
void sc_trace( sc_trace_file* tf, const sc_event&, const
std::string& );

Incompatibilities Between 2.3.1 and 2.3.0

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

458 Questa® SIM User's Manual, v2023.4

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 Questa SIM, you may encounter
several common errors. This section highlights some actions you can take to correct such errors.
Unexplained Behaviors During Loading or Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Errors During Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

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

Questa® SIM User's Manual, v2023.4 459

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

460 Questa® SIM User's Manual, v2023.4

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.2 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.2 installation. By default, sccom automatically picks
up the Questa SIM 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.

Questa® SIM User's Manual, v2023.4 461

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.

462 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 8
Mixed-Language Simulation

Questa SIM 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.
In addition, Questa SIM supports a procedural interface between SystemC and SystemVerilog,
so you may make calls between these languages at the procedural level.

Basic Mixed-Language Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Different Compilers with Common Design Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
The SystemVerilog bind Construct in Mixed-Language Designs . . . . . . . . . . . . . . . . . . 468
Optimizing Mixed Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Simulator Resolution Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Runtime Modeling Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Mapping Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
VHDL Instantiating Verilog or SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Verilog or SystemVerilog Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Sharing User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
SystemC Instantiating Verilog or SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Verilog or SystemVerilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
SystemC Instantiating VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
VHDL Instantiating SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
SystemC Procedural Interface to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Hierarchical References From Verilog/SystemVerilog to SystemC Objects . . . . . . . . . 563
Port Connections at the SV-VHDL Mixed Language Boundary . . . . . . . . . . . . . . . . . . 569

Basic Mixed-Language Flow

Simulating mixed-language designs with Questa SIM 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.

Questa® SIM User's Manual, v2023.4 463

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

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

464 Questa® SIM User's Manual, v2023.4

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. Questa SIM 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.
Questa SIM stores the resulting design units (modules and UDPs) in the working library.
• SystemC/C++ source code is compiled by using the sccom command. Questa SIM
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).

Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Hierarchical References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Access Limitations in Mixed-Language Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

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.

Questa® SIM User's Manual, v2023.4 465

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

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

466 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 467

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

Allowed Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Hierarchical References to a VHDL Object from a Verilog/SystemVerilog Scope. . . . 470
Mapping of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Optimization with SystemVerilog Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Port Mapping with VHDL and Verilog Enumerated Types . . . . . . . . . . . . . . . . . . . . . . 472
VHDL Instance Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Limitations to Bind Support for SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

468 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 469

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

470 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 the
SystemVerilog LRM.

Questa® SIM User's Manual, v2023.4 471

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. Questa SIM 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 8-1 shows the allowed VHDL types for port mapping to SystemVerilog port vectors.
Table 8-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 Questa SIM, 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).

472 Questa® SIM User's Manual, v2023.4

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 8-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 Questa SIM, you can bind any SystemVerilog functionality, such as

Questa® SIM User's Manual, v2023.4 473

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 Questa SIM:
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 8-2 shows how to use the bind statement in a SystemVerilog wrapper module to
connect a SystemVerilog cover directive to a VHDL component.

474 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 475

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. Questa SIM 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 or qverilog commands to compile and simulate the design,
Questa SIM 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 8-3 shows how to use vlog -cuname and -mfcu arguments to elaborate a bind
statement contained in its own file.

476 Questa® SIM User's Manual, v2023.4

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 8-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 Questa SIM 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.

Questa® SIM User's Manual, v2023.4 477

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 you compile the bind.sv file by itself, such as with vlog bind.sv, you will receive a Warning
like this one:

** Warning: (vlog-2650) 'bind' found in a compilation unit scope. Please

use -cuname to ensure that 'bind' gets 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

478 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 479

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Hierarchical References In Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . . 481
Signal Connections Between Mixed HDL and SystemC Designs . . . . . . . . . . . . . . . . . . 482

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

480 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 481

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

482 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 483

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
Questa SIM 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. Questa SIM 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 Questa SIM:

Verilog and SystemVerilog to VHDL Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

VHDL To Verilog and SystemVerilog Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Verilog or SystemVerilog and SystemC Signal Interaction And Mappings . . . . . . . . . 497
VHDL and SystemC Signal Interaction and Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Verilog and SystemVerilog to VHDL Mappings

Verilog or SystemVerilog instantiations of VHDL may associate Verilog nets and values with
VHDL ports and generics.
Table 8-2 shows the mapping of data types from SystemVerilog to VHDL.
Table 8-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

484 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 485

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 8-2. SystemVerilog-to-VHDL Data Type Mapping (cont.)

SystemVerilog Type VHDL Type Comments
Primary mapping Secondary mapping
struct record unpacked structure
Note: Mixed language
implementation
requires that these
datatypes originate from a
common package.
Datatypes cannot be
redefined.
packed struct record std_logic_vector packed structure
bit_vector
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 8-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.”

486 Questa® SIM User's Manual, v2023.4

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

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

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 Questa SIM:

<install_dir>/vhdl_src/verilog/vltypes.vhd

Verilog States
Verilog states are mapped to std_logic and bit as follows:
Table 8-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'

Questa® SIM User's Manual, v2023.4 487

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 8-4. Verilog States Mapped to std_logic and bit (cont.)

Verilog std_logic bit
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'
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 8-5 summarizes the mapping of data types from VHDL to SystemVerilog.

488 Questa® SIM User's Manual, v2023.4

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 8-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
integer int integer, shortint, longint, 2-state data type, 32-bit
int unsigned, shortint signed integer
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 8-6 shows the mapping of VHDL Generics to Verilog types.
Table 8-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.

Questa® SIM User's Manual, v2023.4 489

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

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.

VHDL type bit is mapped to Verilog states as shown in Table 8-12:

Table 8-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 8-8:

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

Supported Types
Table 8-9 shows SystemVerilog supported types.
Table 8-9. Supported Types in SystemVerilog
SystemVerilog Type VHDL Structure Comments
bit bit Bit types

490 Questa® SIM User's Manual, v2023.4

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 8-9. Supported Types in SystemVerilog (cont.)

SystemVerilog Type VHDL Structure Comments
enum enum SystemVerilog enums of
only 2-state int base type
supported
byte, int, shortint, longint integer Integer types
logic/reg std_logic/vlogic multi-valued types
Multi-D arrays Multi-D array multi-dimensional arrays of
supported types
real real 2-state data type, 64-bit real
number
shortreal real 2-state data type, 32-bit real
number
struct record Unpacked structure
packed struct record Packed structure
Table 8-10lists supported types in VHDL records.
Table 8-10. Supported Types in VHDL Record
VHDL Type SystemVerilog Type
bit, Boolean bit
bit_vector bit vector
integer, natural, positive int
multi-D arrays, array of arrays multi-D arrays
real real
record structure
std_logic logic
std_logic_vector, logic vector
std_ulogic_vector, signed, unsigned
std_ulogic logic

TableTable 8-11 lists mapping between VHDL and SystemVerilog Literals

Table 8-11. Mapping Literals from VHDL to SystemVerilog
VHDL SystemVerilog
‘0’ (Forcing 0) ‘0’
‘L’ (Weak 0) ‘0’

Questa® SIM User's Manual, v2023.4 491

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 8-11. Mapping Literals from VHDL to SystemVerilog (cont.)

VHDL SystemVerilog
‘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’
Note that the following conversion are not supported.

• Uninitialized constants in VHDL package

• Unconstrained vhdl arrays
• Records with unconstrained element(s)
• Constrained subtype of record of record type having constrained elements
• Constrained subtype of unconstrained record type, as element of another record type
The following are supported.

• Subtype of constrained record type

• Constrained subtype of unconstrained record type
• Subtype of record of record type having constrained elements
• Generic package instance

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.

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

492 Questa® SIM User's Manual, v2023.4

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

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.

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, Questa SIM gives preference to the primary type (type that
is inferred from the initial value of the parameter) over other types. Further, Questa SIM 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, Questa SIM 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 8-12. Mapping Table for Verilog-style Declarations

Type of Verilog Formal Type of VHDL Actual
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.

Questa® SIM User's Manual, v2023.4 493

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 SystemVerilog parameter is fixed. While Questa SIM overrides it through
VHDL, it will be an error if the type of the actual is not one of its equivalent VHDL types.
Table 8-13 provides a mapping table that lists equivalent types.

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
Questa SIM 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 8-13. 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)

494 Questa® SIM User's Manual, v2023.4

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 8-13. 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 8-13, Questa SIM 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.

Questa® SIM User's Manual, v2023.4 495

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. Questa SIM 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 Questa SIM 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. Questa SIM 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 Questa SIM converts Verilog modules into VHDL entity declarations
(_primary.vhd) and supports only those constructs that are currently handled by the VHDL
language.

496 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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, Questa SIM 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 8-13 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).

Questa® SIM User's Manual, v2023.4 497

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 8-14. 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 8-15 shows the correspondence of SystemC data types to SystemVerilog data types.

498 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 499

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 8-15. 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
struct,2 struct struct packed
union packed union N/A
sc_int<W> / sc_signed shortint (ifW=16) logic [W-1:0]
int (if W=32) wire [W-1:0]
longint (if W=64)
bit [W-1:0] (otherwise)
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)

500 Questa® SIM User's Manual, v2023.4

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 8-15. Data Type Mapping – SystemC to Verilog or SystemVerilog (cont.)

SystemC Type SystemVerilog Primary SystemVerilog Secondary
Mapping Mapping
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]3 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 arrays4 unpacked array5
1. Refer to enum, struct, and union at SystemC-SystemVerilog Mixed-Language Boundary for more
information on these complex types.
2. Supports real and shortreal as field types.
3. WL (word length) is the total number of bits used in the type. It is specified during runtime.
4. SystemC signal arrays are supported only for cases where Verilog or SystemVerilog instantiates a SystemC
module - not vice versa.
5. 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 8-16 shows the correspondence of Verilog or SystemVerilog data types to SystemC data
types.
Table 8-16. 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

Questa® SIM User's Manual, v2023.4 501

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 8-16. Data Type Mapping – Verilog or SystemVerilog to SystemC (cont.)

Verilog/ SystemC Primary SystemC Secondary
SystemVerilog Type Mapping Mapping
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>
longint long long sc_lv<64>
sc_int<64>
sc_bv<64>
long (for 64-bit)

502 Questa® SIM User's Manual, v2023.4

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 8-16. Data Type Mapping – Verilog or SystemVerilog to SystemC (cont.)

Verilog/ SystemC Primary SystemC Secondary
SystemVerilog Type Mapping Mapping
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.
• 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.

Questa® SIM User's Manual, v2023.4 503

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

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.

504 Questa® SIM User's Manual, v2023.4

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 8-17. 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 8-17. 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 8-18.
Table 8-18. 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

Questa® SIM User's Manual, v2023.4 505

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 8-18. 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 8-19:
Table 8-19. 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 8-20:

Table 8-20. 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 8-21:

Table 8-21. Mapping SystemC sc_logic to Verilog States
sc_logic Verilog
'0' St0

506 Questa® SIM User's Manual, v2023.4

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 8-21. 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 8-22 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 8-22. SystemC Port Type Mapping
Channels Ports VHDL mapping
sc_signal<T> sc_in<T> Depends on type T. See table
sc_out<T> entitled Data Type Mapping
Between SystemC and
sc_inout<T> 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

Questa® SIM User's Manual, v2023.4 507

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 8-22. 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 8-23 lists the mapping between SystemC sc_signal types and VHDL types.
Table 8-23. 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)

508 Questa® SIM User's Manual, v2023.4

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 8-23. 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)
sc_signed, bit_vector(WL-1 downto 0)
sc_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
record2 record
element_declaration
{element_declaration}
end record
[ record_type_simple_name ]
signal array3 type signal_name
array (constraint_definition) of
signal_type

Questa® SIM User's Manual, v2023.4 509

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 8-23. 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.
2. Including nested records.
3. 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.

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.

510 Questa® SIM User's Manual, v2023.4

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

• 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 8-24:
Table 8-24. 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>
buffer sc_out<T>,
sc_out_resolved,
sc_out_rv<W>

Note
VHDL constants are supported for port connections at a VHDL-SystemC boundary.

Questa® SIM User's Manual, v2023.4 511

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

VHDL to SystemC State Mapping

VHDL states are mapped to sc_logic, sc_bit, and bool as shown in Table 8-25:
Table 8-25. 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 8-26:
Table 8-26. 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 8-27:

Table 8-27. Mapping SystemC sc_bit to VHDL bit
sc_bit VHDL
'0' '0'
'1' '1'

SystemC type sc_logic is mapped to VHDL std_logic states as shown in Table 8-28:
Table 8-28. Mapping SystemC sc_logic to VHDL std_logic
sc_logic std_logic
'0' '0'
'1' '1'
'Z' 'Z'

512 Questa® SIM User's Manual, v2023.4

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 8-28. Mapping SystemC sc_logic to VHDL std_logic (cont.)

sc_logic std_logic
'X' 'X'

Questa® SIM User's Manual, v2023.4 513

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

Component Declaration for VHDL Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . 514
vgencomp Component Declaration when VHDL Instantiates Verilog. . . . . . . . . . . . . . 515
Modules with Bidirectional Pass Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Modules with Unnamed Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

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

514 Questa® SIM User's Manual, v2023.4

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, Questa SIM does nothing to the Verilog identifier when it
generates the entity.

Questa SIM 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, Questa SIM 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

Questa® SIM User's Manual, v2023.4 515

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.

516 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 517

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.

518 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Entity and Architecture Names and Escaped Identifiers. . . . . . . . . . . . . . . . . . . . . . . . . 520
Named Port Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Generic Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

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

Questa® SIM User's Manual, v2023.4 519

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

520 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 521

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Using a Common SystemVerilog Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

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

522 Questa® SIM User's Manual, v2023.4

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
• Unconstrained arrays.
• Subtypes of all supported types
• Alias of records, enums and arrays only
• Types (static ranges only)

Questa SIM supports VHDL constants of all types currently supported at the VHDL-
SystemVerilog mixed language boundary as shown in Table 8-5.

Deferred constants are not supported. Only static expressions are supported as constant values.

Table 8-29 shows the mapping of literals from VHDL to SystemVerilog.

Table 8-29. 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 8-30 lists all supported types inside VHDL Records.

Questa® SIM User's Manual, v2023.4 523

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 8-30. Supported Types Inside VHDL Records

VHDL Type SystemVerilog Type
bit, boolean bit
std_logic logic
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.

524 Questa® SIM User's Manual, v2023.4

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 8-31 lists all supported types inside SystemVerilog structures.

Table 8-31. Supported Types Inside SystemVerilog Structure
SystemVerilog Type VHDL Type Comments
bit bit bit types
logic, reg std_logic multi-valued types

Questa® SIM User's Manual, v2023.4 525

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

526 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 527

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
SystemC Foreign Module (Verilog) Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Parameter Support for SystemC Instantiating Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . 530

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 8-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. Questa SIM 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.

528 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 529

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

530 Questa® SIM User's Manual, v2023.4

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 8-6. Sample Foreign Module Declaration, with Constructor Arguments

for Parameters

Following Example 8-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 8-7. Passing Parameters as Constructor Arguments - 1

Verilog module:

module counter (clk, count)

Questa® SIM User's Manual, v2023.4 531

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]);
}
};

532 Questa® SIM User's Manual, v2023.4

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 8-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")
{}

Questa® SIM User's Manual, v2023.4 533

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

534 Questa® SIM User's Manual, v2023.4

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]);
}
};

Questa® SIM User's Manual, v2023.4 535

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Exporting SystemC Modules for Verilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Parameter Support for Verilog Instantiating SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . 536

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.

536 Questa® SIM User's Manual, v2023.4

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.

Questa SIM 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, Questa SIM 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 8-10. Verilog/SystemVerilog Instantiating SystemC, Parameter

Information

The following ring buffer example includes all the files necessary for simulation.

Questa® SIM User's Manual, v2023.4 537

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;

538 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 539

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
SystemC Foreign Module (VHDL) Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Generic Support for SystemC Instantiating VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

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.

540 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 541

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.

542 Questa® SIM User's Manual, v2023.4

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 8-12. SystemC Instantiating VHDL, Generic Information

Following Example 8-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 8-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()
{}
};

Questa® SIM User's Manual, v2023.4 543

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

544 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 545

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]);
}
};

546 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Component Declaration for VHDL Instantiating SystemC. . . . . . . . . . . . . . . . . . . . . . . 547
vgencomp Component Declaration when VHDL Instantiates SystemC . . . . . . . . . . . . 548
Exporting SystemC Modules for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Passing Generics From VHDL or Verilog Down to SystemC . . . . . . . . . . . . . . . . . . . . . 549

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

Questa® SIM User's Manual, v2023.4 547

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, Questa SIM
does nothing to the SystemC identifier when it generates the entity.

Questa SIM 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, Questa SIM 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.

548 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 549

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

550 Questa® SIM User's Manual, v2023.4

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() {}

};

Questa® SIM User's Manual, v2023.4 551

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

SystemC DPI Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
SystemC Import Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Calling SystemVerilog Export Tasks / Functions from SystemC . . . . . . . . . . . . . . . . . . 558
SystemC Data Type Support in SystemVerilog DPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
SystemC Function Prototype Header File (sc_dpiheader.h) . . . . . . . . . . . . . . . . . . . . . . 561
Support for Multiple SystemVerilog Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
SystemC DPI Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

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.

552 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 553

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 8-17. SystemVerilog Global Import Declaration

For the SystemC import function shown in Example 8-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 8-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 8-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) {

554 Questa® SIM User's Manual, v2023.4

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 1MByte. If this is not big enough for your
C++ functions you can change the default stack size with the sc_dpi_set_stack_size() interface.
You must use this interface right after the registration routine, for example:

SC_MODULE(top) {

void sc_task() {

Questa® SIM User's Manual, v2023.4 555

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

SC_CTOR(top) {
SC_DPI_REGISTER_CPP_MEMBER_FUNCTION("sc_task", &top::sc_task);
sc_dpi_set_stack_size(10000000); // set stack size to 10Mbytes.
}
}

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.

556 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 8-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

Questa® SIM User's Manual, v2023.4 557

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 8-32, are automatically imported
whenever the mti_scdpi package is imported.

558 Questa® SIM User's Manual, v2023.4

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 8-32. SystemC Types as Represented in SystemVerilog

SystemC Type SystemVerilog Typedef Import/Export 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 Questa SIM 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.

Questa® SIM User's Manual, v2023.4 559

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

560 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 561

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

562 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

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

Hierarchical References From Verilog/

SystemVerilog to SystemC Objects
Hierarchical references allow Verilog code to read/write signals from SystemC scope.
This feature supports the following objects

• Signals
• Shared variables
• Constants
• Generics not declared within processes
In SystemC these correspond to sc_signals and variables.

Questa® SIM User's Manual, v2023.4 563

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

SystemC signals are treated as Verilog wires. You can use hierarchical references to SystemC
signals in instances and left-hand side of continuous assignments, which can be read any place a
wire can be read and used in event control. SystemC variables can be read anywhere and written
in sequential blocks.

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.
• 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.
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).
• he 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 names of all elements of the union/struct must be the same.
• 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.
• The number and order of elements in the definition of structures on SystemVerilog and
SystemC side is the same.

564 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

• When assigning a struct literal to a systemc struct we need to use tick pattern "assign
inst.struct1 = '{...}"
SystemC Special Types
The following systemc channels and types are used to control the the SystemC model, they are
not exactly plain-datatypes. We will support reading them only in SV side.

• sc_fifo
• sc_mutex
• sc_semaphore
• sc_event

Supported Data Types

All the types supported at the SystemC-SystemVerilog mixed language boundary are supported
when binding to a SystemC target.
Table 8-33. Channel and Port Type Mapping
Channels Ports Verilog Mapping
sc_signal<T> sc_in<T> Depends on T. See
sc_out<T> following table.
sc_inout<T>
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

Table 8-34. Data Type Mapping - SystemC to Verilog or SystemVerilog

SystemC Type SystemVerilog SystemVerilog
Primay Mapping Secondary Mapping
bool bit logic
wire
char byte bit[7:0]
logic[7:0]
wire[7:0]
double real N/A

Questa® SIM User's Manual, v2023.4 565

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

Table 8-34. Data Type Mapping - SystemC to Verilog or SystemVerilog (cont.)

SystemC Type SystemVerilog SystemVerilog
Primay Mapping Secondary Mapping
enum enum integer
bit[31:0]
logic[31:0]
wire[31:0]
float shortreal N/A
int int
long longint (for 64-bit) bit[W-1:0]
int (for 32-bit) logic[W-1:0]
wire[W-1:0]
W=64 on 64-bit
W=32 on 32-bi
long long longint bit[63:0]
logic[63:0]
wire[63:0]
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_bit bit logic
wire
sc_bv bit[W-1:0] logic[W-1:0]
wire[W-1:0]
sc_fix_fast bit[WL-1:0] logic[W-1:0]
sc_ufix_fast 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, bit[W-1:0] logic[W-1:0]
O,N> wire[W-1:0]
sc_ufixed_fast<W,I,Q
,O,N>
sc_fixsc_ufix bit[WL-1:0] logic[W-1:0]
wire[W-1:0]

566 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

Table 8-34. Data Type Mapping - SystemC to Verilog or SystemVerilog (cont.)

SystemC Type SystemVerilog SystemVerilog
Primay Mapping Secondary Mapping
sc_int<W> / shortint (if W=16) logic [W-1:0]
sc_signed int (if W=32) wire [W-1:0]
longint (if W=64)
bit [W-1:0]
(otherwise)
sc_logic logic bit
wire
sc_lv logic[W-1:0] bit[W-1:0]
wire[W-1:0]
sc_uint<W> / shortint unsigned logic [W-1:0]
sc_unsigned (ifW=16) wire [W-1:0]
int unsigned (if
W=32)
longint unsigned (if
W=64)
bit [W-1:0]
(otherwise)
short shortint bit[15:0]
logic[15:0]
wire[15:0]
signal arrays unpacked array
struct struct struct packed
union packed union N/A
unsigned char byte unsigned bit[7:0]
logic[7:0]
wire[7:0]
unsigned int int unsigned
unsigned long longint unsigned (for bit[W-1:0]
64-bit) logic[W-1:0]
int unsigned (for 32- wire[W-1:0]
bit) W=64 on 64-bit
W=32 on 32-bit
unsigned long long longint unsigned bit[63:0]
logic[63:0]
wire[63:0]
unsigned short shortint unsigned bit[15:0]
logic[15:0]
wire[15:0]

Questa® SIM User's Manual, v2023.4 567

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Hierarchical References From Verilog/SystemVerilog to SystemC Objects

Table 8-35. Data Type Mapping Verilog or SystemVerilog to SystemC

Verilog/ SystemC Primary SystemC Secondary
SyustemVerilopg Type Mapping Mapping
bit bool sc_bit
sc_logic
bit vector sc_bv<W> sc_lv<W>
sc_int<W>
sc_uint<W>
byte char sc_lv<8>
sc_int<8>
sc_bv<8>
byte unsigned unsigned char sc_lv<8>
sc_uint<8>
sc_bv<8>
enum enum
int int sc_lv<32>
sc_int<32>
sc_bv<32>
integer sc_lv<32> int
sc_int<32>
integer unsigned sc_lv<32> unsigned int
sc_uint<32>
sc_bv<32>
logic sc_logic sc_bit
bool
logic vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>
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)
multi-D array multi-D array
packed struct struct
packed union union

568 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

Table 8-35. Data Type Mapping Verilog or SystemVerilog to SystemC (cont.)

Verilog/ SystemC Primary SystemC Secondary
SyustemVerilopg Type Mapping Mapping
real double
reg sc_logic sc_bit
bool
reg vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>
shortint short sc_lv<16>
sc_int<16>
sc_bv<16>
shortreal float
struct struct
wire sc_logic sc_bit
bool
wire vector sc_lv<W> sc_bv<W>
sc_int<W>
sc_uint<W>

Port Connections at the SV-VHDL Mixed

Language Boundary
Strict type checking during port connection at a SV-VHDL mixed language boundary can result
in runtime errors such as the following:

vsim Message # 3362:

The type of VHDL port is either not compatible with the type of Verilog
connection or is not currently supported at the VHDL-SystemVerilog mixed
language boundary.

Examples
The the argument affects the following types:

• Array
• Enumeration (non-predefined)
• Record

Questa® SIM User's Manual, v2023.4 569

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

Note that the -nostrictsvsh argument does not take any options nor returns any information.

Records
In the mixed language example below, a connection is attempted between a VHDL port of
record type(vh_record_t) and a Verilog structure type(vl_struct_t).

Command Line

Example 1 (SV top - VHDL bot):

vcom bot.vhd
vlog -sv top.sv
vsim -c top_verilog -do "run -a; q"

File
Contents

Connection attempt without the -nostrictsvvh argument fails with the following error:

# ** Fatal: (vsim-3362) The type of VHDL port 'vh_record' is invalid for

Verilog connection (1st connection).
# Time: 0 ns Iteration: 0 Instance: /top_verilog/bottom_vhdl_u File:
bot.vhd Line: 20
# FATAL ERROR while loading design
# Error loading design

570 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

The two types have different definitions across the language boundary, and therefore do not
match by default. There are two ways to achieve such a port connection:

1. Use the -mixedsvvh to convert the VHDL package to an equivalent SV package. Import
this converted package in Verilog module, and then use the exact same type required for
connection.
vcom bot.vhd -mixedsvvh
vlog -sv top.sv
vsim -c top_verilog -do "run -a; q"

2. Use the -nostrictsvvh argument to reduce the strictness of type checking between the
connected ports at the VHDL-SV boundary.
vcom bot.vhd
vlog -sv top.sv
vsim -c top_verilog -do "run -a; q" -nostrictsvvh

However, the following conditions should be met by record/structure types to match

across boundary using the -nostrictsvvh argument:
o Record should be fully constrained
o Both record/structure types should have same number of fields
o Corresponding field types should be compatible* (fields should match by position
and need not match by their names)
• Compatibility: a VHDL type of a record field and SV type of it's corresponding
structure field are compatible, if and only if they are compatible as independent
port types outside the record/structure.

Questa® SIM User's Manual, v2023.4 571

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

• Following table shows mixed language port types and their compatibility:
Table 8-36. Language Port Types and Their Compatibility
VHDL Port Type SV Port Type Compatibility
integer byte compatible
integer real not compatible
integer bit compatible
integer logic compatible
integer shortint compatible
integer int compatible
integer longint compatible
integer shortreal not compatible
integer time compatible
std_logic_vector(0 to 4) realtime not compatible
std_logic_vector(0 to 63) time compatible
std_logic_vector(0 to 63) realtime not compatible
std_logic_vector(0 to 64) time not compatible

If such types are corresponding member field types in a VHDL record and SV
structure, then their individual compatibility decides whether the record type and
structure type can match or not.
• If corresponding record/structure field types are -nostrictsvvh argument effected
types, then matching rules apply recursively with the -nostrictsvvh argument.
For example: Suppose corresponding fields of a record and structure type ports

572 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

are non-predefined enumeration types, then -nostrictsvvh rules for non-

predefined enumeration types is applied to match these types. See the following.

Enumeration (Non-predefined enum)

In mixed language scenario the connection between a non-predefined VHDL enum type
'vh_enum_t' and a Verilog enum type 'vl_enum_t' start with the following code example (SV
top - VHDL

Questa® SIM User's Manual, v2023.4 573

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

bot):

A connection attempt using the previous code without -nostrictsvvh argument fails with the
following error:

# ** Fatal: (vsim-3362) The type of VHDL port 'vh_enum' is invalid for

Verilog connection (1st connection).
# Time: 0 ns Iteration: 0 Instance: /top_verilog/bottom_vhdl_u File:
bot.vhd Line: 19
# FATAL ERROR while loading design

Consider the following code

example.

Compile the previous code example with the following.

574 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

vlog -sv bot.sv -mixedsvvh

vcom top.vhd
vsim -c top_vhdl -do "run -a; q"

Using the previous commands, a connection attempt without -nostrictsvvh fails with the
following error:

# ** Error: (vsim-3055) Type of connected VHDL signal is incompatible with

Verilog port 'vl_enum'.
# Time: 0 ns Iteration: 0 Instance: /top_vhdl/u1 File: bot.sv

This error appears when using -mixedsvvh and without -nostrictsvvh . If both switches are not
used the error is as follows:

** Error: bot.sv(7): (vcom-1593) Cannot load System Verilog package

"work.vl_pkg" because it was not compiled with the -mixedsvvh switch.
** Error (suppressible): bot.sv(7): (vcom-1195) Cannot find expanded name
"work.vl_pkg".
** Error: bot.sv(7): Unknown expanded name.
** Note: top.vhd(20): VHDL Compiler exiting

Using the -mixedsvvh switch, a VHDL package can be converted to an equivalent Verilog
package (imported in a Verilog module and original VH enum type be used for connection).
Alternatively, using the -nostrictsvvh argument, a VHDL enum type port can be connected to a
Verilog enum type port, if the given conditions are met:

• Number of fields(=n) in VHDL enum and SV enum should match.

• SV enum field value should start with 0 and increase by 1 from it's predecessor until n-1
(because VHDL enum cannot have values other than 0 to n-1)
Names need not match. The following table shows examples of the previous
rules.

Arrays
In mixed language scenario consider the connection between a VHDL array type 'vh_array_t'
and a System Verilog array type 'vl_array_t'. (SV top - VHDL

Questa® SIM User's Manual, v2023.4 575

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

bot):

Using the previous code example, without -nostrictsvvh argument, a connection attempt fails
with the following error:

# ** Fatal: (vsim-3362) The type of VHDL port 'vh_array' is invalid for

Verilog connection (1st connection).
# Time: 0 ns Iteration: 0 Instance: /top_verilog/bottom_vhdl_u File:
bot.vhd Line: 22
# FATAL ERROR while loading design

576 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

For another example 2 (VHDL top - SV bot) consider the following

code:

Using the previous code example, without the -nostrictsvvh argument, a connection attempt
fails with the following error:

# ** Error (suppressible): (vsim-3058) The width (32) of Verilog port

'vl_arr' does not match the array length (2) of its VHDL connection.
# Time: 0 ns Iteration: 0 Instance: /top_vhdl/u1 File: bot.sv
# Error loading design

Following sections show various case studies.

Case 1: SV top - VH bot

Consider the following array propertiers:

Nvh= = number of dimensions in VHDL array

NPSV = number of packed dimensions in SV array
NUSV = number of unpacked dimensions in SV array
NSV = number of dimensions in SV array = NPSV + NUSV

Following are the existing vsim rules (independent of -nostrictsvvh) to connect VHDL bot array
type port to SV top array type

Questa® SIM User's Manual, v2023.4 577

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

port:

The -nostrictsvvh argument affects only rule 3.c when NSV = NVH+1, The -nostrictsvvh
arguments allows splitting the last packed SV dimension further into factors of last dimension
width (thus allowing NSV to become > NVH +1).

The following table shows other

examples.

578 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

Questa® SIM User's Manual, v2023.4 579

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

The -nostrictsvvh arguemnt affects only those cases which already connect with rules 1, 2, 3 and
3.c in default behavior (without -nostrictsvvh). It allows splitting the last packed dimension and
increasing the number of SV dimensions beyond NVH+1 (and therefore relaxes rule 3).

Cases from the previous table which connect with 1, 2, 3 and 3.c by default, are given below
with -nostrictsvvh argument applied to split last packed
dimension.

Case 2: VH top - SV bot

Below are the existing vsim rules (independent of -nostrictsvvh) to connect VHDL top array
type port to SV bot array type port.

1. Total width of VHDL array should be equal to the total width of SV array
2. For a VHDL array of non vector type:
a. number dimensions in VHDL array should match the number of dimensions in SV
array (NVH = NSV)
b. connects only with unpacked SV arrays (exception: a 1-D VHDL array connects
with packed 1-D SV array also)
c. width of each dimension of VHDL array should match the width of it's
corresponding dimension in SV array
3. For a VHDL array of vector type:
a. number of unpacked dimensions of SV array should match the number of
dimensions of VHDL array (element vector is not counted as dimension here)
b. width of each unpacked dimension of SV array should match the width of it's
corresponding dimension of VHDL array (element vector is not counted as
dimension here)
c. there can be either 1 or 2 packed dimensions in SV array
d. total width of packed dimensions of SV array should match the width of the
VHDL array element vector

580 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

Following table shows examples.

The -nostrictsvvh argument relaxes the conditions under rule number 3 (only). Take any SV
array which obeys Rules 1 and 3. By applying -nostrictsvvh.

1. Packed dimensions can be split further into multiples of it's factors. That is, the product
of widths of split dimensions should match the width of original dimension.
2. If there is only one unpacked SV dimension, it can be converted a packed dimension, but
cannot be split further.

Questa® SIM User's Manual, v2023.4 581

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

The following shows connections enabled using the -nostrictsvvh

argument:

Derived case: Array of structure/record

Port of a VHDL array of record type and a SV array of structure type can be connected using the
-nostrictsvvh option. Conditions to connect Record-Structure type and array types mentioned
above should be satisfied to make this connection. Note the following example (SV top- VHDL

582 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

bot):

Without the without -nostrictsvvh argument, the previous example produces the following error
message:

# ** Fatal: (vsim-3362) The type of VHDL port 'vh_aor' is invalid for

Verilog connection (1st connection).
# Time: 0 ns Iteration: 0 Instance: /top_verilog/bottom_vhdl_u File:
bot.vhd Line: 21
# FATAL ERROR while loading design
# Error loading design

Questa® SIM User's Manual, v2023.4 583

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Mixed-Language Simulation
Port Connections at the SV-VHDL Mixed Language Boundary

The following code example has a VHDL top - SV bot

pairing.

Using the code from the previous example, it would produce the following error message
without the use of the-nostrictsvvh argument.

# ** Error: (vsim-3055) Type of connected VHDL signal is incompatible with

Verilog port 'vl_aos'.
# Time: 0 ns Iteration: 0 Instance: /top_vhdl/u1 File: bot.sv
# Error loading design
Error loading design

584 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 9
Advanced Simulation Techniques

Questa SIM allows you to use advanced simulation techniques to control and speed the
simulation process.
Checkpointing and Restoring Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Simulating with an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
X Propagation in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

Questa® SIM User's Manual, v2023.4 585

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 9-1. Checkpoint and Restore Commands

Action Definition Command used
checkpoint saves the simulation state checkpoint <filename>
“warm” restore restores a checkpoint file saved in a restore <filename>
current vsim session
“cold” restore restores a checkpoint file saved in a vsim -restore
previous invocation of vsim <filename>

Checkpoint File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586

Checkpoint Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Controlling Checkpoint File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
The Difference Between Checkpoint/Restore and Restart. . . . . . . . . . . . . . . . . . . . . . . . 587
Using Macros with Restart and Checkpoint/Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Checkpointing Foreign C Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Checkpointing a Running Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

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

Checkpoint Exclusions
There are a few items upon which checkpoint/restore does not work.

586 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Controlling Checkpoint File Compression

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

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

Questa® SIM User's Manual, v2023.4 587

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 Questa SIM; 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

This section describes how to deploy the checkpoint/restore flow to handle foreign C code that
works with heap memory (DPI/VPI/PLI/FLI).
Enable foreign C code checkpointing by specifying the -allowcheckpointcpp argument to vsim,
or by setting the value of the AllowCheckpointCpp modelsim.ini variable. You can select
between auto restore and manual restore options, or disable checkpointing support.

• The auto restore flow (vsim -allowcheckpointcpp 2) supports checkpointing without the
requirement for user code changes when checkpointing foreign code (FLI/PLI/VPI/DPI)
This option requires that you specify the -dir argument to the checkpoint command.
Compiling source files with Questa Auto compile using vlog or qrun works with the
auto restore flow, and so does manual compiling with GCC. However, you need to take
additional steps if you are linking with GCC, vsim_auto_compile.so, or working with a
pre-compiled shared library.
o GCC linking — The following example demonstrates the appropriate link option:
gcc -Wl,--wrap=malloc,--wrap=free,--wrap=calloc,--wrap=realloc,--wrap=strdup -
shared -o test.so test.o ...

o Linking with vsim_auto_compile.so — You can link .o object files directly into
vsim_auto_compile.so with the -ldflags argument to vsim as shown below:
vsim -ldflags “test.o” ...

o Precompiled Shared Libraries — Relink shared libraries with the --wrap option
when working with the auto restore flow.
• The manual restore flow (vsim -allowcheckpointcpp 1), is a legacy checkpointing flow
option that typically requires manual user code modifications in order to work with C
interfaces for DPI, VPI, PLI, or FLI, and heap memory allocation.

588 Questa® SIM User's Manual, v2023.4

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

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes. Refer to “Questa Dumping and Visibility” on page 85 for complete details.

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 Questa SIM 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"

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

Questa® SIM User's Manual, v2023.4 589

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

590 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 591

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 Questa SIM 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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

Creating an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Loading an Elaboration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Modifying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Using PLI or FLI Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

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:

• Compile your design — vcom or vlog

• Optimize your design — 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.
vopt -sdf<type> instance=<filename>

592 Questa® SIM User's Manual, v2023.4

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

• Create an elaboration file during the first simulation — 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).
vsim -elab <filename>

• Load the elaboration file for subsequent simulations — Load the elaboration file
along with any arguments that modify the stimulus (refer to Loading an Elaboration
File). You can include DPI import libraries in this step with the -sv_lib argument.
vsim -load_elab <filename> -sv_lib <shared_obj>

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

Questa® SIM User's Manual, v2023.4 593

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
-autoprofile
-c, -i, -batch, or -gui
-coverstore
-do <do_file>
-f
-filemap_elab <HDLfilename>=<NEWfilename>
-l <log_file>
-quiet
-stats
-suppress
-sv_lib <shared_obj>
-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.

The -sv_lib <shared_obj> argument can be used with -load_elab to include DPI shared import
libraries.

All other vsim arguments must be specified when you create the elaboration file, and they
cannot be used when you load the elaboration file.

If you attempt to use vsim SDF arguments (-sdfannotatepercentage, +sdf_verbose, or -

sdfreport) when generating an elaboration file, they will not be considered when the file is
loaded, and no warnings will be generated.

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

Modifying Stimulus
A primary use of elaboration files is to simulate the same design multiple times using a different
stimulus.

594 Questa® SIM User's Manual, v2023.4

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

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.

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

Questa® SIM User's Manual, v2023.4 595

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

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, -no_compress_elab,
-filemap_elab, and -load_elab.

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,
Questa SIM 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

596 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation in Simulation

X Propagation in Simulation
The simulator provides several commands to manage the propagation of X values that occur in
RTL simulation (for both Verilog and VHDL models). These commands enable you to modify
the simulation behavior so that it corresponds more closely to the silicon behavior.
The most significant difference between the RTL simulation and silicon behavior is the
pessimistic or optimistic handling of X values that occur in simulation. When considering X
values, recall that there is no actual X value in silicon. In simulation, X means the value may be
either logical 1 or 0, but the simulator cannot determine which one is correct at a given timestep.
Typically, an uninitialized register will power-up in ether the 0 or 1 state, but that value cannot
be predicted, so simulation generates an X to represent that state.

In certain cases, simulation makes RTL more pessimistic by recognizing an X; in other cases,
simulation makes RTL more optimistic by suppressing an X. The main advantage of managing
X propagation is to find hidden issues in the early stages of verification at the RTL level.

RTL X-Optimism Removal by xprop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

Controlling X Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
X Propagation Miscellaneous Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
X Propagation Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Limitations and Restrictions on xprop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

RTL X-Optimism Removal by xprop

When you use xprop functionality to remove X-optimism, the removal mainly affects a limited
set of Verilog or VHDL constructs used in the design.

X-Optimism and X-Pessimism in RTL

RTL simulation uses the value of X to temporarily represent a state that cannot be predicted or
determined at a given time. Because X values do not appear in the design once it has been
implemented in silicon, a mismatch can occur between simulation and silicon.

Example 1
if (en)
q = d1;
else
q = d2;

If the value of en becomes X, then the RTL semantic considers it false and implements the else
branch of the if statement. However, in actual hardware, either of the two branches can be
implemented. In some cases, this RTL X-optimism can hide potential bugs.

Questa® SIM User's Manual, v2023.4 597

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
RTL X-Optimism Removal by xprop

Example 2
assign out = (sel & a) || (!sel & b);

If sel becomes X, then the RTL semantic assigns X to out, irrespective of the values of a and b.
However, in actual hardware, if a and b are equal, then out should take the value of either a or b.
Because of this RTL X-pessimism, you can lose a great deal of time debugging the cause of a
pessimistic X, only to find that there is no actual design problem.

By default, the simulator identifies certain scenarios of X-propagation in the design, similar to
these examples, which can cause mismatches in RTL-to-silicon. The simulator then modifies
the X-propagation to make the simulation more silicon-compatible (that is, more X-pessimistic
or more X-optimistic).

Removing X-optimism for Verilog and VHDL is described below.

Verilog
Using xprop functionality to remove X-optimism affects the following types of Verilog
constructs:

• if-else
• case
• clocking trigger
Consider the following if-else construct:

if (en)
q = d1;
else
q =d2;

Here, the simulator checks for X values on existing if conditions and pessimistically drives all
the writers to X. This modification effectively acts as wrapping a conditional branching
statement with an immediate assertion that checks for X.

That is, xprop functionality treats this if-else construct as follows:

assert (!$isunknown(en)) begin

if (en) // normal branch
q = d1;
else
q = d2;
end
else // unknown branch
q = `x;

598 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Controlling X Propagation

VHDL
Using xprop functionality to remove X-optimism affects the following types of VHDL
constructs:

• process
• conditional signal assignment
• selected signal assignment
For the following VHDL process:

process(en)
begin
if(en = '1' ) then
out1 <= in1;
end if;
end

if en becomes X (or U), then the simulator applies xprop functionality for out1.

For the following VHDL conditional signal assignment:

out1 <= ‘1’ when (set = ‘0’) else ‘0’;

if sel becomes X or U, then the simulator applies xprop functionality on out1.

For the following VHDL selected signal assignment:

with s1 select
out1 <= ‘1’ when ‘0’ ,
‘0’ when others;

if s1 becomes X or U, then the simulator applies xprop functionality on out1.

Tip
You can use vopt -xprop_disable=stducheck to disable checking for U values and check
only for X values on conditions for std_logic.

Controlling X Propagation
Questa SIM provides several features to control the propagation of X values.
Use the following to control the propagation of X values during simulation:

• The xprop, -xprop_enable, and -xprop_disable Arguments of the vopt Command

• The xprop assertlimit, xprop enable, and xprop disable commands
• The xprop assertlimit Command and the XpropAssertionLimit Variable

Questa® SIM User's Manual, v2023.4 599

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Controlling X Propagation

• The Assertion Commands

• The xprop_off Attribute

Arguments of the vopt Command

Use the following arguments of the vopt command to control X propagation:

• -xprop
• -xprop_enable
• -xprop_disable
The options you specify as part of the -xprop argument apply to specific objects (modules or
instances) in the design. The options you specify as part of the -xprop_enable and
-xprop_disable arguments apply globally to all objects (modules or instances) in the design.

X propagation Resolution
Consider the following code:

always @(sel,a,b)
begin
if (sel)
q <= a;
else
q <= b;
end

Table 9-2. X propagation Resolution

sel a b Non X-Prop Trap Resolve Pass
(q) (q) (q) (q)
X 0 0 0 0 Resolve (a,b) = 0 X
X 0 1 1 1 Resolve (a,b) = X X
X 1 0 0 0 Resolve (a,b) = X X
X 1 1 1 1 Resolve (a,b) = 1 X

Precedence Order of -xprop Arguments

For X propagation simulation, the vopt command follows order of precedence rules, and the
last-specified -xprop argument takes precedence over any previous definitions.

600 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
Controlling X Propagation

For example:

• The following command disables xprop (mode=none) for the subchild instance, even
though the first -xprop argument enabled it (mode=resolve) due to recursion (use of the
dot (.) at the end of the object definition):
vopt -o t tb
-xprop,mode=resolve,object=/top/child.
-xprop,mode=none,object=/top/child/subchild

• The following command disables xprop for all instances of top/child/, and the second
-xprop explicitly enables xprop for only the subchild instance:
vopt –o t tb
-xprop,mode=none,object=/top/child.
-xprop,mode=resolve,object=/top/child/subchild

The xprop assertlimit Command and the XpropAssertionLimit Variable

Use the following to limit assertions in X propagation:

• The xprop assertlimit command — Use the command to set the fail count limit of X-
propagated assertions for a simulation session.
• The XpropAssertionLimit variable — Use the variable in the modelsim.ini file to set the
fail count limit of X-propagated assertions for all simulations.

Note
Do not mix the use of xprop enable and xprop disable commands with assertion enable -on/
-off commands. You should use one command family consistently.

The Assertion Commands

Use the following assertion commands to control assertions in X propagation:

• assertion action
• assertion active
• assertion count
• assertion enable
• assertion fail
• assertion pass
• assertion profile
• assertion report

Questa® SIM User's Manual, v2023.4 601

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Miscellaneous Features

The xprop_off Attribute

For finer control of X propagation, the simulator supports using the xprop_off attribute, which
you include as part of a VHDL architecture or a Verilog module. This attribute turns off
X-propagation for that architecture or module.

Note
The xprop_off attribute does not control index checks.

VHDL Architecture
Use the following syntax to insert the xprop_off attribute in a VHDL architecture:

architecture arch1 of entity1 is

SIGNAL g_valid : STD_LOGIC;
attribute xprop_off : string;
attribute xprop_off of arch1 : architecture is “TRUE” ;
begin -- arch1 begins
P_proc : process (in_clk)
begin --P_proc begins
…
end P_proc
end arch1

Verilog Module
Use the following syntax to insert the xprop_off attribute in a Verilog module:

(*xprop_off = "TRUE"*)
module module_name
……
endmodule

X Propagation Miscellaneous Features

The simulator supports error detection and reporting related to X propagation.

Error Messages for X Propagation

The simulator detects error conditions for X propagation according to the type of model in the
design (such as finite state machines, latches, clocks). The following error message categories
are listed in order of importance.

602 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Miscellaneous Features

Finite State Machine

If the current state variable (cst) of an FSM becomes X, the simulator issues an error message.
For example, if the value of cst is an X:

always @(posedge clk or posedge rst or posedge cnd)

if (rst) cst <= s0;
else if (cnd) cst <= 3'hx;
else cst <= nst;

always @(cst or inp or enb)

case (cst)
s0: begin out = inp[4]; if (enb) nst = s1; end
s1: begin out = inp[5]; if (enb) nst = s2; end
s2: begin out = inp[6]; if (enb) nst = s3; end
s3: begin out = inp[7]; if (enb) nst = s0; end
endcase

The simulator displays the following error message:

# ** Error: XPROP_FSM_27: 'cst' goes X.

# Time: 0 ns Scope: tb.top_vl File: ./src/vl_fsm_case/top.v Line: 27

Flip-Flop, Asynchronous Control

If any asynchronous control input signal (non-clocked) to a flip-flop becomes X, the simulator
issues an error message. For example, if the following reset (rst) or set value is an X:

always @(posedge clk, posedge rst,posedge set)

begin
if(rst)
q <= 1'b0;
else if (set)
q <= 1'b1;
else
q <= d;
end

The simulator displays the following error message:

# ** Error: XPROP_FF_75: 'rst' goes X.

# Time: 66 ns Scope: tb File: ./src/vl_limit_messages1/tb.v Line: 75

Latch
If the value of the enable signal in an always block of a latch becomes X, the simulator issues an
error message. For example, if the following value of en is an X:

always @(en)
begin
if(en)
out <= in1;
end

Questa® SIM User's Manual, v2023.4 603

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Miscellaneous Features

The simulator displays the following error message:

# ** Error: XPROP_LAT_12: 'a' goes X.

# Time: 4 ns Scope: tb.top_vl File: ./src/vl_if_delay/top.v Line: 12

Flip-Flop, Clock
If the synchronous control input signal (clock) to a flip-flop becomes X, the simulator issues an
error message. For example, if the following clock value (clk) is an X:

always @(posedge clk, posedge rst,posedge set)

begin
if(rst)
q <= 1'b0;
else if (set)
1 <= 1'b1;
else
q <= d;
end

The simulator displays the following error message:

# ** Error: XPROP_CLK_73: 'clk' goes X.

# Time: 14 ns Scope: tb File: ./src/vl_limit_messages1/tb.v Line: 73

Miscellaneous Combinatorial Logic

If variables in a condition or case statement become X, the simulator issues an error message.
For example, if values of en1 and en2 in the following if statement becomes X:

always@(*)
if(en1 && en2)
out = a;
else
out = b;

The simulator displays the following error message:

# ** Error: XPROP_COMB_8: 'en1 and en2' goes X.

# Time: 14 ns Scope: tb File: ./src/vl_limit_messages1/tb.v Line: 8

Error Messages for Out-of-Bounds Indexes

Use the xprop enable command to detect out-of-bounds indexes for array expressions. This
command implements assertions to find WRITE and READ operations that are out of bounds,
as shown in the following examples.

WRITE Example
out[index] = in /*index value is out of bound array indices*/

Assertion Message:

** Error: XPROP_OUT_OF_BOUNDS_WRITE_25: 'out[index]' goes out of bounds.

604 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Miscellaneous Features

READ Example
out = in[index] /*index value is out of bound array indices*/

Assertion Message:

** Error: XPROP_OUT_OF_BOUNDS_READ_25: 'in[index]' goes out of bounds.

Error Messages for Array Indexes

The following options to the vopt -xprop command provide different methods of applying
propagation control of X values in WRITE and READ operations on an array index:

• Pass mode — vopt -xprop, mode=pass

• Resolve mode — vopt -xprop, mode=resolve
Pass mode
If you specify pass mode of X propagation control, the simulator implements assertions for
WRITE and READ operations that produce X values on array indexes. For example:

assign B = A[i]; //index i is 'x'

Assertion message:

# ** Error: XPROP_X_INDEX_READ_17: 'A[i]' array index goes X.

# ** Error: XPROP_X_INDEX_WRITE_33: 'XW[i2]' array index goes X

Resolve mode
If you specify resolve mode of X propagation control, the simulator enables a more fine-grain
evaluation of X values in WRITE and READ operations on an array index (resulting in more
accurate error reporting). The simulator checks for every bit of the array, and if they are same
then no error is reported—even if index becomes X.

Consider the same example as given above for pass mode:

assign B = A[i]; //index i is 'x'

where all A[i] are the same. In this case, no error is reported since both simulation and silicon
behavior would be the same (that is, an XPROP_X_INDEX_READ error would be noise in the
report).

Limited X-Propagation Checking on Arrays Only

To enable X-propagation checking only on out-of-bounds arrays and array indexes, specify the
following argument for vopt:

vopt -xprop_enable=indexcheck

The simulator applies no other xprop functionality to the design.

Questa® SIM User's Manual, v2023.4 605

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Examples

Error Messages for Out-of-Range Indexes in VHDL Designs

If you use the xprop enable command, you may receive fatal out-of-range index errors for
VHDL designs. The following example shows a VHDL index and process that can cause this
condition, along with the resulting error message.

Example
As shown below, if the value of en becomes X, then the simulator applies the largest -ve value
on 'index' to signify X propagation. In turn, this would cause the out of range fatal error
(vsim-3421). These errors usually happens at time 0, just as the design is initializing and hence
many signals are still at the X or Z state.

signal index : integer range 0 to 23...process(en)

begin
if(en) then
index <= 0;
end if;
end

A[index] <= 5;

# ** Fatal: (vsim-3421) Value -2147483648 is out of range 0 to 23.

# Time: 0 ps Iteration: 0 Process: …/u_rs422/u_rs422_rx/comb File: …/
users/mdang_ae/mdang_verification/src/rs422_rx.vhd

Solution
From the command line, turn off xprop during time 0, then restore it after time 0, as follows:

vsim>xprop disable
vsim>run 0
vsim>xprop enable
vsim>run -all

X Propagation Examples
Examples of X propagation can be divided into two categories; RTL x-optimism examples and
RTL x-pessimism examples.
You can find additional examples within the install directory at:

<install_dir>/examples/xprop/

RTL X-Optimism Examples

Example 9-1. If-else Statements

if (en)
q = d1;
else
q = d2;

606 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Examples

Table 9-3 describes the resolve and pass output for 'q' for various values of inputs
Table 9-3. If-else - Outputs with pass and resolve xprop Settings
en d1 d2 pass resolve RTL Silicon
Simulation
x 0 0 x 0 0 0
x 1 0 x x 0 ?
x 0 1 x x 1 ?
x 1 1 x 1 1 1

Example 9-2. Latch

always_latch
if (reset) q <= 0;
else if (set) q <= 1;
| else if (en) q <= d;

Table 9-4. Latch - Outputs with pass and resolve xprop Settings
reset set en d q(t-1) pass resolve RTL Sim Silicon
x x x 0 0 x 0 0 0
x x x 0 1 x x 0 ?
x x x 1 0 x x 1 ?
x x x 1 1 x 1 1 1

RTL X-Pessimism Examples

Example 9-3. Array-index Pessimism

Reg [1:0]arr;
q = arr[idx];

If 'idx' goes x, then RTL simulation assigns 'x' value to q irrespective of values stored in
different bits of the vector 'arr'. However in silicon, if all the bits of 'arr' are same then q takes a
valid value.
Table 9-5. Array-Index - Outputs with resolve xprop Setting
idx arr[0] arr[1] resolve RTL Silicon
Simulation
x 0 0 0 x 0
x 0 1 x x ?
x 1 0 x x ?
x 1 1 1 x 1

Questa® SIM User's Manual, v2023.4 607

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Examples

Example 9-4. Assign mux X-Pessimism

assign out = (sel & a) || (!sel & b);

.
Table 9-6. assign mux - Outputs with pass and resolve xprop Setting
sel a b pass resolve RTL-sim Silicon
x 1 1 x 1 x 1
x 1 0 x x x ?
x 0 1 x x x ?
x 0 0 x 0 x 0

Example 9-5. Case Statements

case (en)
1'b1: q = d1;
1'b0: q = d2;

Table 9-7 describes the resolve and pass output for 'q' for various values of inputs.
Table 9-7. Case Statements - Outputs with pass and resolve xprop Settings
en d1 d2 pass resolve RTL Silicon
Simulation
x 0 0 x 0 x 0
x 1 0 x x x ?
x 0 1 x x x ?
x 1 1 x 1 x 1

The following Verilog test produces the resulting truth tables for a flip-flop RTL in
xprop,mode=resolve:

Example 9-6. Flip-Flop

module top (input clk, reset, set, d, output logic q);

always @(posedge clk or posedge reset or posedge set) begin
if (reset)
q <= 0;
else if(set)
q <= 1;
else
q <= d;
end
endmodule

Edges on clock.

608 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Examples

clk rst set D Q

0->1 0->0 0->0 0 0->0
0->1 0->0 0->0 0 1->0
0->1 0->0 0->0 1 0->1
0->1 0->0 0->0 1 1->1

0->x 0->0 0->0 0 0->0

0->x 0->0 0->0 0 1->x
0->x 0->0 0->0 1 0->x
0->x 0->0 0->0 1 1->1

0->z 0->0 0->0 0 0->0

0->z 0->0 0->0 0 1->x
0->z 0->0 0->0 1 0->x
0->z 0->0 0->0 1 1->1

1->0 0->0 0->0 0 0->0

1->0 0->0 0->0 0 1->1
1->0 0->0 0->0 1 0->0
1->0 0->0 0->0 1 1->1

1->x 0->0 0->0 0 0->0

1->x 0->0 0->0 0 1->1
1->x 0->0 0->0 1 0->0
1->x 0->0 0->0 1 1->1

1->z 0->0 0->0 0 0->0

1->z 0->0 0->0 0 1->1
1->z 0->0 0->0 1 0->0
1->z 0->0 0->0 1 1->1

x->0 0->0 0->0 0 0->0

x->0 0->0 0->0 0 1->1
x->0 0->0 0->0 1 0->0
x->0 0->0 0->0 1 1->1

x->1 0->0 0->0 0 0->0

x->1 0->0 0->0 0 1->0
x->1 0->0 0->0 1 0->1
x->1 0->0 0->0 1 1->1

x->z 0->0 0->0 0 0->0

x->z 0->0 0->0 0 1->1
x->z 0->0 0->0 1 0->0
x->z 0->0 0->0 1 1->1

z->0 0->0 0->0 0 0->0

z->0 0->0 0->0 0 1->1
z->0 0->0 0->0 1 0->0
z->0 0->0 0->0 1 1->1

z->1 0->0 0->0 0 0->0

z->1 0->0 0->0 0 1->0
z->1 0->0 0->0 1 0->1
z->1 0->0 0->0 1 1->1

z->x 0->0 0->0 0 0->0

z->x 0->0 0->0 0 1->1

Questa® SIM User's Manual, v2023.4 609

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Examples

z->x 0->0 0->0 1 0->0

z->x 0->0 0->0 1 1->1

Edges on reset

610 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Examples

clk rst set D Q

0->0 0->1 0->0 0 0->0
0->0 0->1 0->0 0 1->0
0->0 0->1 0->0 1 0->0
0->0 0->1 0->0 1 1->0

0->0 0->x 0->0 0 0->0

0->0 0->x 0->0 0 1->x
0->0 0->x 0->0 1 0->1
0->0 0->x 0->0 1 1->x

0->0 0->z 0->0 0 0->0

0->0 0->z 0->0 0 1->x
0->0 0->z 0->0 1 0->1
0->0 0->z 0->0 1 1->x

0->0 1->0 0->0 0 0->0

0->0 1->0 0->0 0 1->1
0->0 1->0 0->0 1 0->0
0->0 1->0 0->0 1 1->1

0->0 1->x 0->0 0 0->0

0->0 1->x 0->0 0 1->1
0->0 1->x 0->0 1 0->0
0->0 1->x 0->0 1 1->1

0->0 1->z 0->0 0 0->0

0->0 1->z 0->0 0 1->1
0->0 1->z 0->0 1 0->0
0->0 1->z 0->0 1 1->1

0->0 x->0 0->0 0 0->0

0->0 x->0 0->0 0 1->1
0->0 x->0 0->0 1 0->0
0->0 x->0 0->0 1 1->1

0->0 x->1 0->0 0 0->0

0->0 x->1 0->0 0 1->0
0->0 x->1 0->0 1 0->0
0->0 x->1 0->0 1 1->0

0->0 x->z 0->0 0 0->0

0->0 x->z 0->0 0 1->1
0->0 x->z 0->0 1 0->0
0->0 x->z 0->0 1 1->1

0->0 z->0 0->0 0 0->0

0->0 z->0 0->0 0 1->1
0->0 z->0 0->0 1 0->0
0->0 z->0 0->0 1 1->1

0->0 z->1 0->0 0 0->0

0->0 z->1 0->0 0 1->0
0->0 z->1 0->0 1 0->0
0->0 z->1 0->0 1 1->0

0->0 z->x 0->0 0 0->0

0->0 z->x 0->0 0 1->1

Questa® SIM User's Manual, v2023.4 611

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
X Propagation Examples

0->0 z->x 0->0 1 0->0

0->0 z->x 0->0 1 1->1

Edges on set

612 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Advanced Simulation Techniques
X Propagation Examples

clk rst set D Q

0->0 0->0 0->1 0 0->1
0->0 0->0 0->1 0 1->1
0->0 0->0 0->1 1 0->1
0->0 0->0 0->1 1 1->1

0->0 0->0 0->x 0 0->x

0->0 0->0 0->x 0 1->0
0->0 0->0 0->x 1 0->x
0->0 0->0 0->x 1 1->1

0->0 0->0 0->z 0 0->x

0->0 0->0 0->z 0 1->0
0->0 0->0 0->z 1 0->x
0->0 0->0 0->z 1 1->1
0->0 0->0 1->0 0 0->0
0->0 0->0 1->0 0 1->1
0->0 0->0 1->0 1 0->0
0->0 0->0 1->0 1 1->1

0->0 0->0 1->x 0 0->0

0->0 0->0 1->x 0 1->1
0->0 0->0 1->x 1 0->0
0->0 0->0 1->x 1 1->1
0->0 0->0 1->z 0 0->0
0->0 0->0 1->z 0 1->1
0->0 0->0 1->z 1 0->0
0->0 0->0 1->z 1 1->1

0->0 0->0 x->0 0 0->0

0->0 0->0 x->0 0 1->1
0->0 0->0 x->0 1 0->0
0->0 0->0 x->0 1 1->1

0->0 0->0 x->1 0 0->1

0->0 0->0 x->1 0 1->1
0->0 0->0 x->1 1 0->1
0->0 0->0 x->1 1 1->1

0->0 0->0 x->z 0 0->0

0->0 0->0 x->z 0 1->1
0->0 0->0 x->z 1 0->0
0->0 0->0 x->z 1 1->1

0->0 0->0 z->0 0 0->0

0->0 0->0 z->0 0 1->1
0->0 0->0 z->0 1 0->0
0->0 0->0 z->0 1 1->1

0->0 0->0 z->1 0 0->1

0->0 0->0 z->1 0 1->1
0->0 0->0 z->1 1 0->1
0->0 0->0 z->1 1 1->1

0->0 0->0 z->x 0 0->0

0->0 0->0 z->x 0 1->1
0->0 0->0 z->x 1 0->0
0->0 0->0 z->x 1 1->1

Questa® SIM User's Manual, v2023.4 613

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Advanced Simulation Techniques
Limitations and Restrictions on xprop

Limitations and Restrictions on xprop

The goal of the simulator is to support X propagation management for synthesizable constructs
of SystemVerilog and VHDL, but there are certain limitations and restrictions.
Multi-core simulation is disabled when vopt -xprop is applied. If you use the -xprop vopt
argument in this case, the simulator issues an error and exits:

Verilog
The simulator disables X propagation when an X literal is present in an if or case conditions.
For example:

If Condition
if (data_en == 2’b0x)
i = 4;
else if (data_en == 2’b01)
i = 6;
else
i = 8;

Case Condition
case (sel)
2'b0x : q = a;
2'b01 : q = b;
default : q = c;
endcase

VHDL
The simulator does not support X propagation management in resolve mode.

614 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 10
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Viewing Transactions in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Debugging Transactions with Tcl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Transactions in Designs with Questa Verification IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Transaction Recording Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Transaction Recording Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Transaction Recording Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
CLI Debugging Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Verilog and VHDL API System Task Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Questa® SIM User's Manual, v2023.4 615

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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
About the Source Code for Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
About Transaction Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

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 Questa SIM, 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 Questa SIM 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.

616 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 10-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 10-1 shows a Wave window view of a number of transactions. (See Viewing
Transactions in the GUI for procedural details.)

Questa® SIM User's Manual, v2023.4 617

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

618 Questa® SIM User's Manual, v2023.4

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 Questa SIM. 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 10-1.

Related Topics
Viewing Transactions in the GUI
Selecting Transactions or Streams in the Wave Window

Questa® SIM User's Manual, v2023.4 619

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Transaction Objects in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Viewing Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Retroactive Recording and Transaction Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Selecting Transactions or Streams in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . 626
Customizing Transaction Appearance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Viewing a Transaction in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Viewing a Transaction in the Objects Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

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 10-2 shows several streams, one of which has eight sub-streams.

620 Questa® SIM User's Manual, v2023.4

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 10-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 Questa SIM. 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".

Questa® SIM User's Manual, v2023.4 621

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.

622 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 623

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 10-4. Concurrent Parallel Transactions

Figure 10-5 shows a simple transaction stream that includes simple, user-defined address and
data attributes.
Figure 10-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 10-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.

624 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 625

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.
Procedure
Use any of these methods to select transaction information in the wave window.

• Use the mouse to select transaction information

o Left-click the mouse to select an individual transaction and any substreams of
that transaction.
o Left-click with the Shift key to select multiple transactions and their substreams.
• Use a pop-up menu to select related transactions
o Right-click to display a pop-up menu with the following choices:
• Select Related — To select a transaction to which the current transaction is
pointing.
• Select Relating — To select a transaction that is pointing to the current trans-
action.
• Select Chain — To select all related and relating transactions for the current
transaction. Use this to select an entire causal chain.
• 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

626 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Customizing Appearance of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

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 10-6).

Questa® SIM User's Manual, v2023.4 627

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

628 Questa® SIM User's Manual, v2023.4

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 10-7).
Figure 10-7. Transaction-Stream Properties Dialog Box

Questa® SIM User's Manual, v2023.4 629

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

630 Questa® SIM User's Manual, v2023.4

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

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 10-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
Viewing Transactions in the Wave Window
Transaction Objects in the Structure Window

Viewing a Transaction in the Objects Window

Use the Objects window to view transactions— but not transaction streams.

Questa® SIM User's Manual, v2023.4 631

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Debugging Transactions with Tcl

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 10-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.
The syntax for specifying a full path (using the Verilog path delimiter) to an attribute is:

<stream>.<substream>[<substream...].<attribute>

632 Questa® SIM User's Manual, v2023.4

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

Procedure
1. Set the names of streams created using TCL. For example:
set streamName “top.stream1”

Questa SIM 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
Questa SIM.
The basic steps for recording transactions are summarized in Figure 10-10.

Questa® SIM User's Manual, v2023.4 633

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 10-10. Recording Transactions

The SystemC tasks and Verilog API calls used in these steps are listed in Table 10-1.

634 Questa® SIM User's Manual, v2023.4

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 10-1. System Tasks and API for Recording Transactions

Action SystemC - Verilog/VHDL -
System Task Used Questa SIM 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 — Required for scv_tr_stream() N/A
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 — Required for See SCV documentation N/A
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 transactions ::add_relation() add_relation

— Optional. or
See Specify a relationship between begin_transaction
transactions by providing:

Questa® SIM User's Manual, v2023.4 635

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 10-1. System Tasks and API for Recording Transactions (cont.)
Action SystemC - Verilog/VHDL -
System Task Used Questa SIM 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 times end_transaction
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.

636 Questa® SIM User's Manual, v2023.4

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.

These guidelines give you an overview of how to record transactions for viewing in
Questa SIM:

Names of Streams and Substreams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

Stream Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Transaction UIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Attribute Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Multiple Uses of the Same Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Anonymous Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Relationship in Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
The Life Cycle of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Transaction Handles and Memory Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

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.

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.

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

Questa® SIM User's Manual, v2023.4 637

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

transaction stream placement may not be where you expect it. In these cases, use full or partial
path specifications.

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.

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

638 Questa® SIM User's Manual, v2023.4

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

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
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

Attribute Type
On any single transaction stream, Questa SIM associates an attribute name with a data type.

Questa® SIM User's Manual, v2023.4 639

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Recording and Viewing Transactions
Multiple Uses of the Same Attribute

Tip
In most cases, Questa SIM 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, Questa SIM 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
Attribute Type
Anonymous Attributes
Relationship in Transactions
The Life Cycle of a Transaction
Transaction Handles and Memory Leaks

640 Questa® SIM User's Manual, v2023.4

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

Anonymous Attributes
Questa SIM 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
Transaction Handles and Memory Leaks

Relationship in Transactions
In Questa SIM, 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

Questa® SIM User's Manual, v2023.4 641

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

assign to the relationship is arbitrary: choose a name that is meaningful. Questa SIM interprets
no meaning from the pointer.

When Questa SIM 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.
• 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.

642 Questa® SIM User's Manual, v2023.4

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

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

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.

Questa® SIM User's Manual, v2023.4 643

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

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

644 Questa® SIM User's Manual, v2023.4

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

Verilog Recorded Transaction Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Valid Verilog Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Recording Transactions in SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Initializing SCV and Creating WLF Database Object. . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Transaction Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Recording SCV Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
SCV API Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
SCV Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Recording Transactions in Verilog and VHDL

Because there is currently no standard for transaction recording in Verilog or VHDL,
Questa SIM 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.

Questa® SIM User's Manual, v2023.4 645

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
Questa SIM. 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 Names of Streams and
Substreams 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

646 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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>). Questa SIM 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");

Questa® SIM User's Manual, v2023.4 647

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

648 Questa® SIM User's Manual, v2023.4

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 Questa SIM, 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.

Questa® SIM User's Manual, v2023.4 649

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.

650 Questa® SIM User's Manual, v2023.4

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
Questa SIM 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 SCV Limitations. If your design
includes user-defined types — such as classes, structures, or enumerations — you must provide

Questa® SIM User's Manual, v2023.4 651

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

SCV extensions so that SCV and the Questa SIM 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**")
{
}
}

652 Questa® SIM User's Manual, v2023.4

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. Questa SIM 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", Questa SIM 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", Questa SIM 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", Questa SIM 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,

Questa® SIM User's Manual, v2023.4 653

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 Questa SIM,
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

654 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 Questa SIM. If recorded, they appear as transactions
within their parent transaction. The SCV specification does not describe this kind of
transaction, but Questa SIM 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.

Questa® SIM User's Manual, v2023.4 655

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

656 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 */
}
};

Questa® SIM User's Manual, v2023.4 657

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
There are a couple limitations to SystemC and transaction recording.
• 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 Questa SIM for viewing
and debugging.
• Type Support for SystemC
The following types are not supported for SystemC transactions:
o bit-field and T* (pointer) native C/C++ types
o 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.

658 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 659

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.
Questa SIM supports the following API system tasks in Verilog and VHDL:

add_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
add_color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
add_relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
begin_transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
create_transaction_stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
delete_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
end_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
free_transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

660 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 661

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

662 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 663

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.

664 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 665

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.

666 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 667

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

668 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 669

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

670 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 11
Verifying Designs with
Questa Verification IP Library Components

This chapter provides a brief introduction to Questa Verification IP transactions in Questa SIM,
and discusses additional features of the Questa SIM GUI available when simulating a model
that includes Questa Verification IP(s).

What is Questa Verification IP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671

What is a Questa Verification IP Transaction? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Questa Verification IP Transaction Viewing in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . 674
Questa Verification IP Transaction Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

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.
Tip
: Transactions in a Questa Verification IP are quite distinct from SystemC or SystemVerilog
transactions in the Questa SIM tool. In this chapter, any occurrence of the word
“transaction” refers to Questa Verification IP transactions exclusively, unless otherwise
specified.

Questa® SIM User's Manual, v2023.4 671

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?

To illustrate, consider a hypothetical Questa Verification IP transaction shown in Figure 11-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 11-1. Questa Verification IP Transaction at Different Levels of

Abstraction

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

672 Questa® SIM User's Manual, v2023.4

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?

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

Questa® SIM User's Manual, v2023.4 673

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.
• Objects window - visible when you select an instance of the interface in Questa
Verification IP in the Structure (sim) window.
• List window - must be logged during a simulation run.
Questa Verification IP Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Arrays in Questa Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Viewing Questa Verification IP Transactions in the Wave Window . . . . . . . . . . . . . . . 677
What the Colors Mean in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Appearance of Concurrent Transactions in the Wave Window . . . . . . . . . . . . . . . . . . . 680
Questa Verification IP Arrays in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Color and Questa Verification IP Arrays in Wave Window . . . . . . . . . . . . . . . . . . . . . . 682
Viewing Questa Verification IP Transactions in Objects Window . . . . . . . . . . . . . . . . . 682
Viewing Questa Verification IP Transactions in List Window . . . . . . . . . . . . . . . . . . . . 684

Questa Verification IP Objects in the GUI

The display of Questa Verification IP transactions in Questa SIM 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 11-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 11-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.

Questa Verification IP objects can be viewed in the Wave window, where they are drawn as
transaction streams or signals. Table 11-1 includes a description of the various objects and how
they appear.

674 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 675

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

676 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 /*

Questa® SIM User's Manual, v2023.4 677

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 11-3. For information on the colors of transactions, see “What the Colors Mean in the
Wave Window”.

678 Questa® SIM User's Manual, v2023.4

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 11-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 11-2. These colors are used as the fill
color for a transaction, or to highlight a signal.
Table 11-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).

Questa® SIM User's Manual, v2023.4 679

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

680 Questa® SIM User's Manual, v2023.4

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 11-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 11-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 11-5. Questa Verification IP Array (2X2) in Wave Window

Questa® SIM User's Manual, v2023.4 681

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

682 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 11-7.
Figure 11-7. Questa Verification IP Objects in Objects Window

Questa® SIM User's Manual, v2023.4 683

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 Questa SIM 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 11-8.
Figure 11-8. Questa Verification IP Objects in List Window

684 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 685

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.
Debugging Using Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Questa Verification IP Transaction Details in Transaction View Window . . . . . . . . . . 689
Updating Contents of the Transaction Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

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.

686 Questa® SIM User's Manual, v2023.4

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 11-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 Questa SIM.

Questa® SIM User's Manual, v2023.4 687

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
What the Colors Mean in the Wave Window

688 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
The Transaction Stream Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Questa® SIM User's Manual, v2023.4 689

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

Figure 11-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 Questa SIM simulator).
• Main State — Identifies how the transaction instance came into existence.
• Sub State — Identifies the phase of life the instance has reached.

690 Questa® SIM User's Manual, v2023.4

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
The Transaction Stream Window

Questa® SIM User's Manual, v2023.4 691

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

692 Questa® SIM User's Manual, v2023.4

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

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 11-11 shows details for instance /high_level_unit/dan/xtor/t_top_A2B, and lists the
relations of that instance.
Figure 11-11. Transaction Window - Relations Tab

Related Topics
Viewing Transactions in the Wave Window

Questa® SIM User's Manual, v2023.4 693

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

Questa Verification IP Objects in the GUI

694 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 12
Recording Simulation Results With Datasets

This chapter describes how to save the results of a Questa SIM simulation and use them in your
simulation flow. In general, any recorded simulation data that has been loaded into Questa SIM
is called a dataset.
One common example of a dataset is a wave log format (WLF) file. In particular, you can save
any Questa SIM 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 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.

Questa® SIM User's Manual, v2023.4 695

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 12-1. Displaying Two Datasets in the Wave Window

The simulator resolution 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Dataset Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Managing Multiple Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Collapsing Time and Delta Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Virtual Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710

696 Questa® SIM User's Manual, v2023.4

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 disable the creation of a WLF file with the vsim +questa_mvc_core+wlf_disable
command.

You can also log variables and values to a WLF file with the$wlfdumvars() Verilog system
task.

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.

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
Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Saving Memories to the WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
WLF File Parameter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Limiting the WLF File Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Opening Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702

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.
Procedure
1. Log objects of interest with the log command.

Questa® SIM User's Manual, v2023.4 697

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

2. Select the Wave window to make it active.

3. Select Tools > Dataset Snapshot to open the Dataset Snapshot dialog box
(Figure 12-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.
Figure 12-2. Dataset Snapshot Dialog Box

698 Questa® SIM User's Manual, v2023.4

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

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

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 12-1. WLF File Parameters
Feature modelsim.ini modelsim.ini vsim argument
Default
WLF Cache Size WLFCacheSize = <n> 0 (no reader cache)
WLF Collapse Mode WLFCollapseModel = 0|1|2 1 (-wlfcollapsedelta) -nowlfcollapse -
wlfcollapsedelta -
wlfcollapsetime
WLF Compression WLFCompress = 0|1 1 (-wlfcompress) -wlfcompress -
nowlfcompress
WLF Delete on Quit WLFDeleteOnQuit = 0|1 0 (-wlfdeleteonquit) -wlfdeleteonquit -
nowlfdeleteonquit

Questa® SIM User's Manual, v2023.4 699

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 12-1. WLF File Parameters (cont.)

Feature modelsim.ini modelsim.ini vsim argument
Default
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>
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.

700 Questa® SIM User's Manual, v2023.4

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 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.
• 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.
Limit the WLF file size with the WLFSizeLimit simulation control variable in the modelsim.ini
file or with the -wlfslim switch for the vsim command. Either method specifies the number of
megabytes for WLF file recording.

A WLF file contains event, header, and symbol portions. The size restriction is placed on the
event portion only. When Questa SIM exits, the entire header and symbol portion of the WLF
file is written. Consequently, the resulting file will be larger than the size specified with -
wlfslim. If used in conjunction with -wlftlim, the more restrictive of the limits takes precedence.

The WLF file can be limited by time with the WLFTimeLimit simulation control variable in the
modelsim.ini file or with the -wlftlim switch for the vsim command. Either method specifies the
duration of simulation time for WLF file recording. The duration specified should be an integer
of simulation time at the current resolution; however, you can specify a different resolution if
you place curly braces around the specification. For example,

vsim -wlftlim {5000 ns}

sets the duration at 5000 nanoseconds regardless of the current simulator resolution.

The time range begins at the current simulation time and moves back in simulation time for the
specified duration. In the example above, the last 5000ns of the current simulation is written to
the WLF file.

If used in conjunction with -wlfslim, the more restrictive of the limits will take effect.

The -wlfslim and -wlftlim switches were designed to help users limit WLF file sizes for long or
heavily logged simulations. When small values are used for these switches, the values may be
overridden by the internal granularity limits of the WLF file format. The WLF file saves data in

Questa® SIM User's Manual, v2023.4 701

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

a record-like format. The start of the record (checkpoint) contains the values and is followed by
transition data. This continues until the next checkpoint is written. When the WLF file is limited
with the -wlfslim and -wlftlim switches, only whole records are truncated. So if, for example,
you are were logging only a couple of signals and the amount of data is so small there is only
one record in the WLF file, the record cannot be truncated; and the data for the entire run is
saved in the WLF file.

Multithreading on Linux Platforms

Multithreading enables the logging of information on a secondary processor while the
simulation and other tasks are performed on the primary processor. Multithreading is on by
default on multi-core or multi-processor Linux platforms.

If you are running a simulation on a Windows system or a single-core or -processor Linux

system this functionality, of course, is not enabled.

You can disable this functionality with the vsim -nowlfopt switch, which you may want to do if
you are performing several simulations with logging at the same time.You can also control this
behavior with the WLFUseThreads variable in the modelsim.ini file.

Opening Datasets
Questa SIM 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 12-3).

702 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 703

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

Structure Window Columns

Structural information about datasets is presented in the Structure window.
Table 12-2 lists the columns displayed in each Structure window, by default.
Table 12-2. Structure Tab Columns
Column name Description
Instance the name of the instance
Design unit the name of the design unit

704 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 705

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

Questa SIM allows you to manage multiple datasets using menu selections from the graphic
interface or from the command line.
Managing Multiple Datasets in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Managing Multiple Datasets from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Restricting the Dataset Prefix Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

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

706 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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,
Questa SIM 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. Questa SIM 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.

Questa® SIM User's Manual, v2023.4 707

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 Questa SIM 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 Questa SIM 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 12-3. vsim Arguments for Collapsing Time and Delta Steps
vsim argument effect modelsim.ini setting
-nowlfcollapse All events for each logged signal are recorded WLFCollapseMode = 0
to the WLF file in the exact order they occur
in the simulation.

708 Questa® SIM User's Manual, v2023.4

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 12-3. vsim Arguments for Collapsing Time and Delta Steps (cont.)
vsim argument effect modelsim.ini setting
-wlfcollapsedelta Each logged signal which has events during a WLFCollapseMode = 1
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.

Questa® SIM User's Manual, v2023.4 709

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
Questa SIM simulation kernel.
Virtual objects are indicated by an orange diamond as illustrated by Bus1 in Figure 12-6:

Figure 12-6. Virtual Objects Indicated by Orange Diamond

Virtual Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710

Virtual Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Virtual Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Virtual Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

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

710 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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 Questa SIM 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

Questa® SIM User's Manual, v2023.4 711

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

712 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 13
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Objects You Can View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Adding Objects to the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Inserting Signals in a Specific Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Working with Cursors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Adding Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Editing Cursor Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Expanded Time in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Expanded Time Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . 729
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . 731
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Expanding and Collapsing Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Zooming the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Zooming with the Menu, Toolbar and Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Saving Zoom Range and Scroll Position with Bookmarks. . . . . . . . . . . . . . . . . . . . . . . . . 738
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Searching in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Searching for Values or Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Filtering the Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Formatting the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Setting Wave Window Display Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Questa® SIM User's Manual, v2023.4 713

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

Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Wave Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Creating a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Deleting or Ungrouping a Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Adding Items to an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Removing Items from an Existing Wave Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Composite Signals or Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Creating Composite Signals through Menu Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Saving the Window Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Exporting Waveforms from the Wave window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Exporting the Wave Window as a Bitmap Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Saving Waveform Sections for Later Viewing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Viewing SystemVerilog Class Objects and Class Path Expressions . . . . . . . . . . . . . . . . 769
Viewing System Verilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Combining Objects into Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Extracting a Bus Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Using the Virtual Signal Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Miscellaneous Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Examining Waveform Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Creating and Managing Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Waveform Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Mixed-Language Waveform Compare Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Setting Up a Comparison with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Adding Signals, Regions, and Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800

714 Questa® SIM User's Manual, v2023.4

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

Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Viewing Differences in Textual Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Saving and Reloading Comparison Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Comparing Hierarchical and Flattened Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

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

Questa® SIM User's Manual, v2023.4 715

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

716 Questa® SIM User's Manual, v2023.4

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

A Window Format Select File > Load and specify a previously saved format file.
File

Questa® SIM User's Manual, v2023.4 717

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

718 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 13-2 summarizes common cursor actions you can perform with the icons in the toolbox,
or with menu selections.
Table 13-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 Tools > Window
<-> full names Preferences > Display Tab Preferences > Display Tab
Edit grid and Wave > Wave Preferences Tools > Window
timeline properties > Grid and Timeline Tab Preferences > 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 only Debug Toolbar Tab only.
Cursors
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.

Questa® SIM User's Manual, v2023.4 719

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 13-3).

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

720 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Editing Cursor Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Jump to a Signal Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Measuring Time with Cursors in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Syncing All Active Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Linking Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Understanding Cursor Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Shortcuts for Working with Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Two Cursor Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

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)

Questa® SIM User's Manual, v2023.4 721

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

Measuring Time with Cursors in the Wave Window

Questa SIM 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 13-4).

Figure 13-4. Original Names of Wave Window 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.

722 Questa® SIM User's Manual, v2023.4

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

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 13-5).
Figure 13-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 13-6, and selecting Cursor Linking > Link All.

Questa® SIM User's Manual, v2023.4 723

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 13-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 13-7).
Figure 13-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

724 Questa® SIM User's Manual, v2023.4

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

window MDI frame. 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.

Questa® SIM User's Manual, v2023.4 725

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Additional Mouse Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

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

726 Questa® SIM User's Manual, v2023.4

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 Questa SIM, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727

Recording Expanded Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Viewing Expanded Time Information in the Wave Window . . . . . . . . . . . . . . . . . . . . . 729
Customizing the Expanded Time Wave Window Display . . . . . . . . . . . . . . . . . . . . . . . . 731
Expanded Time Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Switching Between Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Expanding and Collapsing Simulation Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Expanded Time with examine and Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

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

Questa® SIM User's Manual, v2023.4 727

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

728 Questa® SIM User's Manual, v2023.4

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 13-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 13-8. Waveform Pane with Collapsed Event and Delta Time

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

Questa® SIM User's Manual, v2023.4 729

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 13-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 13-9, had not been added to
the Wave window, the result would be as shown in Figure 13-10.

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

730 Questa® SIM User's Manual, v2023.4

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

Figure 13-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 13-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 Questa SIM. 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.

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.

Questa® SIM User's Manual, v2023.4 731

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

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.

732 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Toolbar Selections for Expanded Time Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Command Selection of Expanded Time Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Menu Selections for Expanded Time Display Modes

The following table shows the menu selections for initiating expanded time display modes.

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

Questa® SIM User's Manual, v2023.4 733

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.

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.

734 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 735

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.

736 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Saving Zoom Range and Scroll Position with Bookmarks . . . . . . . . . . . . . . . . . . . . . . . 738
Editing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

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

Questa® SIM User's Manual, v2023.4 737

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.

738 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Editing Bookmarks

Figure 13-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 13-7. Actions for Bookmarks

Action Menu commands Menu commands Command
(Wave window (Wave window
docked) undocked)
Add bookmark Add > To Add > Bookmark bookmark add wave
Wave > Bookmark
View bookmark Wave > Bookmarks > View > Bookmarks > bookmark goto wave
<bookmark_name> <bookmark_name>
Delete bookmark Wave > Bookmarks > View > Bookmarks > B bookmark delete wave
Bookmarks > <select ookmarks > <select
bookmark bookmark
then > Delete 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.

Questa® SIM User's Manual, v2023.4 739

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

Search with the Expression Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

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.

740 Questa® SIM User's Manual, v2023.4

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 13-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 Questa SIM.

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.

Questa® SIM User's Manual, v2023.4 741

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 . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Saving an Expression to a Tcl Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Searching for a Particular Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Evaluating Only on Clock Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744

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 13-14
Figure 13-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.

742 Questa® SIM User's Manual, v2023.4

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 13-15.
Figure 13-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.)

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.

Questa® SIM User's Manual, v2023.4 743

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

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

744 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 745

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Formatting Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Dividing the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Splitting Wave Window Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755

746 Questa® SIM User's Manual, v2023.4

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 13-16).

Figure 13-16. Display Tab of the Wave Window Preferences Dialog Box

Hiding/Showing Path Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Double-Click Behavior in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Setting the Timeline to Count Clock Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748

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.

Questa® SIM User's Manual, v2023.4 747

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

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.
If the Wave window is undocked, select Tools > Window Preferences from the Wave
window menus. This opens the Wave Window Preferences dialog box.

748 Questa® SIM User's Manual, v2023.4

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

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 13-17).
Figure 13-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 13-18.

Questa® SIM User's Manual, v2023.4 749

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 13-18. Clock Cycles in Timeline of Wave Window

750 Questa® SIM User's Manual, v2023.4

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 13-19).

Figure 13-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 13-20).

Figure 13-20. Format Tab of Wave Properties Dialog

Changing Radix (base) for the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752

Questa® SIM User's Manual, v2023.4 751

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 13-21).

Figure 13-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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

752 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 753

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

754 Questa® SIM User's Manual, v2023.4

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 13-24. Splitting Wave Window Panes

Questa® SIM User's Manual, v2023.4 755

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Deleting or Ungrouping a Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Adding Items to an Existing Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Removing Items from an Existing Wave Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Miscellaneous Wave Group Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761

756 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Adding a Group of Contributing Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Grouping Signals with the add wave Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Grouping Signals with a Keyboard Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

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 13-25), with the name specified in the dialog box.

Questa® SIM User's Manual, v2023.4 757

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 13-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 13-26).

758 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 759

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.

760 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 761

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

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.

762 Questa® SIM User's Manual, v2023.4

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.

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 13-27), where you can save waveform formats in a .do file.
Figure 13-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>

• Select File > Load.

Note
Window format files are design-specific. Use them only with the design you
were simulating when they were created.

Questa® SIM User's Manual, v2023.4 763

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

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.

764 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window to a Postscript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Printing the Wave Window on the Windows Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Saving Waveform Sections for Later Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

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.
• SignalSelection — Allows you to select which signals are exported
• TimeRange — 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.

Questa® SIM User's Manual, v2023.4 765

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.

766 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Viewing Saved Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Working With Multiple Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Saving Waveforms Between Two Cursors

You can save a waveform section between two cursors.
Procedure
1. Place the first cursor (Cursor 1 in Figure 13-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 13-28. Waveform Save Between Cursors

Questa® SIM User's Manual, v2023.4 767

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 13-29)
Figure 13-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 13-30)

768 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 769

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 13-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 13-32).

770 Questa® SIM User's Manual, v2023.4

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 13-32. Class Information Popup in the Wave Window

Questa® SIM User's Manual, v2023.4 771

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.

Working with Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

772 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 773

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 13-33. Virtual Interface Objects Added to Wave Window

774 Questa® SIM User's Manual, v2023.4

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 13-34. Signals Combined to Create Virtual Bus

Extracting a Bus Slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

Wave Extract/Pad Bus Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Splitting a Bus into Several Smaller Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777

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.

Questa® SIM User's Manual, v2023.4 775

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 13-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 13-35) are as follows:

• Source — The name of the bus from which you selected the signals.

776 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 777

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 13-36)

Figure 13-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 13-37).

778 Questa® SIM User's Manual, v2023.4

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 13-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.
• The Test button tests the syntax of your virtual signal.
Creating a Virtual Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779

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.

Questa® SIM User's Manual, v2023.4 779

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 13-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 13-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 13-39)

780 Questa® SIM User's Manual, v2023.4

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 13-39. Virtual Signal in the Wave Window

Related Topics
Virtual Objects

Questa® SIM User's Manual, v2023.4 781

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Displaying Drivers of the Selected Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Sorting a Group of Objects in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783

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.

782 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 783

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

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

Breakpoints within SystemC portions of the design can only be set using File-Line Breakpoints.

Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785

File-Line Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Saving and Restoring Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790

784 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Setting Signal Breakpoints with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Modifying Signal Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785

Setting Signal Breakpoints with the when Command

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

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.

Modifying Signal Breakpoints

You can easily modify the signal breakpoints you have created.

Questa® SIM User's Manual, v2023.4 785

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Waveform Analysis
Signal Breakpoints

Procedure
1. Select Tools > Breakpoints from the Main menus.
2. This will open the Modify Breakpoints dialog (Figure 13-40), which displays a list of all
breakpoints in the design.
Figure 13-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 13-41) opens, allowing you to modify the breakpoint.

786 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Waveform Analysis
Signal Breakpoints

Figure 13-41. Signal Breakpoint Dialog

Questa® SIM User's Manual, v2023.4 787

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
You set file-line breakpoints on executable lines in your source files.
When the simulator encounters a line with a breakpoint, it 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. Once invoked, C Debug can be exited
using the C Debug menu.

Setting File-Line Breakpoints Using the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . 788

Setting File-Line Breakpoints Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Modifying a File-Line Breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789

Setting File-Line Breakpoints Using the bp Command

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

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 13-42).

788 Questa® SIM User's Manual, v2023.4

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

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 13-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 13-43) opens, allowing you to modify the breakpoint.

Questa® SIM User's Manual, v2023.4 789

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

790 Questa® SIM User's Manual, v2023.4

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

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Three Options for Setting up a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Setting Up a Comparison with the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Starting a Waveform Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Adding Signals, Regions, and Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Specifying the Comparison Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Setting Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Viewing Differences in the Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Viewing Differences in the List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Viewing Differences in Textual Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Saving and Reloading Comparison Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Comparing Hierarchical and Flattened Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

Mixed-Language Waveform Compare Support

Mixed-language compares are supported as listed in the following table:

Table 13-8. Mixed-Language Waveform Compares

Language Compares
C/C++ types bool, char, unsigned char,
short, unsigned short,int,
unsigned int, long, unsigned
long

Questa® SIM User's Manual, v2023.4 791

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

792 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Comparison Graphic Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Comparison Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794

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 13-44. Waveform Comparison Wizard

Questa® SIM User's Manual, v2023.4 793

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 Questa SIM to
compare the reference gold.wlf dataset against the current simulation. The compare add /*
command instructs Questa SIM 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.

794 Questa® SIM User's Manual, v2023.4

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 13-45. Start Comparison Dialog

Reference Dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795

Test Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795

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, Questa SIM adds a Compare tab to the
Main window.

Questa® SIM User's Manual, v2023.4 795

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

796 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Adding Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Adding Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

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

Questa® SIM User's Manual, v2023.4 797

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 13-48. Add Comparison by Region Dialog

Adding Clocks
You add clocks when you want to perform a clocked comparison.

798 Questa® SIM User's Manual, v2023.4

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 13-49. Comparison Methods Tab

Continuous Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

Clocked Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800

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.

Questa® SIM User's Manual, v2023.4 799

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

800 Questa® SIM User's Manual, v2023.4

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 13-51. Waveform Comparison Options

Questa® SIM User's Manual, v2023.4 801

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

802 Questa® SIM User's Manual, v2023.4

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

Compare Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

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.

Questa® SIM User's Manual, v2023.4 803

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

804 Questa® SIM User's Manual, v2023.4

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 13-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 Questa SIM’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.

Questa® SIM User's Manual, v2023.4 805

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.

806 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 14
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 14-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.

Questa® SIM User's Manual, v2023.4 807

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

Live Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Two Schematic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Features of the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Common Tasks for Schematic Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Adding Objects to the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Display a Structural Overview in the Full View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Exploring the Schematic Connectivity of the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . 823
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . 833
Finding Objects by Name in the Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Annotating with Sticky Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Automatically Tracing All Paths Between Two Nets in the Schematic Window . . . . . . . 837
Symbol Mapping in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Schematic Window Graphic Interface FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
What Can I View in the Schematic Window? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 843
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
How do I Configure Schematic Window Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

808 Questa® SIM User's Manual, v2023.4

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

Post Simulation Schematic Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810

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.
5. Log simulation data.

Questa® SIM User's Manual, v2023.4 809

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

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 Questa SIM by doing either of the following:
• (Linux) Type vsim in a Linux shell, at the prompt.
• (Windows) Double-click a Questa SIM icon.
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 command:
vsim -view <db_pathname.wlf>

810 Questa® SIM User's Manual, v2023.4

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

Questa SIM opens the .wlf dataset and its associated debug database (.dbg file with the
same basename), if it can be found. If Questa SIM cannot find db_pathname.dbg, it will
attempt to open vsim.dbg.

Questa® SIM User's Manual, v2023.4 811

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 14-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 14-2). You
can toggle back and forth between views by simply clicking this “View” indicator.

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

812 Questa® SIM User's Manual, v2023.4

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 14-3).

Figure 14-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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813

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 14-4).
Solid blue boxes with dashed white borders denote folded instances (see Folding and
Unfolding Instances in the Incremental View).

Questa® SIM User's Manual, v2023.4 813

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 14-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 14-5). By default, all displayed signal values are for the current active time, as
displayed in the Current Time label.
Figure 14-5. Show Incremental View Annotation

814 Questa® SIM User's Manual, v2023.4

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 14-6.
Figure 14-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 14-7).
Figure 14-7. Code Preview Window

The Code Preview window includes a four-button toolbar that provides the options shown in
Table 14-1

Questa® SIM User's Manual, v2023.4 815

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

816 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Display a Structural Overview in the Full View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Exploring the Schematic Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Folding and Unfolding Instances in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . 823
Using Abstract Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Exploring Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Tracing Events in the Incremental View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Tracing the Schematic Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . 833
Finding Objects by Name in the Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Saving and Restoring the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Annotating with Sticky Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Displaying Power Aware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Automatically Tracing All Paths Between Two Nets in the Schematic Window. . . . . . 837

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.

Questa® SIM User's Manual, v2023.4 817

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 14-8).
Figure 14-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.

818 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Limiting the Schematic Display of Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Controlling the Schematic Display of Redundant Buffers and Inverters. . . . . . . . . . . . 821
Tracking Your Path Through the Design with Highlighting. . . . . . . . . . . . . . . . . . . . . . 822

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 14-9).
Figure 14-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 14-10).

Questa® SIM User's Manual, v2023.4 819

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 14-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 14-2; or, right-click the selected item and make the menu
selection described in the second column of Table 14-2.

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

820 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 821

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 14-12).

Figure 14-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 14-13).
Figure 14-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

822 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 823

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 14-15).
Figure 14-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 14-16).
Figure 14-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.

824 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 825

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 14-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 14-18).

826 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 827

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 14-19).

Figure 14-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 14-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.)

828 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 829

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 14-22, signal q of the fifo module ff3 is selected and a cursor is placed on the
transition at 670 ns.
Figure 14-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 14-23).

830 Questa® SIM User's Manual, v2023.4

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 14-23. Show Drivers Control Bar Buttons

In Figure 14-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 14-24).
Figure 14-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 14-25). Click an
item in the list to return to a previous operation.

Questa® SIM User's Manual, v2023.4 831

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 14-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 14-26).
Figure 14-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 14-27. Click Schematic Window Button to View Path Details

This will open a Schematic window with the title Schematic (Path Details). In Figure 14-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

832 Questa® SIM User's Manual, v2023.4

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 14-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 14-29) and in the Wave
Viewer pane of the Schematic window.

Questa® SIM User's Manual, v2023.4 833

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 14-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 14-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 14-30), then
select Show ‘X’ Cause (ChaseX).

834 Questa® SIM User's Manual, v2023.4

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 14-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 14-31).
Figure 14-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.

Questa® SIM User's Manual, v2023.4 835

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

836 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 837

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 14-33:
• All objects become gray
• The source net becomes yellow
• The destination net becomes red
• All intermediate processes and nets become orange.
Figure 14-33. Schematic: Point-to-Point Tracing

Examples
• Change the limit of highlighted processes — There is a limit of 400 processes that will
be highlighted.

838 Questa® SIM User's Manual, v2023.4

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"

Questa® SIM User's Manual, v2023.4 839

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

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"

840 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 841

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

842 Questa® SIM User's Manual, v2023.4

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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
How is the Schematic Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . 843
How Can I Print and Save the Schematic Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
How do I Configure Schematic Window Options?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
How do I Zoom and Pan the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
How do I Use Keyboard Shortcuts? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

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 14-3. Refer to the GUI Reference
Manual for further information on these windows.
Table 14-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

Questa® SIM User's Manual, v2023.4 843

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 14-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 14-34).

Figure 14-34. The Print Postscript Dialog

844 Questa® SIM User's Manual, v2023.4

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 14-35). You can also open this dialog box by clicking the Setup button in the
Print Postscript dialog box (Figure 14-34). This dialog box allows you to configure page view,
highlight, color mode, orientation, and paper options.

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

Questa® SIM User's Manual, v2023.4 845

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

846 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 847

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

848 Questa® SIM User's Manual, v2023.4

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 14-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 14-38. Keyboard Shortcut Table in the Schematic Window

Toggle the list closed by pressing the ‘?’ key again or simply click the list.

Questa® SIM User's Manual, v2023.4 849

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?

850 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Dataflow Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Common Tasks for Dataflow Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Dataflow Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Dataflow Window Graphic Interface Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876

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.

Questa® SIM User's Manual, v2023.4 851

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 15-1. The Dataflow Window

852 Questa® SIM User's Manual, v2023.4

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

Post-Simulation Debug Flow Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855

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 15-2 illustrates the current and post-sim usage flows for Dataflow debugging.

Questa® SIM User's Manual, v2023.4 853

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 15-2. Dataflow Debugging Usage Flow

854 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Use the Post-Simulation Debug Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856

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, Questa SIM
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 Questa SIM to save all signal values generated
when the simulation is run.
4. Run the simulation.
5. Quit the simulation.

Questa® SIM User's Manual, v2023.4 855

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. Questa SIM 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 Questa SIM by typing vsim at a UNIX shell prompt; or double-click a Questa SIM
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>

Questa SIM opens the .wlf dataset and its associated debug database (.dbg file with the
same basename), if it can be found. If Questa SIM cannot find db_pathname.dbg, it will
attempt to open vsim.dbg.

856 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Exploring the Connectivity of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Explore Designs with the Embedded Wave Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Tracing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Tracing the Source of an Unknown State (StX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Finding Objects by Name in the Dataflow Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Automatically Tracing All Paths Between Two Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869

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

Questa® SIM User's Manual, v2023.4 857

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

858 Questa® SIM User's Manual, v2023.4

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 15-4. CurrentTime Label in Dataflow Window

Questa® SIM User's Manual, v2023.4 859

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 15-1.
Table 15-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 signal, window > Expand Net
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860

Control the Display of Readers and Nets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Controlling the Display of Redundant Buffers and Inverters . . . . . . . . . . . . . . . . . . . . . 863
Track Your Path Through the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863

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.

860 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 861

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Limit the Display of Readers and Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

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.

862 Questa® SIM User's Manual, v2023.4

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 15-5)

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

Questa® SIM User's Manual, v2023.4 863

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

Figure 15-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)

864 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 865

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

866 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 867

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:
o Tools > Trace > TraceX
o Tools > Trace > TraceX Delay
o Tools > Trace > ChaseX
o Tools > Trace > ChaseX Delay
• If the Dataflow window is undocked, make one of the following menu selections:
o Trace > TraceX
o Trace > TraceX Delay
o Trace > ChaseX
o 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.

868 Questa® SIM User's Manual, v2023.4

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 15-10:
• All objects become gray
• The source net becomes yellow
• The destination net becomes red
• All intermediate processes and nets become orange.

Questa® SIM User's Manual, v2023.4 869

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

Figure 15-10. Dataflow: Point-to-Point Tracing

870 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
User-Defined Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Current vs. Post-Simulation Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875

Questa® SIM User's Manual, v2023.4 871

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

872 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 873

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

874 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 875

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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
How is the Dataflow Window Linked to Other Windows? . . . . . . . . . . . . . . . . . . . . . . . 876
How Can I Print and Save the Display? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
How Do I Configure Window Options?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880

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

876 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 877

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 . . . . . . . . . . . . . . . . . . . 878
Print from the Dataflow Display on Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . 878
Configure Page Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879

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

878 Questa® SIM User's Manual, v2023.4

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 15-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 15-13. The Page Setup Dialog

Questa® SIM User's Manual, v2023.4 879

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 15-14. Dataflow Options Dialog

880 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 16
Source Window

This chapter discusses the uses of the Source Window for editing, debugging, causality tracing,
and code coverage.
Opening Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Changing File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Navigating Through Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Data and Objects in the Source Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Object Values and Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Search for Source Code Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Debugging and Textual Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Hyperlinked Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Code Coverage Data in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Coverage Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Source Window Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Setting and Removing Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Source Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908

Questa® SIM User's Manual, v2023.4 881

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

Updates to Externally Edited Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883

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

882 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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, Questa SIM 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.

Questa® SIM User's Manual, v2023.4 883

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 16-1):
Figure 16-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.

884 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Displaying Object Values with Source Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Setting Simulation Time in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Search for Source Code Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888

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 16-2)
Figure 16-2. Examine Window Pop Up

You can also invoke the examine and/or describe commands on the command line or in a DO
file.

Questa® SIM User's Manual, v2023.4 885

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 16-3 shows an example of source annotation, where the values are shown in bold red text
and placed under the signals.
Figure 16-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.

886 Questa® SIM User's Manual, v2023.4

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 16-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 16-5).
b. Change the value to the starting time you want for the causality trace.
c. Click the OK button.
Figure 16-5. Enter an Event Time Value

Questa® SIM User's Manual, v2023.4 887

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Searching for All Instances of a String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Searching for the Original Declaration of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889

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.

888 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 889

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Highlighted Text in the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Drag Objects Into Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895

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

890 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 891

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 16-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 16-8).
Figure 16-8. Show Drivers Control Bar Buttons

892 Questa® SIM User's Manual, v2023.4

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 16-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 16-9).
Figure 16-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 16-10). Click an
item in the list to return to a previous operation.
Figure 16-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 16-11 is an example of the List Menu with all three viewing options displayed.

Questa® SIM User's Manual, v2023.4 893

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 16-11. List Menu with All Three Viewing Options On

The driver List Menu in Figure 16-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 16-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 16-13).

894 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 895

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

896 Questa® SIM User's Manual, v2023.4

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

Coverage Data Display

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

Questa® SIM User's Manual, v2023.4 897

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.

Setting Individual Breakpoints in a Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898

Setting Breakpoints with the bp Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Setting SystemC Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Editing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Saving and Restoring Source Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Setting Conditional Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Run Until Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906

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 16-15).
2. The breakpoint markers (red ball) are toggles. Click once to create the breakpoint; click
again to disable or enable the breakpoint.
Figure 16-15. Breakpoint in the Source Window

898 Questa® SIM User's Manual, v2023.4

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

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.

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

Questa® SIM User's Manual, v2023.4 899

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Deleting Individual Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Deleting Groups of Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902

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

900 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Source Window
Editing Breakpoints

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

Questa® SIM User's Manual, v2023.4 901

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.

902 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 903

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 16-17. Source Code for source.sv

904 Questa® SIM User's Manual, v2023.4

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

Setting a Breakpoint For a Specified Value of Any Instance . . . . . . . . . . . . . . . . . . . . . 906

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

Questa® SIM User's Manual, v2023.4 905

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

906 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 907

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

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.

908 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 17
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 Questa SIM
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909

Initiating Causality Traceback from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . 912
Initiating Causality Traceback from the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Multiple Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Causality Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Causality Traceback Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934

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

Questa® SIM User's Manual, v2023.4 909

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

910 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 911

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Command Line Options for Setting Report Destination . . . . . . . . . . . . . . . . . . . . . . . . . 912
Command Line Options for Text Report Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Performing Post-simulation Causality Traceback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914

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.

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 17-1 shows the command line arguments.

912 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 913

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.

914 Questa® SIM User's Manual, v2023.4

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 17-1).

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

Trace to the First Sequential Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916

Tracing to the Immediate Driving Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Tracing to the Root Cause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Tracing to the Root Cause of an ‘X’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Finding All Possible Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Tracing from a Specific Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926

Questa® SIM User's Manual, v2023.4 915

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Initiating the Trace from the Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Initiating the Trace from the Objects or Schematics Windows . . . . . . . . . . . . . . . . . . . 920

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

916 Questa® SIM User's Manual, v2023.4

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 17-2. Cause is Highlighted in Source Window

Click the Control Bar to display a drop-down menu that shows the driver (Figure 17-3), or a list
of drivers if there are multiple drivers (see Multiple Drivers).
Figure 17-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 17-1). The Active Driver Path Details window (Figure 17-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.

Questa® SIM User's Manual, v2023.4 917

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 17-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 17-5).
Figure 17-5. Active Cursor Show Time of Causal Process

The causal process is highlighted in the Structure window (Figure 17-6).

918 Questa® SIM User's Manual, v2023.4

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 17-6. Causal Process Highlighted in Structure Window

The causal signal is highlighted in the Objects window (Figure 17-7).

Figure 17-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 17-8. Time Indicator in Source Window

Prerequisites
Run the simulation.

Questa® SIM User's Manual, v2023.4 919

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 17-9).
2. Change the value to the starting time you want for the causality trace.
3. Click the OK button.
Figure 17-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.

920 Questa® SIM User's Manual, v2023.4

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 17-10).

Questa® SIM User's Manual, v2023.4 921

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 17-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 17-11), then select Show Driver from the drop-down menu.
Figure 17-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 17-12). The time shown in parentheses is the
time at which the causality trace will start.
Figure 17-12. Right-click Menu – Show Driver

922 Questa® SIM User's Manual, v2023.4

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 17-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 17-13).
Figure 17-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.

Questa® SIM User's Manual, v2023.4 923

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 17-14.
Figure 17-14. Trace Event to Root Cause

The Source window jumps to the root cause source code and highlights the relevant line
(Figure 17-15).
Figure 17-15. Root Cause Highlighted in Source Window

924 Questa® SIM User's Manual, v2023.4

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 17-16.
Figure 17-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.

Questa® SIM User's Manual, v2023.4 925

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 17-17).
Figure 17-17. Show All Possible Drivers Menu Selection

This action displays all possible driving assignments of the selected signal
(Figure 17-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 17-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.

926 Questa® SIM User's Manual, v2023.4

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 17-19).
Figure 17-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 17-20).
Figure 17-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 17-21).

Questa® SIM User's Manual, v2023.4 927

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 17-21. Show Drivers Control Bar Buttons

In Figure 17-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 17-22).

Figure 17-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 17-23). Click an
item in the list to return to a previous operation.

928 Questa® SIM User's Manual, v2023.4

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 17-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 17-24 is an
example of the List Menu with all three viewing options displayed.

Figure 17-24. List Menu with All Three Viewing Options On

The driver List Menu in Figure 17-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.

Questa® SIM User's Manual, v2023.4 929

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 17-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 17-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 17-26. View Path Details Buttons

When you click the Schematic Window button, a dedicated Schematic (Path Details) window
opens (Figure 17-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.

930 Questa® SIM User's Manual, v2023.4

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 17-27. Causality Path Details in the Schematic Window

In the Wave viewer (Figure 17-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.

Questa® SIM User's Manual, v2023.4 931

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 17-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 17-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 17-4), when you click the Wave
Window button a dedicated Wave window opens that includes “(Path Details)” as part of its
title (Figure 17-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.

932 Questa® SIM User's Manual, v2023.4

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 17-29. Causality Path Details in the Wave Window

Questa® SIM User's Manual, v2023.4 933

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

934 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 935

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.

936 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 18
Code Coverage

Code coverage is the only verification metric generated automatically from design source in
RTL or gates. While most verification plans require a high level of code coverage, it does not
necessarily indicate correctness of your design. Code coverage measures only how often a suite
of tests exercises certain aspects of the source.
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. A sophisticated exclusions mechanism
enables you to achieve 100% code coverage, even for designs where unused code would
otherwise make it impossible to achieve coverage. Code coverage statistics are collected and
can be saved into the Unified Coverage DataBase for later analysis.

Overview of Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939

Language and Datatype Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Usage Flow for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Specify Coverage Types for Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Enabling Simulation for Code Coverage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Code Coverage in the Graphic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Displaying Coverage Summary in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . 953
Unexpected Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Code Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Statement Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Branch Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Condition and Expression Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
What Objects can be Excluded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Enabling Two-Step Exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996

Questa® SIM User's Manual, v2023.4 937

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

Adaptive Exclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Toggle Exclusion Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Exclude Nodes from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
FSM Coverage Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Code Coverage Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Coverconstructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Code Coverage Mode Interaction with Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . 1027
Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
The toggle report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
XML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Notes on Coverage and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Interaction of Optimization and Coverage Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040

938 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 branch corresponding to if/else,
ternary expressions, and conditional signal assignments, and indicates when a true or
false condition has not executed.
• Condition coverage — Analyzes the decision made in “if” and ternary statements; can
be considered an extension to branch coverage.
• Expression coverage — Analyzes expressions, for example those 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 and transitions within a finite state machine.
• SystemVerilog class coverage — Collects data for each elaborated class type and each
specialization of a parameterized class.
Language and Datatype Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939

Language and Datatype Support

Questa SIM 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.” It stores data for subprograms in the
UCDB as separate regions, and reports on that data separately when you use the coverage report
or vcover report commands. And it displays all subprograms - Verilog tasks and functions as
well as VHDL subprograms - 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, but sometimes optimizations
can make it appear that some statements or branches are not considered for coverage. 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”.

For toggle coverage datatype support, see “Toggle Coverage”.

Questa® SIM User's Manual, v2023.4 939

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.

Code coverage is not collected on any code that is run at elaboration time (loading the design).
For example, a constant function that calculates the array range of a vector signal.

Tip
Coverage ignores design units compiled with -nodebug, and treats them as if they are
excluded. However, toggle coverage of ports compiled with -nodebug is supported only
when you use -nodebug without any options. For example, options like “-nodebug=ports” will
disable toggle coverage.

The basic flow for collecting code coverage in a Questa SIM simulation is:

1. Compile the design and specify the types of coverage to collect:

vlog top.v proc.v
vopt top -o opttop +cover=sbecft

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 can 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.
2. Enable coverage collection during simulation:
vsim -coverage opttop

The optimized design opttop enables coverage for the entire design.
Specify Coverage Types for Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Enabling Simulation for Code Coverage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Saving Code Coverage in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Saving Coverage Using the UVM Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Coverage Auto-save Coverstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946

940 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Specify Coverage Types for Data Collection

Specify Coverage Types for Data Collection

When you specify coverage types for data 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, enable only code for which you intend to collect
coverage statistics.
You can apply coverage to:

• specific source files in the design — By supplying the +cover arguments to vcom or
vlog during compile:
vlog top.v proc.v cache.v +cover=bcesfx -coveropt 1

• specific modules or instance of design — By supplying the +cover arguments to vopt,

using the +<selection> modifier to designate the desired design units or instances:
vlog top.v proc.v cache.v
vopt -o top_opt +cover=bcesxf+moduleA +cover=st+/top/proc/cache
vsim -coverage top_opt

• entire design, globally — By supplying the +cover arguments to vopt:

vlog top.v proc.v cache.v
vopt -o top_opt +cover=bcesxf
vsim -coverage top_opt

or by supplying the +cover arguments using vsim -voptargs (when not specifically using
vopt):
vlog top.v proc.v cache.v
vsim -coverage top -voptargs="+cover=bcesfx”

Union of Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941

Union of Coverage Types

Arguments you specify with +cover are applied in union with all of the previous arguments for
each specific 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

Questa® SIM User's Manual, v2023.4 941

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

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

Enabling Simulation for Code Coverage Collection

Once you specify the coverage types for coverage, you must enable the simulation for code
collection.
Prerequisites
You must specify the coverage types you want to collect (see “Specify Coverage Types for Data
Collection”).

Procedure
1. CLI command: Use the -coverage argument with the vsim command. For example,
vsim -coverage work.top

2. GUI: Simulate > Start Simulation > Others > Enable Code Coverage check box.

942 Questa® SIM User's Manual, v2023.4

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

Figure 18-1. Enabling Code Coverage in the Start Simulation Dialog

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

If you intend to simulate designs multiple times, and capture different coverage data from each
test for post-process viewing and analysis, the naming of the tests becomes important.

Questa® SIM User's Manual, v2023.4 943

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

By default, for non-UVM/OVM tests, the name Questa SIM 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.

Procedure
1. 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 (_).
2. Use any of the following options for saving coverage data dynamically (during
simulation) or in Coverage View mode:
a. 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.
b. 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

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.
c. 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 SystemVerilog LRM; current non-compliant

944 Questa® SIM User's Manual, v2023.4

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

behavior is deprecated and therefore also not recommended. For more information,
see “Simulator-Specific System Tasks and Functions.”
3. 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:
a. Set the modelsim.ini file variable: UCDBFilename=“<filename>”
By default, <filename> is an empty string ("").
b. Specify at the Vsim> prompt: coverage save -onexit command
The coverage save command preserves instance-specific information. For example:
coverage save -onexit myoutput.ucdb

c. Execute the SystemVerilog command:

$set_coverage_db_name(<filename>)

Results
If you use more than one method 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 you specify in the coverage save command. You can use this method to
create the coverage database with a UVM/OVM testname.
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.
% vsim +UVM_TESTNAME=c_test

2. Specify -uvmtestname with the coverage save command.

% 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 it is called c_test.

Questa® SIM User's Manual, v2023.4 945

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

Coverage Auto-save Coverstore

You can use a form of coverage storage called a coverstore to improve merge performance
while automatically saving coverage data without specifying the coverage save command. A
coverstore is a storage location (directory) that holds both design and coverage results, and
which you access in a way similar to the way you access a UCDB file.
The coverstore auto-save functionality improves merge performance, when compared with the
normal situation flow that uses the coverage save command. When vsim is run with -coverstore,
the coverstore directory holds results from multiple tests that share the same design objects and
hierarchy; in the normal situation flow, every leaf level UDCB file holds the test record data, the
design objects, and the results.
Instead of using the coverage save command to save a single UCDB once the simulation has
finished, you can set up the simulation to write coverage data into the coverstore. You can then
use this coverstore as input to the merge process, to produce a regular merge UCDB or an
output coverstore that contains a merged result. You can use command line commands such as
vcover report/attribute/stat/ranktest and vsim -viewcov with coverstores and/or the name of a
coverstore plus a test index (that is, coverstore:test).

Use Flow for Automatically Saving Coverage Data

1. Invoke the simulation (vsim) with -coverstore and -testname options, to automatically
save the coverage data at the end of simulation:
vsim -coverstore <directory_path> -testname <name>

The design hierarchy and all directory paths in the -coverstore argument must be the
same for all of the simulation runs in a regression.
2. Merge all of 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. Optionally, 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 with -outputstore:
vcover merge -outputstore <output_directory> <coverstore_directory_path>

You can use the raw merged output 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

946 Questa® SIM User's Manual, v2023.4

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

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. For example:
vcover merge -out <output_ucdb>
<coverstore_directory_path>[:<testname>[,<testname>]*]

The following are example commands valid for merging user selected tests from the 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
Use 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). Self-contained UCDB
files can handle source-drift (for example, mismatching du signatures). For example, union
merge, or explicit master merge can handle UCDBs generated from different versions of source
code. The coverstore representation of a UCDB does not handle these options, so it is best to use
the coverstore flow 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.

With the 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 in a coverstore are in sync or not. If so, there is no mismatch 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 you cannot use the coverstore flow.

For functional coverage items, a union merge algorithm is used, as the functional coverage
content can 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.

Questa® SIM User's Manual, v2023.4 947

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

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 in a multi-bit count mode for
functional coverage types (covergroups, cover directives, assertions). 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. The
coverstore converts these multi-bit counts to single-bit counts.

If you rely on the integer counts for other types of analysis, such as covergroup, toggle, and
FSM transitions, you can use the -multicount option. For example:

vsim -multicount=f-gt -coverstore store1 -testname test1 design1

In this example, single bit counting is in effect for all coverage types except assertions, cover
directives, fsms, and toggles. See the vsim command -multicount argument for syntax details.

Code Coverage in the UCDB

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

948 Questa® SIM User's Manual, v2023.4

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, various windows display the coverage
data.
In the Code Coverage Analysis window, you can click the Analysis Type selector to display
Statement, Branch, Expression, Condition, FSM, or Toggle coverage.

Figure 18-2. Selecting Code Coverage Analysis Type

The Code Coverage Analysis window displays coverage data “by instance” or “by file,”
depending on whether the “sim” tab (Structure window) or “Files” tab is active.

The Object, Source, and Structure windows display additional Code Coverage Data. 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 an item in the Code
Coverage Analysis window or the Objects window, a Source window opens with the selected
item highlighted. For details, see Table 18-1.

The Structure window displays all subprograms, including Verilog tasks and functions as well
as VHDL subprograms. Since VHDL allows multiple subprograms to have the same name but
different arguments in the same hierarchical scope, the Structure window displays the argument
signature (list of arguments and their types) 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. You can save raw
coverage data to a UCDB and recall, or merge it with coverage data from previous simulations.

Questa® SIM User's Manual, v2023.4 949

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

Table 18-1. Code Coverage in Windows

CDescription
o
v
e
r
a
g
e

w
i
n
d
o
w
CUse this window to perform in-depth analysis
o of incomplete coverage numbers.
d Pulldown menu options for viewing missed
e coverage and details: Statement Analysis,
Branch Analysis, Condition Analysis,
CExpression Analysis, Toggle Analysis, FSM
o Analysis.
v
e Displays exclusions with or without
r comments, missed coverage (anything with
a less than 100% coverage) for the selected
g design object or file, as well as details for each
e object. When the Details window is open, you
can click each line to display object details.
A
n
a
l
y
s
i
s
DDisplays details of missed statement, branch,
e condition, expression, toggle, and FSM
t coverage, as well as exclusions and comments.
a When you select items in Code Coverage
i Analysis windows, the details populate this
l window. Used to perform in-depth analysis of
s incomplete coverage numbers.

950 Questa® SIM User's Manual, v2023.4

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

Table 18-1. Code Coverage in Windows (cont.)

CDescription
o
v
e
r
a
g
e

w
i
n
d
o
w
I Use this window as the primary navigation
n tool when exploring code coverage numbers.
s Displays coverage statistics for each instance.
t It recursively shows all child instances under
a the currently selected region in the Structure
n window. Use this window for analysis based
c on sorting by coverage numbers.
e

C
o
v
e
r
a
g
e

OCan be used to view and analyze Toggle

b Coverage.
j Displays toggle coverage statistics when you
e right-click any column heading and select
c Show All Columns. Various columns show the
t toggle numbers collected for each variable and
s signal shown in the window.

Questa® SIM User's Manual, v2023.4 951

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

Table 18-1. Code Coverage in Windows (cont.)

CDescription
o
v
e
r
a
g
e

w
i
n
d
o
w
SMost useful for statement and branch coverage
o analysis.
u Displays source code for covered items.
r
c
e

SUse this window mainly as a design navigation

t aid.
r Displays coverage data and graphs for each
u design object or file, including coverage from
c child instances compiled with coverage
t arguments. By default, the information is
u displayed recursively. To view coverage by
r local scopes only, deselect Code Coverage >
e Enable Recursive Coverage Sums. Columns
are available for all types of code coverage.
(
s
i
m
)

Displaying Coverage Summary in the Structure Window. . . . . . . . . . . . . . . . . . . . . . . . 953

Unexpected Coverage Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953

952 Questa® SIM User's Manual, v2023.4

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

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 18-3. Coverage Summary Item

Each coverage column contains a summary of that coverage category at the top of the column.
Figure 18-4. Summary Begins Each Coverage Column

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

Questa® SIM User's Manual, v2023.4 953

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Unexpected Coverage Results

• Poorly planned or executed merges can produce unexpected results. (An example of
poor execution is improper application of the -strip and -install options of coverage
edit.)
• Package bodies, whether VHDL or SystemVerilog, are not instance-specific;
Questa SIM sums the counts for all invocations no matter who the caller is.
• All standard and accelerated VHDL packages are ignored for coverage statistics
calculation.
• Design units or instances excluded from code coverage may 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.

954 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Branch Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Finite State Machine Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
SystemVerilog Class Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988

Statement Coverage
Statement coverage is the most basic form of coverage supported by Questa SIM. 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 statement is
processed independently of other statements on the same line. Statement coverage counts are
prominently displayed in the Source window, and in most of the other coverage windows.

Statement coverage statistics for “for” loops display as 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. For example:

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.

Questa® SIM User's Manual, v2023.4 955

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 relates to branching constructs such as “if” and “case” statements. It measures
true branch and false branch execution.
In order to achieve 100% branch coverage, each branching statement in the source code must
have taken its true path and its false path, as well as any AllFalse branches that are present.

Branch Coverage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956

Case and Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
AllFalse Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Missing Branches in VHDL and Clock Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . 960

Branch Coverage Examples

You can analyze Verilog and SystemVerilog 'if … else if … [else]' chains with a code coverage
model.
The code block in Example 18-1 contains an if ... else if ...[else] chain.

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

956 Questa® SIM User's Manual, v2023.4

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 18-2. Coverage Report

Coverage Report by file with details

File: top.v
Branch Coverage:
Enabled Coverage Bins Hits Misses Coverage
---------------- ------ ---- ------ ---------
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 18-1 are inferred —1 ‘if’ branch, 3 'else if' branches, and
1 'else' branch — and three of these branches executed.

If the final 'else' was not in the code block, the coverage score would remain the same; but
instead of 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 each 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 18-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 18-2. Nested
if-else branches are merged differently.

Questa® SIM User's Manual, v2023.4 957

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 used a begin-end pair to segregate the ‘if(reset)’ from the parent ‘else’, the
simulation tool does not merge ‘if(reset)’ with the parent if-elsif-else ladder. Running the
vcover report command 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

958 Questa® SIM User's Manual, v2023.4

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 vlog
and vopt. 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
Missing Branches in VHDL and Clock Optimizations
Branch Coverage Examples
AllFalse Branches

AllFalse Branches
For if statements without a corresponding else, an implicit AllFalse branch is measured. If the if
condition is executed and found to be false, the all false branch is considered to be hit.
In the following VHDL example:

if (fsel = “10”) then

z <= a;
elsif (fsel = “11”) then
z <= b;
end if;

Questa® SIM User's Manual, v2023.4 959

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

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];
end

the AllFalse branch is hit when “fsel” is not equal to INDF_ADDRESS.

You can exclude an AllFalse branch from participation in branch coverage by 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 show the case all false data in the same way if
statement all false data is shown.

You can exclude case statement all false branches in a similar manner. If you use the
CoverExcludeDefault variable in the modelsim.ini file to exclude case statement default clauses,
it will also exclude case statement all false branches.

Related Topics
Exclude Implicit (AllFalse) Branches
Exclude AllFalse Branches in Case Statements

Missing Branches in VHDL and Clock Optimizations

By default, Questa SIM optimizes any VHDL process serving as an edge-triggered flip-flop so
that it is activated only 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 is excluded from code coverage.
The code coverage algorithm reports the exclusion in the Source window, with a special
indicator showing that the branch is excluded for clock optimization. The coverage report notes
the exclusion with the code “ECOP”.

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

Related Topics
coverage on and coverage off Pragma Syntax

960 Questa® SIM User's Manual, v2023.4

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

Condition and expression coverage are described in detail in the following sections.

Focused Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961

Multibit Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Reporting Condition and Expression Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
FEC Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
FEC Report Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
FEC and Short-circuiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Exclusions and FEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Legacy FEC Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
VHDL Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Verilog/SV Condition and Expression Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 975

Focused Expression Coverage

By default, Questa SIM enables only the collection of Focused Expression Coverage (FEC)
style metrics.
FEC is 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
metric 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 with results 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.

Questa® SIM User's Manual, v2023.4 961

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

Multibit Expression Coverage

Questa SIM includes expression coverage for multibit operands and output, giving you the
ability to do coverage analysis on each bit of the expression.
You can perform multibit expression coverage in VHDL and Verilog for all bitwise operators
— AND, OR, XOR, NOT, and ternary. Operand support includes:

• Single dimensional paced vectors

• Part selects of vectors
• Multi-dimensional unpacked arrays
• Structures
Questa SIM’s multibit expression capabilities includes exclusion support for lines, terminals,
and indexes (or ranges).

Usage Model
The use model consists of three steps:

1. Add the -covermultibit argument during optimization.

vopt +cover=e -covermultibit

Optionally, you can include the -covermaxmultiwidth <int> argument if you want to
change the maximum size of the multibit expression. By default, the limit is 32 bits.
2. Use the -coverage command during simulation.
vsim -coverage

3. Generate a text or html report that includes multibit expression results.

vcover report -code=e

or
vcover report -code=e -details -multibitverbose

Including the -details and -multibitverbose arguments with the vcover report command
generates a more detailed and robust coverage report of multibit expression results.

Text and HTML Multibit Expression Reporting

Figure 18-5 is an example of a multibit expression text report generated with the -details and -
multibitverbose arguments.

962 Questa® SIM User's Manual, v2023.4

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

Figure 18-5. Multibit Expression Text Report

• The “Focused Expression View” section of the report shows four variables — a[0:2],
b[0:2], c[0:2], and d[0:2]. Each variable is three bits wide.
• The “Hits” columns are for the index representations (0 and 1) for each term of the
variables.
• Like all other expression reports, the same generalized non-masking conditions apply.
Figure 18-6 is an example of a multibit expression HTML report generated with the -details and
-multibitverbose arguments.

Questa® SIM User's Manual, v2023.4 963

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

Figure 18-6. Multibit Expression HTML Report

Like the multibit text report, the HTML report contains the bit-blasted FEC input terms, the
generalized non-masking conditions, and the indexes that are used for each of the terms.

964 Questa® SIM User's Manual, v2023.4

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

Reporting Condition and Expression Coverage

The guidelines and usage associated with condition and expression coverage reporting are based
on the individual metrics being applied.
By default, when you enable coverage with the “+cover=ec” argument (where “=ec” enables
expression and condition coverage) to vcom/vlog/vopt, only FEC coverage statistics are
collected and reported.

• You can turn on/off FEC collection using the -coverfec and -nocoverfec argument to
vcom/vlog/vopt.
You can print condition and expression coverage tables in coverage reports as follows:

• GUI: Select Coverage Reports > Condition Coverage or Expression Coverage (refer
to “Coverage Reports”)
• Command Line: Enter coverage report -details to obtain detailed analysis metrics. This
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.
coverage report -details -all

or
vcover report -details -all

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 -fecudpeffort argument to vlog/vcom/vopt, or the FecUdpEffort modelsim.ini
file variable.

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.

Questa® SIM User's Manual, v2023.4 965

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 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 said to be fully covered when the following conditions apply:

• All other inputs are in a state that allow the covered input to control the output of the
expression.
• The output can be seen in both 0 and 1 states while the target input is controlling it.
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 (Modified Condition/Multiple Decision).

Every expression, regardless of how complex it is, 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))

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

966 Questa® SIM User's Manual, v2023.4

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

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, the assumption when evaluating 'b' in 'a && b && c' is 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 18-2 lists operators with non-masking states of inputs. In this table, the coverage of 'A' is
being collected in the expression.
Table 18-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
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, make sure the input being examined for coverage has taken
both '0' and '1' states when the other input of the expression is in a non-masking state. Note that
you are looking only at the value of the other input in the basic expression, and not inputs of the
expression. An input is 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.

Questa® SIM User's Manual, v2023.4 967

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

For example, consider the following expression:

a & (b | c)

For terminal a to be covered, the value of expression (b | c) must be in a non-masking state (that
is, 1 for the & operator).

In case of XOR, the value of the other input must be the same when the two collections are done
to ensure that both collections are done when the input is active in the same mode (inverting or
non-inverting).

For example, consider the following expression:

a ^ b ^ c

For terminal a to be covered, the expression (b ^ c) must evaluate to the same value for both _0
and _1 values of a. That is, if b = 0 and c = 0, then b^c = 0; if b = 1 and c = 1, then (b^c) = 0.
Although both b and c are changing, the expression (b^c) remains the same, ensuring that
terminal a is controlling the output.

An expression is 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 18-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.

968 Questa® SIM User's Manual, v2023.4

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 table 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 observed. By definition a is 0 for every
Non-masking condition on the a_0 list. 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. It is always the case
that non-masking conditions are identical for each pair of FEC rows (non-short circuit logic
only).

In walking through the FEC report 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.

Questa® SIM User's Manual, v2023.4 969

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 5 of Example 18-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 18-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}. Note that the input order for each input
vector is (a,c,b,d).

As in the simple, unimodal case shown in Example 18-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. The hits are divided into two
columns based on the output value of the expression. The output value for any FEC target is
observed by applying an input pattern that satisfies the corresponding non-masking conditions.
An input terminal qualifies as FEC covered only when it receives _0 and _1 hits for different
output values. This ensures that the terminal is independently controlling the expression output
while operating in one mode (inverting or non-inverting). Note that multiple, comma-separated,
non-masking conditions in the report indicate separate non-masking conditions, not a list of
conditions that must all hold.

970 Questa® SIM User's Manual, v2023.4

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 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 bin corresponding to 'a_0' was
incremented for output value 1, as an input vector satisfying the non-masking conditions was
observed. Similarly, an input vector satisfying non-masking 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
Looking at the FEC tables for bimodal expressions, above, 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 is uncovered. If you scan down the ->0 and ->1 columns
looking for strings of '0's, you can then concentrate on those inputs and their matching input
patterns.

FEC and Short-circuiting

Some expressions do not require evaluation of all of the inputs within the expression, once the
output has been determined. Skipping evaluation of some of the inputs 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
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)

Questa® SIM User's Manual, v2023.4 971

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

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 'a_0' and 'a_1'. They are 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.

The Details window and the text coverage report for each condition and expression give a brief
short-circuit status.

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

972 Questa® SIM User's Manual, v2023.4

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

pair breaks the link between their outputs. If one row is excluded, the non-excluded row
becomes independent — which 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 18-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

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

Questa SIM implements Rapid Expression Coverage (REC) processing as the default mode for
FEC condition and expression coverage.
REC processing offers better performance, handles larger expressions than previous versions of
coverage processing, and defaults to printing the non-masking conditions in the FEC tables
instead of the matching input patterns.

In previous releases, the FEC report printed matching input patterns by default. To produce a
report that prints matching input patterns, set the modelsim.ini variable CoverREC to 0
(disable), or apply the -nocoverrec argument to vcom, vlog, or vopt.

Questa® SIM User's Manual, v2023.4 973

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

Example 18-5 shows an example of this style of report, which is equivalent to the simple
expression FEC report shown in Example 18-3.

Example 18-5. Simple Expression - Pre-10.3 Style Report for FEC Coverage

# ----------------Focused Expression View-----------------

# Line 31 Item 1 #1 tempreg1 <= (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 Matching input patterns
# --------- --------- -------------------- -------------------------
# Row 1: 1 a_0 { 011 }
# Row 2: 1 a_1 { 111 }
# Row 3: 1 b_0 { 101 }
# Row 4: 1 b_1 { 111 }
# Row 5: ***0*** c_0 { 110 }
# Row 6: 1 c_1 { 111 }
#
# NOTE:
# * Order of matching input pattern values: {a,b,c}

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.
A subexpression with a relational operator is 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.

974 Questa® SIM User's Manual, v2023.4

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

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/SystemVerilog condition and expression coverage, as in VHDL, arbitrary types are
supported when they involve a relational operator with a boolean result.
Verilog/SystemVerilog condition and expression coverage ignores expressions that contain
only one input variable, and also ignores expressions that result in vector values. Condition and
expression coverage does support logical operators (&& || ^, for example) for one-bit net, logic,
and reg types.

Related Topics
Condition and Expression Coverage

Questa® SIM User's Manual, v2023.4 975

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 for
various Verilog, SystemVerilog, and VHDL signal types.
The signal types include:

• For Verilog and SystemVerilog: 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.
• For VHDL: 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 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'.

When compiling or simulating, specify standard (2-state) toggle using the “t” code, and
extended (3-state) toggle using the “x” code.

Toggle coverage can be excluded from statistics collection, though proper management of
exclusions is important.

Toggle Coverage and Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976

VHDL Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Verilog/SV Toggle Coverage Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Toggle Ports Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Viewing Toggle Coverage Data in the Objects Window . . . . . . . . . . . . . . . . . . . . . . . . . 979
Toggle Counts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Specifying Toggle Coverage Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Toggle Using the Main Window Menu Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Limiting Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987

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 SIM. Collecting
toggle coverage indiscriminately across an entire design can cause slowdowns of 10x or more.

976 Questa® SIM User's Manual, v2023.4

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 the performance impact (see “Toggle Ports Only Flow”).

Other methodologies may help reduce performance impact. For example; collecting toggle
coverage only on a subset of simulations, or on a subset of regions within a simulation.

You can also use the following vcom, vlog, and vsim options 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, or
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.
A limit variable determines the maximum number of values to record. The default is 100 values,
but you can change the limit value on a per-signal basis. You can turn the limit variable off
completely with the -notoggleints option for the vsim command, or by setting
ToggleNoIntegers in the modelsim.ini file. You can increase the limit variable 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 is seen, the VHDL integer 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.

Questa® SIM User's Manual, v2023.4 977

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

Toggle coverage type support for Verilog and SystemVerilog includes 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. Each bit of non-scalar object
types is counted and recorded. 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.
Questa SIM treats SystemVerilog integer atom types as toggle nodes unless the
-notogglevlogints argument is applied with the vsim command, or the ToggleVlogIntegers
variable is turned off in the modelsim.ini file. 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 -togglevlogreal argument with the vsim command or turn on the
ToggleVlogIntegers variable in modelsim.ini. When toggle collection is in effect for SV real
types, Questa SIM keeps a record 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. You can increase the limit variable with the -togglemaxrealvalues argument to the vsim
command, or by setting ToggleMaxRealValues in the modelsim.ini file. A SystemVerilog real
is considered 100% toggled if at least two different values are seen during simulation. If only
one value is 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 argument causes coverage to be reported as if the object is
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 treat the object as an equivalent packed array of bit or logic type. The
“ToggleVlogEnumBits” modelsim.ini variable provides a default value for
-togglevlogenumbits.

Questa SIM limits SystemVerilog unpacked array support 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

978 Questa® SIM User's Manual, v2023.4

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 argument only applies to the packed dimensions of
multi-dimensioned SystemVerilog arrays.

Questa SIM supports SystemVerilog unpacked structs as long as all struct elements consist of
supported data types. It breaks unpacked structs into their fields, and calculates toggle coverage
for each field 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 collecting coverage only 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. You can enable it with the
TogglePortsOnly modelsim.ini variable, or by using 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
because inlining is turned off. If you specify vopt acc=p in case of a QIS flow you need –
inlineFactor=0 and -access=rw to get the same result. You can selectively enable toggle
coverage on specific ports with the “vopt +acc=p+<selection>” command.

The coverage reports and GUI show only numbers associated with togglenodes that are ports in
the design. Similarly, coverage aggregation calculations involve only 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, right-click in the Objects window to open a context popup menu,
and mouse-over the Toggle Coverage selection to open the sub-menu.

Questa® SIM User's Manual, v2023.4 979

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

Figure 18-7. 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, and Reset. A
second-level sub-menu enables 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 display
all Toggle coverage columns. 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 18-8. Toggle Coverage Data in the Objects Window

980 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 981

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

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

Conversion of Extended Toggles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Coverage Computation for Toggles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Toggle Nodes that Span Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Extended Toggle Mode Across Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985

Standard and Extended Toggle Coverage

Standard (2-state) toggle coverage only counts 0L->1H and 1H->0L transitions, while 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.
To address the issue of togglenodes that cannot produce Z values, all modes of extended toggle
coverage calculation allow 100% coverage for lh and hl, as long as no Z edge occurs. When an
extended togglenode with no Z edges is observed in simulation, it is implicitly converted to a 2-
state togglenode.

The 2-state togglenode has only0L->1H and 1H->0L counts. Such togglenodes 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.

982 Questa® SIM User's Manual, v2023.4

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 two
bins. In extended mode, there are a different number of bins based on the exact extended toggle
mode.
Nothing changes with respect to 0L->1H and 1H->0L bins. These are two 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 affects 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 Questa SIM, 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.

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.

Questa® SIM User's Manual, v2023.4 983

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

In some situations, aliasing is not applicable. The following are some of the more common
cases, where a signal could be counted more than once:

• 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.
• SystemVerilog variable ports (like a Verilog reg used as a port) — These are not treated
as connected nets, hence are not treated as aliases.
• VHDL conversion functions on port actuals.
• When you use the vsim -nocollapse option (applies only to VHDL designs).
Questa SIM uses the following rules when processing hierarchical togglenodes:

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

The existence of alias names for high level toggle nodes can create confusion when you are
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

984 Questa® SIM User's Manual, v2023.4

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

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. When you do not use these, many ports on hierarchical
signals are not visible to the coverage reporting system. The +acc=p switch can degrade
simulator performance significantly, so use it only when necessary for analysis. Use the
+acc=p+<selection> modifier whenever possible, 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. For example:

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

A signal that spans multiple levels of hierarchy can 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.
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

Questa® SIM User's Manual, v2023.4 985

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.
You can specify either standard toggle or extended toggle, using any of the following methods:

• Compile (vcom/vlog) using the argument +cover= with either ‘t’ or ‘x’.
• 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986

Using the Toggle Add Command

The toggle add command enables you to initiate toggle coverage at any time from the command
line. Upon the next running of the simulation, toggle coverage data is collected according to the
arguments you employ (for example, the -full argument enables collection of extended toggle
coverage statistics).
Arguments you specify with the toggle add command override the +cover=t(x) arguments that
were 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 run a toggle add command on a group of signals, then run 'toggle add -full' on the
same signals, the signals will be converted to extended toggle coverage mode (all six
transitions). (See Standard and Extended Toggle Coverage.) Similarly, running a 'toggle add'
command on extended toggle coverage mode toggles (six transitions), 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 applies to all fields of the structure, and not to any
particular type of field.

986 Questa® SIM User's Manual, v2023.4

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 you make a selection, toggle coverage statistics are 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.
Use the ToggleCountLimit modelsim.ini variable to set the limit. After the limit is reached,
further activity on the node is 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 six edge transitions, all six 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

Questa® SIM User's Manual, v2023.4 987

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 Questa SIM 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 collected separately for each constructed dynamic class object, only the sum of
all objects of a given elaborated type. Data is 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.

988 Questa® SIM User's Manual, v2023.4

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 can use coverage exclusions to exclude coverage for
individual design units, files, lines of code, objects, and so on.
You can exclude coverage objects with 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 enables you to generate reports later in Coverage View mode that match the
most recent simulation state.

What Objects can be Excluded?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989

Excluded Objects in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Auto Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Methods for Excluding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Enabling Two-Step Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Exclude Individual Metrics with CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude Individual Metrics with Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Adaptive Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Toggle Exclusion Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Exclude Nodes from Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
FSM Coverage Exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Saving and Recalling Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021

What Objects can be Excluded?

Exclusions can be instance or file specific.
You can exclude the following objects 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 with “coverage exclude -code t”,
“coverage exclude -togglenode”, or “toggle disable”.

Questa® SIM User's Manual, v2023.4 989

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

Excluded Objects in the GUI

Excluded coverage objects are designated in the GUI by a green ‘E’ in the appropriate coverage
column.
You can 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.

Auto Exclusions
Exclusions are automatically applied to certain code constructs. An 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 example is FSM state exclusions. By default, excluding a state excludes all transitions
to and from that state. 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 18-3 for a list of codes (such as “EBCS”) that appear in the
coverage report and are associated with auto exclusions.
Table 18-3. Auto-Exclusion Reason Codes in Coverage Reports
Reason Code Description of Coverage Item’s Exclusion
E Item is excluded, with no reason given
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

990 Questa® SIM User's Manual, v2023.4

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

Table 18-3. Auto-Exclusion Reason Codes in Coverage Reports (cont.)

Reason Code Description of Coverage Item’s Exclusion
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.

Methods for Excluding Objects

Questa SIM includes several 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
o Coverage Details window: Right-click a logic transition and select Exclude
transition.
OR

Questa® SIM User's Manual, v2023.4 991

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Enabling Two-Step Exclusions

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

Enabling Two-Step Exclusions

Enable two-step exclusions to avoid GUI lag when adding many exclusions individually. The
two-step exclusions mode postpones the application of exclusions until you manually execute
them.
Prerequisites
• Review Methods for Excluding Objects to become familiar with adding exclusions.

992 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Enabling Two-Step Exclusions

Procedure
1. Enable two-step exclusions at the vsim command prompt or with the GUI menu bar:
• Command Prompt — enter the coverage configure -2stepexclusion command as
follows:
coverage configure -2stepexclusion on

• GUI — Select Tools > Coverage Configuration > Two-Step Exclusions

This opens the Pending Exclusions window.
2. Add any desired exclusions.
• Load an exclusion file with the Pending Exclusions window File > Load Exclusion
File menu item.
3. (Optional) Save pending exclusions.
Save the list of pending exclusions with the File > Save Exclusion File menu item in
the Pending Exclusions window.
This action saves all listed exclusion commands to the file, regardless of which are
selected.
4. Execute pending exclusions.
• Execute the full list from the Pending Exclusions window. Select Pending
Exclusions > Apply All.
• Execute a partial selection of the pending exclusions list. Select the specific
exclusion commands from the pending list with the mouse, then select Pending
Exclusions > Apply.
Examples
This example illustrates the basic flow for enabling two-step exclusions and applying a pending
exclusion.

1. Enable two-step exclusions by selecting Tools > Coverage Configuration > Two-Step
Exclusions. The Pending Exclusions window appears, but is empty.

Questa® SIM User's Manual, v2023.4 993

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Enabling Two-Step Exclusions

Figure 18-9. Empty Pending Exclusions Window

2. Add some exclusions using the vsim command prompt.

coverage exclude -src test_sm -line 84 -code s
coverage exclude -src test_sm -line 124 -code s
coverage exclude -src test_sm -line 125 -code s

The window is now populated with exclusion commands. Note that the commands listed
are the exact same as those entered at the application command prompt.
Figure 18-10. Populated Pending Exclusions Window

3. Select an exclusion with the mouse, the green Execute Selected Exclusions button is
now active.
Figure 18-11. Selecting a Pending Exclusion

994 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Enabling Two-Step Exclusions

4. Click the Execute Selected Exclusions button to apply the selected exclusion.

Questa® SIM User's Manual, v2023.4 995

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

You can use the coverage exclude command with specific arguments to exclude individual
metrics.
Exclude True or False Branch of if Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude Implicit (AllFalse) Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Exclude AllFalse Branches in Case Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Exclude Any/All Coverage Data in a Single File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997

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.

Exclude Implicit (AllFalse) Branches

You can explicitly exclude branches which are implicit at the end of an if/ elsif/elsif tree, but
only if there is no trailing “else” at the end of the tree.
For example:

if (a = '1') then -- line 30

Z <= Y;
elsif (b = '1') then -- line 32
Z <= X;
end if;

996 Questa® SIM User's Manual, v2023.4

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

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, when 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 are also excluded.

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 is 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, in the same way 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

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

To exclude coverage data in a given source file, use the coverage exclude command.

Questa® SIM User's Manual, v2023.4 997

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

You can use the coverage exclude command to exclude any or 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 18-6. 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):

transcript on

Default Exclusion Filter File

You can use the default exclusion filter file to aid in applying default exclusions to your
simulation.

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.

998 Questa® SIM User's Manual, v2023.4

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

Questa SIM supports the use of source code pragmas to selectively turn coverage off and on for
individual code coverage metrics.
Pragmas enable you to turn statement, branch, condition, expression, toggle, and FSM coverage
on and off independently.

Supported Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999

Verilog vs. VHDL Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
coverage on and coverage off Pragma Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Pragma Usage and Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005

Supported Pragmas
Questa SIM supports pragmas for branch, expression, statement, toggle, and FSM coverage.
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).

Questa® SIM User's Manual, v2023.4 999

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 can change from one report to the next, depending on
whether branch coverage was enabled.

Verilog vs. VHDL Pragmas

Verilog and VHDL pragmas are enforced at different levels and also have other usage
differences.
• Verilog — Pragmas are enforced at the file level, so will have no affect on an
instantiated instance. If you want to disable coverage for an instance, you need to put
pragmas in the file containing that design unit. 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 design unit level. For example, if you place the “-
- coverage off”pragma inside an architecture body, all 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” pragma). 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”.
• Pragmas can 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”.

1000 Questa® SIM User's Manual, v2023.4

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

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 the number of 'coverage off' pragmas encountered earlier in the file.

• The “coverage off” and “coverage on” pragmas turn coverage on and off 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.
<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 '( )'.

Questa® SIM User's Manual, v2023.4 1001

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

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.

1002 Questa® SIM User's Manual, v2023.4

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

The coverage on|off pragma has two forms; one for general exclusions of specific coverage
types, or for all types if none are specified, and another for fine-grained exclusion, 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 valid only 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
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,

Questa® SIM User's Manual, v2023.4 1003

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

from left to right, beginning with 1. Specify item numbers as an integer or a series of
integers (item 1 or items 2-4). Separate multiple items with a white space.
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.

1004 Questa® SIM User's Manual, v2023.4

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

Pragma Usage and Nesting

Using coverage pragmas in long source files or included files during development can result in
nested pragmas, which can lead to unintended or confusing coverage behavior. Synthesis
pragmas can also effect coverage.
The following scenarios describe coverage behavior that Questa SIM exhibits as it encounters
nested pragmas. In all cases, Questa SIM generates notes to inform you when coverage is
enabled in the sourced code. You can disable these notes with the vsim argument “-suppress
2071”.

Consider how code coverage is enabled in the following examples of nested pragmas.

Questa® SIM User's Manual, v2023.4 1005

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

Example 18-7. 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 */

You might assume that coverage collection is enabled by the fourth pragma (on line 7), but it is
the third pragma (on line 5) which enables the code coverage collection; and coverage
collection remains on for the rest of the code. The fourth pragma is ignored and a note appears
in the Transcript window showing 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 coverage is already enabled.

Example 18-8. 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.

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

1006 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1007

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Generating an Adaptive Exclusion DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009

The Adaptive Exclusion DO File

The adaptive exclusion DO file marks intended exclusions for later use even when design
changes 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 through use of a DO file—specifying
everything to exclude from coverage in a particular run—coverage exclusions contain specific
file line number information to identify objects to exclude.

Because exclusions are tied to line numbers, when you want to change the source code and
rerun the simulation, your changes can alter the file line number information and render the
original version of the exclusion DO file useless.

You can use adaptive exclusions to avoid having to manually edit the exclusion DO file. Use the
-adaptive argument with the vopt command to generate coverage signatures for all coverage
items which uniquely identifies them based on their content and where they exist in the flow of
code, rather than by line number. This allows you to apply exclusions to multiple simulation
runs, even after changes in the design.

Adaptive exclusion includes a covsig (coverage signature) for every coverage item. As long as
these signatures are the same after the RTL changes, Questa is able to adapt to the new changes.
These signatures are dependent on:

1. Scopes inside the module (generates/blocks)

2. Data flow (if-else-if / case ladder)
3. Coverage item content
If a change in RTL impacts any of the above parameters for a coverage item (statement/branch)
Questa will not adapt to the newly generated exclusions. When you try to apply these adaptive
exclusions, Questa produces an error message indicating it could not apply those exclusions.

You can use adaptive exclusions for statement, branch, expression, and condition coverage in
both Verilog and VHDL. Toggle and FSM coverage work on absolute hierarchical path and are
not reliant on file/line numbers. Other types are adaptive by nature, so the Adaptive Exclusion
feature is not required

1008 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Adaptive Exclusion

The flow diagram below illustrates the steps for generating and applying an adaptive exclusion
file.

Figure 18-12. Adaptive Exclusion Flow Diagram

Generating an Adaptive Exclusion DO File

You use the vopt, vsim, and coverage report or vcover report commands to generate an adaptive
exclusion. You do not need to append any options 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 with either coverage report or vcover
report.
coverage report -excluded -adaptive -file exclusion.do
vcover report -excluded -adaptive -file exclusion.co

Questa® SIM User's Manual, v2023.4 1009

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Adaptive Exclusion

Examples
LIVE SIM FLOW
First Run
1. Compile the design.
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

1010 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Toggle Exclusion Management

4. Save coverage UCDB.

coverage save u1.ucdb

5. Load the coverage UCDB.

vsim -viewcov u1.ucdb

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

Toggle Exclusion Management

Toggle coverage as it relates to exclusions is more complex to configure than other coverage
types, because the toggle command precedes the introduction of code coverage in Questa SIM.
Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1011

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
Toggle Exclusion Management

• Compiler/Simulator flow — Using this flow, you set up Questa SIM 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
relevant only 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 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.
This method requires both “vcom/vlog +cover=t” and “vsim -coverage” in order to add
toggles for coverage.
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 consistently reproduces the same set of enabled toggles only in the
compiler/simulator flow, 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 applied only with respect to currently enabled toggles, not to a pristine, toggle-free
environment.

Nothing in Questa SIM prevents you from mixing commands from the manual and complier/
simulator flows, but you should do so only with a solid understanding of how they interact.

1012 Questa® SIM User's Manual, v2023.4

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 also exclude individual transitions from the GUI. Simply right-click any
transition in the Coverage Details window and select Exclude transition from the
context popup menu.
Figure 18-13. Exclude Individual Transitions in the GUI

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; or you can
right-click an excluded transition in the Coverage Details window (designated with ‘E’) and
select Unexclude transition from the popup menu.

Toggle Pragma Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014

Questa® SIM User's Manual, v2023.4 1013

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 Bus Bits from Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015

Re-enable Toggles Excluded with Pragmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
Exclude enum Signals from Toggle Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016

Toggle Pragma Exclusion

You can use any one of three pragmas to exclude toggle nodes.
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>]

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.

1014 Questa® SIM User's Manual, v2023.4

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

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 are not
created, and the nodes cannot be included later.
The precedence order of these three pragma exclusions is:
“coverage never” > “coverage toggle_ignore” > “coverage on/off”

Simultaneous Behavior of Pragmas

Both // coverage on/off and // coverage toggle_ignore work for toggle coverage. If you use the /
/ coverage on/off and // coverage toggle_ignore pragmas simultaneously, then // coverage
toggle_ignore overrides // coverage on/off. 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 are ignored.

In the following code:

module top;
// coverage toggle_ignore temp1
reg temp;
// coverage on
reg temp1;
endmodule

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

Questa® SIM User's Manual, v2023.4 1015

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

Re-enable Toggles Excluded with Pragmas

Toggles that have been previously excluded using pragmas can be re-enabled (in the compiler/
simulator flow) with 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

You can exclude individual VHDL and SystemVerilog enums or ranges of enums from toggle
coverage and reporting by specifying enum exclusions in source code pragmas or by using the
-exclude argument to the toggle add command.

1016 Questa® SIM User's Manual, v2023.4

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 Questa SIM, you can exclude any transition or state of an FSM from the coverage reports,
either with the coverage exclude command at the command line, or by pragma.
Exclude FSM with coverage exclude Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
FSM Pragma Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018

Exclude FSM with coverage exclude Command

You can use the coverage exclude command 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”).

coverage exclude -du fsm_top -ftrans state

Questa® SIM User's Manual, v2023.4 1017

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Code Coverage
FSM Coverage Exclusions

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.

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

1018 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1019

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

1020 Questa® SIM User's Manual, v2023.4

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

Saving and Recalling Exclusions

You can specify files and line numbers, or condition and expression FEC truth table rows, to
exclude from coverage statistics. You can use vsim’s Tcl command, coverage report, to create a
.do file that contains these exclusions.
For example:

coverage report -excluded -file <filename>.do

You can use the vsim command to load this .do file during a future analysis. For example:

vsim -coverage <design_name> -do exclusions.do

The contents of theexclusions.do file will be similar to 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:

1. Compile your design with the +cover=<argument> to:

o vopt, if using 3-step vopt flow
o vcom or vlog, if not explicitly running vopt (2-step vopt flow)

Questa® SIM User's Manual, v2023.4 1021

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

2. Load and run your design with:

vsim -coverage <design_name> -do “do exclude.do; run -all”

To avoid running the “-do exclude.do” explicitly, you can set the default exclusion filter to run
the exclusion.do file automatically upon invocation.

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

For example, if your <exclude_file_i> files are all the same, and called exclude.do, the contents
of exclude.do could be:

coverage exclude -srcfile xyz.vhd -linerange 12 55 67-90

1022 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1023

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

The Questa SIM default coverage collection for RTL constructs includes a covermode option
that enables you to control coverage collection of your constructs to meet coverage closure
goals.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
Covermodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
Code Coverage Mode Interaction with Coverage Arguments. . . . . . . . . . . . . . . . . . . . . 1027

Coverconstructs
The covermode option provides user-controlled coverconstructs. A coverconstruct corresponds
to a particular HDL code construct that you can instrument for coverage collection.
Some coverconstructs are permanently enabled and you cannot control them. 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.

Two 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 18-4), and the abbreviations for these two
example constructs are “citf” and “evda,” respectively.

The vopt command-line argument for setting a coverconstruct is:

vopt -coverconstruct [comma-separated list of mnemonics]

Example:

vopt -coverconstruct citf, evda

You can also set a coverconstruct with the coverconstruct variable in the [vopt] sections of the
modelsim.ini file:

coverconstruct [list of mnemonics]

1024 Questa® SIM User's Manual, v2023.4

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

Table 18-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 [no]ctes ctes ctes noctes noctes noctes
for Task Enable
statement
Condition coverage [no]cicl cicl cicl nocicl nocicl nocicl
for instance
connection list
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

Questa® SIM User's Manual, v2023.4 1025

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

Table 18-4. Coverconstruct Mnemonics (cont.)

HDL Construct/Item Mnemonic -covermode -covermode -covermode -covermode -covermode
full default set1 set2 fast

Coverage for allfalse [no]cafcase cafcase cafcase cafcase cafcase nocafcase

branch of a case
statement
Coverage for allfalse [no]cafsa cafsa cafsa cafsa cafsa [no]cafsa
(default) branch for
VHDL CSA (default
branch for SSA)
Coverage for default [no]cdcase cdcase cdcase cdcase cdcase nocdcase
branch of a case
statement3
Coverage for [no]bind bind bind bind bind nobind
modules 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]tcpmda tcpmda tcpmda tcpmda notcpmda notcpmda
packed multi-d array
types4
Toggle coverage for [no]tcpu tcpu tcpu tcpu notcpu notcpu
packed union types4
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.
5. Unpacked arrays of mixed packed/unpacked dim, singled, multi-d. Total width controlled by
-togglewidthlimit.

Covermodes
A covermode corresponds to a set of coverconstructs considered for coverage collection.

1026 Questa® SIM User's Manual, v2023.4

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

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
Some code coverage options interact with each other. This section describes each covermode
and its corresponding coverconstructs and provides examples.
The code coverage options are:

• +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
to either the compiler (vlog/vcom) or the optimizer (vopt). The +nocover option can be
given only 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.

Questa® SIM User's Manual, v2023.4 1027

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

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 be given
only 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 -covermode’s default csa specification. Continuous assignments are not
covered.
• Coveropt decides the optimization level of the tool in a coverage enabled run. The
optimization level can affect the coverage bins. A high coveropt level may remove
certain instances of a coverconstruct regardless of other applied (cover, coverconstructs,
or covermode) settings. Instances of the coverconstruct that are removed 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 covermode arguments and corresponding coverconstructs are:

• -covermode full — The most exhaustive coverage collection. Has the richest set of HDL
constructs, and contains all constructs (except for negation items) mentioned in the
mnemonic table.
• -covermode default — (Default) Has a rich set of cover constructs enabled. All the
covermodes have relative positioning with this default covermode.
• -covermode set1 — Does not consider the following constructs for coverage collection:
o Continuous/Concurrent Assignments
o Condition coverage inside Task/Function/Procedures
o Task FSMs and two-state FSMs
o Condition coverage:
• In terminal connection lists in task-enabling statements
• In instance connection lists

1028 Questa® SIM User's Manual, v2023.4

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

• In “for” loops
o FSM coverage for unpacked dimension in current state variable and next state
variables
o 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.
o Coverage for partially/fully protected modules and their children for any coverage
metric. If any part of a module’s code is protected, then do not monitor the module
or its self-instance and the full hierarchy below it, for coverage.
o Toggle for integer atomic types (for example, int, integer, short).
o Coverage for SystemVerilog packages and classes.
o Branch and cond coverage inside assertions.
-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 — Removes Task FSMs (FSM definitions that span through a task/
procedure) and two-state FSMs (FSMs that have less than three states) from coverage
collection.
-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

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 also enables the
following: quad-state FSMs, togglenodes used as loop indexes, and condition coverage inside
tasks and functions.

vopt +cover -coverconstruct fsmqs -covermode set1

Questa® SIM User's Manual, v2023.4 1029

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

1030 Questa® SIM User's Manual, v2023.4

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
You can reate 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
You can create HTML reports by applying the -html argument to the coverage report and
vcover report commands.

Access the Coverage Report dialogs in the GUI by right-clicking any object in the Files or
Structure (sim) windows and selecting Code Coverage > Code Coverage Reports; or, select
Tools > Coverage Report > Textor HTML or Exclusions.

The Coverage Text Report dialog enables you to display coverage reports immediately, either
in the default Notepad text viewer/editor included with the product, in the Source viewer, or in
an editor that you choose with the EDITOR environment variable.

Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031

Code Coverage Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Using the coverage report Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
The toggle report Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Setting a Default Coverage Reporting Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
XML Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
HTML Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Coverage Reporting on a Specific Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038

Report Contents
By default, the coverage report contains a summary of coverage information for the indicated
design unit, file, or instance. The summary includes code coverage numbers for each coverage
type.

Questa® SIM User's Manual, v2023.4 1031

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 corresponding to each active coverage type:

• For statements — Gives a code listing along with counts and exclusion details. This is
similar to the Source window when in coverage mode.
• For branches — Gives a code listing similar to that shown in the Source window.
• For conditions and expressions — Prints detailed row-by-row FEC tables, along with
hit counts for each row. See “Reporting Condition and Expression Coverage” for more
information.
• For toggles — Lists missed togglenodes.
• For FSMs — Lists missed states and transitions.
• Auto-Exclusions — Lists exclusions, along with a code defining the reason they are
excluded. These codes are listed in Table 18-3.
Related Topics
Auto Exclusions

1032 Questa® SIM User's Manual, v2023.4

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 you remove branches and statements and make a condition
constant, or if you make the right-hand-side of a particular statement constant and optimize it
away. When you change the sequence, you change the profile.

When you “inline” an instance of a module, you copy the code for that module into the “parent”
module for that instance. Then, you can perform further optimizations 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. Likewise, if you
inline several instances of a module with different parameters and constant inputs, the resulting
family of instances may have many different code coverage “profiles”.

The solution for resolving different profiles of coverage is to report coverage by-instance. When
you report the data by-instance, you can see exactly which statements are included (no longer
optimized away) and what their coverage counts are. Whereas, if you report the data by-du or
by-file, Questa SIM attempts to merge these different profiles, which can 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 . . . . . . . . . . . . . . . . . . 1033

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 occurs on the same line as another type of coverage
object (such as an assignment) in the source code, enabling or disabling branch coverage can
cause the item numbers for the coverage objects to change from one coverage report to the next.

Using the coverage report Command

The coverage report command produces textual output of coverage statistics or exclusions of
the current simulation.
Example 18-10. Reporting Coverage Data from the Command Line

The following sample command sequence outputs a textual code coverage report and saves the
coverage data:

vlog ../rtl/host/top.v

Questa® SIM User's Manual, v2023.4 1033

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

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.

1034 Questa® SIM User's Manual, v2023.4

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. The command also displays 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Port Collapsing and Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Ordering of Toggle Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036

Using toggle report

Use the toggle report command to display information on nodes that have not toggled.
Note
You can also use the coverage report command to produce this information.

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

Questa® SIM User's Manual, v2023.4 1035

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 18-14. Sample Toggle Report

Port Collapsing and Toggle Coverage

The simulator collapses certain ports that are connected to the same signal in order to improve
performance. Collapsed signals do 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
The toggle report Command
Toggle Nodes that Span Hierarchy

Ordering of Toggle Nodes

The ordering of nodes in the report can vary depending on how you specify the signal list.
If you use a wildcard in the signal argument (for example, “toggle report -all /*.”), the report
lists nodes in the order signals are found when searching down the context tree using the

1036 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Code Coverage
Setting a Default Coverage Reporting Mode

wildcard. If elements of a net occur multiple times, the list includes them multiple times, once
for each occurrence. 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.

Setting a Default Coverage Reporting Mode

You can specify a default coverage mode that persists from one Questa SIM session to the next.
You can set the default coverage reporting mode through the preference variable
PrefCoverage(DefaultCoverageMode). The available modes enable you to list the data given in
each report by file, design unit, or instance. The default is to list the report by file.

You can also specify a default coverage mode for the current invocation of Questa SIM with the
-setdefault [byfile | byinstance | bydu] argument for either the coverage report or the vcover
report command.

XML Output
You can output coverage reports in XML format.
To produce XML output, check Write XML Format in the Coverage Report dialog, or use 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.

Questa® SIM User's Manual, v2023.4 1037

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

HTML Output
You can output coverage reports in HTML format.
To produce HTML output, check Write HTML Format in the Coverage Report dialog, or use
the -html argument to the coverage report command.

For more information on HTML output reports, see “Generating HTML Coverage Reports”.

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.

1038 Questa® SIM User's Manual, v2023.4

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.
An example of a non-essential construct is code in a procedure that is never called. Non-
essential constructs can include statements, expressions, conditions, branches, and toggles.
Removal of non-essential constructs requires you to consider the trade-offs between aggressive
optimization levels and the ease with which your coverage results can be understood.

While aggressive levels of optimization make the simulation run fast, your results may give you
the mistaken impression that your design is not fully covered because native code is not
generated for all HDL source code. Those fragments of HDL code that do not result in native
code generation are never instrumented for coverage, and do not participate in coverage
collection, measurement, or reporting activities.

You can tell which statements do not participate in coverage activities by looking at the
Statement and Branch Count columns on the left side of the Source window. Completely blank
columns (no numbers or ‘X’ symbols at all) indicate that the associated statements have been
optimized out of the simulation database, and will not participate in coverage activities.

Customizing Optimization Level for Coverage Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039

Interaction of Optimization and Coverage Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Code Coverage and Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040

Customizing Optimization Level for Coverage Runs

It is possible to achieve 100% coverage in an optimized design, even if certain statements or
constructs have been optimized away, because 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. 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, Questa SIM 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.

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.

Questa® SIM User's Manual, v2023.4 1039

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

• To change optimizations applied to a specific run — Set the -coveropt argument to vlog,
vcom, or vopt. For example:
vopt +cover=cbesxf -coveropt 2

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, but
slower performance.
In Questa SIM, 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 to apply to your
design when specifying coverage types for collection.

Code Coverage and Verification IP

Questa SIM performance is affected by code coverage for designs using various IP.
As a result, code coverage is disabled for the following:

• Verilog/SystemVerilog source files, design units, and classes whose names begin with
the following prefixes:
ovm_
uvm_
avm_
urm_
tlm_
sqr_
mgc_
mvc_
ovl_
qvl_
questa_

1040 Questa® SIM User's Manual, v2023.4

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

• Verilog/SystemVerilog packages whose names begin with the following prefix:

mti_

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

Questa® SIM User's Manual, v2023.4 1041

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

1042 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 19
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
FSM Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
FSM Multi-State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Collecting FSM Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Reporting Coverage Metrics for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Viewing FSM Information in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
FSM Coverage Metrics Available in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Advanced Command Arguments for FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Recognized FSM Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
FSM Recognition Info Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
FSM Coverage Text Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061

FSM Recognition
Questa SIM recognizes VHDL and Verilog FSMs.
The FSMs are recognized during compilation or optimization when you are Collecting FSM
Coverage Metrics or Viewing FSM Information in the GUI, and when they fit the following
criteria:

• There is a finite number of states which the state variable can hold.
• The next state assignments to the state variable are made under a clock.
• The next state value depends on the current state value of the state variable.
State assignments that do not depend on the current state value are considered reset
assignments.
Questa SIM recognizes the following VHDL and Verilog FSM design styles:

• FSMs using a current state variable.

Questa® SIM User's Manual, v2023.4 1043

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Recognition

• FSMs using current state and next state variables.

• FSMs using multiple next-state variables, where all are used as a buffer assignment.
• FSMs using fixed, non-floating parameters/generics (only supported when using vopt).
• FSMs using a single or multiple Case statements.
• FSMs using a single or multiple If-Else statements.
• FSMs using mixed If-Else and Case statements.
• FSMs using a VHDL wait/select statement.
• FSMs using a VHDL when/else statement for concurrent assignments only.
• FSMs using complex “if” conditions with AND or OR operators.
• FSMs defined using a one-hot or one-cold style (supported for Verilog only).
• FSMs using next state assignments that can be statically evaluated to constants.
• FSMs using a current- or next-state variable as a VHDL record or SystemVerilog struct
field. Nested structures are not supported.
• FSMs using a current- or next-state variable as a VHDL or Verilog index expression.
• FSMs defined completely inside Verilog tasks.
• FSMs using any integral SystemVerilog types like logic, int, bit_vector, enum, packed
struct. Typedefs of these types are also supported.
• FSMs using multi-field record type in VHDL where the state variable is a field of the
record and the complete record is used for driving the current state in the clocked
process.
• Verilog FSMs having state variable assignment to a 'x (unknown) value. X-assignment
is enabled by default.

Note
Due to module in-lining, FSM's defined across multiple modules may sometimes be
recognized; but this is not guaranteed.

Unsupported FSM Design Styles

Questa SIM does not recognize the following design styles:

• Using Verilog part-select expressions as a current-state variable.

• Using VHDL slice expressions as a current-state variable.

1044 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
FSM Recognition

FSM Design Style Examples

The following examples illustrate several supported FSM design styles.

Example 19-1. Verilog Single-State Variable FSM

module fsm_1proc (output reg out, input [7:0] inp, input clk, en, rst);

typedef enum {s0, s1, s2, s3, s4, s5, s6, s7} state_t;
state_t state;

always_ff @(posedge clk, posedge rst)

if (rst)
state <= s0;
else
casex (state)
s0: begin out <= inp[0]; if (en) state <= s1; end
s1: begin out <= inp[1]; if (en) state <= s2; end
s2: begin out <= inp[2]; if (en) state <= s3; end
s3: begin out <= inp[3]; if (en) state <= s4; end
s4: begin out <= inp[4]; if (en) state <= s5; end
s5: begin out <= inp[4]; if (en) state <= s6; end
s6: begin out <= inp[6]; if (en) state <= s7; end
s7: begin out <= inp[7]; if (en) state <= s0; end
default: begin out <= inp[5]; state <= s1; end
endcase

endmodule

Questa® SIM User's Manual, v2023.4 1045

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Recognition

Example 19-2. VHDL Single-State Variable FSM

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity fsm is port( in1 : in signed(1 downto 0);
in2 : in signed(1 downto 0);
en : in std_logic_vector(1 downto 0);
clk: in std_logic;
reset : in std_logic_vector( 3 downto 0);
out1 : out signed(1 downto 0));
end fsm;

architecture arch of fsm is

type my_enum is (s0 , s1, s2, s3,s4,s5);
type mytype is array (3 downto 0) of std_logic;
signal test : mytype;
signal cst : my_enum;

begin
process(clk,reset)
begin
if(reset(1 downto 0) = "11") then
cst <= s0;
elsif(clk'event and clk = '1') then
case cst is
when s0 => cst <= s1;
when s1 => cst <= s2;
when s2 => cst <= s3;
when others => cst <= s0;
end case;
end if;
end process;
end arch;

1046 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Finite State Machines
FSM Recognition

Example 19-3. Verilog Current-State Variable with a Single Next-State Variable

FSM

module fsm_2proc (output reg out, input [7:0] inp, input clk, en, rst);

typedef enum {s0, s1, s2, s3, s4, s5, s6, s7} state_t;
state_t c_state, n_state;

always_ff @(posedge clk, posedge rst)

if (rst)
c_state <= s0;
else
if (en) c_state <= n_state;

always_comb
casex (c_state)
s0: begin out = inp[0]; n_state = s1; end
s1: begin out = inp[1]; n_state = s2; end
s2: begin out = inp[2]; n_state = s3; end
s3: begin out = inp[3]; n_state = s4; end
s4: begin out = inp[4]; n_state = s5; end
s5: begin out = inp[4]; n_state = s6; end
s6: begin out = inp[6]; n_state = s7; end
s7: begin out = inp[7]; n_state = s0; end
default: begin out = inp[5]; n_state = s1; end
endcase

endmodule

Questa® SIM User's Manual, v2023.4 1047

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
FSM Coverage

Example 19-4. VHDL Current-State Variable and Single Next-State Variable FSM

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use work.pack.all;
entity fsm is port( in1 : in signed(1 downto 0);
in2 : in signed(1 downto 0);
en : in std_logic_vector(1 downto 0);
clk: in std_logic;
reset : in std_logic_vector( 3 downto 0);
out1 : out signed(1 downto 0));
end fsm;

architecture arch of fsm is

type my_enum is (s0 , s1, s2, s3,s4,s5);
type mytype is array (3 downto 0) of std_logic;
signal test : mytype;
signal cst, nst : my_enum;

begin
process(clk,reset)
begin
if(reset(1 downto 0) = "11") then
cst <= s0;
elsif(clk'event and clk = '1') then
cst <= nst;
end if;
end process;

process(cst)
begin
case cst is
when s0 => nst <= s1;
when s1 => nst <= s2;
when s2 => nst <= s3;
when others => nst <= s0;
end case;
end process;
end arch;

FSM Coverage
Questa SIM 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.

1048 Questa® SIM User's Manual, v2023.4

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 (or Sequence coverage) — Tracks the various

possible sequences of transitions that have been exercised in the simulation of the state
machine.
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.
In the coverage domain, using the switch -fsmmultitrans with vcom or vlog or vopt yields a
metric sometimes known as sequence coverage, since it measures the progress of an FSM
through a sequence of states. The FSM recognition messages shows multi-state transitions as:

# S0 => S1 => S0

When you specify -fsmmultitrans, you can view this information in the:

• FSM Recognition Info Note in the transcript, specifically the multi-state transition table.
• FSM Coverage Text Report, specifically the covered transition and uncovered transition
tables.
• Details window.
• Code Coverage Analysis window for FSM.

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 19-1 to determine which are required for
your flow.

Table 19-1. Commands Used for FSM Coverage Collection

Task Command/Switch Required
Enable the collection of FSM coverage vcom or vlog with +cover=f1 Yes2
metrics for individual design units.

Questa® SIM User's Manual, v2023.4 1049

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Finite State Machines
Collecting FSM Coverage Metrics

Table 19-1. Commands Used for FSM Coverage Collection (cont.)

Task Command/Switch Required
Enable the collection of FSM coverage vopt with +cover=f1 Yes2
metrics for the complete design.
Produce a detailed report in the transcript vcom, vlog, or vopt with - No
for each recognized FSM. fsmverbose
Enable the reporting and collection of vcom, vlog, or vopt with - No
coverage metrics for FSM Multi-State fsmmultitrans
Transitions
Enable the reporting and collection of vcom, vlog, or vopt with No
coverage metrics for same state transitions. -fsmsamestatetrans
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 vlogor vopt.

2. Compile your design units with vcom or vlog.

Include any switches from Table 19-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 19-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
• The vcom and vlog and vopt commands produce messages related to any recognized
FSMs. Refer to the sections “Recognized FSM Note” and “FSM Recognition Info Note”
for more information.
• The vsim command loads the simulation and changes the GUI layout to Coverage mode.
• Several of the GUI windows will contain coverage metrics; refer to the section “FSM
Coverage Metrics Available in the GUI”.
Examples
• Enable FSM coverage on the complete design.

1050 Questa® SIM User's Manual, v2023.4

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

vcom a.vhdl b.vhdl

vcom top.vhdl
vopt +cover=f top -o opt_top
vsim -coverage opt_top
run -all

• Enable coverage for all types on the complete design.

vlog *.v
vopt +cover top -o opt_top
vsim -coverage opt_top
run -all

• Enable FSM coverage, including mutli-state transitions, on the complete design with
verbose reporting.
vcom top.vhdl
vcom a.vhdl b.vhdl
vopt +cover=f -fsmverbose -fsmmultitrans top -o opt_top
vsim -coverage opt_top
run -all

• Enable FSM coverage only on selected design units.

vlog +cover=f a.v b.v
vlog top.v
vopt top -o opt_top
vsim -coverage opt_top
run -all

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 enables you to
reach 100% FSM coverage. Refer to the section “FSM Coverage Exclusions” for more
information.

Questa® SIM User's Manual, v2023.4 1051

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

1052 Questa® SIM User's Manual, v2023.4

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

Prerequisites
• Invoke Questa SIM in GUI mode.
Procedure
1. Evaluate the commands and switches in Table 19-2 to determine which are required for
your flow.

Table 19-2. Commands Used to Capture FSM Debug Information

Task Comman R
d/Switch e
q
u
i
r
e
d
Retain visibility of and vopt with Y
capture debugging +acc=f1 e
information about FSMs s
for the complete design.
Enable visualization of vsim with Y
FSMs in the GUI. - e
fsmdebug s
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 19-1 in addition to other switches required for your
design and environment.
3. Optimize your design with vopt.
Include any switches from Table 19-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.

Questa® SIM User's Manual, v2023.4 1053

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

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 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 the FSM Viewer and Wave windows simultaneously.
10. Link the FSM Viewer window to the cursor of the Wave window:
a. Select FSM View > Track Wave Cursor
b. Move the cursor in the wave window to view how states change. Either drag the
cursor left and right, or use the Find Previous/Next Transition buttons in the Wave
Cursor toolbar.
Green indicates current state for the cursor location, and yellow indicates the
previous state.
Related Topics
FSM Recognition

FSM Coverage Metrics Available in the GUI

The GUI presents coverage metrics in several windows within the GUI. This section describes
the windows and the metrics they display.
• Code Coverage Analysis window for FSMs — Select FSM from the drop down menu
in the Code Coverage Analysis window. This window lists states and transition
coverage for FSMs.
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.)

1054 Questa® SIM User's Manual, v2023.4

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

The Code Coverage Analysis window for FSMs is linked to several other windows:
o When you double-click a state or transition, the FSM opens in an FSM Viewer
window.
o When you select a state or transition, it is highlighted in the Coverage Details
window.
o When you select the source line number for the transition, a Source window opens
and displays the line number you have selected.
• Coverage Details window — Provides detailed coverage information about any FSM
item selected in the Code Coverage Analysis window for FSMs.
• Columned windows — Provide FSM coverage metrics in the Structure, Files, Objects
and Instance Coverage windows, as indicated in Table 19-3.

Table 19-3. FSM Coverage Columns

Colu St F O Inst Information
mn ru il b anc
ct e j e
ur s e Co
e Wc ver
Wi i ts age
nd n W Wi
ow d i ndo
o n w
w d
o
w
State X X X state hits divided by
% states
State X X X displays a green bar
Grap when 90% or greater,
h a yellow bar when 50-
90%, and a red bar
when less than 50%
State X X X X
s Hit
State X X X
s
Miss
ed
State X X X
s

Questa® SIM User's Manual, v2023.4 1055

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 19-3. FSM Coverage Columns (cont.)

Colu St F O Inst Information
mn ru il b anc
ct e j e
ur s e Co
e Wc ver
Wi i ts age
nd n W Wi
ow d i ndo
o n w
w d
o
w
Tran X X X transition hits divided
sitio by transitions
n%
Tran X X X displays a green bar
sitio when 90% or greater,
n otherwise the bar is
Grap red
h
Tran X X X
sitio
ns
Hit
Tran X X X
sitio
ns
Miss
ed
Tran X X
sitio
ns

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.

1056 Questa® SIM User's Manual, v2023.4

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 19-4 lists Questa SIM command arguments related to FSM recognition and their
consolidated syntax literals.
Table 19-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 19-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

Questa® SIM User's Manual, v2023.4 1057

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 19-5 defines the replaceable values from the Recognized FSM note.
Table 19-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".

1058 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1059

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

1060 Questa® SIM User's Manual, v2023.4

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 instance with details
=========================================================================
=========== Instance: /test_sm/sm_seq0/sm_0
=== Design Unit: work.sm
=========================================================================
========
FSM Coverage:
Enabled Coverage Bins Hits Misses Coverage
---------------- ---- ---- ------ --------
FSM States 11 10 1 90.90%
FSM Transitions 20 12 8 60.00%
...
...

See Example section for more detailed example of the file.

Parameters
• The FSM Coverage Report contains the following sections:
o Header — Specifies whether the report was generated by file (-srcfile), instance
(-instance), or design unit (-du).
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 Uncovered States — A list of all states that have no coverage metrics.
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
The following example shows an FSM coverage report reporting the metrics by instance.

Questa® SIM User's Manual, v2023.4 1061

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 for instance /test_sm/sm_seq0/sm_0 --

FSM_ID: state
Current State Object : state
----------------------
State Value MapInfo :
---------------------
Line State Name Value
---- ---------- -----
59 IDLE 1
92 RD_WD_1 512
82 WT_BLK_1 16
78 WT_WD_1 4
76 CTRL 2
80 WT_WD_2 8
84 WT_BLK_2 32
86 WT_BLK_3 64
88 WT_BLK_4 128
90 WT_BLK_5 256
94 RD_WD_2 1024
Covered States :
----------------
State Hit_count
----- ---------
IDLE 15625
RD_WD_1 9372
WT_BLK_1 1563
WT_WD_1 3126
WT_WD_2 3126
WT_BLK_2 1563
WT_BLK_3 1563
WT_BLK_4 1563
WT_BLK_5 1562
RD_WD_2 9372
Covered Transitions :
---------------------
Line Trans_ID Hit_count Transition
---- -------- --------- ----------
70 0 9372 IDLE -> RD_WD_1
68 1 1563 IDLE -> WT_BLK_1
66 2 3126 IDLE -> WT_WD_1
93 4 9372 RD_WD_1 -> RD_WD_2
83 6 1563 WT_BLK_1 -> WT_BLK_2
79 8 3126 WT_WD_1 -> WT_WD_2
81 11 3126 WT_WD_2 -> IDLE
85 12 1563 WT_BLK_2 -> WT_BLK_3
87 14 1563 WT_BLK_3 -> WT_BLK_4
89 16 1562 WT_BLK_4 -> WT_BLK_5
91 18 1562 WT_BLK_5 -> IDLE
95 19 9372 RD_WD_2 -> IDLE
Uncovered States :
------------------
State
-----
CTRL
Uncovered Transitions :
-----------------------
Line Trans_ID Transition
---- -------- ----------

1062 Questa® SIM User's Manual, v2023.4

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

64 3 IDLE -> CTRL

51 5 RD_WD_1 -> IDLE
51 7 WT_BLK_1 -> IDLE
51 9 WT_WD_1 -> IDLE
77 10 CTRL -> IDLE
51 13 WT_BLK_2 -> IDLE
51 15 WT_BLK_3 -> IDLE
51 17 WT_BLK_4 -> IDLE
Summary Bins Hits Misses Coverage
------- ---- ---- ------ --------
FSM States 11 10 1 90.90%
FSM Transitions 20 12 8 60.00%

Questa® SIM User's Manual, v2023.4 1063

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

1064 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 20
Verification with Assertions and Cover
Directives

This chapter discusses methods for using VHDL, PSL, and SystemVerilog assertions and cover
directives for design verification with Questa SIM. It is organized into four sections.
Questa SIM 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.

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

Questa SIM supports the Questa Verification IP verification components.

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-2017 for SystemVerilog.

Overview of Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066

Using PSL Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Using SVA Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Using -assertdebug to Debug with Assertions and Cover Directives . . . . . . . . . . . . . . . 1125

Questa® SIM User's Manual, v2023.4 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
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. Questa SIM
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.

Assertion Coding Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067

Processing Assume Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Configuring Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Simulating Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Analyzing Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089

1066 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 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
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.

1068 Questa® SIM User's Manual, v2023.4

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;

Questa® SIM User's Manual, v2023.4 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
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.
Using Assert Directive Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
SystemVerilog Bind Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071

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

1070 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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 Questa SIM 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,
Questa SIM simulates assume directives as if they are assert directives and displays them in the
Assertions window.
You can configure how Questa SIM processes assume directives using the -assume and
-noassume switches for the vsim command or the SimulateAssumeDirectives var
SimulateAssumeDirectives variable in the modelsim.ini file.

Questa® SIM User's Manual, v2023.4 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
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 20-2).

Figure 20-2. Configure Assertions Dialog

1072 Questa® SIM User's Manual, v2023.4

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

Enabling Memory and Performance Profiling Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Configuring Message Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Setting Break Severity for Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Enabling/Disabling Assertion Failure and Pass Logging . . . . . . . . . . . . . . . . . . . . . . . . . 1076
Setting Assertion Failure Limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Setting Assertion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Changing the Default Configuration of Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . 1079
Other Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081

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 20-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 20-3). The selection
acts as a toggle.
Figure 20-3. Assertion Enable Menu Selection

Questa® SIM User's Manual, v2023.4 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
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 20-4).
Figure 20-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.

1074 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 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
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 20-5) and click
OK.
Figure 20-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 20-6) and click OK.
Figure 20-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.

1076 Questa® SIM User's Manual, v2023.4

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
Do any one of the following to enable or disable assertion failure and pass logging.

• 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 20-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 20-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 Questa SIM 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.

Questa® SIM User's Manual, v2023.4 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
Configuring Assertions

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.
• 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 20-8).
Figure 20-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.
Questa SIM 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.
Questa SIM 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 Questa SIM prompt.

1078 Questa® SIM User's Manual, v2023.4

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

• Exit — Halt simulation and exit Questa SIM.

• TCL — Execute designated tcl subroutine.
You can set the assertion action with the assertion action command or in the GUI.

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

Questa® SIM User's Manual, v2023.4 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
Configuring Assertions

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.
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 20-10).
Figure 20-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.

1080 Questa® SIM User's Manual, v2023.4

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

Choosing AtLeast Counts for Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Limiting Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082

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.

Questa® SIM User's Manual, v2023.4 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
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 20-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.

1082 Questa® SIM User's Manual, v2023.4

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

The -nopsl and -nosva arguments will remove assertions from the design. Therefore, any
$asserton/$assertoff statement including these assertions will have no effect in this case

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

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 and -noasssertcounts arguments were formerly named -assertcover
and -noassertcover. The -assertcover and -noassertcover arguments are deprecated and will
result in an error.

The specific actions counted depends on whether the simulation is run with the -assertcounts or
the -assertdebug argument for vsim or without either option.

Questa® SIM User's Manual, v2023.4 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
Simulating Assertions

For example, consider the following SystemVerilog assertion:

assert property (@(posedge clk) disable iff (ignore) (b0 |=> b1 ##1 b2 ##1 b3));

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

Figure 20-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 20-12. The assertion failures are indicated in the Wave
window by red triangles.

1084 Questa® SIM User's Manual, v2023.4

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 20-12. Assertion Failures Indicated by Red Triangles

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

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

Questa® SIM User's Manual, v2023.4 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
Simulating Assertions

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 20-14).
Figure 20-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 20-15.

1086 Questa® SIM User's Manual, v2023.4

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 20-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
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 20-13).

Questa® SIM User's Manual, v2023.4 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
Simulating Assertions

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

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.

1088 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Viewing Cover Directives in the Cover Directives Window . . . . . . . . . . . . . . . . . . . . . . 1090
Viewing Memory Profile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Viewing Assertions and Cover Directives in the Wave Window. . . . . . . . . . . . . . . . . . . 1092
Utilizing GUI Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Comparing Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Saving Metrics to the UCDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
Excluding Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Creating Assertion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102

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

Questa® SIM User's Manual, v2023.4 1089

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 20-18).
Figure 20-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 20-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.

1090 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1091

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 .

1092 Questa® SIM User's Manual, v2023.4

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. Questa SIM represents assertions and cover directives as signals or waveforms in the
Wave window. The Wave window in Figure 20-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 20-20. SystemVerilog Assert and Cover Directives in the Wave Window

3. The Wave window in Figure 20-21 shows several PSL assertions and cover directives.
PSL assertions are represented by magenta triangles. PSL cover directives are
represented by magenta chevrons.

Questa® SIM User's Manual, v2023.4 1093

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

1094 Questa® SIM User's Manual, v2023.4

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 20-22. Antecedent Matches Indicated by Yellow Triangle

8. Table 20-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 20-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

Questa® SIM User's Manual, v2023.4 1095

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

Questa SIM provides a number of GUI display options for viewing assertions and cover
directives data.
Assertions Window Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Display Options for Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
Filtering Data in the Assertions and Cover Directives Window . . . . . . . . . . . . . . . . . . . 1097
Displaying Cover Directives in Count Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097

Assertions Window Display Options

The Assertions window can display assertion directives in hierarchical (tree) mode or in the
flattened form.
Figure 20-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

1096 Questa® SIM User's Manual, v2023.4

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 20-24. Viewing Cover Directive Waveforms in Count Mode

Questa® SIM User's Manual, v2023.4 1097

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.

1098 Questa® SIM User's Manual, v2023.4

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
Questa SIM’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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099

Two Types of Assertion Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
Child Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100

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\

Questa® SIM User's Manual, v2023.4 1099

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.

1100 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1101

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Specifying an Alternative Output File for Assertion Messages . . . . . . . . . . . . . . . . . . . . 1103

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 20-25).
2. Select the options you want to report.
3. Click the OK button.
Figure 20-25. Assertions Report Dialog

1102 Questa® SIM User's Manual, v2023.4

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 Questa SIM implementation
will increment the count twice.

Questa® SIM User's Manual, v2023.4 1103

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

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

1104 Questa® SIM User's Manual, v2023.4

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

Common PSL Assertions Coding Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
Compiling and Simulating PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
PSL Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120

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.

Questa® SIM User's Manual, v2023.4 1105

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
HDL Code Inside PSL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Writing PSL Assertions in an External File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Sharing a Single .psl File Between VHDL and Verilog Models. . . . . . . . . . . . . . . . . . . . 1112
Inserting VHDL library and use Clauses in External PSL Assertion Files . . . . . . . . . . 1112
PSL Clocked and Unclocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Using PSL ended() in HDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115

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.

1106 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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 Questa SIM’s PSL
support was based. Support of the endpoint construct will be maintained in Questa SIM.

Examples
Example 11-1 shows how embedded assertions should appear in your code.

Questa® SIM User's Manual, v2023.4 1107

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

1108 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1109

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.

1110 Questa® SIM User's Manual, v2023.4

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 20-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;
}

Questa® SIM User's Manual, v2023.4 1111

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 Questa SIM 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, Questa SIM will ignore the first vunit and parse the second:

Internally Questa SIM 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, Questa SIM 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.

1112 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1113

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 Questa SIM may be clocked or unclocked.
PSL Unclocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Default Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
PSL Partially Clocked Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
PSL Multi-Clocked Properties and the Default Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115

PSL Unclocked Properties

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

1114 Questa® SIM User's Manual, v2023.4

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, Questa SIM 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 Questa SIM 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 Questa SIM’s PSL support was based. Support
of the endpoint construct will be maintained in Questa SIM.

Questa® SIM User's Manual, v2023.4 1115

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 20-3 and Example 20-4 are two complete examples that demonstrate the use of
ended() in Verilog and VHDL code, respectively.

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

1116 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1117

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.

1118 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Compiling an External PSL Assertions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Applying PSL Assertions During Elaboration/Optimization . . . . . . . . . . . . . . . . . . . . . 1119
Making Changes to PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120

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.

Questa® SIM User's Manual, v2023.4 1119

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
Questa SIM 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).

1120 Questa® SIM User's Manual, v2023.4

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 concepts are important for understanding how to use SVA assertions and cover
directives.
Assertions and Action Blocks in SVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Deferred Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
SystemVerilog Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
SVA Usage Flow for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122

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

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

Questa® SIM User's Manual, v2023.4 1121

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
Questa SIM 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 20-27 shows the use of SystemVerilog assertions in the debug flow.

1122 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1123

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.

1124 Questa® SIM User's Manual, v2023.4

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 Questa SIM to
examine all assertions and display assertion details in the Assertions window.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

Viewing Debugging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125

Enabling ATV Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126
Enabling and Disabling ATV Recording During Simulation . . . . . . . . . . . . . . . . . . . . . 1127
Saving Assertion and Cover Directive Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Analyzing Assertion Failures in the Assertion Debug Pane of the Wave Window . . . . 1130
Using the Assertion Active Thread Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Viewing Assertion Threads in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132
Navigating Inside an ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Actions in the ATV Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141

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 20-28).
Figure 20-28. Enable Assertion Debug

Questa® SIM User's Manual, v2023.4 1125

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 are displayed in the transcript and
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.

1126 Questa® SIM User's Manual, v2023.4

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 20-29).
Figure 20-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.

Questa® SIM User's Manual, v2023.4 1127

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

1128 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1129

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),
• the Verification Management Tracker window when linked to from a Verification
Plan item (see Viewing Test Data in the Tracker Window in the Verification
Management User’s Manual),
• 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.

1130 Questa® SIM User's Manual, v2023.4

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 20-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.
Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1131

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

1132 Questa® SIM User's Manual, v2023.4

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 20-32).
Selecting (or typing) an entry will bring up the ATV view for that particular instance
and starting time.
Figure 20-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 20-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

Questa® SIM User's Manual, v2023.4 1133

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 20-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 20-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 20-34).

Note
If the sub-menu of evaluation attempt start times is empty, ATV recording has
not been enabled.

1134 Questa® SIM User's Manual, v2023.4

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 20-34. Opening ATV from the Message Viewer Window

Questa® SIM User's Manual, v2023.4 1135

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 20-35. ATV Panes - SystemVerilog

Expression Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137

Thread Viewer Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Local Variables Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138
Design Objects Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139

1136 Questa® SIM User's Manual, v2023.4

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 20-36).

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

Questa® SIM User's Manual, v2023.4 1137

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 20-37).

1138 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1139

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.

1140 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Viewing Multiple Clock Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Expanding and Contracting Expression Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Highlighting a Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Hovering the Mouse for Thread and Directive Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Annotating Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146

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 20-38).

Figure 20-38. View Thread at 150 ns

This opens the ATV window for the assertion, as shown in Figure 20-39.

Questa® SIM User's Manual, v2023.4 1141

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 20-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 20-40). All clock
symbols in the Thread Viewer Pane align with the appropriate clock expression in the
Expression Pane.

1142 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1143

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 20-41, will highlight the path from the start thread to the failed
thread.

Figure 20-41. Root Thread Analysis of a Directive Failure

In Figure 20-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.

1144 Questa® SIM User's Manual, v2023.4

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 20-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 20-43, the cursor hovers over a hollow green circle and the status indicates “Passed
but directive waiting on other running threads.”

Figure 20-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 20-43).

Questa® SIM User's Manual, v2023.4 1145

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

Figure 20-45. Local Variables Annotation in Thread Viewer Pane

1146 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 21
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. 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.

Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148

Functional Coverage Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Functional Coverage Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Functional Coverage Statistics in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
Reporting on Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Assertion/Cover Directive Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
Covergroup Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
Saving Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180

Questa® SIM User's Manual, v2023.4 1147

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

Functional Coverage Flow

The SystemVerilog functional coverage flow in Questa SIM is broken down into three main
steps: compilation of design files, simulation, and data analysis.
Figure 21-1. SystemVerilog Functional Coverage Flow

Questa SIM 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. After running a simulation, you may optionally
view coverage interactively in the GUI with commands such as coverage report. You may also
save coverage data to the (UCDB) with the coverage save command, which facilitates
reporting, merging, and ranking coverage data, as well as other types of verification analysis.

1148 Questa® SIM User's Manual, v2023.4

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 set of facilities for configuring covergroups, coverpoints, and crosses
through the option and type_option structures. These structures can be used to control various
aspects of SystemVerilog simulations, using guidelines which apply to each of the settings.
Guidelines for Functional Coverage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Controlling Functional Coverage Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149

Guidelines for Functional Coverage Control

Control functional coverage behavior in Questa SIM with the change command from the
command line interface, or from within a .do file, to adjust the value of variables contained in
option and type_option structures.
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

Questa SIM 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 any of these methods:
• 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 21-2).
• Simulating with vsim -cvgzwnocollect enabled, when option.weight is set to 0 within
the source code (see also the SVCovergroupZWNoCollect modelsim.ini variable) 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. An svverification license
is not required when -nocvg is used in the simulation.

Questa® SIM User's Manual, v2023.4 1149

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

To print a report of functional coverage items which have been actively selected for non-
collection, use -nocollect with the coverage report or vcover report commands.

Figure 21-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 type_option.merge_instances=1. You can choose from among three possibilities when
specifying how merge_instances are set in a given covergroup type:

• set to 0 in the SystemVerilog code — aggregated bins do not exist for this algorithm
choice.
• set to 1 in the SystemVerilog code — aggregated bins do exist.
• not set — in this case, the Questa SIM 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 same behavior can be achieved using the modelsim.ini variable
SVCovergroupMergeInstancesDefault. For more information and some examples of
SystemVerilog code containing these options, see “IEEE Std 1800-2009 Option Behavior.”

Controlling Optimization with a UCDB File

You can load a functional coverage database (UCDB file) into your simulation and use it to
control optimization by using the -cvgprecollect argument with the vsim command.

When a coverpoint, cross, or covergroup instance is pre-covered in the input UCDB—namely

the coverage score is 100%—the presence of the -cvgprecollect argument instructs the
simulator to disable the matching instance in the new simulation. When the optimization is
enabled for an instance, the instance is removed from the simulation, therefore no coverage data
is collected or saved into the UCDB.

Optimization is not always possible. For example, if a coverpoint participates in a cross, it

cannot be disabled, because sampling the cross may require sampling the coverpoint. In such
cases, the coverpoint, cross, or covergroup instance will be handled as in a normal simulation.

1150 Questa® SIM User's Manual, v2023.4

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 Questa SIM.
Predefined Coverage Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Predefined Coverage System Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
SystemVerilog Functional Coverage Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
IEEE Std 1800-2009 Option Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Type-Based Coverage With Constructor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157

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. Both 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-2017
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. The variable type_option.weight at the covergroup scope
is used to weight the contribution an individual covergroup makes 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-2017 LRM, Section 19.11.

SystemVerilog Functional Coverage Terminology

The LRM refers to cumulative coverage and type coverage as the same thing; this document
uses the term type-based coverage. The LRM sometimes uses coverage and instance coverage
interchangeably; this document uses instance-based coverage.

Questa® SIM User's Manual, v2023.4 1151

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 is compliant with
changes made to the latest IEEE Std 1800-2009 and later revisions.
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 21-1:
Table 21-1. Questa SIM and SystemVerilog IEEE 1800-2009 Options
1800-2009 Option Default in Questa
option.per_instance 0 - instance data is reported
type_option.merge_instances Refer to “System Verilog 2009
type_option.merge_instances.”
option.get_inst_coverage 0 - only valid when merge_instances is
set (1). Both get_inst_coverage and
get_coverage return the same merged
coverage result

Example of Option Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152

SystemVerilog 2009 option.per_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
SystemVerilog 2009 type_option.merge_instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
SystemVerilog 2009 option.get_inst_coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155
Legacy Behavior and Option Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156

Example of Option Settings

The example code shown below demonstrate how options are set.
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

1152 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 1153

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

1154 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 21-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 21-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 21-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.

Questa® SIM User's Manual, v2023.4 1155

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

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 21-1 on “Questa SIM and
SystemVerilog IEEE 1800-2009 Options.”

Related Topics
Functional Coverage Computation

1156 Questa® SIM User's Manual, v2023.4

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
By default, Questa SIM provides type-based coverage with constructor parameters.
Default Type-Based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Projected Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1160
Testplan Linking and the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162

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 that are parameterized when they are constructed carry additional 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 21-2:

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

Questa® SIM User's Manual, v2023.4 1157

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 with the -details argument:

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

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.

• cgvar 1_2 has the set of bins{ b[1], b[2] }

• cgvar 1_3 has the set of bins { b[1], b[3] }
• The union of cgvar 1_2 & 1_3 has the set of bins { b[1], b[2], b[3] }
• The set of bins actually covered is { b[1], b[3] }
As a result, type-based coverage is 2 / 3 = 66.66%.

Bin Unions by Name

In Example 21-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?

The Questa SIM 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 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

1158 Questa® SIM User's Manual, v2023.4

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

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

The first two examples clearly declare bins a, b[1], b[2], and b[3]. But what of the bins specified
with identifier “c?” Questa SIM 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 21-2 with an explicit size constant in the bin declaration, as shown in
Example 21-3:

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

Questa® SIM User's Manual, v2023.4 1159

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
You can write covergroups in template classes, resulting in each parameterized class instance of
a template class creating separate covergroup type scopes. However, this leads to low coverage
of those covergroup type scopes, due to the fact that parameterized class instances are
specifically optimized though their covergroups, and are still general. As such, it is not possible
to cover all parts of a general covergroup residing under a specifically parameterized class.
To improve the coverage of those covergroup type scopes, you can use the 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, this 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 uses the coverage of that virtual covergroup type scope instead of the original
covergroup type scopes.

1160 Questa® SIM User's Manual, v2023.4

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

Use the covergroup option parameter_projection_name within the source code to specify a
virtual scope name for the covergroup instance being projected.

The option parameter_projection_name is the key to 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 which you specify within the
covergroup declaration, and cannot be changed after instantiation. You cannot include a
covergroup instance in a virtual scope unless you specify the
option.parameter_projection_name for the covergroup instance.

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

Virtual covergroups behave differently than real covergroups with respect to reporting and a
number of coverage operations.

• Appearance and Coverage in Text and HTML Reports —The coverage of virtually
created covergroup type scopes under template class objects is used in calculating
coverage. 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 not taken into account when calculating coverage.
• Appearance in Covergroups Window — Like the coverage report, the Covergroups
window displays the projected view. It displays virtual 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.
• Diff Utility Usage — The diff operation works 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.

Questa® SIM User's Manual, v2023.4 1161

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

• Project Covergroups and Ranktest Operation — The coverage and vcover ranktest
operations rank tests based on coverage numbers, so they work on projected views. This
is because the projection operation is done before computing coverage numbers, which
are used in comparing tests for ranking.
• Projected Covergroups and Coverage Exclude — The scope paths in a coverage exclude
command use the path to a projected covergroup location instead of an 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.

Testplan Linking and the Tracker Window

The testplan specification uses the projected view for specifying paths in the Link column for
linking a testplan to any projected covergroup item (covergroup type, covergroup instance,
coverpoint type, coverpoint instance, cross type, cross instance, or bin).
In order to successfully link testplan items with projected covergroup items, use the path
displayed in the coverage report or in the GUI windows.

The Covergroup Browser window displays projected linked covergroup items using their
projected full names. If the item is created virtually due to projection, the item is then displayed
using the color of a virtual signal.

1162 Questa® SIM User's Manual, v2023.4

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

Functional Coverage Aggregation in Structure Window . . . . . . . . . . . . . . . . . . . . . . . . 1164

Viewing Functional Coverage Statistics in the

Covergroups Window
You can view functional coverage statistics in the Covergroups window to evaluate assess the
state of the verification process.
Procedure
1. Select View > Coverage > Covergroupsfrom the Main window menu bar.
2. Run the simulation. (Covergroups are not displayed in the Covergroups window until
you run the simulation.)
Figure 21-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.

Questa® SIM User's Manual, v2023.4 1163

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

1164 Questa® SIM User's Manual, v2023.4

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 by
entering commands at the command line prompt.
Creating Text Reports Via the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
Creating HTML Reports Via the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Covergroup Bin Reporting and Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Filtering Functional Coverage Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Reporting Via the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Excluding Functional Coverage from the GUI and Reports . . . . . . . . . . . . . . . . . . . . . . 1173

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 21-4).

Questa® SIM User's Manual, v2023.4 1165

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

1166 Questa® SIM User's Manual, v2023.4

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 will be the secondary data
type. Thus, all zero values in covergroup A will 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 argument for the vsim command enables Questa SIM 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.

• The simulation saves timestamp values and test names, with each covergroup bin, to the
UCDB file.
• 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) 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, 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.

Questa® SIM User's Manual, v2023.4 1167

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 change the coveritem goal in the database after it has been
saved—for example, by modifying the UCDB using the coverage edit command—
and automatically inferring 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
Reporting on Functional Coverage

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 > Setupor
Assertions > Filter > Setup). This opens the Filter Setup dialog box(Figure 21-5).
Figure 21-5. Filter Setup Dialog Box

2. To create a new filter, click the Create button to open the Create Filter dialog
box(Figure 21-6).

1168 Questa® SIM User's Manual, v2023.4

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 21-6. Create Filter Dialog Box

The Edit Filter dialog box—which you open by clicking the Edit button in the Filter
Setup dialog box—contains all of the same functions as the Create Filter dialog box.
3. Click the Add button to add criteria, attributes, operators, and values to the filter in the
Add/Modify Select Criteria dialog box(Figure 21-7).
Figure 21-7. Add-Modify Select Criteria Dialog Box

The Criterion field includes a dropdown list that corresponds to the columns in the
Assertions, Cover Directives, and Covergroups windows, 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 box, which opens the Copy Filter dialog box. Or, you
can rename a filter by clicking the Rename button and opening the Rename Filter dialog
box.

Questa® SIM User's Manual, v2023.4 1169

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

Figure 21-8. Copy and Rename Filter Dialog Boxes

The filter you just created appears in the Filters list within the Filter Setup dialog box
(Figure 21-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 flat or hierarchical 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.

1170 Questa® SIM User's Manual, v2023.4

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

Figure 21-9. Sample Output From vcover report Command

You can use the -hierarchical argument with the vcover report command to produce hierarchical
text output similar to what is displayed in the GUI. You can use the -hierarchical argument
along with -instance, for instance hierarchy, or -du, for design unit hierarchy. The examples
below illustrate both types of report.

Figure 21-10 shows sample output of a hierarchical text report organized by instance.

vcover report -instance=/*. -hierarchical

Questa® SIM User's Manual, v2023.4 1171

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

Figure 21-10. Hierarchical Instance Text Report

Figure 21-11 shows sample output of a hierarchical text report organized by design unit.

vcover report -du=* -hierarchical

Figure 21-11. Hierarchical Design Unit Text Report

By default, these reports include 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.

1172 Questa® SIM User's Manual, v2023.4

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 coveragte 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 is an assertion and d a cover directive.

Sample Commands for Excluding Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 1173

Transitive Cross Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Hiding Covergroup Instances from GUI and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175

Sample Commands for Excluding Functional Coverage

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

Questa® SIM User's Manual, v2023.4 1173

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

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 given 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 continues to propagate the exclusion hierarchically into crosses where
those crosses participate; this recursive behavior continues until all associated crosses of crosses
are excluded.

If you exclude a whole coverpoint or cross, 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:

coverage exclude -cvgpath /top/cvg/i1/y -transitive

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.

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.

1174 Questa® SIM User's Manual, v2023.4

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

coverage exclude -cvgpath /top/cvg/i1/x_y/<b2,c1> -transitive

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 it contains some cross products that are not related to the excluding
coverpoint or cross bin. For simplicity, if all the cross products of a 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, assume a cross 'cx' has three coverpoints cvp1, cvp2, cvp3; each of which has two
coverpoint bins: (a1, a2), (b1, b2), and (c1, c2), respectively. What happens when a user cross
bin 'x1' selects 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, because the cross product <a2,b2,c2> is still active; excluding 'x1' may
cover up a hole for that active cross product.

Now, if the bin a2 is also excluded then logically both cross products are excluded transitively.
It follows that the userbin 'x1' should logically be excluded too, however it is not. The tool does
not keep track of exclusions for each cross product due to performance and capacity reasons, so
it would be necessary 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. All 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. Therefore 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 argument is not supported with the -clear argument.

Hiding Covergroup Instances from GUI and Reports

While 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>
Command Line: coverage report or vcover report -hidecvginsts

Questa® SIM User's Manual, v2023.4 1175

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

• 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 Questa SIM reports and
coverage windows, as well as for restoring in simulation with $load_coverage_db().
Questa SIM 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

1176 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177

Canonical String Representation for Coverpoint Bin Value . . . . . . . . . . . . . . . . . . . . . . 1178

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

Questa® SIM User's Manual, v2023.4 1177

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

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.
To ensure unique identification, Questa SIM 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.

1178 Questa® SIM User's Manual, v2023.4

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

• 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 21-3:
Table 21-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. The base value of the
enum constant is not used to derive the bin name,
but is stored in the coverage database by Questa
and reported by the Questa analysis tools.
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 in a Class

Questa® SIM User's Manual, v2023.4 1179

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.
Saving For All Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Saving For The Current Simulation Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Loading a Functional Coverage Database into Simulation . . . . . . . . . . . . . . . . . . . . . . . 1182
Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183

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 Savefrom 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
• execution of explicit $finish in Verilog
• execution of an implicit $finish

1180 Questa® SIM User's Manual, v2023.4

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 $stop
• execution of sc_stop()
• a fatal error

Questa® SIM User's Manual, v2023.4 1181

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

1182 Questa® SIM User's Manual, v2023.4

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, Questa SIM
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 an error message will be 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.

Questa® SIM User's Manual, v2023.4 1183

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

1184 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 22
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.
Questa SIM then processes these constraints using a constraint solver, which generates random
values that meet those constraints. Constraint solver profiling allows you to see how much time
is spent in which constraints, and which are the most expensive constraints to solve. It also
profiles CPU time spent in “Regions” of the solver as opposed to every function call.
Note
The functionality described in this chapter requires an additional license feature. Contact
your Siemens EDA sales representative.

Verification Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185

Constraint Solver Engines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186
Building Constrained Random Test Benches on SystemVerilog Classes . . . . . . . . . . . . 1187
Random Number Generator (RNG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
Const Cast Expression Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226
Solver Record and Replay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Solver Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230

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

Questa® SIM User's Manual, v2023.4 1185

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Constraint Solver Engines

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.

Constraint Solver Engines

The default constraint solver engine is “AUTO”, which instructs Questa SIM to attempt to
select the best solver engine for a randomize() scenario based on the mix of random variables
and constraints.
Note
For constrained random stimulus, random results for a given seed are consistent across all
platforms and variants of platforms.

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

1186 Questa® SIM User's Manual, v2023.4

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

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

Questa SIM 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() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188

Attributes Of Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Inheriting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Constraint Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
Examining Solver Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194

Questa® SIM User's Manual, v2023.4 1187

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

Enabling Solver Profiling and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195

Setting Compatibility with a Previous Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195

Generating New Random Values with randomize()

To generate new random values, you use the randomize() virtual method.
Example 22-2 shows how to use this method to generate random values for the bus example in
Example 22-1.

Example 22-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 22-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 solver may
display a constraint contradiction report (if SolveFailDebug is set to a non-zero value), and the
“Randomization FAILED” error message is displayed.

Note
If Questa SIM cannot acquire the proper license to execute the call to randomize(), it will
display a fatal error message.

1188 Questa® SIM User's Manual, v2023.4

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 22-1 lists the attributes available for use with randomize(), along with the corresponding
modelsim.ini variable.
Table 22-1. Attributes Usable with randomize()
Attribute Variable in Description
modelsim.ini
solvearrayresizemax=<integer> SolveArrayResizeMax Specifies maximum size
randomize() will allow a
dynamic array to be resized.
solveengine=<string> SolveEngine Specifies which solver engine
to use when evaluating
randomize calls.
solvefaildebug=<integer> SolveFailDebug Enables debugging of
SystemVerilog randomize()
failures.
solvefailseverity=<integer> SolveFailSeverity Defines the severity of
messages when randomize
call fails.
solveinfo=<string> None. Enable and specifies solver
debug output options for
randomize() calls.
solvetimeout=<integer> **SolveTimeout Specifies the solver timeout
threshold (in seconds). A
randomize() call will fail if the
CPU time required to evaluate
any randset exceeds the
specified timeout.

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.

Questa® SIM User's Manual, v2023.4 1189

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

Examples:

assert(randomize (* solvearrayresizemax = 100 *) (a, b) with { a > b; });

assert(randomize (* solvearrayresizemax = 100 *) (* solveactmaxtests =

50000 *) (a, b) with { a > b; });

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

Contradicting constraints, such as x > 5 and x < 3, causes the randomize() function to fail (the
return value of the function is 0). When a randomize () failure occurs due to contradicting
constraints and if the SolveFailSeverity and SolveFailDebug modelsim.ini variables are set to
non-zero values, Questa SIM generates a constraint contradiction report for randomize() calls
that fail due to having no solutions. This report enables debugging of randomize() failures.
Procedure
The SolveFailDebug simulator control variable controls whether or not the constraint
contradiction report is generated when randomize() fails due to contradicting constraints. By
default, “basic” debug is enabled (SolveFailDebug = 1). Basic debug allows you to generate a
simplified constraint contradiction report when randomize() fails, without incurring any runtime
performance penalty. You can generate a more informative constraint contradiction report by
enabling “enhanced” debugging (SolveFailDebug = 2). Enhanced debugging incurs a runtime
performance penalty and is only recommended when actively debugging failing randomize()
scenarios. You can use any one of the following three methods to set the SolveFailDebug
option:

• Set the SolveFailDebug simulator control variable to 0, 1, or 2 in the modelsim.ini

file.
• Use the -solvefaildebug[=<value>] argument on the vsim command line
(value=0,1,2). If no value is specified, a default value of 1 is set.

1190 Questa® SIM User's Manual, v2023.4

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

• Use the solvefaildebug[=<value>] SystemVerilog attribute in your source code

(value=0,1,2). If no value is specified, a default value of 1 is set. 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=2 *) (a, b) with { a > b; a < b; };
status = randomize (* solvefaildebug=0 *) (a, b) with { a > b; a < b; };

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

Questa® SIM User's Manual, v2023.4 1191

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

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

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.

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.

1192 Questa® SIM User's Manual, v2023.4

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

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

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,

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

Questa® SIM User's Manual, v2023.4 1193

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Constraint Control Options

constraints can represent physical limits grouped by common properties into named constraint
blocks. These blocks can then be independently enabled or disabled. (See the SystemVerilog
LRM 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.

Constraint Control Options

Command line control options allow you to alter the behavior of certain constraints during
randomize() to generate significant differences in solution distribution.
The options are controlled via the "vsim -svrandext" command line option.

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().
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 arguments will not correct the problem. You must fix the conflict in constraint
specification in the Verilog source code (in this example, delete: a < c;).

1194 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Enabling Solver Profiling and Reporting

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

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.
Following the error report, if you have specified vsim -solvefailtestcase[=<filename>], a
simplified testcase to reproduce the failure will be generated.

Enabling Solver Profiling and Reporting

Either the “profile on” command or the “vsim -autoprofile” command will enable basic
constraint solver profiling, which records performance information related to SystemVerilog
randomize() calls invoked during simulation. When solver profiling is enabled, the constraint
solver report (“profile report -solver” command) includes profile data.
Procedure
1. Enable basic solver profiling with either of the following commands:
profile on

or
vsim -autoprofile

2. Generate a report that includes solver profile data.

profile report -solver

Setting Compatibility with a Previous Release

You can specify random sequence generation compatibility with a prior Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1195

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

• Use the -solverev argument with the vsim command to set a previous release.
2. The <version> must be in the format "<year>.<quarter>" (e.g. "2021.1" or "2022.3").
Only prior releases for the same annual release are allowed. For example, for release
2022.3 you can specify "-solverev 2022.2" or "-solverev 2022.1", but you cannot specify
"-solverev 2021.4".

Note
These instructions do not apply to the SystemC/SCV solver.

1196 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Random Number Generator (RNG)

Random Number Generator (RNG)

In System Verilog, various constructs make use of random numbers that are supplied by
Random Number Generators (RNGs). A random number generator consists of a generation
algorithm and an associated internal state referred to as the randstate.
When requested to generate a random value, the RNG computes a random value using the
internal data of the randstate, then updates the randstate. Given a specific starting randstate, the
RNG will always produce the same sequence of values (referred to as pseudo-random values).
The algorithm is designed to produce a sequence of values that have a "good" random
distribution.

RNG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197

Seeding the RNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Random Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Analyzing Random Instability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
Achieve Random Stability Using set_randstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Enabling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
TCL Variables for Controlling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
RNG Trace Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
RNG Activity With A Fork Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
RNG Activity for a Call to new() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Getting a Call Stack for an RNG Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Automatic Filtering of Set/Reset RNG Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225

RNG Overview
Every SystemVerilog class instance and every process (thread) has its own randstate. Each
process has an associated class instance of type process. The randstate of a SystemVerilog
process is that of its associated process class instance.
The randstate of a process or class is initialized either by seeding it with a 32-bit seed value or
by re-setting it using an randstate-string. A randstate-string is a text encoding of an internal
randstate value. The SystemVerilog method get_randstate is used to get a randstate-string.

The generation algorithm and randstate encoding are tool specific. In Questa SIM, the randstate
of a process or class is represented by 128 bits. Questa SIM initializes (seeds) the randstate of a
process or class instance with the next random value obtained from the RNG of the thread that
creates the object.

When you create a class object via a static declaration initializer, there is no active thread. In
such cases, Questa SIM seeds the object with the next random value of the initialization RNG of
the module instance, interface instance, program instance, or package in which the declaration
is present. Similarly, the RNG of a process created by a static declaration (for example, an

Questa® SIM User's Manual, v2023.4 1197

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Overview

initial or always block) is seeded with a random value from an initialization RNG. The
initialization RNGs are seeded using a default seed. The default seed can be set using the vsim
-sv_seed command.

The RNG of a class is only used by class::randomize(). If a user-defined new() function is

called during class construction, the initialization of the class RNG occurs prior to execution of
the new() function.

Note
A class object is not seeded by the RNG of the executing thread if the class does not contain
any rand/randc fields and is never randomized. In such cases, the randstate of the RNG of
the executing thread is left unchanged when such "non-random" class objects are created.

There are two parts to initializing a process:

• Getting a seed value.

• Initializing the process randstate.
When you create a new dynamic thread, the tool (Questa SIM) obtains the seed value from the
RNG of the parent thread. For a static thread, the tool obtains the seed from the initialization
RNG of the module instance, interface instance, or package in which the declaration is present
and depends on the declaration order of seeded objects within the scope. The tool initializes the
randstate of a process on the fly, prior to the first use of the process RNG.

You may manually initialize the randstate of a class or use the built-in class method, srandom.
You can set the randstate of a process by first getting a handle to the current process class and
then calling the srandom method of the class. Also, you can initialize the randstate of the current
process by specifying an argument (seed value) to the $urandom function. Calling $urandom
with an argument seeds the current process and gets the first random value (after the
initialization).

When $urandom is called with an argument, the argument is first used to seed the RNG of the
executing thread and then a random value is requested from the RNG. In this case there are two
RNG operations: 1) urandom(seed), and 2) urandom.

Various operations may request the next random number from a process or class RNG. You
obtain the random number by a random number generation algorithm that uses the randstate of
the process or class.The algorithm computes the next random value and updates (modifies) the
randstate. The algorithm is deterministic, which means a specific state value always yields the
same random number and next state value. Given an initial state, the sequence of generated
random number is therefore deterministic. This is referred to as pseudo-random number
generation. That is, for a specific seed value the tool generates the same sequence of random
numbers. The RNG algorithm is vendor-specific and the random sequence varies between
vendors.

1198 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Overview

For example:

module top;
TClass var1 = new; // The RNG of this class instance is seeded
with the first random value of the module
initialization RNG
TClass var = new; // The RNG of this class instance is seeded
with the next random value of the
module initialization RNG
initial begin // The process seed is the next random value
of the module initialization RNG
TClass var;
int sval, v2;
// the RNG of the (initial)process is
initialized using the process seed.
var = new; // the RNG of the new class instance (var)
is seeded using the next random value of
the process (initial) RNG
sval= $urandom(); // Assign 'sval' the next random value from
the process RNG
var.srandom( sval ); // initialize the RNG of the class
instance 'var' using the passed seed
value.
v2 = $urandom(sval); // seed the RNG of the current thread
using 'sval', then get a random value
from the thread RNG.
process::self.srandom( sval ); // initialize the RNG of the
current thread using the passed seed value.
end

Use the built-in class methods, get_randstate() and set_randstate(str), to get and set the randstate
of a class instance (or thread, via the thread's process instance). The get_randstate() method
returns a vendor-specific string representing the randstate of the class instance. In Questa SIM,
the string always starts with "MS" (for example, "MS51b809524acc66c8b0d5acb1857ef933").
You can use the string obtained from the get_randstate() method to reset the randstate of a class
instance using the set_randstate() method.

Note
Generating or editing the strings obtained from the get_randstate method is not
recommended.

For example:

string rstate;rstate = process::self.get_randstate(); //get an encoding

of the
randstate of the current
processval = $urandom();
//modifies the randstate of the
process
...
process::self.set_randstate(rstate); //reset the randstate of the
current process

Questa® SIM User's Manual, v2023.4 1199

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 RNG

The next random value of the executing thread is accessed for any of the following reasons:

• To get a seed value for initializing a new class.

• To execute a fork statement. A single random value is accesses from the thread RNG.
This is used to initialize a temporary randstate. The temporary randstate is used in
getting random values to seed each of the new processes created by the fork. This is
done in Questa SIM to improve the stability of the parent process (for example, an
additional forked process does not impact the randstate of the parent thread).
• To place a call to $urandom, $urandom_range
• To execute the 'shuffle' array method. This may get multiple random values.
• To execute a call to std::randomize - to get a single random value.
• To execute a randcase statement - to get a random value used in the case selection.
• To execute a randsequence statement. Multiple random values may be used by the
productions of the randsequence.
• To call the class randomize method – the class RNG is used to get a seed value. The seed
value is used to initialize a local randstate used for any random values needed by the
randomize. The class randomize always gets a single random value from the class RNG
(even if the randomize fails and does not update any random variables).
Related Topics
Seeding the RNG
Automatic Filtering of Set/Reset RNG Operations

Seeding the RNG

In SystemVerilog, each thread has its own unique RNG state. The seed of each child thread is
initialized from the parent RNG. Questa SIM 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.

1200 Questa® SIM User's Manual, v2023.4

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 RNG

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 Questa SIM:
vsim -sv_seed random

Related Topics
RNG Overview
Automatic Filtering of Set/Reset RNG Operations

Questa® SIM User's Manual, v2023.4 1201

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Random Stability

Random Stability
The predictability of a sequence of random values is referred to as random stability.
Since each thread and class instance has its own unique RNG (and randstate), the random values
generated for one thread are independent of other threads. This is important since an individual
RNG produces a predictable "sequence" of random values. If two threads share a common
randstate they will share a single sequence of random values. The values seen by one thread will
be dependent on the random value request of the other thread. This independence combined
with the deterministic seeding and value generation yields predictable simulation (testbench)
behavior. This predictability is referred to as random stability.

The Questa SIM simulator provides random stability across:

• Supported operating systems

• 32 vs 64 bit processing
• Tool options (for example, -acc)
Generated random values are independent of these options.

However, random instability can be introduced by user code. For example, suppose the
behavior of a function is controlled by a user-defined simulation option—as when additional
analysis code is executed if a debug option is enabled. If the conditional code gets a value from
the RNG of the executing thread, it modifies the randstate of the thread. This impacts the
random values subsequently generated from the thread, including after the function returns.

The RNG Trace feature can help you identifying the cause(s) of random instability.

Analyzing Random Instability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202

Achieve Random Stability Using set_randstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208

Analyzing Random Instability

In some cases running a simulation with different options may yield unexpected differences.
When the differences are due to different 'random' values, debugging the cause of the difference
can be difficult. The cause may be due to user code. The RNG Trace feature is intended to help
in identifying the cause(s) of the difference.
Procedure
1. Enable RNG Trace for each simulation. (See Enabling RNG Trace.)
When RNG Trace is enabled, the simulator reports (either to the transcript or an RNG
trace file) each operation that modifies the randstate of a process or class instance. This
allows you to compare the RNG activity between two simulations by comparing the
RNG Trace reporting.

1202 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Random Stability

2. Compare the RNG activity between two simulations by comparing the RNG Trace
reports. (See RNG Trace Reporting.)
Examples
A common source of random instability is an unexpected change to the RNG state of a thread or
class. In SystemVerilog, each process (thread) and class instance has in internal RNG state
(randstate). This randstate is used by various utilities that generate random numbers (such as,
$random(), $randomize). In particular, when certain utilities are called from a process, the
utility uses the randstate of the process in determining the 'random' part of its operation and then
also updates the randstate.

For example, consider a process that makes three calls to $urandom(). The first call computes a
random value using the randstate of the process and also updates the randstate. The second call
uses the (modified) randstate to compute a second random value (and also modifies the
randstate. The third call similarly computes a random value and updates the randstate It is
important to note that when a process calls a function that uses/modifies the randstate, it affects
the 'random' result of 'random' utilities that are subsequently called from the process. In the case
where a process calls a function which calls a random utility (or another function that uses a
random utility), the RNG activity within the function affects the random behavior of code
following the return from the function. So the affect of a change to the process randstate in one
part of the code may have an impact on the subsequent execution other sections of code.

In the following example code, a class (TClassA) containing random variables x, y is

randomized 8 times and the sum of the 'x' values is computed. The final sum is reported. There
is also some debug code that reports intermediate sums. The debug code is conditionally
compiled if "DBG2" defined. Running without the extra debug code, a sum of 266 is reported.
However, when the additional code is enabled, the reported sum is 271. The added code affects
the random behavior (that is, the random values selected by the basic code).

Questa® SIM User's Manual, v2023.4 1203

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Random Stability

01: class TDebug;

02: rand int x;
03: int sum = 0, cnt = 0;
04: function void logValue(int pval);
05: sum = sum + pval;
06: cnt = cnt + 1;
07: $display("logValue, val:%d, sum:%d", pval, sum);
08: endfunction
09: endclass
10: class TClassA;
11: rand int x, y;
12: TDebug dbg = null;
13: constraint Limits {
14: x inside {0, 1, 2, 4, 8, 16, 32, 64, 128};
15: y inside {0, 1, 2, 4, 8, 16, 32, 64, 128};
16: }
17: function void enable_debug();
18: if (dbg == null) begin
19:
20: dbg = new();
21:
22: end
23: endfunction
24: function void post_randomize();
25: dbg.logValue(x);
26: endfunction;
27: endclass
28:
29: module top;
30: int cnt, indx, sum, z, dly;
31: int arr[8] = {1,2,4,8,16,32,64,128};
32: TClassA c1;
33: initial begin
34: automatic rs string;
35: c1 = new();
36: 'ifdef DBG2
37:
38:
39: c1.enable_debug();
40:
41:
42: 'endif
43: assert( std::randomize(z) with { z inside {arr}; } );
44: arr.shuffle;
45: sum = 0;
46: for (indx = 0; indx < 8; ++indx) begin
47: assert(c1.randomize() with { x != arr[indx]; } );
48: sum = sum + c1.x;
49: end
50: dly = $urandom_range(20, 30);
51: $display("Sum: %d, dly:%d", sum, dly);
52: end
53: endmodule

1204 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Random Stability

RNG Trace can be used to identify the cause of the random differences. The two versions are
simulated as follows:

vlib work
vlog -sv test1.sv
vsim -c top -do "run -all; quit -f" -rngtrace=base.trace
vlog -sv test1.sv +define+DBG2
vsim -c top -do "run -all; quit -f" -rngtrace=debug.trace

This produces the following trace files:

base.trace

<rng> Trace File:base.trace<rng>p= /top/#INITIAL#1767962654#: ->

MS47527bb5f9e2c20661d2ea9091ed841d, (thread initialize,
seed:1767962654)<rng>p+ /top/#INITIAL#1767962654#:
MS47527bb5f9e2c20661d2ea9091ed841d -> MSf9e2c20661d2ea90976b2d65b8bdb376,
(get class seed, seed:3948585912) @ test2.sv(35)<rng>c= /top/
#INITIAL#1767962654#: -> MSd1ef12ef321778f006bc6d297504e6e2,
(TClassA::class initialize, seed:3948585912) @ test2.sv(35)<rng>p+ /top/
#INITIAL#1767962654#: MSf9e2c20661d2ea90976b2d65b8bdb376 ->
MS61d2ea90976b2d65a87e6e15750e64d8, (std::randomize) @ test2.sv(43)

<rng>p+ /top/#INITIAL#1767962654#: MS61d2ea90976b2d65a87e6e15750e64d8 ->

MS7727db22178fdac73f76ccf28d501589, (shuffle) @ test2.sv(44)

<rng>c+ /top/#INITIAL#1767962654#: MSd1ef12ef321778f006bc6d297504e6e2 ->

MS321778f0420665ba7797d1d1e04a9cc9, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS321778f0420665ba7797d1d1e04a9cc9 ->

MS420665ba7797d1d19a9755ad98e48700, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS420665ba7797d1d19a9755ad98e48700 ->

MS7797d1d19a9755ad86900a4a259de6ca, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS7797d1d19a9755ad86900a4a259de6ca ->

MS9a9755adc22a02d9c486bad18be287f5, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS9a9755adc22a02d9c486bad18be287f5 ->

MSc22a02d9c486bad15b87b6efea5ff2e0, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MSc22a02d9c486bad15b87b6efea5ff2e0 ->

MSc486bad11f3dbe7ca1370ba2f80d18b9, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MSc486bad11f3dbe7ca1370ba2f80d18b9 ->

MS1f3dbe7ca1370ba27183c1118b9f85f4, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS1f3dbe7ca1370ba27183c1118b9f85f4 ->

MSa1370ba23539c9828dda1dda9ecbda5f, (TClassA::randomize) @ test2.sv(47)

<rng>p+ /top/#INITIAL#1767962654#: MS7727db22178fdac73f76ccf28d501589 ->

MS178fdac73f76ccf28d4287392b9b4874, (urandom_range) @ test2.sv(50)

debug.trace

Questa® SIM User's Manual, v2023.4 1205

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Random Stability

<rng> Trace File:debug.trace

<rng>p= /top/#INITIAL#1767962654#: -> MS47527bb5f9e2c20661d2ea9091ed841d,

(thread initialize, seed:1767962654)

<rng>p+ /top/#INITIAL#1767962654#: MS47527bb5f9e2c20661d2ea9091ed841d ->

MSf9e2c20661d2ea90976b2d65b8bdb376, (get class seed, seed:3948585912) @
test2.sv(35)

<rng>c= /top/#INITIAL#1767962654#: -> MSd1ef12ef321778f006bc6d297504e6e2,

(TClassA::class initialize, seed:3948585912) @ test2.sv(35)

<rng>p+ /top/#INITIAL#1767962654#: MSf9e2c20661d2ea90976b2d65b8bdb376 ->

MS61d2ea90976b2d65a87e6e15750e64d8, (get class seed, seed:393546790) @
test2.sv(20)

<rng>c= /top/#INITIAL#1767962654#: -> MS9e475ce00836ab48451d34b839de76b4,

(TDebug::class initialize, seed:393546790) @ test2.sv(20)

<rng>p+ /top/#INITIAL#1767962654#: MS61d2ea90976b2d65a87e6e15750e64d8 ->

MS976b2d65a87e6e15e5faaa20acc1ac94, (std::randomize) @ test2.sv(43)

<rng>p+ /top/#INITIAL#1767962654#: MS976b2d65a87e6e15e5faaa20acc1ac94 ->

MS178fdac73f76ccf28d4287392b9b4874, (shuffle) @ test2.sv(44)

<rng>c+ /top/#INITIAL#1767962654#: MSd1ef12ef321778f006bc6d297504e6e2 ->

MS321778f0420665ba7797d1d1e04a9cc9, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS321778f0420665ba7797d1d1e04a9cc9 ->

MS420665ba7797d1d19a9755ad98e48700, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS420665ba7797d1d19a9755ad98e48700 ->

MS7797d1d19a9755ad86900a4a259de6ca, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS7797d1d19a9755ad86900a4a259de6ca ->

MS9a9755adc22a02d9c486bad18be287f5, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS9a9755adc22a02d9c486bad18be287f5 ->

MSc22a02d9c486bad15b87b6efea5ff2e0, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MSc22a02d9c486bad15b87b6efea5ff2e0 ->

MSc486bad11f3dbe7ca1370ba2f80d18b9, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MSc486bad11f3dbe7ca1370ba2f80d18b9 ->

MS1f3dbe7ca1370ba27183c1118b9f85f4, (TClassA::randomize) @ test2.sv(47)

<rng>c+ /top/#INITIAL#1767962654#: MS1f3dbe7ca1370ba27183c1118b9f85f4 ->

MSa1370ba23539c9828dda1dda9ecbda5f, (TClassA::randomize) @ test2.sv(47)

<rng>p+ /top/#INITIAL#1767962654#: MS178fdac73f76ccf28d4287392b9b4874 ->

MS3f76ccf28d42873987b1db14d09a5f5a, (urandom_range) @ test2.sv(50)

These trace files show all the operations that modify an RNG state. Both simulations start the
same. The first operation initializes the RNG state for the 'initial' block (that is, process "/top/

1206 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Random Stability

#INITIAL#1767962654#"). The RNG of the process is then used to get a seed value for the
new() at line 35. The seed is then used to initialize the RNG of the new class.

In the second run (with the extra code), the next RNG operation (in red) is to get a seed from the
process RNG for the new() at line 20, followed by initialization of the RNG for the new class
instance. This call to TDebug::new() does not occur in the base simulation because the call to
c1.enable_debug() is conditionally compiled. The extra call to new() modifies the randstate of
the executing process. As a result, the randstate at the start of the call to std::randomize (at line
43) is different.

In the base simulation, the randstate is MSf9e2c20661d2ea90976b2d65b8bdb376 while in the

debug simulation the randstate is MS61d2ea90976b2d65a87e6e15750e64d8. Because
std::randomize utilized the RNG state of the executing thread, the solved values are different.
All the subsequent process RNG operations (shuffle, urandom_range) also have a differenct
randstate. Note that the class randomize operations (line 47) use the RNG of the class instance
(c1) which was not modified by the process RNG operations. The class randomize call yields
different solved values (between the two simulations) because the result of the shuffle operation
(prior to the randomize) is different. This impacts the randomize because 'arr' is referenced by a
constraint.

So there is a random stability issue caused by an extra call to new(). One way to fix this is to use
the "get_randstate()" and "set_randstate()" methods to save the randstate prior to the extra call
to new() and then restore the randstate after the call. This is done as follows:

18: if (dbg == null) begin19: string rs =

process::self().get_randstate();20: dbg = new();21:
process::self().set_randstate(rs);22: end

With this change, both simulations now get the same sum value and the RNG trace files are also
the same.

Addressing Random Instability In Unmodifiable or Common Code

Sometimes the operation causing an extra RNG operations (thus random instability) is in code
that is not easily modified. In the above example, the code for class 'TClassA' might be in a
separate file and can not be easily edited. The extra call to new() is in TClassA::enable_debug().
To avoid editing the code for TClassA::enable_debug() the reset of the RNG state could be
performed following the call enable_debug(), as follows:

36: 'ifdef DBG2

37:
38: rs = process::self().get_randstate();
39: c1.enable_debug();
40: process::self().set_randstate(rs);
41:
42: 'endif

Questa® SIM User's Manual, v2023.4 1207

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Random Stability

Using Optimization to Skip Certain get_seed Operations

Generally, when a new class instance is created (by a call to new) or a new process (thread) is
created (by a fork-join statement) the RNG of the executing thread is used to get a random seed
value that is used to initialize the RNG of the new class or process instance. As seen above, this
can be a source of random instability. In some cases, the RNG of the new class or process is
never used. When this happens, the initialization of the RNG is not necessary. Questa SIM has
an optimization to detect certain cases where the RNG cannot be used (no code references the
RNG) and in those cases the operations to get a seed value and initialize the RNG are omitted.

In the above example, if the 'rand' variable 'x' is removed from the declaration of class TDebug
then when an instance of this class in created (by the call to new() at line 20) the operations to
get a seed and initialize the RNG are omitted. As a result, the call to new() does not modify the
RNG of the executing thread. In this case there is not a random stability issue.

Achieve Random Stability Using set_randstate

When code conditionally causes RNG operations it can result in random instability—behavior
unrelated to the condition changes. A common way to avoid this kind of random instability is to
use the get_randstate and set_randstate methods.
In some cases it may be difficult or infeasible to avoid RNG operations in conditional code. For
example, if you have a common method that includes a call to new() and this method is called in
many places in the testbench.

Consider a case where additional analysis code is added, and it is only executed when a
particular simulation option is specified. The randstate of some thread may be affected by the
option, and the basic simulation changes when the option is enabled versus disabled. This is
particularly problematic if the option is a debug option.

One way to avoid this random instability is to avoid RNG operations that may be conditionally
executed. In this case, the new() would need to be moved out of the base method. Alternatively,
conditional code could be executed in a separate thread so RNG activity will not impact other
code. However, these approaches can cause unnecessary code complexity.

You can avoid this kind of random instability by using the get_randstate and set_randstate
methods. Prior to the conditional RNG activity, use get_randstate() to get the randstate and then
use set_randstate to reset the randstate after the conditional RNG activity. For example, the
print_msg method of class foo in the code below contains a call to new(). There may be
additional calls to this method when a particular option is enabled.

. . .
if (diag_enabled) begin
f2.pring_mesg("before urandom");
end
f2.x=$urandom();

There may be additional calls to this method when a particular option is enabled.

1208 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Random Stability

Because the print_msg method modifies the randstate of the thread, it affects the result of the
subsequent call to $urandom. So when 'diag_enabled' is enabled, 'f2.x' is assigned a different
value. This can be avoided by getting the randstate prior to the call to print_msg and restoring it
after the call. As in:

...
if (diag_enabled) begin
automatic string rs = process::self.get_randstate();
f2.print_msg("before urandom");
process::self.set_randstate(rs);
end
f2.x = $urandom();

Note
set_randstate is used in some UVM code to achieve random stability.

Filtering RNG Operations Preceding a Call to set_randstate

You can use the set_randstate method to achieve random stability when there are RNG
operations in conditional code. Although random stability is achieved, conditional RNG
operations are logged in a RNG trace file, and comparison of RNG trace files will show
differences in these operations. To facilitate comparison of trace files, Questa SIM suppresses
(does not write to the trace file) certain RNG operations.

In general, you can use the set_randstate method to reset an RNG to a prior randstate, so that a
sequence of one or more RNG operations do not affect future RNG operations. For example,
assume the following operation and associated randstate updates are performed on the same
RNG:

Op1: state1 -> state2

... [get_randstate is used to get a randstate string for state2 (not
reported in the trace file)]
op2: state2 -> state3
op3: state3 -> state4
op4: -> state2 [set_randstate used to reset the randstate to state2]
op5: state2 -> state3

In this case, op4 resets the RNG to the randstate prior to op2. So operations op2, op3 and op4
have no effect on subsequent operations of the RNG. RNG Trace suppresses these operations
from the trace file.

In order to detect operations preceding a set_randstate that should be suppressed, Questa SIM
uses an output buffer when writing to a trace file. When a set_randstate operation is written to
the buffer, the operations in the buffer, preceding the set_randstate operation, are scanned. The
preceding operations are scanned (backward) looking for an operation where the starting
randstate matches the randstate of the set_randstate operation. In the example above, this is op2
because its starting randstate is state2, which matches the randstate of the set_randstate
operation. The operations between the matching operation and the set_randstate operation
(inclusive) are deleted from the buffer. If no match is found, no operations are deleted.

Questa® SIM User's Manual, v2023.4 1209

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Random Stability

If the RNG trace output is directed to the transcript (that is, no trace file is created), the
operations are not buffered and this filtering is not performed.

The default buffer size is 20. You can set the buffer size with the “-rngtracebuffersize=<value>”
argument for vsim. If you set the buffer size to 1 or less no filtering is performed.

1210 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

RNG Trace
The RNG Trace feature provides an intuitive tool for analyzing and debugging simulation
differences due to divergences in process or object RNG utilization.
Enabling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
TCL Variables for Controlling RNG Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
RNG Trace Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
RNG Activity With A Fork Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
RNG Activity for a Call to new() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224
Getting a Call Stack for an RNG Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224

Enabling RNG Trace

The RNG Trace feature provides an intuitive tool for analyzing and debugging simulation
differences due to divergences in process or object RNG utilization. When you enable RNG
Trace, the tool generates diagnostic output whenever the RNG of a process or class instance
changes.
Procedure
Enable RNG Trace reporting with the following command:

vsim -rngtrace[=<filename>]

If <filename> is not specified, trace information is written to the transcript. If a filename

is specified, the trace information is written to the named file.
You can also enable the RNG Trace feature using the RNGTrace TCL variable. See
TCL Variables for Controlling RNG Trace.

TCL Variables for Controlling RNG Trace

RNG Trace can be controlled with the TCL variables listed here.
• RNGTrace — Setting this variable to 0 disables reporting of RNG activity. A non-zero
value enables reporting.
• RNGTraceFile — Setting this variable changes the file (or transcript) for reporting
RNG activity. If a different trace file is active, buffered operations are written and the
file is closed. If the new filename is not designated (""), RNG Trace output is directed to
the transcript.
• RNGTraceOpt — When this variable is assigned a value (string) the RNG Trace
options are updated. The option string has the same syntax as specified for the vsim

Questa® SIM User's Manual, v2023.4 1211

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

-rngtraceopt command line argument. Setting this variable updates all RNG trace
options (that is, it is not incremental to a prior assignment). For example:
“set RNGTraceOpt showciid” enables the showciid option and disables other
options (e.g. showsimtime, guiprocessnames, nosupptess).
“setRNGTraceOpt showsimtime,guiprocessnames” enables showsimtime and
guiprocessname and disables other options (showciid, nosuppress).
• RNGTraceClassFilter — When this variable is assigned a value (string) the class
filtering is updated. The filter string has the same syntax as specified for the vsim -
rngtraceclassfilter command line argument.
• RNGTraceProcessFilter — When this variable is assigned a value (string) the process
filtering is updated. The filter string has the same syntax as specified for the -
rngtraceprocessfilter command line option.

RNG Trace Reporting

When RNG Trace reporting is enabled, the tool generates output whenever the RNG of a
process (initial, always, or fork) changes.
Each time a RNG randstate is modified, the RNG Trace feature writes a line to the trace file (or
transcript) in the following format

<rng><type> [<simtime>:] <process_name>:[<old_rand_state>] ->

<new_rand_state> ([fork::|<ciid>] <operation>[,seed:<seed_value>] @
<filename>(<linenumber>)

Where:

<type> — the type of RNG operation, which can be one of the following:

• p= — assignment to the RNG state of a process (either by seeding or a randstate string)

• p+ — update of the RNG state of a process
• c= — assignment to the RNG state of a class instance
• c+ — update of the RNG state of a class instance
<simtime> — the simulation time when the RNG operation occurred. This is reported if you
specify the vsim option "-rngtraceopt=+showsimtime".

<process_name> — the name of the executing process.

<old_rand_state> — a string encoding of the randstate prior to the RNG operation. The
<old_rand_state> is not reported from some initialization operations.

<new_rand_state> — a string encoding of the randstate after the RNG operation.

1212 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

<ciid> — the class instance ID (only for operations on the RNG of a class instance). By
default, the <ciid> is not reported. Reporting is enabled with the vsim option “-
rngtraceopt=+showciid”.

<operation> — the name of the RNG operation.

<seed_value> — the value of a seed used in initialization of the randstate. This is only
reported for operations using a seed.

<filename> — the name of the source file containing the RNG operation.

<linenumber> — the line number of the RNG operation.

For example:

<rng>p= /top/#INITIAL#767962654#-> MS4752bb5f9e2c20661d2ea9091ed841d,

(thread initialze, seed:1767962654)

<rng>p+ /top/#INITIAL#4132083106#: MS3e5cddcd7e4dd4e7c3797a97180a20c6 ->

MS7e4dd4e7c3797a975b291cc791b7a462, (urandom_range) @ ../src/test2.sv(56)

<rng>p+ 10ns: /top/sub_mid/sub_bot/#ALWAYS#1767962654#:

MSf30deb91096b8e693192bcdb8022b775 -> MS096b8e693192bcdb6603c3651c2e87aa,
(urandom) @ ../src/test04_3.sv(8)

The tool shows the optional output in bold red when you use the -rngtraceopt argument with
vsim:

vsim -rngtraceopt=+showsimtime

Reported RNG Operations

The following RNG operations may be reported:
Table 22-2. RNG Operations
operation type description
urandom(seed) p= This operation seeds the RNG of the current thread. It is the
initial part of call to $urandom with an argument (seed value).
urandom p+ This operation gets a random value from the RNG of the
current thread - updating the randstate. It is for a call to
$urandom.
urandom_range p+ This operation gets a random value from the RNG of the
current thread - updating the randstate. This RNG operations is
performed by calls to $urandom_range. It is also performed in
evaluating randcase statements and randsequence statements.

Questa® SIM User's Manual, v2023.4 1213

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

Table 22-2. RNG Operations (cont.)

operation type description
std::randomize p+ A call to the std::randomize method gets a random value from
the thread RNG - updating the randstate. The random value is
used to initialize a RNG local to the randomize method. The
operations against this local RNG are not reported.
randomize c+ A call to a class randomize method gets a random value from
the class RNG - updating the randstate. The random value is
used to initialize a RNG local to the randomize method. The
operations against this local RNG are not reported.
shuffle p+ This operation is reported for call to an array.shuffle method.
The call may get multiple random values. The RNG trace entry
reports the randstate prior to the call and the randstate after the
last update.
get class seed p+ This operation gets a random value (seed) from the RNG of the
current thread. This is the first RNG operation of a call to
new().
class initialize c= This operation uses a seed value to initialize the RNG of a
class instance. This is the second RNG operation of a call to
new().
get thread seed p+ This operation gets a random value (seed) from the RNG of the
current thread. The RNG operation is part of a fork (see below)
thread initialize p= This operation uses a seed value to initialize the RNG of a
thread. It is performed to initialize static threads (initial,
always). It is also performed to initialize dynamic thread as a
part of a fork.
set_randstate c= This operation uses an RNG state string to initialize the RNG
of a class instance. It is performed by a class set_randstate
method.
process::set_randstate p= This operation uses an RNG state string to initialize the RNG
of the current thread. It is performed by the
process::set_randset() method.
srandom c= This operation uses a seed value to initialize the RNG of a
class instance. It is performed by a class srandom() method.
process::srandom p= This operation uses a seed value to initialize the RNG of the
current thread. It is performed by the process::set_randstate()
method.
random value p+ This operation gets a random value from RNG of the current
thread - updating the randstate. It is part of an optimization of
certain calls std::randomize.

1214 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

Constructs That Cause the RNG of a Process to Change

The following constructs (with the associated description in bold) causes the RNG of a process
to change:

• process::new() - initial/always/fork
o init
o The tool prints only new_rand_state
o filename(lineno) may be absent for some implicit processes
• $urandom()
o urandom
• $urandom_range()
o urandom_range
• std::randomize()
o randomize
• array::shuffle()
o shuffle
• fork
o seed_fork
• class::new()
o seed_class
Constructs That Cause the RNG of a Class Instance to Change
The following constructs (with the associated description in bold) causes the RNG of a class
instance to change:

• class::new()
o new
o The tool prints only new_rand_state
• class::srandom() — Reports changes as a process operation rather than a class
operation. (The preceding statement in bold only applies to process instances—all other
non-process classes will report class::srandom() as a class operation.)
o srandom

Questa® SIM User's Manual, v2023.4 1215

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

• class::set_randstate() — Reports changes as a process operation rather than a class

operation. (The preceding statement in bold only applies to process instances—all other
non-process classes will report class::srandom() as a class operation.)
o set_randstate
• class::randomize()
o randomize

RNG Activity With A Fork Statement

Questa SIM creates a temporary RNG (context) for a fork-join. The thread that executes the
fork seeds this RNG, which provides random seed values for the child threads of the fork. In this
way execution of a fork statement always gets a single value from the RNG of the parent thread
(independent of the number of child threads). This yields better random stability because if the
Verilog code is modified to add an additional child thread, the RNG randstate after the fork
statement is still the same.
Execution of a fork statement yields the following RNG activity:

1. Get a random seed value (s0) from the executing thread.

2. Initialize the temporary RNG using the seed (s0).
3. Get a random seed (s1) from the temporary RNG for seeding the first child thread.
4. Initialize the RNG of the first child thread (using s1).
5. Get a random seed (s2) from the temporary RNG for seeding the second child thread.
6. Initialize the RNG of the second child thread using s2.
RNG operations 2, 3, and 5 apply to the temporary RNG (rather than the process RNG). In
reporting operations on a fork temporary RNG, the <operation> is prefixed with "fork::" For
example:

<rng>p+ top/#INITIAL#010000#: MSe761d9c364581202bbab44dbfeff1686 ->

MS64581202ff114c48e7acc1a548370ceb, (fork::get thread seed,
seed:2224394197) @ f.sv(20)

For each child thread, there is a get thread seed operation followed by a thread initialize
operation. However, the thread initialize operation does not necessarily immediately follow
the get thread seed operation. Initialization of the thread RNG randstate is performed on-the-
fly just prior to the first usage of the randstate.

Seed values are reported in RNG trace entries. You can use the seed value to correlate a get
thread seed operation with a thread initialize operation, particularly when there are other
RNG operations between them.

1216 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

<rng>p= tsk1/#FORK#020000#: -> MSebf914963fed29fccf6ddb58fe688eb6,

(thread initialize, seed:2224394197)

Example
The following code contains a fork-join.

Questa® SIM User's Manual, v2023.4 1217

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

1. package pack1;
2. class class1;
3. rand int var_01;
4. task tsk2(string id, int arr[10]);
5. #10;
6. arr.shuffle();
7. #100;
8. $display("tsk2-%s, arr[0] = %d", id, arr[0]);
9. endtask;
10. task tsk1();
11. int tick = 0;
12. int ar1[10];
13. int ar2[10];
14. assert( std::randomize(ar1, ar2) with {
15. foreach(ar1[i]) ar1[i] inside { [0:19] };
16. foreach(ar2[i]) ar2[i] inside { [20:39] };
17. });
18. #10;
19. fork
20. tsk2("J1", ar1);
21. join_none
22. #10;
23. fork
24. begin
25. #10;
26. tick += 1;
27. #10
28. tsk2("J2a", ar1);
29. #10;
30. tsk2("J2a", ar1);
31. end
32. begin
33. #5;
34. tick += 1;
35. #10
36. tsk2("J2b", ar2);
37. #10;
38. tsk2("J2b", ar2);
39. end
40. join
41. endtask;
42. endclass
43. endpackage
44. module top;
45. pack1::class1 c1;
46. pack1::class1 c2
47. bit xx = 0;
48. initial begin
49. c1 = new;
50. c1.tsk1();
51. xx = 1;
52. end

1218 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

53. always@(xx) begin

54. c2 = new;
55. c2.tsk1();
56. end
57. endmodule

Running the simulation with vsim -rngtrace -rngtraceopt=useprocessid yields the following
trace

1. # <rng>p= top/#INITIAL#010000#: -> MS47527bb5f9e2c20661d2ea9091ed841d,

(thread initialize, seed:1767962654)
Initialization of the process (010000) for the initial block declared at line 48 (line not
reported).
2. # <rng>p+ top/#INITIAL#010000#: MS47527bb5f9e2c20661d2ea9091ed841d ->
MSf9e2c20661d2ea90976b2d65b8bdb376, (get class seed, seed:3948585912) @
f.sv(50)
At line 50, the RNG of process 010000 is used to get a class seed.
3. # <rng>c= top/#INITIAL#010000#: -> MSd1ef12ef321778f006bc6d297504e6e2,
(class1::class initialize, seed:3948585912) @ f.sv(50)
At line 5-, the seed is used to initialize the RNG of an instance of 'class1'.
4. # <rng>p+ top/#INITIAL#010000#: MSf9e2c20661d2ea90976b2d65b8bdb376 ->
MS61d2ea90976b2d65a87e6e15750e64d8, (std::randomize) @ f.sv(14)
At line 14, the RNG of process 010000 is used by std::randomize.
5. # <rng>p+ top/#INITIAL#010000#: MS61d2ea90976b2d65a87e6e15750e64d8 ->
MS976b2d65a87e6e15e5faaa20acc1ac94, (get thread seed, seed:2634922342) @
f.sv(19)
The RNG of the executing thread is used to get a seed for the temporary RNG of the fork
at line 19.
6. # <rng>p= top/#INITIAL#010000#: -> MSe761d9c364581202bbab44dbfeff1686,
(fork::thread initialize, seed:2634922342) @ f.sv(19)
The seed value is used to initialize a the temporary RNG for the fork.
7. # <rng>p+ top/#INITIAL#010000#: MSe761d9c364581202bbab44dbfeff1686 ->
MS64581202ff114c48e7acc1a548370ceb, (fork::get thread seed, seed:2224394197)
@ f.sv(20)
The temporary RNG of the fork is used to get a seed value for the forked process at line
20.
8. # <rng>p+ top/#INITIAL#010000#: MS976b2d65a87e6e15e5faaa20acc1ac94 ->
MSa87e6e15e5faaa20aa3483f01591412e, (get thread seed, seed:3166299062) @
f.sv(23)

Questa® SIM User's Manual, v2023.4 1219

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

The RNG of the executing thread is used to get a seed value for the temporary RNG of
the fork at line 23.
9. # <rng>p= top/#INITIAL#010000#: -> MS57543742ce9596bb7c4952aacedfe60a,
(fork::thread initialize, seed:3166299062) @ f.sv(23)
The seed value is used to initialize the temporary RNG of the fork at line 23.
10. # <rng>p+ top/#INITIAL#010000#: MS57543742ce9596bb7c4952aacedfe60a ->
MSce9596bb7c4952aa8a9afdf5872900fa, (fork::get thread seed, seed:1208561986)
@ f.sv(32)
The temporary RNG of the fork is used to get a seed value for the forked process at line
32.
11. # <rng>p+ top/#INITIAL#010000#: MSce9596bb7c4952aa8a9afdf5872900fa ->
MS7c4952aace20f566e5c81aa70c77caab, (fork::get thread seed, seed:1901645935)
@ f.sv(24)
The temporary RNG of the fork is used to get a seed value for the forked process at line
24.
12. # <rng>p= tsk1/#FORK#020000#: -> MSebf914963fed29fccf6ddb58fe688eb6,
(thread initialize, seed:2224394197)
The seed (obtained at trace #7) is used to initialize tsk1/#FORK#020000# (declared at
line 20).
13. # <rng>p+ tsk1/#FORK#020000#: MSebf914963fed29fccf6ddb58fe688eb6 ->
MSefccb706632c52ed90be6f5e785ecd9f, (shuffle) @ f.sv(6)
Forked process tsk1/#FORK#020000# calls the task "tsk2" (line 20).
The RNG of tsk1/#FORK#020000# is used by the shuffle operation at line 6.
14. # <rng>p= tsk1/#FORK#030000#: -> MScb17cfe0cd7d1a45eddfe620d0b2c270,
(thread initialize, seed:1208561986)
The seed (obtained at trace #10) is used to initialize tsk1/#FORK#030000# (declared at
line 32).
15. # <rng>p+ tsk1/#FORK#030000#: MScb17cfe0cd7d1a45eddfe620d0b2c270 ->
MS2d9e424f67468a9bfe33bd2849476ba9, (shuffle) @ f.sv(6)
Process tsk1/#FORK#030000# calls "tsk2" (line 36).
The RNG of tsk1/#FORK#030000# is used by a shuffle operation at line 6.
16. # <rng>p= tsk1/#FORK#040000#: -> MS00371ddfdd5f0b4aacba0f5e5faef94a,
(thread initialize, seed:1901645935)
The seed (obtained at trace #11) is used to initialize tsk1/#FORK#040000# (declared at
line 24).

1220 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

17. # <rng>p+ tsk1/#FORK#040000#: MS00371ddfdd5f0b4aacba0f5e5faef94a ->

MSad0b6cd55e5e8bc21baaa32785a78da9, (shuffle) @ f.sv(6)
The process tsk1/#FORK#040000# calls "tsk2" (line 28).
The RNG of tsk1/#FORK#040000# is used by a shuffle operation at line 6.
18. # tsk2-J1, arr[0] = 12
19. # tsk2-J2b, arr[0] = 38
20. # tsk2-J2a, arr[0] = 18
Output from tsk2.
21. # <rng>p+ tsk1/#FORK#030000#: MS2d9e424f67468a9bfe33bd2849476ba9 ->
MS7b528f9ccc6e59b5ebef8ac39d61a13a, (shuffle) @ f.sv(6)
tsk1/#FORK#030000# returns from the call to tsk2 (line 36).
tsk1/#FORK#030000# calls tsk2 (line 38).
The RNG of tsk1/#FORK#030000# is used by the shuffle at line 6.
22. # <rng>p+ tsk1/#FORK#040000#: MSad0b6cd55e5e8bc21baaa32785a78da9 ->
MS108b1c436db6fca9bc4adf16341d285c, (shuffle) @ f.sv(6)
tsk1/#FORK#040000# returns from tsk2 (line 28).
tsk1/#FORK#040000# call tsk2 (line 30).
The RNG of tsk1/#FORK#040000# is used by the shuffle at line 6.
23. # tsk2-J2b, arr[0] = 27
24. # tsk2-J2a, arr[0] = 18
Output from tsk2.
25. # <rng>p= top/#ALWAYS#050000#: -> MSe72d99dd194728a77ae6d55eca276009,
(thread initialize, seed:4132083106)
The always block (line 54) is initialized.
26. # <rng>p+ top/#ALWAYS#050000#: MSe72d99dd194728a77ae6d55eca276009 ->
MS194728a73e5cddcd7e4dd4e7a2a07c61, (get class seed, seed:318257127) @
f.sv(55)
The RNG of top/#ALWAYS#050000# is used to get a seed for construction of 'c2' at
line 55.
27. # <rng>c= top/#ALWAYS#050000#: -> MSf3cb83beece493b081aa3a2c112b2ad4,
(class1::class initialize, seed:318257127) @ f.sv(55)
The seed is used to initialize the RNG of class 'c2' at line 55.

Questa® SIM User's Manual, v2023.4 1221

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

28. # <rng>p+ top/#ALWAYS#050000#: MS194728a73e5cddcd7e4dd4e7a2a07c61 ->

MS3e5cddcd7e4dd4e7c3797a97180a20c6, (std::randomize) @ f.sv(14)
Task 'tsk1' is called from the always block (line 56).
The RNG of top/#ALWAYS#050000# is used by std:: randomize at line 14).
29. # <rng>p+ top/#ALWAYS#050000#: MS3e5cddcd7e4dd4e7c3797a97180a20c6 ->
MS7e4dd4e7c3797a975b291cc791b7a462, (get thread seed, seed:1182951324) @
f.sv(19)
The RNG of top/#ALWAYS#050000# is used to get a seed for the temporary RNG of
the fork at line 19.
30. # <rng>p= top/#ALWAYS#050000#: -> MSdc4f36967df61ddb59c82cbb35953f45,
(fork::thread initialize, seed:1182951324) @ f.sv(19)
The seed is used to initialize the temporary RNG of the fork at line 19.
31. # <rng>p+ top/#ALWAYS#050000#: MSdc4f36967df61ddb59c82cbb35953f45 ->
MS7df61ddb1d72242848180091a7cca8fd, (fork::get thread seed, seed:1886363867)
@ f.sv(20)
The temporary RNG of the fork is used to get a seed for the forked process at line 20.
32. # <rng>p+ top/#ALWAYS#050000#: MS7e4dd4e7c3797a975b291cc791b7a462 ->
MSc3797a975b291cc700a0ffd9f34aa18a, (get thread seed, seed:808499740) @
f.sv(23)
The RNG of top/#ALWAYS#050000# is used to get a seed for the temporary RNG of
the fork at line 23.
33. # <rng>p= top/#ALWAYS#050000#: -> MS97b5bb38226af1c4e341928275e80a53,
(fork::thread initialize, seed:808499740) @ f.sv(23)
The seed is used to initialize the temporary RNG of the fork at line 23.
34. # <rng>p+ top/#ALWAYS#050000#: MS97b5bb38226af1c4e341928275e80a53 ->
MS226af1c4e3419282863c888234bf67f8, (fork::get thread seed, seed:374229428) @
f.sv(32)
The temporary RNG of the fork is used to get a seed for the forked process at line 32.
35. # <rng>p+ top/#ALWAYS#050000#: MS226af1c4e3419282863c888234bf67f8 ->
MSe3419282863c8882aa991c4ce7d8e848, (fork::get thread seed, seed:70566870) @
f.sv(24)
The temporary RNG of the fork is used to get a seed for the forked process at line 24.
36. # <rng>p= tsk1/#FORK#060000#: -> MS44891bd3b2142e43637b1b8a652eceda,
(thread initialize, seed:1886363867)
A seed (obtained at trace #31) is used to initialize the process tsk1/#FORK#060000#.

1222 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
RNG Trace

37. # <rng>p+ tsk1/#FORK#060000#: MS44891bd3b2142e43637b1b8a652eceda ->

MS6417460c45090c3a113ed3d04eb66c7b, (shuffle) @ f.sv(6)
tsk1/#FORK#060000# calls tsk2 (line 20).
The RNG of tsk1/#FORK#060000# is used by the shuffle at line 6.
38. # <rng>p= tsk1/#FORK#070000#: -> MSeead835ea2b72125211f29fb84f73367,
(thread initialize, seed:374229428)
A seed (obtained at trace #34) is used to initialize tsk1/#FORK#070000#.
39. # <rng>p+ tsk1/#FORK#070000#: MSeead835ea2b72125211f29fb84f73367 ->
MS5b1fd22d26aa5dd78d9c278114bb99bd, (shuffle) @ f.sv(6)
tsk1/#FORK#070000# call tsk2 (line 36).
The RNG of .tsk1/#FORK#070000# is used by the shuffle at line 6.
40. # <rng>p= tsk1/#FORK#080000#: -> MS745208cb0ba7df80474bd878a2f56721,
(thread initialize, seed:70566870)
A seed (obtained at trace #35) is used to initialize tsk1/#FORK#080000#
41. # <rng>p+ tsk1/#FORK#080000#: MS745208cb0ba7df80474bd878a2f56721 ->
MS23a320ee69e2aa968cec87892afab6e3, (shuffle) @ f.sv(6)
tsk1/#FORK#080000# call tsk2 (line 28).
The RNG of tsk1/#FORK#080000# is used by the shuffle at line 6.
42. # tsk2-J1, arr[0] = 7
43. # tsk2-J2b, arr[0] = 30
44. # tsk2-J2a, arr[0] = 5
Output from tsk2.
45. # <rng>p+ tsk1/#FORK#070000#: MS5b1fd22d26aa5dd78d9c278114bb99bd ->
MS8f5101db7c5de82cfb2177b170a3743e, (shuffle) @ f.sv(6)
tsk1/#FORK#070000# returns from tsk2 (line 36).
tsk1/#FORK#070000# calls tsk2 (line 38)
the RNG of tsk1/#FORK#070000# is used by the shuffle at line 6.
46. # <rng>p+ tsk1/#FORK#080000#: MS23a320ee69e2aa968cec87892afab6e3 ->
MSc08996f2e89112292185bd6455b028b3, (shuffle) @ f.sv(6)
tsk1/#FORK#080000# returns from tsk2 (line 28)
tsk1/#FORK#080000# calls tsk2 (line 30)

Questa® SIM User's Manual, v2023.4 1223

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
RNG Trace

the RNG of tsk1/#FORK#080000# is used by the shuffle at line 6.

47. # tsk2-J2b, arr[0] = 27
48. # tsk2-J2a, arr[0] = 14
Output from tsk2.

RNG Activity for a Call to new()

A call to new() to construct a new class instance results in RNG activity.
RNG activity from a call to new() can include the following:

• Getting a random seed value (s0) from the executing thread.

• Initializing the RNG of the class instance (using s0).
Randstate initialization occurs prior to execution of the body of a user defined new method.
This allows the new() method to make use of the instance RNG, as in the method to call
'this.randomize()' to generate initial random values for the new class instance.

Note that getting a random seed value (s0) from the executing thread uses the RNG of the
executing thread. This means that any call to new() modifies the randstate of the executing
thread. This can be undesirable if the RNG of the class instance is never used. InQuesta SIM, if
the class type does not contain any 'rand/randc' variable declarations and there are no calls to the
'randomize' method, the get class seed operation is skipped and a seed value of zero is used to
initialize the instance RNG. As a result, the call to new() does not modify the RNG of the
executing thread.

Optimization to Skip Unnecessary ‘get seed’ Operations

Generally, when a new class instance is created (by a call to new) or a new process (thread) is
created (by a fork-join statement) the RNG of the executing thread is used to get a random seed
value that is used to initialize the RNG of the new class or process instance. In some cases the
compiler can determine that the RNG of the new class or process is never used. Since the ‘get
seed’ in the executing process can be a source of random instability, there is an optimization
that skips the ‘get seed’ and simply uses a seed of 0 to initialize the new class or process RNG.
This happens when the compiler can determine that the RNG cannot be used. In looking at the
RNG output, if the seed value reported for an initialize operation is zero, the ‘get seed’
operation was optimized away.

Getting a Call Stack for an RNG Operation

The RNG Trace report includes the file and line number of RNG operations, but not call stack
information. The call stack, however, can help you debug random stability issues when the

1224 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Automatic Filtering of Set/Reset RNG Operations

calling process matches a specific randstate. You can view the call stack by re-running the
simulation and setting a breakpoint for a particular randstate.
Procedure
Set the breakpoint with the following command:

bp <filename><line_number> -randstate <string>

Examples
The -randstate argument for the breakpoint command qualifies a breakpoint with a randstate-
string. For example, suppose an RNG trace reported the following operations:

<rng>p+ top/#ALWAYS#39: MSe72d99dd194728a77ae6d55eca276009 ->

MS194728a73e5cddcd7e4dd4e7a2a07c61, (get class seed, seed:318257127) @
myfile.sv(41)

To get the call stack of this operation, re-run the simulation and set the following breakpoint:

bp myfile.sv 41 -randstate MSe72d99dd194728a77ae6d55eca276009

The breakpoint triggers when the specified line is about to be executed AND the randstate of the
active thread (process) matches the specified randstate. The call stack can then be examined.

The randstate is an effective qualifier for a breakpoint. Questa SIM uses a 128-bit internal
representation of the randstate. The RNG generation algorithm is such that in a sequence of
RNG operations, a specific randstate value is not repeated for a very long time.

You can use srandom or set_randstate to force a randstate to a specific value, yielding a
repeated randstate value, and subsequent values.

Automatic Filtering of Set/Reset RNG Operations

The RNG Trace feature can help with debugging and identifying random instability issues. It
records all operations that modify the randstate of a process or class. Comparing (diff) trace
files between two simulations can help in the stability analysis.
Random instability can be introduced when operations that modify the RNG state of the active
thread are conditionally executed (for example, controlled by a command line option). A
common workaround is to get the randstate prior to the operation(s) and reset it after the
operations. For example:

string rs;
...
rs == process::self().get_randstate(); // get the randstate
c1 = new(); // modify the randstate
process::self().set_randstate(rs); // reset the randstate

The above usage of 'set_randstate()' works to address the random stability introduced by the
instantiation of ‘c1’. However, the associated operations are still recorded in the RNG trace file

Questa® SIM User's Manual, v2023.4 1225

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Const Cast Expression Support

and can show up as differences when comparing trace files. It is desirable to filter these
operations to facilitate the comparison.

To do this,Questa SIM buffers operations being written to an RNG trace file, then performs a
backward scan of the buffered operation when a set_randstate operation (on the executing task)
is encountered. The tool looks for the first operation where the input (prior) randstate matches
the randstate of the set_randstate operation. If such a operation is found, the matching operation
along with the reset operation and intervening operations are filtered (removed from the buffer).

Only RNG operations executed by the active process are considered.

Consider the example above, when set_randstate is called after a call to new. The sequence of
RNG operations is:

1. Get a seed value from the thread RNG - changing the randstate from RS1 to RS2.
2. Use the seed to initialize the class RNG - the class RNG is set to RS3.
3. Call set_randstate to set the thread RNG to RS1.
The trace buffer records operations 1, 2, and 3. Since operation 1 is a set_randstate operation,
the tool scans the buffer backward from operation 3. Operation 2 is on the same process (thread)
but the input randstate does not match. Operation 1 has a matching process and input randstate.
Therefore, operations 1, 2, and 3 are filtered (deleted).

If a matching randstate is not found within the buffered operations no filtering is performed.

When the RNG trace is being written to the transcript (rather than to a file), the buffering will
not be performed and the filtering is not done. This is because the filtering would delay the
reporting of RNG operation (within the transcript) and make the reporting confusing.

The length of the buffer can be controlled by the "vsim -rngtracebuffersize=<value>"

command. Setting a size less than 2 disables filtering. The default is 20.

All buffered trace operations are written to the trace file (flushed) at the end of simulation. They
are also flushed if the trace file is changed (as in, assignment to the RNGTraceFile variable).

Related Topics
RNG Overview
Seeding the RNG

Const Cast Expression Support

Questa SIM supports the use of ‘const cast’ expressions in constraints. This is valuable when
you want to treat an expression as a constant that would otherwise be considered random.

1226 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Const Cast Expression Support

The constraint expression “const'(expr)” will evaluate “expr” as a constant value. Random
variables referenced by “expr” are evaluated as if non-random. The value of a random variable
referenced by “expr” is sampled prior to randomize().

Note
For class::randomize, the value will be sampled after pre_randomize().

Consider the following code:

int a, b, c;
int status;

a = 123;
status = randomize(a, b, c) with {
b == const'(a);
c == a;
a == 999;
};
$display("a=%0d, b=%0d, c=%0d", a, b, c);

After running the above randomize() call, the following values are displayed:

a=999, b=123, c=999

The expression “const'(a)” is interpreted as a constant value — that is, the current value (before
randomization) of variable “a”. As a result, the constraint “b == const'(a);” is equivalent to “b
== 123;” (where 123 is the value of “a” before randomize). Without the use of const cast, the
constraint “c == a;” forces the values of random variables “c” and “a” to be equal (since “a” is
constrained to 999, the value of “c” is as well).

Questa® SIM User's Manual, v2023.4 1227

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Solver Record and Replay

Solver Record and Replay

Solver record and replay enables you to simulate a testbench in which the solver does not
analyze and solve the constraint. It only assigns previously solved values from a previous run.
Solver Record and Replay Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Solver Record and Replay Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229

Solver Record and Replay Overview

Solver record logs the solved values of random variables evaluated by randomize() calls during
simulation to a solver recording file. Solver replay reads the contents of the solver recording file
and applies the stored values of random variables to randomize() calls during simulation.

Use Cases of Solver Record and Replay

• Provides random stability for debugging simulation
Solver replay enables a simulation, which was recorded with a specific seed running in
an optimized or regression-mode configuration, to re-run with an alternate debug
configuration in a random-stable manner (in cases where the debug configuration would
otherwise impact random stability in a way that would not reproduce the behavior of the
optimized or regression-mode simulation).
• Improves regression performance
Enables a simulation, which was recorded with a specific seed, to re-run with a
performance gain (due to reduced solver overhead).

Unsupported Options
• Solver record and replay has limited support of random associative arrays. An
associative array is eligible for record and replay if it meets all of the following
conditions:
o Index is of integral type, and wildcard type is not supported
o The bit-width of index is 32 bits or less
• Solver record and replay does not support random variables of real type.
• Solver record and replay ignores the following randomize() call variations, that is, these
calls are evaluated as if solver record and replay were not active:
o class::randomize(null) with or without inline constraints

Restrictions
• Use the same version of the tool to record and replay a solver log file.

1228 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verification with Constrained Random Stimulus
Solver Record and Replay Flow

• Use the exact same set of randomize() calls and in the same order as when the solver log
file was written.
• Use the same source file signatures. Solver record and replay accepts minimal changes
to the source files in the design as long as the following conditions are met:
o You do not add any new files to the elaboration snapshot.
o You do not change the location of the randomize() callsites (file name, line number).

Error Conditions
Solver record and replay triggers an error in the following conditions:

• Solver record
o File I/O error on specified solver recording file
o randomize() call with unsupported random associative array
o randomize() call with unsupported random variable of real-type
• Solver replay
o File I/O error on specified solver recording file
o Tool version mismatch in Solver Record and Replay
o randomize() call mismatch from solver recording file
• Filename or line number mismatch
• Random variable type mismatch

Solver Record and Replay Flow

Solver record logs the solved values of random variables evaluated by randomize() calls during
simulation to a solver recording file. Solver replay reads the contents of a solver recording file
and applies the stored values of random variables to randomize() calls during simulation
Procedure
1. Run a simulation with solver record enabled:
vsim -solverecord[=<filename>]

For each randomize() call, the solver stores the solved values to a solver recording file
<filename> or solver.dat (if you do not specify the filename).
2. Re-run the simulation with solver replay enabled:
vsim -solvereplay[=<filename>]

Questa® SIM User's Manual, v2023.4 1229

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verification with Constrained Random Stimulus
Solver Reports

The solver replays randomize() results from the solver recording file <filename> or
solver.dat (if you do not specify the filename). Once the solver replay executes all the
randomize() calls recorded in the solver recording file, it evaluates any subsequent
randomize() calls in a normal (non-replay) manner.

Solver Reports
The simulator generates various solver reports at the Transcript window, which contain
information about random variables, constraints blocks, constraints, and testcases.

Table 22-3. Solver Reports

Report Description Generate With…
Solver Report Contains information related to the Command:
memory allocated by the constraint write report -solver
solver, and returns statistics for every
SystemVerilog randomize() call site See “write report”.
by filename and line number.
Solver Profile Report Contains performance information See “Enabling Solver Profiling
related to SystemVerilog and Reporting”.
randomize() calls invoked during
simulation.
Constraint Contains information related to the Command:
Contradiction Report randomize() calls that fail due no vsim -solvefaildebug
solutions.
See “vsim”.

Information Declared Within A Protected Region

• If you declare a random variable within a protected region, and the variable is not made
visible by a viewport, then the simulator excludes the variable information (name, type,
etc) from the solver reports, and replaces the variable by the “<protected>” keyword.
• If you declare a constraint block within a protected region, the simulator excludes the
constraint block name and all constraints in the constraint block from the solver reports,
and replaces the constraint block name and all constraints by the “<protected>”
keyword.
• If the generated testcase contains a variable or constraint that is declared within a
protected region, the simulator excludes all variable and constraint information from the
solver reports, and replaces them by the “<protected>” keyword.

1230 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 23
Coverage and Verification Management in
the UCDB

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233

A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Calculation of Total Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Where to Find Coverage Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Coverage and Simulator Use Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Coverage View Mode and the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Running Tests and Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Collecting and Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Name Selection for Test UCDB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247

Questa® SIM User's Manual, v2023.4 1231

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

Test Attribute Records in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Predefined Attribute Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Manage Test Data in UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Merging In A Multi-User Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Parallel Merge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 1272
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276
Viewing and Analyzing Verification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Storing User Attributes in the UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Viewing Test Data in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279
Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Customizing the Column Views in Verification Windows . . . . . . . . . . . . . . . . . . . . . . . . 1281
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Analysis for Late-stage ECO Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306

1232 Questa® SIM User's Manual, v2023.4

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 Questa SIM is a set of functionality which allows you to
manage your test environment.
A Flow for Verification of Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
What is the Unified Coverage Database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234

A Flow for Verification of Coverage

The flow described below represents a typical design verification process as it can be applied in
the Questa SIM environment.
Figure 23-1. Verification of a Design

Every project starts with a design specification. The specification contains elaborate details on
the design construction and its intent.

Questa® SIM User's Manual, v2023.4 1233

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 Questa SIM for all coverage data, deprecating previous separate
file formats for code coverage and functional coverage.

When created from Questa SIM, 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
Questa SIM, for example, Questa Formal created functional coverage and other user-defined
data.

1234 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1235

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
Coverage Binning and Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Coverage Aggregation in the Structure Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Coverage Calculation in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Coverage Calculation in the Tracker Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242

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

1236 Questa® SIM User's Manual, v2023.4

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.
Also refer to “Coverage Calculation in Test Plans” in the Verification Management
User’s Manual.
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.

Questa® SIM User's Manual, v2023.4 1237

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

The general algorithm for coverage aggregation can be expressed in the following formula:

where:

cov(t) = #covered bins / #bins1

t = the set of all coverage types

The coverage types (t) are as shown in Table 23-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 the table below, using the coverage
weight command. Additional methods for assigning weights are detailed for each type.
Table 23-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. Assertions may be
-assertcounts nor -assertdebug are used with weighted individually
vsim, the bin consists of only one bit that is set to through the Questa SIM user
1 if the assertion passes, and 0 if it does not (that interface2.
is, if the assertion status is fail, vacuous, disable
or active). If either -assertcounts 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.

1. In the case of conditions/expressions, this # is of terms rather than bins.

1238 Questa® SIM User's Manual, v2023.4

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 23-1. Coverage Calculation for Each Coverage Type (cont.)

Coverage Binning and Calculation Methods for cov(t) Weighting1
Type
Covergroup Performed as if $get_coverage() was called on Controlled by
the scope of aggregation. $get_coverage() is type_option.weight
described in SV1800-2017, Clause 19.11,
Coverage Computation.
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 Toggle Counts for 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

Questa® SIM User's Manual, v2023.4 1239

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

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

The information returned by these commands, along with Table 23-1, can help you understand
the Total Coverage number. See coverage analyze for further details.

Note on Transition Bin iff Enable Semantics

The exact semantic behavior of the bin enable expression applied to a transition bin is not
clearly explained in the SystemVerilog LRM ("Specifying bins for transitions" section). This is
the “iff” (expression) in a transition bins definition.

For a regular value-bin it is clear: If this expression is in the enable condition when the sample is
taken, and the bin value matches, the bin count increments. Otherwise the bin count does not
increment.

A transition bin counts the occurrence of a sequence of samples, and the bin enable may not be
stable as you track each of these sequence samples.

The Questa SIM implementation only tests the bin enable expression on the final transition bin
sequence sample that will trigger the bin count update and terminate the sequence matching.
The state of the transition bin enable expression is ignored at other intermediate sequence
sample points. This is equivalent to the regular bin behavior at the sample point where the count
is incremented.

Coverage Aggregation in the Structure Window

Aggregated coverage data is displayed in Total Coverage column of the Structure (sim)
window.
Coverage statistics are calculated either for the local instance, or recursively. The data
comprises the following on a per design region basis, where each sub-tree of design hierarchy
has its own set of metrics:

• covergroups
• cover directives
• assertion coverage
• code coverage

1240 Questa® SIM User's Manual, v2023.4

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 Calculation in the Browser Window

Figure 23-2. Aggregated Coverage Data in the Structure Window

The Structure window includes the Total Coverage column, which by default shows a weighted
average of all coverage types in the sub-tree recursively, including:

• covergroup type-based coverage

• cover directive coverage
• code coverage
• assertion coverage
• method and type_option.weight weighting
Cover directives are weighted using the weights you set (see “Weighting Cover Directives”).
By default, a cover directive is weighted equally with a covergroup type.

When you disable the default selection of Structure > Code Coverage > Enable Recursive
Coverage Sums, only constructs local to the current design instance contribute to the Total
Coverage number. In this mode, the Total Coverage column displays coverage information for
each design instance in isolation, and no contributions from child instances are taken into
account.

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.

Questa® SIM User's Manual, v2023.4 1241

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 Calculation in the Tracker Window

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.

1242 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 1243

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Name Selection for Test UCDB Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Saving Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Rerunning Tests and Executing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247

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 “Specify
Coverage Types for Data 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.

1244 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1245

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 SystemVerilog LRM; 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

1246 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1247

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

1248 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1249

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.

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

Predefined Attribute Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251

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

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.

1250 Questa® SIM User's Manual, v2023.4

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

• 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 or in post-sim
mode using the “coverage attribute” command.

Table 23-3 lists fields in the test attribute record (in the UCDB) that are predefined for users.

Caution
On Overriding Predefined Attributes, some risk is inherent in overriding 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 23-3. Predefined Fields in UCDB Test Attribute Record

Field / Attribute Override with Setting/Description
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.
SIMTIME Simulation time at completion of the test.
(In Questa SIM, 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 Questa SIM, the simstats command returns
the CPU time.)

Questa® SIM User's Manual, v2023.4 1251

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 23-3. Predefined Fields in UCDB Test Attribute Record (cont.)

Field / Attribute Override with Setting/Description
Name “coverage attribute”
CLI Command
DATE Timestamp is at the start of simulation.
If created by Questa SIM, 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.
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

1252 Questa® SIM User's Manual, v2023.4

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 23-3. Predefined Fields in UCDB Test Attribute Record (cont.)

Field / Attribute Override with Setting/Description
Name “coverage attribute”
CLI Command
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 Questa SIM to indicate severity levels and
other messages. If creating a new status indicator, it is strongly suggested that you use integers 6 and above.

Overriding TESTNAME Attribute

The TESTNAME attribute is a special-case attribute for tests because it is both an attribute and
a name of a test record. By changing its value you rename a test that was previously identified
with a default value or with a user-specified value. If you want to change the name of a test, you
must change the value of the TESTNAME attribute in the test record.

For example, suppose you want to rename a test called “originaltest” in a file that has not been
merged with other files into a UCDB. By definition, “originaltest” is the current value of the
TESTNAME attribute. To rename this test, you change the TESTNAME attribute with the
coverage attribute command as follows:

coverage attribute -name TESTNAME -value testA

The test’s name “originaltest” is changed to “testA.”

Now, if you merge this “testA” file with other test files and save the merged UCDB, the new
name will be present in the merged file to identify this particular test, and to differentiate it from
all the other tests in the UCDB.

The merged file contains multiple tests (multiple test records), and therefore, multiple
TESTNAME attributes. Each test within a merged file has its own test name stored in its
TESTNAME attribute.

To change the name of a test within a merged UCDB file, you must use the -test argument with
the coverage attribute command to identify the specific test you want to rename. For example,

Questa® SIM User's Manual, v2023.4 1253

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

suppose you want to rename “testA” in the merged file to “goldtest”. Use the coverage attribute
command as follows:

coverage attribute -test testA -name TESTNAME -value goldtest

This command will change both the TESTNAME attribute and the name of the test record.

1254 Questa® SIM User's Manual, v2023.4

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
Manage Test Data in UCDBs

Manage 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 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.
You might 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.

Merging Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255

Higher Performance Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Merging with the vcover merge Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Merging In A Multi-User Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Parallel Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Warnings During Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Modifying UCDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
About the Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Test-Associated Merge versus Totals Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 1272
Limitations of Merge for Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Merge Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276

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
• printing of condition and expression truth tables

Questa® SIM User's Manual, v2023.4 1255

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

• 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 23-4. The various options
within the dialog box correspond to the arguments available with the vcover merge
command.

1256 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1257

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

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

1258 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1259

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 1260

Merging Using a Master UCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260

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
Merging Using a Master UCDB

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

1260 Questa® SIM User's Manual, v2023.4

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 In A Multi-User Environment

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
Modifying UCDBs
Warnings During Merge
Merging and Source Code Mismatches

Merging In A Multi-User Environment

To allow merging of coverage results in a multi-user environment, irrespective of the paths of
the source files, Questa SIM incorporates the concept of file signatures.
The multi-user merging feature computes a file signature (32 Bit, MD5) for each source file.
Each file signature is dependent only on the contents, not the location, of the file. File signatures
are saved in the Library for later retrieval, and then dumped into the UCDB. The file signatures
are then used when merging.

Questa® SIM User's Manual, v2023.4 1261

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 In A Multi-User Environment

If file locations are the same, then the traditional merging occurs. But if file locations do not
match, the UCDB is merged based on the file signatures. If there are files with the same file
signatures, they are used for merging coverage bins. In other words, the merge will not perform
a union of bins but will add up the bins’ coverage count properly.

Note
File signatures are different from design unit signatures. In addition to the content of a
design unit, the design unit signature may also depend upon the way by which the design
unit gets compiled. Some common factors (in addition to the design unit content) that can affect
the design unit signature are:

• The timescale used to compile the design unit

• The -mfcu argument used with the vlog command
• The compile order of the design unit

File signature-based merging occurs as follows:

1. The file signature is dumped into the library when you compile the RTL. If a file has
multiple design units (DUs), then each DU contains the same file signature.
2. When you save the UCDBs after each simulation run, the file signature is searched in
the library and saved in the file table of the UCDBs.
3. These UCDBs can be taken to any environment and merged using the vcover merge
command. While merging, file signatures are taken into account.
To merge in a multi-user environment, and to generate file signatures, you must first compile
with the -covermultiuserenv argument to vcom or vlog.

Procedure
1. Compile your design with the -covermultiuserenv argument.
vcom/vlog -covermultiuserenv

This step generates file signatures for all source files.

2. Run vopt/vsim as required.
3. Generate a coverage database (UCDB) with the coverage save command.
4. Merge coverage databases using vcover merge -multiuserenv.
vcover merge -out <out_filename> <ucdb_1> <ucdb_2>... <ucdb_x> -multiuserenv

Your command might look like this:

vcover merge -out out.ucdb run1.ucdb run2.ucdb -multiuserenv

1262 Questa® SIM User's Manual, v2023.4

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 In A Multi-User Environment

Results
You can view the file signatures generated during compile with the vdir command:
vdir -l -lib <name_of_library> [name of module]

Your results may look like the following:

Figure 23-5. Example of File Signature

Questa® SIM User's Manual, v2023.4 1263

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

Parallel Merge
The vcover parallelmerge command performs a merge on a UCDB or CoverStore database
using parallel processes, automatically merging intermediate merge results, and producing the
final merged results.
Requirements for Parallel Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
The Parallel Merge Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Options Used for Building the Merge List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
Distribution of Files into Parallel Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266

Requirements for Parallel Merge

There is one requirement for the successful set-up and use of the parallel merge process:
• License feature ‘qvrm’ — Parallel merge requires the running of VRM, which is a
standard part of the Questa install but requires a license feature called 'qvrm'. The
feature is available with Questa Prime or as an option to Questa Core called Questa
Verification Management.

Modes of Operation
The parallel merge process can be run in three main modes of operation.
These modes are as shown in Table 23-4.
Table 23-4. Modes for Parallel Merge
Option Mode
-runmode local Run Locally on a machine with
multiple cores available.
-runmode rsh Run using rsh to remotely execute
merges on defined machines.
-runmode lsf | sge | uge | Run using various types of grid
rtda software.

A full list of arguments used for parallel merge is found in vcover parallelmerge.

The Parallel Merge Process

There are three stages to the parallel merge process.
• Stage 1: The file list, which contains a list of UCDB files to be merged, is either supplied
or built.

1264 Questa® SIM User's Manual, v2023.4

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

o If the file list is supplied, the UCDB files and their full absolute paths need to appear,
one per line, in the text file.
o If the file list is built, then relevant options must be provided for search name, search
directory, and the teststatus filtering. See options Used for Building the Merge List
for specific details.
• Stage 2: The original file list is split into a certain number of parallel merges.
o Depending on options provided (according to the run mode of the operation),
parallel jobs will run either locally on a multi-core machine, via remote shell to
specified machines or on a compute farm managed by grid software. See Options
Used for Splitting First Level Merges for specific details.
o Once the file list has been split into the number of jobs required, then the first level
Merge processes are launched, using the method set by the -runmode option.
• Stage 3: When the first level merges are complete, an intermediate UCDB file is
generated.
o These intermediate files are managed internally by auto-merge algorithm in vcover
for second level merge.
o Vcover automatically merges intermediate UCDB files as the first level merges are
completed.
o Final merged file is then generated based on the prefix name provided by -outname
option.

Options Used for Building the Merge List

The vcover parallelmerge arguments used to build the merge list are the following.

Table 23-5. Merge List Options

Argument Function Performed Setting
-genlist Generates file list from Default is the current directory
$cwd or $cwd/CoverStore
database location
-genlistfrom Generates the file list from NA
given database locations
-filelist Specifies the file list name Default is $cwd/parallellist
and path
-ucdbname Defines the name pattern Default is the string “*.ucdb”
list of UCDB file(s) used to
search and build the merge
list

Questa® SIM User's Manual, v2023.4 1265

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

Table 23-5. Merge List Options (cont.)

Argument Function Performed Setting
-teststatus Defines the file list for Options:
merging based on the • all — all tests in the original file
TESTSTATUS value in the list are added to the merge file
test record of each UCDB list
• passed — only the
TESTSTATUS results of Note
and Warning are added
• failed — only TESTSTATUS
results of Error and Fatal are
added
Note: If the leaf file is a merged file
itself, then it is included in file list,
irrespective of TESTSTATUS.
Seevcover parallelmerge for more information on these and all other available options.

Distribution of Files into Parallel Processes

The number of files which are distributed and split into parallel processes is determined by the
mode of operation:
• For local and grid modes, the number of jobs that the list is split into is set by the -j
argument. Further controls can be exerted, such as:
o For local mode: the vrun -j switch further controls the actual number of jobs
launched.
o For grid mode, the -gridslots argument controls the number of jobs that will run
concurrently.
• For rsh mode, the -hostlist parameter controls the number of jobs to split the list into by
the number of entries it contains.

1266 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Multiple Test Data Records with Same Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Merging and Source Code Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268

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

Questa SIM 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 Questa SIM 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)

Questa® SIM User's Manual, v2023.4 1267

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, Questa SIM 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.

1268 Questa® SIM User's Manual, v2023.4

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

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

Modifying UCDBs
It is possible, and can sometimes be useful to edit the contents of a UCDB.

Questa® SIM User's Manual, v2023.4 1269

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

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 23-1, which illustrates this case. The full example,
including all necessary files, can be found in <install_dir>/examples/ucdb/coverageedit.

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

Figure 23-6. 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).

1270 Questa® SIM User's Manual, v2023.4

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

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
Covergroup Bin Reporting and Timestamps

About the Merge Algorithm

Several issues related to the merge algorithm are important to note.
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 Questa SIM 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

Questa® SIM User's Manual, v2023.4 1271

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

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

1272 Questa® SIM User's Manual, v2023.4

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

• -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.
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 (orApply)
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

Questa® SIM User's Manual, v2023.4 1273

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

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 23-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 23-3.
For these cases, your best option may be to preserve the original UCDBs and analyze or rank
them individually.

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

1274 Questa® SIM User's Manual, v2023.4

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

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.

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

Questa® SIM User's Manual, v2023.4 1275

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.

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

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

1276 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 1277

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Viewing Test Data in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Viewing Test Data in the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1279
Deleting UCDB Files from the Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Invoking Coverage View Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Customizing the Column Views in Verification Windows. . . . . . . . . . . . . . . . . . . . . . . . 1281
Ranking Related Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
HTML Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Retrieving Test Attribute Record Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Analysis for Late-stage ECO Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306

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

Data related to the management of your verification data can be viewed in the Verification
Browser and Verification Tracker windows (Layout > VMgmt or View > Verification
Management).

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.

1278 Questa® SIM User's Manual, v2023.4

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

Setting Colors for Coverage Display

You can configure the colors for the threshold coverage numbers by selecting the
Tools > Coverage Configuration > Colorization menu option.

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

Questa® SIM User's Manual, v2023.4 1279

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

1280 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1281

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.

1282 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Group Ranking of Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Viewing Ranked Test Data in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
Merged Results vs. Rank Report Coverage: Why They Can Differ . . . . . . . . . . . . . . . . 1286
Ranking Most Effective Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Test-Associated vs. Iterative Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286

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.

Questa® SIM User's Manual, v2023.4 1283

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

Note
If you use the -groupby option, (for example, vcover ranktest myucdb -groupby testname)
the righthand column of the transcript displays the number of tests within each group.

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.

1284 Questa® SIM User's Manual, v2023.4

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

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

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 23-8, 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.

Questa® SIM User's Manual, v2023.4 1285

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 23-8. 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 23-8, 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.

1286 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1287

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
Generating ASCII Text Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Generating HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290

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

• Select a UCDB in the Browser window, then select Tools > Coverage Report > Text
orHTML orExclusions.
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.

1288 Questa® SIM User's Manual, v2023.4

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 23-9. 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. (-srcfile switch with
coverage report).

Questa® SIM User's Manual, v2023.4 1289

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. (-instance with
coverage report).
All design units — Reports data in all instances of each design unit, merged together. (-
du 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
Verification with Functional Coverage
Code Coverage

Generating HTML Coverage Reports

You can create on-screen 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.
See vcover report -html for more information.

1290 Questa® SIM User's Manual, v2023.4

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

Procedure
Generate a coverage report using one of the following methods:

If you want to ... Do the following

Generate an HTML report Use the -html argument with the coverage report or vcover report
from the command line. commands.
Generate an HTML report 1. Select File > Open from the main menu to choose a UCDB
from the GUI. file containing coverage data.
2. From the main menu, selectTools > Coverage
Report > HTML.
The Coverage HTML Report dialog box appears, which
enables 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 the coverage details you want to see in your report.

Questa® SIM User's Manual, v2023.4 1291

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 23-10. Coverage HTML Report Dialog Box

Results
• The HTML 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 23-11.

1292 Questa® SIM User's Manual, v2023.4

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 23-11. HTML Coverage Report Summary

Questa® SIM User's Manual, v2023.4 1293

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

The Questa Coverage Report Summary page is divided into a number of main areas.
• Navigation buttons — The top-right corner of the report contains buttons which remain
available no matter where you navigate within the report:
o Home Page — Navigates you to the HTML Coverage Report Summary Page.
o Design Units — Navigates you to a coverage summary organized by design unit.
This table contains coverage percentages for all coverage types, and can be sorted by
either the total coverage or any of the coverage types.
o Tests — Only present if you generated the report with the -testdetails argument, this
button navigates you to a summary of recorded tests included in the report.
o Testplan — Only present if you are working with a testplan, this button navigates
you to a page tracking the coverage of your testplan sections.
The coverage numbers in the Testplan Summary page are calculated in accordance
with the algorithms shown in “Coverage Calculation in Test Plans” in the
Verification Management User’s Manual.
• The center pane contains sections that display high level coverage summaries of a
number of types:
o Test Summary — Only present if you generate the report with the -testdetails
argument, the test summary displays a pie chart representing the overall status of
tests in the report.
o Instance Coverage Summary — Contains coverage numbers calculated using the
algorithms and weightings as described in Table 23-1.
The Instance Coverage Summary (Figure 23-12) includes Covergroups, Directives,
and Assertions hyperlinks to functional coverage consolidated views.
o Design Units Coverage Summary — Displays an overall design unit coverage
summary. This information is also contained within the more granular presentation
of design unit coverage in the Design Units Coverage page.
• Left side navigation pane — Enables you to navigate and search coverage data by
instance or design unit.
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.

1294 Questa® SIM User's Manual, v2023.4

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 23-12. Instance Coverage Summary

Exclusion comments you add with the coverage exclude -comment command will appear as
tooltips when you mouse over hit count cells denoted with a blue information icon. The
information icon is added to the cell to indicate that it contains an exclusion comment. For
example, Figure 23-13 displays the exclusion comment, “Exclusion comment: sample
comment” when you mouse over the cell that shows the failure count of the Assert_CPU_Write
assertion.
Figure 23-13. 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.

Questa® SIM User's Manual, v2023.4 1295

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

See coverage report -html for full details on these options.

1296 Questa® SIM User's Manual, v2023.4

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.
Canonical Toggle Nodes in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
option or type_option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Viewing Bins Hit by Certain Tests in HTML Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297
Cross Bins in HTML Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Generating Coverage Exclusion Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300

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

Information about which tests hit which bins (also known as, “tests-bins-hits”) is tracked and
displayed by the HTML report when enabled to do so. Enable the viewing of this information
by applying the -testhitdata argument to the coverage/vcover report’s -html command.
Note
If you are having trouble seeing aggregated bins in your design or if you are unclear about
whether you want to see functional coverage type bins or bins of a particular instance of a
covergroup type, refer to “Controlling Presence and Visibility of Aggregated Bins”.

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

Questa® SIM User's Manual, v2023.4 1297

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 23-14. Hyperlinked Bins in the Hits Column

1298 Questa® SIM User's Manual, v2023.4

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

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
clicking the Testname row.
Figure 23-15. Test-Bins-Hit-Table

Cross Bins in HTML Coverage Reports

HTML coverage reports present cross coverage data in a compact view that condenses the
display of bins with zero hits, and illustrates the presence of coverage holes. The compact view
aids you in identifying large coverage holes, and shortens coverage reports.
The Auto, Default, and User Defined Bins table displays coverage data when you select a
specific cross inside an HTML report. Each row contains coverage data for a cross bin, or group
of cross bins. The columns of the table contain the specific pieces of data that define each row:

• Columns corresponding to coverpoints — Contain fields that denote one of two things:
o The name of a specific bin pertaining to the cross bin described by the row.
o An asterisk (*), signifying that the simulator recorded no hits on any bin in the
coverpoint, in combination with other coverpoint column values in the row.
• Bins column — If the row describes a coverage hole, this column contains the number
of bins in the coverage hole.
• At Least column — Describes the number of hits necessary to meet the coverage goal.
• Hits column — Describes the number of hits that occurred during testing.

Questa® SIM User's Manual, v2023.4 1299

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 23-16. HTML Coverage Report Cross Data Table

Consider Figure 23-16, the last row of the table contains coverage data for a coverage hole
within cross_3_8_16. The asterisk in the reg_16 column of this row indicates that, in
combination with bin auto[4:7] of coverpoint reg_3, and bin auto[128:255] of coverpoint reg_8,
the simulator recorded no hits on any bin in coverpoint reg_16. The Bins column indicates that
this coverage hole is comprised of two bins.

Note
This style of compact coverage reporting only applies to bins with zero hits, not bins that
merely fail to meet the coverage goal. HTML coverage reports list covered bins, excluded
bins (in the case that -showexcluded is in effect), and hit-but-uncovered bins in individual rows.

You can modify the behavior of compact cross coverage reporting when you generate HTML
reports with either the vcover report or coverage report commands.

• -nocompactcrossbins — Disables the compact view.

• -usecnpm — By default, you disable compact reporting when you specify this argument.

Note
Text coverage reports use the same asterisk notation for compact coverage reporting as
HTML coverage reports.

Generating Coverage Exclusion Reports

Access:
GUI: Tools > Coverage Report > Exclusions
Command Line: coverage report -excluded

1300 Questa® SIM User's Manual, v2023.4

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

Create a coverage exclusion report within the GUI as follows.

Figure 23-17. Coverage Exclusion Report Dialog

Procedure
1. Select Pragma and/or User Defined Exclusions to report.
2. Save the pathname.
3. Click OK.

Questa® SIM User's Manual, v2023.4 1301

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Setting up or Modifying a Filter for UCDB Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
Applying a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Filtering Results by User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304

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.

1302 Questa® SIM User's Manual, v2023.4

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

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.
b. Choose Filter > Apply, and then select a filter from the list.

Questa® SIM User's Manual, v2023.4 1303

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

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.

1304 Questa® SIM User's Manual, v2023.4

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

Figure 23-19. 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.

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.

Questa® SIM User's Manual, v2023.4 1305

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

Procedure
Use one of the following methods to retrieve test attribute record contents.

To retrieve from ... Do the following

the simulation database Use coverage attribute. For example:
during simulation. coverage attribute
a UCDB file during Use vcover attribute. For example:
simulation vcover attribute <file>.ucdb
a UCDB file loaded with - Use coverage attribute. For example:
viewcov coverage attribute -test <testname>

Results
The Verification Browser and Tracker windows display columns which correspond to the
individual test data record contents, including name/value pairs created by the user. The pre-
defined attributes that appear as columns are listed in Table 23-3.

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

1306 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 24
C Debug

C Debug allows you to interactively debug FLI/PLI/VPI/DPI/SystemC/C/C++ source code with

the GNU Debugger (gdb), which is open-source debugging software.
Even though C Debug does not provide access to all features of the GNU Debugger (gdb), you
can find additional information on gdb on the following web site:

s GDB: The GNU Project Debugger

For debugging memory errors in C source files, refer to the application note provided with the
following Knowledge Base article (MG575561) on Support Center: “Using the Valgrind Tool
with ModelSim.”

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 Siemens EDA sales representative.

Before you use C Debug, you should note the following qualifications and requirements:

• C Debug is an interface to the open-source gdb debugger. Questa SIM 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 Questa SIM. 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++.
Supported Platforms and gdb Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Setting Up C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Running C Debug from a DO File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309

Questa® SIM User's Manual, v2023.4 1307

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

Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310

Stepping in C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311
Quitting C Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Finding Function Entry Points with Auto Find bp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313
Identifying All Registered Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314
Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
Debugging Functions when Quitting Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
C Debug Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322

Supported Platforms and gdb Versions

Questa SIM ships with the gdb version 10.2.0, 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-10.3.0 gdb-10.2.0
64-bit) gcc-7.4.0
Windows (both 32-bit gcc 7.4.0 gdb-10.2.0
and 64-bit)

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 Questa SIM. You cannot use C Debug to debug source that
you have compiled with Microsoft Visual C++.

You should install the gcc/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.

1308 Questa® SIM User's Manual, v2023.4

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

Procedure
1. Compile and link your C code with the -g argument to sccom (to create debug symbols)
and without -O (or any other optimization switches you normally use). See SystemC
Simulation for 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 24-1. Specifying Path in C Debug setup Dialog

Select either:
• default — to point at the supplied version of gdb
• custom — to point at a separate installation.
3. Start the debugger by selecting Tools > C Debug > Start C Debug . Questa SIM 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:
gdb dir <srcdirpath1>[:<srcdirpath2>[...]]

Running C Debug from a DO File

You can run C Debug from a DO file but you should be aware of a configuration issue where 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

Questa® SIM User's Manual, v2023.4 1309

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
C Debug
Setting Breakpoints

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

Setting Breakpoints
Breakpoints in C Debug work much like normal HDL breakpoints. You can create and edit
them with Questa SIM commands (bp, bd, enablebp, and disablebp) or within a Source window
in the GUI.
Some differences for breakpoint usage do exist:

• The Modify Breakpoints dialog box, accessed by selecting Tools > Breakpoints, in the
Questa SIM 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

1310 Questa® SIM User's Manual, v2023.4

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

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

Figure 24-2. Setting Breakpoints in Source Code

Clicking the red ball with your right mouse button pops up a menu with commands for
removing or enabling/disabling the breakpoints.

Figure 24-3. Right Click Pop-up Menu on Breakpoint

Restriction
The gdb debugger has a known problem 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
To step in C Debug you use the same buttons and commands that you use when working with an
HDL-only design.

Questa® SIM User's Manual, v2023.4 1311

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

Table 24-1. Simulation Stepping Options in C Debug

Button Menu equivalent Other equivalents
Step Into Tools > C Use the step command at the
Debug > Run > Step CDBG> prompt
steps the current simulation to the next
statement; if the next statement is a call
to a C function that was compiled with
debug info, Questa SIM will step into
the function
Step Over Tools > C use the step -over command at
Debug > Run > Step- the CDBG> prompt
statements are executed but treated as Over
simple statements instead of entered
and traced line-by-line; C functions are
not stepped into unless you have an
enabled breakpoint in the C file
Tools > C use the run -continue
Continue Run Debug > Run > Cont command at the CDBG>
continue the current simulation run inue prompt
until the end of the specified run length
or until it hits a breakpoint or specified
break event

Debugging Active or Suspended Threads

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.

1312 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Quitting C Debug

Quitting C Debug
End a 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:
cdbg quit

Note
It is recommended that you invoke C Debug once for a given simulation and then
quit both C Debug and Questa SIM. 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
Questa SIM can automatically locate and set breakpoints at all currently known function entry
points.
This ability applies to:

• PLI/VPI/DPI system tasks and functions and callbacks

• FLI subprograms and callbacks and processes created with mti_CreateProcess).
Invoke this feature by selecting Tools > C Debug > Auto find bp.

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, Questa SIM 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, assume 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, the
simulator will stop on the breakpoint set in the called C file.

Questa® SIM User's Manual, v2023.4 1313

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, the simulator 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, the simulator does not step into the C code.

When you first enable Auto step mode, the simulator 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314

Auto Find bp Versus Auto Step Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316

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 following graphic shows a simulation that has stopped at a user-set breakpoint on a PLI
system task.

1314 Questa® SIM User's Manual, v2023.4

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 24-4. Simulation Stopped at Breakpoint on PLI Task

Because you enabled Auto step mode, the simulator automatically sets a breakpoint in the
underlying xor_gate.c file. If you click the step button at this point, the simulator will step into
that file.

Questa® SIM User's Manual, v2023.4 1315

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 24-5. Stepping into Next File

Auto Find bp Versus Auto Step Mode

The Auto find bp command 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.

1316 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317
FLI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318
PLI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319
VPI Functions in Initialization Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Completing Design Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321

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,
the simulator 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, the simulator 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 24-6. Function Pointer to Foreign Architecture

Questa® SIM User's Manual, v2023.4 1317

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. The simulator 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, the simulator hits that
breakpoint and displays the file and associated line in a Source window.
Figure 24-7. Highlighted Line in Associated File

FLI Functions in Initialization Mode

There are two kinds of FLI functions you may encounter in initialization mode. The first is a
foreign architecture and the second is a foreign function.
The simulator 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 ()

1318 Questa® SIM User's Manual, v2023.4

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, such as:

bp -c in_params

or the function pointer:

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

The simulator produces messages in initialization mode depending on your registration method
of callback functions in PLI; using a veriusertfs array to define all usertf entries or adding an
init_usertfs function to explicitly register each usertfs entry.
The simulator 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

Questa® SIM User's Manual, v2023.4 1319

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

You cannot set breakpoints on null functions. The sizetf and misctf entries in the example above
are null (the function pointer is '0x0').

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

The second registration method uses init_usertfs functions for each usertfs entry. The simulator
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:

bp -c init_usertfs

or the function pointer

bp -c *0x40019bec

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

The simulator will hit this breakpoint as you continue through initialization.

1320 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 C Debug
Completing Design Load

Completing Design Load

Instructing C Debug to complete the design load without stopping.
If you are through looking at the initialization code you can select Tools > C
Debug > Complete load at any time, and the simulator 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
The Stop on quit mode allows you to debug functions that are called when the simulator exits.
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 Tools > C Debug > C Debug Setup from the main menu.
3. Select Stop on quit in the C Debug setup dialog box (Figure 24-8).
4. Click OK.
Figure 24-8. Stop on quit Button in C Debug Setup Dialog Box

5. When you enable this mode, 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 the simulator.
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, the simulator automatically quits C-debugger and the GUI (whether or not a
C breakpoint was hit and you return to the simulator prompt).

Questa® SIM User's Manual, v2023.4 1321

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

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 24-2. Command Reference for C Debug

Command Description Corresponding GUI action
bd Deletes a previously set C Right-click a breakpoint in the
breakpoint Source window and choose
Remove Breakpoint.
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 a breakpoint in the
breakpoint Source window and choose
Disable Breakpoint.
enablebp Enables a previously disabled C Right-click a breakpoint in the
breakpoint Source 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
after stopping on the Main or Source window
toolbar.
run -finish Continues running the simulation Tools > C
until control returns to the calling Debug > Run > Finish
function

1322 Questa® SIM User's Manual, v2023.4

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 24-2. Command Reference for C Debug (cont.)

Command Description Corresponding GUI action
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
tb Displays a stack trace of the C call Tools > C Debug > Traceback
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

Questa® SIM User's Manual, v2023.4 1323

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

1324 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 25
Classic Performance Profiler

The Questa SIM statistical sampling profiler provides instance-specific execution so you can
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. In addition, ASIC
and FPGA design flows benefit from the use of this tool.
For information about Functional Verification Profiling see the Profiling In Visualizer chapter
in the Visualizer Debug Environment User's Manual.
Note
The functionality described in this chapter requires an additional license. Contact your
Siemens EDA sales representative.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

Introducing Performance Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326

Getting Started with the Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Viewing Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330
Viewing Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334
Integration with Source Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335
Reporting Profiler Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336
Capacity Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1340
Constraint Solver Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354

Questa® SIM User's Manual, v2023.4 1325

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Introducing Performance Profiling

Introducing Performance Profiling

The profiler provides an interactive graphical representation of CPU usage on a per instance
basis. It shows you what part of your design is consuming resources (CPU cycles), 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.

Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326

Profile Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326

Statistical Sampling Profiler

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

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

1326 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Profile Database

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.

Questa® SIM User's Manual, v2023.4 1327

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Getting Started with the Profiler

Getting Started with the Profiler

You can enable the statistical sampling profiler from the graphic interface (with menu or toolbar
selections) or through the command line.

Enabling the Statistical Sampling Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328

Collecting Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328
Turning Profiling Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329
Running the Profiler on Windows with FLI/PLI/VPI Code . . . . . . . . . . . . . . . . . . . . . . 1329

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

Statistical sampling occurs during the execution of a Questa SIM run command. With profiling
enabled, all subsequent run commands will collect 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 is on, the status bar will display the number of Profile
Samples collected, as shown below. Each profile sample will become a data point in the
simulation’s performance profile.

Figure 25-1. Status Bar: Profile Samples

1328 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Turning Profiling Off

Turning Profiling Off

You can turn off profiling with any one of three methods.
Procedure
Perform any one of the following:

• Deselect the Performance option in the Tools > Profile menu.

• Deselect the Performance Profiling icon in the toolbar.
• Use the “profile off” command with the -p argument.
Results
Any Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1329

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
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 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1330

Design Units Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Calltree Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1331
Structural Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333

Ranked Window
The Ranked window displays the results of the statistical performance 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 25-2).

Figure 25-2. Ranked Window

You can sort ranked results by any other column by clicking the column heading.

1330 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Design Units Window

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 25-3. Design Units Window

Calltree Window
By default, the Calltree window sorts profiler results 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.
You can 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.

• Entries in the Name column of the Calltree window are indented in hierarchical order to
indicate which functions or routines call which others.

Questa® SIM User's Manual, v2023.4 1331

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Calltree Window

• 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 a given
function or instance is using of its parent’s total simulation time. From this column, you can
calculate the percentage of total simulation time used by any function. For example, if a
particular parent entry used 10% of the total simulation time, and it called a routine that used
80% of its simulation time, then the percentage of total simulation time spent in 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 25-4. Calltree Window

1332 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Structural Window

Structural Window
The Structural profile window displays instance-specific performance profile information in a
hierarchical structure format. The Structural profile window contains the same information
found in the Calltree window but adds an additional dimension with which to categorize
performance samples. It shows how call stacks are associated with different instances in the
design.
Figure 25-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 25-6).

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

Questa® SIM User's Manual, v2023.4 1333

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Viewing Profile Details

Viewing Profile Details

The Profiler increases visibility into simulation performance with dynamic links to the Source
window and the Profile Details window.
Enable the Profile Details window 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 25-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 25-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.

1334 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Integration with Source Windows

• 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.
The selected function is distinguished with an arrow on the left and in 'hotForeground'
color as shown below.
Figure 25-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
Profile data collection for the Calltree is on by default 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, Calltree, 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.

Questa® SIM User's Manual, v2023.4 1335

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Reporting Profiler Results

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

Reporting Profiler Results

Questa SIM allows you to easily create performance 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.

1336 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Reporting Profiler Results

• Choose Tools > Profile > Profile Report to open the Profile Report dialog
(Figure 25-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
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.

Performance profile data is displayed with a default cutoff of 0% — meaning, the

report contains any functions or instances that use simulation time — 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.

Questa® SIM User's Manual, v2023.4 1337

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Reporting Profiler Results

Figure 25-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 25-12.

1338 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Reporting Profiler Results

Figure 25-12. Profile Report Example

Questa® SIM User's Manual, v2023.4 1339

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Capacity Analysis

Capacity Analysis
Questa SIM 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
Questa SIM 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, as a
graph or as signal waveforms in the Wave window, or as a text-based report in the Transcript
window which you can also write to a text file.

Enabling or Disabling Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1341

Levels of Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Consolidated Memory Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344
Opening the Capacity Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Displaying Capacity Data in the Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1346
Writing a Text-Based Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
Reporting Capacity Analysis Data From a UCDB File . . . . . . . . . . . . . . . . . . . . . . . . . . 1352
Examining Memory Usage for Assertions and Cover Directives . . . . . . . . . . . . . . . . . . 1353

1340 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Enabling or Disabling Capacity Analysis

Enabling or Disabling Capacity Analysis

When you invoke Questa SIM, 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 25-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 25-1.
Table 25-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.
capstats [-du[+summary | +details | Reports data on memory Use the capstats command
+duname=<duname>]] [-decl] [- capacity in either the to display memory data.
line] [-filename <filename>] Transcript window or to a
file.
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.

Questa® SIM User's Manual, v2023.4 1341

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Enabling or Disabling Capacity Analysis

Table 25-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 from Displays the Capacity Same as entering the view
main menu window containing capacity capacity command.
data.

1342 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Levels of Capacity Analysis

Levels of Capacity Analysis

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Fine-grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Enabling Fine-Grain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344

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, Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1343

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
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 and then
the capstats 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
capstats command as follows:
capstats -decl -line -du+details

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 the capstats command in conjunction
with vsim -capacity. In addition, if you use vsim -capacity=line, you can generate the point of
allocation along with the point of declaration.

Rather than generate a large ascii report, you may use capstats -save to capture the information
into a database, which you can then load after the simulation with capstats -open. This provides
the ability to generate multiple smaller reports that are easier to traverse and analyze.

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.

1344 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Consolidated Memory Reports

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

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.

Questa® SIM User's Manual, v2023.4 1345

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Opening the Capacity Window

• 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.
• 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 25-13).
Figure 25-13. The Capacity Window

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.

1346 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
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 25-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 25-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

Questa SIM allows you to easily generate text-based reports of capacity data using the capstats
command.

Questa® SIM User's Manual, v2023.4 1347

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Writing a Text-Based Report

Procedure
1. The proper syntax for generating a text-based capacity data report with the capstats
command is:
capstats [-du [+summary | +details] [+duname=<duname>]] [-decl] [-line] [-filename
<filename>]

2. When you specify capstats with -du+summary, the tool reports coarse-grain analysis.
When you specify capstats with -du+details, it reports fine-grain analysis.
3. When you specify capstats -line, 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,

capstats -line -decl -du+details

when used with vsim -capacity=line, produces a point of allocation (line) based capacity report
with the following format:

=================
CAPSTATS REPORT
=================
==============
Report details
==============
Generated on : Wed Dec 7 12:06:30 2022
QuestaSim Version : DEV-main 5460573
QuestaSim Platform : linux_x86_64
Generated with capacity option : -capacity=line
Simulation time : 0ns
Created with options : du+details,decl,line
==================
End Report details
==================

==============================
Summary report for the process
==============================
Total Memory Allocated for the Process (VSZ) : 483.95 Mb
Total Memory in-use by the Process (RSS) : 20.89 Mb
Total Peak Memory Allocated by vsim : 128.00 Mb
Total Current Memory Allocated by vsim : 128.00 Mb
==================================
End Summary report for the process
==================================

1348 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Writing a Text-Based Report

=================================
Summary report for each category
=================================
UNUSED : 122.92 Mb
HDL : 1.39 Mb
FREED : 1.00 Mb
SIM_CODE : 512.02 Kb
SESSION_INFO : 448.52 Kb
DESIGN_UNITS : 384.00 Kb
LIBRARY_INFO : 384.00 Kb
DEBUG : 256.00 Kb
OPT_DESIGN : 256.00 Kb
PLI : 128.00 Kb
UCDB : 128.00 Kb
PROFILER : 128.00 Kb
----------------------------------------------
TOTAL Current Memory : 127.88 Mb
=================================
Summary report for freed pools
=================================
ELAB_CODE : 512.02 Kb
ELABORATION : 384.00 Kb
=====================================
End Summary report for each category
=====================================

==================================
Detailed report for each category
==================================
******************************************************************
UNUSED : 122.92 Mb
******************************************************************
HDL : 1.39 Mb
---------------------------------------------------
STATIC HDL : 861.75 Kb
---------------------------------------------------
Assertions : 779.29 Kb
Kernel : 60.48 Kb
Nonblocking Assigns : 8.59 Kb
Variable Objects : 3.53 Kb
Function Objects : 3.25 Kb
Class Objects : 1.92 Kb
Capacity UI : 1.39 Kb
Processes : 840.00 B
Module Objects : 616.00 B
QIS : 512.00 B
Block Objects : 456.00 B
PLI : 416.00 B
Parameter Objects : 360.00 B
Process Objects : 80.00 B
User Interface : 48.00 B
Assertion Objects : 40.00 B
---------------------------------------------------
DYNAMIC HDL : 31.41 Kb
---------------------------------------------------
Classes : 30.75 Kb
Assertions : 672.00 B

Questa® SIM User's Manual, v2023.4 1349

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Writing a Text-Based Report

---------------------------------------------------
UNUSED HDL : 341.41 Kb
---------------------------------------------------
******************************************************************
FREED : 1.00 Mb
******************************************************************
ELAB_CODE : 512.02 Kb
******************************************************************
SIM_CODE : 512.02 Kb
******************************************************************
SESSION_INFO : 448.52 Kb
******************************************************************
ELABORATION : 384.00 Kb
******************************************************************
DESIGN_UNITS : 384.00 Kb
******************************************************************
LIBRARY_INFO : 384.00 Kb
******************************************************************
DEBUG : 256.00 Kb
******************************************************************
OPT_DESIGN : 256.00 Kb
******************************************************************
PLI : 128.00 Kb
******************************************************************
UCDB : 128.00 Kb
******************************************************************
PROFILER : 128.00
Kb******************************************************************
======================================
End Detailed report for each category
======================================

====================
DU based HDL report
====================
Design units consuming memory : 4
Total memory accounted under DUs : 33.92 Kb
HDL memory not accounted under DUs : 1.36 Mb

DU std : 28.20 Kb (Instance count : 1, Language : System Verilog,

Timescale : 1ns / 1ns, acc : abclmnprstuv)
Classes : 22.02 Kb
Variable Objects : 2.27 Kb
Function Objects : 1.62 Kb
Classes UI : 1.17 Kb
Parameter Objects : 360.00 B
QIS : 288.00 B
Kernel : 204.00 B
Block Objects : 184.00 B
Module Objects : 104.00 B

DU pkg : 4.97 Kb (Instance count : 1, Language : System Verilog,

Timescale : 1ns / 1ns, acc : <none>)
Function Objects : 1.62 Kb
Variable Objects : 1.27 Kb
Classes : 869.00 B
Classes UI : 528.00 B
Processes : 232.00 B

1350 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Writing a Text-Based Report

Block Objects : 216.00 B

Kernel : 152.00 B
Module Objects : 104.00 B
Process Objects : 32.00 B

DU mid1 : 624.00 B (Instance count : 1, Language : Verilog,

Timescale : 1ns / 1ns, acc : <none>)
Processes : 464.00 B
Classes : 64.00 B
Process Objects : 48.00 B
Block Objects : 48.00 B

DU top : 144.00 B (Instance count : 1, Language : Verilog,

Timescale : 1ns / 1ns, acc : <none>)
Module Objects : 80.00 B
Kernel : 56.00 B
Block Objects : 8.00 B

========================
End DU based HDL report
========================

======================================
DU based dynamic HDL report:
======================================
DU pkg : 4.97 Kb (Instance count : 1, Language : System Verilog)
Classes : 64.00 B
cls1 : 64.00 B (Objects : 1, File : test2.sv, Line : 5)
DU mid1 : 624.00 B (Instance count : 1, Language : Verilog)
Classes : 64.00 B
cls2 : 64.00 B (Objects : 1, File : test2.sv, Line : 21)
========================================
End DU based dynamic HDL report:
========================================

======================================
Declaration based Dynamic HDL report:
=====================================
Reporting total capacity data for class objects
Objects CurrMem PeakMem PeakTime@ns
---------- ---------- ---------- -------------
2 30.8K 30.8K 0

Reporting detailed capacity data for class objects

Objects CurrMem Name Type FileInfo
---------- ---------- ----------- -------- -----------------
0 30.6K GC overhead Class -
1 64B cls1 Class test2.sv(2)
1 64B cls2 Class test2.sv(6)

Reporting total capacity data for Assertions/Covers

Threads CurrMem PeakMem PeakTime@ns
---------- ---------- ---------- -------------
0 672B 672B 0

Reporting detailed capacity data for Assertions/Covers

Threads CurrMem Name Type FileInfo
--------- ---------- ----------------- ----------- ----------

Questa® SIM User's Manual, v2023.4 1351

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Reporting Capacity Analysis Data From a UCDB File

0 672B Assertion Kernel Assertion -

=========================================
End Declaration based Dynamic HDL report:
=========================================

==============================
Line based Dynamic HDL report:
==============================
Reporting total capacity data for class objects
Objects CurrMem PeakMem PeakTime@ns
---------- ---------- ---------- -------------
2 30.8K 30.8K 0

Reporting detailed point of allocation based capacity data for class

objects
Objects CurrMem Name Type FileInfo
---------- ---------- ------------- -------- --------------
0 30.6K GC overhead Class -
1 64B cls1 Class est2.sv(5)
1 64B cls2 Class test2.sv(21)

Reporting total capacity data for Assertions/Covers

Threads CurrMem PeakMem PeakTime@ns
---------- ---------- ---------- -------------
0 672B 672B 0

Reporting detailed capacity data for Assertions/Covers

Threads CurrMem Name Type FileInfo
--------- --------- -------------- ----------- -----------
0 672B Assertion Kernel Assertion -

==================================
End Line based Dynamic HDL report:
==================================

=====================
END CAPSTATS REPORT
=====================

Note
'UNKNOWN' object name is displayed if the object is either an implicit object or it is in
protected part of the design.

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.

1352 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Classic Performance Profiler
Examining Memory Usage for Assertions and Cover Directives

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 fine grained profile report of memory usage for assertions and cover directives.
The assertion profile command presents memory usage data in three columns of the Assertions
and Cover Directives browsers: current memory, peak memory, and peak memory time.

If you use assertion profile in the middle of the simulation, memory usage profiling starts|stops
from that simulation time onwards. The command does not require that you compile designs
with +acc, or that you run vsim in the -assertdebug mode. You can give the command in a fully
optimized simulation run.

Questa® SIM User's Manual, v2023.4 1353

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Classic Performance Profiler
Constraint Solver Profiling

Constraint Solver Profiling

The Questa SIM random constraint solver stores performance information about the
SystemVerilog randomize() calls invoked during simulation and reports on how much time is
spent in which constraints, and which constraints are the most expensive to solve.
The random constraint solver is different from vsim profiling. It does not store profiling
information based on fine grain function calls. Rather, it profiles the CPU time spent in
“Regions” of the solver as opposed to every function call.

You can enable constraint solver profiling with the profile option commands.

1354 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 26
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.
With the VHDL-2008 standard, VHDL supports hierarchical referencing as well. However, you
cannot reference from VHDL to Verilog. The Signal Spy procedures and system tasks provide
hierarchical referencing across any mix of Verilog, VHDL and/or SystemC, allowing you to
monitor (spy), drive, force, or release hierarchical objects in mixed designs. While not strictly
required for references beginning in Verilog, it does allow references to be consistent across all
languages.

Signal Spy Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1356

Signal Spy Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359

Questa® SIM User's Manual, v2023.4 1355

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.
Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

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 “System Verilog System
Tasks and Functions.”
Table 26-1. Signal Spy Reference Comparison
VHDL procedures Verilog system tasks SystemC function
disable_signal_spy() $disable_signal_spy() disable_signal_spy()
enable_signal_spy() $enable_signal_spy() enable_signal_spy()
init_signal_driver() $init_signal_driver() init_signal_driver()
init_signal_spy() $init_signal_spy() init_signal_spy()
signal_force() $signal_force() signal_force()
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.

The command vopt has two arguments to manage spy signals.

• -spyaccess[+scope]. Analyze signal spy code and enable access for the signals being
used. The +scope enables access on all the objects in the scopes identified in signal spy
code when names of the objects are not statically available.
• spyaccesslogfile=<path>. File where information about different paths in signal spy will
be dumped
For example, the following option enable access setting on the signals being used in the
$signal_force system tasks.

vopt -uvmaccess -spyaccess -o my top

1356 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Signal Spy
Signal Spy Formatting Syntax

class c1 #(int p1 = 1, p = p1, p2 = 2);

task mytask(int sel , logic index);
begin
| logic [63:0] tmp ;
string str1 = "top.dut" ;
string str2 ;
str2 = $sformatf("%s.sig2" ,str1) ;
tmp=64'h5555_5555_5555_5555_5555_5555_5555_5555;
$signal_force(str2,tmp);
endtask

Signal Spy Formatting Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357

Signal Spy Supported Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
Signal Spy Unsupported Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358

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

Questa® SIM User's Manual, v2023.4 1357

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

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

Signal Spy Unsupported Types

Signal Spy provides no support for the following.
• SystemC variables

1358 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
enable_signal_spy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
init_signal_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
init_signal_spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
signal_force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1372
signal_release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376

Questa® SIM User's Manual, v2023.4 1359

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

1360 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1361

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

1362 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1363

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.

1364 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1365

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

1366 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1367

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.

1368 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1369

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.

1370 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1371

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

1372 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1373

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.

1374 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1375

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

1376 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1377

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Signal Spy
signal_release

1378 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 27
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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380

Running JobSpy from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382
Running the JobSpy GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Viewing Results During Active Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387
Licensing and Job Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Checkpointing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1388
Connecting to Load-Sharing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389

Questa® SIM User's Manual, v2023.4 1379

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
Start the JobSpy Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
Set the JOBSPY_DAEMON Variable as a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 1381

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 1380”
• directory — Refer to the section ““Set the JOBSPY_DAEMON Variable as a
Directory” on page 1381”

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

1380 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1381

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 Questa SIM
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1382

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

1382 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1383

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Invoking Simulation Commands in Job Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384
Interactive Job Session Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
View Commands and Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386

Starting Job Manager

You can start Job Manager with a command from a shell prompt or with Questa SIM 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 27-2) to
access menu commands.

1384 Questa® SIM User's Manual, v2023.4

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 27-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 27-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 Questa SIM command at the prompt.
However, you need to be careful as many Questa SIM commands will not function properly
with JobSpy.

Questa® SIM User's Manual, v2023.4 1385

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.

1386 Questa® SIM User's Manual, v2023.4

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 27-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.
Viewing Waveforms from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387

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 *

2. Save a dataset

Questa® SIM User's Manual, v2023.4 1387

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

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

1388 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1389

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring Flowtracer for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring Grid Engine for Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390

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>/questasim/<platform>
<platform> refers to the VCO for the Questa SIM 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>/questasim/<platform>/jobspy -check

1390 Questa® SIM User's Manual, v2023.4

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

where <platform> refers to the VCO for the Questa SIM installation (for example, linux,
sunos5, and so forth). See the Installation Guide for a complete list.
3. Set the Migration Command field to:
<install_dir>/questasim/<platform>/jobspy -check k

4. Consult the Grid Engine documentation for additional information.

Questa® SIM User's Manual, v2023.4 1391

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

1392 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 28
Generating Stimulus with Waveform Editor

The Questa SIM 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.
• Edit waveforms with numerous functions including inserting, deleting, and stretching
edges; mirroring, inverting, and copying waveform sections; and changing waveform
values on-the-fly.
• 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.
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Using Waveform Editor Prior to Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Accessing the Create Pattern Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Creating Waveforms with Wave Create Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Editing Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Selecting Parts of the Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Stretching and Moving Edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Simulating Directly from Waveform Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Exporting Waveforms to a Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Driving Simulation with the Saved Stimulus File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
Signal Mapping and Importing EVCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404

Questa® SIM User's Manual, v2023.4 1393

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

Saving the Waveform Editor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1405

1394 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Using Waveform Editor After Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396

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 28-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 28-2).

Questa® SIM User's Manual, v2023.4 1395

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 28-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 28-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”).

1396 Questa® SIM User's Manual, v2023.4

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 28-4. Note that the
Drive Type field is not present for input and output signals.
Figure 28-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 28-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.

Questa® SIM User's Manual, v2023.4 1397

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 28-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,
Questa SIM 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.

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

1398 Questa® SIM User's Manual, v2023.4

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

5. The table below summarizes the editing commands that are available.

Table 28-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; Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1399

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

1400 Questa® SIM User's Manual, v2023.4

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 28-6. Manipulating Waveforms with the Wave Edit Toolbar and Cursors

Selection and Zoom Percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401

Auto Snapping of the Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Stretching and Moving Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402

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

Questa® SIM User's Manual, v2023.4 1401

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 28-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. Questa SIM
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.

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.

1402 Questa® SIM User's Manual, v2023.4

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

Procedure
To save the waveform data, select File > Export > Waveform or use the wave export
command.

Figure 28-7. Export Waveform Dialog

You can save the waveforms in four different formats:

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

Questa® SIM User's Manual, v2023.4 1403

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 28-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, Questa SIM 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 Questa SIM 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 28-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 Questa SIM.

1404 Questa® SIM User's Manual, v2023.4

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

Saving the Waveform Editor Commands

When you create and edit waveforms in the Wave window, Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1405

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

1406 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 29
Standard Delay Format (SDF) Timing
Annotation

This chapter covers the Questa SIM 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
Questa SIM.

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
Questa SIM can read SDF files that were compressed using gzip. Other compression
formats (for example, Unix zip) are not supported.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

Specifying SDF Files for Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408

Compiling SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411
VHDL VITAL SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1412
Verilog SDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
SDF for Mixed VHDL and Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Interconnect Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Disabling Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428

Questa® SIM User's Manual, v2023.4 1407

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

Questa SIM 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 vopt and 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.

Recommended Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408

Instance Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408
SDF Specification with the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Errors and Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409

Recommended Flows
How you specify your SDF file differs depending on whether you are using the three-step or the
two-step optimization flow for your design simulation.
In the Three-Step Flow (compile, optimize, simulate), specify the SDF file on the vopt
command line (as opposed to the vsim command line) because vopt uses information extracted
from the SDF file to ensure visibility of objects for annotation in the vsim step.

In the Two-Step Flow (compile, simulate), specify the SDF files on the vsim command line.

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,

1408 Questa® SIM User's Manual, v2023.4

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 Specification with the GUI

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

Questa® SIM User's Manual, v2023.4 1409

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

Another option is to use the SDF tab from the Start Simulation dialog box (Figure 29-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.

1410 Questa® SIM User's Manual, v2023.4

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

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

You should be aware of the following limitations 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

• Place all $sdf_annotate() calls in a single initial block when they are order-dependent.

Questa® SIM User's Manual, v2023.4 1411

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

The IEEE Std 1076.4-2000, IEEE Standard for VITAL ASIC Modeling Specification describes
how cells must be written to support SDF annotation. The following summary reviews how
SDF constructs are mapped to associated VHDL generic names, and may help you understand
simulator error messages. VHDL SDF annotation works on VITAL cells only.
SDF to VHDL Generic Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413

1412 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1413

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

1414 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416
SDF to Verilog Construct Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418

Questa® SIM User's Manual, v2023.4 1415

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.

1416 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1417

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 29-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 Questa SIM 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 29-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 29-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.

1418 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1419

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 29-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 29-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 29-11. Matching SDF RECREM to Verilog

SDF Verilog
(RECREM (negedge reset) (posedge clk) (5) $recovery(negedge reset, posedge clk, 0);
(5))
(RECREM (negedge reset) (posedge clk) (5) $removal(negedge reset, posedge clk, 0);
(5))
(RECREM (negedge reset) (posedge clk) (5) $recrem(negedge reset, posedge clk, 0);
(5))

• SKEW is matched to $skew:

Table 29-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 29-13. Matching SDF WIDTH to Verilog

SDF Verilog
(WIDTH (posedge clk) (5)) $width(posedge clk, 0);

1420 Questa® SIM User's Manual, v2023.4

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 29-14. Matching SDF PERIOD to Verilog

SDF Verilog
(PERIOD (posedge clk) (5)) $period(posedge clk, 0);

• NOCHANGE is matched to $nochange:

Table 29-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,
or Chapter 16 - Back Annotation Using the Standard Delay Format (SDF).

Retain Delay Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1421

Optional Edge Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
Optional Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
Rounded Timing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424

Retain Delay Behavior

The simulator processes RETAIN delays based on the definitions in an SDF file, the transition
of the signal, and your use of command line arguments.
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:

• If only rval1 is specified, rval1 is used as the value of rval2 and rval3.
• If 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.

Questa® SIM User's Manual, v2023.4 1421

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 29-16 defines which delay is used depending on the transitions:

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

Use +vlog_retain_same2same on the vsim command line to specify X insertion on outputs that
do not change except when the causal inputs change. 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 29-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

1422 Questa® SIM User's Manual, v2023.4

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

In other cases, the SDF file may contain more accurate data than the model can accommodate.
Table 29-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 29-20. Matching Explicit Verilog Edge Transitions to Verilog
SDF Verilog
(SETUP data (posedge clock) (5)) $setup(data, edge[01, 0x] clk, 0);

Questa® SIM User's Manual, v2023.4 1423

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

1424 Questa® SIM User's Manual, v2023.4

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
only annotate Verilog cells.

Interconnect Delays
An interconnect delay represents the delay from the output of one device to the input of another.
Questa SIM 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.

Disabling Timing Checks

Questa SIM offers a number of options for disabling timing checks on a global or individual
basis.
The table below provides a summary of commands and arguments to disable timing checks.
You can pass some of the arguments to multiple commands, but which command you should
pass them to depends on whether you intend to follow the two-step flow, or the three step flow.
See the command and argument descriptions in the Reference Manual for further detail on
individual commands.

You can pass the +nospecify and +notimingchecks arguments to either vlog, vopt, or vsim, but
the correct choice depends on your flow choice.

• Three-step flow - pass these arguments to vopt.

• Two-step flow - pass these arguments to vsim.
When you pass +nospecify or +notimingchecks to vsim in the two-step flow, vsim will
split off a vopt subprocess to handle the required actions.
• Passing to vlog - Passing these arguments on the vlog command line removes specify
blocks or timing checks from the compiled Verilog cells and modules as if they were
never present. As a result, running a timing simulation at a later point requires you to

Questa® SIM User's Manual, v2023.4 1425

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

recompile the libraries without +nospecify or +notimingchecks. This procedure exists

for backward compatibility and is not recommended usage.

Table 29-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.
vlog +notimingchecks Removes timing checks from all Verilog cells/modules
compiled into a library. The effect is as if the timing checks
were never specified in those cells/modules.
vlog +nospecify Removes specify path delays and timing checks for all
instances in the specified Verilog design. The affect is as if
the specify blocks were never specified in those cells/
modules.
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.
vopt +nospecify Removes specify path delays and timing checks for all
instances in the specified Verilog design
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 Removes Verilog timing checks and disables 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 Removes specify path delays and timing checks for all
instances in the specified design

1426 Questa® SIM User's Manual, v2023.4

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

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.

Questa® SIM User's Manual, v2023.4 1427

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
Questa SIM provides a number of tools for troubleshooting designs that use SDF files.
Specifying the Wrong Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
Matching a Single Timing Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
Mistaking a Component or Module Name for an Instance Label. . . . . . . . . . . . . . . . . . 1429
Forgetting to Specify the Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
Reporting Unannotated Specify Path Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
Failing to Find Matching Specify Module Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1432

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

1428 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 1429

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

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

1430 Questa® SIM User's Manual, v2023.4

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.
• Incompletely annotated timing check (IATC)
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) = Incompletely annotated specify path transition edges.
(IATC) = Incompletely annotated timing check.
-------------------------------------------------------------
/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.

Questa® SIM User's Manual, v2023.4 1431

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
Failing to Find Matching Specify Module Path

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) = Incompletely annotated specify path transition edges.
(IATC) = Incompletely annotated timing check.
--------------------------------------------------------------
/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.

Failing to Find Matching Specify Module Path

The basic function of SDF annotation is to map SDF timing statements to the corresponding
statements in the specify block of the module. The SDF annotation warning “Failed to find
matching specify module path” indicates that there is a mismatch between the SDF data and the
module timing information available to Questa SIM.
The mismatch can occur because there is a difference in the Verilog module specify block
description and the SDF data, or because of differences between the SDF statements and what
the simulator sees for the cell timing data. The simulator's vsim/vlog/vopt command line
arguments will control what vsim will have for timing information.

The vsim/vlog/vopt command arguments that affect the path delays are:

• vsim
o +nospecify
• vlog/vopt
o +delay_mode_unit
o +delay_mode_zero

1432 Questa® SIM User's Manual, v2023.4

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
Failing to Find Matching Specify Module Path

o +nospecify
These are possible +define options that correspond to ifdef statements in the Verilog code. ifdef
statements will affect what is actually compiled.

The +nospecify argument tells the simulator to ignore the specify block. Using the
+delay_mode_unit argument sets nonzero distributed delays to one unit of simulation resolution
and ignores the specify block’s path delays and timing constraints. Using the
+delay_mode_zero argument sets distributed delays to zero (and ignores the specify block’s
path delays and timing constraints).

Note
You can convert the SDF annotation errors to warnings with the vsim option -sdfnoerror or
+nosdferror.

To determine what timing is visible to the simulator, use the vsim command:

write timing <full_instance_pathname>

to return the timing data that vsim sees for a specific instantiation of a module.

To double check the vsim command line options from within vsim, use:

echo [StartupGetArgs]

To determine how a cell was compiled, this command returns the module name and library
information for the instance:

context du <full_instance_pathname>

and this command returns the compile options for the cell:

vdir -l -lib <libname> <module_name>

If these commands do not resolve your problem, another issue could be conditional path delays.
Specifically, because path delays can be very complex, Questa SIM requires that path delays
match identically.

For example:

((COND r1||r2 IOPATH a y (val) (val) ))

does not match:

if (r2 || r1) ( a *> y ) = (val)

It is possible that the cell does not have a path delay declared. In that case, the vsim argument:

+sdf_iopath_to_prim_ok

Questa® SIM User's Manual, v2023.4 1433

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
Failing to Find Matching Specify Module Path

forces the annotation of an SDF IOPATH statement to a primitive.

1434 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 30
Value Change Dump (VCD) Files

The Value Change Dump (VCD) file format is supported for use by Questa SIM 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. Questa SIM provides equivalent commands for these system tasks and
extends VCD support to SystemC and VHDL designs. You can use these Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436

Using Extended VCD as Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438
VCD Commands and VCD Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
VCD File from Source to Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
VCD to WLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Capturing Port Driver Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Resolving Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
VCD for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454

Questa® SIM User's Manual, v2023.4 1435

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

Questa SIM provides two general methods for creating a VCD file.
Four-State VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
Extended VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
VCD Case Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437
Checkpoint/Restore and Writing VCD Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437

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.
Procedure
1. Compile and load the design. For example:
cd <installDir>/examples/tutorials/verilog/basicSimulation
vlib work

1436 Questa® SIM User's Manual, v2023.4

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

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 Questa SIM maintains case when it produces a VCD file.
However, VHDL is not case-sensitive, so Questa SIM converts all signal names to lower case
when it produces a VCD file.

Checkpoint/Restore and Writing VCD Files

If a checkpoint occurs while Questa SIM 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, Questa SIM issues a warning in this situation.

Questa® SIM User's Manual, v2023.4 1437

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.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/visibility
purposes.

Simulating with Input Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438

Replacing Instances with Output Values from a VCD File . . . . . . . . . . . . . . . . . . . . . . . 1440
Port Order Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1441

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

1438 Questa® SIM User's Manual, v2023.4

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

quit -f

Next, rerun the counter without the test bench, using the -vcdstim argument:

vopt counter -o counter_replay

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

Questa® SIM User's Manual, v2023.4 1439

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

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"
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 Questa SIM 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

1440 Questa® SIM User's Manual, v2023.4

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

-vcdstim /top/m=memory.vcd
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.

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.

Questa® SIM User's Manual, v2023.4 1441

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

Questa SIM 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 30-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

Questa SIM also supports extended VCD (dumpports system tasks). The table below maps the
VCD dumpports commands to their associated tasks.
Table 30-2. VCD Dumpport Commands and System Tasks
VCD dumpports commands VCD system tasks
vcd dumpports $dumpports
vcddumpportsall $dumpportsall
vcd dumpportsflush $dumpportsflush
vcd dumpportslimit $dumpportslimit
vcd dumpportsoff $dumpportsoff
vcddumpportson $dumpportson

Questa SIM 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 30-3 maps the VCD commands to their
associated tasks. For additional details, please see the Verilog IEEE Std 1364-2005
specification.
Table 30-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)

1442 Questa® SIM User's Manual, v2023.4

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

Compressing Files with VCD Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444

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

Questa® SIM User's Manual, v2023.4 1443

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

Questa SIM 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, Questa SIM will compress the output.

1444 Questa® SIM User's Manual, v2023.4

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
VCD Simulator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445

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.

Questa® SIM User's Manual, v2023.4 1445

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.

1446 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1447

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 Questa SIM vcd2wlf command is a utility that translates a .vcd file into a .wlf file that can
be displayed in Questa SIM 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 Questa SIM, 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 30-5 shows the driver states recorded as TSSI states if the direction is known.
Table 30-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 30-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)

1448 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1449

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
When force Command is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
Extended Data Type for VHDL (vl_logic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
Ignoring Strength Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452

Default Behavior
By default, Questa SIM 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, Questa SIM 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 30-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

1450 Questa® SIM User's Manual, v2023.4

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

Siemens EDA 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 Questa SIM, 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.

Questa® SIM User's Manual, v2023.4 1451

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 Questa SIM 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, Questa SIM reports strengths for both the zero and one components of the
value if the strengths are the same. If the strengths are different, Questa SIM 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

Questa SIM 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 Questa SIM. 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 30-9. Values for file_format Argument
File_format value Meaning
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)

1452 Questa® SIM User's Manual, v2023.4

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 30-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 30-10 is sample
driver data.
Table 30-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

Questa® SIM User's Manual, v2023.4 1453

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

VCD for VHDL

You can enable VHDL variable dumping for VCD files by specifying the -vcd=+vhar argument
to vsim.
To enable VHDL variable dumping for VCD files, specify -vcd=+vhar to vsim. This option
works in the -debug flow, and also enables VHDL variable dumping using the $dumpvars
system task in mixed language designs.

To dump multi-dimensional arrays, specify both the vhar option and the multid option.

Supported Types
The types supported for VHDL variable dumping are the same as those supported for signals.
The access type is not supported.

Examples
Example of VHDL variable dumping:

vsim -c t -vcd=+vhar -do "vcd file new.vcd; vcd add -r*; run 100; q -f"

Example of VHDL variable dumping with multi-dimensional arrays:

vsim -c t -vcd=+vhar+multid -do "vcd file new.vcd; vcd add -r*; run 100; q
-f"

Example of VHDL variable dumping in mixed design with $dumpvars:

$dumpfile(“dump.vcd”); $dumpvars(0,top);

1454 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 31
Tcl and DO Files

Tcl is a scripting language for controlling and extending Questa SIM. Within Questa SIM 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 Questa SIM. In addition, if Questa SIM does not provide a
command you need, you can use Tcl to create your own commands.
Tcl Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
Tcl Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
List Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
Simulator Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
The Tcl Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483
TclPro Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487

Questa® SIM User's Manual, v2023.4 1455

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456

Tcl References
For quick reference information on Tcl, choose the following from the Questa SIM 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.

1456 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1457

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 31-1 lists the backslash sequences that are handled specially,
along with the value that replaces each sequence.

Table 31-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 (“\”)

1458 Questa® SIM User's Manual, v2023.4

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 31-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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
set Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
Command Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Command Separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Multiple-Line Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Evaluation Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
Tcl Relational Expression Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
Variable Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
System Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
Questa SIM Replacements for Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464

Questa® SIM User's Manual, v2023.4 1459

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.

1460 Questa® SIM User's Manual, v2023.4

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 CheckpointCompressMode

RunLength IgnoreNote NumericStdNoWarnings
IterationLimit IgnoreError StdArithNoWarnings
BreakOnAssertion IgnoreFailure PathSeparator
DefaultForceKind IgnoreSVAInfo DefaultRadix
WLFFilename IgnoreSVAWarning DelayFileOpen
WLFTimeLimit IgnoreSVAError
WLFSizeLimit IgnoreSVAFatal

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

Questa® SIM User's Manual, v2023.4 1461

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

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.
In the example below, note the way the opening brace “{” is at the end of the if and else lines.
This placement of the opening brace is important: If it is not there, the Tcl scanner assumes the
command is complete and will try to execute what it has up to that point, which is not what you
intend.

1462 Questa® SIM User's Manual, v2023.4

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

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

will work.
• For the equal operator, you must use the C operator (==). For not-equal, you must use
the C operator (!=).

Questa® SIM User's Manual, v2023.4 1463

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

Variable Substitution
When a $<var_name> is encountered, the Tcl parser will look for variables that have been
defined either by Questa SIM 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 Questa SIM-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]

Questa SIM Replacements for Tcl Commands

For complete information on Tcl commands, select Help > Tcl Man Pages.
Questa SIM command names that conflict with Tcl commands have been renamed or have been
replaced by Tcl commands, as shown in Table 31-2.
Table 31-2. Changes to Questa SIM Commands
Previous Command changed to (or replaced by)
Questa SIM
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
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.

1464 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Questa SIM Replacements for Tcl Commands

Table 31-2. Changes to Questa SIM Commands (cont.)

Previous Command changed to (or replaced by)
Questa SIM
command
source vsource
wave add wave

Questa® SIM User's Manual, v2023.4 1465

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 Questa SIM DO file scripts. The variables are referenced in
commands by prefixing the name with a dollar sign ($).

Table 31-3. Simulator State Variables

Variable Description
architecture 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, Returns an empty
string.
argc Returns the total number of parameters passed to the current script.
argv Returns the list of parameters (arguments) passed to the vsim command
line.
configuration Returns the name of the top-level configuration currently being
simulated; returns an empty string if no configuration.
delta Returns the number of the current simulator iteration.
entity Returns the name of the top-level VHDL entity or Verilog module
currently being simulated.
library Returns the library name for the current region.
MacroNestingLevel Returns the current depth of script call nesting.
n Represents a script parameter, where n can be an integer in the range 1-
9.
Now Returns the current simulation time with time units (for example,
110,000 ns). Note: the returned value contains a comma inserted
between thousands.
now 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), 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), 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 Returns the current simulation time resolution.

1466 Questa® SIM User's Manual, v2023.4

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

Table 31-3. Simulator State Variables (cont.)

Variable Description
RNGTrace Returns 1 if the RNG trace feature is enabled, and returns 0 if the
feature is disabled. The value of the RNGTrace variable is associated
with the vsim -rngtrace argument. For example, the following
command yields the RNGTrace value “1”:
vsim -rngtrace
Note: To enable or disable the RNG trace feature, use the following
command:
set RNGTrace <0|1>
RNGTraceFile Returns the filename to which the RNG trace related output is
redirected. If the value of this variable is “”(empty string), then the
RNG trace output is redirected to the Transcript window. The value of
the RNGTraceFile variable is associated with the vsim
-rngtrace=<filename> argument. For example, the following command
yields the RNGTraceFile value “myfile.txt”:
vsim -rngtrace=myfile.txt
Note: To change the filename to which the RNG trace related
output is redirected, use the following command:
set RNGTraceFile "<filename>"
RNGTraceOpt Returns the configuration option string for the RNG trace generated
output. The value of the RNGTraceOpt variable is associated with the
vsim -rngtraceopt argument. For example, the following command
yields the RNGTraceOpt value “showciid”:
vsim -rngtraceopt=showciid
Note: To change the configuration option string for the RNG trace
generated output, use the following command:
set RNGTraceOpt "<option_string>"
RNGTraceClassFilter Returns the RNG trace output class filter string. The value of the
RNGTraceClassFilter variable is associated with the vsim
-rngtraceclassfilter argument. For example, the following command
yields the RNGTraceClassFilter value “TFoo”:
vsim -rngtraceclassfilter=TFoo
Note: To change the RNG trace output class filter string, use the
following command:
set RNGTRaceClassFilter "<class_filter_string>"

Questa® SIM User's Manual, v2023.4 1467

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

Table 31-3. Simulator State Variables (cont.)

Variable Description
RNGTraceProcessFilt Returns the RNG trace output scope filter string. The value of the
er RNGTraceProcessFilter variable is associated with the vsim
-rngtraceprocessfilter argument. For example, the following command
yields the RNGTraceProcessFilter value “/top”:
vsim -rngtraceprocessfilter=/top
Note: To change the RNG trace output scope filter string, use the
following command:
set RNGTraceProcessFilter "<scope_filter_string>"
SolveInfo Returns the current debug output configuration string. The value of the
SolveInfo variable is associated with the vsim -solveinfo argument. For
example, the following command yields the SolveInfo value, “1,gentc”.
vsim -solveinfo=1,gentc
Note: To change the debug output configuration string, use the
following command:
set SolveInfo <option_string>
SolveInfoClassFilter Returns the current debug output class filter string. The value of the
SolveInfoClassFilter variable is associated with the vsim
-solveinfoclassfilter argument. For example, the following command
yields the SolveInfoClassFilter value, “TBar,TBaz”.
vsim -solveinfo=2,gentc -solveinfoclassfilter=TBar,TBaz
Tip: To change the debug output class filter string, use the
following command:
set SolveInfoClassFilter <class_filter_string>

Referencing Simulator State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468

Special Considerations for the now Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
Reading Variable Values From the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
Setting Variable Values for the INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469

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.

1468 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Tcl and DO Files
Special Considerations for the now Variable

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.

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.

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

Questa® SIM User's Manual, v2023.4 1469

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

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 31-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
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, val2, replaces elements first through last with val1, 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.

1470 Questa® SIM User's Manual, v2023.4

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 Questa SIM. Only brief
descriptions are provided in the following table.
Simulator Tcl Time Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472

Questa® SIM User's Manual, v2023.4 1471

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

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472

Time Relations Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Tcl Time Arithmetic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473

Time Conversion Tcl Commands

The following table provides Tcl time conversion commands.

Table 31-5. 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
Questa SIM 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 31-6. 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

1472 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1473

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.

1474 Questa® SIM User's Manual, v2023.4

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
}

Questa® SIM User's Manual, v2023.4 1475

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
Questa SIM DO files are simply scripts that contain Questa SIM and, optionally, Tcl
commands. You invoke these scripts with the Tools > TCL > Execute Macro menu selection
or the do command.
Creating DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
Using Parameters with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
Deleting a File from a .do Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
Making Script Parameters Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
Breakpoint Flow Control in Nested DO files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
Useful Commands for Handling Breakpoints and Errors . . . . . . . . . . . . . . . . . . . . . . . . 1481
Error Action in DO File Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
Using the Tcl Source Command with DO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482

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 Questa SIM Tutorial. This script adds several signals to the
Wave window, provides stimulus to those signals, and then advances the simulation.

1476 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1477

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, Questa SIM 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.

1478 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1479

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 31-1. Breakpoint Flow Control in Nested DO Files

1480 Questa® SIM User's Manual, v2023.4

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,
Questa SIM 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 31-8. 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 Questa SIM
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).

Questa® SIM User's Manual, v2023.4 1481

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, Questa SIM does the following:
1. If an onerror command has been set in the script, Questa SIM 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, Questa SIM 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.

1482 Questa® SIM User's Manual, v2023.4

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

The Chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
Tcl Debugger Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487

The Debugger
Select Tools > TCL > Tcl Debugger to run the debugger. Make sure you use the Questa SIM
and TDebug menu selections to invoke and close the debugger.
Select the Popup button in the Chooser to open the debugger window (Figure 31-2).

Questa® SIM User's Manual, v2023.4 1483

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 31-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 31-9.
Table 31-9. Tcl Debug States
Button Description
Stop stop after next expression, used to get out of slow/fast/
nonstop mode

1484 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1485

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 Questa SIM, 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 31-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 31-5. Variables Dialog Box

1486 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1487

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Tcl and DO Files
TclPro Debugger

1488 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix A
modelsim.ini Variables

Themodelsim.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
AcceptLowerCasePragmaOnly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
AmsStandard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
AssertionCover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
AutoExclusionsDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
BatchTranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
BindAtCompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
BreakOnAssertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
BreakOnMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
CheckPlusargs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542

Questa® SIM User's Manual, v2023.4 1489

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
CheckSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
CodeCoverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
CodeLinkAutoLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
CommandHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
common . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
CompilerTempDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
CoverageSaveParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
CoverCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
CoverClkOptBuiltins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
CoverExcludeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
CoverOpt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
CoverREC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
CoverThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
CoverWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
CppOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
CppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
data_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
DefaultLibType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
DefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
DefaultRestartOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587

1490 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
DpiCppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
DpiCppPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
EnableSVCoverpointExprVariable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
EnumBaseInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
ExtendedToggleMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
FlatLibPageDeletePercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
floatfixlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
ForceSigNextIter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
ForceUnsignedIntegerToVHDLInteger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
FsmResetTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
GCThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
GenerateFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
GenerateLoopIterationMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
GenerateRecursionDepthMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
Hazard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
IgnoreFailure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632

Questa® SIM User's Manual, v2023.4 1491

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

IgnoreSVAWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
IgnoreWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
InitOutCompositeParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
IterationLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
LargeObjectSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643
License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
MaxReportRhsSVCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
MaxSVCoverpointBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
MaxSVCrossBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
MessageFormatFail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
MessageFormatWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
modelsim_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
MsgLimitCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
MultiFileCompilationUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
NoCaseStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
NoRangeCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677

1492 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
NumericStdNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
OnFinishPendingAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
PedanticErrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
RequireConfigForAllDefaultBinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
ScMainFinishOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
ScStackSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
Show_Warning1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
Show_Warning2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
Show_Warning3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
Show_Warning4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
Show_Warning5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722

Questa® SIM User's Manual, v2023.4 1493

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
SignalForceFunctionUseDefaultRadix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
SmartDbgSym. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
SolveArrayResizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
SolveBeforeErrorSeverity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
SolveEngineErrorSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
SolveFailDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
SolveFailTestcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
SolveGraphMaxEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1741
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
StackTraceDepth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1745
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
Stats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1749
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
StdArithNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754
sv_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1755
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758
SVCovergroupGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
SVCovergroupPerInstanceDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1761
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
SVCovergroupTypeGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
SVCoverpointAutoBinMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768

1494 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables

SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769
SVCoverpointWildCardBinValueSizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1770
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
SvRandExtensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
ToggleMaxRealValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1793
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
ToggleVlogEnumBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799
toolblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1800
TranscriptFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
UnattemptedImmediateAssertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
UVMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1813
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
VhdlSeparatePduPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819

Questa® SIM User's Manual, v2023.4 1495

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables

WarnConstantChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1821
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
wholefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823
WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824
WildcardSizeThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
WildcardSizeThresholdVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
WLFCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
WLFCollapseMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
WLFDeleteOnQuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1830
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
WLFFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
WLFOptimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1833
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
WLFSimCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
WLFTimeLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1838
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
WrapColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
WrapWSColumn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
XpropAssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843
Commonly Used modelsim.ini Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Common Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Hierarchical Library Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Warnings from Arithmetic Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Restart Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847

1496 Questa® SIM User's Manual, v2023.4

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.

Note
QIS is the preferred method to use when optimizing designs with vopt for debug/
visibility purposes.

• The [DefineOptionset] section allows you to define groups of commonly used

command line arguments.
• 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.
Making Changes to the modelsim.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
Editing modelsim.ini Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
Overriding the Default Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
The Runtime Options Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499

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.

Questa® SIM User's Manual, v2023.4 1497

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

Procedure
1. Navigate to the location of the modelsim.ini file:
<install directory>/modelsim.ini
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. ClickOK.
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.

1498 Questa® SIM User's Manual, v2023.4

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

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

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.

Questa® SIM User's Manual, v2023.4 1499

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.

1500 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1501

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

1502 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1503

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

Variables
Themodelsim.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
AccessObjDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
AddPragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
AllowCheckpointCpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
AmsStandard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
AppendClose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519
AssertFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
AssertionActiveThreadMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
AssertionActiveThreadMonitorLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
AssertionCover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523
AssertionDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
AssertionEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525
AssertionEnableVacuousPassActionBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
AssertionFailAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
AssertionFailLocalVarLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
AssertionFailLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
AssertionLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
AssertionPassLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
AssertionThreadLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
AssertionThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
ATVStartTimeKeepCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
AutoExclusionsDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
AutoLibMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536

1504 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

BatchMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
BatchTranscriptFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
BindAtCompile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
BreakOnAssertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
BreakOnMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
CheckPlusargs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
CheckpointCompressMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
CheckSynthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
ClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
CodeCoverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
CodeLinkAutoLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
CommandHistory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
common. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
CompilerTempDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
ConcurrentFileLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
CoverageSaveParam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
CoverAtLeast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
CoverCells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
CoverClkOptBuiltins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
CoverConstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
CoverDeglitchOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558
CoverDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
CoverEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
CoverExcludeDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
CoverFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
CoverLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563
CoverLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
CoverMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
CoverOpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
CoverREC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
CoverRespectHandL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
CoverReportCancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
CoverShortCircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
CoverSub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571

Questa® SIM User's Manual, v2023.4 1505

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

CoverThreadLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
CoverThreadLimitAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
CoverWeight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
CppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
CppOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
CppPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
CreateDirForFileAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
CreateLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
CvgZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
data_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
DatasetSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
DefaultForceKind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
DefaultLibType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
DefaultRadix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
DefaultRadixFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
DefaultRestartOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
DelayFileOpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
displaymsgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
DpiCppInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
DpiCppPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
DpiOutOfTheBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
DumpportsCollapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
EmbeddedPsl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
EnableDpiSosCb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
EnableSVCoverpointExprVariable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
EnableTypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
EnumBaseInit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1598
error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
ErrorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
ExtendedToggleMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
FecCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
FecUdpEffort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
FlatLibPageSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606

1506 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

FlatLibPageDeletePercentage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
FlatLibPageDeleteThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
floatfixlib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609
ForceSigNextIter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
ForceUnsignedIntegerToVHDLInteger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
FsmImplicitTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
FsmResetTrans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
FsmSingle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
FsmXAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
GCThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
GCThresholdClassDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
GenerateFormat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
GenerateLoopIterationMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
GenerateRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
GenerousIdentifierParsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
GlobalSharedObjectList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
Hazard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
ieee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
IgnoreError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
IgnoreFailure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626
IgnoreNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
IgnorePragmaPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
ignoreStandardRealVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
IgnoreSVAError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
IgnoreSVAFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
IgnoreSVAInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
IgnoreSVAWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
IgnoreVitalErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
IgnoreWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
ImmediateContinuousAssign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
IncludeRecursionDepthMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
InitOutCompositeParam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
IterationLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
LargeObjectSilent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641

Questa® SIM User's Manual, v2023.4 1507

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

LargeObjectSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
LibrarySearchPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643
License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
MaxReportRhsCrossProducts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
MaxReportRhsSVCrossProducts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
MaxSVCoverpointBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
MaxSVCoverpointBinsInst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
MaxSVCrossBinsDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
MaxSVCrossBinsInst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
MessageFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
MessageFormatBreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
MessageFormatBreakLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
MessageFormatError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
MessageFormatFail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
MessageFormatFatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656
MessageFormatNote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
MessageFormatWarning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
MixedAnsiPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
modelsim_lib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
MsgLimitCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
msgmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
mtiAvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
mtiOvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664
mtiPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
mtiUPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
mtiUvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
MultiFileCompilationUnit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
MvcHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
NoCaseStaticError. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
NoDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1671
NoDeferSubpgmCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
NoIndexCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
NoOthersStaticError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
NoRangeCheck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676

1508 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

NoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
NoVitalCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
NumericStdNoWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
OldVHDLConfigurationVisibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
OldVhdlForGenNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
OnFinish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
OnFinishPendingAssert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
Optimize_1164 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
ParallelJobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
PathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
PedanticErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
PliCompatDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1688
PreserveCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1689
PrintSimStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
PrintSVPackageLoadingAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
Protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692
PslOneAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
PslInfinityThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
Quiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
RequireConfigForAllDefaultBinding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
RunLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
ScalarOpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
SccomLogfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1700
SccomVerbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
ScEnableScSignalWriteCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
ScMainFinishOnQuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
ScMainStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
ScStackSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
ScShowIeeeDeprecationWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
ScTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
ScvPhaseRelationName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
SeparateConfigLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
Show_BadOptionWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
Show_Lint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711

Questa® SIM User's Manual, v2023.4 1509

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

Show_PslChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
Show_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
Show_VitalChecksWarnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
Show_Warning1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
Show_Warning2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
Show_Warning3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
Show_Warning4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
Show_Warning5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
ShowConstantImmediateAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
ShowFunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
ShowUnassociatedScNameWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
ShowUndebuggableScTypeWarning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
ShutdownFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
SignalForceFunctionUseDefaultRadix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1725
SignalSpyPathSeparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
SimulateAssumeDirectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
SimulateImmedAsserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
SimulatePSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
SimulateSVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
SmartDbgSym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
SolveArrayResizeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
SolveArrayResizeWarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
SolveBeforeErrorSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
SolveEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
SolveEngineErrorSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
SolveFailDebug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
SolveFailSeverity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
SolveFailTestcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
SolveGraphMaxEval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
SolveGraphMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1741
SolveRev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
SolveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
SparseMemThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
StackTraceDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1745
Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746

1510 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

Stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747
std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1749
std_developerskit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
StdArithNoWarnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751
suppress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
SuppressFileTypeReg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753
Sv_Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754
sv_std. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1755
SVAPrintOnlyUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756
SVCovergroupGetInstCoverageDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757
SVCovergroupGoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758
SVCovergroupGoalDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759
SVCovergroupMergeInstancesDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1760
SVCovergroupPerInstanceDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1761
SVCovergroupSampleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
SVCovergroupStrobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
SVCovergroupStrobeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
SVCovergroupTypeGoal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
SVCovergroupTypeGoalDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766
SVCovergroupZWNoCollect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
SVCoverpointAutoBinMax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
SVCoverpointExprVariablePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769
SVCoverpointWildCardBinValueSizeWarn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1770
SVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
SVCrossNumPrintMissingDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
SvExtensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
SVFileSuffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
Svlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
SVPrettyPrintFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
SvRandExtensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
synopsys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1784
SyncCompilerFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
ToggleCountLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
ToggleDeglitchPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
ToggleFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788

Questa® SIM User's Manual, v2023.4 1511

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Variables

ToggleMaxFixedSizeArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
ToggleMaxIntValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1790
ToggleMaxRealValues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1791
ToggleNoIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
TogglePackedAsVec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1793
TogglePortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
ToggleVHDLRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
ToggleVlogEnumBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
ToggleVlogIntegers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797
ToggleVlogReal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798
ToggleWidthLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799
toolblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1800
TranscriptFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
UCDBFilename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
UCDBTestStatusMessageFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
UnattemptedImmediateAssertions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
UnbufferedOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805
UndefSyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806
UpCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807
UserTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
UseScv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809
UseSVCrossNumPrintMissing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810
UseUvmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
UVMControl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812
verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1813
Veriuser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814
VHDL93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815
VhdlSeparatePduPackage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816
VhdlVariableLogging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817
vital2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
vlog95compat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819
WarnConstantChange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1820
warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1821
WaveSignalNameWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
wholefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823

1512 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Variables

WildcardFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824
WildcardSizeThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
WildcardSizeThresholdVerbose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
WLFCacheSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
WLFCollapseMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
WLFCompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
WLFDeleteOnQuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1830
WLFFileLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
WLFFilename. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
WLFOptimize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1833
WLFSaveAllRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
WLFSimCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835
WLFSizeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
WLFTimeLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
WLFUpdateInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1838
WLFUseThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
WrapColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
WrapMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
WrapWSColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
XpropAssertionLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843

Questa® SIM User's Manual, v2023.4 1513

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.

1514 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1515

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 ("").

1516 Questa® SIM User's Manual, v2023.4

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 2|1|0
Arguments
• The arguments are described as follows:
o 0 — Off (default), disables checkpointing support.
o 1 — legacy (manual restore).
This option requires manual code changes to checkpoint foreign C code.
o 2 — auto (auto restore).
Also specify the -dir argument to the checkpoint command if you select the auto
restore flow.
Description
This variable may be overridden with the vsim -allowcheckpointcpp command. It is not
supported on Windows platforms.

Questa® SIM User's Manual, v2023.4 1517

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
Setting Environment Variables

1518 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1519

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

1520 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1521

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

1522 Questa® SIM User's Manual, v2023.4

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
deprecated and will result in an error.

Questa® SIM User's Manual, v2023.4 1523

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

1524 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1525

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.

1526 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1527

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.

1528 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1529

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 Questa SIM responds to a VHDL/PSL/SVA
assertion failure event. Questa SIM 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.

1530 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1531

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

1532 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1533

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

1534 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1535

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

1536 Questa® SIM User's Manual, v2023.4

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
TranscriptFile

Questa® SIM User's Manual, v2023.4 1537

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.

1538 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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}.

Questa® SIM User's Manual, v2023.4 1539

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

1540 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
BreakOnMessage

BreakOnMessage
Section [vsim]
This variable stops the simulator when the severity of a tool message is equal to or higher than
the value set for the variable.
Note
The elaboration phase ignores this variable.

Syntax
BreakOnMessage = {0 | 1 | 2 | 3}
Arguments
• The arguments are described as follows:
The default behavior is to not break on any level of message.
o 0 — Note
o 1 — Warning
o 2 — Error
o 3 — Fatal
Examples
• Instruct the simulator to break on any message of level Note or higher.
BreakOnMessage = 0

• Instruct the simulator to break on any Fatal message.

BreakOnMessage = 3

Questa® SIM User's Manual, v2023.4 1541

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.

1542 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1543

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.

1544 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1545

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

1546 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CodeLinkAutoLoad

CodeLinkAutoLoad
Section [vsim]
This variable adds the contents of the $CODELINK_HOME/sim/ms.cmd file to the vsim
command line. This file contains information required by Questa Codelink during the loading of
a simulation. If you do not have $CODELINK_HOME set, a warning will be issued and the
simulation will continue.
Syntax
CodeLinkAutoLoad = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

Questa® SIM User's Manual, v2023.4 1547

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 ( ; ).

1548 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
common

common
Specifies a file of common encryption directives for the vencrypt and vhencrypt commands.
Usage
common=<file_name>
Arguments
• Specifies a file containing common encryption directives used across the tools. This file is
optional. If you use this variable, then its presence requires at least one "toolblock" directive
within the specified file. Directives such as "author", "author_info", and "data_method"as
well as the common block license specification are placed in this file.

Questa® SIM User's Manual, v2023.4 1549

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.

1550 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1551

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

1552 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
CoverageSaveParam

CoverageSaveParam
Section: [vopt]
Enables or disables storage of elaborated parameter overrides to each instance in the UCDB.
Syntax
CoverageSaveParam = {0 , 1}
Arguments
• The arguments are:
o 0 — (default) Disable
o 1 — Enable

Questa® SIM User's Manual, v2023.4 1553

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.

1554 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1555

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.

1556 Questa® SIM User's Manual, v2023.4

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
Code Coverage Modes

Questa® SIM User's Manual, v2023.4 1557

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

1558 Questa® SIM User's Manual, v2023.4

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 “<n> <time_unit>”, 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 enclose <n> <time_unit> in quotation marks (“ ”) when you put a space
between <n> and <time_unit>.

Questa® SIM User's Manual, v2023.4 1559

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

1560 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1561

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.

1562 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1563

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

1564 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1565

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], [vopt]
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.

1566 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1567

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.

1568 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1569

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.

1570 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1571

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

1572 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1573

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.

1574 Questa® SIM User's Manual, v2023.4

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
Questa SIM, 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
Questa SIM. 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.

Questa® SIM User's Manual, v2023.4 1575

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.

1576 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1577

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

1578 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1579

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

1580 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
data_method

data_method
Specifies the length of the symmetric session key used by the encryption commands vencrypt
and vhencrypt.
Usage
data_method={aes128 | aes192 | aes256}
Arguments
• The session key is a symmetric key that the vencrypt and vhencrypt commands randomly
generate for each protected region. The data_method argument sets the length of the session
key.
o aes128 — AES key size of 128. This is the default.
o aes192 — AES key size of 192.
o aes256— AES key size of 256.

Questa® SIM User's Manual, v2023.4 1581

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.

1582 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1583

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

1584 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1585

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.

1586 Questa® SIM User's Manual, v2023.4

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
Checkpointing and Restoring Simulations

Questa® SIM User's Manual, v2023.4 1587

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

1588 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1589

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
DpiCppInstall

DpiCppInstall
Section [vsim], [vlog]
This variable specifies the compiler version from the list of support GNU compilers (i.e., 4.5.0,
4.7.4).
Syntax
DpiCppPath = <GNU_compiler_version_number>
Arguments
• The arguments are described as follows:
<GNU_compiler_version_number> — Specifies the version number of the GNU compiler
to use.

1590 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1591

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.

1592 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1593

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

1594 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1595

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

1596 Questa® SIM User's Manual, v2023.4

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 Verilog 1364-2005 designs.
Syntax
EnableTypeOf = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

Questa® SIM User's Manual, v2023.4 1597

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

1598 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1599

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.

1600 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1601

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.

1602 Questa® SIM User's Manual, v2023.4

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
Message Severity Level
suppress
warning

Questa® SIM User's Manual, v2023.4 1603

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

1604 Questa® SIM User's Manual, v2023.4

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) Larger expressions/conditions considered.
o 3 — (high) Very large expressions/conditions considered.

Questa® SIM User's Manual, v2023.4 1605

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.

1606 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1607

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.

1608 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1609

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.

1610 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1611

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.

1612 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1613

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

1614 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1615

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.

1616 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1617

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.

1618 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1619

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.

1620 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1621

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], [vsim]
For the vopt flow, this variable instructs Questa SIM to load the specified shared objects library
with global symbol visibility. Essentially, setting this variable is required if the SystemC top is
elaborated in vopt and is depending on the symbols from a common library being loaded with
the GlobalSharedObjectList variable for vsim (or using vsim -gblso).
For vsim, this variable instructs Questa SIM 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
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 -gblso with vopt, or vsim.

1622 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1623

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.

1624 Questa® SIM User's Manual, v2023.4

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 Questa SIM 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
set Command Syntax

Questa® SIM User's Manual, v2023.4 1625

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 Questa SIM to disable runtime failure messages.
Syntax
IgnoreFailure = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1626 Questa® SIM User's Manual, v2023.4

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 Questa SIM to disable runtime note messages.
Syntax
IgnoreNote = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

Questa® SIM User's Manual, v2023.4 1627

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.

1628 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1629

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

1630 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1631

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

1632 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1633

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

1634 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1635

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

1636 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1637

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.

1638 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1639

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
keyring

keyring
Specifies the location of the common and toolblock files used by the vencrypt and vhencrypt
commands.
Usage
keyring = <directory_name>
Arguments
The default location for the keyring directory is in the product installation directory keyring
which is <install_dir>/keyring.

1640 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1641

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.

1642 Questa® SIM User's Manual, v2023.4

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
VHDL Resource Libraries

Questa® SIM User's Manual, v2023.4 1643

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

1644 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1645

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.

1646 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1647

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.

1648 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1649

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.

1650 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1651

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

1652 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1653

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

1654 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1655

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.

1656 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1657

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.

1658 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1659

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

1660 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1661

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.

1662 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1663

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.

1664 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1665

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.

1666 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1667

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

1668 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1669

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.

1670 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1671

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.

1672 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1673

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

1674 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1675

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
Message Severity Level
fatal
suppress
warning

1676 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1677

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.

1678 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1679

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.

1680 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1681

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 Questa SIM when it encounters either an assertion failure,
a $finish, or an sc_stop() in the design code. Stopping can aid post-simulation debug by
allowing you to examine the state of the design prior to exiting.
Syntax
OnFinish = {ask | exit | final | stop}
Arguments
• The arguments are described as follows:
o ask — (default) In batch mode, the simulation will exit; in GUI mode, the user is
prompted for action to either stop or exit the simulation.
o exit — The simulation exits without asking for any confirmation.
o final — The simulation executes the stop command after executing any
SystemVerilog final blocks.
You can override this variable by specifying vsim -onfinish.
o stop — The simulation executes the stop command before executing any
SystemVerilog final blocks.

1682 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1683

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

1684 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1685

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 ( / ).

1686 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1687

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.

1688 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1689

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.

1690 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1691

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

1692 Questa® SIM User's Manual, v2023.4

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,
Questa SIM 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

Questa® SIM User's Manual, v2023.4 1693

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

1694 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1695

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.

1696 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1697

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

1698 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1699

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.

1700 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1701

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

1702 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1703

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.

1704 Questa® SIM User's Manual, v2023.4

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 and the implicitly created DPI-SC
thread.
Syntax
ScStackSize = <n>{Kb | Mb | Gb}
Arguments
• The arguments are described as follows:
o <n> — An integer followed by Kb, Mb, Gb. The default for ScStackSize is 1
MByte.

Questa® SIM User's Manual, v2023.4 1705

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

1706 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1707

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

1708 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1709

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

1710 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1711

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 Questa SIM to display PSL warning messages.
Syntax
Show_PslChecksWarnings = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — Off
o 1 — (default) On

1712 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1713

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

1714 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1715

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

1716 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1717

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

1718 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1719

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

1720 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1721

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 Questa SIM to display unassociated SystemC name warnings.
Syntax
ShowUnassociatedScNameWarning = {0 | 1}
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

1722 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1723

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.

1724 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1725

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

1726 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1727

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

1728 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1729

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

1730 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1731

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 or queue to be
resized. If randomize() attempts to resize a dynamic array or queue 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 65535.

1732 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveArrayResizeWarn

SolveArrayResizeWarn
Section [vsim]
This variable specifies the maximum size that a random dynamic array or queue may be resized
by the solver without a warning. If the solver attempts to resize a dynamic array or queue to a
size greater than the specified limit, a warning will be issued
Syntax
SolveArrayResizeWarn = <n>
Arguments
• The arguments are described as follows:
o <n> — Any positive integer (a value of 0 indicates no limit). Default value is 65535.

Questa® SIM User's Manual, v2023.4 1733

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.

1734 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1735

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SolveEngineErrorSeverity

SolveEngineErrorSeverity
Section [vsim]
This variable specifies error message severity for suppressible errors that are related to solve
engine capacity limits.
Syntax
SolveEngine = [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 "-solveengineerrorseverity".

1736 Questa® SIM User's Manual, v2023.4

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 debugging SystemVerilog randomize() failures. By default,
(SolveFailDebug - 1) Questa SIM generates a constraint contradiction report for randomize()
calls that fail due to having no solutions when SolveFailSeverity is set to a non-zero value. The
report 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 - Disable solvefaildebug
o 1 - (default) 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

Questa® SIM User's Manual, v2023.4 1737

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).
Note
SolveFailSeverity can affect the behavior of SolveFailDebug. When SolveFailDebug is
enabled, a constraint contradiction report is displayed for randomize() calls that have a
message severity >= warning (i.e. constraint contradiction reports will not be generated for
randomize() calls having a "no error" severity level).

Syntax
SolveFailSeverity = {<value1>[<value2>}
Arguments
• The arguments are described as follows:
o 0 — No error
o 1 — (default) Warning
o 2 — Error
o 3 — Failure
o 4 — Fatal

1738 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SolveFailTestcase

SolveFailTestcase
Section [vsim]
Specifies a file in which a simplified testcase is generated. The testcase reproduces the failure
when a randomize() failure is encountered. By default, this variable is OFF (that is, it does not
generate a testcase file). To enable it, uncomment this variable in the modelsim.ini file. You can
override this variable by specifying “vsim ‘-sovefailtestcase’”.
Note
Testcases for “no-solution” failures are not generated with this variable. You must enable
the SolveFailDebug variable to generate testcases for “no-solution” failures.

Syntax
SolveFailTestcase = <filename>
Arguments
• <filename>
The name of a file that is to include the simplified testcase. If you do not specify a filename,
the testcase is generated in the transcript.

Questa® SIM User's Manual, v2023.4 1739

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.

1740 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1741

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 specifies SystemVerilog randomize() solution generation compatibility with a
prior release. Use it to get the same random sequences during simulation as a prior release.
Syntax
SolveRev = <year>.<quarter>
Arguments
• The arguments are described as follows:
o <year> — The year of your Questa SIM release.
o <quarter> — The integer 1, 2, 3, or 4, indicating the quarter of the year of your
release.

Note
Only prior quarter releases within the same year are allowed. For example, if you have a
2022.3 release, you can set “SolveRev= 2022.2” or “SolveRev = 2022.1”, but cannot set
“SolveRev =2021.4”.

You can override this variable by specifying vsim -solverev.

1742 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1743

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

1744 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1745

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
Using a Startup File

1746 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1747

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

1748 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1749

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

1750 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1751

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 = {<msgNumber> | <msgGroup>} [,[<msg_number> | <msgGroup>] ,...]
Arguments
• <msgNumber>
A specific message number
• <msgGroup>
A value identifying a pre-defined group of messages, based on area of functionality. These
groups only suppress notes or warnings. The valid arguments are:
All,GroupNote, GroupWarning, GroupFLI, GroupPLI, GroupSDF, GroupVCD,
GroupVital, GroupWLF, GroupTCHK, GroupPA, GroupLRM
Description
You can override this variable setting by specifying the sccom, vcom, vlog, vopt, or vsim
command with the -suppress argument.

1752 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1753

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.

1754 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1755

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 SystemVerilog LRM-defined
Severity System tasks.
o 1 — Prints only the severity information and the user message.

1756 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1757

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.

1758 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1759

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

1760 Questa® SIM User's Manual, v2023.4

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
tobe 0 in the LRM). 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

Questa® SIM User's Manual, v2023.4 1761

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.

1762 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1763

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. It does not override explicit assignments to
type_option.strobe (defined to be 0 in the LRM).
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.

1764 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1765

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. It does not override specific assignments in SystemVerilog source
code (defined to be 100 in the LRM).
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.

1766 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1767

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.

1768 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1769

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.

1770 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1771

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

1772 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1773

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.
• ftpas — Forwards the $test$plusargs systf evaluation to vsim during simulation
time. Use svext=ftpas while saving the checkpoint. Prevents systf evaluation
during elaboration time. Doing this provides +arg at restore time. $test$plusargs
will now honor this argument.
• idcl — Allows passing of import DPI call locations as implicit scopes.
When there is no svSetScope() call, the DPI scope will always be implicitly set
to the current DPI call location and restored after the call returns. This is

1774 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SvExtensions

different than the LRM behavior, which sets the scope to the import function
declaration’s scope instead of the call location.
When you call svSetScope in a C function, it stays sticky until the enclosing C
function returns. The calling chain initiates inside the enclosing C function, but
after svSetScope(), will always see the same user scope setting. svSetScope()
will not impact additional DPI calls in the same thread after the enclosing C
function returns.
• iddp — Ignore the DPI task disable protocol check.
• idlitres — Previous versions of QuestaSIM would incorrectly interpret an
unbased/unsized constant literal '1 on the RHS of an 'inside' or 'dist' operator.
This issue has been fixed. However this fix may impact existing designs. As a
result, QuestaSIM provides backward compatibility for the incorrect behavior
for customers that require it. Backward compatibility is provided via a compile-
time argument -svext=idlitres, where "idlitres" means "perform non-LRM
compliant resolution of unbased/unsized literals in 'inside' expressions and 'dist'
constriants). The "idlitres" extension is DISABLED by default.
• 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.
• mewq — (vlog only) Allows macro substitutions inside string literals not within
a text macro.
• ncref — A ref argument in the new operator of a covergroup will not be treated
as a constant, unless specified.
• numscale — Allows a scale factor to follow numeric literals (for example, 10u).
• pae — Automatically export all symbols imported and referenced in a package.
• pae1 — 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.

Questa® SIM User's Manual, v2023.4 1775

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SvExtensions

• 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.
• voidsystf — (vlog and vopt only)
When enabled (default), specifies to evaluate any occurrences of $void(x) within
constraint contexts as (x), and issue a suppressible warning each time.
Occurrences of $void outside of constraint contexts will behave as user-defined
system function calls (PLI).
When disabled, evaluates any occurrences of $void(x) as user-defined system
function calls (PLI). Because system function calls are not generally allowed
within constraint contexts, the use of $void in a constraint generates a vlog/vopt
error.
Specifying -pedanticerrors disables the voidsystf extension, even if you enable it
with -svext=voidsystf.
• Multiple extensions are specified as a comma separated list. For example:
SvExtensions = +feci,-uslt,pae

1776 Questa® SIM User's Manual, v2023.4

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 (\\).

Questa® SIM User's Manual, v2023.4 1777

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

1778 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1779

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SVPrettyPrintFlags

o For example, SVPrettyPrintFlags=C256 will limit the output to 256 characters.

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.

1780 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SvRandExtensions

SvRandExtensions
Section [vsim]
Enables or disables non-LRM compliant SystemVerilog constrained random language
extensions.
Syntax
SvRandExtensions = [+|-]<extension>[, [+|-]<extension>] …
Arguments
• +
Enables the extension
• -
Disables the extension
• extension
A collection of arguments identifying different non-LRM compliant extensions:
arraymode
Enables a non-LRM compliant form of rand_mode for random unpacked arrays
(fixed, dynamic, queues, associative). When you enable this extension every random
unpacked array will keep track of its rand_mode value independently of the
rand_mode values of its elements. This extension is disabled by default.
deepcheck
Enabled by default, the deepcheck extension allows class::randomize(null) calls to
recursively consider constraints from member 'rand' class handles. Use
“SvRandExtensions = -deepcheck” or “vsim -svrandext=-deepcheck” to disable this
extension.
funcback
Allows functions to be called multiple times in constraints with complex interactions
between the function input(s) and function output (ACT solver only. By default (non-
funcback behavior), the solver evaluates random variables related to the input(s) of a
function call before random variables that depend on the output of the function call;
the function call is executed at most once. If a constraint contradiction occurs while
evaluating the random variables that depend on the output of the function call,
randomize() fails. With funcback behavior enabled, the solver evaluates random
variables related to the input(s) and output of a function call simultaneously; the
function call may be executed multiple times if the output of the function call does
not satisfy the existing constraints. If no solution can be found after executing the
function 100 times, randomize() fails
nodist
Interprets ‘dist’ constraint as an ‘inside’ constraint (ACT solver only).
noorder

Questa® SIM User's Manual, v2023.4 1781

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
SvRandExtensions

Ignores solve/before ordering constraints (ACT solver only).

oobidx
When enabled, this extension allows out-of-bound (OOB) values for an indexed-
expression with random indices if either of the following criteria are met:
• The base-expression of indexed-expression is a 2-state packed type, i.e. array,
vector etc.
• The base-expression of indexed-expression is an unpacked array of 2-state
packed elements.
The oobidx extension is disabled by default.
pathseed
Seeds different module instances differently with hierarchical pathname based
permutation. This extension is disabled by default.
purecheck
Suppresses the invocation of pre_randomize() and post_randomize() functions for
class::randomize(null) calls. This extension is disabled by default. When disabled,
there will be no changes to the pre-existing simulation behavior.
prerandfirst
Calls the pre_randomize() functions of class instances referenced by random dynamic
array/queue fields before registering/evaluating the constraints in the parent class.
This extension is disabled by default.
promotedist
Promotes the priority of a 'dist' constraint if its target has no explicit solve/before
constraint.
randindex
(enabled by default) Allows random variables in index expressions for both packed
and unpacked arrays within constraints.
randstruct
Treats all fields of an unpacked struct as 'rand', regardless of whether an explicit 'rand'
attribute is specified for the field or not.
skew
Skews randomize results (ACT solver only).
srandom
(enabled by default) Any occurrence of the $srandom(seed) will be evaluated as
process::self().srandom(seed). If srandom is disabled, any occurrence of $srandom is
evaluated as a user-defined system function call (PLI). If no user-defined PLI for
$srandom is found, an error is issued during elaboration. Specifying vsim
-pedantic_errors disables the srandom extension (even if it is enabled via
-svrandext=+srandom).

1782 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
SvRandExtensions

strictstab
Enables “strict” random stability, which guarantees that two instances of the same
class, having the same randstate, will generate the same randomize() results,
regardless of the order in which the randomize() calls are made and independent of
any randomize() calls that are made before them. Enabling this option can negatively
impact randomize() performance for some scenarios.
Description
You can override these extensions with the vsim -svrandext argument.

Questa® SIM User's Manual, v2023.4 1783

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.

1784 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1785

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.

1786 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1787

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

1788 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1789

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.

1790 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1791

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.

1792 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1793

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.

1794 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1795

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.

1796 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1797

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

1798 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1799

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
toolblock

toolblock
Specifies the file containing one or multiple toolblock directives to be used by the vencrypt and
vhencrypt commands.
Usage
toolblock = {<key_file_name>[,<rights_file_name>]} ...
Arguments
• Specifies the root name of a file that contains directives intended for a toolblock.
o key file name— The root name of a file that contains directives intended for a tool
block. Generally, it is the name of a key (key_keyname) contained within the file.
This file is in the "keyring" directory after appending either *.deprecated or *.active
to the base name.
o rights file name— Optionally, a "rights file" name may appear after the keyfile
name; It contains the control directives defining user rights. You are not required to
have a ".depreceated" or ".active" suffix. However, it must have a *.rights suffix.

1800 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1801

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.

1802 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1803

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

1804 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1805

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.

1806 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1807

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.

1808 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1809

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

1810 Questa® SIM User's Manual, v2023.4

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
Questa SIM.
Usage
UseUvmc = { 0 | 1 }
Arguments
• The arguments are described as follows:
o 0 — (default) Off
o 1 — On

Questa® SIM User's Manual, v2023.4 1811

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

1812 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1813

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.

1814 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1815

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.

1816 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1817

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.

1818 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1819

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

1820 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1821

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.

1822 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
wholefile

wholefile
Controls whether the encryption commands encrypt the entire file by either ignoring or using all
pragmas that are present in the input.
Usage
wholefile = { 0 | 1 }
Arguments
• The default is 0 which directs the encryption commands to use all the protect directives
embedded in the input. If you set the variable to 1, then the encryption commands will
ignore all encryption directives except for "viewport" and "interface_viewport”.

Questa® SIM User's Manual, v2023.4 1823

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.

1824 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1825

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.

1826 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1827

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

1828 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1829

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.

1830 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1831

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.

1832 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1833

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.

1834 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1835

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.

1836 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1837

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.

1838 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1839

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.

1840 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1841

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.

1842 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
XpropAssertionLimit

XpropAssertionLimit
Section [vsim]
This variable sets the default fail count limit of X propagated assertions.
Syntax
XpropAssertionLimit = <n>
Arguments
• The arguments are described as follows:
o <n> — (default) 5. Any non-negative integer, or -1. A value of -1 indicates
unlimited assertions.
You can override this variable setting using the xprop assertlimit command.

Questa® SIM User's Manual, v2023.4 1843

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.
Common Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Hierarchical Library Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Creating a Transcript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
Using a Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Assertion Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Turn Off Warnings from Arithmetic Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1846
Force Command Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Restart Command Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
VHDL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847
Delay Opening VHDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1847

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 Questa SIM (it
is not user-definable). Questa SIM 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 Questa SIM commands and operations to find the libraries.

Hierarchical Library Mapping

By adding an “others” clause to your modelsim.ini file, you can have a hierarchy of library
mappings. If the Questa SIM tools do not find a mapping in the modelsim.ini file, then they will

1844 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 modelsim.ini Variables
Creating a Transcript File

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/questasim/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 Questa SIM 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 Questa SIM command
immediately after Questa SIM starts:

transcript file ""

Questa® SIM User's Manual, v2023.4 1845

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

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

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 Questa SIM prompt:

set NumericStdNoWarnings 1
run 0
set NumericStdNoWarnings 0
run -all

1846 Questa® SIM User's Manual, v2023.4

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

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

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

VHDL Standard
You can specify which version of the 1076 Std Questa SIM 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

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

Questa® SIM User's Manual, v2023.4 1847

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
modelsim.ini Variables
Delay Opening VHDL Files

1848 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix B
Design Packager

The Questa Design Packager is a utility that captures a design and test environment with the
intention of sharing the design with Siemens EDA. The packager executes the user’s script then
collects a directory with all necessary files. When the design is unpacked, it will be ready to run
without modification.For a complete description of the pkgr comand consult the command
reference page in the QuestaSIM Reference manual.
The Design Packager collects and tars your test and design environment with all files necessary
to run independent of your network. When the design is unpacked, it is ready to run without
modification. The Design Packager is intended to capture a single test with the design. Capture
of a full regression suite is not fully supported.

The Design Packager has various arguments to control how you pack your design, but one
feature is that you can scripts as in the following examples:

• pkgr run.csh
• pkgr make
• pkgr “make run”
You must run the test before running the Design Packager or use the --exec switch to run the
design while packaging. Please note that using –exec switch can greatly increase the amount of
time the Design Packager takes to package the design. Run scripts and make files that have
several arguments must be inside quotes. For example:

pkgr “make run_batch DEBUG_TEST=1”

he Design Packager creates a log file called “pkgr.log” by default. It is important to review the
warnings and errors in this log file before attempting to unpackage and run the design.The
Design Packager does not tar the packager output directory by default. O

Once you have determined that the packaged design has been captured correctly, add the “-tar”
switch to the pkgr command line to create a zipped tar file.

Prior to the 2022.3 release the Design Packager was unable to capture any file that was used by
a Verilog System task or function if the filename was not specified as a literal string. Following
is a Verilog code snippet that shows the case when the Design Packager could not determine
and capture the filename:

string myFileName = "testfile.txt";

int fileDesc;
initial
fileDesc = $fopen(myFileName, "r");

Questa® SIM User's Manual, v2023.4 1849

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

In the 2022.3 release, functionality was added to thhe vsim command to help the Design
Packager resolve these filenames. It requires adding a switch with a filename on the user’s vsim
command line before running the simulation, and a switch plus that same filename on the
Design Packager command line. Vsim can resolve the filenames used by the system task/
function and write that information into a text file that is then supplied to the Design Packager
so they can be packaged.

Following is an example of this usage. Notice that “filenames.txt” is an output file on the vsim
command line and an input file on the pkgr (Design Packager) command line.

•vsim -dp_dump_systask_filenames filenames.txt -lib work -c -do "run -all;

quit -f" opt•pkgr --add_systasks_filelist filenames.txt -F t.csh

The Design package recognizes and packages qrun command lines. It is handled the same as
any other command line. No special switches are required. The following is an example of use
the Design Packager with qrun:

pkgr “qrun t.sv"

The Design Packager supports the following qrun arguments:

• -f / -F / -file
• -l / -log / -logfile
• -designfile
• -load_elab
• -defineall <macro=value>
• -env
• -makelib
• -precompile
• -script
• --uvm
• -uvmexthome
• -uvmhome
• -reflib
• -outdir
• -<tool>.ext

1850 Questa® SIM User's Manual, v2023.4

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

Following are usage tips on using Design Packager:

• Environments with run scripts that run in the background or in parallel are not currently
supported by the Design Packager and may not be captured correctly. It is recommended
that the user disable all parallelism when capturing the design with the Design Packager
• Since the Packager does not evaluate `ifdef, `ifndef macros it will always try to package
conditionally included include files regardless of the value of these macros. In some
cases, these include files don’t exist in the user’s environment which will result in a
missing include file warning. This can be safely ignored.
• The Packager cannot track any files, directories, etc. that are removed or moved during
runtime. The files, etc. must exist for the packager to copy them.
o Any files that are removed by the user's run script during runtime will not be
captured by the packager
o The Packager will produce an error count for files that are not found.
o You can avoid this issue by using the “–exec” switch. Note that this will increase the
time it takes the Design Packager to package the design
• The packager doesn't support/recognize encryption. All encrypted source files are
copied without any type of processing

Questa® SIM User's Manual, v2023.4 1851

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

1852 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix C
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854

Questa® SIM User's Manual, v2023.4 1853

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

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1854

Pathname Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855
How Location Mapping Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855

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.
Questa SIM tools open the location map file on invocation if the MGC_LOCATION_MAP
environment variable is set. If MGC_LOCATION_MAP is not set, Questa SIM 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 Questa SIM binaries
• The Questa SIM 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

1854 Questa® SIM User's Manual, v2023.4

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/questasim/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, Questa SIM expects an
environment variable to be set for each logical pathname (with the same name). Questa SIM
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, Questa SIM 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, Questa SIM will automatically set it to “/home/vhdl/src”.

Questa® SIM User's Manual, v2023.4 1855

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

1856 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix D
Error and Warning Messages

This appendix describes the messages and status information that Questa SIM displays in the
Transcript window.
Message System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858
Suppression of Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1860
Exit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862
Miscellaneous Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Error Messages from the sccom Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1869
Enforcing Strict 1076 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870

Questa® SIM User's Manual, v2023.4 1857

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

Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1858

Getting More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Message Severity Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859
Syntax Error Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859

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 D-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 Questa SIM 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.

1858 Questa® SIM User's Manual, v2023.4

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:

• Use the -error, -fatal, -note, -suppress, and -warning arguments to sccom, vcom, vlog,
vopt, or vsim. See the command descriptions in the Reference Manual for details on
those arguments.
• Use the suppress command.
• Set a permanent default in the [msg_system] section of the modelsim.ini file. See
modelsim.ini Variables for more information.
Related Topics
Suppression of Warning Messages

Syntax Error Debug Flow

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

Questa® SIM User's Manual, v2023.4 1859

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

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.

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

1860 Questa® SIM User's Manual, v2023.4

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

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.

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

Questa® SIM User's Manual, v2023.4 1861

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

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

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 Questa SIM 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 D-1 lists the exit codes used by Questa SIM commands, processes, and languages.

1862 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1863

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 D-2. Exit Codes (cont.)

Exit code Description
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)
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 Questa SIM
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 — Questa SIM was unable to locate a C compiler to compile the DPI
exported tasks or functions in your design.

1864 Questa® SIM User's Manual, v2023.4

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

• Suggested Action —Make sure that a C compiler is visible from where you are running
the simulation.

Empty port name warning

# ** WARNING: <path/file_name>: (vlog-2605) empty port name in port list.
# ** WARNING: <path/file_name>: (vopt-2605) empty port name in port list.

• Description — Questa SIM reports these warnings if you use the -lint argument with
vlogor vopt. 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

• Description — Questa SIM 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, Questa SIM 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 — Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1865

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

• 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 Questa SIM, you need to download and install 3
files from the ftp site. These files are:
questasim-base.mis

questasim-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 Questa SIM 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

1866 Questa® SIM User's Manual, v2023.4

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 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.
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 — Questa SIM 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 — Questa SIM could not locate the libswift entry and therefore could not
link to the Logic Modeling library.

Questa® SIM User's Manual, v2023.4 1867

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

• 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 — Questa SIM has ended the simulation after 10000000 iterations in a
zero-delay loop.
• Suggested action — Set the iteration limit variable from the Simulate > Runtime
Options menu or increase the IterationLimit variable in the modelsim.ini file and try to
continue the simulation.
If the problem persists, follow these steps to find and debug the zero-delay loop causing
the error:
a. Re-run vopt with +acc to open full visibility to the design.

Tip
For large designs, use +acc=npr with the vopt command for less impact on the
performance.

b. Re-run vsim with +autofindloop.

This produces the vsim-3601 error again, but with information about zero-delay
loops.
# ** 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

c. Use this information to debug any loops in your design. The following are potential
coding techniques that lead to zero-delay loops:
• A missing or incorrectly applied SDF annotation to a netlist.
• An RTL design with an asynchronous feedback loop with no delays.
• Processes without wait statements or sensitivity lists, for example:
a <= not b;
b <= not a;

1868 Questa® SIM User's Manual, v2023.4

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

• 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 Questa SIM 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)
• 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.

Questa® SIM User's Manual, v2023.4 1869

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

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 Questa SIM’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].

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

1870 Questa® SIM User's Manual, v2023.4

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

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, Questa SIM'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
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.

Questa® SIM User's Manual, v2023.4 1871

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

• 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 Questa SIM displays only a
compiler warning and then performs an implicit subtype conversion at run time.
To enforce the prior compiler behavior, use vcom -pedanticerrors.

1872 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix E
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.
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.

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

Accessing 50000 Series Error Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876
Why Series 50000 Errors Occur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879
Concepts Involved in the Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Transaction Types and Time Queue ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Parents and Children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884

Questa® SIM User's Manual, v2023.4 1873

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

Deleted Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884

TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
Understanding the ‘Time Queue’ ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
Viewing the Time Queue ID Number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
TQ Id Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887
Understanding ‘Parents’ and ‘Children’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1890
Parent/Child Relationship Related Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1891
Understanding Generation and Recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893
Generation/Recognition Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1894
Understanding Deletions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896
Deletion Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896
Understanding Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
Activated Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899
Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1901
Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1902
Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903
Understanding Start and End Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1904
Understanding the Volatile Clause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Volatile Clause Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Understanding Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907
Activity Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907
Understanding ‘Throw’ and ‘Catch’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1908
Throw and Catch Related Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1908
Understanding TLM and WLM Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
WLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
WLM-connected and TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910

Accessing 60000 Series Error Documentation

The 60000 series documentation is included in the install.
Note
To access documentation regarding the 60000 series errors, you must open a browser to a
specific path within the installed QVIP library.

1874 Questa® SIM User's Manual, v2023.4

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

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 E-1).
Figure E-1. InfoHub for QVIP Library

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 QVIP API Reference.

Questa® SIM User's Manual, v2023.4 1875

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Accessing 50000 Series Error Documentation

Figure E-2. QVIP API Reference Information

4. Select "Assertions" on the left hand column (Figure E-3) to see the list of 6000 series
messages.
Figure E-3. Select Assertions

5. Click the appropriate 6000 series message to view its documentation.

Accessing 50000 Series Error Documentation

The 50000 Series documentation is included in the install.
Note
To access documentation regarding the 50000 series errors, you must open a browser to a
specific path within the installed QVIP library.

1876 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Questa Verification IP Errors
Accessing 50000 Series Error Documentation

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 E-4).
Figure E-4. QVIP Library

2. Choose the “Questa VIP Library” scope.

3. Under “Other References,” select “Base QVIP Reference” and click Open (Figure E-5).

Questa® SIM User's Manual, v2023.4 1877

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Questa Verification IP Errors
Accessing 50000 Series Error Documentation

Figure E-5. Base QVIP Reference

The local HTML version of the Base QVIP Reference Manual opens in a separate
browser tab.
4. Expand “Overview” under “QVIP Fundamentals” and select “Errors” in the left column
(Figure E-6).

1878 Questa® SIM User's Manual, v2023.4

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

Figure E-6. Select Errors from QVIP Fundamentals List

5. Click the appropriate 50000 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.
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.

Questa® SIM User's Manual, v2023.4 1879

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

Prerequisites for Error Debugging

Familiarity with Questa Verification IP and the QuestaSIM GUI.

Related Topics
Verifying Designs with Questa Verification IP Library Components

1880 Questa® SIM User's Manual, v2023.4

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

Parents and Children. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882
Generation and Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
Deleted Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884
TLM and WLM Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1884

Transaction Types and Time Queue ID

There are various methods and approaches to debugging a design, with the Questa SIM 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 E-7. 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.

Questa® SIM User's Manual, v2023.4 1881

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

1882 Questa® SIM User's Manual, v2023.4

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 E-8. 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 E-8. Generation and Recognition

Related Topics
Parents and Children
Questa Verification IP Transaction Details in Transaction View Window
Communication Semantics

Questa® SIM User's Manual, v2023.4 1883

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.

1884 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1885

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 Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886

The Time Queue ID Number Reported in Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886
TQ Id Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887

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.

1886 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1887

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

1888 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1889

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 E-9.
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 E-9. 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 E-9, 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 E-9, the ‘Transfer’ transaction has
two children: an ‘Address’ transaction and a ‘Data’ transaction. It also has one parent: ‘Burst

1890 Questa® SIM User's Manual, v2023.4

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

Transfer’. Each ‘Burst Transfer’ transaction can have multiple ‘Transfer’ transactions as
children.

Parent/Child Relationship Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1891

Parent/Child Relationship Related Errors

Context: QVIP
The errors in this section are related to the transaction queue id.

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

Questa® SIM User's Manual, v2023.4 1891

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

1892 Questa® SIM User's Manual, v2023.4

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 E-10. 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 E-10. 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 E-11. 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 E-11. 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.

Questa® SIM User's Manual, v2023.4 1893

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 E-10 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 E-11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1894

Generation/Recognition Related Errors

Context: QVIP transactions
The errors in this section are related to the transaction queue id.

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

1894 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1895

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

Deletion Related Errors

Context: QVIP errors.
The errors in this section are related to the transaction queue id.

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

1896 Questa® SIM User's Manual, v2023.4

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

Uni-directional Transmission of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899
Uni-directional Reception of Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1901
Constraining Communication Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1902
Communication Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903

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.

Questa® SIM User's Manual, v2023.4 1897

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 E-12. 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 E-13. Activating MVC_transaction

1898 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1899

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 E-15. 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 E-16. 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.

1900 Questa® SIM User's Manual, v2023.4

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 E-17. 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 E-18. Receive MVC_transaction, MVC_Message or MVC_Stripe

Questa® SIM User's Manual, v2023.4 1901

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 E-19. 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 E-20. 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.

1902 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1903

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

1904 Questa® SIM User's Manual, v2023.4

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 E-21. MVC_Transaction and MVC_Message Start and End Times

Figure E-22 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 E-22. MVC_Stripe Start and End Times

Questa® SIM User's Manual, v2023.4 1905

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

Volatile Clause Related Error

Context: QVIP errors
The errors in this section are related to the volatile clause.

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

1906 Questa® SIM User's Manual, v2023.4

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

Activity Related Errors

Context: QVIP errors
The errors in this section are related to activities.

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

Questa® SIM User's Manual, v2023.4 1907

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

Throw and Catch Related Error

Context: QVIP errors
The error in this section is related to throw and catch errors.

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

1908 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
TLM-connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
WLM-connected and TLM-connected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
TLM/WLM Related Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910

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.

Questa® SIM User's Manual, v2023.4 1909

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.

1910 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1911

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

1912 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix F
Verilog Interfaces to C

This appendix describes the Questa SIM 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. In addition, you may write your own
interface applications.

Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914

GCC Compiler Support for use with C Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915
Registering PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916
Registering VPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917
Registering DPI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1919
DPI Use Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1921
PLI Catalog Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1928
Compiling and Linking C Applications for Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . 1938
Compiling and Linking C++ Applications for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 1942
Specifying Application Files to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
PLI Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947
VPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947
DPI Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948
The PLI Callback reason Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949
The sizetf Callback Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1951
PLI Object Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1952
Third Party PLI Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1952
Support for VHDL Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953
IEEE Std 1364 ACC Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954
IEEE Std 1364 TF Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954
SystemVerilog DPI Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957
Verilog-XL Compatible Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957

Questa® SIM User's Manual, v2023.4 1913

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

PLI/VPI Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Checkpointing and Interface Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1959
Debugging Interface Application Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1960

Implementation Information
This chapter describes only the details of using the Verilog interfaces with Questa SIM Verilog
and SystemVerilog.
• Questa SIM SystemVerilog implements DPI as defined in the IEEE Std 1800-2017.
• 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 Series SystemVerilog standards.
New applications should not rely on this functionality being present and should instead
use the VPI.
• VPI Implementation — The VPI is implemented as defined in IEEE Std 1800-2017. 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, the combined IEEE Std 1364-2005/IEEE Std 1800-2005
object models, the IEEE Std 1800-2009 object models, or the ‘latest’ object models. By
default, the simulator uses the ‘latest’ object models, which are equivalent to the 2009
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 F-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

1914 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1915

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, Questa SIM 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 Questa SIM 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 Questa SIM Verilog.

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

1916 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1917

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 F-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 */
};

1918 Questa® SIM User's Manual, v2023.4

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>

Questa® SIM User's Manual, v2023.4 1919

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

1920 Questa® SIM User's Manual, v2023.4

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 Questa SIM DPI depends on the flow presented in this section.
Figure F-1. DPI Use Flow Diagram

1. Run vlog to generate a dpiheader.h file.

This file defines the interface between C and Questa SIM 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.

Questa® SIM User's Manual, v2023.4 1921

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.

Questa SIM 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 Questa SIM.
3. Compile the C code using vlog. For example:
vlog *.c

4. Simulate the design. For example

vsim top

DPI and the vlog Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1922

Deprecated Legacy DPI Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923
When Your DPI Export Function is Not Getting Called . . . . . . . . . . . . . . . . . . . . . . . . . 1923
Troubleshooting a Missing DPI Import Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1924
Simplified Import of Library Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1924
Optimizing DPI Import Call Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925
DPI Arguments of Parameterized Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925
Making Verilog Function Calls from non-DPI C Models . . . . . . . . . . . . . . . . . . . . . . . . 1926
Calling C/C++ Functions Defined in PLI Shared Objects from DPI Code . . . . . . . . . . 1926

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.

1922 Questa® SIM User's Manual, v2023.4

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 Questa SIM.
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”.

Questa® SIM User's Manual, v2023.4 1923

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 and can produce incorrect C++ names if you do not use the
appropriate extern “C” declaration.
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, 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.

1924 Questa® SIM User's Manual, v2023.4

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

<installDir>/verilog_src/dpi_cpack/dpi_cpackages.sv

You do not need to compile this file, it is automatically available as a built-in part of the
SystemVerilog simulator.

Note
On Windows platforms, you must use the -sv_lib option to import these 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. And the element types can be both signed and
unsigned.
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);

Questa® SIM User's Manual, v2023.4 1925

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-2017, Section 35.5.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 Questa SIM 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.

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 or DPI code.

1926 Questa® SIM User's Manual, v2023.4

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

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

If your shared objects contain circular references you must combine the shared object files with
the -gblso argument to vsim.

For more information about this topic please refer to the section "Loading Shared Objects with
Global Symbol Visibility."

Questa® SIM User's Manual, v2023.4 1927

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
PLI Catalog Use Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1935

1928 Questa® SIM User's Manual, v2023.4

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

PCAT File with PLI Autocompile Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
PLI Catalog File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1931

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

Questa® SIM User's Manual, v2023.4 1929

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.

1930 Questa® SIM User's Manual, v2023.4

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 your Questa SIM 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 F-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.

Questa® SIM User's Manual, v2023.4 1931

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

1932 Questa® SIM User's Manual, v2023.4

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.

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.

Questa® SIM User's Manual, v2023.4 1933

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

$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

1934 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1935
Using a PCAT File with PLI Autocompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936

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

Questa® SIM User's Manual, v2023.4 1935

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.

1936 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1937

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 Questa SIM. 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
Questa SIM <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 all UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938

Windows Platforms — C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1939
Linux Platforms — C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1940

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
LD_LIBRARY_PATH_64= <library path without filename> (for 64-bit)

1938 Questa® SIM User's Manual, v2023.4

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

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>\questasim\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>\questasim\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 Questa SIM can
find the symbol when it dynamically loads the DLL.
If you need to run the profiler (see “Classic Performance Profiler” on page 1325) on a
design that contains interface code, add these two switches to the link commands shown
above:
/DEBUG /DEBUGTYPE:COFF

These switches add symbols to the .dll that the profiler can use in its report.

Questa® SIM User's Manual, v2023.4 1939

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

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 Questa SIM 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>/questasim/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>/questasim/include app.c
gcc -shared -Bsymbolic -o app.so app.o

To compile 64-bit systems for 32-bit operation, specify the -m32 argument on both the
compile and link gcc command lines.

1940 Questa® SIM User's Manual, v2023.4

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

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>/questasim/include math_app.c
gcc -shared -Bsymbolic -o math_app.so math_app.o -lm

Questa® SIM User's Manual, v2023.4 1941

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
Questa SIM does not have direct support for any language other than standard C; however, C++
code can be loaded and executed under certain conditions.
Since Questa SIM'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 Questa SIM.

Although compilation and simulation switches are platform-specific, loading shared libraries is
the same for all platforms.

For PLI/VPI only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1942

Windows Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1943
Linux Platforms — C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1944

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

1942 Questa® SIM User's Manual, v2023.4

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>\questasim\include app.cxx
link -dll -export:<init_function> app.obj
<install_dir>\questasim\win32\mtipli.lib /out:app.dll

For 64-bit:
cl -c [-GX] -I<install_dir>\questasim\include app.cxx
link -dll -export:<init_function> app.obj
<install_dir>\questasim\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 Questa SIM can
find the symbol when it dynamically loads the DLL.
If you need to run the profiler (see “Classic Performance Profiler” on page 1325) 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.

Questa® SIM User's Manual, v2023.4 1943

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

• MinGW
For 32-bit:
g++ -c -I<install_dir>\questasim\include app.cpp
g++ -shared -Bsymbolic -o app.dll app.o
-L<install_dir>\questasim\win32 -lmtipli

For 64-bit:
g++ -c -I<install_dir>\questasim\include app.cpp
g++ -shared -Bsymbolic -o app.dll app.o
-L<install_dir>\questasim\win64 -lmtipli

Questa SIM 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>/questasim/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>/questasim/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>/questasim/include math_app.cpp
g++ -shared -Bsymbolic -o math_app.so math_app.o -lm

1944 Questa® SIM User's Manual, v2023.4

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
DPI File Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
Loading Shared Objects with Global Symbol Visibility . . . . . . . . . . . . . . . . . . . . . . . . . 1946

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 F-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 Questa SIM expects
are: .dll for Win32/Win64, .so for all other platforms.)

Questa® SIM User's Manual, v2023.4 1945

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

In addition, you can use the -gblsoauto argument to vsim to enable global symbol visibility
when loading the vsim_auto_compile shared library. This is equivalent to issuing the following
command:

vsim –gblso <tmp_path>/linux_gcc-10.3.0/vsim_auto_compile.so

1946 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Verilog Interfaces to C
PLI Example

Caution
Using the -gblsoauto argument can entail a risk of symbol conflicts with other precompiled
objects.

PLI Example
The following example shows a small but complete PLI application for Linux.
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>/questasim/examples/verilog/vpi.

Questa® SIM User's Manual, v2023.4 1947

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>/examples/systemverilog/dpi directory.

1948 Questa® SIM User's Manual, v2023.4

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

Given the file 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) */
}

and the file 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

You will first compile the Verilog code:

vlib work
vlog -sv -dpiheader dpiheader.h hello.v hello_c.c

then simulate and run the design:

vsim -c hello_top -do "run -all; quit -f"

which results in the following output:

# 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 Questa SIM Verilog, and

Questa® SIM User's Manual, v2023.4 1949

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

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

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

1950 Questa® SIM User's Manual, v2023.4

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

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

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 Questa SIM Verilog.

reason_force

Not supported in Questa SIM Verilog.

reason_release

Not supported in Questa SIM Verilog.

reason_disable

Not supported in Questa SIM 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".

Questa® SIM User's Manual, v2023.4 1951

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Verilog Interfaces to C
PLI Object Handles

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
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 Questa SIM 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 Questa SIM
Verilog. Even without the instructions, it is still likely that you can get it to work with
Questa SIM Verilog as long as the application uses standard PLI routines. The following
guidelines are for preparing a Verilog-XL PLI application to work with Questa SIM 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 Questa SIM 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>/questasim/include veriuser.c

% gcc -shared -Bsymbolic -o app.so veriuser.o libapp.a

The PLI application is now ready to be run with Questa SIM 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”).

1952 Questa® SIM User's Manual, v2023.4

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

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.
The following table lists the VHDL objects for which handles may be obtained and their type
and fulltype constants:
Table F-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 Questa SIM VHDL foreign
interface (mti_* routines). See the FLI Reference Manual for more information.

Questa® SIM User's Manual, v2023.4 1953

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

Questa SIM Verilog supports the following ACC routines:

Table F-6. Supported ACC Routines

Routines
acc_append_delays acc_fetch_itfarg_str acc_next_driveracc_next_h
acc_append_pulsere acc_fetch_timescale_infoacc_fet iconnacc_next_inputacc_ne
acc_closeacc_collectacc_com ch_type xt_loadacc_next_loconnacc
pare_handlesacc_configureac acc_fetch_type_stracc_fetch_val _next_modpathacc_next_net
c_countacc_fetch_argcacc_fe ue acc_next_outputacc_next_p
tch_argvacc_fetch_attribute acc_freeacc_handle_by_nameacc_h arameteracc_next_portacc_
acc_fetch_attribute_intacc_ andle_calling_mod_macc_handle_c next_portoutacc_next_prim
fetch_attribute_stracc_fetc onditionacc_handle_connacc_hand itiveacc_next_scopeacc_ne
h_defnameacc_fetch_delay_mo le_hiconnacc_handle_interactive xt_specparamacc_next_tchk
deacc_fetch_delaysacc_fetch _scopeacc_handle_loconnacc_hand acc_next_terminalacc_next
_directionacc_fetch_edgeacc le_modpathacc_handle_notifierac _topmodacc_object_in_type
_fetch_fullnameacc_fetch_fu c_handle_objectacc_handle_paren listacc_object_of_typeacc
lltypeacc_fetch_indexacc_fe tacc_handle_pathacc_handle_path _product_typeacc_product_
tch_locationacc_fetch_namea inacc_handle_pathoutacc_handle_ versionacc_release_object
cc_fetch_paramtypeacc_fetch portacc_handle_scopeacc_handle_ acc_replace_delaysacc_rep
_paramvalacc_fetch_polarity simulated_netacc_handle_tchkacc lace_pulsere
acc_fetch_precisionacc_fetc _handle_tchkarg1acc_handle_tchk acc_reset_bufferacc_set_i
h_pulsereacc_fetch_rangeacc arg2acc_handle_terminalacc_hand nteractive_scopeacc_set_p
_fetch_sizeacc_fetch_tfarga le_tfargacc_handle_itfargacc_ha ulsereacc_set_scopeacc_se
cc_fetch_itfarg ndle_tfinstacc_initialize t_valueacc_vcl_addacc_vcl
acc_fetch_tfarg_intacc_fetc acc_nextacc_next_bitacc_next_ce _deleteacc_version
h_itfarg_intacc_fetch_tfarg llacc_next_cell_loadacc_next_ch
_str ild

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

Questa SIM Verilog supports the following TF (task and function) routines;

1954 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1955

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 F-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
1956 Questa® SIM User's Manual, v2023.4

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

Questa SIM SystemVerilog supports all routines in the "svdpi.h" file as defined in Annex I of
the SystemVerilog LRM.

Verilog-XL Compatible Routines

The following PLI routines are not defined in IEEE Std 1364, but Questa SIM 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 Questa SIM with 32-bit Applications

If you have 32-bit PLI/VPI/DPI applications and want to use 64-bit Questa SIM, 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.

Questa® SIM User's Manual, v2023.4 1957

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Invoking a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958

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

1958 Questa® SIM User's Manual, v2023.4

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 F-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
PLI/VPI Tracing

Checkpointing and Interface Code

The checkpoint feature in Questa SIM captures the state of PLI/VPI/DPI code.
See The PLI Callback reason Argument for reason arguments that apply to checkpoint/restore

The following sections pertain to the legacy manual restore flow described by Checkpointing
Foreign C Code. They are not relevant to the auto restore flow.

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.

Questa® SIM User's Manual, v2023.4 1959

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

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
memory allocated with raw malloc() will not be restored correctly, and simulator crashes can
result.

Debugging Interface Application Code

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

1960 Questa® SIM User's Manual, v2023.4

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

Related Topics
C Debug

Questa® SIM User's Manual, v2023.4 1961

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

1962 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix G
System Initialization

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963
Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1964
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967

Files Accessed During Startup

When you invoke Questa SIM, it reads several files in file system and configuration
environment.
Table G-1 lists the files that are read during startup. They are listed in the order in which they
are accessed.
Table G-1. Files That Questa SIM 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 Questa SIM tools to find source files based on
easily reallocated "soft" paths; default file name is
mgc_location_map
.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

Questa® SIM User's Manual, v2023.4 1963

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 Questa SIM. 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 (../questasim/<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. Finds the location map file by evaluating the following conditions:
o use MGC_LOCATION_MAP if it exists (if this variable is set to "no_map",
Questa SIM skips initialization of the location map); else
o use mgc_location_map if it exists; else
o use $(HOME)/mgc/mgc_location_map; else
o use $(HOME)/mgc_location_map; else
o use$(MGC_HOME)/etc/mgc_location_map; else
o use $(MGC_HOME)/shared/etc/mgc_location_map; else

1964 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Initialization Sequence

o use $(MODEL_TECH)/mgc_location_map; else

o use $(MODEL_TECH)/../mgc_location_map; else
o use no map
Environment Variables used: MGC_LOCATION_MAP, HOME, MGC_HOME,
MODEL_TECH
4. Reads various variables from the [vsim] section of the modelsim.ini file. See
modelsim.ini Variables for more details.
5. Parses any command line arguments that were included when you started Questa SIM
and reports any problems.
6. 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
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
7. Initializes the simulator’s Tcl interpreter.
8. Checks for a valid license (a license is not checked out unless specified by a
modelsim.ini setting or command line option).
9. The next four steps relate to initializing the graphical user interface.
10. Sets Tcl variable MTI_LIB_DIR=$(MODEL_TECH_TCL)
Environment Variables used: MTI_LIB_DIR, MODEL_TECH_TCL
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

Questa® SIM User's Manual, v2023.4 1965

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Initialization Sequence

o use ./modelsim.tcl; else use $(HOME)/modelsim.tcl if it exists

That completes the initialization sequence. Also note the following about the modelsim.ini file:

• When you change the working directory within Questa SIM, 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, Questa SIM
updates the appropriate sections of the file.

1966 Questa® SIM User's Manual, v2023.4

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 Questa SIM, 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 Questa SIM operation.
Expansion of Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967
Setting Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1968
Creating Environment Variables in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974
Library Mapping with Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974
Referencing Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1975
Removal of Temporary Files (VSOUT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1975

Expansion of Environment Variables

Questa SIM 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 Questa SIM 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
Location Mapping

Questa® SIM User's Manual, v2023.4 1967

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Setting Environment Variables

modelsim.ini 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 Questa SIM 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.

EDITOR
The EDITOR environment variable specifies the editor to invoke with the edit command

1968 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Setting Environment Variables

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 Questa SIM to the same path as
MODEL_TECH_TCL; must point to libraries supplied by Siemens.

ITK_LIBRARY
Identifies the pathname of the [incr]Tk library; set by Questa SIM to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Siemens.

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.

Questa® SIM User's Manual, v2023.4 1969

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

1970 Questa® SIM User's Manual, v2023.4

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

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_FINDLOOP_STEP_LIMIT
Changes the default findloop step limit of 500 to a positive integer you supply.

MTI_LIB_DIR
Identifies the path to all Tcl libraries installed with Questa SIM.

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

Questa® SIM User's Manual, v2023.4 1971

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
System Initialization
Setting Environment Variables

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.

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) Questa SIM 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
questasim/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 Questa SIM reads files.

QUESTASIM_HOME_OVERRIDE
Specifies the directory where the Questa SIM tool suite is installed. This is normally the parent
directory of the various platform directories. If set, this variable overrides any search of the
PATH variable. This should typically only be used in cases where you cannot have the Questa
SIM installation directory placed in your PATH, or if you want to use a different version than
specified in PATH. The tool validates this variable by scanning for the appropriate platform
directory and executables within that directory. If the value of the variable is incorrect,
Visualizer reports an error. This check is only be done if one of the Questa SIM commands are
executed from within the Visualizer through the transcript window command interface.

QUESTASIM_HOME
Specifies the directory where the Questa SIM tool suite is installed.

1972 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Setting Environment Variables

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 Questa SIM to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Siemens.

TK_LIBRARY
Identifies the pathname of the Tk library; set by Questa SIM to the same pathname as
MODEL_TECH_TCL; must point to libraries supplied by Siemens.

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

VISUALIZER_HOME_OVERRIDE
Specifies the directory where the Visualizer tool suite is installed. This directory will be the
parent directory of the various platform directories. If set, the variable overrides any search of
the PATH variable by the vsim tool. Typically, you should only set this variable if you cannot
have the Visualizer installation directory placed in your PATH, or if you want to use a different
version than specified in PATH. The tool validates the value of this variable by scanning for the
appropriate platform directory and executables within that directory. If the value of the variable

Questa® SIM User's Manual, v2023.4 1973

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

is incorrect, vsim reports a fatal error and exits. This check will only be done if the -visualizer
argument is used with the vsim command.

VSIM_LIBRARY
Identifies the pathname of the Tcl files that are used by Questa SIM; set by Questa SIM to the
same pathname as MODEL_TECH_TCL; must point to libraries supplied by Siemens.

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)

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 G-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
Questa SIM 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.

1974 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 System Initialization
Referencing Environment Variables

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 Questa SIM.
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;

Environment variables may also be referenced from the Questa SIM 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 Questa SIM
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.

Questa® SIM User's Manual, v2023.4 1975

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)

1976 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix H
Third-Party Model Support

This appendix provides information about using Questa SIM with the Synopsys SmartModels
and Synopsys hardware modeling.
Synopsys SmartModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978
VHDL SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987
Synopsys Hardware Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1988
VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1989
hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1990

Questa® SIM User's Manual, v2023.4 1977

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

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

Verilog SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987

1978 Questa® SIM User's Manual, v2023.4

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

Questa SIM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Creating Foreign Architectures with sm_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
sm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1981
SmartModel Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Command Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1984
SmartModel Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1985
Memory Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987

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 Questa SIM
installation directory indicated by the MODEL_TECH environment variable.
Questa SIM 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 Questa SIM installation directory.

Questa® SIM User's Manual, v2023.4 1979

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;

1980 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1981

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.

1982 Questa® SIM User's Manual, v2023.4

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

Questa® SIM User's Manual, v2023.4 1983

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. Questa SIM provides
access to the Command Channel from the command line.
The form of a SmartModel command is:

lmc {<instance_name> | -all} "<SmartModel command>"

1984 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1985

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.

1986 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1987

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

VHDL Hardware Model Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1989

hm_entity Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1990

1988 Questa® SIM User's Manual, v2023.4

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

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

Questa® SIM User's Manual, v2023.4 1989

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1990
hm_entity Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1991
Hardware Model Vector Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993
Hardware Model Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994

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.

1990 Questa® SIM User's Manual, v2023.4

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.

Questa® SIM User's Manual, v2023.4 1991

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.

1992 Questa® SIM User's Manual, v2023.4

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!

Questa® SIM User's Manual, v2023.4 1993

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>

1994 Questa® SIM User's Manual, v2023.4

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>

Questa® SIM User's Manual, v2023.4 1995

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

1996 Questa® SIM User's Manual, v2023.4

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.

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.