Magellan Ug PDF

Magellan
User Guide
Version C-2009.09
September 2009
Comments?
E-mail your comments about this manual to
magellan-support@synopsys.com.
Copyright Notice and Proprietary Information
Copyright © 2009 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without
prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CRITIC,
CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM, HSPICE, Hypermodel, iN-Phase, in-Sync,
Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill,
PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, Testify, TetraMAX, TimeMill,
TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™)
Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora,
AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia,
Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC
Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision,
DesignerHDL, DesignTime, DFM-Workbench, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI,
Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ,
Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express,
Frame Compiler, Galaxy, Gatran, HANEX, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II,
Hierarchical Optimization Technology, High Performance Option, HotPlace, HSIMplus, HSPICE-Link, iN-Tandem,
Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme,
Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture,
Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product
Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View,
Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate,
ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael, Raphael-NES, RoadRunner, RTL Analyzer,
Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access,
SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC,
Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT,
Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice,
TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System
Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)
MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
All other product or company names may be trademarks of their respective owners.
Contents
1 Installing and Setting up Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Installing Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Using the Synopsys Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Downloading the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Installing Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Setting up Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Setting up Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Configuring Environment and Path Variables . . . . . . . . . . . . . . . . . . . . . 21
Setting up VCS MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Checking Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Checking Your Environment and Version of Magellan . . . . . . . . . . . . . . 24
2 Magellan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
What is Magellan? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Why use Properties/Assertions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Why use Coverage Goals and High-Coverage Stimulus? . . . . . . . . . . . . . . 27
When to use Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Learning to use Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Verilog Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Quick Start Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Magellan Project Files are Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Quick Start Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Magellan User Guide 3

Contents
Source File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Use Smart Defaults to Test SVA/PSL Goals . . . . . . . . . . . . . . . . . . . . . . . . 34
Automatically Extracted Properties (AEPs) . . . . . . . . . . . . . . . . . . . . . . . . . 36
SVA Combinational Property Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
SVA Sequential Property Failure and Debug . . . . . . . . . . . . . . . . . . . . . . . 46
SVA Assertion-Style Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
SVA Functional Coverage Goal Covered . . . . . . . . . . . . . . . . . . . . . . . . . . 58
FSM Coverage and Debug Simulation/Synthesis Mismatches . . . . . . . . . . 64
Magellan GUI Debug SVA Property Failure . . . . . . . . . . . . . . . . . . . . . . . . 69
Extract Reset State from System-level Simulation . . . . . . . . . . . . . . . . . . . 73
4 Mixed-Language Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Quick Start Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Magellan Project Files are Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Quick Start Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Source File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Use Smart Defaults to Test SVA/PSL Goals . . . . . . . . . . . . . . . . . . . . . . . . 86
Use Assertions from SVA Checker Library . . . . . . . . . . . . . . . . . . . . . . . . . 89
Add Custom SVA/PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Add a Reset Task and an SVA Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Run SVA/PSL Cover Functional Coverage Test . . . . . . . . . . . . . . . . . . . . 101
Run State Machine Coverage Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5 Using MG Shell and Magellan Commands . . . . . . . . . . . . . . . . . . . . . . . . 107

Invoking the Magellan GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Using mgui Easy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Getting Started with MG Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Running in Sever Mode Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Running in No Server Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using the Tcl Command Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using the history Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Customizing MG Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4 Magellan User Guide

Contents
Using Magellan Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Getting Help on Commands and Error Messages . . . . . . . . . . . . . . . . 114
Understanding Data and Action Commands . . . . . . . . . . . . . . . . . . . . 115
Using Blocking and Non-Blocking Commands . . . . . . . . . . . . . . . . . . . 115
Creating a Magellan Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Understanding the Magellan Project Structure . . . . . . . . . . . . . . . . . . . 116
Creating a Magellan Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Using Smart Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Smart Defaults Module Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Smart Defaults Example Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Smart Defaults Command Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Running Smart Defaults Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Specifying Multiple Smart Defaults Sessions . . . . . . . . . . . . . . . . . . . . 126
Adding Information to Smart Defaults Modules . . . . . . . . . . . . . . . . . . 127
Mixing Smart Defaults with Custom Modules . . . . . . . . . . . . . . . . . . . . 128
Writing and Running Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using Magellan Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using Telnet with MG Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using a Remote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6 Building and Running a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Building a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Understanding the Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Understanding the Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
User Directory Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Using the Simulation Test Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Running a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Session Run Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Specifying a Debugger for the Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Running 64-bit Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Managing Memory Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Filtering Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Understanding the Run Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Understanding Magellan’s Default Run Behavior . . . . . . . . . . . . . . . . . . . 144
Using Run Modes to Tune Magellan’s Run Behavior . . . . . . . . . . . . . . . . 145
Run Search Engines Only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Contents
Run Short Trace Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Run Formal Only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Run Bounded Proof Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Run Random Simulation Only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Run Code Coverage Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Solver Engine Reporting and Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Reusing a Specific Solver Engine and Effort Level . . . . . . . . . . . . . . . . 149
Using Guideposts to Aid Formal Searches . . . . . . . . . . . . . . . . . . . . . . . . 150
Defining Guidepost Coverage Modules . . . . . . . . . . . . . . . . . . . . . . . . 150
Running Guidepost Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Reporting Guidepost Session Results . . . . . . . . . . . . . . . . . . . . . . . . . 152
Distributing Magellan Engines on a Server Farm . . . . . . . . . . . . . . . . . . . 154
Using Breakpoint Options to Control Magellan Runs . . . . . . . . . . . . . . . . 156
Filtering and Reporting Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7 Preparing Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Describing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Specifying Files for Verilog Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Specifying Files for VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Specifying Files for Mixed-Language Designs . . . . . . . . . . . . . . . . . . . 168
Specifying Compile and Runtime Simulator Options . . . . . . . . . . . . . . 170
Overriding Top-Level Verilog Parameters or VHDL Generics . . . . . . . . 170
Building the Design for the First Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Describing a Minimal Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Adding a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Finding Non-Synthesizable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Synopsys Translate Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ASIC Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
VHDL VITAL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Other Non-Synthesizable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Managing Non-Synthesizable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Rewriting Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Adding ‘ifdef Compiler Directives (Verilog only) . . . . . . . . . . . . . . . 176
Treating Non-Synthesizable Code as a Black Box . . . . . . . . . . . . . . . . 178
Removing Non-Synthesizable Code with Compiler Directives . . . . . . . 184

Contents
Randomizing X Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Using Partial Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Using Verilog Cross-Module References (XMRs) . . . . . . . . . . . . . . . . . . . 187
Remodeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Remodeling Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Controlling Asynchronous Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Evaluating Combinational Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . 193
Understanding the Combinational Loops Report . . . . . . . . . . . . . . . . . 195
Working with Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Automatic Constraint of Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . 197
Using a Template to Write your own Constraints . . . . . . . . . . . . . . . . . 198
Using DesignWare Components (Verilog only) . . . . . . . . . . . . . . . . . . . . . 200
Initializing Verilog UDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Working with VHDL and Mixed-language Designs . . . . . . . . . . . . . . . . . . 201
VHDL Data Type Support at Top Level . . . . . . . . . . . . . . . . . . . . . . . . . 201
Using User-Defined Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Working with Multiple Architectures and Configurations . . . . . . . . . . . . 202
Modifying Top-Level Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Using HDL XMRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Using Extended Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
8 Preparing the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Understanding the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Describing the Environment in the Project File . . . . . . . . . . . . . . . . . . . . . 207
Defining Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Specifying Clock Periods and Time Units . . . . . . . . . . . . . . . . . . . . . . . 208
Specifying Multiple Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Specifying Clocks With Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Clock Specification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Understanding Magellan’s System Clock . . . . . . . . . . . . . . . . . . . . . . . 212
Using RTL Clock Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Understanding and Controlling the Reset State . . . . . . . . . . . . . . . . . . . . 220
Controlling the Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Writing Verilog Reset Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Contents
Writing VHDL Reset Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Using Tcl-based Reset or Reset from File . . . . . . . . . . . . . . . . . . . . . . 230
Using PLI/VHPI Routines to Extract a Reset File . . . . . . . . . . . . . . . . . 247
Handling Uninitialized Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Debugging Reset Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Configuring Input and Internal Design Signals . . . . . . . . . . . . . . . . . . . . . 253
Setting Input Signals to Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Setting Internal Signals to Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Forcing Input Signals to Have Random Values . . . . . . . . . . . . . . . . . . 259
Constraining Input Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Understanding Constraint Models in Magellan . . . . . . . . . . . . . . . . . . . 260
Over-Constraining and Under-Constraining Inputs . . . . . . . . . . . . . . . . 261
Connecting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Using Generator-Style Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Using Assertion-Style Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Overriding Default Parameters in the Environment Code . . . . . . . . . . . 271
Using Cross-Module References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Debugging Constraint Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Constraint Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Biasing Random Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Constraints and Biasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Using Biasing (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Specifying Solve Order for Constraint Solver . . . . . . . . . . . . . . . . . . . . 286
Avoiding Dead-End States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
What are Dead-End States? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Causes of Dead-End States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Avoiding Dead-End States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Identifying and Debugging Constraint Conflicts . . . . . . . . . . . . . . . . . . . . . 296
Debugging Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
9 Testing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Understanding Properties and Property Checkers . . . . . . . . . . . . . . . . . . 300
Why Use Assertions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
About Proofs and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
About Bounded Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Handling SVAs/OVAs During Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Assertions and the Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Contents
Choosing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Using SVAs with Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
SVA Current Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
SVA Action Block Support and Limitations . . . . . . . . . . . . . . . . . . . . . . 306
SVA Local Variable Support Limitations . . . . . . . . . . . . . . . . . . . . . . . . 306
Writing and Connecting SVAs to Designs in Magellan . . . . . . . . . . . . . 312
SVA Coding Guidelines for Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . 313
SVA Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Using SVAs from the Standard Assertion Library . . . . . . . . . . . . . . . . . 319
Adding SVAs to the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Using SVAs with VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Avoiding Incompatible SVA Constructs . . . . . . . . . . . . . . . . . . . . . . . . . 324
SVA Current Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Adding Inline SVAs to VHDL Design Files . . . . . . . . . . . . . . . . . . . . . . 324
Specifying Inline SVAs in Magellan Project File . . . . . . . . . . . . . . . . . . 326
Specifying SVA Binds for VHDL Design Files . . . . . . . . . . . . . . . . . . . . 326
Specifying SVA Binds for VHDL in Magellan Project File . . . . . . . . . . . 327
Using OVA Checkers and Constraints (Verilog only) . . . . . . . . . . . . . . . . . 329
Writing and Binding OVAs to Designs in Magellan . . . . . . . . . . . . . . . . 329
Avoiding Incompatible OVA Constructs . . . . . . . . . . . . . . . . . . . . . . . . 330
Excluding Incompatible OVA Assertions . . . . . . . . . . . . . . . . . . . . . . . . 332
Using OVAs From the Standard Unit Library . . . . . . . . . . . . . . . . . . . . 333
Adding OVAs to the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Using Inline OVAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Using Property Specification Language (PSL) Assertions . . . . . . . . . . . . 340
Avoiding Incompatible PSL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . 340
Using PSL Assertions with Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Using PSL Assertions with VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Using OVL Checkers and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Specifying SVA OVL v2.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Specifying Verilog OVL v1.8 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 350
Specifying VHDL OVL v1.8 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . 351
Using Wildcards to Activate OVLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Excluding OVL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Using Verilog and VHDL Checkers and Constraints . . . . . . . . . . . . . . . . . 354
Adding Instantiated Checkers to the Project File
(Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Adding External Checkers to the Project File . . . . . . . . . . . . . . . . . . . . 357

Contents
Specifying Which Assertions are Checked . . . . . . . . . . . . . . . . . . . . . . . . 360

Specifying Assertions as Checkers or Constraints . . . . . . . . . . . . . . . . 360
Excluding Checkers or Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Assertion Naming in Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Checking a Single Instance of an Assertion . . . . . . . . . . . . . . . . . . . . . 363
Checking All Instances of an OVA Assertion . . . . . . . . . . . . . . . . . . . . 363
Using Pattern Matching with -scope and -ovaPath . . . . . . . . . . . . . . . . 364
Debugging Property Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
10 Testing Automatically Extracted Properties (AEPs) . . . . . . . . . . . . . . . . . . 367

Using AEP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Parallel-case Directives (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . 369
Full-case Directives (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
X Assignments (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Array Boundaries (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Arithmetic Overflow (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Simultaneous Set/Reset (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . 371
Multiple Driver Bus Checks (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . 372
Conflicting Driver Bus Checks (Verilog only) . . . . . . . . . . . . . . . . . . . . 373
Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Testing all AEP Property Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Testing all AEP Coverage Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Limiting the Scope of AEP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Isolating Specific AEP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
11 Testing RTL Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Coverage Testing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Coverage Testing Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Stimulus Generation for RTL State Coverage . . . . . . . . . . . . . . . . . . . . 381
Selecting RTL Coverage Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Defining RTL Coverage Goal Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Adding RTL Coverage Goals to the Project File . . . . . . . . . . . . . . . . . . . . 384
Adding Cross-State Machine Goal Sets . . . . . . . . . . . . . . . . . . . . . . . . 385
Checking FSM State Transition Coverage . . . . . . . . . . . . . . . . . . . . . . 386
Using VHDL Enumeration Signals in a Goal Set . . . . . . . . . . . . . . . . . 386
Generating Stimulus for a Coverage Goal Set . . . . . . . . . . . . . . . . . . . . . 389

Contents
Detecting Deadlock/Livelock Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 389
12 Testing Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Code Coverage Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Block-level Verification Before Testbench Available . . . . . . . . . . . . . . . 392
Comparing Design Behavior to Non-Synthesizable Reference Model . 392
Filling Coverage Holes from System-Level Testbench Environment . . 393
Accelerating Convergence with Parallel Random Simulations . . . . . . . 394
Using the Automated Flow for Line and Condition Coverage . . . . . . . . . . 395
Specifying Code Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Using an Input Coverage Database to Focus Magellan . . . . . . . . . . . . . . 399
Specifying Input Coverage Database Name . . . . . . . . . . . . . . . . . . . . . 400
Identifying Intentionally Unreachable Lines (Verilog only) . . . . . . . . . . . . . 401
Configuring the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Reporting Intentional Unreachables . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Code Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Code Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Using the VCS Uniform Report Generator Tool . . . . . . . . . . . . . . . . . . . . . 406
13 Testing Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Testing SVA/OVA Cover Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Adding SVA/OVA Covers to the Project File . . . . . . . . . . . . . . . . . . . . . 408
Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Functional Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Understanding Inconsistent Coverage Results . . . . . . . . . . . . . . . . . . . 411
Understanding Discovery Coverage Terminology . . . . . . . . . . . . . . . . . 412
Using the Functional Coverage Database to Focus Magellan . . . . . . . . . 413
Reusing Magellan Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . 413
Saving Functional Coverage Databases . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Saving High-Value Regression Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Knowing When You Are Done with Functional Coverage . . . . . . . . . . . 416

Contents
14 Reporting and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Reporting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Automatically Generated Transcripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Trace Length Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
AEP Property Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
AEP FSM State Coverage Detailed Reporting . . . . . . . . . . . . . . . . . . . 425
Assertion Property Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . . . . 426
Code Coverage Goals Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . 427
RTL Coverage Goals Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . . 428
Detailed Report Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Summary Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Accessing Session Results in Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . 432
Bounded Proof Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Vacuous Proof Reporting (SVA/PSL only) . . . . . . . . . . . . . . . . . . . . . . . . . 435
Turning Off Vacuity Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Witness Trace Reporting (SVA/PSL only) . . . . . . . . . . . . . . . . . . . . . . . . . 437
Turning On Witness Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Witness Trace Report Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Cone of Influence Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Generating Cone of Influence Reports . . . . . . . . . . . . . . . . . . . . . . . . . 440
Assertion Cone of Influence Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Debugging Property Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Setting a Default Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Controlling Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
About Waveform Readability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Debugging Without Saving the Test Stimulus . . . . . . . . . . . . . . . . . . . . 449
Debugging a Previously Run Session . . . . . . . . . . . . . . . . . . . . . . . . . 450
Saving Test Stimulus for Later Replay . . . . . . . . . . . . . . . . . . . . . . . . . 451
Moving Tests to Another Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Debugging a Single Falsified Property . . . . . . . . . . . . . . . . . . . . . . . . . 453
Creating VPD Files with VCS (Verilog only) . . . . . . . . . . . . . . . . . . . . . 454
Creating VPD Files with VCS MX (VHDL only) . . . . . . . . . . . . . . . . . . 455

Contents
15 Detecting Simulation/Synthesis Mismatches . . . . . . . . . . . . . . . . . . . . . . . 457

Understanding Mismatch Detection in Magellan . . . . . . . . . . . . . . . . . . . . 458
About the Compare Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Checking for Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Responding to Replay Misses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Debugging Replay Misses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Responding to Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Debugging Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Responding to Unknowns on Goal Signals . . . . . . . . . . . . . . . . . . . . . . . . 463
Diagnosing Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Identifying Code That Leads to Mismatches . . . . . . . . . . . . . . . . . . . . . 465
Using Magellan’s Mismatch Reports . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Generating VCD Files for Formal Traces . . . . . . . . . . . . . . . . . . . . . . . . . 473
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Contents

1
Installing and Setting up
Magellan
This chapter explains how to install Magellan and set up licensing and the environment to run
the tool.
In This Chapter
Installing Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Setting up Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Installing Magellan
Installing Magellan
Magellan is only available from the Synopsys FTP site. Before you download
Magellan, contact your Synopsys Applications Consultant for specific
download instructions and license keys.
Using the Synopsys Installer

To install Magellan, first download the Synopsys Installer. For more
information on using this tool, see the Synopsys Installation Guide on the
Synopsys Web site.
System Requirements
Before installing Magellan, be sure you have the following operating system
and tool versions installed on your workstation:
Solaris™ 2.9 or later (32- or 64-bit)
SUSE Linux Enterprise Server 9 (32-bit)
SUSE Linux Enterprise Server 9 (64-bit)—Verilog only
RHEL v4 (32-bit)
RHEL v4 (64-bit AMD Opteron)
For more information, see “Running 64-bit Magellan” on page 142.
VCS 2006.06-SP2-6 and later
or
VCS MX 2006.06-SP2-6 and later (for VHDL and mixed-language designs)
Vera 2005.06-SP1-3 or later (only needed if you are using Vera biasing)
Debussy, Novas 2006.10v2 and later
Synopsys Common Licensing (SCL) v10.9.x and later
Synopsys common licensing software is available on a separate CD. The
SCL documentation set, available on the SCL CD and on the Synopsys
FTP server (ftp://ftp.synopsys.com), includes the following publications:

Installing and Setting up Magellan Installing Magellan
Licensing QuickStart
This booklet provides instructions for obtaining an electronic copy of
your license key file and for installing and configuring SCL on UNIX and
Windows NT.
Licensing Installation and Administration Guide
This guide provides information about installation and configuration, key
concepts, examples of license key files, maintenance, and
troubleshooting.
For larger designs, it is desirable to have the following configuration:

4 GB of RAM
2 processors
Magellan creates multiple processes during formal searches. It runs on

single-processor machines, but you see the best performance on machines
with multiple processors (see “Understanding the Run Process” on page 143).
Downloading the Software

The Magellan distribution includes one common package and multiple
platform-specific packages. Download the common package and the specific
packages you need for the platforms where you run Magellan. You can overlay
multiple platform packages in the same location. There is one set of packages
for Verilog users (releaseName-base) and another set of packages for
VHDL or mixed-language users (releaseName-full).
To download the Magellan software:
1 Start an FTP session to ftp.synopsys.com:

% ftp ftp.synopsys.com
2 Enter anonymous as your login name:

ftp> anonymous
3 Enter your e-mail address as your password.

Your FTP session starts.

Installing Magellan
4 Set the transfer mode to binary:

ftp> binary
5 Change to the pub directory:

ftp> cd pub
6 Change to the full or base release directory. The release directory name is
provided to you by your Synopsys Applications Consultant or CAE. For
example:
Verilog users:
ftp> cd MG_2006.06-SP2-base
VHDL users:
ftp> cd MG_2006.06-SP2-full
7 Use the get command to download the release tar files and
mg_INSTALL_README.txt file. The actual release file names are provided
by your Synopsys Applications Consultant or CAE. What follows is just an
example that shows the naming conventions. For example:
ftp> get mg_vMG_2006.06-SP2-common.tar
ftp> get mg_vMG_2006.06-SP2-suse64.tar
ftp> get mg_vMG_2006.06-SP2-suse32.tar
ftp> get mg_INSTALL_README.txt
8 Log off the FTP server:

ftp> quit
Installing Magellan
Before you can install Magellan, you need to download the software from the
Synopsys FTP site (see ““Downloading the Software” on page 17”).
To install Magellan:
1 Navigate to the directory where you want to install Magellan. Note that
Magellan needs up to 1.7 GB of disk space when installed.

Installing and Setting up Magellan Installing Magellan
2 Untar the release files. For example, enter:

% tar xf mg_vMG_2006.06-SP2-common.tar
% tar xf mg_vMG_2006.06-SP2-suse64.tar
% tar xf mg_vMG_2006.06-SP2-suse32.tar
3 Run the Synopsys Common Installer either in command-line or GUI mode.

% install.now
Answer the questions as prompted.

% install -gui
When you are finished with the installation process, set your MG_HOME
environment variable to this location.

Setting up Magellan
Setting up Magellan
Make sure Synopsys Common Licensing (SCL) is installed (see “System
Requirements” on page 16).
Setting up Licensing
Before continuing, make sure you’ve received license keys from your
Synopsys Applications Consultant. To set up licensing:
1 Locate and open the license key file on your license server.
2 Add the Magellan license key information to the license file.

For example:
INCREMENT Magellan snpslmd 1.0 31-jan-2002 10 \
2CACC0E1A2A475EBE36F ISSUED=01-jan-2002 ck=102 \
SN=TK:60463 START=01-jan-2002
If you received your license key information via e-mail, you can copy the
information directly from the e-mail to the license file.
The INCREMENT line defines the license to use Magellan. For a complete
description of the license file and the INCREMENT line, see the Licensing
Installation and Administration Guide.
3 To read the new license key information, run the lmreread utility (see the
FLEXlm™ End-User Manual).
4 To check for available licenses, use the lmstat utility. For example, to
check for all active licenses, at the UNIX prompt:
% lmstat -a
Note If you add the -waitlic switch to your mgsh invocation, Magellan waits for a
license if none is currently available instead of exiting. For example:
% mgsh -waitlic

Installing and Setting up Magellan Setting up Magellan
Configuring Environment and Path Variables

Set the following environment variables in each shell that runs Magellan.
Note To avoid unexpected failures that are difficult to debug, set your stacksize and
datasize limits in the shell to unlimited. If there are hard limits in place, see
your system administrator.
MG_HOME Indicates the directory where Magellan is installed.
VCS_HOME Indicates the directory where VCS or VCS MX is installed. This is

required for both Verilog and VHDL users.
SYNOPSYS_SIM Indicates the directory where VCS MX is installed. Do not set

this variable. It is being phased out. VHDL users should instead set
VCS_HOME to point to the directory where VCS MX is installed.
VERA_HOME Indicates the directory where Vera is installed. Vera is only

required if you are using Vera biasing.
SYNOPSYS Indicates the directory where Design Compiler is installed. This is

required if you are checking designs that have DesignWare Foundation
Library parts instantiated (see “Using DesignWare Components (Verilog only)”
on page 200).
LD_LIBRARY_PATH If you are testing a VHDL or mixed-language design, set

this variable to $MG_HOME/platform/ctg/lib:$LD_LIBRARY_PATH,
where platform is sparcOS5, suse32, or linux. This setting is for the
simulator. Running a VHDL or mixed-language design in 64-bit mode in the
simulator is currently not supported.
SNPSLMD_LICENSE_FILE The host name of the license server. Set this

environment variable to port@host_name.
PATH Set this environment variable to $MG_HOME/platform/ctg/bin:\

$SYNOPSYS_SIM/bin:$PATH, where platform is sparcOS5, sparc64,
suse32, suse64, linux, or amd64.
Note If you are using Vera biasing, add $VERA_HOME/bin to your path.

Setting up Magellan
VCS and VCS MX require that you include make in your path. For Solaris,
include /usr/ccs/bin in the path. For Linux, include /usr/bin in the path.
MODELTECH The path to Model Technology’s ModelSim® VHDL simulator.

Magellan only uses this environment variable when you use the
test.csh -mti command. For more information, see the ModelSim
documentation.
Caution On Solaris, do not set the optional VCS_CC environment variable for VCS to a
3.x version of gcc. This can cause the simulator to crash. VCS uses gcc 2.95.2
by default.
Setting up VCS MX
VCS MX use the synopsys_sim.setup file to configure its environment. This
file maps VHDL design library names to specific host directories, sets search
paths, and assigns values to simulation control variables. Magellan
dynamically creates the synopsys_sim.setup in your working directory and
maps the logical library names to physical paths in this file. If this file already
exists in your working directory, Magellan overwrites it. You should remove
any synopsys_sim.setup file in your home or working directory because it can
augment settings and cause problems.
If you want to set search paths or assign values to simulation control

variables, add this information to a separate file. Name the file something
other than synopsys_sim.setup. In the Design module of your Magellan
project file, use a define_design -scoSetupFile command to point to
this file. When Magellan builds the project, this information is added to the
synopsys_sim.setup file that it creates. For more information on the
synopsys_sim.setup file, see the VCS MX User Guide located in
$VCS_HOME/doc/UserGuide/vcsmx_ug.pdf.

Installing and Setting up Magellan Testing the Installation
Testing the Installation

After you’ve installed and set up Magellan, run the test script that comes with
the software. The TestInstall.csh script checks that all the required
licenses are available, starts Magellan, builds a simple design, and runs a
short test. If the script completes successfully, your installation is correct. To
verify the Magellan installation, go to the Magellan installation directory and
type TestInstall.csh at the UNIX prompt. If you do not specify either
switch, the script checks a Verilog installation.
% TestInstall.csh [-verilog] [-vhdl]
Checking Licenses
You can check that you have all the licenses required to successfully run
Magellan at any time. Magellan requires its own license and a license for
either VCS or VCS MX. If you are using Vera biasing, you also need a Vera
license. To check licenses:
1 From the UNIX prompt, start MG shell:

% mgsh
2 At the MG shell prompt:

mgsh> check_licenses
Magellan reports on all required licenses for Verilog and VHDL (see
Figure 1).
Figure 1: Check Licenses Output
** Checking required licenses...

>> Checking feature: Magellan
>> Checking feature: Magellan-Sim
>> Checking feature: Magellan-TB
** All Licenses are accessible!
Note If you add the -waitlic switch to your mgsh invocation, Magellan waits for a
license if none is currently available instead of exiting. For example:
% mgsh -waitlic

Testing the Installation
Checking Your Environment and Version of Magellan

To check your environment and version of Magellan:
% mgsh -ID
The -ID switch produces a report that shows the path to the mgsh executable
you are pointing to, along with the build date and version number of Magellan.
The report also shows information about the host machine and current
settings for environment variables required to run Magellan (see Figure 2).
Figure 2: Magellan Environment and Version Report
Magellan Shell
---------------
/remote/release/nightly.Wed/sparcOS5/ctg/bin/mgsh
Magellan Version -> MG_2006.06-Alpha1

Magellan Build Date -> May 24, 2006
Machine Name -> casca
Machine OS -> SunOS 5.8
Machine Type -> sparcOS5
FLEXlm host ID -> 83090375
Environment:
- $SNPSLMD_LICENSE_FILE -> 26585@raz:26585@daman
- $LM_LICENSE_FILE -> **NOT SET**
- $MG_HOME -> /remote/release/nightly.Wed
- $VCS_HOME -> /u/ctg/tools/vcs_latest
- $SYNOPSYS -> **NOT SET**
- $DEBUSSY_HOME -> /u/ctg/tools/Debussy_latest
- $LD_LIBRARY_PATH(ctg) ->
/remote/release/nightly.Wed/sparcOS5/ctg/lib
If you need to renew your license, please email this

information to yourAccount Manager. To obtain contact
information for your Account Manager please email
pass@synopsys.com
Note For LD_LIBRARY_PATH, the report shows only the library path that is
required to run Magellan.

2
Magellan Introduction
This chapter provides a brief introduction to Magellan.
In This Chapter
What is Magellan? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Why use Properties/Assertions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Why use Coverage Goals and High-Coverage Stimulus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
When to use Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Learning to use Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

What is Magellan?
What is Magellan?
Magellan is a high-capacity functional verification tool that uses static formal
mathematical techniques and dynamic random simulation to test properties or
assertions that are important to the correct operation of your design. Magellan
can also generate high-coverage stimulus for interesting areas of your design
and tell you what states are reachable and unreachable in these targeted
areas given legal input stimulus. This introduction to the tool covers the
following topics:
Why use Properties/Assertions?
Why use Coverage Goals and High-Coverage Stimulus?
When to use Magellan
Learning to use Magellan
Why use Properties/Assertions?

A property or assertion is an executable piece of code based on a fragment
from the design specification. For example, “The FIFO will never overflow” or
“The bus will be granted within 30 clock cycles of a request.” You can use
Magellan to test properties like these written in synthesizable SVA, PSL, OVA,
or RTL code. Magellan can provide you with formal proofs that your properties
are true in all cases or generate a stimulus trace that shows you a property
failure right in the debugger window. In either case, you get valuable
information to aid your design verification efforts.
Note A formal proof indicates that for any stimulus sequence of arbitrary length, the
property is always true. A proof is valuable because there is no need to verify
the property in simulation, and you don’t need to worry that you didn’t provide
the exact stimulus needed to expose a bug.

Magellan Introduction Why use Coverage Goals and High-Coverage Stimulus?
Why use Coverage Goals and High-Coverage Stimulus?

Traditional RTL source code coverage measures which lines of HDL source
code are executed when the design is exercised by a particular stimulus
stream. However, stimulus that generates 100 percent code coverage may
only cover a small fraction of possible design behaviors.
To supplement RTL source code coverage, you can use Magellan’s state
coverage tests to try to exercise all possible behaviors of a small, potentially
problematic area of your design. You define the signals of interest in a
coverage goal. Magellan generates the high-coverage stimulus that can flush
out corner-case bugs. Of the total state space for your coverage goal,
Magellan tells you which of the states are reachable, unreachable, and
unknown, and generates a stimulus trace to hit all reachable goals. You can
save this stimulus and reuse it later for high-value regression tests.
You can also use SVA or OVA cover directives to test functional coverage with
high-coverage stimulus generated by Magellan.

Magellan is a block-level verification tool that works best as part of a larger
system-level simulation and testbench verification strategy. To use Magellan
effectively, you must already have a synthesizable design block that is alive
and demonstrates basic functional correctness. And it is a good idea to find
and fix coding issues that will cause problems with synthesis using a linting
tool such as Leda before you run Magellan.
The best time to start thinking about applying Magellan to a design verification
project is before you start RTL coding. A little pre-planning maximizes the

benefit of formal and dynamic formal verification and minimizes the

implementation effort. Figure 3 shows Magellan in the design flow.
Figure 3: Magellan in the Design Flow
Specification
Reference Models White Box

RTL Coding Checkers
Black Box Checkers
BFM/Constraint Models
Lint Checking
Initial Verification of Functional
Correctness with Simulator
Magellan
Verify Properties
Test All Behaviors
Random Simulation
System Integration
System-Level Verification

Magellan Introduction Learning to use Magellan

Magellan comes with a set of tutorial exercises and sample design files that
you can use to learn the basics about running the tool. There are tutorials for
both Verilog and VHDL/mixed-language users, each located in the install tree
at $MG_HOME/tutorial. In the exercises directories, you will find five sample
Magellan project files labeled exercise2.prj through exercise6.prj. To get up
and running quickly with Magellan, see:
“Verilog Quick Start” on page 31
“Mixed-Language Quick Start” on page 83
Note You don't need to be familiar with Magellan’s project file syntax in order to use
the tool effectively. You can use the Magellan GUI (mgui) to develop, run, and
monitor test results in Magellan. The GUI includes a context-sensitive,
embedded, HTML-based help system to help you build, run, and monitor tests
(see “Invoking the Magellan GUI” on page 108). There is also a GUI exercise
in the Verilog quick start and extensive use of the GUI in the mixed-language
quick start that can familiarize you with how to use mgui to develop and run
tests in Magellan.


3
Verilog Quick Start
This chapter shows you how to build project files, run different kinds of tests, and examine the
results using the Verilog tutorials and example design files that are shipped with the tool.
In This Chapter
Quick Start Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Use Smart Defaults to Test SVA/PSL Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Automatically Extracted Properties (AEPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SVA Combinational Property Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
SVA Sequential Property Failure and Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
SVA Assertion-Style Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
SVA Functional Coverage Goal Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
FSM Coverage and Debug Simulation/Synthesis Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . 64
Magellan GUI Debug SVA Property Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Extract Reset State from System-level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Quick Start Overview

To get started quickly running tests with Magellan, first install the software
(see “Installing Magellan” on page 16) and set up your environment (see
“Configuring Environment and Path Variables” on page 21). The procedures in
this chapter show you how to build project files, run tests, and examine the
results in Magellan in step-by-step fashion, using examples from the Verilog
tutorials shipped with the tool to illustrate the basic principles. For
comprehensive, in-depth information, see the remainder of this manual.
Magellan Project Files are Tcl Scripts

Magellan project files are composed of Tcl commands that the tool reads and
executes. There are order dependencies that you will see as we go (for
example, you have to define things before you can add to them). The
Magellan Tcl commands are organized in modules. At a minimum, a Magellan
project requires valid Project, Design, Environment, and Session modules.
And to do anything interesting, you need to add a Property, AEP, or Coverage
module. You can have multiple Property, Coverage, Environment, and
Session modules in the same project file. The Session module determines the
environment used and the property or coverage goals run in that test. Table 1
shows the recommended order for defining new projects.
Table 1: Magellan Project File Modules
Module Defines For Details on Configuring, see ...
Project Project name and HDL format “Describing the Design” on page 163
Design Design files “Describing the Design” on page 163
Environment Clock and reset signal/state, design “Preparing the Environment” on

constraints page 205
Property SVA, PSL, OVA, or RTL properties “Testing Properties” on page 299
AEP Automatically extracted properties “Testing Automatically Extracted

Properties (AEPs)” on page 367
Coverage State or functional coverage goals “Testing RTL Signal Coverage” on

page 379
Session Environment and Coverage or Property “Running a Session” on page 140

module to run in test

Verilog Quick Start Quick Start Overview
Quick Start Approach

All of the exercises in this Quick Start use the same basic example design for
a data encryption circuit. Additional files are added to the environment for
different exercises as needed. The later exercises build on concepts
introduced in earlier exercises.
Copy the $MG_HOME/tutorial/tutorial_verilog directory to a private location,

change the files in the exercises directory so that they are writable, and work
from there. For example:
% cp -r $MG_HOME/tutorial/tutorial_verilog \
/u/me/MG/tutorial
% cd /u/me/MG/tutorial/exercises
% chmod -R 755 *.prj
Source File Organization

The Quick Start source files are organized as shown in Table 2.
Table 2: Quick Start Source File Organization
Directory Contents
Rtl Verilog RTL source files.
Models Reset file and the assertion files.
Answers Completed project files for reference.
exercises Working directory with project file

templates to use with the labs. Run
Magellan from this directory.

Use Smart Defaults to Test SVA/PSL Goals

For many commonly used tests you can use Magellan’s smart defaults to
simplify your project files. This is also a good way to quickly get started using
the tool. For more information, see “Using Smart Defaults” on page 120. This
exercise shows how to use a minimal Magellan project file to test some
SVA/PSL goals in the example design. Before you get started, see “Quick
Start Approach” on page 33 and set up your work area.
1 Open a new file named easy.prj and enter the same command line you use
with VCS to compile your design. Use the -topModule option to identify
the top-level module in your design (des_chip in this example). In
Magellan you use a set_design_info command to define your VCS
command line:
set_design_info -topModule des_chip -vcs { -f
../Rtl/filelist +incdir+../Rtl -sverilog
../Models/mutex.v +define+ASSERT_ON -y
$VCS_HOME/packages/sva +libext+.v
+incdir+$VCS_HOME/packages/sva }
2 Magellan needs to know the names of your clock and reset ports. Use
add_env_port commands to define them. You use the -clock option to
specify the clock period (100 in this example) and the -reset option to
specify the value the reset signal should have at reset (1 in this example).
When you use smart defaults, Magellan uses the opposite value (0 in this
example) for the Random Generation phase that starts when the design
reset is complete:
add_env_port –name clk_st –clock 100
add_env_port –name rst_st –reset 1
3 Your completed project file should look like Example 1.
Example 1: Smart Defaults Verilog Project File
set_design_info -topModule des_chip -vcs { -f

../Rtl/filelist +incdir+../Rtl -sverilog
../Models/mutex.v +define+ASSERT_ON -y
$VCS_HOME/packages/sva +libext+.v
add_env_port –name clk_st –clock 100
add_env_port –name rst_st –reset 1

Verilog Quick Start Use Smart Defaults to Test SVA/PSL Goals
4 At the UNIX prompt, start the Magellan shell (called MG shell) and read in
your project file in one step:
% mgsh easy.prj
5 At the MG shell prompt, use a run_session command to run the test:

mgsh> run_session
6 While the session is running, Magellan prints a running total in the

transcript that shows its progress toward proving or falsifying the properties
found. When the test run completes, you see the following message:
*** Information: (HVSH-400)
Run (session: _MgSession) finished at time (08:39:48 -
Jan 07). Use 'list_session', 'stat -ses' or 'report'
command to see results.
>>>> HIT RETURN FOR PROMPT <<<<

[Clock: 0:00:37] Alive Session: _MgSession
- _MgChecker SVA: 16 , fls: 0 , prv: 16 , unk: 0
Using this example design, Magellan found 16 SVA/PSL properties in the

design and proved them all. Note the name of the smart defaults Property
module shown in the transcript (_MgChecker).
7 Enter a list_session_results command to see a one-line report for

each property tested. (Add the -long switch to see more detail.) Note the
name of the smart defaults Session module shown in the report
(_MgSession).
mgsh(alive...)> list_session_results
Session Results for: _MgSession
Property Module: _MgChecker

[ 0] Proven -
des_chip.u_des_core.u_des_unit0.dd_d.assert_mutex_inst.
assert_mutex
...
[15] Proven -
des_chip.u_des_core.u_des_unit7.de_d.assert_mutex_inst.
assert_mutex

Automatically Extracted Properties (AEPs)

Build a project file to prove automatically extracted properties in Magellan,
using exercise1 in the Verilog tutorials as a guide. Because Magellan finds the
properties to test automatically with AEPs, they are a good way to familiarize
yourself with the tool. Magellan AEP properties include parallel_case,
full_case, array boundary, conditional X assignment, multiply driven bus,
floating bus, arithmetic overflow, simultaneous set/reset, and line and
condition coverage. For more information on the available AEP tests, see
“Testing Automatically Extracted Properties (AEPs)” on page 367).
Before you get started, see “Quick Start Approach” on page 33 and set up
your work area.
With the example design used in this exercise, Magellan finds some full_case
and parallel_case properties to check.
1 At the UNIX prompt, start the Magellan shell (called MG shell). MG shell is
the primary user interface to the tool:
% mgsh
When MG shell is running, the prompt changes to look like this:
mgsh>
2 Using a text editor, open a new file named exercise1.prj and use a
define_project command to set your project name at the top of the file
(exercise1 in this example). The Project module is the container that
creates the project in Magellan.
### Project module ###
define_project exercise1
Note Magellan project files can have any extension you want, but .prj is a
convention that makes it easier to identify your Magellan projects.
3 Add a Design module that describes your design files, include directories,
and top-level module. In this example, we use a define_design
command to define the design (des) and the -topModule option to point
to the top-level module in the design block (des_chip). Once the design is
defined, use a set_design_info -vcs command to point to the design

Verilog Quick Start Automatically Extracted Properties (AEPs)
files and include directories, using the same command-line options you use
with VCS:
### Design module ###
define_design des -topModule des_chip
set_design_info -vcs { -f ../Rtl/filelist
+incdir+../Rtl }
4 Add an Environment module that defines simulation options, additional port

descriptions such as clock and reset signals, and any other supporting files
for the design under test. We used a define_env command to name the
environment MyEnv. Notice how this same name is used with the different
commands throughout the Environment module.
Use an add_env_port command to define the clock (clk_st) that
drives the design and any constraint models. The clock period here is
100.
Use an add_env_port -reset command to define the value for the
reset signal (rst_st) to take at the beginning of reset (1 in this
example).
Use an add_env_port -constant command to define the value for
the reset signal (rst_st) to take after reset (0 in this example).
Use a set_env_reset -defaultLen command to set the duration of
the default reset task in terms of the number of system clock cycles (10
in this example).
### Environment module ###
define_env MyEnv
add_env_port MyEnv -name clk_st -clock 100
add_env_port MyEnv -name rst_st -reset 1
add_env_port MyEnv -name rst_st -constant 0
set_env_reset MyEnv -defaultLen 10
5 Add a Property module that defines the AEPs that you want to test using a
define_aep command. The -allProps switch tells Magellan to test all
property AEPs that it finds in your design, looking for formal proofs or
falsifications.
### Property module ###
define_aep MyAep0 -allProps

6 Add a Session module that defines the Environment and Property modules
to use for the test.
### Session module ###
define_session s1 -env MyEnv
add_session_info s1 -aep MyAep0
Note how the Session module references the Environment module

(MyEnv) and Property module (MyAep0) created earlier. You can have as
many Property or Environment modules as you want in one project file. The
Session module determines which ones are used for any one test run. You
can also have as many Session modules as you want in one project file.
7 Save the completed project file (exercise1.prj). When you are done, the file
should look like Example 2.
Example 2: AEP Tests Magellan Project File


+incdir+../Rtl }

define_env MyEnv -timeUnits 100ps
add_env_port MyEnv -name clk_st -clock 100
add_env_port MyEnv -name rst_st -reset 1
add_env_port MyEnv -name rst_st -constant 0
set_env_reset MyEnv -defaultLen 10

define_aep MyAep0 -allProps

define_session s1 -env MyEnv
add_session_info s1 -aep MyAep0
8 At the MG shell prompt, use a read_project command to read your

project file into the tool:
mgsh> read_project exercise1.prj

Verilog Quick Start Automatically Extracted Properties (AEPs)
9 Still at the MG shell prompt, use a run_session command to run the test
by specifying the session that we set up in the project file (s1):
mgsh> run_session s1
10 Magellan builds your design and generates messages telling you about the
various build steps. In this example, you see some warning messages in
the transcript. Don’t worry about them for now. Next, you see a report in the
transcript telling you how many AEPs Magellan found in the example
design:
AEP Summary:
----------------------------------------------
AEP Module: MyAep0, found (104) properties.
----------------------------------------------

transcript that shows its progress toward proving or falsifying the AEP
properties found. When the test run completes, you see the following
message:
Run (session: s1) finished at time (16:50:41).
Use 'stat -ses' or 'report' command to see results.
12 When you press the Enter key, Magellan prints a brief summary of the test
results for the AEPs found in the design, and returns you to the following
prompt, to tell you that the Session is still alive:
[Clock: 0:06:50] Alive Session: s1
- MyAep0 {AEP # 104}

=> proven : 96
=> falsified : 8
=> unknown : 0
mgsh(alive...)>

13 You can report the results for the AEP properties at any time later in the
session using a list_session_results -long command:
mgsh(alive...)> list_session_results -long
Magellan generates a report on the screen showing you the types of
properties found in separate categories (for example, parallel_case,
full_case) and the status of each property (proven, falsified, or unknown).
For falsified properties, you can use the File and Line numbers to go
back to the source code and correct the errors. Magellan reports the
SimTime in the detailed reports only for falsified properties. You can use
this information to locate a property failure in the waveform viewer. Here is
a sample of the report output that shows results for the first few AEP
properties Magellan found and tested in the session:
AEP Module: MyAep0
> ID: [0] Proven

- Elapsed Time : 0:00:28
- Type : Full Case Check
- Signal : inst172.mgaep_fullcase_I172_L86_ID1
- Inst : des_chip.u_des_unit0.de_a
- File : ../Rtl/des_a.v
- Line : 86
> ID: [1] Proven

- Update : 09:32:19 - Sep 11
- Inst : des_chip.u_des_unit0.de_b
- File : ../Rtl/des_b.v
- Line : 81
...

Verilog Quick Start SVA Combinational Property Proof
SVA Combinational Property Proof

Build a project file to prove a SystemVerilog Assertion (SVA) combinational
property in Magellan, using exercise2 in the Verilog tutorials as a guide. In this
test, we attempt to formally prove that the i_xfer and o_xfer signals in the
des_d module from the example design are never asserted at the same time
(they are mutually exclusive).
your work area.
1 At the UNIX prompt, start the Magellan shell (called MG shell):

% mgsh
mgsh>
2 Copy or create a new file named exercise2.prj, and use a

(exercise2 in this example).
and top-level module.
+incdir+../Rtl -sverilog ../Models/mutex.v
+define+ASSERT_ON -y $VCS_HOME/packages/sva +libext+.v
The set_design_info -vcs command accepts the same

command-line options as VCS.
The -sverilog switch makes VCS accept SystemVerilog constructs.
The -y switch in this example includes assertions from the SVA
standard assertion library that are shipped in the $VCS_HOME tree.
The ASSERT_ON compiler directive turns on assertions in the SVA
standard assertion library.

The ../Models/mutex.v SystemVerilog design file contains the bind

that hooks up the assert_mutex assertion (from the SVA standard
assertion library) to the des_d module, which is instantiated 16 times in
the example design.

for the design under test. Here, we added a define_env -timeUnits
command to set the time units to 100ps. This is the value that Magellan
uses in simulation. We use a set_env_reset -defaultLen command
to set the duration of the default reset task in terms of the number of
system clock cycles (10 in this example). The -sva switch tells Magellan to
look for SVAs in your design and environment.
define_env env -sva -timeUnits 100ps
add_env_port env -name clk_st -clock 100
add_env_port env -name rst_st -reset 1
add_env_port env -name rst_st -constant 0
set_env_reset env -defaultLen 10
5 Add a Property module that defines the property that you want to prove or
falsify. Use a define_property -checker command to name the
property (mutex) and tell the tool that we are using the property as a
checker in this test. (The other option is to use a property as a constraint for
a downstream block after you prove it for an upstream block.) Notice how
the two commands in this module both refer to the mutex property. This is
the general rule in Magellan project files. First, you define something, then
you add information to it.
define_property mutex -checker
add_property_info mutex -scope {*assert_mutex*}
The -scope {*assert_mutex*} tells Magellan to test all instances of

the assert_mutex assertion found in the design hierarchy. Because this
assertion is bound to a design module that is instantiated 16 times in the
design hierarchy, it is tested 16 times.
6 Add a Session module that references the property and environment that
you want to use for this test. Notice that in this example we are referring to
the env environment from the Environment module defined earlier. Use an

add_session_info -property command to define the property to test

in this session (mutex from the Property module defined earlier).
define_session s2 -env env
add_session_info s2 -property mutex
Example 3: SVA Combinational Property Magellan Project File


+define+ASSERT_ON
-y $VCS_HOME/packages/sva +libext+.v


define_property mutex -checker
add_property_info mutex -scope {*assert_mutex*}



10 Magellan builds your design and generates messages telling you about the
various build steps. In this example, you see some bounded proof results
(see “About Bounded Proofs” on page 302), followed by formal proofs for
the 16 instances of the mutex property found in the design hierarchy.
When the test run completes, you see the following message:
When you press the Enter key, Magellan reports the final results for the
mutex property, and returns you to the MG shell prompt. The prompt now
says “alive” to let you know that your MG shell session is still running:
mgsh(alive...)>
11 You can report the results for the mutex property at any time later in the
session using the list_session_results -long command:
Magellan generates the report. There is a separate assertion report for all
16 assertions found in the design hierarchy (O to 15). The following
example shows the first few:
Property Module: mutex
> ID: [0] Proven

- Type : SVA Checker
- Update : 10:30:48 - Aug 22
- Assertion : assert_mutex
- Assertion Loc : /vcs/packages/sva/assert_mutex.v:108
- Scope :
des_chip.u_des_core.u_des_unit0.dd_d.assert_mutex_inst

- Instantiation : ../Models/mutex.v:2
- SV Module : Module
- Parent Loc : /vcs/packages/sva/assert_mutex.v:59
> ID: [1] Proven

- Update : 10:30:49 - Aug 22
- Assertion Loc :/vcs/packages/sva/assert_mutex.v:108
- Scope :
des_chip.u_des_core.u_des_unit0.de_d.assert_mutex_inst
...

SVA Sequential Property Failure and Debug

Build a project file to attempt to prove a SystemVerilog Assertion (SVA)
sequential property in Magellan, using exercise3 in the Verilog tutorials as a
guide. In this test, we attempt to verify the handshaking protocol used in the
pipeline control logic of the example design. The assertions state that if
i_rval_dd and o_rrdy_dd of the des_a module are both true
accumulatively for three clock cycles, then dval_b_dd of the des_b module
must be true within four clock cycles, unless rst_st or clear_dd happened
in the meantime. This time Magellan falsifies the property, so that you can see
how to debug an error.
your work area.
1 At the UNIX prompt, start the Magellan shell (called MG shell):

% mgsh
mgsh>
2 Copy or create a new file named exercise3.prj and use a

+incdir+../Rtl -sverilog ../Models/pipe_ctrl.v }
The -sverilog switch makes VCS accept SystemVerilog constructs.

The ../Models/pipe_ctrl.v SystemVerilog design file contains the
bind that hooks up the assert_pipe_ctrl assertion to the example
design.

Verilog Quick Start SVA Sequential Property Failure and Debug

for the design under test. The -sva switch tells Magellan to look for SVAs
in your design and environment.
5 Add a Property module that defines the property you want to test (prove or
falsify). Use a define_property command to name the property
(pipe_ctrl). The add_property_info -scope command tells
Magellan to test all instances of the assert_pipe_ctrl assertion found
in the design hierarchy.
define_property pipe_ctrl
add_property_info pipe_ctrl -scope {*assert_pipe_ctrl}
Note We did not use the -checker switch with the define_property command
in this example. This switch is not necessary if you are using an assertion as a
checker, because -checker is the default.
6 Add a Session module that references the property and environment that
you want to use for this test. Notice that in this session, we are referring to
the env environment from the Environment module defined earlier and the
pipe_ctrl property from the Property module defined earlier.
add_session_info s3 -prop pipe_ctrl

Example 4: SVA Sequential Property Magellan Project File


+incdir+../Rtl -sverilog ../Models/pipe_ctrl.v }



add_session_info s3 -prop pipe_ctrl

Magellan builds your design and generates messages telling you about the
various build steps.

10 When the test run completes, you see the following message:
When you press the Enter key, Magellan reports that the pipe_ctrl
property was falsified (fls) and non-vacuous (vac: 0), and returns you to
the MG shell prompt.
- pipe_ctrl SVA: 1, fls: 1, prv: 0, unk: 0, (vac: 0)
The prompt now says “alive” to let you know that your MG shell session is
still running:
mgsh(alive...)>
11 You can report the results for the pipe_ctrl property at any time later in
the session using a list_session_results -long command:
Magellan generates the property report:

Session Results for: s3
Property Module: pipe_ctrl

> ID: [0] Falsified
* Vacuity [1] Non-vacuous
- SimTime : 2099
- Update : 15:05:47 - Aug 13
- Random Cycles : 9
- Formal Cycles : 0
- Assertion : assert_pipe_ctrl
- Assertion Loc : ../Models/pipe_ctrl.v:34
- Scope : des_core.u_des_unit0.pipe_ctrl_1
- Instantiation : ../Models/pipe_ctrl.v:42
- Parent Loc : ../Models/pipe_ctrl.v:12

12 Use a write_session_test command to write out the test files:

mgsh(alive...)> write_session_test dirname
where dirname is the path name to a directory where you want to store
the test files.
13 Exit your MG shell session:

mgsh(alive...)> quit
14 When you return to the UNIX prompt, run the test.csh test driver to bring up
the debugger on the trace. The test files are located in
mg_sessionName/test/dirname:
% mg_s3/test/debug_trace/test.csh -dve
15 It takes a while for the debugger to come up. Add the assertion signal
group (assert_pipe_ctrl) to the waveform display and run the
simulation using the run icon (blue arrow facing down). The waveform
display looks similar to Figure 4. The red arrow shows the failure point for
the assert_pipe_ctrl assertion that we defined in the Property module
for this test.

Figure 4: SVA Property Failure Trace in DVE

SVA Assertion-Style Constraint

Build a project file to use a SystemVerilog Assertion (SVA) constraint in
Magellan, using exercise4 in the Verilog tutorials as a guide. This exercise
shows you how to define an assertion-style constraint in Magellan and use a
debugger to examine the correctness of the stimulus. With assertion-style
constraints, the constraints are represented by assertions about the
correctness of the input stimulus. Magellan only generates input signal values
that satisfy the assertions. Note that assertion-style constraints must be
synthesizable to work with Magellan.
In this exercise, the assertion-style constraints work as follows: After a random

interval, assert rval and drive random input data. At the next clock, if rrdy is
not asserted, continue to hold the inputs. If rrdy is asserted, randomly drive a
new data value or de-assert rval and begin a new interval.
your work area.
1 At the UNIX prompt, start the Magellan shell (called MG shell).

% mgsh
mgsh>

+incdir+../Rtl -sverilog ../Models/data_drive_assert.v
../Models/pipe_ctrl.v }
The ../Models/data_drive_assert.v SystemVerilog design file

contains the bind that hooks up the assert_hold_rval_rdata,

Verilog Quick Start SVA Assertion-Style Constraint
assert_start_interval, and assert_interval_rdata_zero

assertion-style constraints to the example design.
The ../Models/pipe_ctrl.v SystemVerilog design file contains the
bind that hooks up the assert_pipe_ctrl checker to the example
design.
Note You cannot put bind statements inside the module that they are binding (no
self-binding). Move the bind statement outside of the module definition.

for the design under test.
Add a set_env_reset command to define a reset task that correctly
initializes your design. This reset task is written in Verilog (-taskFormat).
Bringing your design to a correct, repeatable Reset State is very important
in Magellan because all formal searches start from the Reset State. For
more information on configuring your Reset State, see “Understanding and
Controlling the Reset State” on page 220.
add_env_port env -name output_enable -constant 1
set_env_reset env -taskName reset_and_init \
-taskFile ../Models/reset.v -taskFormat verilog
5 Add a Property module that defines the property you want to prove or
falsify and the assertion-style constraint you want to use to constrain the
input stimulus.
Use a define_property command to name the property
(pipe_ctrl). The add_property_info -scope
{*assert_pipe_ctrl} command tells Magellan to test all instances
of the assert_pipe_ctrl assertion found in the design hierarchy.

Use a define_property command to name the assertion-style

constraint (assume). The add_property_info -scope
{*data_drive_assert*} command tells Magellan to use all
instances of the data_drive_assert constraint found in the design
hierarchy.
define_property assume -constraint

add_property_info assume -scope {*data_drive_assert*}
Note The -constraint switch is required with the define_property command

for the assume property because -checker is the default.
6 Add a Session module that defines the property and environment you want
to use for this test. Notice that in this session, we are referring to two
different properties:
the pipe_ctrl property checker that Magellan attempts to prove or
falsify
the assume property constraint that Magellan uses to constrain the
random input stimulus to the design
add_session_info s4 -property pipe_ctrl
add_session_info s4 -property assume


Example 5: SVA Property Checker and Constraint Magellan Project File




# Define the constraint
define_prop assume -constraint
add_property_info assume -scope {*data_drive_assert*}
# Define the property to test


add_session_info s4 -property pipe_ctrl

10 When the test run completes, you see the following message:
When you press the Enter key, Magellan reports that the pipe_ctrl
property was falsified (fls) and non-vacuous (vac) again, even with the
addition of the constraints:
- pipe_ctrl SVA: 1, fls: 1, prv: 0, unk: 0, (vac: 0)
still running:
mgsh(alive...)>

12 When you return to the UNIX prompt, run the dbgSim.csh simulation script
to bring up a debugger on the trace. The debug script is located in the
mg_sessionName/user directory. To run the simulation script and examine
the correctness of the stimulus, type:
% mg_s4/user/dbgSim.csh -dve

13 It takes a while for the debugger to come up. Run the simulation using the
run icon (blue arrow facing down). The waveform viewer looks similar to
Figure 5.
Figure 5: Input Signals Constrained by Assertion-Style Constraint (SVA)

SVA Functional Coverage Goal Covered

Build a project file to test a SystemVerilog Assertion (SVA) “cover” in
Magellan, using exercise5 in the Verilog tutorials as a guide. Magellan
generates the stimulus to reach the cover (or reports back that it is
unreachable).
Running functional coverage tests can flush out corner-case bugs and create
high-value regression tests for interesting areas of your design (for example,
state machine control registers, status flags, data path signals, and functional
assertions).
This exercise shows you how to define an SVA-based functional coverage

goal in a Magellan project file and run the test to see if the expected behavior
actually happens.
your work area.

% mgsh
mgsh>
2 Copy or create a new file named exercise5.prj and use a

Add a Design module that describes your design files, include directories,
and top-level module. The ../Models/pipe_ctrl.v SystemVerilog
design file contains the bind that hooks up the cover_pipe_ctrl cover
to the example design.

Verilog Quick Start SVA Functional Coverage Goal Covered

for the design under test. Again, we use a set_env_reset command to
define a reset task that correctly initializes the design. This reset task is
written in Verilog (-taskFormat).
4 Add a Property module. Use a define_property command to name the

assertion-style constraint (assume). The add_property_info -scope
{data_drive_assert*} command tells Magellan to use all instances of
the data_drive_assert constraint found in the design hierarchy.
add_property_info assume \
-scope {data_drive_assert.assert*}
5 Add a Coverage module that defines the cover to test

(cover_pipe_ctrl). The add_coverage_info -scope
{*cover_pipe_ctrl*} command tells Magellan to test all instances of
the cover_pipe_ctrl cover found in the design hierarchy.
### Coverage module ###
define_coverage cover_pipe_ctrl
add_coverage_info cover_pipe_ctrl \
-scope {*cover_pipe_ctrl*}
6 Add a Session module that defines the property and environment you want
to use for this test. Notice that in this session, we are referring to a Property
module and a Coverage module. Magellan uses the assume property
constraint to constrain the random input stimulus to the design, and the
cover_pipe_ctrl SVA cover as the coverage goal to test.
add_session_info s5 -coverage cover_pipe_ctrl

Example 6: SVA Functional Coverage Goal Magellan Project File


+incdir+../Rtl ../Models/data_drive_assert.v -sverilog


add_property_info assume \
-scope {data_drive_assert.assert*}

define_coverage cover_pipe_ctrl
add_coverage_info cover_pipe_ctrl \
-scope {*cover_pipe_ctrl*}

add_session_info s5 -coverage cover_pipe_ctrl


by specifying the session that we set up in the project file (s5).
10 When the test run completes, Magellan reports that it reached the
cover_pipe_ctrl SVA cover, and generates the following message:
>>> Running Session: s5
Goal Clock SimTime State

------------------------------------------------------
cover_pipe_ctrl 0:00:15 14499 Cover [ 0]=covered

Run (session: s5) finished at time (11:23:49 - Feb 23,
2006). Use 'stat -ses' or 'report' command to see
results.
11 When you press the Enter key, Magellan reports that the
cover_pipe_ctrl SVA cover was reached (rch) or covered:
- cover_pipe_ctrl Covers: 1, rch: 1, unr: 0, unk: 0
still running:
mgsh(alive...)>
12 Use a list_session_results -long command to generate a full

coverage report:
Magellan generates the report.

Coverage Module: cover_pipe_ctrl
> ID: [0] Covered
- Type : SVA Cover
- SimTime : 14399
- Update : 15:45:04 - Aug 13

- Random Cycles: 11
- Formal Cycles : 0
- Cover : cover_pipe_ctrl
- Cover Loc : ../Models/pipe_ctrl.v:38
- Scope :
des_chip.u_des_core.u_des_unit0.pipe_ctrl_1

mgsh(alive...)> write_session_test dirname
the test files. For example:
mgsh(alive...)> write_session_test cover_pipe_ctrl

mg_sessionName/test/dirname:
% mg_s5/test/cover_pipe_ctrl/test.csh -dve

16 It takes a while for the debugger to comes up. Run the simulation using the
run icon (blue arrow facing down), and review the trace (see Figure 6).
Figure 6: SVA Cover Trace in DVE

FSM Coverage and Debug Simulation/Synthesis Mismatches

Build a project file that uses a Coverage module to test a set of RTL signals in
a finite state machine (FSM). Magellan tests the signals to see if they are
reachable given legal input stimulus to the design. Then use the Magellan
“compare” run mode to find and debug simulation/synthesis mismatches that
could affect your test results. For more information on detecting and fixing
simulation/synthesis mismatches, see “Detecting Simulation/Synthesis
Mismatches” on page 457.
your work area.

% mgsh
mgsh>

set_design_info -vcs { -f ../Rtl/filelist_bug
+incdir+../Rtl }

Verilog Quick Start FSM Coverage and Debug Simulation/Synthesis Mismatches
4 Add an Environment module that defines additional port descriptions such

as clock and reset signals, the reset task, and any other supporting files for
the design under test. Use an add_env_port command to set a constant
value of 1 for the output_enable port during the Random Generation
phase.
define_env env -timeUnits 100ps
5 Add a Coverage module that defines the RTL signals to include in your
coverage goal set. Use a define_coverage command to specify the
coverage goal name (case_coverage). Then use an
add_coverage_info -signals command to define the RTL signals to
include in the coverage goal set. These coverage signals are for a state
machine in the design.
define_coverage case_coverage
add_coverage_info case_coverage -signals {
des_chip.u_des_core.u_des_unit7.dd_decrypt.state[2:0]
des_chip.u_des_core.u_des_unit7.dd_decrypt.ein
des_chip.u_des_core.u_des_unit7.dd_decrypt.i_xfer
}
6 Add a Session module that references the Environment (env) and

Coverage (case_coverage) modules that you want to use for this test.
add_session_info s6 -cov case_coverage

Example 7: FSM Coverage Goal Magellan Project File


set_design_info -vcs { -f ../Rtl/filelist_bug
+incdir+../Rtl }


define_coverage case_coverage
add_coverage_info case_coverage -signals {
des_chip.u_des_core.u_des_unit7.dd_decrypt.ein
des_chip.u_des_core.u_des_unit7.dd_decrypt.i_xfer
}

add_session_info s6 -cov case_coverage

by specifying the session that we set up in the project file (s6).
mgsh> run_session -compareAlways -compareFullDesign s6

Verilog Quick Start FSM Coverage and Debug Simulation/Synthesis Mismatches
The -compareAlways switch tells Magellan to compare every state in

the transitive fanin of the session’s property and coverage goals at every
cycle beginning at time zero.
The -compareFullDesign switch tells Magellan to compare all
registers and outputs in the design, not just those in the transitive fanin
of your session goals.
10 As the run progresses, Magellan reaches a breakpoint and stops so that

you can diagnose and fix simulation/synthesis mismatches that could affect
results for the FSM coverage goal test. The messages you see in the
transcript look like this:
*** Information: (HVSI-403)
Mismatch on Signal:top_des_chip.des_chip.o_dout[31]
(SynVal:0 SimVal:1)

Mismatch on Signal:top_des_chip.des_chip.o_dout[26]
(SynVal:0 SimVal:1)

Additional mismatching signals only in diagnose.out
report file
*** Information: (HVOR-405)

Breaking for user analysis of mismatch data in
directory:/remote/techpub/halr/MG/REGRESSION/quick_start_
fsm_mismatch/mg_s6/user

A diagnostic break at simulation time (26825) has
occurred in the current run. Use 'run' to resume the run
when break diagnoses is complete.
11 When you press the Enter key, the prompt returns and says “paused” to let
you know that your MG shell session has paused so that you can debug
the simulation/synthesis mismatch errors:
mgsh(paused...)>


mgsh(paused...)> write_session_test dirname
the test files. For example:
mgsh(paused...)> write_session_test debug

mgsh(paused...)> quit
14 Open the mg_s6/user/diagnose.out file in a text editor to check the

mismatches in the simulation and formal (synthesized) models, and review
the RTL source code to investigate the problem.
mg_sessionName/test/dirname. Examine the sequentials in the waveform
viewer to see what is causing the mismatches. To run the trace, type:
% mg_s6/test/debug/test.csh -dve

Verilog Quick Start Magellan GUI Debug SVA Property Failure
Magellan GUI Debug SVA Property Failure

Use the Magellan GUI (mgui) to build and run one of the same exercises we
ran earlier in batch mode (exercise 3, entitled SVA Sequential Property Failure
and Debug). You can use the context-sensitive Help tab at the top right of the
Activity View at any time to get help on using mgui. Before you get started, see
“Quick Start Approach” on page 33 and set up your work area.

% mgsh
mgsh>
2 At the MG shell prompt, start the Magellan GUI (see Figure 13 on

page 108):
mgsh> mgui
3 From the main menu, choose Edit > Configure/Setup, and select the DVE
radio button at the bottom of the Configure mgui window. Then click the
Done button to dismiss the window.
4 From the main menu, choose File > New Project. The Configure tab at the
top left opens automatically at the correct place to begin defining a new
project: the Project tab.
5 Project Tab. The Project Module Name field is prefilled with a sample
name (myProject), which we can leave as is.
In the File Name field just to the right, type in exercise7.prj and press
the Enter key.
In the System panel immediately below, the Default HDL Format is set
to Verilog. This is the default and that’s what we want for this exercise,
so leave it as is.
6 Design Tab. Choose the Configure > Design tab:

In the Design Module Name field, enter des.
In the Top HDL Module field, enter des_chip.

In the Design Files tab, the radio button for View Cmd Line is already
selected. Leave that as is, and enter the following VCS command line in
the adjacent window:
-f ../Rtl/filelist +incdir+../Rtl
-sverilog ../Models/pipe_ctrl.v
Then click the Set Command Line button at the lower right of the
window. Magellan updates the MG shell.
7 Environment Tab. Choose the Configure > Environment tab:

With the Environment > Setup tab open, click the Define New button at
the top of the tab, and enter env in the Define Env dialog box that pops
up. Then click OK.
Select the check box labeled Search for SystemVerilog (SVA)
Assertions.
The time units are already set at the defaults of 100 ps. Leave that as is.
In the Environment > Ports tab, in the Add/Set name field at the bottom
of the window, enter clk_st and make sure clock is selected in the
pull-down menu to the right. Leave the Period field at the default value of
100, and click the Add/Set button. Magellan adds the clock definition to
the list window above and updates the MG shell.
Still in the Environment > Ports tab, in the Add/Set name field, enter
rst_st and select reset from the pull-down menu to the right. Leave the
Value field at 1. This represents the value that the reset signal has
during reset. Click the Add/Set button. Magellan adds the reset signal
definition to the list window above and updates the MG shell.
Still in the Environment > Ports tab, in the Add/Set name field, enter
rst_st and select constant from the pull-down menu to the right. Leave
the Value field at 0. This represents the value that the reset signal
maintains during the Random Generation phase. Click the Add/Set
button. Magellan adds the reset signal constant to the list window above
and updates the MG shell.
8 Property Tab. Choose the Configure > Property tab:

Click the Define New button at the top of the window. In the Define
Property Module dialog box that pops up, enter pipe_ctrl and click the
OK button. Magellan adds the property name to the display field on the

Verilog Quick Start Magellan GUI Debug SVA Property Failure
right. In the Property Source panel, the SVA/OVA Scope radio button is
already selected. And in the Property Type panel, the Checker radio
button is already selected. Leave these settings as is.
In the Scope Assertion List panel at the bottom of the tab, leave the
“Include” List radio button selected. Then, in the Add/Set scope field,
enter *assert_pipe_ctrl, and click the Add/Set button to the right.
Magellan adds the scope for the assertion to the display above and
updates the MG shell.
9 Session Tab. Choose the Configure > Session tab:

Click the Define New button at the top of the window. In the Define
Session dialog box that pops up, enter s3 and click the OK button.
Magellan fills in the session selection field to the right and updates the
MG shell with the session name.
In the Module References tab, select env from the pull-down menu for
Environment Reference. This references the Environment module that
we defined earlier for this test. Magellan updates the MG shell.
In the Add field directly below, select Property Module from the
pull-down menu. Magellan automatically fills the Name field to the right
with the name of the Property module we defined earlier (pipe_ctrl).
Click the add button. Magellan updates the MG shell with the name of
the Property to test in this session.
10 From the GUI main menu, choose File > Save. Magellan saves the
completed exercise7.prj file in the current working directory. You can later
rerun your tests either from mgui or in batch mode using this project file.
11 Run Tab. Choose the Run tab.

In the Session pull-down menu at the top of the tab, select the s3
Session module that we defined earlier.
The radio button for the Run Session (Auto Build) option is already
selected. Leave that as is.
In the Run Options table, leave the Run Normal radio button selected
and click the Run/Build button.

12 Monitor Tab.
After you click the Run/Build button, Magellan displays the Monitor tab.
When the run server starts, the display changes to show you the goals
defined for the test. In this exercise, the goal is the SVA pipe_ctrl
property, which you see displayed in the Property Goals tab. Magellan
falsifies the property (finds a bug) and changes the display to show you
the status (Falsified).
13 Report Tab.
Double-click the Falsified string in the Monitor tab display. Magellan
displays the Report tab, where you can see more information about the
SVA pipe_ctrl property that Magellan falsified.
14 Debug Trace in DVE.

From the Run tab, click the Testbench button. From the Debug Testbench
Setup dialog box that pops up, make sure DVE is selected and click OK.
Run the simulation using the run icon and review the trace (see Figure 7).
Figure 7: SVA Property Failure Trace in DVE
Note the failure for the assert_pipe_ctrl assertion at simulation time

20,000.

Verilog Quick Start Extract Reset State from System-level Simulation
Extract Reset State from System-level Simulation

Learn how to extract a Magellan Reset State from your system-level
simulation. In this exercise, we’ll test coverage on some RTL signals in the
design. We’ll use our initial project file to build the design and generate
temporary files that are needed to extract the Reset State using the PLI.
The Reset State is the value of all sequentials in the design block you are
testing. All formal searches in Magellan begin from the Reset State.
Simulation sequences may return to the Reset State multiple times to try
different random stimulus or to replay error traces calculated by Magellan’s
formal engines. For more information, see “Understanding and Controlling the
Reset State” on page 220.
your work area.
1 Copy or create a new file named exercise8a.prj, and use a

(exercise8a in this example).
define_project exercise8a
+incdir+../Rtl +define+MEM_RESET }
The MEM_RESET compiler directive turns on some memory elements in the

sample design.

for the design under test:

4 Add a Coverage module that defines some RTL signals in the design to
test.
define_coverage rtl_cover
add_coverage_info rtl_cover -signals {
}
5 Add a Session module that references the Coverage and Environment

modules to use for this test:
define_session s8a -env env
add_session_info s8a -coverage rtl_cover
6 Save the completed project file (exercise8a.prj). When you are done, the
project file for the initial build should look like Example 8.
Example 8: Initial Build Magellan Project File

define_project exercise8a

set_design_info -vcs { -f ../Rtl/filelis +incdir+../Rtl
+define+MEM_RESET }


}

define_session s8a -env env
add_session_info s8a -coverage rtl_cover

7 At the UNIX prompt, start MG shell and read in the project file in one step:
% mgsh exercise8a.prj
8 At the MG shell prompt, use a build_session command to build your

design:
mgsh> build_session
When the build completes, you see a message similar to the following on
the screen:
Build (session: s8a) finished at time (14:26:00 - Jan
28).
Use 'stat -build' command to see results.
9 Exit MG shell to return to the UNIX prompt:

mgsh> quit

10 Add the Magellan Reset State capture PLI script

($MG_HOME/auxx/ctg/scripts/mgCaptureReset.pl) to your
system-level simulation script (see Example 9). Note the use of an example
testbench (testbench_des_chip.v)for this exercise.
Example 9: VCS Simulator Build Script with Reset State Capture Script Call
#$/bin/csh
setenv prjDir ./
setenv srcDir ../Rtl
setenv runDir ./mg_s8a
setenv tbdir ../Models
setenv pliDir `pwd`
unalias rm
/usr/local/bin/rm -rf getDsnStateForMg.v simv csrc
if ($#argv < 1) then

echo "Usage: run_vcs_mg_reset.csh
platform(linux/sparcOS5/suse32)"
exit
endif
${VCS_HOME}/bin/vcs -l MY.LOG -R -notice -Vt \

-Mdir=$pliDir/csrc \
-assert enable_diag \
-f $srcDir/filelist +incdir+$srcDir +define+MEM_RESET \
$tbdir/testbench_des_chip.v \
+libext+.v +incdir+$VCS_HOME/packages/sva \
+notimingcheck \
+transport_path_delays +pulse_e/10 +pulse_r/10 \
-assert maxfail=1 -override_timescale=1ns/1ns \
+plusarg_ignore +captureState +vpi \
`$MG_HOME/auxx/ctg/scripts/mgCaptureReset.pl $1 100000
testbench_des_chip.u_des_chip $runDir ./myRst`
The sample VCS build and run script shown in Example 9 is named
run_vcs_mg_reset.csh. You can find this script in the
$MG_HOME/tutorial/tutorial_verilog/exercises directory. If you are building
a 64-bit simulation executable, use the run_vcs_mg_reset_64.csh
script instead. Note that the -full64 VCS switch is required on 64-bit
platforms.
At the end of Example 9, note the call to the Reset State extraction PLI
script (mgCaptureReset.pl). You also need the +captureState

+vpi simulator build options highlighted in Example 9. The script takes

four required arguments and a fifth argument that is optional:
mgCaptureReset.pl platform rst_time dut_inst
session_dir [rst_dir]
where:
platform — is sparcOS5, linux, suse32,amd64, sparc64, or

suse64.
rst_time — is the simulation time where you want to snapshot the

state of sequentials in your design.
dut_inst — is the hierarchical path to the instance name used as a

top-level module in Magellan.
session_dir — is the path name to the Magellan session directory

created during the initial build (mg_s8a in this example).
rst_dir — Optionally, specify the directory name where you want the
generated Reset State files stored. Specifying a directory name here is
recommended because the script generates lots of files in this directory.
The default is the current working directory.
11 The VCS build script takes your platform name as its only required
argument. For 32-bit platforms, the legal values are linux, sparcOS5,
and suse32. For 64-bit platforms, the legal values are amd64, sparc64,
and suse64. For example:
% run_vcs_mg_reset.csh linux
-or-
% run_vcs_mg_reset_64.csh amd64

When the VCS build script completes, you see messages similar to the
following on the screen:
VCS Build Date = Dec 11 2007 21:30:01
Start run at Jan 28 14:26 2008
Simulation starting
getRstStateForMg Using CaptureTime = 100000
Reset deactivated
getRstStateForMg.mgGetDsnStateTask Capturing Reset

State at time 100000
getRstStateForMg.mgGetDsnStateTask Capturing Reset

State in directory ./myRst
Note: Creating reset inject dir for

testbench_des_chip.u_des_chip using
map:./mg_s8a/.temp/env/design.map.
Output Directory:./myRst
12 In the output directory (myRst) the PLI script creates a Reset State file
named ResetState.dat. You can now add the custom Reset State specified
in the ResetState.dat file created in the previous step:
set_env_reset env -file ./myRst/ResetState.dat

When you are done revising your Magellan project file, rename the file to
exercise8b.prj. The revised file should look like Example 10.
Example 10: Magellan Project File with Reset State File Specified

define_project exercise8b

+incdir+../Rtl +define+MEM_RESET }

set_env_reset env -file ./myRst/ResetState.dat

}

define_session s8b -env env
add_session_info s8b -coverage rtl_cover
13 At the UNIX prompt, start MG shell and read in the revised project file in
one step:
% mgsh exercise8b.prj

14 At the MG shell prompt, use a run_session command to run your

session and test the rtl_cover coverage goal:
mgsh> run_session
When the session run completes, you see messages similar to the
following on the screen:
Run (session: s8b) finished at time (14:31:43 - Jan 28).
Use 'list_session', 'stat -ses' or 'report' command to
see results.
When you press the Enter key, Magellan reports summary results for the
rtl_cover coverage goal and returns you to the MG shell prompt.
[Clock: 0:01:06] Alive Session: s8b
- rtl_cover FSM Cov: 8, rch: 5, unr: 3, unk: 0
still running:
mgsh(alive...)>
15 You can report detailed results for the rtl_cover goal at any time later in
the session using a list_session_results -long command:
Magellan generates the report:

Session Results for: s8b
Coverage Module: rtl_cover
Signals:
- (00)
/des_chip/u_des_core/u_des_unit7/dd_decrypt/state[2]
- (01)
- (02)
Expanded Nets for Coverage Module:
- (00)
des_chip.u_des_core.u_des_unit7.dd_decrypt.state[2]
- (01)

- (02)
Reached Report (Count: 5)
Bit: 000
012
----------
(RCH 0-- )
(RCH 100 )
Unreachable Report (Count: 3)
Bit: 000
012
----------
(UNR 101 )
(UNR 11- )
Unknown Report (Count: 0)


4
Mixed-Language Quick
Start
This chapter shows you how to build project files, run different kinds of tests, examine the
results, verify constraints, and debug assertion failures using the mixed-language tutorials and
some example design files that are shipped with the tool.
In This Chapter
Quick Start Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Use Smart Defaults to Test SVA/PSL Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Use Assertions from SVA Checker Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Add Custom SVA/PSL Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Add a Reset Task and an SVA Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Run SVA/PSL Cover Functional Coverage Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Run State Machine Coverage Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104


To get started quickly running tests with Magellan, first install the software
(see “Installing Magellan” on page 16) and set up your environment (see
“Configuring Environment and Path Variables” on page 21). The procedures in
this chapter show you how to build project files, run tests, and examine the
results in Magellan in step-by-step fashion, using examples from the
mixed-language tutorials shipped with the tool to illustrate the basic principles.
For comprehensive, in-depth information, see the remainder of this manual.
Magellan Project Files are Tcl Scripts

Magellan project files are composed of Tcl commands that the tool reads and
executes. There are order dependencies that you will see as we go (for
example, you have to define things before you can add to them). The
Magellan Tcl commands are organized in modules. At a minimum, a Magellan
project requires valid Project, Design, Environment, and Session modules.
And to do anything interesting, you need to add a Property, AEP, or Coverage
module. You can have multiple Property, Coverage, Environment, and
Session modules in the same project file. The Session module determines the
environment used and the property or coverage goals run in that test. Table 3
shows the recommended order for defining new projects.
Table 3: Magellan Project File Modules
Module Defines For Details on Configuring, see ...
Project Project name and HDL format “Describing the Design” on page 163
Design Design files “Describing the Design” on page 163
Environment Clock, reset signals/state, design “Preparing the Environment” on

constraints page 205
Property SVA, PSL, OVA, or RTL properties “Testing Properties” on page 299
AEP Automatically extracted properties “Testing Automatically Extracted

Properties (AEPs)” on page 367
Coverage State or functional coverage goals “Testing RTL Signal Coverage” on

page 379
Session Environment and Coverage or Property “Running a Session” on page 140

module to run in test

Mixed-Language Quick Start Quick Start Overview
Quick Start Approach

All of the exercises in this Quick Start use the same basic example JPEG
design written in VHDL with a top-level Verilog wrapper. Additional files are
added to the environment for different exercises as needed. The later
exercises build on concepts introduced in earlier exercises.
Copy the entire $MG_HOME/tutorial/tutorial_mx directory to a private location,

change the files in the exercises directory so that they are writable, and work
from there. For example:
% cp -r $MG_HOME/tutorial/tutorial_mx \
/u/me/MG/mixed_tutorial
% cd /u/me/MG/mixed_tutorial/exercises
% chmod -R 755 *.prj
Source File Organization

The Quick Start source files are organized as shown in Table 4.
Table 4: Quick Start Source File Organization
Directory Contents
rtl VHDL and Verilog RTL source files.
env Reset file and the assertion files.
answers Completed project files for reference.
exercises Working directory with project file

templates to use with the labs. Run
Magellan from this directory.


For many commonly used tests you can use Magellan’s smart defaults to
simplify your project files. This is also a good way to quickly get started using
the tool. For more information, see “Using Smart Defaults” on page 120. This
exercise shows how to use a minimal Magellan project file to test some
SVA/PSL goals in the Verilog-top, mixed-language example design. Before
you get started, see “Quick Start Approach” on page 85 and set up your work
area.
1 Open a new file named easy.prj and enter the same command lines you
use with VCS MX to compile your design. In Magellan you use
add_design_info -vhdlan and -vlogan commands to define your
VCS MX command lines. Use a set_design_info -topModule
command to identify the top-level module in the design (see Example 11).
2 Magellan needs to know the names of your clock and reset ports. Use
add_env_port commands to define them. You use the -clock option to
specify the clock period (100 in this example) and the -reset option to
specify the value the reset signal should have at reset (1 in this example).
When you use smart defaults, Magellan uses the opposite value (0 in this
example) for the Random Generation phase that starts when the design
reset is complete:
add_env_port –name clk –clock 100
add_env_port –name rst –reset 1

Mixed-Language Quick Start Use Smart Defaults to Test SVA/PSL Goals
3 Your completed project file should look like Example 11.
Example 11: Smart Defaults Mixed-language Project File
add_design_info -vlogan { -psl -sverilog

../rtl/jpeg_top.v ../env/sva_checkers.sva
+define+SVA_CHECKER_NO_MESSAGE +define+ASSERT_ON
+incdir+$VCS_HOME/packages/sva}
add_design_info -vhdlan { -sva -psl -w DESW02

../rtl/DW02_components.vhd ../rtl/DW02_mult.vhd
../rtl/DW02_mult_sim.vhd }
add_design_info -vhdlan { -sva -psl -w WORK

../rtl/jpeg_types.vhd ../rtl/sreg_e.vhd
../rtl/sreg_a.vhd ../rtl/counter_e.vhd
../rtl/counter_a.vhd ../rtl/dct_input_e.vhd
../rtl/dct_sum_1_a.vhd ../rtl/dct_sum_2_e.vhd
../rtl/dct_sum_2_a.vhd ../rtl/dct_mult_1_e.vhd
../rtl/dct_mult_1_a.vhd ../rtl/dct_mult_2_e.vhd
../rtl/dct_mult_2_a.vhd ../rtl/dct_trans_e.vhd
../rtl/dct_trans_a.vhd ../rtl/dct_e.vhd
../rtl/dct_a.vhd ../rtl/quantizer_e.vhd
../rtl/quantizer_a.vhd ../rtl/runlength_e.vhd
../rtl/runlength_a.vhd ../rtl/dc_encode_e.vhd
../rtl/dc_encode_a.vhd ../rtl/ac_encode_num_e.vhd
../rtl/ac_encode_num_a.vhd ../rtl/ac_encode_end_e.vhd
../rtl/ac_encode_end_a.vhd ../rtl/ac_encode_e.vhd
../rtl/ac_encode_a.vhd ../rtl/compress_e.vhd
../rtl/compress_a.vhd ../rtl/huffman_e.vhd
../rtl/huffman_a.vhd ../rtl/jpeg_e.vhd
../rtl/jpeg_a_sc.vhd }
set_design_info -topModule jpeg_top -vcs { -sva_bind

../env/sva_lib_bind.v }
add_env_port -name clk -clock 100

add_env_port -name reset -reset 0
4 At the UNIX prompt, start the Magellan shell (called MG shell) and read in
your completed project file in one step:
% mgsh easy.prj

5 At the MG shell prompt, use a run_session command to run the test:

mgsh> run_session

transcript that shows its progress toward proving or falsifying the properties
found. When the test run completes, you see the following message:
Run (session: _MgSession) finished at time (10:15:25 -
Jan 07). Use 'list_session', 'stat -ses' or 'report'
command to see results.
[Clock: 0:01:00] Alive Session: MgSession
- _MgChecker SVA: 14, fls: 3, prv: 11, unk: 0, (vac: 0)
Magellan found 14 SVA/PSL properties in the example design. The tool

proved 11 of them and falsified 3. Note the name of the smart defaults
Property module shown in the transcript (_MgChecker).
7 Enter a list_session_results command to see a one-line report for

each property tested. (Add the -long switch to see more detail.) Note the
name of the smart defaults Session module shown in the report
(_MgSession).
Session Results for: _MgSession

Property Module: _MgChecker
[ 0] Proven (Non-vacuous) -
jpeg_top.jpeg0.U_DCT.U_DCT_INPUT.SVA_DCT_READY_FOLLOW_P
ASS
...
[26] Proven (Non-vacuous) -

jpeg_top.jpeg0.U_HUFFMAN.U_RUNLENGTH.PSL_COUNTER_INCREA
SE

Mixed-Language Quick Start Use Assertions from SVA Checker Library
Use Assertions from SVA Checker Library

Use the Magellan GUI (mgui) to create a mixed-language project file that uses
the assert_implication checker from the SVA standard assertion library that
ships with VCS.
your work area.
1 Review how the assert_implication checker is used in the example design.

There are some instantiations and binds in both the Verilog and VHDL
portions of the design.
Type File Line Assertion Name
SVA instantiated Verilog ../rtl/jpeg_top.v 24 LIB_data_check
SVA instantiated VHDL ../rtl/dct_input_a.vhd 44 & 200 VHDL_LIB_DCT_READY_FOLLOW_PASS
SVA bind Verilog ../env/sva_lib_bind.v 2 LIB_bind_data_check
SVA bind VHDL ../env/sva_lib_bind.v 5 LIB_BIND_DCT_READY_FOLLOW_PASS
2 Start the Magellan GUI:

% mgui
3 From the main menu, select File > New Project and change the File Name
to exercise1.prj. Press Enter to update MG shell. The Top HDL Format field
defaults to Verilog, which is what we are using for this exercise.
4 In the Add/Set Filter field, type ELAB-351 and click the Add/Set button or
press Enter. Magellan adds this message label to the ones that it filters out
from your transcript and log files during the build. Repeat for ELAB-402 and
ELAB-349. You can use this mechanism to filter out any warning or error
messages that you don’t want recorded.
5 Now, create a Design module for the project which specifies the design
files to check. Click the Design tab and change the Top HDL Module name
to jpeg_top. Press Enter to update MG shell. Note that jpeg_top is the
name of the top-level Verilog module that instantiates the JPEG design,
written in VHDL (see Figure 8).

Figure 8: mgui Design Tab Display
6 In the Design Setup subtab, the Top Module Setup pull-down shows
Verilog (VCS) because we selected Verilog as the Top HDL Format on the
Project tab. Leave the View Command Line radio button selected and enter
the following VCS command in the large window:
-sva_bind ../env/sva_lib_bind.v
Then click the button to update MG shell. The

sva_lib_bind.v file contains two binds of the assert_implication checker
from the SVA checker library, one to the Verilog portion of the design and
one to the VHDL portion of the design. Note that the -sva_bind switch is
required to compile external bind files.

7 Click the View Entry Table radio button and leave the Analyze Compiler
pull-down selection showing vlogan. In the text entry field just to the right
enter:
-psl -sverilog ../rtl/jpeg_top.v \
../env/sva_checkers.sva +define+ASSERT_ON -y \
+define+SVA_CHECKER_NO_MESSAGE \
$VCS_HOME/packages/sva +libext+.v \
+incdir+$VCS_HOME/packages/sva
Click the Add/Set button to update MG shell. Magellan displays your vlogan
command in the window on top. Note that we are using the -psl switch
here because there are some PSL assertions in this design environment,
so this is required for compilation. We’ll use them in a later exercise. The
ASSERT_ON compiler directive is needed to turn on assertions in the SVA
standard assertion library. The SVA_CHECKER_NO_MESSAGE compiler
directive filters out checker error messages coming from the SVA standard
assertion library.
8 To specify the VHDL design files, you can set the Analyze Compiler
pull-down menu to vhdlan and enter the commands just as you did for
vlogan in the previous step. But here, we’ll source a Tcl file that contains
the vhdlan commands. At the mgsh> prompt at the bottom of the GUI
window, enter:
mgsh> source design_source.tcl
When you press Enter, Magellan loads the commands and updates the
display in the window above. Sourcing a Tcl file like this is a handy way to
enter long compilation commands that you are using in more than one
Magellan project, as we are here in these Quick Start exercises.
9 Now let’s create the environment around the design. Select the
Environment tab and click the Rename button. Enter env in the small
window that pops up and click OK.
10 In the Setup tab (already selected), select the check box for Search for
SystemVerilog assertions to activate the search.
11 Select the Reset Task tab and enter 20 in the Number of Cycles field. This
specifies the length for the reset sequence to run. Then press Enter.
Magellan updates the MG shell.

12 Select the Ports tab:

a Type clk in the Add/Set Name field. Leave the pull-down menu to the
right set to clock and the Period set to 100. Click the Add/Set button to
update MG shell and the display above.
b Type reset in the Add/Set Name field and select reset from the
pull-down menu. Enter 0 in the value field and click the Add/Set button.
This specifies that Magellan set the reset signal to 0 during the Reset
phase. Click the Add/Set button.
c Leave reset in the Add/Set Name field and select constant from the
pull-down menu. Enter 1 in the Value field and click the Add/Set button.
This specifies that Magellan hold the reset signal at a constant 1 during
the generation of test stimulus.
13 Next, we’ll define the properties for Magellan to test. Select the Property
tab and then click the Define New button. Enter lib_props in the small
window that pops up and click OK. Magellan updates the display. Notice
that the radio buttons for SVA/OVA scope and the Checker property type
are already selected. These are the defaults and that’s what we want to
use for this exercise.
14 In the Scope Assertion List panel, the Include List radio button is already
selected. Leave that as is and type *LIB_* in the Add/Set Scope text entry
field. You can use wildcard name matching like this to specify which
assertions in your environment you want to test. Click Add/Set to update
MG shell and the display.
15 Now, we need to define a Session module. This is where your design,

property, and environment come together to specify a test in Magellan.
Select the Session tab and click the Rename button. Enter s_lib_props
in the small window that pops up and click OK.
16 Click in the Environment Reference field and select env. This is the name
of the environment we set up earlier. In the Add field at the bottom of the
window, select Property Module. Magellan fills in the Name field to the right
with the name of the Property module we set up earlier (lib_props). Click
the Add button to update MG shell and the display above.
17 We now have a complete project file. Let’s save it in case we want to run
the test again later without redefining everything. From the main menu,

select File > Save Project. Magellan saves the project file in the current
working directory with the project name we defined in Step 2
(exercise1.prj). Note that project files can have any extension you want, but
the .prj extension is a Magellan convention that makes it easier to locate
project files later.
18 Now we can run the test. Click the Run tab. Notice that the s_lib_props
Session module that we created earlier is already displayed in the Session
field. If we had defined more than one Session module for this project file,
the pull-down menu would show all of them, and you could choose the one
you want to run.
19 In the Console Log Options subtab, deselect the “Show user simulation
messages in console log” check box. This makes for a cleaner transcript
and a faster run when you have some assertions that fail on every clock
cycle, as there are in this test.
20 In the Run Options tab, Run Normal is already selected. Leave that as is
and click the Run/Build button. While the Run/Build is progressing,
Magellan displays the Monitor tab and shows you the tool’s progress
building the design and testing the properties.
21 To see the test results, select the Report tab. Click the Save button .
Magellan saves the report in HTML format. If you prefer to see a text file
report, type:
mgsh> list_session_results -file report_lib_props
Notice that Magellan proved two of the checkers and falsified two others. In
the next exercise, we’ll show you how to debug falsified properties.
22 From the mgui main menu, select File > Exit. When the Terminate Mgsh
Server window pops up, click the Yes button.

Add Custom SVA/PSL Assertions

In this exercise we’ll add some custom SVA and PSL properties to the same
mixed-language design and test those properties along with the checkers from
the SVA standard assertion library we used in the previous exercise. Then
we’ll show you how to save a simulation trace and debug an assertion failure.
your work area.
1 Review the custom SVA and PSL assertions added for this exercise.
Type File Line Assertion Name
SVA inline VHDL ../rtl/jpeg_a_sc.vhd 107 SVA_TOP_DCT_QUANT
../rtl/dct_input_a.vhd 207 SVA_DCT_READY_FOLLOW_PASS
../rtl/dc_encode_a.vhd 154 SVA_ENCODER_PASS_FOLLOW_READY
../rtl/runlength_a.vhd 538 SVA_COUNTER_INCREASE
SVA instantiated VHDL ../rtl/dc_encode_a.vhd 33 & 145 SVA_INSTANCE
SVA bind VHDL ../env/sva_bind_all.v 8 BIND_CHECKERS_INST
PSL inline Verilog ../rtl/jpeg_top.v 25 PSL_TOP_DATA_CHECK
PSL inline VHDL ../rtl/jpeg_a_sc.vhd 100 PSL_TOP_DCT_QUANT
../rtl/dct_input_a.vhd 211 PSL_DCT_READY_FOLLOW_PASS
../rtl/dc_encode_a.vhd 164 PSL_ENCODER_PASS_FOLLOW_READY
../rtl/runlength_a.vhd 543 PSL_COUNTER_INCREASE

% mgui
3 From the mgui main menu, select File > Open Project and open
exercise2.prj. The GUI loads all the Magellan Tcl commands contained in
the project file and fills up the display. Note that in this exercise we are
using the same Project, Design, and Environment modules that we used in
the first lab (see “Use Assertions from SVA Checker Library” on page 89).

Mixed-Language Quick Start Add Custom SVA/PSL Assertions
4 But the Property and Session modules are different. Select the different
configuration tabs to see how the project is set up. In particular, look at the
Property tab. Notice that there are two property modules defined for this
project, one that tests the SVA properties (sva_props) and another that
tests the PSL properties (psl_props).
5 Use the Property Module Name pull-down menu to select each property
and review the Scope Assertion List, which determines which assertions in
your design environment are activated for checking. The regular
expression you use can be as simple as *, which means test all. This is
shown with the sva_props property.
6 Select the Run tab. Notice that the s_sva_psl_props session is already
prefilled in the Session module pull-down. In the Console Log Options
subtab, deselect the “Show user simulation messages in console log”
check box. This makes for a cleaner transcript and a faster run when you
have some assertions that fail on every clock cycle, as there are in this test.
and click the Run/Build button. Magellan displays the Monitor tab so you
can watch the tool’s progress.
8 Magellan finds 15 SVA/PSL properties to test and proves 12 of them; the

other 3 are falsified, as shown in the Property Goals subtab of the Monitor
tab. Click the Report tab to view summary results for the test. Then click the
red .1. or .2. links in the display to see the details on the falsified properties.
9 To debug the falsified properties, select the Run tab again and click the
Debug Testbench button. In the Debug Testbench Setup dialog box that
pops up, DVE is already selected as the debugger. That’s what we’ll use
for this exercise. Click the Filter Debugger Waveform View check box.
Notice that the Failures Only radio button is already selected. We’ll use this
setting so that we see only the falsified assertions in the waveform viewer.
Otherwise, you see all targeted assertions. Click OK to dismiss the dialog
box. The testbench build takes a few minutes.

10 When the DVE waveform viewer comes up, click the run button on the
toolbar and look in the viewer for red arrows that show where
assertions failed (see Figure 9).
Figure 9: SVA/PSL Assertion Failures in DVE Waveform Viewer
11 Exit DVE. Then from the main menu, choose File > Exit to close mgui.
When the Terminate Mgsh Server window pops up, click the Yes button.
12 If you want to replay the test again later, you can. Magellan saves the files
needed to rebuild the testbench in the mg_sessionName/test/mgsh_debug
directory. There is a test.csh test driver in that directory that you can use to
rebuild the test in batch mode. Let’s run the test driver with the -vpd
switch, which causes it to create a VPD file for use in DVE. Use the
following command:
% mg_s_sva_psl_props/test/mgsh_debug/test.csh -vpd

Mixed-Language Quick Start Add Custom SVA/PSL Assertions
13 Now we can bring up DVE on the VPD file as follows:

% dve -vpd magellan.vpd &
When the DVE top-level window pops up, you can see the failed assertions
displayed in the middle of the window. DVE provides information about the
total number of successes and failures for the assertions, as well as the
reasons for the failures. Click on one of the failed assertions. The waveform
viewer pops up with the cursor at the first failure point (see Figure 10).
Figure 10: DVE Waveform Viewer Showing Assertion Point of Failure

Add a Reset Task and an SVA Constraint

In this exercise we’ll add a reset task to the test and an assertion-based
constraint written in SVA. The reset task establishes the initial or Reset State,
meaning the value of all registers and latches in the design. The Reset State is
important because it is used as the starting point for all formal searches in
Magellan. You use constraints to make sure that only legal inputs are getting
to your design during a test run.
1 Review the SVA assertion in the ../env/sva_constraint.sva file. This

assertion says that if the data_in_ready input is low, then the
data_element_in input should be 0. This assertion-based constraint is
instantiated on line 28 of the ../rtl/jpeg_top.v file with the name
data_constraint.

% mgui
exercise3.prj. Review the information in the Project and Design tabs. Note
that this is the same design used in the first two exercises.
4 To add a custom reset task, select the Environment tab and then the Reset
Task subtab.
5 Select the User Reset Task radio button and enter jpeg_reset_seq in the
Name field. When you press the Tab key, Magellan updates MG shell and
moves the cursor to the next field.
6 In the File field, enter ../env/jpeg_reset.vhd and select vhdl from the
pull-down menu to the right.
7 To add the SVA constraint, first select the Property tab. Click the Define
New button and enter data_constr as the name for the new property in the
small window that pops up.
8 Leave the SVA/OVA scope radio button selected and then select the
Constraint radio button in the Property Type panel.

Mixed-Language Quick Start Add a Reset Task and an SVA Constraint
9 In the Add/Set Scope field at the bottom of the window, enter

*data_constraint* and click the Add/Set button. Magellan updates MG shell
and the display above.
10 To add this new constraint property to the session, first select the Session
tab. Notice that the two properties we tested in the last exercise are still
displayed in the window (sva_props and psl_props). We’ll test them again
in this exercise, but with the addition of the custom reset task and
assertion-based constraint.
11 In the Add pull-down menu at the bottom of the window, select Property
Module and then choose data_constr from the Name pull-down menu to
the right. Click the Add button on the far right. Magellan updates MG shell
and the display above.
12 Now that we’ve configured our changes to the exercise3 project, let’s save
them so that we can run the project again later without reconfiguring
everything. From the mgui main menu, choose File > Save Project.
Magellan saves the exercise3.prj changes.
13 Select the Run tab and click the Run/Build button. Magellan displays the
Monitor tab so that you can see the tool’s progress. Notice that with the
addition of the SVA constraint, Magellan now proves all of the SVA and
PSL properties used in the test.
14 From the main menu, choose File > Exit to close mgui. When the
Terminate Mgsh Server window pops up, click the Yes button.
15 Let’s use the simulation script that Magellan generates in the user directory
to examine the correctness of the stimulus after the addition of the
constraint we used for this exercise:
% mg_s_constraints/user/dbgSim.csh -dve
When the debugger comes up, click the run button .

When you use this script, Magellan runs 10,000 cycles of constrained
random simulation. Examine the correctness of the stimulus. Note the
assert_data_constr constraint in the assertion display in the middle of the
window. It is green because Magellan honored the constraint and did not
send any stimulus vectors to the design that violated the constraint.

16 Double click the assert_data_constr constraint in the assertion display.

DVE highlights the assertion in the SVA source file in the top-level window
Figure 11).
Figure 11: SVA Constraint in DVE

Mixed-Language Quick Start Run SVA/PSL Cover Functional Coverage Test
Run SVA/PSL Cover Functional Coverage Test

In this exercise we’ll learn how to run functional coverage tests in Magellan
using SVA and PSL cover properties. One aspect of functional coverage
testing is making sure that some events or sequences of interest happen at
least once during testing (for example, preconditions to properties). You can
describe these events or sequences in SVA or PSL and use the cover
directive to test for their occurrence. Magellan generates the stimulus for the
test and tells you if the covers are reachable or uncoverable.
1 Review the SVA and PSL cover properties.
Type File Line Cover Name
SVA inline VHDL ../rtl/jpeg_a_sc.vhd 111 sva_cov_top_dct_quant
../rtl/dc_encode_a.vhd 160 sva_cov_pass_follow_ready
PSL inline VHDL ../rtl/dc_encode_a.vhd 168 psl_cov_pass_follow_ready
../rtl/jpeg_a_sc.vhd 104 psl_cov_top_dct_quant

% mgui
exercise4.prj. Click around the configuration tabs to see the information
that was loaded from the project file. Note that this is the same design used
in the last exercise, including the custom reset task and SVA constraint
used for that test.
4 You define functional coverage tests in a Coverage module. Select the

Coverage tab and click the Define New button. Enter sva_covers in the
small window that pops up and click OK.
5 In the Coverage Source panel, the OVA/SVA Scope radio button is already
selected. That’s what we’ll use for this test. In the Add/Set Scope field,
enter *SVA_COV* and click the Add/Set button.

Run SVA/PSL Cover Functional Coverage Test
6 Now, define another coverage target, this one is PSL. Click the Define New
button and enter psl_covers. Leave the OVA/SVA Scope radio button
selected. In the Add/Set Scope field, enter *PSL_COV* and click the
Add/Set button.
7 Now let’s add our new coverage targets to a Session module we can run.
Select the Session tab. The s_sva_psl_covers Session module is prefilled
in the Session Module Name pull-down menu. At the bottom of the tab,
select Coverage Module from the Add pull-down menu. Magellan makes
the Coverage modules we just defined available in the Name field. Set the
pull-down menu to sva_covers and click the Add button. Then do the same
thing for psl_covers. When you are done you should see the sva_covers
and psl_covers Coverage modules in the display above, along with the
SVA data_constr Property module we set up in the last exercise.
the file so that we can run the project again later without reconfiguring
everything. From the mgui main menu, select File > Save Project.
9 Select the Run tab and click the Run/Build button. Magellan displays the
Monitor tab so that you can see the tool’s progress. When the run finishes,
Magellan reaches three of the cover properties and proves that the other
two are uncoverable.
10 Still in the Monitor tab, click the Un-Coverable links to go to the Report tab
and see more information about those coverage goals.
11 To save the test, select the Run tab and click the Save Test button. A small
window pops up prompting you for the name of the directory where your
test files will be stored. At the end of the default path that is displayed,
replace mgsh_debug with trace and click OK.
12 From the mgui main menu, select File > Exit. When the Terminate Mgsh
13 From the UNIX prompt, invoke the test driver script from the directory
where you saved the test:
% mg_s_sva_psl_covers/test/trace/test.csh -dve

Mixed-Language Quick Start Run SVA/PSL Cover Functional Coverage Test
14 When the debugger comes up, run the simulation and review the trace.
15 In the middle of the DVE main window, change the pull-down menu to
Cover Properties and double-click a covered property highlighted in green.
DVE brings up the waveform viewer on the cover property (see Figure 12).
Figure 12: DVE Showing Covered SVA Cover

Run State Machine Coverage Test

In this exercise we’ll learn how to run state machine coverage tests in
Magellan. In this flow, you select interesting signals in the design (such as
state machine control register signals) and let Magellan’s high-coverage
stimulus generation tell you which states for those signals are reachable or
unreachable given legal input stimulus to the design.

% mgui
From the mgui main menu, select File > Open Project and open
exercise5.prj. Click around the configuration tabs to see the information
that was loaded from the project file. Note that this is the same design used
in the last exercise.
2 To define the RTL signals for the coverage test, select the Coverage tab.
Notice that the data_state_cov Coverage module name is prefilled in the
module name field. Magellan read this data from the exercise5.prj file that
we loaded.
3 Select the RTL radio button in the Coverage Source panel. In the RTL
Signal List panel, add the following signals in the Add/Set Signal text entry
field:
jpeg_top.jpeg0.u_dct.u_dct_buffer_1.data_element_out_1[7:0]
Note that for mixed-language designs, paths to internal signals are

case-sensitive and use the dot (.) to separate different levels in the
hierarchy. Click the Add/Set button to update MG shell and the display
above.
4 Select the Session tab. Notice that the s_data_state_cov Session module
name is prefilled in the module name field. Use the Add pull-down menu to
select Coverage Module. Magellan prefills the name of the Coverage
module we just defined (data_state_cov) in the Name field. Click the Add
button to update MG shell and the display above.
the file so that we can run the project again later without reconfiguring
everything. From the mgui main menu, choose File > Save Project.

Mixed-Language Quick Start Run State Machine Coverage Test
6 Select the Run tab. In the Console Log Options subtab, deselect the “Show
user simulation messages in console log” check box. This makes for a
cleaner transcript and a faster run when you have some assertions that fail
on every clock cycle, as there are in this test.
and click the Run/Build button. Magellan displays the Monitor tab so that
you can see the tool’s progress.
8 When the run finishes, go to the mgsh> prompt at the bottom of the window
and request a test report:
mgsh > list_session_results -file cov.rpt
9 Use your text editor to view the state coverage report showing the
reachable and unreachable states.
10 From mgui main menu, select File > Exit. When the Terminate Mgsh


5
Using MG Shell and
Magellan Commands
This chapter explains how to invoke the Magellan GUI, and use the MG shell and Magellan
commands to create projects, write control scripts, and run verification tests.
In This Chapter
Invoking the Magellan GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Getting Started with MG Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Using Magellan Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Creating a Magellan Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Using Smart Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Writing and Running Control Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using Magellan Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Invoking the Magellan GUI
Invoking the Magellan GUI

The Magellan GUI gives you an easy-to-use way to access the MG shell,
which is the primary interface to Magellan. You can use the GUI to create new
projects, review or edit existing projects, run Magellan tests, and monitor your
results. There are three ways to connect the GUI to your MG shell:
Invoke the GUI from the MG shell. Type mgui at the MG shell prompt:
mgsh> mgui
Invoke the GUI stand-alone and let it automatically start an MG shell for
you in the current directory when you create a new project or open an
existing project. Type mgui at the UNIX prompt:
% mgui
Invoke the GUI stand-alone, and connect to an MG shell you already have
running. From the GUI, click on the button.
When you invoke the GUI, and open a new or existing project, the display
looks like Figure 13. Open the Help tab for information on getting started.
Figure 13: Magellan GUI Display
Activity List Activity View
Configure, edit, run,

Navigate project and monitor projects
modules, test
runs, monitors,
reports, and help
Console View
Monitor activity in MG
shell, enter MG shell
commands, and get
command help

Using MG Shell and Magellan Commands Getting Started with MG Shell
Using mgui Easy Mode

You can also use mgui in easy mode, which takes advantage of Smart
Defaults (see “Using Smart Defaults” on page 120). Add the -easy switch to
your mgui invocation:
% mgui -easy
-or-
mgsh> mgui -easy
Getting Started with MG Shell

MG shell is the primary interface to Magellan. It is the process where you enter
commands and run scripts. For information on how to simplify your Magellan
project files for some commonly used tests, see “Using Smart Defaults” on
page 120.
To start MG shell:
% mgsh
To load a project when starting MG shell:
% mgsh project.prj
To view command-line options for MG shell:
% mgsh -help
To view the Magellan documentation:
% mgsh -doc
Running in Sever Mode Only

If you want to run MG shell in server mode only, add the -serverModeOnly
switch. For example:
% mgsh -serverModeOnly
This is like running a job in the background in UNIX. In this mode, there is no
STDIN client.

Running in No Server Mode

If you want to run MG shell with just a STDIN client, use the -noServerMode
switch. For example:
% mgsh -noServerMode
This mode prevents anyone from attaching to this MG shell using telnet or
mgui.
Using the Tcl Command Interface

Magellan commands are extensions to the Tool Command Language (Tcl).
Magellan supports a subset of the Tcl commands, and a set of
Magellan-specific commands. The commands use the same language
constructs as Tcl:
Tcl is case-sensitive. All commands are lowercase. Switches and options
use mixed-case.
Arguments are order-independent.
The dollar sign $ performs variable substitution.
Double quotation marks " " group words and characters together. Tcl
expands Tcl $ variables inside quotation marks. To access shell
environment variables inside double quotation marks, you can use the
$env array. For example:
$env(MG_HOME)
Curly braces { } create a literal list of arguments. Tcl does not expand Tcl
$ variables inside curly braces. The variable name is interpreted as a
literal. However, the set_design_info -vcs and add_design_info
-vhdlan commands are customized to expand shell environment
variables inside curly braces. This is makes it easier for you to
cut-and-paste your VCS or VCS MX command lines into a Magellan project
file without modifications. For this to work, the environment variables inside
curly braces must be defined in the shell where you started Magellan.
To create a list of evaluated variables, use the list command in square
brackets. For example, [list $var1 $var2].
The pound sign # comments a line in a Tcl script.

Using MG Shell and Magellan Commands Getting Started with MG Shell
The semicolon ; separates commands on a single line.
Note When working interactively in MG shell, do not enter non-blocking commands

with other commands on a single line (see “Using Blocking and Non-Blocking
Commands” on page 115).
All commands must be entered on a single line. Use a backslash \ to

continue a command across multiple lines. Literal lists that span multiple
lines do not require backslash \ continuation characters.
All commands and options can be abbreviated to the shortest unique name
for the command or option.
Note In Verilog, you can create escaped identifiers by prepending a backslash to

the identifier (for example, \<something>). At the same time, Tcl recognizes
backslash substitutions for a set that includes the familiar newline (\n) and tab
(\t) characters. So, to identify Verilog escaped identifiers in Magellan Tcl
commands, you need to escape the escape (for example, \\n or \\t) so that
Tcl doesn’t misinterpret your intent. This only applies if the escaped identifier
happens to match one of the Tcl backslash substitutions.
For more information about Tcl, see the Tcl Developer Xchange at
http://www.scriptics.com.
Using the history Command

The history command lists the commands you have entered in MG shell. To
get a description and the arguments for the history command, use the
history ? command:
mgsh> history ?
The ! command executes a previously entered command. For example, !4

executes the fourth command entered in the shell. The !read command runs
the last command that started with read. The !! command runs the last
command you entered.

Customizing MG Shell
If you want to set Tcl variables or write your own Tcl procedures and load
them every time you start MG shell, you can put them in a file named
.mgsh_rc. Magellan first looks for this file in the current working directory, and
then in your home directory. If the file exists in both locations, Magellan loads
both. Example 12 shows an .mgsh_rc file that declares a Tcl variable and
includes a few Tcl procedures.
Example 12: The .mgsh_rc File
# Global variable of test directory

set regression /tests/system/all
# Blocking run procedure:

proc runTest {session} {
echo “Start run...”
if { [run_session $session -block ] == “@runFinish” }
{
echo “>>> Run was successful.”
} else {
echo “>>> Unsuccessful run.”
}
report $session
}
# Procedural use of build:

proc buildTest {session} {
echo “Start build...”
if { [build_session $session -block] } {
echo “>>> Build was successful.”
} else {
echo “>>> Unsuccessful build.”
}
}
# Procedure using ‘get’ command result:

proc listDesignFiles {} {
set files [get_design_info -designFiles]
foreach file $files {
puts “ file - $file”
}
}

Using MG Shell and Magellan Commands Using Magellan Commands
Using Magellan Commands

Magellan commands are organized to help you easily find and use them; they
are arranged in the following groups:
Module commands either describe or act on a Magellan module.
Function commands configure MG shell and tools.
Built-in commands are Magellan-supported Tcl commands.
Procedures include Tcl procedures and user-defined procedures.
Magellan commands follow naming conventions that help you to know when
to use them. The following list shows the general naming conventions:
define/set commands
Define commands create new modules. For example, define_project
creates a new project.
Set commands add or change module definitions for a module that has
already been created. For example, set_project_info adds or
changes information for an existing project.
add/remove commands
Add commands add new information to a module. For example,
add_design_info adds design files to a Design module.
Remove commands delete information from a module. For example,
remove_design_info deletes design files from a Design module.
get commands
Get commands return values that you can use in a Tcl script or procedure.
The return values are strings, a list of strings, or a nested list of key-value
pairs. When used interactively, these commands may not show readable
output.
For information about the current project, enter the status or
list_session_results command at the MG shell prompt.
Note For information on how to simplify your Magellan project files for some
commonly used tests, see “Using Smart Defaults” on page 120.

Using Magellan Commands
Getting Help on Commands and Error Messages

To get help on Magellan commands, do one of the following in MG shell:
To list the command modules in Magellan:
mgsh> help
To list all the commands in a module:
mgsh> help module_name
-or-
mgsh> help -v module_name
The -v (verbose) switch lists each command in the module and all its
arguments.
To get a description of a command, type help command_name. For
example:
mgsh> help define_project
define_project #Define the project module.
To get a description and the arguments for a command, type:
help command_name -v or command_name ?. For example:
mgsh> define_project ?
define_project # Define the project module.
[-comment <string>] (comment for this project.)
[-filename <fname>] (project file name.)
[-force] (define a new project, discard any current
project changes.)
<projname> (project name)
To get a description and arguments for all commands that include a string,
use the * wildcard. For example:
mgsh> *prop ?
This command returns all the commands with prop in the name.
To view the man page for a command, type man command_name. For
example:
mgsh> man define_project

Using MG Shell and Magellan Commands Using Magellan Commands
To get a list of all commands matching an abbreviation, type

command_abbreviation?. For example:
mgsh> define_p?
define_proc_attributes#Add extensions to a procedure
define_project#Define the project module
define_property#Define a property module
To view the man page for a warning or error message, type
man message_label. For example:
mgsh> man HVB-005
Man pages for error messages from the Presto compiler are also available
in Magellan. For example:
mgsh> man VHDL-283
Understanding Data and Action Commands

There are two kinds of Magellan commands:
Data commands set up data for a test run. When you save a project in
Magellan, these commands are saved in the project file. Examples of data
commands include define_project and add_design_info.
Action commands perform operations on the data. You use action
commands in the MG shell, but they don’t go in the project file. Examples of
action commands include run_session, build_session, and status.
Using Blocking and Non-Blocking Commands

Magellan has both blocking and non-blocking commands. Blocking
commands prevent additional input until they finish. Non-blocking commands
return you to the MG shell prompt immediately.
Magellan has two non-blocking commands: run_session and

build_session. When you run either of these commands, the MG shell
prompt returns immediately, while the Build or Run process completes the
request (see “Building and Running a Session” on page 133). This is useful if
you want to query the status of a session while it is running.

Creating a Magellan Project
The run_session and build_session commands have -blockmode

switches that enable you to run them in blocking mode. The -blockmode
switch is required if you use either command in a script where you need the
command to complete before starting the next operation.

This section provides an overview of Magellan projects, and explains how to
create them. For information on how to simplify your Magellan project files for
some commonly used tests, see “Using Smart Defaults” on page 120.
Understanding the Magellan Project Structure

The project is a container for all the definitions Magellan needs to evaluate
your design and run tests. MG shell only processes one project at a time.
Figure 14: Magellan Project Structure
Project
Coverage
Environment
Property
Design
Session

Using MG Shell and Magellan Commands Creating a Magellan Project
As shown in Figure 14, a project has the following modules:

Project module
This is the container module that creates the project in Magellan. There is
only one Project module in a project.
In the Project module, you give the project a name and declare
project-wide settings, such as the default file format, and any preprocessor
macros or compiler directives. Macros or compiler directives defined in the
Project module apply to both the Formal build and the Simulation build. See
“Understanding the Build Process” on page 135.
Design module
This module describes the design under test. Here you give the design a
name, identify the top module, specify the design files, and list any include
directories used in the design files. There is only one Design module per
project. See “Preparing Your Design” on page 161.
Environment module
The Environment module is where you define simulation options, constraint
files, checkers, additional port descriptions such as clock and reset signals,
and any other supporting files for the design under test. See “Preparing the
Environment” on page 205.
You can have any number of Environment modules in a project. Give each
Environment module a unique name and then define the appropriate
options for that environment.
Property modules
Once you’ve identified a property you want to test and have written checker
code, you can add a property checker to the project here, in a Property
module. You can also direct Magellan to automatically generate checkers
from properties that it infers from the code. See “Testing Automatically
Extracted Properties (AEPs)” on page 367.
You can define any number of Property modules and AEP (Automatic
Extraction Processor) modules. Give each module a unique name and then
define the appropriate signals and options.

Coverage modules
Once you’ve determined the signals that are most interesting for generating
high-coverage stimulus, you can add coverage goals here, in a Coverage
module (see “Testing RTL Signal Coverage” on page 379).
You can define any number of Coverage modules in a project. Give each
Coverage module a unique name, and then list the appropriate signals and
options for that coverage goal.
Session modules
The Session module is where your environment, coverage goals, and
property checkers come together for a test that you can run (see “Running
a Session” on page 140).
You can define any number of Session modules in a project. Give each
Session module a unique name, and then choose the environment and
tests you want to run in that session.
Creating a Magellan Project File

A Magellan project file is a Tcl script of data commands specifying all the
project information. Although you may periodically enter project commands
interactively, you’ll want to keep the information in a file so you can easily load
it into Magellan. For information on how to simplify your Magellan project files
for some commonly used tests, see “Using Smart Defaults” on page 120.
You can create the project in the following ways:

Enter data commands interactively at the MG shell prompt. The project
data is stored in memory as long as you are in MG shell.
Then use a save_project command to save all the project-specific data
commands you’ve entered at the MG shell prompt into a project file.
The project file is saved in the current working directory.
The save_project command does not save any action commands that
you’ve entered in the project file or at the MG shell prompt (see
“Understanding Data and Action Commands” on page 115).
Use the Magellan GUI (mgui) to create a project file, then save it to run
your tests from the GUI or in batch mode.

Using MG Shell and Magellan Commands Creating a Magellan Project
Write the project file using a text editor, and use the read_project
command to load the project into Magellan.
Store the project file in the project directory (see “Understanding the
Directory Structure” on page 136).
Note In this guide, Magellan project files are described in terms of writing a file and
organizing the commands in the file by modules.
To see some complete Magellan project file examples, refer to the “Verilog
Quick Start” on page 31.
Save the project file frequently. Typically, the file name is the design name
with a .prj extension. This is a Magellan convention.
To load a project into Magellan, use the read_project command. This

command runs all the data commands in the project file. The read_project
command also enables Magellan to know the state of the project. When you
exit Magellan, you are only prompted to save the project if you’ve made
changes to it. You can also load a project when you start MG shell:
% mgsh projectName.prj
This is equivalent to starting MG shell, and then using the read_project

command. You can also use the source command to load a project, but this
doesn’t allow Magellan to track the project state. When you exit Magellan, you
are prompted to save the project even if you didn’t make any changes.

Using Smart Defaults

Smart defaults is a style of writing Magellan project files that makes it easier to
specify many commonly used tests. You don’t need to use a special switch or
mode to take advantage of smart defaults because they are assumed when
you give Magellan a project file that implies the need for them. If you don’t use
“define” commands such as define_design or define_property to
create containers for your project file modules, Magellan assumes that you are
expecting the tool to use smart defaults. Magellan defines the necessary
modules for you by default when you use “set” or “add” commands to specify
your design files, environment, and goals. This section explains how to use
smart defaults in the following subsections:
“Smart Defaults Module Names” on page 120
“Smart Defaults Example Project” on page 121
“Smart Defaults Command Style” on page 122
“Running Smart Defaults Tests” on page 125
“Specifying Multiple Smart Defaults Sessions” on page 126
“Adding Information to Smart Defaults Modules” on page 127
“Mixing Smart Defaults with Custom Modules” on page 128
Smart Defaults Module Names

Depending on the “set” or “add” commands you use, Magellan creates the
appropriate default modules using standard names you later see in the
transcript and any reports you generate to see test results. The default
modules are named as follows:
Project Module: _MgProject
Design Module: _MgDesign
Environment Module: _MgEnv
SVA/PSL Property Constraint Module: _MgConstraint
SVA/PSL Property Checker Module: _MgChecker
SVA/PSL Cover Module: _MgCover
RTL FSM Coverage Module: _MgFsm

Using MG Shell and Magellan Commands Using Smart Defaults
AEP Property Module: _MgAep

AEP Line, Condition, and FSM Coverage Module: _MgCm
AEP Toggle Property Module: _MgToggle
OVL Property Checker Module: _MgOvlChecker
OVL Property Constraint Module: _MgOvlConstraint
Session Module: _MgSession
Note The underbar ( _ ) in all the smart defaults module names is reserved. You
cannot use an underbar as the first character in the name for a custom module
that you create.
There are two different types of SVA/PSL and OVL Property module default
names. This allows you to use one Property module for checkers and another
Property module for constraints. There are also three different types of AEP
modules. You can use all three in the same project file using smart defaults.
You can also create custom project file modules using “define” commands and
combine custom modules and smart default modules in the same project file
(see “Mixing Smart Defaults with Custom Modules” on page 128). Custom
module definitions are required if you want to define multiple Environment
modules or dissimilar Property module types such as SVA and OVL in the
same project file.
Smart Defaults Example Project

Example 13 shows a Magellan project file that takes maximum advantage of
smart defaults. This example shows a Verilog design. For VHDL and
mixed-language designs you specify your design files with
add_design_info -vhdlan and -vlogan commands (see “Describing the
Design” on page 163).
Example 13: Smart Defaults Magellan Project File
set_design_info -topModule top –vcs { -sverilog dut.v }

add_env_port –name rst –reset 1 -constant 0

When you run Example 13, Magellan tests all SVA/PSL assertions found in
the design. Example 14 shows a project file that is functionally equivalent to
Example 13, but defined in the traditional style.
Example 14: Equivalent Traditional Magellan Project File

define_project myProject

define_design myDesign –topModule top
set_design_info myDesign –vcs { -sverilog dut.v }

define_env myEnv –sva -psl
add_env_port myEnv –name clk –clock 100
add_env_port myEnv –name rst –reset 1
add_env_port myEnv –name rst –constant 0

define_property myChecker –checker
add_property_info myChecker –scope { * } –type assert

define_session mySession –env MgEnv
add_session_info mySession –property MgChecker
Smart Defaults Command Style

Let’s take a closer look at how the simplified command style shown in
Example 13 on page 121 works. In the first line we say:
set_design_info -topModule top –vcs { -sverilog dut.v }
Because no Design or Project module is defined here, Magellan automatically

uses the predefined Project (_MgProject) and Design (_MgDesign)
modules.
When you use smart defaults, Magellan automatically searches for SVA/PSL
asserts in your design, but does not automatically search for SVA/PSL
constraints. To use constraints, you need to add the following line:
add_property_info -constraint -scope { * } -type assume

The next two lines in the smart defaults example say:

add_env_port –name rst –reset 1 -constant 0
Because we used “add” commands without specifying an Environment

module name with a “define” command, Magellan uses the predefined default
Environment module (_MgEnv). Here, the reset signal (rst) is set to 1 for the
Reset Phase and a constant 0 for the Random Generation phase.
Testing SVA/PSL Properties and Covers with Smart Defaults

If you don’t specify any goal modules in a smart defaults project file, Magellan
tests any SVA and PSL asserts in the design. The default goals that Magellan
uses are equivalent to Example 15.
Example 15: Smart Defaults Goal Module Default Definition (MgChecker)
add_property_info -checker -scope { * }
But perhaps you want to more tightly define which assertions are checked and
add constraints for the test. Maybe you also want to check SVA/PSL covers in
your design. In that case you can specify the goal modules yourself and define
the -scope arguments as needed (see Example 16).
Example 16: User-specified Smart Defaults Goal Module Definitions
add_property_info -checker -scope { a* }

add_property_info -constraint -scope { b* }
add_coverage_info -scope { c* }
Note As soon as you use an “add” or “set” command to specify any goals (including
SVA/PSL asserts) you are no longer using the default goals. In that case
Magellan tests just the smart default goals you specify.
In Example 16, because we used “add” property commands when no Property

module is defined, Magellan creates one Property module for SVA/PSL
checkers (_MgChecker), another for SVA/PSL constraints

(_MgConstraint), and another for SVA/PSL covers (_MgCover). Using this

example, the checkers must be specified as asserts and the constraints must
be specified as assumes. To specify that some assertions in the design be
used as constraints you can say:
add_property_info -constraint -scope { a* } -type assert
To specify that some assumes in the design be used as assertions you can
say:
add_property_info -checker -scope { b* } -type assume
Or to exclude some assertions from the set that are tested, you can say:
add_property_info -checker -scope { a* } -type assert \
-exclude { nocheck* }
The argument to the add_property_info -scope option specifies which

asserts or assumes to target for the test. For example, { a* } in the example
above means use any assertions found in the design with names that start
with the letter a. For more information on specifying scopes for your goals, see
“Specifying Which Assertions are Checked” on page 360.
Testing OVL Properties with Smart Defaults

To check OVL properties using smart defaults, use an add_property_info
command with the -ovlScope option to define the scope for locating OVL
assertion names in the design:
add_property_info -checker -ovlScope { a* }
Because we used an “add” or “set” property command when no Property

module is defined, Magellan creates a smart defaults checker OVL Property
module (_MgOvlChecker). If you use the -constraint switch instead of
-checker, Magellan creates a smart defaults OVL constraint Property
module (_MgOvlConstraint). For more information on OVL testing, see
“Using OVL Checkers and Constraints” on page 348.

Testing AEP Properties with Smart Defaults

To test AEP properties using smart defaults, use a set_aep_info command
and the appropriate switches for the tests you want. For example, to test all
property and coverage goals Magellan finds in the design, use the following
command:
set_aep_info -allProps -allCovs
With this command Magellan creates three separate AEP modules, one for
properties (_MgAep), one for line, condition, and FSM coverage tests (_MgCm),
and one for toggle checks (_MgToggle). For more information on the
available AEP tests, see “Testing Automatically Extracted Properties (AEPs)”
on page 367.
Testing RTL Finite State Machine Coverage with Smart Defaults

To test coverage on RTL finite state machine (FSM) signals using smart
defaults, use an add_coverage_info command with the -signals option
to identify the signals. For example:
add_coverage_info -signals \
{ qrm.route_current_0q[2:0] qrm.route_current_1q[2:0]} }
With this command, Magellan creates a smart defaults RTL FSM Coverage
module (_MgFsm).
Running Smart Defaults Tests

When you use smart defaults you don’t need to define a Session module for
your project. If you issue a run_session command without specifying a
Session name, Magellan uses the default Session name (_MgSession) for
the test run. This session includes all the tests you specified in the project file
using smart defaults or the default goals if you did not use any “add” or “set”
commands (see “Testing SVA/PSL Properties and Covers with Smart
Defaults” on page 123).

For example:
% mgsh project.prj
mgsh> run_session
Note Remember that any reports you generate using a list_session_results

command reference the default module names used by Magellan when you
use smart defaults command style (see “Smart Defaults Module Names” on
page 120).
Specifying Multiple Smart Defaults Sessions

You can create multiple smart defaults sessions that share the same
environment and design files, but target different goals. Just add the
-session option to the commands you use to specify the goals. For
example, to specify some property goals in one session, coverage goals in
another session, and AEP line and condition coverage goals in a third session,
you can specify them as shown in Example 17.
Example 17: Specifying Multiple Smart Defaults Session Modules
add_property_info -checker -scope { *u1* } \

-session aluCheck1
add_coverage_info -scope { *chk* } -session aluCheck2
set_aep_info -line 1 -cond 1 -session aluCheck3
Using Example 17, Magellan creates three separate smart defaults session
modules (aluCheck1, aluCheck2, and aluCheck3). Now you can run

those sessions independently, rather than having Magellan target all the goals
in the same run. For example:
% mgsh project.prj
mgsh> run_session aluCheck1
Note If you use the same three commands shown in Example 17 without the
-session option, Magellan adds all three sets of goals to the default session
module (_MgSession).
To add a goal set to multiple sessions, specify those session names in a list for
the -session switch. For example:
add_coverage_info -scope { *chk* } \
-session {aluCheck1 aluCheck2}
To add a goal to all defined sessions (including the default, _MgSession) use
the -allSessions switch. For example:
add_coverage_info -scope { *chk* } -allSessions
To add a constraint to all sessions and create a special simulation-only

session with that constraint you can specify:
add_property_info -constraint { *con* } -allSessions \
-session {simOnly}
Adding Information to Smart Defaults Modules

You can use many of the MG shell commands to “set”, “get”, “add”, or
“remove” information in smart defaults modules. For example, if you want to
set a design port to a constant value during the Random Generation phase,
you can use an add_env_port -constant command:
add_env_port -name design_port -constant 1
Magellan adds this definition to the smart defaults Environment module

(_MgEnv).

Writing and Running Control Scripts
If you attempt to use an MG shell command to add or modify information in a

smart defaults module where the intent is ambiguous, Magellan issues an
error message. In this case, you can create a custom module for that test.
Mixing Smart Defaults with Custom Modules

You can take advantage of smart defaults and add custom modules in the
same Magellan project file. For tests that require more detailed information,
use the appropriate “define” command (for example, define_property,
define_coverage, and define_session). When you use a “define”
command, Magellan expects a complete definition for the module, including
“add” or “set” commands that use the module name you specified with the
“define” command. Custom modules specified this way are not added to the
smart defaults Session module. You need to either create a separate session
to test those goals or explicitly add the new goals to the default session
module. For example:
add_sesson_info -property propertyName
For more information on specifying custom project file modules, see the
appropriate chapters in this manual.
Writing and Running Control Scripts

Control scripts automate tasks that you want to do repeatedly. The Magellan
project file is a special type of control script that describes your test data (see
“Creating a Magellan Project File” on page 118). Control scripts can contain
Tcl commands and Magellan commands. Example 18 shows a simple control
script that loads the UART project, runs session cov, reports the results of the
test, and then saves a test stimulus file for replay in the simulator.
Example 18: Tcl Script File
read_project uart.prj
run_session cov -blockmode
list_session_results cov
write_session_test fifo_goalset_test
Example 19 shows a control script that runs a series of sessions.

Using MG Shell and Magellan Commands Writing and Running Control Scripts
Example 19: Tcl Script That Loops Through a List of Sessions
read_project my_project.prj
set ses_list [get_session_info *]
set f [open results.txt w]
foreach s $ses_list {
puts -nonewline $f "Session: $s"
set res [run_session -blockmode -maxTime 1.0 $s]
if {$res=="@runFinish"} {
set proplist [get_session_info -prop $s]
foreach prop $proplist {
set stat [get_session_run_info $s -prop $prop]
set value [lindex $stat 0]
puts $f " Property: $prop -> $value"
}
} else {
puts $f " Error...!"
}
flush $f
}
close $f
You can run a script using any of the following methods:

The source Tcl command.
Use this command when you want to run a script interactively in MG shell
or from within another script. For example, if the script is called
run_goal.tcl, enter the following in MG shell:
mgsh> source run_goal.tcl
Note how the uart_test.tcl script shown in Example 20 calls another script
named run_goal.tcl using the source command.
Example 20: Tcl Script in a Script
read_project uart.prj
if [build_session cov -blockmode] {
echo “Run Test”
source run_goal.tcl
echo “Run Complete”
}

Using Magellan Remotely
The mgsh -batch option.

Use the -batch option when you want to run a script and then quit MG
shell. Run this command from the UNIX prompt. For example:
% mgsh -batch run_goal.tcl
The mgsh -eval option.

Use the -eval option when you want to enter Tcl commands and then quit
MG shell. Run this command from the UNIX prompt. For example:
% mgsh -eval ‘read_project uart.prj; run_session cov’

This section describes how to use telnet to access Magellan, and how to set
up Magellan to use a remote server.
Using Telnet with MG Shell

Before you can use telnet to remotely connect to MG shell, you need to know
the host name and port number of the MG shell to which you want to connect.
To get the host name and the port number, run the status command in the
MG shell. The status command reports the host name as the Client Server
Name. For example:
Client Server Name: pixie.mynetwork.com
Address: 198.182.45.62
Port: 5557

Using MG Shell and Magellan Commands Using Magellan Remotely
Enter the following telnet command to access the MG shell with the
information from the previous example:
% telnet pixie 5557
>Trying 198.182.45.62...
>Connected to pixie.mynetwork.com.
>Escape character is ‘^]’.
Press the Enter key and you are remotely connected to MG shell.
Tip If you have a portable PC, you can start the MG shell in server mode as a
background process, and telnet to it later from a remote site:
% mgsh project.prj -serverModeOnly -port 6000 &
Then use telnet to connect to the server and start a session run. When you are
ready to change locations, unplug your PC. At the new location, use telnet to
connect to the server and continue.
To disconnect from MG shell without terminating, enter the exit command.

To remotely shut down MG shell, enter the exit_server command.
Using a Remote Server

You can set up Magellan to use a remote server whenever you do a build or
run a session. Use the set_server command to identify the remote host that
you want to use. The following example sets up Magellan to do builds on the
mercury server and run sessions on the jupiter server.
set_server -build mercury -run jupiter
Magellan starts a shell on the remote server. This shell must be initialized to
use the correct environment or the command will fail. Set the environment
using a .cshrc file on the remote server. Or, if you don’t have access to the
remote server, use the set_option command (see “Configuring
Environment and Path Variables” on page 21).
Note If you are using Rational™ ClearCase™, the view to the project must be
correctly initialized or you need to move the design outside of ClearCase.

Example 21 shows a Tcl script that uses a remote host to do a build or run.
Example 21: Remote Build Script
#Setup for remote build

proc remote {host args} {
set results (-build) ““
set results (-exp) ““
set results (-run) ““
parse_proc_arguments -args $args results
#Set the ClearCase View

set_option -atriaView mars
#Set shell environment variables

set_option -setEnvs {
VCS_HOME=/u/ctg/tools/vcs_latest
MG_HOME=/vobs/propver/rls
SNPSLMD_LICENSE_FILE=5310@saturn
PATH=$PATH:/usr/ccs/bin
}
if {$results(-build) == 1} {
set_server -build $host
}
if {$results(-run) == 1} {
set_server -run $host
}
}
define_proc_attributes remote \
-info “sets remote host for build, run, or explore” \
-define args {
{-build “build server” ““ boolean optional }
{-run “run server” ““ boolean optional }
}

6
Building and Running a
Session
This chapter explains how to build and run a session in Magellan.
In This Chapter
Building a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Understanding the Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Running a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Understanding Magellan’s Default Run Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Using Run Modes to Tune Magellan’s Run Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Solver Engine Reporting and Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Using Guideposts to Aid Formal Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Distributing Magellan Engines on a Server Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Using Breakpoint Options to Control Magellan Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Filtering and Reporting Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Building a Session
Building a Session
Before you can successfully build a session, you need to create a project and
define at least the following four modules: Project, Design, Environment, and
Session (see “Understanding the Magellan Project Structure” on page 116).
Each session you define in a Magellan project is built separately. Do not build
one session while another session in the same project is building in another
mgsh process. To build a session:
1 Start MG shell:
% mgsh
If you add the -waitlic switch to your mgsh invocation, Magellan waits
for a license if none is currently available instead of exiting. For example:
% mgsh -waitlic
2 Load the project:

mgsh> read_project project.prj
For example:
mgsh> read_project uart.prj
3 Build the session:

mgsh> build_session sessionName
Note The build_session command has a number of options you can use to build
all or part of the project. For more information, at the MG shell prompt, type
man build_session.
You can also build a session on a remote server (see “Using a Remote
Server” on page 131).
When you build a session, Magellan checks to see if anything has changed
since the last build. Magellan only rebuilds the areas that have changed. To
force a complete rebuild, use the -force switch.

Building and Running a Session Building a Session
Understanding the Build Process

When you enter the build_session command, Magellan starts a new
process called the Build server. The Build server process initiates two
additional build processes. One process, known as the Formal build, runs the
front-end of the synthesis compiler and creates a formal model of the design.
The other process, called the Simulation build, runs the simulator. Figure 15
shows the build processes.
Figure 15: Build Process Architecture
MG Shell
Build Server
Formal Simulation
Build Build
While a build is running, you can continue entering commands in MG shell.

This is because the build runs in its own process. Commands that change the
build dependencies or the design generate errors indicating that a build is in
progress.
When you build a session, the last step is to prepare the design for the run.
This preparation step reduces the design to the signals included in the
Property and Coverage modules referenced in the session and the transitive
fanin of those signals. This improves Magellan’s performance and increases
the chances that Magellan will prove or falsify properties.

Understanding the Directory Structure
For Magellan to effectively evaluate a design, the formal model needs to be

functionally equivalent to the simulation model (see “Preparing Your Design”
on page 161 and “Detecting Simulation/Synthesis Mismatches” on page 457).

When you build and run a project, Magellan creates a directory structure
anchored at the top by the project or current working directory (see Figure 16).
Figure 16: Directory Structure
project
directory
mg_common mg_session1 mg_session2 mg_session3
... ...
sim
test
user
As Magellan compiles a session, it stores the compiled design information

under the current project directory in a subdirectory called mg_common. The
design information in mg_common is reused for each session.
Note Use a unique working directory for each design. If you put more than one
design in the same project directory, the information in mg_common does not
represent a single design, but a combination of the designs stored in the
project directory.

Building and Running a Session Understanding the Directory Structure
Also in the project directory, Magellan records every command you enter in
MG shell in the mgsh_commands.log. This is useful for reviewing the
sequence of events. Magellan also stores build messages and every message
issued during a run in the mgsh_messages.log.
As shown in Figure 16, Magellan creates a session directory named

mg_sessionName, where sessionName is the session name specified in the
project file. Below each session directory are three more directories: sim, test,
and user.
The test directory contains test cases generated when you issue the
write_session_test command. Use these files in the simulator for further
design validation.
The sim directory contains all the files the simulator generates during a run.
This includes, for example, waveform dump files.
User Directory Generated Files

The mg_sessionName/user directory contains files, logs, and scripts you can
use to help debug checkers and constraints, diagnose design build issues,
and solve simulation/synthesis mismatch issues. This directory also contains
files that show important information about the test environment setup. In most
cases, the following list of files also includes hyperlinks to other sections in this
manual where you can find detailed information about the files and their uses:
goals.log
Shows the trace results from the most recent run of the session (see
“Automatically Generated Transcripts” on page 419).
build.log
Contains messages generated during the build phase and a build server
summary at the end which shows statistics about the design and
environment.
build.rpt
Shows user-specified or default settings used during the build, along with
statistics about the design and environment.

compile.log
Shows the simulation compile log for the build.
xFile.init
The xFile.init file contains messages about registers that have X values
when the reset sequence finishes.
dbgSim.csh
The dbgSim.csh script invokes the simulator in command-line mode by
default. Add the -dve switch to invoke the Design Visualization
Environment (DVE) GUI. Use the dbgSim.csh script to debug checkers,
constraint models, reset sequences, and so on. See “Using the Simulation
Test Scripts” on page 139.
Depending on your test setup, the user directory may also contain the
following files:
forcedSignals.log
Black box and forced signals report (see “Understanding “forces” in RTL
Simulation Models” on page 181).
latchRemodelWarning.log
Warning messages for unsafe latches found in the design (see
“Remodeling Latches” on page 190).
loops.rpt
Combinational loops report (see “Understanding the Combinational Loops
Report” on page 195).
design_driver.v or design_driver.vhd
Bidirectional port random driver template (see “Using a Template to Write
your own Constraints” on page 198).
2xSystemClock.rpt
Report of conditions that require a 2x system clock (see “2X System Clock
Generation and Reporting” on page 212).
unobservedInputs.log
Report of inputs that cannot affect search results (see “About Waveform
Readability” on page 449).

Building and Running a Session Understanding the Directory Structure
diagnose.out
Simulation/synthesis mismatch diagnosis report (see “Using Magellan’s
Mismatch Reports” on page 471).
TraceFile.simTime.vcd
VCD trace files (see “Generating VCD Files for Formal Traces” on
page 473).
coi___propName_nonvacuity_n.txt
If the goals in your session do not converge quickly, there is one text file for
each goal in the session, where n equals the goal index number. The files
contain information about the cone of influence for each goal, showing the
sequentials in the cone. You can also generate cone of influence reports
using a report_session -cone command (see “Cone of Influence
Reporting” on page 439).
resetState.diff.n
Reports the registers whose values in a subsequent Reset State don’t
match the values from the initial Reset State (see “Miscompare Warning
Message” on page 252).
Using the Simulation Test Scripts

Use the dbgSim.csh script to debug checkers, constraint models, reset
sequences, and so on, in the simulator. This script invokes the simulator and
then waits for user input before running the reset sequence and then 10,000
clock cycles of random input stimulus (see “Understanding and Controlling the
Reset State” on page 220). Add the -dve switch to invoke the Design
Visualization Environment (DVE) GUI.
To run the simulation test script in the default command-line mode, from the
UNIX prompt, enter:
% mg_sessionName/user/dbgSim.csh

Running a Session
Running a Session
This section explains how to run a session in the following subsections:
“Session Run Basics” on page 140
“Specifying a Debugger for the Run” on page 141
“Running 64-bit Magellan” on page 142
“Managing Memory Resources” on page 142
“Filtering Messages” on page 142
Session Run Basics

When you run a session, Magellan first evaluates whether any part of the
project or design has changed since the last build. If there are changes,
Magellan automatically rebuilds the project before starting the run. A session
can include one or more Coverage modules and one or more Property or AEP
modules. Example 22 shows a Session module that includes both types of
modules.
Example 22: Session Module with Coverage and Property Modules

define_session cov_prop -env env
add_session_info cov_prop -coverage FIFO_goalset
add_session_info cov_prop -property mutex
Be careful to weigh the advantages and disadvantages of combining multiple

Property and Coverage modules in a single session. There is a practical limit
of about 24 signals for coverage goals (see “Defining RTL Coverage Goal
Sets” on page 384), and the chance of proving a property may be reduced
when more than one property is analyzed at a time. To run a session:
1 Start MG shell:
% mgsh

Building and Running a Session Running a Session
2 Load the project:

mgsh> read_project projectName
For example:
mgsh> read_project uart.prj
3 Run the session:

mgsh> run_session sessionName
For example:
mgsh> run_session cov
The sessionName argument is optional. If you do not specify a session,

Magellan prompts you with a list of session names from which you can
choose.
Specifying a Debugger for the Run

When you run a session, Magellan generates waveform files by default. If you
are using DVE as your debugger, the tool creates one VPD file for each
simulator reset and trace that reaches new goals. If you are using Debussy or
Verdi as your debugger, the tool creates FSDB files instead. Magellan decides
which file format to use based on your default debugger setting (see “Setting a
Default Debugger” on page 445).
If you want all dump information for the run in one VPD or FSDB file, use the
-oneDebugFile switch. For example:
mgsh> run_session sessionName -oneDebugFile
If you prefer not to generate waveform files, use the -noDebug switch:
mgsh> run_session sessionName -noDebug
You can also override the default debugger setting using the -fsdb switch for
Debussy/Verdi or -vpd switch for DVE. For example:
mgsh> run_session sessionName -fsdb

Running a Session
Regardless of your default debugger setting, this command causes Magellan

to create waveform files for Debussy during this run.
Running 64-bit Magellan

When you use a 64-bit version of mgsh, the Magellan Build and Run servers
run in 64-bit mode for the increased memory addressing capability, and the
VCS compile and runtime executables run in 32-bit mode.
Running VCS in 64-bit Mode (Verilog only)

If you want to force VCS to also run in 64-bit mode, add the -full64 switch
to the compiler options you specify with the set_design_info command in
the Design module of your project file.
If you use the -full64 option and are using Vera biasing, make sure you
also have $VERA_HOME set to a supported 64-bit Vera release.
Managing Memory Resources

Magellan is optimized to use multiple concurrent processes and 4 GB of
physical memory. To avoid excessive swapping, if you have less than 4 GB of
physical memory, use the -maxMemory option to the run_session
command. For example, if you have 2 GB of memory, use the following
command:
mgsh> run_session sessionName -maxMemory 2GB
Filtering Messages
To suppress warning or information messages that you don’t think are
significant, use the add_project_info -msgFilters command.
For example, to filter out messages HVSH-200 and HVSH-201, use the
following command in your project file:
add_project_info -msgFilters { HVSH-200 HVSH-201 }

Building and Running a Session Running a Session
Understanding the Run Process

When you initiate a session in Magellan, it starts a new process called the Run
server (see Figure 17). The Run server starts multiple processes that
concurrently validate the design. The Unreach processes can run concurrently
with either the Simulator process or the Reach process. This allows Magellan
to take advantage of machines with two CPUs and provide the best
performance. If only one CPU is available, Magellan runs longer before
reporting results.
Figure 17: Run Process Architecture
MG Shell
Build Server Run Server
Formal Simulation Simulator Reach Engine

Build Build
Unreach
Engines
While a session is running, you can continue entering commands in the MG

shell. This is because a session runs in its own process. Commands that
change the build dependencies or the design generate errors indicating a test
run is in progress.

Understanding Magellan’s Default Run Behavior
Understanding Magellan’s Default Run Behavior

Magellan’s default behavior is to run the session until one of the following
occurs:
Magellan completes the task:
Proves or falsifies all the properties in the session.
Classifies all possible coverage goal states as reached or unreachable.
Magellan reaches a predetermined time limit.
To limit the run, use the run_session -maxTime command. If you have
large numbers of black boxes in your design, see “Controlling
Internal/Black Box Signals” on page 180 for information on a -maxTime
limitation.
Magellan pauses at a breakpoint.
When a breakpoint is reached, Magellan pauses the Run server, which in
turn pauses the engines that it governs after they complete their current
tasks. The time it takes for all engines to pause is not predictable (see
“Understanding the Run Process” on page 143).
Breaks occur in the following situations:
You use the -break argument with the define_session command
when checking properties (see “Debugging Property Violations” on
page 445).
You use the -compareAlways or -compareReplay switches with the
run_session command, and Magellan finds a simulation/synthesis
mismatch (see “Detecting Simulation/Synthesis Mismatches” on
page 457).
You use a $stop command in your Verilog source code.
During a test run, use the status or list_session_results command to

get more information (see “Automatically Generated Transcripts” on
page 419).

Building and Running a Session Using Run Modes to Tune Magellan’s Run Behavior
Using Run Modes to Tune Magellan’s Run Behavior

You can use run_session command options to focus Magellan’s run
behavior, or mode of operation, in a number of ways, depending on what you
want to test:
“Run Search Engines Only Mode” on page 145
“Run Short Trace Mode” on page 146
“Run Formal Only Mode” on page 146
“Run Bounded Proof Mode” on page 146
“Run Random Simulation Only Mode” on page 147
“Run Code Coverage Mode” on page 147
You can combine run_session mode options with breakpoint options in the
same run_session command (see “Using Breakpoint Options to Control
Magellan Runs” on page 156). In addition, you can abbreviate run_session
-mode commands using the shortest unique string from the set of run modes.
Run Search Engines Only Mode

In this mode, Magellan searches only for property failures and reachable
states for coverage goals, and does not try to prove properties or find
unreachable states for coverage goals, so runtime performance may be
improved. This mode can enhance Magellan’s chances of finding defects in
your design. Search mode can be a good option if you already tried to find a
proof for a property and the result was still unknown after a long search. To run
Magellan in search engines only mode, use the following command:
mgsh> run_session sessionName -mode searchOnly
If all the properties you test in search-only mode are true, the tool runs
indefinitely unless you limit the run using a break option or the -maxTime
option with your run_session command. For more information on proving
properties and reaching coverage goals, see “Testing Properties” on page 299
and “Testing RTL Signal Coverage” on page 379. You can also use
search-only mode to run guidepost sessions (see “Using Guideposts to Aid
Formal Searches” on page 150).

Using Run Modes to Tune Magellan’s Run Behavior
Run Short Trace Mode

In this mode, Magellan focuses more on deep formal searches from the Reset
State and less on random simulation cycles while trying to get the shortest
trace possible. If you falsify a property using Magellan's normal run mode, but
get a long simulation trace, you can rerun your session with short trace mode
on and sometimes obtain a more compact trace that shows the failure earlier
in the simulator. A longer runtime may be necessary to obtain this shorter error
trace. To run Magellan in short trace mode, use the following command:
mgsh> run_session sessionName -mode shortTrace
Run Formal Only Mode

In this mode, Magellan focuses just on deep formal searches from the Reset
State and doesn’t do any random simulation. This is an exhaustive search
from the Reset State, which can be time consuming. Also, there may be cases
where this mode does not converge, and normal run mode would have found
a bug. To run Magellan in formal only mode, use the following command:
mgsh> run_session sessionName -mode formalOnly
Run Bounded Proof Mode

In this mode, Magellan is optimized to find the deepest bounded proofs
possible in the shortest amount of time. Bounded proof mode is a different
kind of formal-only mode in that Magellan runs multiple formal engines using
different algorithms concurrently to look for bounded proofs, but no random
simulation at all. As a side effect, this run mode may produce error traces that
may not be found in normal run mode, so it can be a good bug-hunting option.
For more information on the value and limitations of bounded proofs, see
“About Bounded Proofs” on page 302. To run Magellan in bounded proof
mode, use the following command:
mgsh> run_session sessionName -mode boundedProof

Building and Running a Session Using Run Modes to Tune Magellan’s Run Behavior
Run Random Simulation Only Mode

In this mode, Magellan doesn’t do any formal searches and focuses instead
on constrained random simulation only. You cannot prove properties or find
unreachable states for coverage goals in this mode. If you run this mode
without setting a Cyc breakpoint condition (see “{Cyc=n}” on page 157), the
run terminates only when there are no remaining unknowns. Simulation-only
mode can be a good option earlier in the verification cycle as it can expose
issues with your clock/reset definitions and sometimes even basic constraint
modeling issues by way of deadends. Further, it can be used to hunt very
basic bugs for which formal analysis may not be required.To run Magellan in
simulation-only mode, use the following command:
mgsh> run_session sessionName -mode randomSim
Note If you use the -compareAlways switch with -mode randomSim in the same
run_session command, Magellan still compares every state at every cycle
beginning at time zero, but does not generate any formal traces.
Run Code Coverage Mode

This mode is optimized to converge faster on large numbers of reachable
goals. It can be a good option for AEP line and condition coverage tests and
AEP toggle tests (see “Testing all AEP Property Goals” on page 375 and
“Toggle Coverage” on page 374). This mode is not a good choice for proving
properties. To run Magellan in code coverage mode, use the following
command:
mgsh> run_session sessionName -mode codeCoverage

Solver Engine Reporting and Reuse
Solver Engine Reporting and Reuse

Magellan includes information in the output reports that tells you the formal
solver engine used to converge each property or coverage goal, along with the
effort level that was used.
For example, for each property or coverage goal that converged during the
run, the list_session_results -long command output contains two
additional fields, as shown in Example 23.
Example 23: Solver Engine Individual Property/Goal Reporting
-Solver Engine : eng1

-Effort Level : 1
In Example 23:
The Solver Engine field tells you which solver engine or algorithm
converged the property or coverage goal.
The Effort Level field tells you how hard the reported solver engine
worked to converge that goal. Possible values for Effort Level include
1 (the default), and 2 through 10.
You can also get summary reports for solver engine performance on your
session using the report_session -stats command. When you run your
session in goal narrowing mode, the report_session -stats output
contains the additional section shown in Example 24.
Example 24: Solver Engine Summary Reporting
- Solver Engine Statistics

Eng1 effort 0 proved 1 and falsified 3 total 4
In Example 24, the most productive combination of solver engine and effort
level was Eng1 at effort level 3, which converged 7 properties (proved 3
and falsified 4).

Building and Running a Session Solver Engine Reporting and Reuse
Reusing a Specific Solver Engine and Effort Level

You can rerun a session with the specific solver engine and effort level already
reported to be successful in converging your properties or coverage goals. For
example, to reuse the most successful combination shown in Example 24
(Eng1 at effort level 3) use the following command:
mgsh> run_session -mode parallelEng1:3 sessionName
With this command, Magellan runs multiple instances of the parallelEng1

solver algorithm, each at effort level 3. Note that the default effort level is 1.
Legal values that you can specify include 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10.
Be sure to specify a legal solver engine name that maps to a solver engine
name reported by the list_session_results -long (see Example 23 on
page 148) or report_session -stats command (see Example 24 on
page 148). To form a legal solver engine name for the run_session -mode
argument, prepend the word parallel to the reported engine name, as
shown in the following examples:
eng1 or Eng1 maps to parallelEng1
...
If you specify a solver engine name that is not legal, Magellan issues a
warning message and uses the default engine for that run.
As another complete example, if Eng2 was successful in converging most of

your properties or coverage goals using effort level 4, and you want to reuse
that combination, use the following command:
mgsh> run_session -mode parallelEng2:4 sessionName
Note Running individual proof engines is not supported in grid mode (see
“Distributing Magellan Engines on a Server Farm” on page 154).

Using Guideposts to Aid Formal Searches

You can use guideposts to aid Magellan’s searches for property failures (bugs)
that have not been discovered in the default flow. The Guideposts feature is a
special variant of search-only mode in which Magellan searches only for
property failures and reachable states for coverage goals, and does not try to
prove properties or find unreachable states for coverage goals, (see “Run
Search Engines Only Mode” on page 145).
Guideposts give you a way to specify interesting design states that Magellan
can use as starting points for formal searches. For example, to search for a
FIFO overflow condition, it may be useful if the FIFO is full or nearly full before
starting the formal analysis. A potentially useful guidepost is one that is close
to the property in the state space of the design.
Before using guideposts, try to converge (prove or falsify) your properties in

the default flow (see “Understanding Magellan’s Default Run Behavior” on
page 144). Properties that you suspect may reveal design bugs but do not
converge in the default flow are candidates for the guideposts feature.
Defining Guidepost Coverage Modules

Magellan uses Coverage modules to implement guideposts. (You cannot use
Property modules to implement guideposts.) You use SVA covers to specify
the guidepost coverage goals. Magellan assumes that the guidepost coverage
goals you define are easier to reach than the properties they are intended to
help converge.
For example, to create a guidepost Coverage module that uses SVA covers to
implement guideposts, use a define_coverage -guidePost command.

Building and Running a Session Using Guideposts to Aid Formal Searches
Then use an add_coverage_info -scope command to define the goal

signals, as shown in Example 25.
Example 25: Guideposts Coverage and Session Modules for SVA Covers

define_coverage gp_cover -guidePost
add_coverage_info gp_cover -scope {*cover*}

define_session s1 -env env1
add_session_info s1 -coverage { gp_cover }
add_session_info s1 -property { p_overflow }
add_session_info s1 -property { myConstraints }
For more information on specifying SVA covers, see “Adding SVA/OVA Covers
to the Project File” on page 408.
In Example 25, notice that the Session module also includes a Property
module (p_overflow). This property is the one that Magellan searches for
using the specified guidepost as the starting state for the formal search. To
use guideposts you must run a Session module that specifies both the
Coverage module where the guidepost is defined and the Property module
where the property is defined.
You can use guideposts to aid searches for more than one property at a time.
And you can define more than one guidepost for the properties in that session.
However, Magellan performance is often enhanced when you give the tool
one property and one guidepost in any one session that you run.
Running Guidepost Sessions

You must use the Magellan search-only run mode for guideposts to take
effect. To run Magellan in search-only mode, use the following command:
mgsh> run_session sessionName -mode searchOnly

For example, to run the guidepost session defined in Example 25, use the
following run_session command:
mgsh> run_session s1 -mode searchOnly
Note When you use search-only run mode, the tool behavior depends on whether
there are any guideposts defined in your project file. If there are no
guideposts, the tool runs the normal search-only mode (see “Run Search
Engines Only Mode” on page 145).
You can run a session that includes guideposts in the default run mode, but in
this case Magellan treats the guideposts as regular coverage goals with no
special significance with regard to aiding property searches.
Reporting Guidepost Session Results

Magellan does not report guidepost session information in the transcript or the
mgsh_messages.log file. To see guidepost results, use the
list_session_results -long command. For example:
Property Module: p_overflow
> ID: [0] Falsified

- SimTime : 6849
- Update : 15:04:16 - Jul 14
- Random Cycles : 4
- Formal Cycles : 62
- Assisted GP : gp_cover:3
- GP Radius : 126
- Assertion : assert_overflow
- Assertion Loc : ../rtl/des_fifo.v:116

Building and Running a Session Using Guideposts to Aid Formal Searches
Coverage Module: gp_cover (GuidePost)

...
> ID: [3] Covered

- Type : SVA Cover
- SimTime : 549
- Update : 15:03:54 - Jul 14
- Random Cycles : 3
- Formal Cycles : 0
- Search Radius : 126
- Cover : cover_status_cnt_1
- Cover Loc : ../rtl/des_fifo.v:99
- Instantiation : ../rtl/des_fifo.v:1
- Parent Loc : ../rtl/des_fifo.v:1
...
> ID: [7] Covered

- Type : SVA Cover
- SimTime : 5449
- Update : 15:04:15 - Jul 14
- Random Cycles : 4
- Formal Cycles : 48
- Assisted GP : gp_cover:3
- GP Radius : 126
- Cover : cover_status_cnt_31
- Cover Loc : ../rtl/des_fifo.v:105
- Scope : des_fifo
- Instantiation : ../rtl/des_fifo.v:1
- Parent Loc : ../rtl/des_fifo.v:1
In the Property Module section of the report:

the Assisted GP field shows the guidepost that was used to help falsify
the property (gp_cover:3 in this example). Details for the gp_cover:3
SVA cover are shown in the ID:[3] section of the report.
The GP Radius field in the report shows the sequential cycle depth to
falsify the property from the guidepost (126 cycles in this example).

Distributing Magellan Engines on a Server Farm
In the Coverage Module section of the report:

The Assisted GP and GP Radius fields appear if another SVA cover
guidepost was used to reach that SVA cover target. For example, the report
for the SVA cover shown as ID:[7] includes the Assisted GP and GP
Radius fields. Here, the report tells you that this SVA cover was reached
from the same guidepost (gp_cover:3) that was used to falsify the
property.
The Search Radius field reports the maximum search radius used from a
guidepost looking for goals.
Distributing Magellan Engines on a Server Farm

If you use Load Sharing Facility (LSF) or Sun Grid Engine (SGE) software,
you can distribute the Magellan engines to different processors at the same
time. This can speed up performance on hard properties and help with
physical memory limitations (as evidenced by excessive swapping). It can also
improve performance on sessions with multiple properties. The minimum
supported version of LSF is 6.2 and the minimum supported version of SGE is
6.0.
If you want your distributed engine settings to be persistent, use

set_project_info commands in the Project module of your Magellan
project file to set up the configuration, as shown in Example 26.
Example 26: Project File Settings for Distributing Magellan Engines
### Project Module ###

define_project project1
# To use LSF
set_project_info -grid lsf:num -gridOpts { options }
# To use SGE
set_project_info -grid sge:num -gridOpts { options }
The argument to the -grid option takes a string (lsf or sge) to specify the
load sharing software you use. You can optionally specify how many
processors to use with the :num extension. If you don’t include the :num,

Building and Running a Session Distributing Magellan Engines on a Server Farm
Magellan uses a value of 4 by default. The legal values for num are 4, 5, 6, 7,
8, 9, and 15. If you specify 15, Magellan uses some formal engines that are
not part of the normal orchestration, so this may be a good option for
properties that do not converge using other settings.
You can add the -gridOpts option to pass any settings you customarily use
directly to the load sharing software. Make sure these are legal options for the
software you use; Magellan does not check them for correctness. You need to
escape any square brackets in the -gridOpts you specify. For example:
-gridOpts {-R "select\[mem>2000 && (linux || rhel40u4)\]"
-P proj1 -q normal}
You can also specify the same -grid and -gridOpts settings at runtime
using a run_session command. For example, if you are using SGE:
mgsh> run_session sessionName -grid sge \
-gridOpts { options }
Distributed engine options that you specify this way override any settings you
may have in your Magellan project file. With this command, Magellan uses 4
processors (the default) during the run.
If you use a run_session -grid command but do not specify -gridOpts

with the same command, Magellan uses any -gridOpts specified in your
project file.
If you specify just the -gridOpts, either in the Magellan project file or with a
run_session command, this does not imply a -grid setting. You need to
set the -grid option either in the project file or with the run_session
command to make this work.
Note To distribute Magellan engines on a server farm you must invoke MG shell on
a machine that has dispatch host authority.

Using Breakpoint Options to Control Magellan Runs

For more control over Magellan’s run behavior, you can use breakpoint
options with the run_session command. You can direct the tool to cause a
breakpoint when a certain number of random simulation cycles or cycles of
proof depth has run, properties are falsified, or a specified percentage of
coverage goal states has been determined to be reached, unreachable, or
unknown. You can also combine breakpoint options with run mode options in
the same run_session command (see “Using Run Modes to Tune
Magellan’s Run Behavior” on page 145).
When a breakpoint is reached according to the options you specify, Magellan

pauses the Run server, which in turn pauses the engines that it governs after
they complete their current tasks. The time it takes for all engines to pause is
not predictable, so you may still see messages from them. You can restart a
run after Magellan pauses at a breakpoint using the run_session
-continue command.
Note If you use the -blockMode switch with any of these breakpoint options in the
same run_session command, Magellan respects the command-blocking
feature until the breakpoint condition is met or there are no more unknowns.
You cannot use more than one type of breakpoint option in the same session
run. The syntax for specifying breakpoint options is:
mgsh> run_session sessionName -break breakpointOption
where breakpointOption is one of the following options.
{Rch=n}
Use n to specify the percentage of coverage goal states that must be reached
before Magellan pauses at a breakpoint. For example:
mgsh> run_session sessionName -break {Rch=50}

Building and Running a Session Using Breakpoint Options to Control Magellan Runs
{Unr=n}
Use n to specify the percentage of coverage goal states that must be
classified as unreachable before Magellan pauses at a breakpoint. For
example:
mgsh> run_session sessionName -break {Unr=10}
{Unk=n}
With this option, Magellan pauses at a breakpoint when the percentage of
coverage goal states classified as unknown falls below n. For example:
mgsh> run_session sessionName -break {Unk=15}
{Dep=n}
Use this option to get a report on bounded proofs when Magellan finds a proof
of n cycles depth on any property in that session. If you have multiple
properties in your session, this breakpoint condition is met when any of them
meets or exceeds the specified number of proof cycles (n). When a property is
proven for n cycles, then it is considered proven for that session. At this point,
Magellan reports the property that met the proof depth requirement and
continues to work on any other properties in that session. For example:
mgsh> run_session sessionName -break {Dep=100}
{Cyc=n}
Specify n number of random simulation cycles for Magellan to run before it
pauses at a breakpoint. Use this option only in conjunction with random
simulation mode (-mode randomSim, see “Run Random Simulation Only
Mode” on page 147) or compare-always mode (-compareAlways, see
“Checking for Mismatches” on page 461).
When you specify the {Cyc=n} breakpoint option and -mode randomSim in
the same run_session command, Magellan pauses at a breakpoint only
when the specified number of random simulation cycles (n) has run.
When you specify the {Cyc=n} breakpoint option and -compareAlways in

the same run_session command, Magellan either stops when the specified

number of random simulation cycles (n) has run or when there are no
remaining unknowns, whichever comes first. For example:
mgsh> run_session sessionName -mode randomSim -break {Cyc=300}
{P1 | P2 ... }
When you specify this option, Magellan pauses at a breakpoint when any
property used as a checker in either the P1 or P2 property modules is falsified.
Substitute the names of property modules in your project file defined for the
session you are running. You can “or” as many property modules as you want
in this option. If all the properties you test in this mode are true, the tool runs
indefinitely unless you limit the run using the -maxTime option with your
run_session command. For example:
mgsh> run_session sessionName -break {pmod1 | pmod2}
{P1 & P2 ... }

When you specify this option, Magellan pauses at a breakpoint when any
property used as a checker in the P1 and P2 property modules is falsified.
Substitute the names of property modules defined for the session you are
running. You can “and” as many property modules as you want in this option. If
all the properties you test in this mode are true, the tool runs indefinitely unless
you limit the run using the -maxTime option with your run_session
command. For example:
mgsh> run_session sessionName -break {pmod1 & pmod2}
Note The run_session command has a number of other options you can use to
control the test run. For more information, at the MG shell prompt, enter
man run_session.

Building and Running a Session Filtering and Reporting Error Messages
Filtering and Reporting Error Messages

Magellan generates lots of messages. Some of them come from the Magellan
build and run processes in MG shell (mgsh), and others from tools used under
the hood like the simulator and synthesis front-end. All of these messages
appear in the console transcript and are saved in the mgsh_messages.log file
in the project directory. But it is possible to miss messages in the transcript
that may provide important information about your run. To solve this problem,
you can filter and report the various messages using the list_msgs
command.
For example, to report all messages during or after a Magellan session build
or run, use the list_msgs command at the MG shell prompt:
mgsh(alive)...> list_msgs [sessionName]
The list_msgs command reports on the current session by default. If you

want to see messages for another session, first read the project file into MG
shell and then specify the sessionName with your list_msgs command.
Use the -type option to filter the reported messages by:

severity (error, warning, information, or note)
source (user, simulation, or goal)
user is for user-defined messages from simulation that you specify with
the add_project_info -msgTag command
simulation is for simulation messages
goal is for goal-result messages (for example, results on the properties
or coverage goals)
Each message category supported by the -type option is reported

separately. There is no correlation between the categories. To report on user
messages from within Magellan, add a message code in parentheses at the
beginning of your $display line. For example:
$display("(MY-TAG1) Main transaction started...");
Then add the following line to a Property module in your Magellan project file:
add_project_info -msgTags MY-TAG1

Filtering and Reporting Error Messages
If you want to see just error messages, use the following command:
mgsh(alive)...> list_msgs -type error
If you want to see the number of error messages, add the -count switch to
your list_msgs command. For example:
mgsh(alive)...> list_msgs -type error -count
To report on a specific message, supply the message tag. For example:
mgsh(alive)...> list_msgs -tags HVSH-120

7
Preparing Your Design
This chapter explains how to create the project’s Design module, provides guidelines for
ensuring your design uses synthesizable RTL code and compiles in Magellan, and helps you
with design elements that need special attention in Magellan.
In This Chapter
Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Describing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Finding Non-Synthesizable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Managing Non-Synthesizable Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Randomizing X Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Using Partial Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Using Verilog Cross-Module References (XMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Remodeling Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Remodeling Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Controlling Asynchronous Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Evaluating Combinational Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Working with Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Using DesignWare Components (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Initializing Verilog UDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Working with VHDL and Mixed-language Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Before You Begin
Before You Begin

Before you make any modifications to your RTL code for Magellan, confirm
the following:
The design compiles and simulates.
Magellan uses the simulator to compile and simulate generated test stimuli.
It is more efficient to compile and run the design in the simulator directly
first, rather than using Magellan to try and debug simulator compile
problems.
You also need to specify some (if not all) of the options you use to compile
and simulate the design in Magellan’s project file.
The design is essentially correct.
Verify that the clocking is correct. Verify in the simulator that when you give
the design some basic input stimulus you see the expected results at the
outputs. If the design is not basically “alive,” it is very difficult to get
meaningful results from Magellan.
The design doesn’t have undriven nets or nets that are driven by more than
one non-tristate source at the same time.
If Magellan finds a net that is not driven, it issues a warning that it is making
the net a primary input to the design. For example:
*** Warning: (HVB-130)
A primary input node was added for undriven net
’/DW_16550_wrap/Ver_mod/shift_time’. This may affect
formal search results and prevent simulation replay
of traces.
Review these warnings to ensure that these nets don’t alter the behavior of
the design. You can explicitly drive internal signals using cross-module
references (see “Driving Internal Design Signals” on page 273).
Nets that are driven by multiple non-tristate sources are typically a result of
the synthesis tool creating a netlist with multiple drivers for the same net.
This most often occurs when multiple clocked always or process blocks
are assigned to the same register. To avoid this situation, reorganize the
design code so the assignments are made in only one always block.
Top-level ports driven by a tristate source are special cases (see “Working
with Bidirectional Ports” on page 197).

Preparing Your Design Describing the Design
Describing the Design

Use Design module commands to describe the design, including the following
elements:
Design name
Top module or entity name
Elaborator name and options
Design files and compilation options
List of any include directories required by the design files
If you are using Verilog, you can use your VCS command line to specify the
design files and options. If you are using VHDL or a mixed-language design,
you can use your VCS MX command lines to specify the design files and
options, as explained in the following sections:
“Specifying Files for Verilog Designs” on page 163
“Specifying Files for VHDL Designs” on page 167
“Specifying Files for Mixed-Language Designs” on page 168
“Overriding Top-Level Verilog Parameters or VHDL Generics” on
page 170
Note For information on building partial designs in Magellan, see “Using Partial
Designs” on page 186.
Specifying Files for Verilog Designs

For pure Verilog designs, use a set_design_info -vcs command to
specify your design files and options in the same way that you do for VCS (see
Example 27). If your design contains SystemVerilog design constructs or
SystemVerilog assertions (SVAs), add the -sverilog switch to the
command line you pass to VCS.
Magellan expands environment variables in your VCS command line.

Magellan also recognizes any include directories specified in your VCS
command line with the +incdirs option and any macros defined with the
+define option.

Example 27: Using VCS Command Line

+define+ASSERT_ON -y $VCS_HOME/packages/sva
+libext+.v +incdir+$VCS_HOME/packages/sva }
The following VCS command-line options are not compatible with Magellan,
and should not be used:
+cli+n for n < 4
+acc+n for n < 2
+rad
-q
-o exe_filename
Using SystemVerilog Data Types at Top Level of Design

Magellan supports SystemVerilog data types such as structs, unions,
user-defined ports, and interfaces at the top level of the design. If you are
using interfaces at the top level, you need to specify the interface names and
modport connections using add_env_block and add_env_port
commands in the Environment module of your project file:
1 For each interface instance, use an add_env_block command to specify

the interface definition name (with -name) and interface instance name
(with -instance). For example:
add_env_block envName -name interface_definition_name \
-instance interface_instance_name
2 For each interface or modport signal referenced in the design, use an

add_env_port command to specify the port name (with -name) and what
interface instance or interface instance modport to use (with -interface).
For example:
add_env_port envName -name signal_name \
-interface interface_instance_or_modport_name

Example 28 shows a sample top-level design file that includes an interface

named simple_t.
Example 28: Top-level Design File with SystemVerilog Interface (test.sv)
interface simple_t(input wire clk, input wire rstn);

logic [3:0] in_data;
logic [3:0] out_data;
modport master(input in_data, output out_data);
modport slave (output in_data);
endinterface : simple_t
module test(input wire clk, input wire rstn,

simple_t.master biteq);
logic [3:0] lastInput;
assign biteq.out_data[0] = biteq.in_data[0] !=

lastInput[0];
lastInput[1];
lastInput[2];
lastInput[3];
always @(posedge clk) begin

if (!rstn) begin
lastInput <= 4'b0;
end
else begin
lastInput <= biteq.in_data;
end
end
endmodule
In Example 28, the test module uses a port named bitreq that is defined in
the simple_t.master interface modport.

To use the Example 28 design in Magellan, the project file looks like
Example 29.
Example 29: Magellan Project File for SystemVerilog Interface at Top Level

define_design modport -topModule test
set_design_info -vcs {-sverilog test.sv}

define_env env
add_env_port env -name clk -clock 100
add_env_port env -name rstn -reset 0
add_env_port env -name rstn -constant 1
add_env_block env -name simple_t -instance biteq

add_env_port env -name test.biteq -interface \
biteq.master

define_coverage c1
add_coverage_info c1 -signal { biteq.out_data }
### Session module###

add_session_info s1 -coverage { c1 }
In Example 29:
the add_env_block command specifies the interface definition name with
the -name option (simple_t) and the interface instance with the
-instance option (bitreq).
the add_env_port command specifies the design port used with the
-name option (test.bitreq) and the interface instance modport to use
with the -interface option (bitreq.master).
This example project (Example 29) runs a simple coverage test on the
bitreq.out_data signal.

Specifying Files for VHDL Designs

Example 30 shows Project and Design modules for a pure VHDL design. The
Project module identifies the VHDL language to use for the project. This is
necessary because Verilog is the default. Note the use of the $desDir
variable to simplify the path to the design files.
Example 30: Project and Design Modules for a VHDL Design

define_project des_proj

define_design my_design -topModule jpeg
set desDir ../VHDL
add_design_info -vhdlan { -w DesW02

$desDir/DW02_mult.vhd $desDir/DW02_mult_sim.vhd
$desDir/DW02_components.vhd }
add_design_info -vhdlan { -w WORK

$desDir/jpeg_types.vhd
$desDir/sreg_e.vhd
$desDir/sreg_a.vhd $desDir/counter_e.vhd
$desDir/counter_a.vhd $desDir/dct_input_e.vhd
$desDir/dct_input_a.vhd $desDir/dct_buffer_e.vhd
$desDir/dct_buffer_a.vhd $desDir/dct_sum_1_e.vhd
$desDir/dct_sum_1_a.vhd $desDir/dct_sum_2_e.vhd
$desDir/dct_sum_2_a.vhd $desDir/dct_mult_1_e.vhd
$desDir/dct_mult_1_a.vhd $desDir/dct_mult_2_e.vhd
$desDir/dct_mult_2_a.vhd $desDir/dct_trans_e.vhd
$desDir/dct_trans_a.vhd $desDir/dct_e.vhd
$desDir/dct_a.vhd $desDir/quantizer_e.vhd
$desDir/quantizer_a.vhd $desDir/runlength_e.vhd
$desDir/runlength_a.vhd $desDir/dc_encode_e.vhd
$desDir/dc_encode_a.vhd $desDir/ac_encode_num_e.vhd
$desDir/ac_encode_num_a.vhd
$desDir/ac_encode_end_e.vhd
$desDir/ac_encode_end_a.vhd $desDir/ac_encode_e.vhd
$desDir/ac_encode_a.vhd $desDir/compress_e.vhd
$desDir/compress_a.vhd $desDir/huffman_e.vhd
$desDir/huffman_a.vhd $desDir/jpeg_e.vhd
$desDir/jpeg_a_sc.vhd }

Use add_design_info -vhdlan commands in the Design module of your

project file to list the design files. Magellan uses the vhdlan -w option to pick
up the name of your logical library. If you do not specify a logical library for a
-vhdlan command, the default is WORK.
VHDL Source File Automatic Ordering

Magellan automatically determines VHDL source file analysis order
dependencies within each add_design_info -vhdlan command. It is an
error to specify more than one logical library for a single add_design_info
-vhdlan command. If you are using more than one logical library, make sure
the libraries are compiled in the correct order, as per the LRM ordering rules.
Magellan does not merge multiple add_design_info -vhdlan commands,
even if the target logical libraries are the same.
You can use wildcards to specify the list of VHDL source files, as shown in the
following examples:
add_design_info -vhdlan { -w first_lib_name *.vhd }
add_design_info -vhdlan { -w second_lib_name t*.vhd }
Note Be careful when using wildcards to specify design files. If more than one entity
with the same name is found, you get a compilation error.
Use a define_design -topModule command in the Design module of

your project file to identify the top-level design entity.
Specifying Files for Mixed-Language Designs

For mixed-language designs, use add_design_info -vhdlan and
-vlogan commands in the Design module of your project file to specify your
design files and compile options. Magellan passes any options you specify
directly to the simulator without checking for correctness, so you can
copy-and-paste your vhdlan and vlogan command lines directly from your
build scripts into the Magellan project file. The compile switches that you
specify with each -vhdlan or -vlogan command apply only to the files in
that list. Magellan uses the vhdlan -w option to pick up the name of your

logical library for VHDL design files. If you do not specify a logical library for a
-vhdlan command, the default is WORK.
Use a define_design -vcs or -scs command in the Design module of

your project file to identify any elaborator options. You don’t need to specify
the -mhdl elaborator switch because Magellan sets it by default for
mixed-language designs.
Note VCS MX supports specific data type mappings for port declarations used in
mixed-language instantiations and performs some data type conversions
automatically. For details, see the VCS MX User Guide located in
$VCS_HOME/doc/UserGuide/vcsmx_ug.pdf.
Specifying Verilog-Top Designs

Use add_design_info -vlogan commands to specify your Verilog design
files and options and add_design_info -vhdlan commands to specify
your VHDL design files and options. You need to use one -vlogan or
-vhdlan command for each subtree in the design, and they must be listed in
the correct compilation order. Use a define_design -vcs command to
specify any elaborator options (see Example 31).
Example 31: Specifying Verilog-Top Designs

define_project ver_top

define_design des -topModule verilog_top -vcs “options”
add_design_info -vhdlan { -w WORK subtree_file.vhd }
add_design_info -vlogan { top_file.v }
Specifying VHDL-Top Designs

Use add_design_info -vhdlan commands to specify your VHDL files
and options and add_design_info -vlogan commands to specify your
Verilog design files and options. You need to use one -vlogan or -vhdlan
command for each subtree in the design, and they must be listed in the correct
compilation order. Use a define_design -scs command to define any

elaborator options. You do not need to specify the top-level entity with -scs
because Magellan gets that information from the -topModule option in the
same project file command (see Example 32).
Example 32: Specifying VHDL-Top Designs

define_project vhdl_top

define_design des -topModule vhdl_top -scs “options”
add_design_info -vlogan { subtree_file.v }
add_design_info -vhdlan { -w WORK top_file.vhd }
Specifying Compile and Runtime Simulator Options

Add compile and runtime options to the command lines for VCS or VCS MX
that you specify with the define_design or set_design_info command
in the Design module of your project file.
Overriding Top-Level Verilog Parameters or VHDL

Generics
If you need to override the values of any top-level Verilog parameters or VHDL
generics in your design, use a set_design_info -parameters command
in the Design module of your Magellan project file.
For example, to override a parameter or generic port named depth in your

top-level Verilog module or VHDL entity, use the following command:
set_design_info -parameters {depth=16}
If you want to override multiple parameters, separate them by blank spaces,

as shown in this next example:
set_design_info -parameters \
{param1=100 param2=200 param3=100}

Preparing Your Design Building the Design for the First Time
Building the Design for the First Time

This section describes how to create a project file with the minimum amount of
information so you can build the design. There are two benefits to building the
design before you complete an Environment module:
You resolve any build problems with the design as early as possible.
When you successfully build the design, Magellan generates simulation
scripts that may be helpful in developing the environment.
Describing a Minimal Environment

To compile your design in Magellan, you must specify a minimal environment
(see “Preparing the Environment” on page 205). The minimum environment to
build the project for most designs includes the following elements:
An environment name
Declaration of the clock signal
Declaration of the reset signal
To build the design and resolve build errors, you can ignore multiple clocks
and complex reset sequences. Example 33 shows an example environment
module.
Example 33: Environment Module

define_env env_1 -timeUnits 100ps
add_env_port env_1 -name clk -clock 100
add_env_port env_1 -name rst_n -reset 0
add_env_port env_1 -name rst_n -constant 1

Building the Design for the First Time
If you use a specific time unit for your design, declare it with the
define_env -timeUnits command. The default time unit in Magellan is
100 ps. Specify the clock period in terms of the time unit.
Note If your design is written in VHDL, specify the time unit as 1s, 1ms, 1us, 1ps,
1ns, or 1fs. For example, if delays in the design are in nanoseconds, specify
-timeUnits 1ns in the project file.
When Magellan runs the simulator, it uses the options listed with the VCS or
VCS MX command lines you specify with the define_design or
set_design_info commands in the Design module of your project file. For
the best simulation performance, always use the +notimingcheck option.
Magellan needs to know about the clock and reset ports on your design.
Declare them with the add_env_port command (see Figure 33 on
page 171).
Note If you specify Verilog escaped identifiers with the add_env_port command,
be sure to escape the escape (for example, \\n) if your signal name matches
any of the Tcl backslash substitutions.
Adding a Session
You need a Session module in the project file to build the simulation
environment. A minimal session requires a name and an environment. In the
following example, session cov is created using the env_1 environment.
define_session cov -env env_1
You now have enough information to build the design and resolve any build
errors (see “Building a Session” on page 134).

Preparing Your Design Finding Non-Synthesizable Code
Finding Non-Synthesizable Code

The design files processed by Magellan’s Formal build must contain
synthesizable code (see “Understanding the Build Process” on page 135).
There are a few places where non-synthesizable code frequently appears in a
design. The following sections explain how to find non-synthesizable code and
modify it so that Magellan can process your design.
“Synopsys Translate Directives” on page 173
“ASIC Libraries” on page 174
“VHDL VITAL Components” on page 175
“Other Non-Synthesizable Code” on page 175
Synopsys Translate Directives

Search for code that is bracketed by synopsys translate_off and
synopsys translate_on directives. For example:
Verilog:
// synopsys translate_off
...code ignored by synthesis...
// synopsys translate_on
VHDL:
-- synopsys translate_off
-- synopsys translate_on
This tells the synthesis tool to ignore code between the directives. Magellan
also ignores the code between these comments for the Formal build.
However, Magellan’s Simulation build includes this code (see “Understanding
the Build Process” on page 135).

Finding Non-Synthesizable Code
For Magellan to do any meaningful validation, the code inside these directives
must not be a critical part of the design’s functionality. This code should only
monitor the design or check a property, as shown in Example 34.
Example 34: Synopsys Translate Directives
for (j = 0; j < ‘cam_line_num; j = j + 1) begin

write_2_replace = ~hit & over_write & (token == j);
if (‘verbose_over_write & write_2_replace)
$display(“CAM Error: over write!”);
write_control(j) = write_nice(j) | write_2_replace;

end
When functionally significant code is contained inside Synopsys translate

directives, mismatches can occur between the behavior of the RTL and formal
models. Mismatches can reduce or eliminate Magellan’s verification
effectiveness (see “Detecting Simulation/Synthesis Mismatches” on
page 457).
If the code within translate directives is a functional part of the design, or you
want to use the checker code in Magellan to formally prove a property, see
“Managing Non-Synthesizable Code” on page 176.
ASIC Libraries
ASIC libraries often use non-synthesizable code to describe the behavior of
technology cells. This is only an issue for Magellan if a cell is instantiated in
the design. When a cell is instantiated in the design, Magellan searches for
the component’s code in the ASIC library and includes it in the build.

Preparing Your Design Finding Non-Synthesizable Code
If you instantiate ASIC library components that use non-synthesizable code,

you get unlinked cell errors when you build the design in Magellan. For
example:
*** Error: (HVB-004)
8 unlinked cells found during elaboration: These are
listed as ’Cannot link cell’ or ’Cell will be treated as a
black box’ warning messages in the HDL compiler output.
For more information, see “Managing Non-Synthesizable Code” on page 176.
VHDL VITAL Components

VHDL Initiative Toward ASIC Libraries (VITAL) components are not
synthesizable, and therefore cannot be used with Magellan. Replace VITAL
components with equivalent synthesizable models.
Other Non-Synthesizable Code

It is possible that non-synthesizable code exists in other parts of your design.
To find such non-synthesizable code, run the design through a synthesis
policy checker tool (such as Leda) to ensure that it conforms to synthesis
rules.

Managing Non-Synthesizable Code

There are several ways to manage non-synthesizable code so that the design
compiles in Magellan:
Rewrite the code so that it is synthesizable (see “Rewriting Code” on
page 176).
Add ‘ifdef compiler directives that preserve the existing code and use
alternate synthesizable code for Magellan. This only applies to Verilog
designs (see “Adding ‘ifdef Compiler Directives (Verilog only)” on
page 176).
Remove the code from evaluation (see “Treating Non-Synthesizable Code
as a Black Box” on page 178).
Comment the code so that it is ignored by both the synthesis tool and
Magellan (see “Removing Non-Synthesizable Code with Compiler
Directives” on page 184).
Rewriting Code
Rewriting the non-synthesizable code ensures that Magellan evaluates a
complete design with all the available environmental information.
If you have not synthesized the design yet, use a synthesis policy checker tool
(such as Leda) to determine if the code is synthesizable.
Make sure the new code is functionally equivalent to the previous description.
You can temporarily add a compiler directive that enables you to switch
between the old and new code and compare the simulation results.
Adding ‘ifdef Compiler Directives (Verilog only)

Adding the Verilog ‘ifdef compiler preprocessor directive enables you to
keep the existing code for its original purpose while writing synthesizable code
for Magellan.

Preparing Your Design Managing Non-Synthesizable Code
This methodology is valuable for many reasons, a few of which are listed
below:
If timing issues are a concern, you can continue to use the original
non-synthesizable code when you simulate your design. Magellan does not
use timing information. It evaluates the design based on clock cycles.
You can validate whether the remodeled code is functionally equivalent to
the original code.
Use the +define option in VCS to toggle between the two code versions.
This may be a good temporary strategy until you’ve confirmed the
remodeled code is equivalent to the original. You can then remove the
compiler directive and the original non-synthesizable code.
Example 35 uses the ‘ifdef compiler directive to replace non-synthesizable

code with synthesizable code for Magellan.
Example 35: ifdef Compiler Directive (Sheet 1 of 2)
always @(posedge clk or negedge reset_)

begin
//Code modeled for Magellan

‘ifdef MAGELLAN
if (~reset_)
rstate <= 3’b0;
else if (state_clr)
rstate <= 3’b0;
else begin
if (stat_mask[0]) rstate[0] <= 1’b1;
end
//Original non-synthesizable code

‘else
begin
if (~reset_)
rstate[0] <= 0;
else if (state_clr)
rstate[0] <= 0;
else if (stat_mask[0])
rstate[0] <= 1;
end

Example 35: ifdef Compiler Directive (Sheet 2 of 2)
begin
if (~reset_)
rstate[1] <= 0;
else if (state_clr)
rstate[1] <= 0;
rstate[1] <= 1;
end
begin
if (~reset_)
rstate[2] <= 0;
else if (state_clr)
rstate[2] <= 0;
rstate[2] <= 1;
end
‘endif
end
In the Magellan project file, define the MAGELLAN macro along with your
set_design_info -vcs or add_design_info -vhdlan commands.
This macro is used by both the Simulator and Formal builds.
Treating Non-Synthesizable Code as a Black Box

You can use black boxes to remove specified portions of your design from
consideration in Magellan. Magellan treats the outputs of a black box as
primary inputs to the design and leaves the inputs to a black box dangling.
Magellan allows you to specify a list of modules, entities, or instances as black

boxes. If you specify a module or entity, all instances of that module/entity are
treated as black boxes.
Use this methodology with caution. Black boxes can change verification
results by introducing false negatives for properties specified in other portions
of the design. This is only a problem if the black box has significant outputs
that affect portions of your design where you are trying to prove or falsify
properties.

To specify a list of modules or entities to be handled as black boxes, use an

add_design_info -blackBoxes command in the Design module of your
project file:
add_design_info -blackBoxes {ram_rw_129x16k ram_rw_32x8k}
If you want to create a black box for a specific instance of a module, specify
the full hierarchical path to the instance:
add_design_info -blackBoxes {top.cache2.tag_mem}
You can also use the wildcard (*) to make Magellan create black boxes for all
modules or entities found in files that match that regular expression. For
example:
add_design_info -blackBoxes {ram_*}
If you specify a black box for a module, entity, or instance that does not exist in
the design (perhaps you did not list the file), Magellan treats the unresolved
cell as an implicit black box for the formal model, but the simulation model fails
to build and you get an error message.
Another more subtle cause of unresolved designs is when the design files
specified for the formal model build differ somehow from the files used for the
simulation model. For example, maybe you have a macro defined using a
compiler option that brings in simulation-only code for the simulation model
build. But this code won’t build for the formal model because it is not
synthesizable. In this case, Magellan issues a warning message about
unlinked cells and creates an implicit black box for the unresolved portion of
the design in the formal model.

Controlling Internal/Black Box Signals

In Magellan, all black box methodologies create output signals that become
unconstrained “free” inputs to the formal model.
Note that large numbers of unconstrained free variables can slow simulation
performance considerably, because Magellan has to force random values into
the simulation model for all those signals to match the formal model. In
extreme cases, where there are many thousands of unconstrained free
variables, it is even possible to mask the effectiveness of the run_session
-maxTime command, because the time required to force the random values is
greater than the maximum time set up for the session.
One way to solve this problem is to attach outputs of black box instances to
constraint model outputs using cross-module references. You can set the
value of a black box output from a generator-style constraint model using a
cross-module reference that you establish with the add_env_connect
command in the Environment module of your project file:
add_env_connect env -connect {mydesign.ila.intsig
myConst.sigB}
For more information on cross-module references, see “Using Cross-Module

References” on page 271. You can also connect checkers to the inputs of
black box instances using cross-module references.
Another approach is to specify the values for black box output signals using
add_env_port commands. You can use an add_env_port command to
set instance-specific internal signals to constant or random values, and
specify a different value for reset, as shown in the following examples. Note
that paths to internal signals are case-sensitive and use the dot (.) to
separate different levels in the hierarchy. This applies to both Verilog and
VHDL designs.
To set the value of a black box output or other internal signal to a constant
value:
add_env_port envName -constant 0 -name mydes.ila.intsig

To force a two-dimensional array element to a random or constant value,

specify the full range definition, as shown in the following example:
add_env_port envName -name mem[20][7:0] -constant 8'd25
This example forces memory cell 20 to a constant value of 25 for random

simulation.
To set the value of a black box output or other internal signal to a constant
value for reset:
add_env_port envName -reset 1 -name mydesign.ila.intsig
You don’t need to set black box outputs to random values because that’s what
the tool feeds them by default. However, this can be a useful technique for
other internal signals. To set the value of an internal signal to random values:
add_env_port envName -random -name mydesign.ila.intsig
For information on using wildcards to specify signal names with the

add_env_port -name command, see “Setting Internal Signals to
Constants” on page 257.
Understanding “forces” in RTL Simulation Models

When you set values for black box output signals in your formal model as
described in “Controlling Internal/Black Box Signals” on page 180, Magellan
also modifies the corresponding RTL simulation model to force black box
output signals to values that match what you specified for the formal model.
These forces override any other drivers for these signals in your design. This
tool behavior helps reduce mismatches between the formal model and the
RTL simulation model. To see what values Magellan is forcing on black box
outputs for your simulation model, use a report_session -blackbox
command:
mgsh (alive ...)> report_session -blackbox

This command prints the Black Box and Forced Signals Report on the screen
(see Figure 18). The report is also stored in the user directory after you run a
session:
mg_sessionName/user/forcedSignals.log
Figure 18: Black Box and Forced Signals Report Example (forcedSignals.log)
# Black Box Section:

B R Y DW8051_op_decoder DW8051.i_core.i_cpu.i_opdec
# Forced Signals Section:

0 1 des_chip.u_des_io.core_rst_st
0 0 des_chip.u_des_io.core_i_trdy_dd
1 1 des_chip.u_des_io.core_i_rdata_dd[0]
1 1 des_chip.u_des_io.core_i_rdata_dd[1]
F 1 des_chip.u_des_io.core_i_rval_dd
F 1 des_chip.u_des_io.o_tval_dd
S S des_chip.u_des_io.core_i_addr[0] driver.core_i_addr[0]
F 0 des_chip.u_des_io.o_rrdy_de
F 0 des_chip.u_des_io.core_i_rval_de
F 0 des_chip.u_des_io.core_i_trdy_de
The Black Box Section of the report contains a list of black boxes that
Magellan identified in the design. You may have created black boxes explicitly
using an add_design_info -blackBoxes command (see “Treating
Non-Synthesizable Code as a Black Box” on page 178) or as a side-effect of
testing a partial design (see “Using Partial Designs” on page 186).
Note If a module shows up as unresolved (U) in the Black Box Section of the report
(see Table 5), that means there is no definition for that module in the design
files specified in your project file.

Table 5 explains how to read the Black Box and Forced Signals Log report.
The fields appear from left to right in the report in the order presented.
Table 5: Black Box and Forced Signals Log Report Decoder
Report Section Field Meaning Values
Black Box B Module was black boxed B is the only value
Black Box <resolution> Shows the resolution status U = unresolved

in the design R = resolved
Black Box <user> Shows if this is a Y = yes

user-specified black box N = no
Black Box <name> Lists the module/entity that Design-dependent

was black boxed
Black Box <instance_path> Lists the instance path to the Design-dependent

black box
Figure 18: B R Y DW8051_op_decoder DW8051.i_core.i_cpu.i_opdec
This module was black boxed (B), resolved (R) in the design, and user-specified (Y).
Forced Signals <simulation_value> Shows the value used in 0 = logic 0
simulation 1= logic 1
F = free variable
S = driven by
<driving_signal>
Forced Signals <reset_value> Shows the value used during 0 = logic 0

reset 1= logic 1
S = driven by
<driving_signal>
Forced Signals <internal_signal_name> Lists the internal signal to be Design-dependent

forced
Forced Signals <driving_signal> Lists the driving signal to be Design-dependent.

used to force the value for Not present if no
the <internal_signal_name> <driving_signal>
Figure 18: S S des_chip.u_des_io.core_i_addr[0] driver.core_i_addr[0]
Signal des_chip.u_des_io.core_i_addr[0]is being driven by

driver.core_i_addr[0] in simulation (first S) and during reset (second S).

These forces on black box output signals for your RTL simulation model
effectively mask off the affected inputs from upstream portions of your design,
as shown in Figure 19.
Figure 19: Effect of Forces on RTL Simulation Model
Signal masked off
A
X C
B
Removing Non-Synthesizable Code with Compiler

Directives
You can remove non-synthesizable code using the Synopsys translate
directive. This removes the code from the formal model, but keeps it for
simulation. For example, in Verilog:
Be careful not to introduce a mismatch between the behavior of the RTL

simulation model and the formal model. For more information about the
consequences of removing non-synthesizable code, see “Synopsys Translate
Directives” on page 173.
If any of the code within a translate_off ... translate_on region makes

assignments to signals that affect the functionality of the circuit described
outside of that region, there is the potential for mismatches between the
behavior of the simulation and formal models. For information on how to set
values for these signals, see “Controlling Internal/Black Box Signals” on
page 180.
If you remove an entire module using the Synopsys translate pragmas, this
effectively black boxes that module from the design.

Preparing Your Design Randomizing X Values
If you black box a module using this strategy:

module test (...);
...
endmodule
do not use an add_design_info -blackBoxes command for that same

module. It is already black boxed by the Synopsys translate pragmas.
Randomizing X Values
In normal operation, when Magellan finds signals that are explicitly assigned X
values in the design, it optimizes them away as “don’t cares” in the formal
model. However, these X assignments remain in the RTL model as unknowns.
This can lead to simulation/synthesis mismatches if the X assignments occur
during simulation (see “Detecting Simulation/Synthesis Mismatches” on
page 457).
You can preserve explicit X assignments (don’t cares) in the formal model
build so that they become free inputs which take random values. To run
Magellan with X value randomization, add the -xRandom switch to your
define_design command in the Design module of your project file. For
example:
define_design myDesign -topModule top -xRandom
You can also use a set_design_info command to set this up. Here, the
-xRandom option takes a Boolean argument (1 or 0). For example:
set_design_info -xRandom 1
When you run Magellan using the -xRandom build switch/option, the tool runs
only the formal engines. There is no random simulation or trace replay in the
simulator. Instead, Magellan generates a formal VCD file for any property
falsifications.
To get a report on all don’t cares resulting from explicit X assignments in your
design, use a report_session -xRandom command at the MG shell
prompt after your build completes. For example:
mgsh(alive...)> report_session -xRandom

Using Partial Designs
Using Partial Designs

You can specify all design files for an area of the DUT that you want to test
with Magellan, but not list files for other portions of the design that would
normally be required for a successful build. Magellan treats areas of the
design whose source files are not specified as black boxes (see “Controlling
Internal/Black Box Signals” on page 180). To enable a partial build for your
design, use a define_design -partialDesign command in the Design
module of your Magellan project file.
Note If you do not use the -partialDesign switch and any modules or entities
required to elaborate the design are missing from the source file list, Magellan
issues an error message and stops the build.
When you use the -partialDesign switch for your build, the following
features apply:
Circuit elements that have unresolved module/entity definitions after
synthesis are removed.
The forceSignals.log report shows the instances that were black boxed due
to missing module or entity declarations (see Figure 18 on page 182).
The forcedSignals.log report lists the signals that are now unconstrained
free variables due to missing design instances.

Preparing Your Design Using Verilog Cross-Module References (XMRs)
Using Verilog Cross-Module References (XMRs)

Although Verilog cross-module references (XMRs) are not synthesizable, you
may use them in verification-only code that is part of the design you want to
test with Magellan.
Magellan can handle XMRs as long as they are used only for read access. In
procedural code, you can use XMRs only on the right-hand side of an
expression.
Note The only SystemVerilog data types that are supported with XMRs are bit and
logic.
When Magellan detects XMRs in your design, it issues a message to let you
know that an additional recompilation of the HDL is needed:
*** Information: (HVB-931)
XMR signals detected, HDL database being recompiled.
If you have multiple instantiations of modules that contain XMRs in your

design, there is the potential for mismatches on signal widths. This can
happen if you use parameters (such as weight) to define values for different
module instances. When Magellan detects multiple module instances with
XMRs, it issues a warning message:
XMR Processing: <#> instances found for module
'<module_defname>'. Using instance <instance_path>
for determining scope of XMR signal '<xmr>'.
To prevent potential mismatches, use the same values for parameters in

multiple module instantiations that contain XMRs.

Remodeling Memory
Remodeling Memory
Most on-chip memories are developed using vendor-specific libraries and
tools. These tools typically provide a behavioral description of the memory for
simulation and a database file for use by the synthesis tool.
The behavioral description is often not synthesizable. Magellan needs a

synthesizable version that describes both the behavior and the interfaces.
It is usually a simple task to remodel the memory. Much of the information in

the original model is not required for Magellan. Magellan only needs a
cycle-based abstraction of the memory; no timing or X-handling behavior is
required.
Example 36 shows a typical memory model written in Verilog. Example 37

shows a similar memory model written in VHDL. These examples limit the
address range and show that Magellan handles tristate output buses.
Example 36: Magellan-Compatible Verilog Memory Model
module spram (CLK, CEN, WEN, OEN, A, E, Q);

input CLK;// Positive edge trigger clock
input CEN, WEN, OEN;// Active low control signals
input [10:0] A;// Address range 0..1500
input [31:0] E;// 32-bit data input
output [31:0] Q;// 32-bit tristate data output
reg [31:0]mem [1599:0];
wire [10:0]A_in;
reg [31:0]Q_reg;
assign A_in = (A < 1600) ? A : 11'd0;
always @ (posedge CLK) begin

if (~CEN & ~WEN) begin
mem[A_in] <= E;// Write to memory
Q_reg <= E;// Data write through
end
else if (~CEN & WEN)
Q_reg <= mem[A_in];// Read from memory
else
Q_reg <= Q_reg;// Nop
end
assign Q = (~OEN) ? Q_reg : 32'bz;// Tristate buffer
endmodule

Preparing Your Design Remodeling Memory
Example 37: Magellan-Compatible VHDL Memory Model
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity memory is
port (
CEN, WEN, OEN, clock : in std_logic;
A : in std_logic_vector (10 downto 0);
D : in std_logic_vector (31 downto 0);
Q : out std_logic_vector (31 downto 0));
end memory;
architecture rtl of memory is

type mem_type is
array (1599 downto 0) of std_logic_vector (31 downto
0);
signal mem : mem_type;
signal A_in : std_logic_vector (10 downto 0);
signal Q_reg : std_logic_vector (31 downto 0);
begin
A_in <= A when (A < 1600) else (others => '0');
Q <= Q_reg when (OEN='0') else (others => 'Z');
mem_proc: process (clock) begin
if (clock'event and clock='1') then
if ((CEN='0') and (WEN='0')) then
-- write to memory
mem(conv_integer(A_in)) <= D;
-- data write through
Q_reg <= D;
elsif ((CEN='0') and (WEN='1')) then
-- read from memory
Q_reg <= mem(conv_integer(A_in));
else
-- Nop
Q_reg <= Q_reg;
end if;
end if;
end process;
end architecture;

Remodeling Latches
Remodeling Latches
To improve its capacity to handle large latch-based design blocks, Magellan
automatically remodels safe latches in the formal model of your design.
Magellan does not alter your RTL during this process.
A safe latch is defined as one in which every sequential feeding into the
combinational logic driving the latch is on a different phase of the clock than
the latch being examined.
With unsafe latches that are driven by the same phase of the same clock, data
can ripple through multiple latches. Unsafe latches can also cause
simulation/synthesis mismatches (see “Detecting Simulation/Synthesis
Mismatches” on page 457).
Magellan generates information messages when it finds unsafe latches in your

design (see Figure 20).
Figure 20: Unsafe Latch Warning Message
*** Information: (HVNL-407)

375 unsafe latches found in Design:mm_dc_dcu
ReportFile: /project/mg_scan_session/user/latchRemodelWarning.log
You can find these information messages in the latchRemodelWarning.log file

in the mg_sessionName/user directory. In some designs unsafe latches may
be intentional, but it is a good idea to review these information messages and

Preparing Your Design Remodeling Latches
remodel any unsafe latches as appropriate. Figure 21 shows an example of

the latchRemodelWarning.log file format.
Figure 21: Example latchRemodelWarning.log File Format
F: flip-flop
L: latch
Pos: Positive
Neg: Negative
warning: SEQ m0_whi_lft_c_a_v2<3> have fanin SEQs with

both edges.
SEQ m0_whi_lft_c_a_v2<3> (L,Neg) fanin SEQs: Safe
SEQ mdb_dcu_m0_ld_hit_me2a_l_mmin_reg(F,Pos)
SEQ m0_lfsel_com_lft_me2b(L,Neg)
Unsafe
SEQ m0_wordhi_ld_lft_me2b(L,Neg)
For the SEQ m0_whi_lft_c_a_v2<3> latch to be safe, all the sequentials in

the fanin would have to be active on the positive phase of the clock, but there
are two latches in the fanin that are active on the negative phase of the clock.

Controlling Asynchronous Latches
Controlling Asynchronous Latches

Magellan requires that asynchronous latches driven by primary inputs be
constrained so that there are no input changes on the primary inputs when
such latches are open. This is to make sure the behavior of the formal and
simulation models stays in sync. Otherwise, you may see replay misses or
other simulation/synthesis mismatch problems. See “Detecting
Simulation/Synthesis Mismatches” on page 457.
When Magellan detects a primary input directly driving an asynchronous latch,

it issues a message similar to the following:
2 latches found where asynchronous input of latch is
driven directly by primary input. This may cause replay
misses during simulation.
ReportFile:/MG/stabilityConstraint/mg_s1/user/latch.rpt
Magellan can automatically apply SVA stability constraints to such

asynchronous latches when necessary. To turn on automatic stability
constraints, use a set_env_info command in the Environment module of
your project file. For example:
set_env_info -stability 1
With this setting in place, Magellan uses SVA stability constraints under the
hood to stabilize primary inputs that drive asynchronous latches directly. To
turn off automatic stability constraints, set the -stability option to 0 (this is
the default). For example:
set_env_info -stability 0
An alternative method of preventing unwanted input transitions while latches

are open is to add flip-flops to the primary inputs. However, the stability
constraints methodology offers advantages over that technique:
It should not interfere with other assertion-style constraints applied to the
same primary inputs.
It doesn’t add to the sequential depth of the design.
Because automatic stability constraints are active on both edges of the clock,
it is possible to run into dead-ends if you have another constraint for the same
signal that is active on only one edge of the clock. If you encounter this

Preparing Your Design Evaluating Combinational Feedback Loops
problem, revise the conflicting constraint so that it is also active on both edges
of the clock. For more information, see “Avoiding Dead-End States” on
page 292
Evaluating Combinational Feedback Loops

In general, Magellan cannot handle designs with combinational loops, where a
combinational loop is defined to have a signal path that only propagates
through combinational design elements back to itself. However, Magellan can
handle non-state-holding combinational loops. A combinational loop is
considered non-state-holding if the output is only a function of the current
inputs and not any previous values.
For example, Magellan can validate the loop shown in Figure 22. The blocks
labelled F and G have only combinational design elements. The feedback nets
are labelled fb.
Figure 22: Non-state-holding Combinational Feedback Loop
0
FF .
1
fb
X . 0
Y
1
0 fb
1
G .
mode . .
Figure 22 implements the following expression:

Y = mode ? F(G(X)) : G(F(X));

The design shares F and G so that only one copy of each is needed. The
implied mux ensures that the input X never loops through F and G at the
same time. The output Y is only a function of the current value of X and mode,
not any previous values.
An example of a state-holding combinational feedback loop is the loop created

between two NAND gates that make up a flip-flop, as shown in Figure 23.
Figure 23: State-holding Combinational Feedback Loop
S . y
R
. y’
This set-reset (SR) flip-flop remains in one state indefinitely until it is directed
by an input signal to do otherwise. A signal at the S input sets the flip-flop to
the logic 1 state (y=1). A signal at the R input resets the flip-flop to the logic 0
state.
When Magellan finds a combinational feedback loop, it issues the following

message:
*** Information: (HVNL-405)
Asynchronous loops found in Design:rma_top
ReportFile:/rma_top/mg_p3_cov/user/loops.rpt
Magellan cannot determine if the loop is state-holding or not, so it assumes

the loop is non-state-holding. You need to determine if the loop is
state-holding or non-state-holding.
Use the information in the mg_sessionName/user/loops.rpt file to find the

combinational loops in your design. If the loop is non-state-holding, Magellan’s

Preparing Your Design Evaluating Combinational Feedback Loops
treatment of the loop is transparent and you can be confident that the loop
does not adversely affect the reported results.
If your design has state-holding combinational feedback loops, Magellan’s

treatment of the loop may result in failure to prove properties that otherwise
might be proven.
Magellan may also generate traces that do not reach the target state when
they are replayed in the simulator. In this situation, you get replay misses. See
“Responding to Replay Misses” on page 462. You may also see warning
messages about replay assignments to artificial inputs. For example:
*** Warning: (HVSI-041)
Unable to drive:0 to un-bound port: qrz_ac
For Magellan to correctly evaluate your design, you need to remove

state-holding loops. Even if the design has state-holding loops, when
Magellan proves a property in this situation, it remains a valid proof.
Understanding the Combinational Loops Report

When Magellan finds a combinational loop, it:
Identifies groups of interacting, or overlapping combinational loops in the
design and labels them as Strongly Connected Components (SCC).
Identifies a minimal number of points needed to break all the loops in the
SCC.
Makes the breakpoints into artificial primary inputs to the formal model of
the design, and unrolls the logic of the SCC.
Prints a message and directs you to the loops.rpt file, located in the
mg_sessionName/user directory.
The format of the loops.rpt file is a series of SCC (strongly connected

components) blocks, where an SCC block looks like the following:
SCC: #
Node: name
...
nNode: summary
LoopPi: location
...

Each SCC found in the design is numbered in the report.
Following the SCC statement are a series of Node statements. Each Node
statement identifies a structural node in the formal model that is in the SCC.
Some of these nodes can be mapped back to the simulation model. However,
not all nodes can be mapped to the RTL model. The Node statements end
with a summary line indicating the number of nodes, the number of snip
points, and the number of copied nodes.
Following the Nodes are a series of LoopPi statements that identify places
where the SCC was snipped. These nets then become artificial inputs to the
design. The names are relative to the formal model and may or may not map
back to the RTL model. Figure 24 shows part of a loops.rpt file.
Figure 24: Loops.rpt File
SCC: 1
Node:/asyncLoop/f/C2/C0/N0
Node:/asyncLoop/f/C2/N2
Node:/asyncLoop/f/N22
Node:/asyncLoop/f_out<0>
Node:/asyncLoop/g_sel/N1
Node:/asyncLoop/g_sel/N2
Node:/asyncLoop/g_in<0>
...
nNodes=159 nSnip=4 nNew=636
LoopPi:/asyncLoop/__LoopIn_/asyncLoop/f_out<3>
LoopPi:/asyncLoop/__LoopIn_/asyncLoop/g_sel/N5

Preparing Your Design Working with Bidirectional Ports
Working with Bidirectional Ports

Bidirectional ports at the top level of the design under test need special
attention if the tristate nets connected to the bidirectional ports have internal
drivers. Bidirectional signals internal to the design do not require special
attention.
Automatic Constraint of Bidirectional Ports

When a tristate net is connected to a top-level bidirectional port or input port,
Magellan drives random stimulus to that port during cycles when no internal
drivers of that net are active. These automatic constraints can reduce the
number of bus contention and floating bus events. However, if there is a bug
that causes the internal driver to be active at the wrong times, the automatic
constraint applied by Magellan may hide that or other bugs. Therefore,
Magellan issues a warning message when it applies this type of constraint
(see Figure 25).
Figure 25: Bidirectional Port Automatic Constraint Warning
*** HVB-233 (warning)

Automatic constraint of top-level bidirectional ports;
see the ‘Magellan User Guide’ and forcedSignals.log
report: '%s'.

Working with Bidirectional Ports
You can use the forcedSignals.log report that Magellan stores in the
mg_sessionName/user directory after you run a session to review the list of
affected bidirectional ports (see Figure 26).
Figure 26: Top-level Bidirectional Port Section of forcedSignals.log Report
# Top-level Bidirectional Port Section:

# T <top-level bidirectional port>
# G <top-level bidirectional port NOT automatically
constrained>
G top.tt[3]
T top.tt[2]
T top.tt[1]
T top.tt[0]
T top.triseq[1]
T top.triseq[0]
Using a Template to Write your own Constraints

You may want to create your own constraint that precisely defines when the
bidirectional port should be driven with random values (that is, when it is not
legal for the design to drive the port). This requires some white-box knowledge
about the design.
Magellan creates a random driver template that you can use to create a
constraint model which resolves driver conflicts. Copy the design_driver.v or
design_driver.vhd template file from the mg_sessionName/user directory to
another location so that Magellan doesn’t overwrite it on the next session run,
and modify it to drive Z when the internal driver is enabled.
Bidirectional design ports are listed as comments in the template file, as

shown in Example 38. Remove the comment marks from the assignment
statement to modify the port, and delete the uncommented line at the end of
this example. You need to add code to the template to specify when the
external random driver is active.
Example 39 shows the Magellan project file commands to add the template to
your environment. In this Verilog-only design example, mux.v is the design
under test and mux_driver.v contains the random driver template. If you
are testing a mixed-language design, use an add_design_info -vlogan
command instead to specify the random driver template file.

Preparing Your Design Working with Bidirectional Ports
Example 38: Bidirectional Port Comments
//bidirectional port may require enable to function properly

//assign portA = <enable>?rand_portA : 1’bZ;
assign portA = rand_portA
Example 39: Random Driver Template in the Environment Module

define_design des -topModule mux
set_design_info -vcs {mux.v mux_driver.v}

# Connect design reset to reset in driver template

add_env_port env_1 -name rst_n -sysReset
# Name the driver template

add_env_block env_1 -name mux_driver
# Connect design clock to clock in driver template

add_env_connect env_1 -connect { mux.clk
mux_driver.clock }

Using DesignWare Components (Verilog only)
Using DesignWare Components (Verilog only)

If you have DesignWare Foundation Library components instantiated in the
design you are testing with Magellan, you need to have Design Compiler
(version 2006.06 or earlier) installed on the machine you are running on, and
set your SYNOPSYS environment variable to point to that installation, either in
the shell or in the Design module of your project file. You can then use the
VCS -y option with a set_design_info command to point to the
DesignWare Verilog behavioral models, as shown in Example 40. If you don’t
set up your project file this way, you get error messages from the simulator
about missing modules, and your test run fails.
Example 40: Project File Snippet for using DesignWare Components

define_project lt_100

set env(SYNOPSYS) /d/dwt1/synopsys/2003.06
define_design stk -topModule top
set_design_info -vcs { design.v -y
$env(SYNOPSYS)/dw/sim_ver +libext+.v
+incdir+$env(SYNOPSYS)/dw/sim_ver }
If your DesignWare installation is not in $SYNOPSYS/dw, add the -dwRoot

option to point to the location:
set_design_info -dwRoot DesignWare_install_path
All outputs of DesignWare Foundation Library components instantiated in the

design appear in the forcedSignals.log report located in the
mg_sessionName/user directory after a Magellan run. This is normal tool
behavior.
Note Only Foundation Library components shipped with Design Compiler are
supported with this methodology.

Preparing Your Design Initializing Verilog UDPs
Initializing Verilog UDPs

Uninitialized registers and X assignments can cause mismatches and replay
misses if they are in a part of the design critical to a coverage or property goal,
or if they are in the reset sequence (see “Detecting Simulation/Synthesis
Although Magellan attempts to assign a logic 1 or 0 in the reset sequence or

when doing a formal search, Magellan cannot change X values in
state-holding UDPs and does not report them in the xFile.init file. Therefore,
you need to initialize them to a logic 0 or logic 1.
Working with VHDL and Mixed-language Designs

The following sections describe the VHDL constructs that Magellan supports,
and any restrictions or limitations that apply:
“VHDL Data Type Support at Top Level” on page 201
“Using User-Defined Types” on page 202
“Working with Multiple Architectures and Configurations” on page 202
“Modifying Top-Level Generics” on page 203
“Using HDL XMRs” on page 203
“Using Extended Identifiers” on page 203
VHDL Data Type Support at Top Level

At the top level of the design, Magellan supports ports declared with the
following data types, including user-defined types and arrays of the following
types:
std_logic
std_logic_vector
bit
bit_vector
boolean

std_ulogic
std_ulogic_vector
unsigned
signed
integer
natural
enumeration
records
Using User-Defined Types

Initialize integer types to known values. Magellan cannot detect integer types
that are not initialized and report them in the same way it reports registers with
initial X values. Uninitialized integer types can lead to replay misses. See
“Responding to Replay Misses” on page 462.
When using a natural range user-defined type, such as a range of 56 to 60,

write a constraint model which has std_logic_vector inputs and generates
integers or naturals to ensure that the port value is never driven outside of the
range.
Enumeration types require special handling when they are part of a coverage
goal set. See “Using VHDL Enumeration Signals in a Goal Set” on page 386.
Working with Multiple Architectures and Configurations

Magellan supports only one VHDL architecture at the top level of your design.
If you have multiple top-level architectures, reorganize your code so that there
is only one top-level architecture.
Magellan does not support top-level configurations. If you have one or more
configurations at the top level, reorganize your code so that they are no longer
required at the top level.

Preparing Your Design Working with VHDL and Mixed-language Designs
Modifying Top-Level Generics

Magellan treats top-level VHDL generics as constants. This only applies to
generics that are at the top level of the design. To change a top-level generic,
you need to set the value when you analyze the design. You can override
integer and natural typed top-level generics in your constraint model or
property checker using an add_env_block -parameters command. See
Example 58 on page 268.
Using HDL XMRs

Magellan supports $hdl_xmr system tasks in Verilog and hdl_xmr
procedures in VHDL the same as VCS MX. For Verilog $hdl_xmr system
tasks to work, you must include the hdl_xmr.tab file in the simulator build.
In Magellan you do this using a set_design_info -vcs command in the
Design module of your Magellan project file. For example:
define_design my_design -topModule top
add_design_info -vlogan "design_file.v"
add_design_info -vhdlan "design_file.vhd"
set_design_info -vcs { -mhdl -P
$VCS_HOME/include/hdl_xmr.tab top_file.v }
For more information, see the VCS MX Simulation Coding and Modeling Style
Guide located in $VCS_HOME/doc/UserGuide/cmsg.pdf.
Note If you use absolute scopes with $hdl_xmr system tasks or hdl_xmr
procedures, you must append top_design to the start of those absolute
scope names. For example:
top_myDesign.myDesign ...
Using Extended Identifiers

Magellan supports only the VHDL basic identifiers. If you use extended
identifiers, replace them with basic identifiers.


8
Preparing the Environment
This chapter describes the Magellan environment around the design, and explains how to
modify it.
In This Chapter
Understanding the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Describing the Environment in the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Defining Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Understanding and Controlling the Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Configuring Input and Internal Design Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Constraining Input Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Biasing Random Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Avoiding Dead-End States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Identifying and Debugging Constraint Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Understanding the Environment
Understanding the Environment

The Magellan environment that you define ensures that you are testing the
design with legal inputs. This includes initializing the design to a known and
repeatable start-state, clocking, constraining the input signals that Magellan
generates, and assigning constant inputs.
Figure 27 shows the environmental elements that interface with the design in
Magellan.
Figure 27: The Magellan Environment
Magellan
Constrained Assertion-Style
Stimulus Constraint
Generator Assertion-Style
Constraint
Property
Checker
Design Under Test
Property
Reset Generator-Style Checker
Task Constraint
ConstA
You define the environment in the project’s Environment module, and

instantiate property checkers and constraints via this environment. You can
have more than one Environment module, each including a unique set of
constant ports, constraint models, and reset sequences.

Preparing the Environment Describing the Environment in the Project File
Describing the Environment in the Project File

The Environment module requires an environment name, and optionally
includes the following elements:
Port definitions, such as the clock and other port constants.
Reset ports or tasks
Constraints
Checkers
Simulator and other environment options
Defining Clocks
If your design contains any state-holding elements, you must define the clocks
in your Magellan project file. Use an add_env_port command to specify
each clock input:
add_env_port envName -name clkName -clock period
where:
clkName is a top-level input port on your design or an environment block,
or a hierarchical pathname of an internal clock signal in the design. You can
use wildcard characters in the clkName to assign multiple clocks with a
single command. You can also use part-select notation to chose individual
bits or words of port or signal arrays.
period is an integer that specifies the number of time units for the clock
period. Because Magellan analyzes design behavior in a cycle-based
manner, the exact value of period is usually not critical, but the following
section provides some guidelines and restrictions
Note To select a word within a two-dimensional array, you must specify the full
range definition (for example mem[20][7:0]).

Defining Clocks
Specifying Clock Periods and Time Units

If you use a specific time unit for your design, declare it with a
define_env -timeUnits command. The default simulation time unit in
Magellan is 100 ps.
If your design is written in Verilog, Magellan evaluates the clock cycle as the
period multiplied by the time unit. For example, if the clock period is 100, then
the clock cycle is 100 periods times 100 ps long, or 10 ns. The clock period
must be long enough that any #delay statements in the design do not affect
the results. If a #delay statement does affect the results, you may see a
simulation/synthesis mismatch. As a general rule, the sum of all the #delay
statements on any combinational path must not exceed one quarter of the
system clock period.
If your design is written in VHDL, specify the time unit as 1s, 1ms, 1us, 1ps,
1ns, or 1fs. For example, if delays in the design are in nanoseconds you must
specify define_env -timeUnits 1ns in the project file.
Specifying Multiple Clocks

If your design uses multiple clocks to handle different bus interfaces or
low-power areas of the circuit, you can either write RTL clock generators in the
constraint model (see “Using RTL Clock Generators” on page 216), or use
add_env_port -clock -waveform commands in the Environment module
of your project file. This way, Magellan automatically generates the RTL clock
generator models for you, and puts them in your environment. Example 41
shows part of a project file for a design that has three clocks, all with different
clock periods, and different rise and fall times.
Example 41: Multiple Clocks in Project File

define env env1
add_env_port env1 -name clk1 -clock 100
add_env_port env1 -name clk2 -clock 200 \
-waveform {0 150}
add_env_port env1 -name clk3 -clock 300 \
-waveform {100 200}

Preparing the Environment Defining Clocks
You use the add_env_port command:

-name option to specify the clock name
-clock option to specify the clock period
-waveform option to specify the rise and fall times if you want Magellan to
create the RTL clock generator for this clock automatically
In Example 41:
clk1 has a period of 100. You can optionally use this clock as the basis for
any RTL clock generators you write in the constraint model. Because this
clock definition does not use the -waveform option, Magellan gives it a
50-50 duty cycle by default (that is, -waveform {0 50}).
clk2 has a clock period of 200. The rising edge of clk2 occurs at time 0
and the falling edge occurs at time 150. Magellan automatically creates an
RTL clock generator in the constraint model for this clock.
Note how the rise and fall times are specified in curly braces using the
-waveform option. You can specify pairs of rise and fall times in a pattern that
repeats until the end of the clock period (for example, {50 150 200 250
300 350 400 500}). The transition times must be in ascending order.
Magellan generates error messages when a -waveform option specification

in the project file does not respect the following rules:
Integers only
Specify ascending order in the curly braces. The first integer represents the
rise time for the clock. It cannot be less than 0. The second integer
specifies the fall time for the clock. It must be greater than the rise time and
cannot be greater than the clock period.
There must be an even number of rise and fall times in the list.
Specifying the Reset Sequence Length

If you specify multiple clocks in your Magellan project file and also use the
set_env_reset -defaultLen option, you can specify which clock should
be used for the reset sequence using the set_env_reset -refClock

Defining Clocks
option in the Environment module of your project file. For example, the
following command specifies the reset sequence length as 40 cycles of clk1:
set_env_reset -refClock clk1 -defaultLen 40
Specifying Clocks With Wildcards

You can also use wildcards (* or ?) with the add_env_port -name -clock
command to specify one or more clocks (see Example 42).
Example 42: Specifying Clocks With Wildcards

define env env1
add_env_port env1 -name clk* -clock 100
Using Example 42, if your design contains three clocks named clk1, clk2,
and clk3, Magellan picks up all three clocks and sets the clock period to 100
for each of them. Contrast this result to Example 41 on page 208, where
Magellan also picks up three clocks, but they all have different clock periods.
You cannot force clocks to constant values. Consider the following example. If
your design contains the following signals:
ocp_clock
ocpMCmd[3:0]
ocpSCmdAccept
and you use the following commands in the Environment module of your
project file:
add_env_port envName -name ocp* -constant 1
add_env_port envName *clock -clock 100
Magellan adds ocp_clock as a clock, and sets the following signals to

constant values:
ocp_MCmd[3:0] tied to 4'b1111

ocp_SCmdAcept tied to 1'b1

But Magellan does not tie ocp_clock to a constant value, because the last
match in the project file wins.
Clock Specification Examples

Here are some examples that show how to specify clocks in the Environment
module of your Magellan project file. This first example specifies that the
dut.submut1.sig1 internal signal be used as a clock with a period of 100
and rise and fall times of 50 and 100, respectively.
add_env_port envName -name dut.submut1.sig1 -clock 100 \
-waveform {50 100}
For more information on using the -waveform option, see “Specifying

Multiple Clocks” on page 208.
This next example may result in multiple signal matches because a wildcard is
used in the specified internal signal name:
add_env_port envName -name dut.submod*.sig1 -clock 100
For these next few examples, suppose sig1 is a 4-bit vector. In this first
example, the LSB of the sig1 vector is specified as a clock with a period of
100.
add_env_port envName -name sig1[0] -clock 100
In this next example, the next bit in the sig1 vector is specified as a clock with
a period of 100, and rise and fall times of 50 and 100, respectively.
add_env_port envName -name sig1[1] -clock 100 \
-waveform {50 100}
In this example, sig1[2] and sig1[3] are each specified as clocks with
clock periods of 200:
add_env_port envName -name sig1[2:3] -clock 200
If you specify a vector name without an index, Magellan creates clocks for
each signal in the vector. For example:
add_env_port envName -name sig1 -clock 100

Defining Clocks
Using this specification, Magellan creates clocks for sig1[3], sig1[2],

sig1[1], and sig1[0], each with a clock period of 100.
Understanding Magellan’s System Clock

The primary function of Magellan’s system clock is to apply random inputs at
all possible cycles of your design. Magellan applies random inputs at the
negative edge of the system clock.
For most design environments, the system clock and your design clock or
internal generated master design clock are the same (see “Internal Generated
Master Design Clock” on page 214). In these cases, random inputs change at
the falling edges of the system clock, as shown in Figure 28.
Figure 28: System Clock Equals Design Clock Frequency
System Clock
Design Clock
Random Inputs
2X System Clock Generation and Reporting

There are five conditions in designs that cause Magellan to generate a system
clock that is twice the frequency of your design clock or internal generated
master design clock (see Example 43).
When Magellan encounters one or more of these conditions, it issues an

information message similar to the following:
System clock doubled. See report:
/remote/julius/work/mg_s1/user/2xSystemClock.rpt.

The 2xSystemClock.rpt is stored in the mg_sessionName/user directory,

as shown in the example above. The report lists all conditions that require a
2X system clock, not just the first such condition encountered. Example 43
shows an annotated report that includes each of the different conditions that
cause Magellan to use a 2X system clock.
Example 43: 2X System Clock Reporting Examples
1. Latch
SEQ /xfsm/c is a latch.
2. Negative edge-triggered or both edge-triggered flip-flops

SEQ /cy7c80a00_adcclkA/ClkPDM<1> is clocked by negedge of clock:
/cy7c80a00_adcclkA/ClkIn.
3. Other primary inputs in the fan-in cone of the clock pin on a flip-flop
SEQ /chip_top/pad_ring/padi/padi_ctl_obs_tdi/obs_launch_1 is clocked
by PI:/chip_top/ccb_jtslow_clk, not the same as
/chip_top/mg_crg/clk_in.
4. Non-clock pins on sequentials that are driven by a clock

SEQ:/buffer_logic_fv_wrapper/dma_out_clk_ack
Clock port: /buffer_logic_fv_wrapper/clock drives non-clock pins in
the above SEQs/goals.
5. XOR gate in the fan-in cone to the clock pin on a flip-flop

SEQ /ahb_bb_gea0/defmast<3> is clocked by a clock cone with XOR type
gates.
When Magellan uses a system clock that is twice the frequency of the design
clock, random inputs are available at the positive and negative edges of your

Defining Clocks
design clock or internal generated master design clock, as shown in

Figure 29.
Figure 29: System Clock Twice the Design Clock Frequency
System Clock
Design Clock
Random Inputs
Caution Do not tie Magellan’s internal system clock to any signals in your design for
any reason. This causes undesirable side effects that are difficult to debug.
Internal Generated Master Design Clock

When you specify multiple design clocks in the Magellan project file, Magellan
generates an internal master design clock that is at least as fast all active
transitions specified for all clocks in the design. Magellan then prints a
message in the transcript and the mgsh_messages.log file to let you know the
calculated clock period. This information is important because faster clocks
result in slower tool performance. For example:
Internal generated master design clock
'/clk_stop_high/HV_ClockGenerator/DesignClock' period is
set to 100 (timescale=100ps)
Note For designs with multiple clocks, the internal generated master design clock is
used as a reference for the creation of Magellan’s system clock. For designs
with one clock, the design clock itself is used as a reference for the creation of
Magellan’s system clock.

System Clock Generation

The clock period specified in the project file is often the same as the system
clock period. However, if your design has multiple clocks or complex gated
clocks, Magellan automatically determines a system clock period so that the
posedge of the system clock sees all active edges of all clocks in the design.
First, Magellan looks at the fastest design clock and determines if it can be
used to generate all possible transitions for all design clocks. If not, Magellan
calculates a system clock cycle that meets the basic requirement that the
system clock sees all active edges of all clocks in the design. Consider the
following two examples.
Example 1—Clk1=100 and Clk2=200
This is the simple case. Clk2 has a waveform specified as follows in the
Environment module of the project file:
add_env_port env1 -name clk2 -clock 200 -waveform {0 100}
In this example, Clk2 transitions at time 100, 200, 300 ... All clock transitions
are on the positive edge of the clock. Therefore, Magellan uses the clock cycle
for Clk1 (100) as the system clock cycle.
Example 2—Clk1=100 and Clk2=300
This is the less obvious case. Clk2 has a waveform specified as follows in the
Environment module of the project file:
add_env_port env1 -name clk2 -clock 300 -waveform {0 150}
In this example, Clk2 transitions at time 150, 300, 450 ... At time 150, Clk1 is
on the negative edge, which cannot be used to generate the transition for
Clk2. Therefore, Magellan calculates a system clock of 50.
System Clock Period Must be Multiple of Two

Magellan requires the system clock period to be a multiple of two. When you
specify clock periods for your design clocks, make sure the system clock

Defining Clocks
period also results in a multiple of two. If the system clock is not a multiple of
two, Magellan errors out and issues the following message:
System clock period '%d' for Magellan must be
divisible by two. Please change the project file to modify
the clock periods.
To solve this problem, adjust the clock period of the fastest clock in your
design so that it is at least 16 and evenly divisible by 4, and adjust the intervals
between all clock transition times so that they are evenly divisible by 4.
Using RTL Clock Generators

If your design requires more than one clock, you can also write RTL clock
generators in the constraint model to derive the multiple clocks. Declare the
clock in the project file using Environment module commands as shown in
Example 44. Add the source file that contains the clock generator to the list of
files you specify for the build in the Design module of your project file.
Example 44: Adding Clock Generator to Environment

add_env_block env -name cnstr_model_module_name
add_env_port env -name cnstr_model.port -clock period
Note If you write your own RTL clock generators, do note use the -waveform
option with the add_env_port command. If you use the -waveform option,
Magellan automatically builds the RTL clock generator for that clock.
Figure 30 shows a multi-clock environment. The master clock signal, Clock, is

an input to the constraint model in the Magellan environment, which in turn
drives the clock signals on the design:1 clk1 and clk2.

Figure 30: Multi-Clock Environment
Clock
Derived
Clock Clocks
clk1
clk2
Constraint
Model Design Under Test
Random
Inputs
Creating Multiple Clock Signals

To create multiple clock signals, use one of the following options in the
constraint model:
Bind to a single master clock
The simplest solution is to bind all clock signals to a master clock. Use this
solution if design behavior does not depend on specific clock ratios.
Build a clock divider
For clocks that have integral ratios, write a clock divider.
The code that generates the derived clocks must be synthesizable RTL. To
reference the file in a Magellan project, use an add_env_block -clock
command (see Example 55 on page 264). You cannot use assertion-style
constraints to create derived clocks. Use generator-style clock dividers (see
“RTL Clock Generator Examples” on page 218).

Defining Clocks
RTL Clock Generator Examples

Following are two examples of RTL clock generators that you can implement
in your constraint model for designs with multiple clocks. Example 45 shows
an RTL model that generates two clocks with the same frequency, but which
have an offset between them.
Example 45: Clock Generator for Two Clocks with Same Frequency
module clock_generator (mclk, en, clk1, clk2);

input mclk, en;
output clk1, clk2;
reg clk1, clk2;
reg[1:0] count;
always @(posedge mclk)

begin
if (!en) begin
clk1 <= 1'b0;
count <= 2'd0;
clk2 <= 1'b0;
end
else begin
count <= count +1'b1;
if (count==2'd1)
clk1 <= 1'b1;
else if (count==2'd3)
clk1 <= 1'b0;
if (count==2'd2)
clk2 <= 1'b1;
else if (count==2'd0)
clk2 <= 1'b0;
end
end
endmodule

Example 46 shows how to generate a clock with a 30-percent duty cycle.
Example 46: Clock Generator with 30-Percent Duty Cycle
module clock_generator (mclk, en, clk1);

input mclk;
input en;
output clk1;
reg clk1;
reg[3:0] count;
always @(posedge mclk)

begin
if (!en) begin
clk1 <= 1'b0;
count <= 4'd0;
end
else begin
if (count<4'd3)
begin
clk1 <= 1'b1;
count <= count +1'b1;
end
else begin
clk1 <= 1'b0;
if (count < 9) count <= count +1'b1;
else count <= 4'd0;
end
end
end
endmodule

Understanding and Controlling the Reset State

An important part of the Magellan environment is the initial or Reset State of
the design for property and coverage searches. As shown in Figure 31, there
are two phases to a run in Magellan: the Reset Phase and the Random
Generation phase.
Figure 31: Reset Timeline
Reset Random Generation
t0 Reset State
The Reset State is the value of all storage elements (registers or latches) in
the design. All formal searches begin from the Reset State. Simulation
sequences may return to the Reset State multiple times to try different random
stimulus or to replay error traces calculated by Magellan’s formal engines.
There are several different techniques you can use to establish the Reset
State for the design. Whichever method you use, Magellan captures the Reset
State from the simulation environment at the end of the first reset sequence.
Later, when Magellan needs to return the simulation to the Reset State, it
injects the remembered Reset State back into the simulator. This section
explains how to control the Reset State in the following subsections:
“Controlling the Reset State” on page 222
“Writing Verilog Reset Sequences” on page 227
“Writing VHDL Reset Sequences” on page 228
“Using Tcl-based Reset or Reset from File” on page 230
“Using PLI/VHPI Routines to Extract a Reset File” on page 247
“Handling Uninitialized Registers” on page 250
“Debugging Reset Sequences” on page 251

Preparing the Environment Understanding and Controlling the Reset State
Magellan determines the Reset State by sampling the values in design

registers one quarter cycle after the last rising edge of the system clock during
the reset sequence, as shown in Figure 32. At the subsequent falling edge of
the system clock, Magellan applies the first set of random values.
Figure 32: Reset Sequence Timing
Reset State
Sampled
System Clock ...
Reset Sequence Last Event Drive First Set

Initiated in Reset of Random
Sequence Values
The first reset sequence begins at the first falling edge of the system clock.
When Magellan activates the reset sequence again, it may start on any falling
edge of the system clock.
The system clock period may be half the period of the fastest design clock
(see “Understanding Magellan’s System Clock” on page 212). Derived clocks
may be even slower. To be sure that the reset sequence behavior is
repeatable, it is good practice to synchronize it with all clocks by waiting for a
particular edge of the slowest clock in the design.

Controlling the Reset State

During the Magellan reset sequence, you can make a number of things
happen to bring the design to a repeatable, deterministic state. Figure 33 and
Table 6 show an overview of the sequence of events.
Figure 33: Reset Sequence Diagram
set_env_reset [options]
t0 AB CDEFG
System
Clock
rst_n
add_env_port envName -name rst_n -reset 1
Table 6: Reset Sequence Decoder
Symbol What Magellan Does
t0 Applies values specified in initial blocks and sets primary input signals to X
by default (only for first reset). If you need primary inputs to have non-X
values at t0, use an add_env_port -reset command, as shown above.
A Injects 1 or 0 for registers with set_env_reset -value and sets primary

inputs to 1 or 0 with set_env_reset -defaultValue.
B Calls reset task specified with set_env_reset -taskFile or

-scriptFile, or runs default reset task.
C After one or more clocks, the reset task returns.
D Injects values from ResetFile for set_env_reset -file.
E Captures Reset State for use by formal engines.
F Generates xFile.init file, which reports Xs in the Reset State. Note that any
remaining Xs are randomized to 1 or 0 in the simulation model and treated
as free variables (“don’t cares”) in the formal model.
G If first reset, remembers this state for later reuse. If not first reset, reinjects
the first Reset State unless -reuse is set to 0.

You can supply a reset sequence in Verilog or VHDL, or use a specially

formatted text file (ResetFile) to specify the Reset State. Or mix and match the
two approaches. Alternatively, you can specify a reset sequence using a file of
Tcl-based reset commands. You cannot mix a reset task using Verilog/VHDL
and Tcl-based reset commands. The last set_env_reset -taskFile or
-scriptFile command in your project file is the one Magellan uses.
The default for any X values in state-holding sequentials that remain at the
end of the Reset phase for the formal model is “don’t care.” This helps reduce
the potential for simulation/synthesis mismatches and replay misses. For
more information, see “Handling Uninitialized Registers” on page 250.
Specifying a Design Signal for Safe Resets

In some cases, you may need to prevent Magellan from resetting the simulator
during the Random Generation phase until certain conditions are met. For
example, you may need a specific number of cycles to run after any trace
replay to guarantee that some values propagate far enough into the design for
your test requirements. To ensure that Magellan simulator resets do not
interfere in cases like this, use a set_env_reset -safeReset command in
the Environment module of your project file. You use this option to point to a
design_signal that, when high, ensures that it is safe for Magellan to reset
the simulator. For example:
set_env_reset envName -safeReset design_signal
Note When design_signal goes high this does not trigger a Magellan simulator
reset. It just means that when Magellan is ready to do a reset according to its
own algorithms, it checks that design_signal. If it is high, the reset
proceeds. If it is low, the reset is delayed until the design_signal goes high.
Using the Default Reset Sequence

The default reset sequence is one design clock cycle long. It sets all primary
inputs (and outputs of blackboxed modules) to X, and then asserts the reset
signals specified by the add_env_port -reset command. You can
increase the duration of the default reset sequence with the following
command:
set_env_reset envName -defaultLen N

where N is the number of system clock cycles that the reset signals are
asserted.
Simple Reset Declaration

Example 47 shows a simple reset declaration. With this code, Magellan sets
the rst_n reset signal to a constant 0 during the Reset Phase and a constant
1 during the Random Generation phase.
Example 47: Simple Reset Declaration

add_env_port env_1 -name rst_n -reset 0
add_env_port env_1 -name rst_n -constant 1
Replacing the Default Reset Sequence

If you write reset code to replace the default reset sequence, use a
set_env_reset command to specify the reset task. During reset, Magellan
ignores any port assignments that set the reset value or a port constant value.
Example 48 shows an Environment module that uses a set_env_reset

command to replace the default reset sequence with a Verilog reset task in the
reset.v file.
Example 48: Replacing the Default Reset Sequence

set_env_reset env_1 -taskName new_reset \
-taskFile reset.v -taskFormat verilog

Setting all Registers to a Value Before Reset Sequence

To eliminate unknowns, you may want to set all the design registers to a logic
0 or a logic 1 before the reset sequence runs. You can then customize the
reset sequence to set the registers that require alternate values.
Note Magellan only sets registers that are inferred as sequentials during synthesis.
Also, Magellan cannot set values in state-holding UDPs. Therefore, you need
to initialize them to a logic 0 or a logic 1.
To set all the registers in the design, use a set_env_reset -value

command. By default, Magellan applies the specified value before the reset
sequence runs. For example, to set all registers in the design to logic 1 before
the reset sequence runs, use the following command:
set_env_reset envName -value 1
Setting Primary Inputs and Internal Signals During Reset Phase

If you want to set any primary inputs or internal signals to constant values
during the Reset Phase, use add_env_port -reset commands. Legal
values include 1, 0, and X. You cannot specify a Z value with this command.
For example:
add_env_port envName -name signal_name -reset X
If you want to set all primary inputs (and outputs of blackboxed modules) not
specified with add_env_port -reset commands to constant values during
the Reset Phase, use a set_env_reset -defaultVal command. Legal
values include 1, 0, and X. You cannot specify a Z value with this command.
For example:
set_env_reset envName -defaultVal 0
Note If the range specified with add_env_port -reset is less than the range of
the signal_name, Magellan pads using the default value specified with
set_env_reset -defaultVal.
If there is no reset value specified for a primary input with an add_env_port

-reset or set_env_reset -defaultVal command, Magellan looks for a

constant value to use instead (add_env_port -constant). If there is no

port constant value defined, Magellan uses X by default during the Reset
Phase.
Determining if Reset Sequence is Executing

Magellan provides a built-in signal that you can use to determine if the reset
sequence is executing. You can connect this signal to input ports on constraint
models or property checkers using the following command:
add_env_port envName -name inst_name.port_name -sysReset
Modifying the Default Reset Sequence

If the design requires a reset that is longer than one clock cycle, you can
extend or replace the default reset sequence. If you need to initialize the state
of registers, you can:
Use a Magellan command to reset all registers to a value (see “Writing
Verilog Reset Sequences” on page 227).
Extend or replace the default reset sequence.
If you extend or replace the default reset sequence, write the reset code in a
separate file and reference that file in your Magellan project. See “Replacing
the Default Reset Sequence” on page 224.
You can write the reset code in Verilog or VHDL. See:

“Writing Verilog Reset Sequences” on page 227
“Writing VHDL Reset Sequences” on page 228.
Note The reset task cannot control the values of design inputs after the end of the
reset task. In general, you must use add_env_port -constant commands
in your project file to hold design reset ports to their inactive values. See
“Setting Input Signals to Constants” on page 253.
Because formal verification starts after the reset sequence, reset code is not
part of the Formal build. See “Understanding the Build Process” on page 135.

Writing Verilog Reset Sequences

This section provides guidelines on how to write a reset sequence in Verilog.
These guidelines apply to inline files that are appended to the default reset
sequence and task files that replace the default reset sequence.
Magellan typically applies input assignments on the system clock’s falling

edge. However, input assignments in your Verilog reset sequence occur as
they are written, and may not align with the falling edge of the system clock. If
you apply inputs on the rising edge (posedge) of the system clock, then the
design must handle any potential race conditions between the active clock
edge and the input value changes.
At the beginning of the reset sequence, Magellan drives each input on the
design, constraint models, and property checkers that is not connected or
assigned a value with a zero value. Example 49 shows a custom reset task
written in Verilog.
Example 49: Verilog Reset Task
task my_reset;
begin
fpu_wrap_reset = 1; // Assert reset
fpu_wrap_resetDone = 0;
// Hold 40 clocks
repeat (40) @(posedge fpu_wrap_MCLK);
@(negedge fpu_wrap_MCLK);
fpu_wrap_reset = 0; // Drop reset
// Wait 2 clocks
repeat (2) @(posedge fpu_wrap_MCLK);
@(negedge fpu_wrap_MCLK);
fpu_wrap_resetDone = 1;
$display("Initialization complete.\n");
end
endtask
After writing your reset sequence and adding it to the project file, verify that
your reset sequence initializes the design correctly (see “Debugging Reset
Sequences” on page 251).

Referencing Ports and Internal Design Nodes

In the Verilog reset file, reference a design port as designTopModule_port.
Reference a port on a constraint or a checker instance as
instanceName_port.
To reference an internal Verilog node, specify the complete hierarchical name

from the design’s top module, and then prepend top_designTopModule to
the name. For example:
top_designTopModule.hierarchy.nodeName
Writing VHDL Reset Sequences

This section provides guidelines on how to write a reset sequence in VHDL.
These guidelines apply to inline files that are appended to the default reset
sequence and task files that replace the default reset sequence. Example 50
shows a custom reset task written in VHDL.
Example 50: VHDL Reset Task
procedure my_reset is
begin
fpu_wrap_reset <= ‘1’;-- Assert Reset
fpu_wrap_resetDone <= ‘0’;
for i in 0 to 39 loop-- Hold 40 clocks
wait until (fpu_wrap_MCLK = ‘1’);
end loop;
fpu_wrap_reset <= ‘0’;-- Release Reset
for i in 0 to 1 loop-- Wait 2 clocks
end loop;
end;
Note Magellan does not support VHDL reset tasks with pure VHDL designs or
designs that contain SVA or PSL.

After writing a reset sequence and adding it to the project file, verify that it
initializes your design correctly (see “Debugging Reset Sequences” on
page 251).
Referencing Ports
In a VHDL reset file, reference a design port as designTopModule_port.
Reference a port on a constraint or a checker instance as
instanceName_port.
Referencing the System Clock Period

Magellan defines a generic called simulation_cycle, which you can use to
access the system clock period in your reset sequence. Example 51 shows a
reset task using the simulation_cycle generic.
Example 51: VHDL Reset Task Using the Simulation_Cycle Generic
procedure my_reset is
begin
fpu_wrap_reset <= ‘1’;-- Assert Reset
fpu_wrap_resetDone <= ‘0';
wait for simulation_cycle * 40;-- Hold 40 clocks
fpu_wrap_reset <= ‘0’;-- Release Reset
wait for simulation_cycle * 2;-- Wait 2 clocks
end;

Using Tcl-based Reset or Reset from File

You can use a specially formatted ASCII text file to specify all or part of the
Reset State for your design, and then point Magellan to this file using a
set_env_reset -file command in your project file. See “Using Reset
From File” on page 231.
Alternatively, you can specify a Reset State using a file that contains Tcl-based
reset commands and point Magellan to this file using a set_env_reset
-scriptFile command in your project file. See “Using Tcl-based Reset” on
page 233.
Using either approach, you set reset values for registers and memories in a
language-correct manner.
Your reset file doesn’t need to specify reset values for all of the state-holding
sequentials in your design. This gives you the flexibility to fill in the blanks
using set_env_reset -value commands. However, keeping most or all of
your reset information in one file can make it easier to manage the Reset State
in Magellan.
The registers and memories in your reset file should be sequentials and
memories inferred from the synthesis process (Magellan ignores them if
they’re not). To create a reset file for Magellan, it is good practice to build your
design first, and then use the output from the analysis phase to identify the
state-holding sequentials for reset. Magellan generates messages during the
build that point you to log files which contain detailed information about the
sequentials in your design, as shown in Figure 34.
Figure 34: Pointers to Log Files from Analysis Listing Sequentials
***** Analyzing Design *****

Loading db file '/vobs/propver/rls/synopsys/libraries/syn/gtech.db'
Presto compilation completed successfully.
Presto compilation completed successfully.

The HDL compiler diagnostic output is in file:
/tests/system/simple/oneMem/mg_common/mem_test.compile.log

Examine the log files from both the Analyze Design and Analyze Environment
phases of the Formal build to locate all of the sequentials inferred in your
design, and add them to your reset file. Each phase generates a separate
information message like the one shown in Figure 34.
During the reset sequence, Magellan generates an xFile.init file in the

mg_sessionName/user directory which lists all state-holding sequentials that
are still unknown (X) after reset. Use this file to identify additional sequentials
that you want to handle during reset, and add them to your reset file.
Using Reset From File

The reset text file can have any name you choose, but must conform to the
following format. Note that escaped names/identifiers must be enclosed in
quotes and specified in a language-correct manner:
# - comment
S <scopeName>
R <regName> <radix><vecVal>
M <memoryName> <radix> <filePath>
where:
S <scopeName>
<scopeName> is an instance name used as the scope for the following

register, vector value, or memory statements.
A scope specified as <DUT> means the top-level module or root of the design
(this is the default). Magellan also recognizes <DUT> as a scope in other path
names. You use Verilog format for specifying register names and hierarchy
delimiters, even if your design is in VHDL. For example:
S <DUT> # Current scope is the design root instance
S <DUT>.inst1 # Scope is now inst1 inside the root inst
R bar[7:0] 01101100 # bar[7:0] is in inst1, default
radix is binary
R foo[7:0] h6c #radix is hexadecimal

where:
R <regName> <radix><vecVal>
<regName> is the name of a single or multibit register and the associated

reset value. Specify the radix followed by the vector value (vecVal), with no
spaces in between. The default radix is binary (use h or b to specify). The
width of the vector must match the register width; otherwise Magellan
right-justifies the value and pads with zeros on the left.
where:
M <memoryName> <radix> <file_path>
<memoryName> is the name of the memory you want to set up for reset,
followed by the radix and the file_path to the memory file. (The space
between the radix and the file_path is required.) The accepted memory file
formats are Verilog $readmemh and $readmemb for hexadecimal and binary,
respectively (the radix is h or b).
Use a set_env_reset -file command in the Environment module of your

project file to point Magellan to the file that contains your reset state
specification. For example:
set_env_reset envName -file ResetFile

Using Tcl-based Reset

You can use custom Tcl-based procedures to specify the Reset State in a
language-correct manner for VHDL, Verilog, and mixed-language designs.
Magellan supports all Tcl constructs and commands (Tcl 8.3) in Tcl-based
reset files except exit and quit. This section explains how to use Tcl-based
resets in Magellan in the following subsections:
“Specifying Numeric Values” on page 233
“Specifying Bit and Part Selects” on page 234
“Specifying Memories” on page 234
“Specifying Hierarchical Path Names” on page 234
“Specifying Records and Structures” on page 235
“Specifying Generate Statements” on page 235
“Specifying Escaped Identifiers” on page 236
“Referencing Design Variables” on page 236
“Using Wildcards with Signal Names” on page 236
“Evaluating HDL Expressions” on page 237
“Tcl -based Reset Script Commands” on page 237
“Example Tcl-based Reset Files” on page 245
Specifying Numeric Values

For pure Verilog designs, you can specify numeric values using Verilog
syntax. For pure VHDL and mixed-language designs, you can specify numeric
values using either VHDL or Verilog syntax. Here are some examples:
VHDL Style 1
16#FFca23#
2#1111_1110#
-10#23749

VHDL Style 2
B"11111110"
B"1111_1110"
X"FFca23"
O"777"
Verilog
'b11111110
8'b11111110
16'b0011_0101_0001_1111
32'h 12ab_f001
Specifying Bit and Part Selects

You can specify bit selects and part selects in a language-correct manner for
VHDL or Verilog portions of your design. Here are some bit-select examples:
vlObj[0], vlObj(0), vhObj(0), vhObj[0]
and some part-select examples:

vlObj[0:5], vlObj(0:5),
vhObj(5 downto 0), vhObj[0:5], vhObj(0:5)
Specifying Memories
For Verilog, specify memories as part selects with respect to rows or down to
the bit-level. For example:
mem_inst.tmp_ram(2), mem_inst.tmp_ram(2)(0)
Specifying Hierarchical Path Names

To specify hierarchical path names, follow these guidelines:
Pure Verilog designs, use “.” as the path delimiter.
Pure VHDL designs, use “:” or “/” as the path delimiter.
Mixed-language designs, use any of the above path delimiters.

The default scope for specifying hierarchical path names is always the
top-level module/entity that Magellan automatically generates. When you
specify the reset sequence, use path names relative to this top-level
module/entity.
For example, if your top-level module is named soc_arb
the Magellan testbench is named top.soc_arb
The top-level module/entity name (soc_arb) is implicit, so you specify path

names as:
i1.i2
i1/i2
i1:i2
Note the following exception to this general rule. To access signals in

environment blocks, you must specify the full hierarchical path. Let’s say you
have a user-specified environment block that contains a clock inverter. To
access a signal in that environment block you specify the hierarchical path
name as follows:
top_designname.clkInvInst.in ,
top_designname.clkInvInst.generator.index
Specifying Records and Structures

Regardless of the path delimiter you use, you must use the “.” to specify
VHDL records or SystemVerilog structures. For example:
record_sig.field
Specifying Generate Statements

Specify VHDL and Verilog generate statements the same way you index or
bit-select arrays. For example:
vlgen[0], vlgen(0), vhgen(0), vhgen[0]

Specifying Escaped Identifiers

Verilog escaped identifiers start with “\” and end with a space “ ”. VHDL
extended identifiers start and end with “\”. Therefore, you can use a space or
a “\” delimiter. This means you cannot use a space in a VHDL extended
identifier. For example:
"\escapedvlog " , "\escapedvhdl\" ,
{\ext_ident!\ } # Note the trailing space and {} braces
\\ext\ ident\!\\ # All non-alphanumeric characters escaped
For mixed-language designs, the following are both supported:
{\ocp_MCmd }
{\ocp_MCmd\ }
Referencing Design Variables

Reference all design variables (for example, signals, ports, etc.) without the $
sign. Use the $ sign only for Tcl variables.
Using Wildcards with Signal Names

You can use the * and ? wildcards to specify HDL signal names with the
mg_force, mg_release, and mg_show commands.
The * matches any sequence of characters and the ? matches any single
character. For example:
mg_force req_rdy.*fsm*.*.* 0
Magellan does not expand wildcards across instance boundaries. Also, note
that Tcl supports more powerful regular expressions using regsub and regexp.
You can use these in your Tcl-based reset file but not paired with
Magellan-specific reset commands (the regular expressions don’t expand
when used that way). However, you can use Tcl regsub and regexp
commands on the list of signal names returned by [mg_show *].

Evaluating HDL Expressions

There is no built-in support for HDL expression evaluation. However, you can
use Tcl constructs to do the same thing in the reset file. For example, the
following is not supported:
if {[mg_get (counter_inst.count(3) AND
counter_inst.count(0)) -dec] == 1} {
...
The supported syntax makes use of Tcl operators:

if { [mg_get counter_inst.count(3) -dec] == 1 &&
[mg_get counter_inst.count(0) -dec] == 1} {
...
Because Tcl expression evaluation treats 'X' and 'Z' as strings, you must
handle these separately.
Tcl -based Reset Script Commands

You can use the following custom Tcl commands only in a reset script file that
you point to in your Magellan project file using a set_env_reset
-scriptFile command. For example:
set_env_reset envName -scriptFile myFile
The following reset commands don’t work in the MG shell.
mg_run
Run Magellan for the specified number of edges of either the default clock
(see “mg_refclock” on page 239) or the specified clock. When you use this
command, the simulator stops at the end of the time step when the edge
happens. Any effects from forcing signals are visible in the next time step
(another mg_run command).

Syntax
mg_run number_of_cycles
[-clk clock_name]
[-rising | -falling | -both]
Arguments
number_of_cycles
Specify the number of clock edges to run. By default, this command

encapsulates both edges of the clock. You can override this using the
-rising or -falling switches.
[-clk clock_name]
Name of the clock on whose edges the run is executed. The clock_name
must refer to a clock previously defined in the project file. You cannot define
a clock in the Tcl-based reset file. The clock defaults to a single clock
defined with either add_env_port -clock or set_env_reset
-refClock in the project file. If there are multiple clocks defined in the
project file, specify the default clock using the mg_refclock command or
add it as an argument to the mg_run command.
[-rising | -falling | -both ]
Run for number_of_cycles number of -rising (posedge), -falling

(negedge), or -both clock edges. -both is the default.
Examples
Run Magellan for 4 cycles of the default clock (both edges):
mg_run 8
Run for 4 cycles of the ocp_clock:

mg_run 8 ocp_clock
Run until the next edge of the default clock:

mg_run 1
Run until the next posedge of the default clock:

mg_run 1 -rising

Run for 4 negedges of the default clock:

mg_run 4 -falling
Run for 10 edges of the default clock (amounts to 5 clock cycles):

mg_run 10 -both
mg_refclock
Set the default clock to be used with mg_run commands unless overridden by
an explicit clock_name argument with an mg_run command. If there are
multiple clocks defined in the project file, use this command to specify the
default clock to use with mg_run commands. Note that you cannot use an
mg_force command to force a default clock specified in a Tcl-based reset file.
Syntax
mg_refclock clock_name
Arguments
clock_name
Specify the clock to use as the default clock with mg_run commands. The
clock must be a clock previously defined in the project file (add_env_port
-clock). The clock_name you specify cannot contain wildcards.
Examples
Set the default clock:
mg_refclock ocp_MAddr(0)
Set the default clock:

mg_refclock ocp_clock

mg_force
Force a value onto one or more variables or signals. These forces override
any previous forces and any design drivers. Forced values must be
language-correct. For example, forcing a VHDL Boolean with value 0 is
incorrect; it must be forced to 'true'. Language-specific padding rules apply
if the width of the signal_name is different from the width of the
signal_value. When mg_force completes successfully, it lists the signal
name and the value forced at the output. You cannot use this command to
override the behavior of any clocks specified in the project file using
add_env_port -clock commands.
You can only specify literal values of the appropriate type for a given HDL
object. Integer, real number, enumeration, character, bit, 4-value logic, 9-value
logic, character string, bit vector, logic vector, and array literals are supported.
You can use VHDL or Verilog syntax for literals.
Note Signals that you force but don’t release in a Tcl-based reset sequence are
automatically released at the end of step (B) (see Figure 33 on page 222).
This means that design driver transactions propagate when (B) is over.
Magellan implicitly converts a VHDL 9-value logic literal to Verilog 4-value

logic when it is forced on a Verilog object (see Table 7).
Table 7: VHDL 9-value Logic Literal Conversions
VHDL 9-Value Verilog 4-Value
U X
W X
L 0
H 1
- X
Forcing VHDL Bit Objects (2-value Logic)
X 1
Z 0

Enclose character string literals in curly braces.
Syntax
mg_force signal_name signal_value [args]
Arguments
signal_name
Name of the signal to force. The signal_name can be hierarchical, and

wildcards are allowed. The default is all.
signal_value
Value to apply (see “Specifying Numeric Values” on page 233).

[args]
Optionally, specify filters for signal_name. Valid options include:
-pi — primary inputs only
-po — primary outputs only
-pio — primary inouts only
-sig — internal signals only
-var — internal variables only
-all — all the above. This is the default.
Examples
Force all primary inputs (except clock) and outputs of blackboxed modules
to 0 bitwise:
mg_force * 0 -pi
Force all signals/variables starting with ocp_MAddr to X bitwise:

mg_force ocp_MAddr* X -sig -var
Force a part select:

mg_force ocp_MAddr(1:0) 0
Force a hierarchical signal to a specific value:
mg_force req_rdy.state_reg 8'b0101111

Force a VHDL enum to a specific value:

mg_force req_rdy.fsm_vhd.CS S2;
Force a memory to all 0s:

set NUM_MEM_ROWS 3
for {set i 0} {$i < $NUM_MEM_ROWS} {incr i} {
mg_force mem_inst.tmp_ram($i) 0
}
mg_release
Release one or more signals previously forced with an mg_force command.
When mg_release completes successfully, it lists the signal name that was
released. When you release a signal that has an internal driver in the design,
that design driver regains control of the signal.
Syntax
mg_release signal_name signal_value [args]
Arguments
signal_name
Name of the signal to release. The signal_name can be hierarchical, and

[args]
Optionally specify filters for signal_name. Valid options include:

Examples
Release all forced primary inputs:
mg_release * -pi
Release all forced signals starting with ocp_:
mg_release ocp_*
Release a hierarchical signal:
mg_release req_rdy.gen_vlg_fsm(2).fsm_vlg.CS
mg_get
Get the current value of the specified signal.
Syntax
mg_get signal_name [radix]
Arguments
signal_name
The name of the signal. This can be a hierarchical name. You cannot use
wildcards in the signal_name.
[radix]
Format specification for the returned value of the signal. Legal values
include:
-bin — binary
-dec — decimal
-oct — octal
-hex — hexadecimal
The default is decimal.
Examples
Get memory row value:

set mem_val [ mg_get mem_inst.tmp_ram(2) -bin ]

Run until some value:

while {[mg_get counter_inst.count -dec] != 10}{mg_run 2;}
mg_show
Retrieve a list of design signals matching the specified signal_name and
filters. This command returns signal names in a Tcl list. The returned signal
names are relative to the top-level design module/entity.
Syntax
mg_show signal_name [args]
Arguments
signal_name
Name of the signal to retrieve. The signal_name can be hierarchical, and

[args]
Optionally specify filters for signal_name. Valid options include:
Examples
Retrieve list of all primary inputs and outputs of blackboxed modules:

set pi_list [mg_show * -pi]
Retrieve list of all signals starting with ocp_:

set ocp_sig_list [mg_show ocp_*]

mg_time
Get the current simulation time. This command returns the current simulation
time as a string.
Syntax
mg_time
Example
Print the current simulation time:

puts "current simtime: [mg_time]"
Example Tcl-based Reset Files

Figure 35 shows a simple reset.
Figure 35: Simple Tcl-based Reset
mg_refclock clock
mg_force reset_n 1'b0
mg_run 20
Figure 36 shows a gated/multi reset.
Figure 36: Gated/Multi Tcl-based Reset
mg_refclock ocp_clock
mg_run 20
mg_force ocp_MCmd 3'b101
mg_run 8

Figure 37 shows how to configure a register.
Figure 37: Register Configuration in Tcl-based Reset
set index 0
puts "[mg_get ocp_clock]"
puts "[mg_get counter_inst.count]"
mg_force ocp_MCmd 3'b111
while {[mg_get counter_inst.count -dec] != 10} {
set index [expr $index +1]
}
puts "[mg_get counter_inst.count]"
puts "[mg_get ocp_clock]"
Figure 38 shows a single clock edge protocol for the ARM NWait register
configuration.
Figure 38: Single Clock Edge Protocol in Tcl-based Reset
# Primary Reset
mg_refclock clk_gn
mg_force reset_n 0
mg_force scli_i 1 -pi
mg_force sdai_i 1 -pi
mg_force arm_a 16'b0011_0101_0001_1111 -pi
mg_force arm_do* 0 -pi
mg_force arm_mas 1 -pi
mg_force arm_nrw 1 -pi
mg_force arm_nmreq 0 -pi
mg_force sim 1 -pi
mg_run 15
mg_force reset_n 1
mg_run 6
# Register Programming
mg_force arm_a 16'b1111_0101_0000_1100 -pi
mg_run 1
mg_force arm_do 0x00000000 -pi
mg_run 1
while {[mg_get arm_nwait] != 1} {
mg_run 2
}
mg_force arm_a16 'b0011_0101_0001_1111 -pi
mg_run 1

Using PLI/VHPI Routines to Extract a Reset File

If your design has a limited number of state-holding sequentials that you want
to handle for reset, you can write a reset file using any text editor (see “Using
Tcl-based Reset or Reset from File” on page 230). But if you have a more
complicated design with lots of sequentials and memories that you want to
configure precisely for reset, you can more easily extract a reset file from your
system-level simulation using the PLI/VHPI routines supplied with Magellan.
Follow these steps:
1 Use Magellan to build your design. This initial build produces a design.map
file that is a required input to the PLI/VHPI routine in the next step. In your
system-level testbench, add a PLI/VHPI call at precisely the simulation time
at which you want to sample the design state. For example.
Verilog
initial begin
#49000;
$writeResetInjectFileHV("top.dma1.U3",
"/u/mg_design/test/mg_ses3/.temp/env/design.map",
"ResetDir");
end
VHDL
process begin
wait for 49000ns;
work.vhpiTasks.writeResetInjectFileHV("top:dma1:U3",
"ResetDir");
wait;
end process;
2 In these examples, the design is deemed to be in the correct state for reset
at time 49000, and the path name to the design in the system-level context
is top.dma1.U3, as shown in the first argument. The second argument is
the full path to the design.map file produced in Step 1. The design.map file
identifies the state-holding registers that need to be extracted for reset.
Use the ResetDir in the third argument to this routine to specify the name
and location of the directory that will contain the output files you’ll use to
specify the Reset State for your design on your next run with Magellan.

3 If you have any memories in your design that are synthesized into
sequentials, you need to identify and extract them for reset. This is
analogous to the way the design.map file identifies state-holding registers.
Follow these steps:
Verilog
Locate the memInit.vh file in the mg_sessionName/.temp/env directory and
copy all of the $defineMemoryBlockHV calls. There is one memory block
call for each memory in your design. Paste these calls into your
system-level testbench right before the reset PLI routine. For example:
initial begin
#49000;
$defineMemoryBlockHV("mem_test.mem_inst.ram", 0);
$writeResetInjectFileHV("top.dma1.U3",
"ResetDir");
end
Modify the path names of all the memory instances in these calls so that
they are full path names from the system-level design. You don’t need to
modify the second arguments to these memory block calls. They are just
numerals that increment for each memory block found in your design.
VHDL
Locate the memInit.inc file in the mg_sessionName/sim directory and copy
it to someplace where it won’t get overwritten. Include this file in the system
simulation run. The defineMemoryBlockHV calls are the ones that need to
be there for the system simulation. Modify the path names of all the
memory instances in these calls so that they are full path names from the
elaborated system-level design. Make the defineMemoryBlockHV calls by
including them in an existing VCS MX simulation include file. Or source the
modified memInit.inc file from the VCS MX command line.
When you invoke VCS MX, use the following -vhpi option to call the entry
point function that registers the defineMemoryBlockHV call as a new VCS
MX command:
-vhpi ctgSco:ketchumEntryPoint:ketchum

4 To access these new PLI or VHPI functions, include the Magellan

simulation library in the simulator build as follows:
Verilog (VCS)
-P $MG_HOME/sparcOS5/ctg/lib/ctgPli.tab \
$MG_HOME/sparcOS5/ctg/lib/ctgVpi.o
Mixed-language (VCS MX)

$MG_HOME/sparcOS5/ctg/lib/libctgMix.so
VHDL (VCS MX)

$MG_HOME/sparcOS5/ctg/lib/libctgSco.so
vhdlan \
$MG_HOME/auxx/ctg/sim/vhdl/include/CTG_vhdltasks.vhd
Include this in the file from which you call out the VHPI routine. For
example:
library IEEE, WORK;
use WORK.vhpiTasks.all;
Then add the new library to your load library path as follows:
% setenv LD_LIBRARY_PATH \
$MG_HOME/sparcOS5/ctg/lib:$LD_LIBRARY_PATH
5 Rerun your system-level simulation with the new PLI/VHPI routine in place.
6 Copy the ResetDir to someplace where it will not get overwritten. This
directory contains one ResetState.dat file for your design and one or more
ResetMemn.dat files, where n starts at 0 and increments for each memory
found in the design (for example, ResetMem2.dat).
7 Open the ResetState.dat file in a text editor and modify register bit values
as needed. If you captured reset information for memories in your design,
this reset file contains includes for those memories, as shown in Figure 39.
Modify the paths to any memory includes as needed.

Figure 39: Sample ResetState.dat File with Memory Include
## Snapshot of state for design:top_mem_test.mem_test

## Date:Mon Mar 3 13:00:00 2003
## Captured at sim time:49
S <DUT>
R out_sum[7:0] 00000111
R r_in_data[3:0] 1101
R r_addr[2:0] 001
R r_wr_en 0
M <DUT>.mem_inst.ram b ResetDir/ResetMem0.dat
8 Use a set_env_reset -file command in your project file to point to

this ResetState.dat file, as follows:
set_env_reset envName -file path_to_ResetState.dat
The next time you run Magellan, it uses the Reset State specified in this file
to reset your design.
Handling Uninitialized Registers

In many designs there are memories or registers that are not easily initialized.
These elements typically contain X values at the beginning of simulation. In
formal analysis, X indicates an unknown state. This means that the analysis
must consider both the 1 and 0 states. In simulation, X is a discrete state that
behaves differently than 1 or 0. This can lead to mismatches between the
simulation and formal models. See “Detecting Simulation/Synthesis
Magellan reports on X values in the Reset State with a message during the
build phase. It also logs the uninitialized registers in the xFile.init file located in
the mg_sessionName/user directory. If the sequential is a bit of memory,
Magellan writes the memory name into the file once rather than logging each
bit of the memory. Review the contents of the xFile.init to make sure that only
the elements you expected to be uninitialized show a logic X.

After each reset, Magellan randomly sets any Reset State X values to 0 or 1
individually for the simulation model. The formal model treats Reset State X
values as free variables (“don’t care”).
Notes 1. When computing formal proofs or unreachable states, Magellan treats X or

Z bits in the Reset State as unknowns. Therefore, a property proof is valid
regardless of which value (0 or 1) the unknown bits have.
2. In VHDL, an integer bit never has an X or Z state. Magellan cannot detect

uninitialized integers. Therefore, you need to initialize integer elements to
known values.
3. VHDL enumeration types are treated as integers. As a result, you need to

initialize elements that are enumeration types to known values.
4. Magellan cannot change X values in state-holding UDPs, and does not

report them in the xFile.init file. Therefore, you need to initialize them to logic 0
or logic 1.
Debugging Reset Sequences

Like all design and verification code, reset sequences must be tested to
ensure that they are functionally correct. Use the simulator to evaluate
whether the reset sequence initializes the design correctly. After you build a
session, you can use the random simulation scripts to test the reset sequence.
See “Using the Simulation Test Scripts” on page 139.
Reset Reuse and Miscompares

Magellan captures the initial state after the first design reset, and injects the
captured state back into the design at each subsequent reset. The process
that injects the initial state may not work correctly for state-holding UDPs, so
Magellan checks to see if the initial state is consistent. If the state is not
consistent with the first captured state, you see miscompare warnings similar
to Figure 40.
Magellan stores miscompare information in a resetState.diff file, and continues

to run. The resetState.diff file contains a line identifying each register whose
value is different for the initial and subsequent Reset States. Each line

Figure 40: Miscompare Warning Message
*** Warning (HVOR-036)

First and Nth reset state miscompare at T=30488.
File=mg_sessionName/user/resetState.diff.1
includes the simulation time for the original Reset State and the subsequent
Reset State. If you don’t consider these miscompares to be significant, you
can turn off reset state comparisons. Use the following command:
run_session sessionName -noCompareReset
Repeatable Resets and Miscompares

A repeatable reset sequence returns the design to the same state every time it
runs, regardless of the state before reset. To see if your reset sequence is
repeatable, you can turn off Magellan’s default reset reuse behavior, and let
your reset sequence run as often as needed. Use this command:
set_env_reset envName -reuse 0
If Magellan finds miscompares between the initial Reset State and any
subsequent Reset State, it issues a warning message and generates a
resetState.diff file (see Example 40). In this case, you can use the miscompare
information to figure out why your reset sequence didn’t work as expected.

Preparing the Environment Configuring Input and Internal Design Signals
Configuring Input and Internal Design Signals

After the reset sequence completes, Magellan applies random values to all
unique inputs in the design, the constraint model, and checkers that aren’t
driven by some other port or a constant in the project file.
Setting Input Signals to Constants

To set a signal to a constant value during the Random Generation phase (see
Figure 31 on page 220), use an add_env_port command. The following
examples assign a single port a value and a 32-bit vector port a value:
add_env_port envName -name sigA -constant 0
add_env_port envName -name busB -constant 32’hFFFFFFFF
The value of the port may not be constant in the reset task, but once the
Random Generation phase begins, Magellan holds the port to the constant
value.
To set a portion of a vector port to a constant value, specify the bits using an
add_env_port command. The other bits of the vector receive random values
during the Random Generation phase. The following example assigns a
constant to the 16 least significant bits of the vector port busB:
add_env_port envNname -name busB[15:0] -constant 16’h1FFF
Note When you set primary inputs to constant values using an add_env_port
-constant command, the RTL simulation model and the formal model both
build with the constant value you specify. During the Formal build, sequential
registers that are held at constant values may be pruned or optimized away if
there is no way they can change their state in the design.
Using Wildcards to Set Signals to Constants

You can use wildcards with the add_anv_port -name option to specify
constant values for one or more signals. Magellan supports * (match any
sequence of characters) and ? (match any single character). For example, to
set all input signals with names that begin with mre_ to a constant 0 during the
Random Generation phase:
add_env_port envName -name mre_* -constant 0

When you use wildcards, you can also filter the list of matches by signal type
using the -type option, which takes the following values:
pi — primary inputs only. This is the default.
po — primary outputs only.
pio — primary inouts only.
sig — internal signals only.
var — internal VHDL variables only.
all — all the above.
You can use one or more of these options with the same command. The filter
options do not work if there are no wildcards in the signal name you specify
with add_env_port -name.
The following examples show how to specify multiple -type options with the
same command:
add_env_port MyEnv -name e* -type "pi po" -constant 0
add_env_port MyEnv -name e* -type {pi po} -constant 0
These next examples show how to use wildcards to specify internal signal
values:
add_env_port MyEnv -name FIFO.gen_mem_*.memcore.* \
-constant 1 -type all
add_env_port MyEnv -name FIFO.gen_mem_*.memcore.* \

-constant 1 -type {sig var}
Note If you are setting internal signals to constant values, see also “Setting Internal
Signals to Constants” on page 257.
When you use wildcards with add_env_port -name, the following features
apply:
Magellan matches signal names based on language-specific
case-sensitivity rules.
If there is more than one add_env_port -name command entered for the
same signal, Magellan uses the last command entered.

Use the “.” to delimit hierarchical names.

Wildcard expansion does not cross instance boundaries and is not
recursive.
If the specified signal is a vector and you use a bit or part select, you must
explicitly specify the range using Verilog syntax ([lindex:rindex]).
If the specified range is greater than the vector width, Magellan pads the
left-most bits with zeros. For example:
If the design contains signal mmr_address[5:0]
add_env_port envName -name mmr_* -constant 1'b1
implies:
mmr_address[5:0] tied to 6'b000001
If the specified range is less than the vector width, Magellan ignores the
left-most bits. For example:
If the design contains signal mmr_address[5:0]
add_env_port envName -name mmr_* \
-constant 10'b1111_1011_11
implies:
mmr_address[5:0] tied to 6'b1011_11
For MDAs, the syntax is mem[row][lindex:rindex]. For example, to
set the first row in the following Verilog memory:
reg [63:0] sp.sequence [0:15]
to constant 0 values in the Magellan project file, use:

add_env_port envName -name sp.sequence[0][63:0] \
-constant 0
To set the seventeenth row in the following VHDL memory:

TYPE data_array IS ARRAY (integer range <>)
OF unsigned(7 DOWNTO 0);
SIGNAL data : data_array(0 to 32);
to constant 0 values in the Magellan project file, use:

add_env_port envName -name FIFO.memcore.data[16][7:0] \
-constant 0

If the signal name you specify does not exist in the design or the specified
range is not present, Magellan issues an error message.
Note You cannot specify constants for VHDL records, enumerated types, or
user-defined types. Magellan expects the value specified with the
add_env_port -constant option to be an explicit number. SystemVerilog
structures and interfaces are also not supported.
Automatic Range Extraction for Vectors and Memories

You don’t need to specify vector or MDA widths with the add_env_port
-name command. Magellan automatically extracts the widths from the design
(taking into account design parameters). If you specify the ranges in the
project file, Magellan extracts the widths based on the signal type (vector or
memory). The following examples show how this works.
For this vector: reg mmr_address[5:0];

add_env_port envName -name mmr_address[0]
translates to mmr_address[0]
and:
add_env_port envName -name mmr_address
translates to mmr_address[5:0]
For this memory: reg [63:0] sequence [0:15];

add_env_port envName -name sp.sequence[7]
translates to sp.sequence[7][63:0]
and:
add_env_port envName -name sp.sequence[7:9][20:0]

and:
add_env_port envName -name sp.sequence[7:9][0]
translates to sp.sequence[7][0]
and:
add_env_port envName -name sp.sequence[7:8]
and:
add_env_port envName -name sp.sequence
...
Setting Internal Signals to Constants

You can also use add_env_port commands to force internal design signals
to constant values during the Random Generation phase, as shown in the
following example:
add_env_port envName -name des.sigA -constant 0
To unambiguously force an internal signal, you need to specify the point in the
design hierarchy closest to the signal driver. This kind of force in Magellan
works just like a force in VCS; it affects only downstream portions of the
design logic. Figure 41 shows a design diagram to illustrate how this works.
In Figure 41, if we assume that the rst signal is in instances A,B,C,D, and E,
Table 8 explains how the forces work.

Figure 41: Setting Internal Signals to Constants
A
B
E
D C
rst
Table 8: Setting Internal Signals to Constants
Forcing this signal Affects
A.rst only A.rst and A.C.rst
A.C.rst only A.C.rst
A.B.E.rst only A.B.E.rst
A.B.rst A.B.rst, A.C.rst, A.rst, and A.B.E.rst
A.B.D.rst all rst signals
To set a portion of an internal vector to a constant value, specify the bits using
an add_env_port command. The following example assigns a constant to
the 16 least significant bits of internal design signal des.busB.
add_env_port envNname -name des.busB[15:0] \

-constant 16’h1FFF
For example, let’s assume the design has three levels of hierarchy and d_top
is the top level of the design. It contains a signal named rstInt that you want

to force to a constant value. This signal is generated inside a module named

misc, as shown in Example 52.
Example 52: Design Example for Setting Internal Signals to Constants
module d_top(..);
wire rstInt;
...
misc d_misc(...);
endmodule
module misc(...);
...
myflop _rst(.d(rstIn), .clk(clk), .q(rstOut) ...
endmodule
For the design shown in Example 52, you can use the following commands in
the Environment module of your project file to force the rstInt signal as close
as possible to the signal driver:
add_env_port envName -name d_top.d_misc._rst.q -reset 1
add_env_port envName -name d_top.d_misc._rst.q -constant 0
Instead of:
add_env_port envName -name d_top.rstInt -reset 1

add_env_port envName -name d_top.rstInt -constant 0
Forcing Input Signals to Have Random Values

If you have more than one input port in your environment with the same name,
Magellan connects the signals and applies the same random values to them.
To break these implicit connections and force the signals to have unique
random values, use add_env_port -random commands.

Constraining Input Signals
Example 53 shows the Environment module commands to use if you have

multiple instances of a constraint model (c1, c2, and c3) and want an input
port on all instances (input1) to receive unique random values.
Example 53: Making Constraint Model Input Signals Receive Random Values
add_env_port env_1 -name c1.input1 -random


After the reset sequence completes, Magellan sends values to any input on
the design or the constraint model that isn’t driven by some other port or a
constant in the project file, except for the clock port. Without any constraints,
these values are random.
Note Constraints are not used during the Reset phase. The Reset phase is entirely
user-directed, and does not use random stimulus.
During the Random Generation phase, constraints ensure that Magellan

applies legal stimulus to the design. Constraints are essential for generating
correct high-coverage stimulus and eliminating false violations of property
checkers.
Understanding Constraint Models in Magellan

There are two types of constraint models in Magellan:
Generator-style Constraints
Assertion-style Constraints
Generator-style Constraints
Generator-style constraints accept random inputs and design outputs and
generate legal inputs to the design. Generator-style constraints must be
written in synthesizable RTL.

Preparing the Environment Constraining Input Signals
Assertion-style Constraints
An assertion-style constraint is a logical assertion about the correctness of the
input stimulus—a piece of verification code that monitors the inputs to the
design for compliance with a property. The checker signals a warning if the
inputs violate the assertion. Assertion-style constraints must be written in
synthesizable SVA, PSL, OVA, or RTL.
Note You can reuse property checkers written to check for correct outputs on one
block in a large design as constraints for adjacent blocks where the same
signals are inputs.
You can also include assertion-style constraints in a system-level verification

environment to check if the entire system adheres to the properties. This may
provide some protection against the error of verifying blocks using constraints
that are not correct.
To control dynamic formal stimulus generation, assertion-style constraints

must directly involve design input signals. In general, you cannot write a
property that is only connected to design inputs through complex sequential
logic and expect Magellan to always generate stimulus that satisfies the
property. It is practical, however, to write constraint properties that depend on
both design inputs and design outputs.
Over-Constraining and Under-Constraining Inputs

It is sometimes difficult to write a constraint model that is completely accurate.
In this case, it may be necessary to either over- or under-constrain the inputs,
or to use multiple constraint models.
With over-constrained inputs, some legal input sequences are not applied to
the design, as shown in Figure 42. In this situation it is possible to miss
defects that would have been detected with a full set of legal inputs. It is also
possible that a property proven with this environment will not be proven with a

less constrained environment. In this case, Magellan may overestimate the

number of unreachable states in a coverage goal set.
Figure 42: Over-constrained Inputs
Illegal
Inputs
Legal Over-constrained
Inputs Inputs
With under-constrained inputs, some illegal stimulus is applied to the design,

in addition to legal stimulus, as shown in Figure 43. The most extreme case of
an under-constrained model is to have no constraint model and to use the
randomly generated inputs from Magellan. In an under-constrained
environment you may find false defects or problems that only arise because of
invalid inputs. And Magellan may overestimate the number of reached states
in a coverage goal set. On the other hand, if you prove a property in an
under-constrained environment, the proof remains valid in a more tightly
constrained environment.
Figure 43: Under-constrained Inputs
Illegal
Inputs
Legal Under-constrained
Inputs Inputs

It is possible for the stimulus to be both over-constrained and

under-constrained at the same time, as shown in Figure 44. In this situation
some illegal inputs are generated and some, but not all legal inputs are
generated.
Figure 44: Over- and Under-constrained Inputs
Illegal
inputs
Over- and
Legal Under-constrained
inputs Inputs
Connecting Constraints
Most inputs to the constraint model are randomly generated input signals from
Magellan. Constraint model output ports automatically connect to the design’s
input ports if their names are the same.
For Magellan to automatically connect signals, the signal names must match
exactly. For example, signal a on the constraint connects automatically to
signal a on the design, and signal a[0:0] on the constraint connects to
signal a[0:0] on the design. However, Magellan does not connect signal a
on the constraint to signal a[0:0] on the design, and signal a[0:1] does not
connect to a[1:0].
If you are reusing a constraint model whose port names don’t match the
design’s port names, you have two options:
Change the constraint port names to match the design’s port names.
Use cross-module references (XMRs) to tie the constraint to the design
(see “Using Cross-Module References” on page 271).

Using Generator-Style Constraints

Generator-style constraint models must be synthesizable. Example 54 shows
a simple generator-style constraint where input A must not be asserted at the
same time as input B. The inputs to the constraint are Magellan’s randomly
generated signals.
Example 54: Simple Generator-Style Constraint in Verilog
module simpleConstraint (rand_A, rand_B, A, B);

input rand_A, rand_B;
output A, B;
assign A = rand_A;
assign B = (A) ? 1’b0 : rand_B;
endmodule
Adding Generator-Style Constraints to the Project

If you are testing a mixed-language design, use an add_design_info
-vlogan (Verilog) or -vhdlan (VHDL) command in the Design module of
your project file to specify the design file that contains the constraint. If you are
testing a Verilog-only design, use a set_design_info -vcs command
instead. For VHDL-only designs, use an add_design_info -vhdlan
command. Example 55 shows the commands to add a generator-style
constraint for a Verilog-only design. This example references the constraint
shown in Example 54.
Example 55: Adding a Generator-Style Constraint

define_design des -topModule wrap_top
set_design_info -vcs { constraint.v file1.v file2.v}

add_env_block env_1 -name simpleConstraint \
-instance newCnstr1

For information on specifying design files for Magellan, see “Describing the
Design” on page 163.
Using Assertion-Style Constraints

Assertion-style constraint models must be synthesizable. Example 56 shows
the same constraint as shown in Example 54 on page 264, but written in
assertion-style instead of generator-style.
Conflicts and other bugs in assertion-style constraint models can lead to

incorrect verification results. You can use Magellan’s automatic compile-time
linting messages and runtime error messages to identify and fix bugs in
assertion-style constraints. For more information on commonly encountered
issues and good coding style for assertion-style constraints, see “Causes of
Dead-End States” on page 288 and “Avoiding Dead-End States” on page 292.
The following sections provide step-by-step instructions for adding

assertion-style constraints to Magellan projects and completed project file
examples that you can copy and modify for use with your project.
“SVA Assertion-Style Constraint” on page 52.
“Adding Assertion-Style Verilog Constraints to the Project” on page 265
“Adding Assertion-Style VHDL Constraints to the Project” on page 268
Adding Assertion-Style Verilog Constraints to the Project

Example 56 shows an assertion-style Verilog constraint.
Example 56: Simple Assertion-Style Constraint in Verilog
module simpleConstraint (A, B, fail);

input A, B;
output fail;
assign fail = A && B;
endmodule

To add an assertion-style Verilog constraint like Example 56 to a Magellan

project file, follow these steps:
1 Add the constraint file to the Design module along with your design files. In
this example, mux.v is the design we are checking and
simple_constraint.v contains the constraint. For example:
set_design_info -vcs { simple_constraint.v mux.v }
2 Use an add_env_block command to identify the constraint module name

(simpleConstraint) and instance (Chk0). The -instance name can
be any unique string. You use the instance name to connect signal names
in the constraint model to the design if the port names don’t match using an
add_env_connect command (see “Connecting Constraints” on
page 263). For example:
define_env env1 -timeUnits 100ps
add_env_block env1 -name simpleConstraint \
-instance Chk0
add_env_connect env1 -connect { mux.d1 Chk0.A
mux.d1 Chk0.B }
3 Create a Property module using a define_property -constraint

command. If the constraint is implemented in RTL, use an
add_property_info -signals command to identify the fail signal and
value (Chk0.fail 1). For example:
define_property prop1 -constraint
add_property_info prop1 -signals { Chk0.fail 1 }
4 Create a Session module that references the Environment module and the
Property module. In this example, we also create a Coverage module for a
signal in the design so that Magellan has something to check, and specify
that in the Session module as well. For example:
define_session session_1 -env env1
add_session_info session_1 -property { prop1}
add_session_info session_1 -coverage { cov1 }

Example 57 shows a completed example project file for adding the Verilog
assertion-style constraint shown in Example 56 on page 265.
Example 57: Example Project File Adding Verilog Constraint

define_project constraint

set_design_info -vcs { simple_constraint.v mux.v }

define_env env1 -timeUnits 100ps
-instance Chk0
add_env_connect env1 -connect {
mux.d1 Chk0.A
mux.d1 Chk0.B
}

define_property prop1 -constraint
add_property_info prop1 -signals { Chk0.fail 1 }

define_coverage cov1
add_coverage_info cov1 -signals { mux.c }

define_session session_1 -env env1
add_session_info session_1 -property { prop1}
add_session_info session_1 -coverage { cov1 }

Adding Assertion-Style VHDL Constraints to the Project

Example 58 shows an assertion-style VHDL constraint.
Example 58: Simple Assertion-Style Constraint in VHDL
library IEEE;
entity simpleConstraint is
port (
A : in std_logic;
B : in std_logic;
fail: out std_logic);
end simpleConstraint;
architecture structure of simpleConstraint is

begin
process (A, B)
begin
if (A = '1' and B = '1') then
fail <= '1';
else
fail <= '0';
end if;
end process;
end structure;
To add an assertion-style VHDL constraint like Example 58 to a Magellan

project file, follow these steps:
1 Add the constraint file to the Design module along with your design files. In
this example, mutex.vhd is the design we are checking and
assert_constraint.vhdl contains the constraint. For example:
define_design my_design -topModule mutex
add_design_info -vhdlan { assert_constraint.vhdl
mutex.vhd }
2 Use an add_env_block command to identify the constraint module name

(simpleConstraint) and instance (Constr0). The -instance name
can be any unique string. You use the instance name to connect signal

names in the constraint model to the design if the port names don’t match
using an add_env_connect command (see “Connecting Constraints” on
page 263). For example:
define_env env1 -timeUnits 1ns
-instance Constr0
mutex.a Constr0.A
mutex.b Constr0.B
}
3 Create a Property module using a define_property -constraint

command. Use an add_property_info -signals command to identify
the fail signal and value (Constr0.fail 1). For example:
define_property c1 -constraint
add_property_info c1 -signals { Constr0.fail 1 }
4 Create a Session module that references the Environment module and the
Property module. In this example, we also create a property for an RTL
signal in the design so that Magellan has something to check, and specify
that in the Session module as well. For example:
add_session_info s1 -property {c1 p1}

Example 59 shows a completed example project file for adding the VHDL
assertion-style constraint shown in Example 58 on page 268.
Example 59: Example Project File Adding VHDL Constraint

define_project vhdl_constraint

define_design my_design -topModule mutex
add_design_info -vhdlan { assert_constraint.vhdl
mutex.vhd }

define_env env1 -timeUnits 1ns
-instance Constr0
mutex.a Constr0.A
mutex.b Constr0.B
}

define_property c1 -constraint
add_property_info c1 -signals { Constr0.fail 1 }
define_property p1
add_property_info p1 -signals { mutex.fail 1 }

add_session_info s1 -property {c1 p1}

Overriding Default Parameters in the Environment Code

If you want to override default values for parameters in your Verilog code or
generics in your VHDL code in the Magellan environment, use an
add_env_block -parameters command. For VHDL, the -parameters
option only supports VHDL integer and natural typed top-level generics.
Note You cannot use add_env_block -parameters commands to specify or

override parameter values in your design.
The -parameters option accepts:

A list of values
The values must be in the same order as the parameters or generics in
your code.
add_env_block env -name newConstraint -instance c1 \
-parameters { 16 32 32 }
A list of name-value pairs separated by an equal sign
If you use name-value pairs with your Verilog code, you must enter the
pairs in the same order as they appear in your Verilog code.
add_env_block env -name newConstraint -instance c1 \
-parameters { busA=16 busB=32 busC=32 }
Using Cross-Module References

Cross-module references (XMRs) enable you to connect constraint model
signals to the design, drive an input on a constraint model with a signal
internal to the design, or connect signals with compatible data types in Verilog
and VHDL portions of your design.
You can also use XMRs to connect design signals to OVAs using bind
expressions. You cannot connect them directly because Verilog XMRs are not
synthesizable. For information on binding OVAs to your design, see “Writing
and Binding OVAs to Designs in Magellan” on page 329.
To add a cross-module reference, use an add_env_connect command.

Example 60 shows an XMR that ties a series of output ports from the

constraint model instance u1 to a series of input ports on the cpu, where cpu
is the module name of the design under test.
Example 60: XMR Connecting a Constraint Port to a Design Port
define_env env_1
add_env_connect env_1 -connect {
u1.portK cpu.sigB
u1.portL cpu.sigC
u1.portM cpu.sigD
}
When listing connection pairs, use the following guidelines:

Prefix all connection signals with their instance paths.
The right-side signal must be an input port, unless you are driving an
internal design signal (see “Driving Internal Design Signals” on page 273).
The left-side signal can be either an input or output port.
Do not use bus subrange notation for the right-side signal; it must be the
whole bus.
Use only square brackets for bus notation for the left-side signal ([m:n] or
[n]). Magellan does not support other forms of bus notation.
If the left-side signal is a bus, it must use bus notation even if all bits of the
bus are referenced.
Port widths must match.
Accessing Internal Design Signals

If you need to access an internal design signal within the constraint model to
drive a port on the constraint model, use a cross-module reference (XMR).
XMRs are not synthesizable, so you cannot use them directly within the
constraint model. Instead, create a port on the constraint model and connect it
to the top level of the design using an XMR in the project file.
XMRs are unidirectional. The internal design signal drives the input port on the
constraint model. For example, in Example 61, the designZ.modA.sigB

signal drives the constraint model’s portK input port on the driver0
instance. The signal path for sigB starts with the top-level module name and
descends through the instance path until you reach the signal.
Example 61: Cross-Module Reference in a Constraint Model

designZ.modA.sigB driver0.portK }
Driving Internal Design Signals

You can use an XMR to drive an internal signal that does not have any other
drivers. Undriven nets can occur if you created black boxes or commented
RTL code in your design. Magellan issues a warning when it finds an undriven
net. For example:
A primary input node was added for undriven net
’/DW_16550_wrap/Ver_mod/shift_time’. This may affect
formal search results and prevent simulation replay
of traces.
You can drive this internal signal from an environment constraint block, as
shown in Example 62.
Example 62: Cross-Module Reference Driving an Internal Signal

DW_16550_wrap.Ver_mod.shift_time constr.shift_time }
Note In this case, the right-side signal of the connect statement must be an output
port of an instance in the environment.

Debugging Constraint Models

Like all design and verification code, constraint models need to be tested to
ensure that they are functionally correct. Use the simulator to evaluate
whether the constraints are generating legal stimulus for the design. After you
build a session, you can use the random simulation scripts to test your
constraints. See “Using the Simulation Test Scripts” on page 139.
If Magellan reports dead-end states, replay the simulation and pay close
attention to the output signals of the constraint properties (see “Avoiding
Dead-End States” on page 292).
Simulation/Synthesis Mismatches with Constraints

Along with the design you are testing, Magellan also uses two models of any
constraint assertions. One is a formal model used by the constraint solver and
the other is the native code used during simulation. When the solver finds a
set of legal input stimulus that satisfies the formal model, but the simulation of
the constraint assertion reports a failure, Magellan generates the following
warning message:
Constraint: %s has incorrect value (%c) at T: %s, possibly
due to a simulation-synthesis mismatch.
The mismatch between the models can be caused by an error in the design or
the initial state of the design. One common cause is unknown (X) values
propagating from the design into a constraint assertion. If you get this
message, try running your session with the -compareAlways switch to
check for mismatches:
mgsh (alive ...)> run_session -compareAlways
Correct the source of the mismatch and then try your run again. For more
information, see “Diagnosing Mismatches” on page 465.

Constraint Examples
The constraints you need depend on your design. This section shows a variety
of common generator- and assertion-style constraints you can copy and
modify for your design.
Random But Constant Inputs

In Example 63, input A accepts a random value on the first cycle after reset
and then holds that value constant during the Random Generation phase. This
is a good approach for configuring inputs that do not change during normal
circuit operation. Setting these inputs randomly enables Magellan to explore
all possible configuration settings.
Example 63: Random But Constant Inputs in Verilog
module constConstraint (clk, reset_done, rand_A, A);

input clk, reset_done, rand_A;
output A;
reg A, A_latched;

if (~reset_done) begin
A <= 1’b0;
A_latched <= 1’b0;
end
else if (~A_latched) begin
A <= rand_A;
A_latched <= 1’b1;
end
end
endmodule
Example 64 shows the constraint from Example 63, but written in SVA instead
of Verilog RTL.
Example 64: Random But Constant Inputs in SVA
a_input_stable : assert property (@(posedge clk) ##1

$stable(A)) ;

Simple Combinational Constraints

In Example 65, input A must not be asserted at the same time as input B. You
can model this with a simple combinational circuit constraining two random
inputs.
Example 65: Simple Combinational Constraint in VHDL
library IEEE;
port (rand_A : in std_logic;
rand_B: in std_logic;
A : out std_logic;
B : out std_logic);

begin
A <= rand_A;
B <= ‘0’ when (rand_A=‘1’) else rand_B;
end structure;

Example 66 shows this same constraint written in assertion-style VHDL.
Example 66: Simple Assertion-Style Constraint in VHDL
library IEEE;
port (
A : in std_logic;
B : in std_logic;
fail : out std_logic);

begin
process (A, B)
begin
if (A = '1' and B = '1') then
fail <= '1';
else
fail <= '0';
end if;
end process;
end structure;

Legal Value Selector

Example 67 shows an input that must be one of a set of legal values. This
situation is often found with opcode or control inputs where not all input values
are supported. A combinational selector circuit generates all possible legal
values based on a random control bus.
Example 67: Legal Value Selector in Verilog
module legalConstraint (rand_OP, OP);

input [3:0] rand_OP;
output [4:0] OP;
reg [4:0] OP;
always @(rand_OP) begin

case (rand_OP)
4’h0: OP = ‘OPCODE_ADD;
4’h1: OP = ‘OPCODE_SUB;
4’h2: OP = ‘OPCODE_MUL;
default: OP = ‘OPCODE_DIV;
endcase
end
endmodule
Example 68 shows the constraint from Example 67, but in SVA instead of
Verilog.
Example 68: Legal Value Selector in SVA
a_legal_op : assert property (@(posedge clk)

OP==ÒPCODE_ADD || OP==ÒPCODE_SUB
|| OP==ÒPCODE_MUL || OP==ÒPCODE_DIV);

Handshaking
Example 69 shows a handshake constraint that asserts the data_valid
signal until the design acknowledges the data. This type of constraint requires
a simple state machine to hold the data constant until the input is
acknowledged.
Example 69: Handshake Constraint in Verilog
module hndshkConstraint (clk, reset, rand_data,

rand_gap, data_ack, data, data_valid);
input clk, reset, rand_gap, data_ack;

input [7:0] rand_data;
output data_valid;
output [7:0] data;
reg data_valid;
reg [7:0] data;
reg state; // Two state machine

if (reset) begin
data_valid <= 1’b0;
data <= 8’b0;
state <= 1’b0;
end
else begin
if (state == 1’b0 && ~rand_gap) begin
data <= rand_data;
state <= 1’b1;
end
if (state == 1’b1 && data_ack)
if (rand_gap) begin
state <= 1’b0;
end
else
data <= rand_data;
end
end
endmodule

Example 70 shows the constraint from Example 69 in SVA instead of Verilog.
Example 70: Handshake Constraint in SVA
a_hand_shake : assert property (@(posedge clk)

(!reset && data_valid && !data_ack) |=>
(data_valid && $stable(data)));
Packet Generator
Example 71 shows a packet generator model. This state machine generates a
random length sequence of bytes with sop (start of packet) and eop (end of
packet) signals. The packet length is between 8 and 255 bytes.
Example 71: Packet Generator in VHDL (Sheet 1 of 2)
library IEEE;
entity myConstraint is
port ( clk:in std_logic; reset:in std_logic;
rand_data:in std_logic_vector(7 downto 0);
rand_gap:in std_logic;
sop:out std_logic; eop:out std_logic;
data:out std_logic_vector(7 downto 0) );
constant state0 : std_logic := ‘0’;
constant state1 : std_logic := ‘1’;
end entity;
architecture packet_gen of myConstraint is

signal state : std_logic;
signal count : std_logic_vector(7 downto 0);
signal initial_count : std_logic_vector(7 downto 0);
begin
initial_count <= rand_data when (rand_data > 8)
else “00001000”;

Example 71: Packet Generator in VHDL (Sheet 2 of 2)
behavior_packet_gen: process (clk) begin

if (clk‘event and clk=‘1’) then
if (reset=‘1’) then
state <= state0;
sop <= ‘0’; eop <= ‘0’;
data <= (others => ‘0’);
else
case state is
when state0 =>

eop <= ‘0’;
if (rand_gap = ‘0’) then
data <= rand_data;
count <= initial_count - 1;
sop <=‘1’;
state <= state1;
end if;
when state1 =>

sop <= ‘0’;
data <= rand_data;
if (count = “00000000”) then
eop <= ‘1’;
state <= state0;
end if;
count <= count -1;
when others => null;

end case;
end if;
end if;
end process;
end packet_gen;

Example 72 shows the constraint from Example 71, but in SVA instead of
VHDL.
Example 72: Packet Generator in SVA
logic[7:0] counter;
always @(posedge clk)
counter <= reset? 0 : (sop==1 ? (data-1) : (counter!=0 ?
(counter-1) : 0));
a_packet_length : assert property (@(posedge clk)

sop |-> (data > 8 && data < 255));
a_assert_eop : assert property (@(posedge clk)

((counter==0 && $past(counter)!=0) |-> eop));
a_dessert_eop : assert property (@(posedge clk)

(!(counter==0 && $past(counter)!=0)) |-> !eop);
a_sop : assert property (@(posedge clk)

(counter!=0 || eop) |-> !sop);

Preparing the Environment Biasing Random Inputs
Biasing Random Inputs

Biasing is a method for influencing the probability of a given random value on
an input port. Biasing has no effect on formal analysis of properties or reached
and unreachable coverage goal states. However, correct biasing can improve
the efficiency of dynamic formal searches by increasing the chances that
random simulation will find valuable results.
When Magellan generates random inputs, in any one cycle there is a 50%
probability of the signal being high and a 50% probability of the signal being
low. For example, if a restart input on a design is not biased, there is a 50%
chance of it being asserted in any one cycle. If a desired behavior only triggers
when there are at least 100 cycles between restart assertions, there is an
extremely low probability of that occurring if the restart signal is not biased.
When the restart signal is biased so that it only has a tenth of a percent
(0.1%) probability of being asserted, then the desired behavior has a much
better chance of triggering during the simulation run.
Constraints and Biasing

Assertion-style constraints take precedence over biasing and may affect the
probability of inputs that are both constrained and biased. By default,
Magellan attempts to uniformly cover the legal input state space, not the total
input state space. For example, let’s assume that you have a valid signal
that is 1 bit and a data_bus signal that is 3 bits:
If there are no constraints on these signals, there is 50% distribution on
each input. Thus, valid is active 50% of time.
However, if the following constraint is present:
assert_never (valid && (data != 3'h5))
the constraint solver finds nine legal states:
-- valid -- -- data_bus --
0 000
0 001
0 010
0 011
0 100
0 101

0 110
0 111
1 101
Because the constraint solver provides equal distribution to each state, in

the presence of the constraint, the probability of the valid signal being
active is approximately 11%:
(1/((2**3)+1))*100
So, out of every 100 cycles, the valid signal is active 11 times.
If we extrapolate this example to a larger data bus (200 bits wide), the
distribution of states where valid is active becomes:
(1/((2**200)+1))*100 %
which is much less. In this case it can appear that the constraint solver is
taking the easy route by keeping valid inactive, but it is actually honoring
the constraints on that signal.
To improve the probability of valid being active, you can bias the signal
so that the probability of valid being active is high (for example, use Vera
biasing to make valid active approximately 80% of the time).
Using Biasing (Verilog only)

Example 73 shows the contents of a bias description file. Write the bias
description in Vera using a dist command. The bias description file does not
need to be synthesizable.
Example 73: Vera Bias File
constraint bias_ports {
cktA_write_counter_reset dist {0 := 999, 1 := 1};
cktA_read_counter_reset dist {0 := 90, 1 := 10};
cktA_pixel_read dist {0:18 :/ 35, 19:255 :/ 65};
}

In Example 73, the top-level module name is cktA. The

write_counter_reset, read_counter_reset, and pixel_read
names are design inputs. The dist expressions control the probability of
random value assignments to the inputs:
The write_counter_reset has a 0.999 probability of taking the value 0,
and a 0.001 probability of taking the value 1.
The read_counter_reset has a 90% probability of taking the value 0,
and a 10% probability of taking the value 1.
The pixel_read port is 8-bits wide on the design. It has a 35% probability
of taking a value between 0 and 18, and a 65% probability of taking a value
between 19 and 255, inclusively.
For more information on the dist command, see the Vera User Guide.
All possible values of each signal must have a non-zero probability. If an input
must never have a particular value, write a synthesizable constraint model to
restrict its value.
Note Reference a design port in the bias description file as

designTopModule_port. Reference a port on a constraint as
instanceName_port.
To include the bias file in the project, add the following command to the
Environment module:
add_env_inline envName -bias -format vera -file bias.vr

Specifying Solve Order for Constraint Solver

You can improve the chances of getting the desired biasing in the presence of
constraints by specifying a partial solve order for the constraint solver. By
solving early for inputs where biasing is important, Magellan’s constraint
solver is more likely to be free to select biased random values for those inputs.
Use an add_env_info -solveOrder command in the Environment
module of your project file, as shown in the following example:
add_env_info envName -solveOrder order_file_name
To specify different solve order files for separate interfaces (for example), use
multiple solve order files. For example:
add_env_info envName -solveOrder order_file1_name

add_env_info envName -solveOrder order_file2_name
The file format for order_file_name is one or more entries of the following
form:
solve input_port_list before input_port_list;
You can specify a solve order for a bus in the natural way. For example:
solve sbs6_state_vld[7:0] before sbs7_state_vld[7:0];
Examples of Solve Order Files

In the following examples, the primary inputs of the design are i1, i2, j1, j2,
k1, and k2.
Example 1 (Basic)
solve i1, i2 before j1, j2;
With this example, the constraint solver assigns values to i1 and i2, and then
to j1, j2, k1, and k2. This is because the SystemVerilog 3.1a LRM says that
variables not explicitly ordered are solved together with the last ordered
variables.

Example 2 (Loop)
solve i1 before j1;

solve j1 before i1;
solve i1 before i2;
This is illegal in SystemVerilog 3.1a. When Magellan detects loops like this it
generates an error message followed by multiple information messages that
list the signals in the loop.
Example 3 (Splitting)
solve i1 before k1;

solve j1 before k1;
With this example, the constraint solver first solves for i1 and j1, then solves
for k1 and the rest. This is the same as:
solve i1, j1 before k1;
Example 4 (Transitivity)
solve i1 before j1;

solve j1 before k1;
With this example, the constraint solver first solves for i1, then for j1, then for
k1 and the rest.

Avoiding Dead-End States

This section explains dead-end states in Magellan: what causes them, and
how to avoid them, in the following subsections:
“What are Dead-End States?” on page 288
“Causes of Dead-End States” on page 288
“Avoiding Dead-End States” on page 292
What are Dead-End States?

During the generation of random stimulus, at each system clock cycle,
Magellan examines the state of the design and any registers in the
assertion-style constraint circuits, and attempts to find a set of input values
that can simultaneously satisfy all the constraints. If there is a set of one or
more legal stimulus vectors, Magellan randomly selects one and applies it to
the design inputs. If there are no input values that can satisfy all the
constraints, Magellan has reached a dead-end state. At this point, Magellan
can no longer be sure that legal stimulus has been applied to the design, so it
issues a message, resets the design, and resumes the search from the Reset
State. If this happens more than five times during a search, Magellan issues
an informational message and switches to formal only mode (see “Run Formal
Only Mode” on page 146).
Causes of Dead-End States

Dead-end states can occur because of errors in assertion-style constraints or
errors in the design (they typically do not occur with generator-style
constraints). Here are some common causes of dead-end states in Magellan:
“Mutually Exclusive Constraints” on page 289
“Design Defects” on page 289
“Constraint Failure Not Connected to Primary Input” on page 289
“Incorrect Constraint Classification” on page 290
“Conflicting or Incomplete Constraints” on page 291
“Simulation/Synthesis Mismatches” on page 291

Preparing the Environment Avoiding Dead-End States
Mutually Exclusive Constraints

If two or more constraints are mutually exclusive, they always trigger a
dead-end state because no stimulus vector can simultaneously satisfy both.
Design Defects
If the design contains defects that affect the behavior of outputs that connect
to the constraints, dead-end states may appear when the design behavior
diverges from normal operation.
Constraint Failure Not Connected to Primary Input

If the output signal in an assertion-style constraint that indicates failure is not
controlled by a primary input to the design, this is called an input control
violation. Input control violations usually result in dead-end states. For
example, the constraint shown in Example 74 says that the number of
count_req input signals that are not acknowledged must be less than 6.
Example 74: SVA Constraint not Connected to Primary Input
reg [2:0] count_req;

if (!rstn)
count_req <= 3'd0;
else begin
if (req && !ack)
count_req <= count_req+1'b1;
else if (!req && ack)
count_req <= count_req-1'b1;
end
a1: assume property (@(posedge clk) count_req < 6);

In this example, the a1 assertion runs into a dead-end state because it is not
controlled by a primary input. Example 75 shows the corrected constraint.
Example 75: Corrected SVA Constraint
reg [2:0] count_req;

if (!rstn)
count_req <= 3'd0;
else begin
if (req && !ack)
count_req <= count_req+1'b1;
else if (!req && ack)
count_req <= count_req-1'b1;
end
a1: assume property (@(posedge clk) count_req == 5 |->

(!req || ack));
Incorrect Constraint Classification

As explained in the previous section, dead-end states can result when an
assertion-based constraint does not have at least one primary input. But
assertion-based checkers do not have to satisfy this requirement. So the style
you use when writing assertions affects whether you can use them as
checkers or constraints in Magellan. For example, the assertion shown in
Example 74 cannot be used as a constraint but can be used as an assertion
(see “Specifying Assertions as Checkers or Constraints” on page 360).

Conflicting or Incomplete Constraints

At times, Magellan is able to satisfy some but not all of the specified
constraints. A typical cause is missing or incomplete constraints. Consider
Example 76, which shows two SVA constraints.
Example 76: SVA Incomplete Constraints
A: assert property (@(posedge clk) X |-> ## 4 Z);
B: assert property (@(posedge clk) Y |-> ##2 !Z);
In Example 76, when X is asserted, Y is asserted two cycles later. Two more
cycles later, Z is overconstrained, causing a dead-end state. Clearly, Y should
not be asserted two cycles after X is asserted. Magellan generates debug
messages to alert you to conditions like this. You can prevent dead-end states
of this kind by adding the missing constraint, as shown in Example 77.
Example 77: SVA Completed Constraints
A: assert property (@(posedge clk) X |-> ## 4 Z);
B: assert property (@(posedge clk) Y |-> ##2 !Z);
C: assert property (@(posedge clk) not(X ##2 Y));
You can also use Magellan’s dead-end state avoidance feature to

automatically add the missing constraint (see “Avoiding Dead-End States” on
page 292).
Simulation/Synthesis Mismatches
Dead-end states can be caused by simulation/synthesis mismatches (see
“Detecting Simulation/Synthesis Mismatches” on page 457). For example, if
you use:
disable iff (sigA)

where sigA is an asynchronous signal (that is, neither the flip-flop nor reset
signal is defined in the Magellan project file), you encounter dead-end states
because of the resulting simulation/synthesis mismatch.
Simulation/synthesis mismatches and resulting dead-end states can also be

caused by unknowns (Xs) in the constraint fanin. When Magellan encounters
Xs in state-holding sequentials which constraint generation depends upon, it
issues an error message about “X in constrained state fanin.” At this point a
dead-end state has been reached, because the tool cannot generate a set of
legal inputs for the next random simulation cycle.
If an X value propagates to the output of an assertion, you may also see “BAD
value(X)” warning messages. BAD value(1) and BAD value(0) warning
messages are also indications of simulation/synthesis mismatch problems.To
solve this problem, debug the error and remove the Xs.

Magellan provides several tools to help you diagnose and fix problems with
the design and your constraint model that lead to dead-end states, including:
“Compile-Time Linting” on page 293
“Runtime Debug Messages” on page 293
“Using Dead-End State Avoidance on Constraints” on page 293
“Using Dead-End State Avoidance on Constraints and Design” on
page 294
“Dead-End State Avoidance Reporting” on page 295
Note You can use Magellan’s compile-time linting and runtime debug messages to
help diagnose and fix problems with constraints that can lead to incorrect
verification results.

Compile-Time Linting
Magellan generates compile-time linting messages that identify constraints
prone to dead-end states. For example:
Warning: Deadend state possible because constraint xyz
is not always controlled by DUT inputs. (HVB-430)
This feature is automatically disabled when you have dead-end state

avoidance on and the input control violation is inside a constraint (see “Using
Dead-End State Avoidance on Constraints” on page 293).
Runtime Debug Messages

Magellan also generates runtime debug messages that identify constraints
responsible for dead-end states and over-constrained design inputs. For
example:
Error: (HVSI-061)
Deadend state for constrained input at T=38626. #Cycles
since last reset:71
Information: (HVSI-406)
Constraint contributing to deadead: cu3232af.TC2.TP03
Information: (HVSI-407)
Overconstrained input: cu3232af_devsel_in_n
Note Dead-end state debug messages only examine the dead-end state itself. This
means that debug messages may not refer to the constraints that contributed
to the dead-end state in earlier cycles.
Using Dead-End State Avoidance on Constraints

Magellan can automatically generate additional constraints at compile time in
order to avoid dead-end states. This feature is called dead-end state
avoidance.
Dead-end state avoidance can be useful, but it is off by default because it also
has the potential to mask unresolved problems with your constraints that
would otherwise be reported by the compile-time linting or runtime messages.

To turn on dead-end state avoidance, add the following command to a Session

module in your project file:
set_session_info sessionName -avoidDeadends basic
With this command, Magellan searches the entire state space of the
constraints for conflicts that would cause dead-end states, and generates the
additional constraints needed to avoid them. This mode is thorough, but can
also be expensive in terms of wall clock time and memory consumption. You
can limit the number of states that Magellan examines using the following
command:
set_session_info sessionName -lookahead n
where n equals the maximum number of cycles that Magellan examines while
searching for dead-end state conditions. Use this command only after
dead-end-state avoidance has been enabled; otherwise you get an error. This
command should only be used when runtime without it is not acceptable. If
your temporal assertions are bounded to a certain number of clock cycles by
definition, you can safely set the -lookahead limit to an integer just beyond
that cycle boundary. However, if you have cascading assertions that depend
on one another, you need to add the cycle delays in all the related assertions
to develop a -lookahead limit that is effective. Otherwise, there is no
guarantee that dead-end states will be avoided in the entire state space of the
design when you limit the lookahead.
Using Dead-End State Avoidance on Constraints and Design

Dead-end state avoidance is most effective when all constraint inputs are
design primary inputs. When constraints include design outputs, dead-end
states are reduced but may not be eliminated entirely. To turn on dead-end
state avoidance on your design and constraints, add the following command to
a Session module in your project file:
set_session_info sessionName -avoidDeadends full
In this mode, Magellan avoids a larger class of dead-end states. The

-avoidDeadends full option should be used with caution, however,
because it can prevent real problems in the design from being detected by
constrained random simulation.

To turn off dead-end state avoidance, use the none option:

set_session_info sessionName -avoidDeadends none
Dead-End State Avoidance Reporting

During the build, when you have dead-end state avoidance enabled, Magellan
issues information messages to let you know if it needed to add additional
constraints to help prevent dead-end states. The messages differ based on
whether you have dead-end avoidance set to basic (set_session_info
-avoidDeadends basic) or full (set_session_info -avoidDeadends
full). If Magellan is not able to generate the additional constraints required to
avoid dead-end states, you get an error message similar to the following:
Constraints have no solution.
In this situation, the circuit never leaves the Reset State because the
constraints cannot be solved, and you are guaranteed to encounter dead-ends
during random simulation. To obtain meaningful results from Magellan you
must first debug your constraints (see “Avoiding Dead-End States” on
page 292 and “Causes of Dead-End States” on page 288).
Note If Magellan hits a resource limit during the analysis, dead-end state avoidance
is aborted and no partial information is saved.

Identifying and Debugging Constraint Conflicts

Conflicting assertion-based constraints cause dead-end states in Magellan
(see “What are Dead-End States?” on page 288 and “Causes of Dead-End
States” on page 288). When Magellan reaches a dead-end state, it issues
error and information messages similar to the ones shown in Example 78.
Example 78: Dead-end Error and Information Messages
*** Error: (HVSI-061)

DeadEnd state for constrained input at T=12426. #Cycles since last
reset:123

Constraint contributing to deadend: counter.CO.frc_down

Constraint contributing to deadend: counter.CO.frc_up
Constraint solver cannot solve for input signal : counter/UP_DOWN
The error message in Example 78 shows the simulation time when Magellan
encountered a dead-end state (12426). The information messages that follow
show the two assertion-based constraints contributing to the dead-end and the
input signal where there was a problem.
You should investigate dead-ends to determine if they indicate a problem with

the constraints or the design. If Magellan finds dead-end states after only a
few clock cycles, random simulation may not provide much value for
improving coverage or finding property violations. Note that Magellan’s formal
engines are not affected by dead-end states unless the dead-ends are caused
by errors in the constraints.

Preparing the Environment Identifying and Debugging Constraint Conflicts
Debugging Constraints
You can use a view_session_results -deadend command to analyze
dead-ends in the debugger. For the -deadend option, specify the simulation
time shown in the error message (see Example 78). DVE is the default
debugger. If you want to use Debussy or Verdi instead, see “Setting a Default
Debugger” on page 445.
Determine the root cause of the dead-end and modify the design code or
constraint before trying your run again. For example, the following command
brings up the debugger on the dead-end shown in Example 78.
mgsh(running...)> view_session_results -deadend 12426
When the waveform viewer comes up, look in the viewer for red arrows
that show where constraints failed (see Figure 45).
Figure 45: DVE Debug for Assertion-based Constraints


9
Testing Properties
This chapter introduces assertion-based property checkers, explains how to define properties,
describes a variety of assertions, and shows you how to use them to test your design in
Magellan.
In This Chapter
Understanding Properties and Property Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Choosing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Using SVAs with Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Using SVAs with VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Using OVA Checkers and Constraints (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Using Property Specification Language (PSL) Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Using OVL Checkers and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Using Verilog and VHDL Checkers and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Specifying Which Assertions are Checked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Debugging Property Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Understanding Properties and Property Checkers

A property is a logical assertion about the behavior of the design. Properties
are typically fragments of the complete design specification. For example,
“The FIFO will never overflow” or “The bus will be granted within 30 clock
cycles of a request.”
A checker is a piece of verification code that monitors the design for

compliance with a property. The checker signals a warning if the design
behavior violates the property. For Magellan to try to prove a property, the
checker must be synthesizable.
Magellan proves properties by mathematically analyzing the design, the

checker, any input constraints, and the initial state (the Reset State). A proof
indicates that for any stimulus sequence of arbitrary length, the property is
always true.
A proof is valuable because there is no need to verify the property in

simulation, and you don’t need to worry that you didn’t provide the exact
stimulus needed to expose a bug. Proofs depend on the correctness of the
checker, correctness of the input constraints, and the state to which the design
is initialized.
While looking for proofs, Magellan may also discover property violations.
Magellan generates a sequence of stimulus vectors that drives the design
from the Reset State to a state where the checker signaled a violation of the
property. The stimulus may not be the only sequence that violates the
property, and it may not be the shortest sequence. The stimulus enables you
to use standard RTL debugging techniques in the simulator. When debugging
violations, remember that property violations can be caused by errors in the
checker or the constraints, as well as by defects in the design.
There are cases where Magellan finds neither a proof nor a violation for a
particular property. This is generally a result of capacity limitations in the
formal analysis engines. Even when this occurs, the effort to write property
checkers and properly constrain the design’s inputs still provides value. If you
select the checker inputs as a coverage goal and generate stimulus that
thoroughly exercises those signals, you can be reasonably confident that the
property is true even though you could not find a proof. See “Testing RTL
Signal Coverage” on page 379.

Testing Properties Understanding Properties and Property Checkers
Why Use Assertions?

A big part of verifying digital electronic designs is testing that signals have the
right values, in the right order, at the right times. An interrupt signal must be
followed by an acknowledgement within a certain range of clock ticks. Outputs
must go to specified values one clock cycle after the reset signal goes low.
Only one of several states should be active at the same time.
With random value testing, you also want to know how many times various
actions occurred. In a PCI burst test, how many times did an abnormal
termination occur? How many times were each of several states active? Was
every type of control packet received while the buffer was full? Assertions
provide a concise declarative method to describe sequences of events, or
properties, such as these and test for their occurrence. You can write
assertions that range from very simple to extremely complex logical and
conditional combinations. You can also specify precise timing or a range of
acceptable times for sequences of events.
About Proofs and Constraints

It may be difficult to accurately constrain the input stimulus to the design. As a
result, it is important to understand the way input constraints affect proof
results. If the inputs to the design are under-constrained or unconstrained,
proofs reported by Magellan are still valid in a correctly constrained design.
Under-constraining inputs allows some illegal stimulus to be applied to the
design, in addition to all legal stimuli.
It may be worth attempting to find property proofs before developing input

constraints. If all the properties of interest are proven without constraints, you
may avoid the work of specifying the constraints. However, if Magellan finds
property violations, they could be the result of illegal stimulus applied to the
design rather than a design defect. In this case, further investigation is
required to determine if there are missing constraints.
If the inputs to the design are over-constrained, proofs reported by Magellan

may not be valid. However, violations reported by Magellan are still violations
in a correctly constrained design. Over-constraining inputs means that some
legal input sequences are not applied to the design. These inputs might have
exposed a defect. With good design understanding, it is often practical to
over-constrain the design if you are confident this won’t impact the proof

results. Another technique is to provide multiple environments (such as

multiple reset sequences) that may be individually over-constrained but
together cover all situations of interest.
It is possible for the design inputs to be both over-constrained and

under-constrained at the same time (see “Over-Constraining and
Under-Constraining Inputs” on page 261).
About Bounded Proofs

A bounded proof indicates that for any stimulus of N cycles starting from the
Reset State, the property is always true. Bounded proofs are useful if your
design uses a pipeline data path or a similar element that has a known
maximum latency; for example, the pipeline is flushed within a known period.
Magellan reports bounded proof information automatically as part of the
search process (see “Bounded Proof Reporting” on page 434).
The bounded proofs reported by Magellan are intermediate results. It is

common to see a sequence of progressively larger bounded proofs, and later
see that the property is proven or falsified.
Note For many designs that can retain state indefinitely, a bounded proof has
limited value. It does not guarantee that there is no error the way an
unbounded proof does.
You can use bounded proof results as one progress indicator for bug hunting,
but not for finding formal proofs. That’s because bounded proofs apply only to
the initial state of the design. If Magellan reports that it has reached a bounded
proof of 100 cycles, that does not mean that the formal engines cannot search
more deeply into the design state space. Magellan’s dynamic-formal
technology runs formal searches from deep states many thousands of cycles
away from the Reset State. These searches are often the key to finding
difficult, corner-case bugs, but Magellan cannot report bounded proof results
from these deep-state searches. So in many cases, bounded proof results
stop increasing long before the tool reports a final proof or falsification. A
much better progress indicator for formal proofs is state coverage measured
on signals at or near the inputs to the property checker. For more information,
see “Coverage Testing Overview” on page 380.

Testing Properties Understanding Properties and Property Checkers
Handling SVAs/OVAs During Reset

During resets, Magellan resets SVA and OVA variables to their initial values.
This is true even if the SVAs/OVAs are not used for target properties,
constraints, or coverage goals. You cannot use Magellan project commands
like set_env_reset to control SVA/OVA variables during resets like you can
for signals in your RTL design (see “Controlling the Reset State” on page 222).
As a result, it is a good idea to have resets in your SVA/OVA module
definitions.
Assertions and the Simulation Model

SVA, PSL, OVA, and OVL assertions are always present in the simulation
model, including test cases that you write out using the
write_session_test command. You may get messages from the
simulator or Magellan about these assertions even if you are not using them to
prove properties or reach coverage goals in your session run.

Choosing Properties
Choosing Properties
Choosing the properties you want to prove is important. The chance of
success for proving or disproving a property is partly driven by how you define
the property.
Magellan can only prove safety properties. A safety property specifies a

subset of safe states for the design, and requires that the design never leave
this set of safe states. All possible error traces of a safety property have a
finite length.
Magellan cannot prove fairness or liveness properties. If the English language

statement of the property includes the word eventually, it cannot be proven by
Magellan. Most eventuality properties can be converted to safety properties by
limiting the duration of the event. For example, instead of “ack eventually
follows req,” use “ack follows req within 50 cycles.”
Properties that clearly describe measurable states in the design are more
likely to result in proofs or violations. Properties that are general statements of
correctness are more difficult to prove.
Here are a few examples of design elements that often result in provable
property definitions:
Bus protocol
FIFO overflow
One-hot bus
Case statement
Illegal state detection
Here are some examples of properties that are more difficult to prove:
Global correctness of a large circuit
Large arithmetic data paths, such as a multiplier or an encryption circuit
Long duration properties, such as “The Req signal is followed by an Ack
signal within 10,000 cycles”

Testing Properties Using SVAs with Verilog
Using SVAs with Verilog

You can use SystemVerilog Assertions (SVAs) as a declarative method to
develop properties that you use as checkers or constraints in Magellan. This
section explains how to use SVAs with Magellan:
SVA Current Limitations
“SVA Action Block Support and Limitations” on page 306
“SVA Local Variable Support Limitations” on page 306
“Writing and Connecting SVAs to Designs in Magellan” on page 312
“SVA Usage Examples” on page 318
“Using SVAs from the Standard Assertion Library” on page 319
“Adding SVAs to the Project File” on page 320
“Specifying Which Assertions are Checked” on page 360
“Specifying Assertions as Checkers or Constraints” on page 360

Note the following limitations:
No complex clock expressions. For example:
@(posedge clock or negedge clock)
No SVAs in initial blocks.
No user-defined function calls in sequence expressions.
No recursive properties.
No “and”, “or” in properties.
No “if ... else” in properties.
No bind statements inside the modules you are binding (no self-binding).
Bound modules cannot have outputs or inouts (inputs only). For example, if
you say:
bind dut checkers chk1 (...)
checkers cannot have outputs.

No nested bind statements. Magellan does not support binding to a

module that is itself bound to some other module.
The $inset and $insetz assertion system functions are not supported.
No subroutine calls on sequence matches (LRM 17.9).
No expect statement (LRM 17.16).
Magellan supports SystemVerilog data types in SVAs, but you cannot use
unpacked unions (not synthesizable).
No use of SVA immediate assertions as constraints.
Note SVA immediate assertions in procedural always blocks may trigger in the
simulator at any time during an evaluation cycle, but Magellan’s cycle-based
fail state sampling for all types of assertions occurs only once per timestep.
This can result in immediate assertions that fail in the simulator but get proven
in the Magellan formal model. Glitches like this can also result in
simulation/synthesis mismatches (see “Detecting Simulation/Synthesis
SVA Action Block Support and Limitations

Magellan supports the use of action blocks in SVAs, and code inside these
action blocks can drive internal design signals that interact with other SVA
checkers or constraints. When using SVA action blocks with Magellan,
observe the following limitations:
The code must be synthesizable
No SVA system tasks (for example, $past, $rose, etc.)
No user-defined tasks or functions
SVA Local Variable Support Limitations

Magellan translates SVA code into synthesizable RTL so that it can build a
formal model of the design. This process has some limitations, because it is
possible to write SVAs (with or without local variables) that have no equivalent
representation in synthesizable code.

For SVAs with local variables, the RTL translation process begins with checks
for global limitations:
If any of the global limitations are not met, Magellan generates an error
message, and stops processing. The error message explains the limitation,
as shown in the following example:
Error: unsupported assignment to local variable 'i' in
negated automaton
Note An automaton is a finite state machine created by the assertion compiler and
used in the formal proof search process. When you see an error message
about a degenerate or negated automaton, you must modify the assertion in
order to use it with Magellan. Note that a degenerate automaton is a finite
state machine with only one state.
If all global limitations are satisfied, Magellan attempts a series of

translation strategies, starting with those that generate the simplest and
most efficient RTL, and progressing to more complex schemes. Each
translation scheme has its own restrictions on acceptable local variable
usage. Magellan translates assertions using the first technique for which all
restrictions are satisfied.
If none of Magellan’s translation schemes can handle the assertion,
Magellan generates an error message that explains the problem cause,
and stops processing. When you see error messages like this, you must
modify the assertion in order to use it with Magellan.
In some cases, Magellan is able to translate an assertion with local
variables, but the resulting RTL synthesizes into a larger formal model that
may inhibit the effectiveness of the formal engines. When this occurs,
Magellan generates a warning message that explains the limitation, as
shown in the following example:
Warning: use of local variable 'x' in non-separable
expression will cause less efficient RTL code to be
generated.
When you see warning messages like this, consider modifying the
assertion so that a more efficient formal model can be generated. For
example, given the warning message above, if you can modify the
assertion so that the expression is bit-separable, Magellan creates a more
efficient formal model.

Global Limitations
SVAs with local variables that violate any of the following global limitations
cause Magellan to generate an error message and stop processing. If any
assertion in a Magellan session causes a violation based on these limitations,
the tool stops building and does not generate any RTL.
No local variable assignments in the consequent of an implication.
property p1; //Not supported (assignment in consequent)
logic [2:0] x;
@(posedge clk)
enable |-> (1, x = in_data) ##[1:10] valid && (x ==

out_data);
endproperty
a1: assert property(p1);
No local variables of aggregate types (for example, struct, array, or union).

typedef struct {
int mytype;
byte payload [255:0];
} packet_t;
packet_t mypacket;
property p2; // Not supported (aggregate types)
packet_t temp;
@(posedge clk)
(pkt_valid, temp = mypacket) |-> ##5 (temp.mytype
==type_reg5);
endproperty

Only one assignment per local variable.

property p3; // Not supported (multiple assignments)
logic x;
@(posedge clk)
(en1, x = d1) or (en2, x = d2) |=> (x == rreg);
endproperty
Simplest Translation
If all of the general restrictions are met, Magellan first tries its simplest
translation scheme; this generally creates the most efficient RTL
representation. For this to work, there must be a bounded depth between the
local variable assignment and the reference.
property p4; // OK
logic [127:0] x;
(load_pipe, x=data) ##3 1'b1 |-> ##[1:7] dest_reg == x;
endproperty
Moderately Complex Translation

If the first translation scheme fails, Magellan tries a moderately complex
translation scheme. For this to work, the local vector variable reference must
use a == test on a vector variable. No functions of the variable are allowed in
the test.
property p5; // OK
logic [2:0] x;
@(posedge clk)
(a, x=data) ##1 done[->1] |=> (x == odata);
endproperty

Note Magellan could have translated the p5 assertion with the Simplest Translation
technique if it were not for the loop (the sequential depth of the property
cannot be known at compile time).
property p5a; // Not supported for this technique
logic [2:0] x;
(a, x=data) ##1 done[->1] |=> (^x == parity);
endproperty
Note Property p5a cannot be translated with this technique because of the
non-separable operation (^x == parity). However, this property is
supported using the Most Complex Translation technique.
Most Complex Translation

If the first and second translation schemes fail, Magellan tries its most
complex translation scheme. This is a more general technique that can
generate a large amount of logic if the local variable can take on a large
number of values, or if there are multiple local variables used in a sequence or
property. If Magellan cannot translate the assertion with this last technique, it

reports an error and stops. The following coding styles cause this final
translation attempt to fail.
No local variable vectors wider than 10 bits.
property p6; // Not supported (too many values)
logic [127:0] x;
@(posedge clk)
(load_pipe, x = data) ##1 busy[=3] |-> ##[1:5]

data_ready && (dest != x);
endproperty
Note If you can convert the loop in p6 into a bounded range, Magellan can translate
this assertion using the Simplest Translation technique. If that isn’t possible,
but you can rewrite the compare so that it is separable, Magellan can translate
this assertion using the Moderately Complex Translation technique. There is
no limitation on the bit width of local variable vectors with either of these
techniques.
No self assignment to local variables.

property p7; // Not supported (self assignment)
logic [2:0] x;
@(posedge clk)
(start, x = 0) ##1
(x = x + (push ? 1 : pop ? -1 : 0))[*1:$] ##1 done |-> x

< 5;
endproperty

No local variable assignment in unbounded loops.

property p8; //Not supported (assign in unbounded loop)
int v_count;
logic [7:0] v_dma_addr;
@ (posedge clk)
($rose(dma_ack), v_count=1, v_dma_addr=dma_addr) ##1

(1'b1, v_count = v_count + 1)[*0:$] ##1 (done || abort)
|-> v_count ==(dma_addr - v_dma_addr);
endproperty
Writing and Connecting SVAs to Designs in Magellan

You write SVAs in separate modules or interfaces and instantiate them
directly in your design. Or write them inline with your Verilog design code. For
information on how to write SVAs, see the chapter on SystemVerilog in the
VCS/VCSi User Guide ($VCS_HOME/doc/UserGuide/vcs.pdf). For a list of
unsupported SVA constructs, see the VCS/VCSi Release Notes, version 7.1
and up ($VCS_HOME/doc/ReleaseNotes.pdf).
Note Magellan supports use of the sv_pragma compiler directive inside comments
for assertions only. You cannot put any code that needs to be synthesized
inside such comments, including assignments used by your assertions,
because it is not part of the formal model build. You can use binds for such
code instead (see “Bind the SVA” on page 318).
Avoiding Incompatible SVA Constructs

You can use SVAs in several environments with different verification tools. As
a result, there are some elements of the language that are suitable for
traditional testbench-driven testing, but not for proving properties in Magellan.
This is because, in order to prove properties, Magellan builds a formal model
of the synthesizable design and any assertions used in it. Do not write

assertions that contain non-synthesizable code like comparisons to Xs and Zs

if you want to test them in Magellan.
If you write your own assertions that are not formal-compatible and use them
in Magellan, you need to wrap them inside SVA_CHECKER_FORMAL
compiler directives (see Figure 79). Magellan automatically sets the
SVA_CHECKER_FORMAL compiler directive when it processes assertions.
Put only assertion sequences inside the else block. Variable declarations and
other logic used within the assertions must be outside of the else block.
Example 79: Wrapping Formal-incompatible SVAs for Magellan
// Magellan-compatible and simulation assertions here
ìfdef SVA_CHECKER_FORMAL
èlse
// Magellan-incompatible assertions here
èndif /* SVA_CHECKER_FORMAL*/
SVA Coding Guidelines for Magellan

Observe the following coding guidelines when writing SVAs for use with
Magellan:
Avoid the use of non-synthesizable operators such as === and !==.
Do not use liveness properties. These are properties where something is
specified to happen eventually. For example:
property eventually_gnt;
@(posedge clk) req |-> ##[4:$] gnt;
endproperty
a1: assert property(eventually_gnt);
Magellan cannot prove or falsify liveness properties. Change the

unbounded ranges in liveness properties to bounded ranges.

If you use the $isunknown system function, enable compilation of the

SVA in Magellan by adding the -svaIsUnk0 switch to the define_env
command in the Environment module of your project file. For example:
define_env env1 -sva -svaIsUnk0
When you use the -svaIsUnk0 switch, Magellan sets the return value of
the $isunknown system function to 0 in the formal model, where
unknowns don’t exist.
If you use the past operator, add a delay (##n) to avoid referencing
uninitialized values (X) of the past operator. For example:
property keep_stable;
@(posedge clk) (!reset && !ack) |->
##2(data==$past(data,2));
endproperty
a1: assert property(keep_stable);
Note $fell(A) is equivalent to $past(A) && ~A, so all the cautions about using past
values for either checks or constraints apply.
Do not try to verify behavior during the reset sequence. The Magellan
formal proof engines do not start until after the reset sequence completes.
For example, do not use reset ##1 !reset in the antecedent of
implication operators as follows:
a1 : assert property(@(posedge clk) reset ##1 !reset
|-> (a==8'd30));
Because the formal proof engines start after the reset sequence, Magellan
does not see the reset ##1 !reset, and the result is a vacuous proof.
However you can use the following code to detect the end of the reset
sequence:
a2 : assert property(@(posedge clk) $past(reset) &&
!reset |-> (a==8'd30));
When reset deasserts, $past(reset) still remembers the reset value 1;
now the formal proof engines can see $past(reset) && !reset.

Avoid verifying signals from different directions in an assertion. Consider

the following example (see Figure 46). The problem here is that this
assertion cannot be used as a constraint.
property prop;
@(posedge clk) start |-> ##[1:2] (req && rdy);
endproperty
Figure 46: Avoid Verifying Signals from Different Directions
rst
clk rdy
start Design dout
req
din
To solve this problem, break the assertion into two separate assertions:
one for the req input to use as a constraint and one for the rdy output to
use as a checker:
// Constraint for req input
property p1;
@(posedge clk) start |-> ##[1:2] req;
endproperty
// Checker for rdy output
property p2;
@(posedge clk) start |-> ##[1:2] rdy;
endproperty

Avoid only referring to registered signals or $past operators in assertions

used as constraints. For example:
property constraint_1;
@(posedge clk)
(stateVar1==2) |-> (stateVar2==1);
endproperty
a1: assert property(constraint_1);
The problem here is that this assertion tries to constrain the values already
generated in the past; this causes dead-end states in Magellan. To solve
this problem, use primary inputs in constraint assertions so that the primary
inputs can be controlled in order to satisfy the conditions of the assertion.
Avoid using a large delay and repetition range:
property prop;
@(posedge clk) disable iff (reset) $rose(req) |->

##[1:max_latency] ack;
endproperty
a1: assert property(prop);
In the previous example, when max_latency is greater than 20 but is not

overlapping transactions, use a sequential variable as follows:
reg pre_req;
pre_req <= req;
always @(posedge clk or posedge reset)
if (reset) timer <= 0;
else begin
if (!pre_req && req) timer <= 1;
else if (timer > 0 && timer <= max_latency)

timer <= timer+1;
end
assert_req_ack: assert property
(@(posedge clk) ( ack |-> (timer > 0 && timer <=

max_latency)));
When max_latency is greater than 20 and is overlapping transactions,

use a time stamp generator (counter) and a FIFO to hold the time stamp.
See version 1 of the SVA standard library req_ack_unique.v.
Handling Asynchronous Resets

If you use a disable iff (reset) expression in an assertion, as shown in
the first large delay and repetition example, you must handle the
asynchronous reset by setting the reset signal to 1 for the Reset phase and
0 for the Random Generation phase (or vice-versa). Use the following
commands in the Environment module of your project file:
add_env_port envName -name reset -reset 1
add_env_port envName -name reset -constant 0
Note Using disable iff (expression) in an assertion for any expression

that refers to an unregistered primary input causes simulation/synthesis
mismatches in Magellan. The mismatches are caused by the asynchronous
behavior of disable iff in the simulator.
In general, avoid using asynchronous inputs with disable iff. For

example, the following expression:
@(posedge clk) disable iff (input1)
results in simulation/synthesis mismatches because the simulator sees the

input1 change immediately, but the formal model only sees the change at
the next posedge of clk.

SVA Usage Examples

The following examples show three different ways to use the
assert_implication.v SVA from the standard assertion library in your design:
Instantiate the SVA
Bind the SVA
Inline the SVA
Instantiate the SVA

You can instantiate SVAs as shown in Example 80, which uses the
assert_implication.v.
Example 80: Instantiate SVA
assert_implication end_bit
(uart_clk,1'b1,v_bit_count==160,uart_XMIT_dataH);
Bind the SVA

You can bind SVAs as shown in Example 81, which uses the
assert_implication.v. Note that SVA bind statements can be inside a module
(as shown in this example) and specified along with your other design files in
the Design module of your Magellan project file (see Example 83). However,
you cannot put a bind statement inside the module you are binding (no
self-binding). In that case, move the bind statement outside of the module
definition.
Example 81: Bind SVA
module bindings;
bind uart_sva assert_implication end_bit (

uart_clk,1'b1,v_bit_count==160,uart_XMIT_dataH );
endmodule

Inline the SVA

You can inline SVAs as shown in Example 82, which uses the uart_checker.v.
Example 82: Inline SVA
prop_2xmits:
assert property(@(posedge uart_clk)
gotXmit_w |-> ##1 (xmitH == 1'b0) );
Cover_count_160: cover property
(@(posedge uart_clk) (v_bit_count==160) );
Using SVAs from the Standard Assertion Library

To use predefined assertions from the SVA standard assertion library, follow
these steps, and see Example 83 on page 321:
1 Use the VCS -y switch with the set_design_info -vcs command in

the Design module of your project file to specify the SystemVerilog files that
contain the assertions, in addition to your design files.
2 Specify the VCS include file directory as

+incdir+$VCS_HOME/packages/sva.
3 Set the +define+ASSERT_ON compiler directive. The ASSERT_ON

compiler directive turns on assertions in the SVA standard assertion library.
You can also use this compiler directive to bracket assertions that you write
if you want to be able to toggle between having all assertions (user-written
and from the SVA standard assertion library) on or off at the same time.

Magellan automatically sets the SVA_CHECKER_FORMAL compiler

directive when it processes assertions from the SVA library.
Note The assert_driven assertion from the SVA standard assertion library is not
compatible with formal analysis. Also, assert_never,
assert_no_contention, assert_one_hot, assert_one_cold, and
assert_zero_one_hot contain both formal-compatible assertions and
non-formal-compatible assertions. Magellan ignores the
non-formal-compatible assertions.
4 To filter out error messages from checkers in the SVA library that fail in the
simulator during a Magellan run, add the SVA_CHECKER_NO_MESSAGE
compiler directive to your VCS command line in the Magellan project file
(see Example 83).
Adding SVAs to the Project File

There are two commands that you use in the project file to control processing
of SVAs (see Example 83):
Add external SystemVerilog design files that contain assertions (SVAs) to
your project using a set_design_info -vcs command in the Design
module of your project file. The -sverilog switch is required to make
VCS accept SystemVerilog constructs.
Enable inline and external SVA checking using a define_env -sva
command in the Environment module of your project file.
You only need to use the add_env_info -svaCompOpts line in your project
file if you have compiler options specific to the SVA compiler that you don’t
want Magellan to pass to VCS or the Formal build.
If you use different file name extensions for Verilog 95, Verilog 2001, and
SystemVerilog source files, you can also:
use the VCS +systemverilogext+ext option to specify the file name
extension (ext) for SystemVerilog source files. If you use the
+systemverilogext+ext option to enable compilation of SystemVerilog
files that do not use the .sv extension, you need to add another option
(+systemverilogext+.sv) to enable compilation of internal files used

Example 83: Project File Snippet for SVA Checking

set_design_info -vcs { -sverilog traffic.v assert.v
+define+SVA_CHECKER_NO_MESSAGES
+define+ASSERT_ON

define_env env1 -sva -timeUnits 100ps
add_env_info env1 -svaCompOpts “<sva_compiler_options>”

define_property prop -checker
add_property_info prop -scope { *.assert_* }
by Magellan in the simulator build. This is because Magellan names

internal files containing SystemVerilog constructs with the .sv extension.
use the VCS +verilog2001ext+ext option to specify the file name
extension (ext) for Verilog 2001 source files. If you use this option, you
can omit the +v2k switch.
use the VCS +verilog1995ext+ext option to specify the file name
extension (ext) for Verilog 95 source files. Note that Verilog 95 is the
default in VCS.
The rest of the project file syntax for using SVA assertions is in the Property
module, and works similarly for SVAs and OVAs. You add SVA assertions to
the project data using the add_property_info -scope command in the
Property module. You can select SVA assertions (single or multiple) by name,
and specify whether to use them as checkers or constraints (see “Specifying
Which Assertions are Checked” on page 360 and “Specifying Assertions as
Checkers or Constraints” on page 360).
In Example 83, Magellan checks all formal-compatible assertions in the SVA

standard assertion library that are instantiated in the design and match the
*.assert_* glob pattern. For more information on using glob patterns to
select SVAs, see “Using Pattern Matching with -scope and -ovaPath” on
page 364.

Filtering Asserts and Assumes

Magellan treats code that contains the assert or assume keyword
identically. This applies to SVA, OVA, and PSL. You specify the function of the
code using a define_property -checker or -constraint command in
the Magellan project file. And you use an add_property_info -scope
command to specify which asserts/assumes in your environment are targeted
for a particular test.
You can then optionally filter this initial set of asserts/assumes using an
add_property_info -type command. For example, if you want to only
target the SVAs in your environment that use the assert keyword and use
them as checkers, the Property module in your project file would look like
Example 84.
Example 84: Targeting SVAs with assert Keyword as Assertions

define_property p1 -checker
add_property_info p1 -scope {*} -type assert
If you want to only target the SVAs in your environment that use the assume
keyword and use them as constraints, your project file would look like
Example 85.
Example 85: Targeting SVAs with assume Keyword as Constraints

define_property p1 -constraint
add_property_info p1 -scope {*} -type assume

Testing Properties Using SVAs with VHDL
Using SVAs with VHDL

You can use SystemVerilog Assertions (SVAs) as a declarative method to
develop properties that you use as checkers or constraints in Magellan with
VHDL and mixed-language designs. Inline SVAs and SVA binds are both
supported, as explained in the following subsections:
“Avoiding Incompatible SVA Constructs” on page 324
“SVA Current Limitations” on page 324
“Adding Inline SVAs to VHDL Design Files” on page 324
“Specifying Inline SVAs in Magellan Project File” on page 326
“Specifying SVA Binds for VHDL Design Files” on page 326
“Specifying SVA Binds for VHDL in Magellan Project File” on page 327
Note For information on writing SVAs for VHDL and mixed-language designs, see
the VCS MX/VCS MXi User Guide, version 2006.06 and up
($VCS_HOME/doc/UserGuide/vcsmx_ug.pdf).
For details on current limitations and unsupported SVA constructs, see the
VCS MX/VCS MXi Release Notes, version 2006.06 and up
($VCS_HOME/doc/VCSMXReleaseNotes.pdf).

Avoiding Incompatible SVA Constructs

You can use SVAs in several environments with different verification tools. As
of the synthesizable design and any assertions used in it. Do not write
assertions that contain non-synthesizable code like comparisons to Xs and Zs
if you want to test them in Magellan.

The SVA limitations for Verilog designs also apply to VHDL designs. This
includes:
“SVA Current Limitations” on page 305
“SVA Coding Guidelines for Magellan” on page 313.
In addition, when using SVAs with VHDL and mixed-language designs, you
cannot use local variables in the SVAs.
Adding Inline SVAs to VHDL Design Files

You write inline SVAs in the form of comments that start with the --sva
keyword, as shown in Example 86. The check_counter in this example is

instantiated as a component in another design file (counter.vhd) that contains

the counter entity and architecture.
Example 86: Inline SVA in VHDL Design File
library IEEE;
use IEEE.std_logic_arith.all;
entity check_counter is
generic (width : integer := 16);
port (resetn : in std_logic;
clk : in std_logic;
count_end : in std_logic;
count_start : in std_logic;
count_active : in std_logic;
request_in : in std_logic;
accum : in std_logic_vector(width - 1 downto 0));
end entity;
architecture checker of check_counter is
signal precounter : std_logic_vector(width - 1 downto 0);
begin
--sva svachk: assert property (@(posedge clk) (precounter <=

accum));
P1 : process
begin
wait until (clk'event and clk = '1');
if (resetn = '0') then
precounter <= (others => '0');
else
if (count_start = '1') then
else
if (count_active = '1') then
precounter <= precounter + 1;
else
if (count_end = '1') then
precounter <= accum;
end if;
end if;
end if;
end if;
end process;
end architecture;

Specifying Inline SVAs in Magellan Project File

Add the -sva switch to the add_design_info -vhdlan command you
specify in the Design module of your Magellan project file to enable
compilation of VHDL design files that contain inline SVA assertions. Then add
the -sva switch to the define_env command you use in the Environment
module of the project file to enable SVA checking in Magellan. Example 87
shows the project file used to check the inline SVA shown in Example 86.
Example 87: Inline SVA with VHDL Magellan Project File

define_project vhdl_sva

define_design counter -topModule COUNTER
add_design_info -vhdlan "-sva check_counter.vhd"
add_design_info -vhdlan counter.vhd

define_env env -sva -timeUnits 1ns
add_env_port env -name COUNTER.clk -clock 100
add_env_port env -name COUNTER.resetn -reset 0
add_env_port env -name COUNTER.resetn -constant 1

define_property p1
add_property_info p1 -scope { *SVACHK* }

add_session_info s1 -property { p1 }
Specifying SVA Binds for VHDL Design Files

Specify SVA binds in a separate SystemVerilog design file, as shown in
Example 88.
Example 88: Bind SVA to VHDL Design
bind MY_VHDL RTL_SVA MY_SVA (.RST(RST), .CLK(CLK), .A(A

&& A_ENABLE), .B(B), .C(C));

In Example 88, the VHDL entity for the bind is MY_VHDL and the module in the
SystemVerilog file that contains the SVAs is RTL_SVA..
Specifying SVA Binds for VHDL in Magellan Project File

Compilation order is important in this flow. Follow these steps:
1 Use a set_design_info -vcs command in the Design module of your

project file to compile the SystemVerilog file that contains the bind (see
Example 88). For example:
set_design_info -vcs { -sverilog -sva_bind
../rtl/bind_expr.v }
The -sverilog switch is required to compile SystemVerilog design files

and the -sva_bind option is required to compile bind files.
2 Use an add_design_info -vlogan command to compile the

SystemVerilog file that contains the assertions you want to bind to your
VHDL design. For example:
add_design_info -vlogan { -sverilog ../sva/rtl_sva.v }
3 Use add_design_info -vhdlan commands to compile the VHDL

design files you are testing in the correct compilation order. For example:
add_design_info -vhdlan { ../rtl/rtl.vhd }
4 Use a define_env -sva command in the Environment module to enable

SVA checking in Magellan.

Example 89 shows a completed project file for this example design.
Example 89: SVA Bind VHDL Project File
### Project Module ###

define_project sva_bind_vhdl
### Design Module ###

define_design example -topModule MY_VHDL
set_design_info -vcs { -sverilog -sva_bind
../rtl/bind_expr.v }
add_design_info -vlogan { -sverilog ../sva/rtl_sva.v }
add_design_info -vhdlan { ../rtl/rtl.vhd }
### Environment Module ###

define_env env1 -sva
add_env_port env1 -name clk -clock 10000
add_env_port env1 -name rst -reset 1
add_env_port env1 -name rst -constant 0
### Property Module ###

define_property prop1 -checker
add_property_info prop1 -scope { *ASSUME* }
### Session Module ###

add_session_info s1 -property prop1
As with other VHDL designs in Magellan, you specify the top-level entity with
the define_design -topModule command (see Example 89). However,
with this flow, Magellan automatically determines the language, so you don’t
specify the format with the define_project command as you do with other
project files.

Testing Properties Using OVA Checkers and Constraints (Verilog only)
Using OVA Checkers and Constraints (Verilog only)

You can use OpenVera Assertions (OVAs) as a declarative method to develop
properties that you use as checkers or constraints in Magellan. This section
explains how to use OVAs with Magellan, in the following subsections:
“Writing and Binding OVAs to Designs in Magellan” on page 329
“Avoiding Incompatible OVA Constructs” on page 330
“Excluding Incompatible OVA Assertions” on page 332
“Using OVAs From the Standard Unit Library” on page 333
“Adding OVAs to the Project File” on page 335
“Using Inline OVAs” on page 337
Writing and Binding OVAs to Designs in Magellan

You can write OVA assertions in files separate from your design source or use
predefined assertions from the OVA standard unit library with Magellan. OVA
files are given an .ova extension by convention. OVAs are organized into
units, which are analogous to Verilog modules. You bind OVA units to your
design using bind statements in your .ova files.
Note Before you start testing OVA assertions with Magellan, use the
-ova_lint_magellan switch with VCS to check your OVA assertions for
compatibility with Magellan’s formal analysis.
For detailed information on writing and binding OpenVera Assertions, see the
OpenVera Language Reference Manual: Assertions (in the
$VCS_HOME/doc/UserGuide directory).
Example 90 shows an example of an OVA temporal assertion file that binds

the ref_req_ctl OVA unit to the DW_memctl_miu_refctl module.

Example 90: OVA Temporal Assertion File with Bind Statement
unit ref_req_ctl (
logic clk,
logic rst_n,
logic auto_refresh_en,
logic ref_req);
clock posedge clk {

event noref_seq: (auto_refresh_en & rst_n & ~ref_req) *[16];
event ref_req_ok: if (ended noref_seq) then #1 ref_req;
}
assert chk_ref_req: check (ref_req_ok);
endunit
bind module DW_memctl_miu_refctl: ref_req_ctl inst_1 (clk, rst_n,

auto_refresh_en, ref_req);
OVA Bind Limitations

Magellan has the following limitations for OVA binds:
Magellan only supports parameters of unsized decimal constants in bind
commands.
There is no support for full Verilog expressions such as arithmetic
expressions of sized constants or Verilog expression types such as
concatenation.
Avoiding Incompatible OVA Constructs

OVAs can be used in several environments with different verification tools. As
of the synthesizable design and any assertions bound to it. Things like Xs
(which make sense in simulation) don’t exist in the formal world.

To add assertions that are compatible with Magellan’s formal and dynamic
formal analysis, avoid the OVA constructs shown in Table 9.
Table 9: Incompatible OVA Constructs
Construct Description Example
Unbounded Magellan can only prove or assert a1: check (e1);

Eventuality falsify assertions for which clock posedge clk {
every possible error trace event e1: req #[3..] ack;
event e2: plu ->> oee;
has a finite length.
}
SimTime Clock The OVA compiler requires assert a1: check (e1);
that all events be clocked event e1: e2 #2 e3;
by a signal in the design. assert a2: forbid(e4 #5 e5);
Simulation-time clocking is
not supported.
Non-synthesiz- The OVA compiler passes assert a1: check (e1);

able Boolean boolean expressions clock posedge clk {
Operators directly into the generated event e1: bus2 !== bus1;
}
HDL code. Operators that
are not synthesizable, such
as the case equality
operators, cause errors in
Magellan.
Posedge and The OVA compiler does not assert a1: check (e1);
Negedge recognize transitions to or clock posedge clk {
Semantics from an X state when event e1: req #[3..5] ack;
}
evaluating posedge and
negedge operators.
Bind Instance The OVA compiler requires bind module myModule :

Names unique bind instance ova_a_unit I1 (clk, ack,
names. They are optional in select);
simulation.
Multidimensional The OVA compiler does not unit A (clk, C)

Arrays support multidimensional logic clk;
arrays in unit port logic [0:5] C [0:5];
endunit
declarations.

Note The OVA past()operator references signal values from a pipeline of

previous values which is initialized to unknown (X). If the number of previous
cycles you specify with this operator exceeds the number for which there are
values available in the pipeline, the returned signal value is X. For example,
this is the case on the first evaluation cycle in Magellan (there are no past
values at this point). One way to work around this limitation is to put a
one-cycle delay (#1) immediately before the past()operator, as shown in
Example 64 on page 275.
Excluding Incompatible OVA Assertions

The ova_driven, ova_no_contention, and ova_multiport_fifo OVA units from
the OVA standard unit library are not compatible with formal analysis. You can
use the -ova_lint_magellan switch with VCS to check your OVA
assertions for compatibility with Magellan’s formal analysis.
You can also use the SNPS_OVA_FORMAL complier directive to control

processing of OVA assertions that are not compatible with formal analysis.
Magellan defines this directive by default when it processes OVAs.
Example 91 shows an OVA unit that uses this directive to exclude
incompatible assertions.
Example 91: OVA Unit Excluding Incompatible OVA Assertions
unit example (logic clk, logic A, logic B, logic C);
‘ifdef SNPS_OVA_FORMAL
‘else
‘endif
endunit

Using OVAs From the Standard Unit Library

Your Magellan installation includes .ova files from the standard unit library in
the $MG_HOME/platform/oc/etc/ova directory. You don’t need to specify this
location when you add OVAs to your Magellan projects because Magellan
finds the OVA units automatically. However, to see what’s available or find the
exact name of an OVA unit that you want to use, it can be helpful to look at the
source code located there.
Magellan supports all unit library assertions except ova_driven,

ova_no_contention, and ova_multiport_fifo (see “Excluding Incompatible OVA
Assertions” on page 332).
To use OVAs from the standard unit library, create a separate OVA file that
contains your OVA bind statements and point to this .ova file using an
add_env_block command in the Environment module of your project file
(see Example 92).
Note For information on OVA bind syntax, see the OpenVera Language Reference
Manual: Assertions ($VCS_HOME/doc/UserGuide/ova_lrm.pdf).

Example 92 shows a complete project file for using OVAs from the standard
unit library.
Example 92: Project File for Using OVAs from Standard Unit Library


+incdir+../Rtl +define+ASSERT_ON -ova_debug
+notimingcheck }

define_env env_1 -ova -timeUnits 100ps
add_env_port env_1 -name clk_st -clock 100
add_env_port env_1 -name rst_st -reset 0
add_env_port env_1 -name rst_st -constant 1
add_env_block env_1 -format ova -files assert.ova

define_property ova_prop -checker
add_property_info ova_prop -ovaPath { assert_range }

define_session session_1 -env env_1
add_session_info session_1 -property { ova_prop }
With this project file, you need a separate OVA file named assert.ova that
contains the bind to the OVA unit in the standard checker library that you want
to use (see Example 93). This example uses the assert_range unit.
Example 93: OVA File Binding Unit from Standard Library
bind module des_chip : assert_range ranger

#(0, 1, 0, 1)(clk_st, rst_st, output_enable);

Adding OVAs to the Project File

Magellan supports OVAs in external .ova files. You can also bind OVAs inline
with your Verilog source files.
There are two commands that you use in your project file to control processing
of OVAs (see Example 94):
Add external OVA files to your project using an add_env_block
command. You don’t need to add this command if you are only using
assertions from the OVA standard assertion library, because Magellan
finds them automatically.
Enable inline and external OVA checking using a define_env -ova
command.
Example 94: Project File Snippet for OVA Checking


define_env env1 -ova -timeUnits 100ps
add_env_block env1 -format ova -files assert.ova

add_property_info ova_prop -ovaPath \
{ ref_req_ctl.chk_ref_req }
The rest of the project file syntax for using OVA assertions is in the Property
module, and works the same way for inline and external OVAs. You select
OVA assertions for checking using an add_property_info command in the
Property module. You can select OVA assertions for checking (single or
multiple) by name (see “Assertion Naming in Magellan” on page 361).
Using OVA VCS Switches

Magellan’s OVA processing sets the VCS -ova_file, -ova_api, and
-ova_inline switches under the hood, so you don’t need to define them
yourself.

Using OVA Include Files

Magellan supports the ‘include directive in OVA code, but if the referenced
include file is not in the current working directory, you may need to specify one
or more include directories in your project file.
To use OVA include files, add the +incdir option to the VCS or command
line you specify in the Design module of your project file:
set_design_info -vcs {other_vcs_command_line_options

+incdir+Include_Dir}
Adding OVA Assertions Instantiated in Templates

With OVA, you can have one unit which instantiates multiple copies of a
template, each of which contains assertions (see Example 95).
Example 95: OVA Unit with Multiple Template Instances
template my_mutex_tmpl(en=1, clk, a, b) : {

clock posedge clk {
event ova_e_mutex : if (en) then (!(a && b));
}
assert ova_c_mutex : check(ova_e_mutex);
}
unit mg_ova_mutex (logic en, logic clk, logic a,
logic b, logic c, logic d);
my_mutex_tmpl t0 (en, clk, a, b);
my_mutex_tmpl t1 (en, clk, c, d);
endunit
bind module dut : mg_ova_mutex m0 (!rst, clk, sig1, sig2, sig3, sig4);
To pull the OVA code in Example 95 into a Magellan project, use an

add_env_block command in the Environment module of your project file. To
test just the assertion in template instance t0, use an add_property_info
-ovaPath command in the Property module of your project file (see
Example 96). Notice how the template instance name (t0) is prefixed to the
assertion name (ova_c_mutex) to produce t0_ova_c_mutex.

Example 96: Project File Snippet for Selecting OVA Assertions in Template
Instances

add_env_block env1 -format ova -files mg_mutex.ova

define_property prop_t0
add_property_info prop_t0 -ovaPath {
mg_ova_mutex.t0_ova_c_mutex
}
Or, to test all assertions in the mg_ova_mutex unit, use the following
command in the Property module of your project file:
add_property_info prop_t0 -ovaPath {mg_ova_mutex.*}
Using Inline OVAs

You include inline OVA assertions in Verilog design files by encapsulating
them in C-style comments (/* OVA_assertion_code */). Example 97
shows an example of a simple inlined OVA assertion.
Example 97: Inlined OVA Assertion in Verilog Design File
module myModuleName(<port_list_here>)
// Verilog code ...
/* ova bind assert_range ranger #(0, 1, 0, 1)(clk,

reset, quant_col_ready); */
// Verilog code ...
endmodule

The ova and bind keywords that you see in this example must be present for
Magellan to recognize and include the inlined OVA assertion.
Note OVA binds work in Magellan the same as they do in VCS. For information on
writing and binding OVA assertions, see the OpenVera Language Reference
Manual: Assertions located in the $VCS_HOME/doc/UserGuide directory.
To enable inline OVA checking, add the -ova switch to your define_env
command in the Environment module of your project file. Although you cannot
bind inline OVAs to specific instances of the module in which they appear, you
can use the add_property_info -scope or -ovaPath commands to
select where the inlined OVAs are checked by Magellan.
Note that the inline approach has the advantage of being self-documenting,
but is not as portable as keeping binds or assertions in separate .ova files.
Using Design Parameters with Inline OVA Unit Binds

You can use design parameters with inline OVA unit binds without any
additional specifications in the Magellan project file if you are using the
parameters to define vector widths or memory sizes, for example. However, if
you are:
Using a design parameter in a way that affects the number of assertions
generated in the OVA unit (for example, if you have an assert statement in
a for loop and the design parameter controls the number of loop iterations)
Setting a parameter that affects the cycle depth of an assertion. For
example:
a #<design_parameter> b

Then you need to add the -ova_exp_param switch to the VCS command
line you specify in the Design module of your project file:
set_design_info -vcs {other_vcs_command_line_options
-ova_exp_param}
Note When you use the -ova_exp_param switch, you must keep the OVA
instantiation all on one line in your file. You cannot break the instantiation
across multiple lines in a multi-line comment.
To test whether the -ova_exp_param switch is necessary, you can build the
design in Magellan first without the switch. If you get an error similar to the
following example, add the switch and rebuild the design:
Error: ova compile, ova-00701
/d/tests/BUILD/5754/miss_oh.v:[1035]:
An error has occurred while compiling assertions.
Unit parameter value expected to be constant integer.

Using Property Specification Language (PSL) Assertions

You can use Property Specification Language (PSL) as a declarative method
to develop properties that you use as checkers or constraints in Magellan.
Magellan supports the simple subset of PSL specified in the Accellera

Property Specification Language Reference Manual, version 1.1, section 4.4.4
Simple Subset. This is the same support level as VCS and VCS MX. Magellan
and the simulator both support the SystemVerilog flavor of PSL.
Magellan supports PSL vunits and inline PSL assertions in Verilog and VHDL
designs. See:
“Using PSL Assertions with Verilog” on page 342
“Using PSL Assertions with VHDL” on page 345
Avoiding Incompatible PSL Constructs

You can use PSL assertions in several environments with different verification
tools. As a result, there are some elements of the language that are suitable
for testbench-driven testing, but not for proving properties in Magellan. This is
because, in order to prove properties, Magellan builds a formal model of the
synthesizable design and any assertions used with it. Do not write assertions
that contain non-synthesizable code like comparisons to Xs and Zs if you want
to test them in Magellan.
Magellan supports clocked properties but not combinational properties,

because combinational properties are not synthesizable. A clocked property is
one that has an explicit clock declaration in the assertion (for example,
@(posedge clk)), or a default clock that applies to the assertion.
If you write your own assertions that are not formal-compatible and use them
in Magellan, you need to wrap them inside SVA_CHECKER_FORMAL
compiler directives (see Example 98). Magellan automatically sets the
SVA_CHECKER_FORMAL compiler directive when it processes assertions.

Testing Properties Using Property Specification Language (PSL) Assertions
Put only assertion sequences inside the else block. Variable declarations and
other logic used within the assertions must be outside of the else block.
Example 98: Wrapping Formal-incompatible PSL Assertions for Magellan
ìfdef SVA_CHECKER_FORMAL
èlse
èndif /* SVA_CHECKER_FORMAL*/
PSL Usage Notes

Magellan detects vacuous proofs for PSL assertions that use the implication
operator (->) and can also generate witness traces for PSL properties. For
more information, see “Vacuous Proof Reporting (SVA/PSL only)” on
page 435 and “Witness Trace Reporting (SVA/PSL only)” on page 437.
If you use PSL compiler options that you want to pass to the assertion
compiler but do not to the simulator build, specify those options using an
add_env_info -svaCompOpts command in the Environment module in
your project file.
Note You can use SVA options and features with your PSL. All compile-time and
runtime options for SVA do comparable things for PSL.
It is a good idea to name your assertions, as shown in Example 99, where p1

and p2 are assertion names. If you don’t provide names for your assertions,
Magellan makes generated names for them that are more difficult to identify in
the reports and simulator traces.

Using PSL Assertions with Verilog

You write PSL assertions inline with your Verilog code or in verification units
(vunits). Example 99 shows some PSL assertions inlined in a Verilog module.
The PSL code follows the single-line comment characters and the psl
keyword. With this example, Magellan tests the p1 and p2 assertions.
Example 99: Inline PSL Assertions in Verilog Design File
module test (clk, rstn, a, b, c);

input clk, rstn, a;
output b, c;
reg b, c;

if (!rstn)
begin
b <= 0;
c <= 0;
end
else
begin
b <= a;
c <= b;
end
// psl p1: assert never (b == 1'b1) @(posedge clk);

// psl p2: assert always ((a || b) && !c) @(posedge
clk);
endmodule
PSL Assertions with Verilog in the Project File

There are several commands that you use in the Magellan project file to
control processing of PSL assertions (see Example 100):
Add files that contain PSL assertions using a set_design_info -vcs
command in the Design module of your project file. If you are using inline
PSL assertions, add the -psl switch to enable compilation. The -psl
switch is not required when you use separate files for PSL vunits. To make
VCS recognize files that do not have a .psl extension, use the -pslfile
option.

Enable PSL checking using a define_env -psl command in the

Environment module of your project file. Note that when you enable PSL
checking, Magellan automatically looks for SVAs in your environment too.
Specify which assertions are checked using an add_property_info
-scope command in the Property module. You can select PSL assertions
(single or multiple) by name, and specify whether to use them as checkers
or constraints (see “Specifying Which Assertions are Checked” on
page 360 and “Specifying Assertions as Checkers or Constraints” on
page 360).
Example 100: Project File for PSL Checking with Verilog

define_design des -topModule test
set_design_info -vcs { test.v test.psl }

define_env env1 -psl
add_env_port env1 -name clk -clock 100
add_env_port env1 -name rstn -reset 0
add_env_port env1 -name rstn -constant 1

define_property prop -checker
add_property_info prop -scope { * }

add_session_info s1 -prop prop

Using PSL vunits with Verilog

In Example 100, test.v is a sample design file which contains a top-level
Verilog module named test. The test.psl file contains the PSL vunit
shown in Example 101. The vunit hooks up automatically to the test
module (no bind required). The signal names in your vunits must match the
signal names in your design exactly.
Example 101: PSL vunit File (test.psl) for Verilog
vunit vu1 (test) {

p1 : assert never (b == 1'b1) @(posedge clk);
p2 : assert always ((a || b) && !c) @(posedge clk);
p3 : assert always ((a || b) -> c==1'b1) @(posedge clk);
p4 : assert always ({a ; b} |-> ( 1'b0)) @(posedge clk);
p5 : assert always (a -> next[1] (b==1'b1)) @(posedge
clk); cover {a; b; c} @(posedge clk);
}

Using PSL Assertions with VHDL

You can put PSL assertions inline with your VHDL code or in verification units
(vunits). You write inline PSL assertions in the form of comments that start
with the psl keyword, as shown in Example 102. The check_counter in
this example is instantiated as a component in another design file
(counter.vhd) that contains the counter entity and architecture.
Example 102: Inline PSL Assertion in VHDL Design File
library IEEE;
use IEEE.std_logic_arith.all;
entity check_counter is
generic (width : integer := 16);
port (resetn : in std_logic;
clk : in std_logic;
count_end : in std_logic;
count_start : in std_logic;
count_active : in std_logic;
request_in : in std_logic;
accum : in std_logic_vector(width - 1 downto 0));
end entity;
architecture checker of check_counter is

signal precounter : std_logic_vector(width - 1 downto 0);
begin
-- psl default clock is rising_edge(clk);
-- psl property chk is always( precounter <= accum );
-- psl pslchk: assert chk;
P1 : process
begin
wait until (clk'event and clk = '1');
if (resetn = '0') then
else
if (count_start = '1') then
else
if (count_active = '1') then
precounter <= precounter + 1;
if (count_end = '1') then
precounter <= accum;
end if;
end if;
end if;
end if;
end process;
end architecture;

PSL Assertions with VHDL in the Project File

There are several commands that you use in the Magellan project file to
control processing of PSL assertions (see Example 103):
Add files that contain PSL assertions using add_design_info -vhdlan
commands in the Design module of your project file. If you are using inline
PSL assertions, add the -psl switch to enable compilation.The -psl
switch is not required when you use separate files for PSL vunits. To make
VCS MX recognize files that do not have a .psl extension, add the
-pslfile option.
Enable PSL checking using a define_env -psl command in the
Environment module of your project file. Note that when you enable PSL
checking, Magellan automatically looks for SVAs in your environment too.
Specify which assertions are checked using an add_property_info
-scope command in the Property module. You can select PSL assertions
(single or multiple) by name, and specify whether to use them as checkers
or constraints (see “Specifying Which Assertions are Checked” on
page 360 and “Specifying Assertions as Checkers or Constraints” on
page 360 .
Example 103: Project File for PSL Checking with VHDL

define_design counter -topModule COUNTER
add_design_info -vhdlan "check_counter1.vhd \
counter.vhd vunit1.psl"

define_env env -psl -timeUnits 1ns
add_env_port env -name resetn -reset 0
add_env_port env -name resetn -constant 1

define_property psl
add_property_info psl -scope { * }

define_session psl1 -env env
add_session_info psl1 -property { psl }

Using vunits with VHDL

Magellan supports simple assignments within vunits. Conditional assignments
are not currently supported. Example 104 shows two vunits contained in an
external PSL file (vunit1.psl) The vunits hook up automatically to the ENT
entity defined in the checkCounter1.vhd file and instantiated in the
counter.vhd file. Binds are not required for the PSL vunits. The signal
names in your vunits must match the signal names in your design exactly.
Example 104: PSL vunit File (vunit1.psl) for VHDL
vunit VU1(ENT){
default clock is rising_edge(clk);
property inchk_1 is always( internalFail.f1 = '0' );
pslchk_inline_1: assert inchk_1;
}
vunit VU2(ENT){
default clock is rising_edge(clk);
property inchk_2 is always( internalFail.f1 = '1' );
pslchk_inline_2: assert inchk_2;
}

Using OVL Checkers and Constraints

Magellan supports assertions from the Open Verification Library (OVL). For
information about the OVL library, visit the Accellera Open Verification Library
Web site:
http://www.accellera.org/activities/ovl
The following sections explain how to use OVLs with Magellan:

“Specifying SVA OVL v2.1 Assertions” on page 348
“Specifying Verilog OVL v1.8 Assertions” on page 350
“Specifying VHDL OVL v1.8 Assertions” on page 351
“Using Wildcards to Activate OVLs” on page 353
“Excluding OVL Assertions” on page 354
Specifying SVA OVL v2.1 Assertions

The Magellan-compatible implementation of SVA OVL assertions is based on
OVL v2.1. The $MG_HOME/ovl-sva directory contains SVAs for OVL v2.1 and
OVL v1.8 (for backward compatibility). The v1.8 libraries use names beginning
with assert_. The v2.1 libraries use names beginning with ovl_. You can
find the OVL documentation in the $MG_HOME/ovl-sva/docs directory.
To use the OVL v2.1 SVAs with Magellan, define the following macros in the
VCS command line you specify with the set_design_info -vcs command
in the Design module of your Magellan project file (see Example 105).
OVL_SYNTHESIS
OVL_SVA
OVL_GATING_OFF
OVL_ASSERT_ON
OVL_XCHECK_OFF
If you want to activate coverage assertions in these libraries, you also must
define the OVL_COVER_ON and OVL_COVERGROUP_OFF macros.

Testing Properties Using OVL Checkers and Constraints
To specify OVL SVA assertions in a Magellan project:
1 Instantiate, bind, or inline OVL v2.1 SVA assertions in your design just like
any other SVAs. Be sure to use the Magellan-compatible OVL SVA
assertion files located in the $MG_HOME/ovl-sva directory.
2 Add the Magellan-compatible OVL v2.1 SVA assertions to the Design

module section of your Magellan project file using a set_design_info
-vcs command (see Example 105).
Example 105: Specifying OVL 2.1 SVA Design Files

define_design my_design -topModule top
set_design_info -vcs { -sverilog design_files.v
-y $MG_HOME/ovl-sva +libext+.v
+incdir+$MG_HOME/ovl-sva/+$MG_HOME/ovl-sva/sva05
+define+OVL_SYNTHESIS+OVL_SVA+OVL_GATING_OFF+OVL_ASSER
T_ON+OVL_XCHECK_OFF+OVL_COVER_ON+OVL_COVERGROUP_OFF }

define_env env -sva
3 To enable SVA checking, use a define_env -sva command in the

Environment module of your project file (see Example 105).
4 In the Property module of your Magellan project file, you can use the
add_property_info -scope command’s wildcarding feature to pick up
all assertions that match a simple pattern. For more information, see “Using
Wildcards to Activate OVLs” on page 353.
Note Magellan does not support using the ovl_memory_async and ovl_valid_id
libraries in the OVL v2.1 SVA library as constraints.

Specifying Verilog OVL v1.8 Assertions

The Magellan-compatible implementation of OVL Verilog assertions is based
on OVL v1.8. To specify Verilog OVL assertions in a Magellan project:
1 Instantiate OVL assertions in your design just like any other design
modules. Be sure to use the Magellan-compatible OVL assertion files
located in the $MG_HOME/ovl directory.
2 Add the Magellan-compatible OVL design files to the Design module

section of your Magellan project file using a set_design_info -vcs
command and the VCS -y command-line option (see Example 106).
Example 106: Specifying OVL 1.8 Verilog Design Files

define_project uart
define_design DW_16550 -topModule DW_16550_wrap
set_design_info -vcs { design_files -y $MG_HOME/ovl
+define+ASSERT_ON +incdir+$MG_HOME/ovl +libext+.vlib }
3 Use a define_property -ovl command to define the Property module

that contains the OVL properties you want to check. Then use the
add_property_info -scope command’s wildcarding feature to pick up
all OVL instantiations that match a simple pattern. For more information,
see “Using Wildcards to Activate OVLs” on page 353.

Specifying VHDL OVL v1.8 Assertions

The Magellan-compatible implementation of VHDL OVL assertions is based
on OVL v1.8. To specify VHDL OVL assertions in a Magellan project, follow
these steps and see Example 107 to view the commands in the context of a
complete project file:
1 Instantiate OVL assertions in your design just like any other design
entities/architectures. Be sure to use the Magellan-compatible OVL
assertion files located in the $MG_HOME/ovl-vhdl directory.
2 Use an add_design_info -vhdlan command to build the

ovl_assert.vhd, ovl_assert_util.vhd, and ovl_mg_buf.vhd
files into an ACCELLERA logical library. These files contain support
routines, declarations, and functions used in the actual OVL VHDL
assertions.
3 Use add_design_info -vhdlan commands to build all the assertions

that you are using as checkers or constraints before analyzing the files that
refer to them. You can build the assertions and other design files into any
logical libraries that you choose. Make sure the design files refer to the
assertion logical libraries in binding the OVL instances. In Example 107,
the assertions are built into the ACCELLERA logical library. Check the
$MG_HOME/ovl-vhdl directory to see what assertions are currently
available.
4 Use an add_design_info -vhdlan command to build your top-level

design file into a logical library named WORK.
5 Use a define_property -ovl command to define the Property module

that contains the OVL properties you want to check, and add the
-checker or -constraint switch to the command depending on how
you want to use the OVL property (see Example 108 and Example 109).
Then use the add_property_info -scope command’s wildcarding
feature to pick up all OVL instantiations that match a simple pattern.

Example 107: Specifying OVL 1.8 VHDL Design Files

set MG_HOME path_to_install_directory
set desDir path_to_design_directory

define_design MyDesign -topModule top_entity
add_design_info -vhdlan { -w ACCELLERA
$MG_HOME/ovl-vhdl/ovl_assert.vhd
$MG_HOME/ovl-vhdl/ovl_assert_util.vhd
$MG_HOME/ovl-vhdl/ovl_mg_buf.vhd
$MG_HOME/ovl-vhdl/assert_win_unchange.vhd
$MG_HOME/ovl-vhdl/assert_never.vhd
$MG_HOME/ovl-vhdl/assert_always.vhd
$MG_HOME/ovl-vhdl/assert_zero_one_hot.vhd
$MG_HOME/ovl-vhdl/assert_implication.vhd
$MG_HOME/ovl-vhdl/assert_window.vhd }
add_design_info -vhdlan { -w DesW02 $desDir/DW02_mult.vhd
$desDir/DW02_mult_sim.vhd $desDir/DW02_components.vhd }
add_design_info -vhdlan { -w WORK $desDir/jpeg_types.vhd
$desDir/sreg_e.vhd $desDir/sreg_a.vhd $desDir/counter_e.vhd
$desDir/counter_a.vhd $desDir/dct_input_e.vhd $desDir/dct_input_a.vhd
$desDir/dct_buffer_e.vhd $desDir/dct_buffer_a.vhd
$desDir/dct_sum_1_e.vhd $desDir/dct_sum_1_a.vhd
$desDir/dct_sum_2_e.vhd $desDir/dct_sum_2_a.vhd
$desDir/dct_mult_1_e.vhd $desDir/dct_mult_1_a.vhd
$desDir/dct_mult_2_e.vhd $desDir/dct_mult_2_a.vhd
$desDir/dct_trans_e.vhd $desDir/dct_trans_a.vhd $desDir/dct_e.vhd
$desDir/dct_a.vhd $desDir/quantizer_e.vhd $desDir/quantizer_a.vhd
$desDir/runlength_e.vhd $desDir/runlength_a.vhd
$desDir/dc_encode_e.vhd $desDir/dc_encode_a.vhd
$desDir/ac_encode_num_e.vhd $desDir/ac_encode_num_a.vhd
$desDir/ac_encode_end_e.vhd $desDir/ac_encode_end_a.vhd
$desDir/ac_encode_e.vhd $desDir/ac_encode_a.vhd
$desDir/compress_e.vhd $desDir/compress_a.vhd
$desDir/huffman_e.vhd $desDir/huffman_a.vhd
$desDir/jpeg_e.vhd $desDir/ovltester.vhd }


define_property -checker -ovl property_name
add_property_info ringo -scope {*}

add_session_info s2 -property property_name

Using Wildcards to Activate OVLs

You can use the add_property_info -scope command’s wildcarding
feature to pick up all OVL instantiations that match a simple pattern. The
pattern match is on the names that you use to instantiate the OVL assertions
in your design, not the names of the OVL assertions themselves. For example,
to activate all OVLs instantiated in the top-level of your design whose names
start with assert_slave_, and use them as checkers, use the full path plus
wildcards (see Example 108).
Example 108: Using Wildcards to Activate Multiple OVL Instances as Checkers

define_property ovl_checker -checker -ovl
add_property_info ovl_checker -scope \
{ dut_RootName*assert_slave_* }
To activate a subset of all instantiated OVLs that matches a wildcard pattern

and use them as constraints instead of checkers, specify -constraint with
your define_property command (see Example 109).
Note In addition to the wildcard (*), you can also use the question mark (?) to
match a single occurrence of any character. These are the only pattern
matches that are supported with the add_property_info -scope
command for OVL Property modules.
Example 109: Using Wildcards to Activate Multiple OVL Instances as

Constraints

define_property ovl_constraint -constraint -ovl
add_property_info ovl_constraint -scope \
{ dut_RootName*.assume_*.prop_master_* }

Using Verilog and VHDL Checkers and Constraints
Excluding OVL Assertions

Use an add_property_info -scope -exclude command to exclude
one or more assertions from the check (see Example 110). In this example,
Magellan excludes from the test all assertions that have the patterns
ovl_assert_0, ovl_assert_1, ovl_assert_2, and ovl_assert_3 in
their path names.
Example 110: Using Wildcards to Exclude OVL Instances from Check

define_property ovl_checker -checker -ovl
add_property_info ovl_checker \
-scope { dut_RootName*ovl_assert_* } \
-exclude { dut_RootName*ovl_assert_0*
dut_RootName*ovl_assert_1*
dut_RootName*ovl_assert_2*
dut_RootName*ovl_assert_3* }

You can also write property checkers in Verilog or VHDL and keep them in
separate files or, in the case of Verilog, inlined with your Verilog source code.
There are a few guidelines for writing property checkers in HDL:
Checkers that you want to formally prove must be written in synthesizable
RTL code.
Write each checker in a separate module.
Use an output signal to indicate detection of a property violation.
Your checker output signals for property violations do not need to be
connected to the design. Magellan monitors the checker outputs that you
specify in the project file.
Note You can reuse property checkers written to check for correct outputs on one
block in a large design as constraints for adjacent blocks where the same
signals are inputs (see “Constraining Input Signals” on page 260).

Testing Properties Using Verilog and VHDL Checkers and Constraints
If you want to override default values for parameters in your Verilog code or
generics in your VHDL code, use an add_env_block -parameters
command (see Example 58 on page 268).
For VHDL checkers, keep them external to the design so that they are not
synthesized as part of the final circuit implementation (see “Adding External
Checkers to the Project File” on page 357).
For Verilog checkers, consider whether you want to instantiate them directly in
the design or keep them external to the design and connect them using the
Magellan project file. Table 10 describes the tradeoffs between these two
alternatives.
Table 10: Checkers in the Design Versus External to the Design
When checkers are in the design ... When checkers are external to the design ...
Connections between the design and the Each checker input is connected with a
checker are obvious. hardcoded path in the project file.
The design is modified and you need to make The design is not modified.
sure that checkers are not included in the
design implementation.
Changes to the checker require the entire Changes to the checker do not require the
design to be rebuilt by Magellan. design to be rebuilt, thus reducing the build
time.
You can easily instantiate the checker Each time you reuse the checker, you must
multiple times throughout the design. add the connections for each input in the
project file.
The project file requires only a few lines for The project file may require many lines for
each Property module. each Property module.
If the checker is written in synthesizable The checker must be written in synthesizable

code, Magellan can try to prove the property. code.
If the checker is not written in synthesizable
code, you can only attempt to find a violation
using high-coverage stimulus generation.
Magellan cannot prove the property (see
“Testing RTL Signal Coverage” on page 379).

Adding Instantiated Checkers to the Project File

(Verilog only)
Example 111 shows the instantiation of a checker that fails when signal a and
signal b are both high.
Example 111: Mutex Checker Instantiation
‘ifdef MAGELLAN
mutex chk0 (.a (i_xfer), .b (o_xfer), .fail ());
‘endif
Use the ‘ifdef MAGELLAN compiler directive to exclude the checker from
later being synthesized along with your design after it has been completely
verified. Define the +define+MAGELLAN macro in the command line you
pass to VCS with the set_design_info -vcs command in the Magellan
project file. Do not use the // synopsys translate_off directive to
exclude the checker code from synthesis. Magellan ignores the code wrapped
in this directive.
You can use Verilog cross-module references (XMRs) in your checker module
instantiations to read signal values (see Example 112). However, you cannot
use XMRs to write to signals in Magellan. XMR reads must be to signals
outside the scope of where the XMR is defined.
Example 112: Mutex Checker Instantiation with XMR
‘ifdef MAGELLAN
mutex chk0 (.a (A.i_xfer), .b (o_xfer), .fail ());
‘endif
To verify a property checker, create a Property module in the project file. You
can have as many Property modules as you want in the project file. To add a
property checker that is instantiated in the design, name the checker and add
the output signal value description.
Example 113 shows the Property module for the mutex checker shown in
Example 111. The checker indicates a violation when the fail signal is high.

Example 113: Property Module for an Instantiated Checker

define_property mutex
add_property_info mutex \
-signals { des_chip.u_des_core.chk0.fail 1 }
The signal path starts with the top-level module name and descends through
the design hierarchy until you reach the output signal. In Example 113, the top
module name is des_chip and the fail signal name is fail with a hot value
of 1.
Adding External Checkers to the Project File

Example 114 shows a Verilog checker written external to the design. The
checker fails when signal a and signal b are both high. In this example, the
// synopsys translate_off directives wrap PLI code that reports if the
checker fails when you simulate the design.
Example 114: Verilog Mutex Checker Definition
module mutex (a, b, fail);

input a;
input b;
output fail;
assign fail = a & b;
always @(fail) begin
if (fail == 1’b1)
$display (“Error: mutex checker failure: %m”);
end
endmodule

Example 115 shows the same checker from Example 114 written in VHDL.
Example 115: VHDL Mutex Checker Definition
library IEEE;
entity mutex is
port (a : in std_logic;
b : in std_logic;
fail: out std_logic );
end entity;
architecture mutex_check of mutex is

signal fail_mutex : std_logic;
begin
fail <= fail_mutex;
fail_mutex <= a and b;
-- synopsys translate_off
check_mutex: process (fail_mutex)
begin
assert (fail_mutex=‘1’) report
“Error: mutex checker failure” severity warning;
end process;
-- synopsys translate_on
end architecture;
Add the VHDL checker to Magellan’s Environment module using an

add_env_block command. If the checker’s input signal names match the
design’s output signal names, Magellan automatically connects the checker to
the design.
Note For Magellan to automatically connect signals, the signal names must match
exactly. For example, signal a on the checker connects automatically to
signal a on the design, and signal a[0:0] on the checker connects to signal
a[0:0] on the design. However, Magellan does not connect signal a on the
checker to signal a[0:0] on the design, and signal a[0:1] does not connect
to a[1:0].

If the checker’s input signal names do not match the design’s output signal
names, use an add_env_connect command to make the connection (see
Example 116).
Example 116: External VHDL Checker Project File

define_design my_design -topModule jpeg
set desDir ../VHDL
add_design_info -vhdlan {-w DesW02 $desDir/DW02_mult.vhd
$desDir/DW02_mult_sim.vhd
$desDir/DW02_components.vhd}
add_design_info -vhdlan { -w WORK
$desDir/jpeg_types.vhd $desDir/sreg_e.vhd
$desDir/sreg_a.vhd $desDir/counter_e.vhd
$desDir/counter_a.vhd $desDir/dct_input_e.vhd
$desDir/dct_input_a.vhd $desDir/dct_buffer_e.vhd
$desDir/dct_buffer_a.vhd $desDir/dct_sum_1_e.vhd
$desDir/dct_sum_1_a.vhd $desDir/dct_sum_2_e.vhd
$desDir/dct_sum_2_a.vhd $desDir/dct_mult_1_e.vhd
$desDir/dct_mult_1_a.vhd $desDir/dct_mult_2_e.vhd
$desDir/dct_mult_2_a.vhd $desDir/dct_trans_e.vhd
$desDir/dct_trans_a.vhd $desDir/dct_e.vhd
$desDir/dct_a.vhd $desDir/quantizer_e.vhd
$desDir/quantizer_a.vhd $desDir/runlength_e.vhd
$desDir/runlength_a.vhd $desDir/dc_encode_e.vhd
$desDir/dc_encode_a.vhd $desDir/ac_encode_num_e.vhd
$desDir/ac_encode_num_a.vhd
$desDir/ac_encode_end_e.vhd
$desDir/ac_encode_end_a.vhd $desDir/ac_encode_e.vhd
$desDir/ac_encode_a.vhd $desDir/compress_e.vhd
$desDir/compress_a.vhd $desDir/huffman_e.vhd
$desDir/huffman_a.vhd $desDir/jpeg_e.vhd
$desDir/jpeg_a_sc.vhd }
define_env env_mutex
add_env_port env_mutex -name clk -clock 100
## Declare the checker instance
add_env_block env_mutex -name mutex -file mutex.vhd \
-format vhdl
## Connect design signals to the checker
add_env_connect env_mutex -connect { jpeg.test_si mutex.a
jpeg.test_se mutex.b }
define_property mutex
## Declare the output signal
add_property_info mutex -signals { mutex.fail 1 }
define_session s1 -env env_mutex

Specifying Which Assertions are Checked

Magellan provides flexible project file options that you can use to check:
An assertion based on a single instance of an assert. This is useful when
you want to focus Magellan on one assertion at a time, with the possibility
of enhanced performance. See “Checking a Single Instance of an
Assertion” on page 363.
A set of assertions. This is useful when you are seeking assertion proofs
across a larger area of the design. See “Checking All Instances of an OVA
Assertion” on page 363.
Specifying Assertions as Checkers or Constraints

You can use assertions either as checkers or constraints. The syntax you use
in the Property module of your project file determines how the assertions are
applied. When you use the -checker switch with the define_property
command, Magellan uses the specified assertions to try to prove or falsify the
properties they contain. When you use the -constraint switch with the
define_property command, Magellan uses your assertions to control the
stimulus applied to the design. You cannot specify both checkers and
constraints in the same property. If you do not specify either -checker or
-constraint, -checker is the default.
Excluding Checkers or Constraints

You can use add_property_info -scope -exclude commands to
exclude assertions from the check. For example, if you have separate Verilog
files which contain assertions bound to the top-level module in your design
and want to use them as constraints, first specify those files along with your
design files. Then use an add_property_info -scope -exclude
command to exclude the constraints from the check. When you use the

Testing Properties Specifying Which Assertions are Checked
-exclude option, you must also specify the -scope this applies to in the
same add_property_info command (see Example 117).
Example 117: Excluding Checkers or Constraints

define_design top -topModule top
set_design_info -vcs { top.v rainy.v asserts.sv }
### Property Module ###
define_property checks -checker
add_property_info checks -checker -scope { top.* } \
-exclude [list good better]
define_property constraints -constraint

add_property_info constraints -scope \
{ *good* *better* }
### Environment Module ###

define_env MyEnv -sva -timeUnits 100ps
In this example, the good module is defined in the rainy.v file and the
better module is defined in the asserts.sv file. Each of those files contain
assertions bound to the top module. Assertions defined in the top module
are used as checkers, as specified by the wildcard used as a glob pattern with
the add_property_info -scope command, but the good and better
assertions bound to the top module are excluded from the check and used as
constraints for the test.
Note If you use the assert and assume keywords to specify the intended usage,
you can also filter them so that the assumes are used as constraints and the
asserts as checkers (see “Filtering Asserts and Assumes” on page 322).
Assertion Naming in Magellan

Every assertion that you use with Magellan has a set of names associated
with it which identify its location in the HDL design, and in the case of OVAs,
the OVA unit hierarchy. You use these assertion names with
add_property_info -scope or -ovaPath commands in the Property
module of your project file to select where you want your properties checked
or constraints applied. Use the -scope option if the name you are specifying
starts with a Verilog module or VHDL entity. You must use the -scope option

to select SVA, PSL, or OVL. Use the -ovaPath option if the name you are
specifying starts with an OVA unit.
For example, if you have an assertion named mutex defined in an OVA unit
bind instance named OvaUnitBind1, which is bound to a module
instantiated in the top level of your design hierarchy, one name for that
assertion is:
top.U1.OvaUnitBind1.mutex
This fully-qualified name points to a unique instance of an OVA assertion, so

you can use it to specify that Magellan check just that one instance of the OVA
assertion.
The same mutex assertion has another named associated with it that starts
with the OVA unit name:
OvaUnit.mutex
This name may not be unique. Perhaps it is bound to a module that is

instantiated multiple times in your design. You can use this name to specify
that Magellan check an assertion in more than one place.
If U1 is an instance of module A, and that module is instantiated multiple times

in the design, another name for the mutex assertion is from the module
definition perspective:
A.OvaUnitBind1.mutex
This name does not point to a unique instance of an OVA assertion. Instead it
references every instantiation of module A, which may include multiple
instances of the mutex assertion.
Note Observe the naming convention used by Magellan for assertion names, where
the OVA unit instance and assertion appear as though they are part of the
HDL design hierarchy, and the Verilog path separator character (.) is used to
separate different levels in the hierarchy. Magellan uses this same naming
convention for locating SVA, PSL, OVA, and OVL in both Verilog and VHDL
designs.

Testing Properties Specifying Which Assertions are Checked
Checking a Single Instance of an Assertion

To check a single instance of an assertion, it is convenient to use the
add_property_info -scope command in the Property module of your
project file. With this option, Magellan uses the list of modules or entities you
specify as the point of view for determining which assertions to check.
Example 118 shows a snippet from the Environment and Property modules for
the assertion shown in Example 90 on page 330. Using this example, the
chk_ref_req assertion from the ref_req_ctl unit in the assert.ova file
is the assertion that Magellan checks. The -scope option takes a list of one or
more hierarchical paths, so you can use this method to select as many or as
few assertions in the hierarchy as you want. Of course, you may want to limit
the number of assertions that you check in any one run of Magellan. You can
create multiple property modules like the one shown in this example that
reference the same Environment module, and then run the different property
modules in separate sessions.
Example 118: Project File Snippet for Single Instance of OVA Assertion


add_property_info ova_prop -scope \
{ top.alu.sel.ref_req_ctl.chk_ref_req }
Checking All Instances of an OVA Assertion

To check all instances of an OVA assertion, it is convenient to use the
add_property_info -ovaPath command in the Property module of your
project file. With this option, Magellan uses a list of OVA units and assertions
that you specify as the point of view for determining which assertions to check.
The checks apply to all instances of the modules or entities to which those
assertions are bound. This option does not work for SVAs (use the -scope
option instead). To check all instances of an OVA assertion, create a Property

module in the project file. Example 119 shows Environment and Property
modules for the assertion shown in Example 90 on page 330.
Example 119: Project File Snippet for all Instances of an OVA Assertion


add_property_info ova_prop -ovaPath \
{ ref_req_ctl.chk_ref_req }
Using this example, the chk_ref_req assertion from the ref_req_ctl unit
in the assert.ova file is the assertion that Magellan checks.
Using Pattern Matching with -scope and -ovaPath

The add_property_info -scope and -ovaPath options support the *
and ? regular expressions. You can put these regular expressions anywhere
in the path that you specify. The * matches a sequence of zero or more
characters and the ? matches any single character. If you use * or ?, and the
path also includes square brackets ([]), Magellan considers the [] to be part
of the regular expression and handles them as a character class. Because []
are also special characters in Tcl, you need to escape the square brackets for
this to work. For example:
*top.\[abc\]
If the property name contains square brackets for an index and you want
Magellan to treat it as a literal instead of a character class, you need to add
more escapes. For example:
*dut.testgen\\\\[2\\\\].p3
If there are no * or ? regular expressions in the property name and all the
characters between square brackets are integers, Magellan treats the entire
string as a literal and attempts to match it exactly. For example, xyz[10]

Testing Properties Debugging Property Checkers
matches the bit select xyz[10] and nothing else. In this case, you don’t need
to add backslashes to escape the square brackets.
Debugging Property Checkers

Debugging property checkers is as important as debugging the design. This is
true for checkers written in SVA, PSL, OVA, or synthesizable RTL (VHDL or
Verilog).
Use random simulation to demonstrate that the checker accepts correct

behavior and flags illegal behavior. After you’ve successfully built the project in
Magellan, use the generated simulation scripts to exercise the design and the
checker (see “Using the Simulation Test Scripts” on page 139).
To ensure that the checker traps illegal behavior, introduce a defect in the
design and confirm that the checker detects it.

Debugging Property Checkers

10
Testing Automatically
Extracted Properties
(AEPs)
This chapter explains how to define and test automatically extracted properties (AEPs) in
Magellan. AEPs are a good way to get started with the tool because there is minimal setup
required.
In This Chapter
Using AEP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Testing all AEP Property Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Testing all AEP Coverage Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Limiting the Scope of AEP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Using AEP Properties

You can use Magellan to find properties and coverage goals in your design
and automatically test them. These properties and coverage goals are called
Automatically Extracted Properties, or AEPs.
Magellan extracts AEPs from the design based on specifications in an AEP

module in the project file, and creates specially instrumented RTL signals in
the test environment that can be asserted or de-asserted in both the formal
and simulation models.
Note Magellan only tests the subset of AEP goals that can be targeted formally. For
example, Magellan cannot formally test coverage goals for asynchronous
design behavior, but may reach many of these goals in the simulator as a
side-effect while testing synchronous coverage goals.
Magellan can create AEPs for:

“Parallel-case Directives (Verilog only)” on page 369
“Full-case Directives (Verilog only)” on page 369
“X Assignments (Verilog only)” on page 370
“Array Boundaries (Verilog only)” on page 370
“Arithmetic Overflow (Verilog only)” on page 371
“Simultaneous Set/Reset (Verilog only)” on page 371
“Multiple Driver Bus Checks (Verilog only)” on page 372
“Conflicting Driver Bus Checks (Verilog only)” on page 373
“Toggle Coverage” on page 374
Note Magellan also used the AEP mechanism to implement code coverage tests.
For more information, see “Testing Code Coverage” on page 391.

Testing Automatically Extracted Properties (AEPs) Using AEP Properties
Parallel-case Directives (Verilog only)

For case statements with the //synopsys parallel_case directive,
Magellan can test that the case expression matches no more than one case
item expression. To test parallel-case directives in your design, use a
define_aep -parallelCase command in an AEP module in your project
file (see Example 120).
Example 120: Parallel-case AEP and Session Modules
### AEP module ###

define_aep set1 -parallelCase

define_session aep_session -env env_1
add_session_info aep_session -aep set1
Full-case Directives (Verilog only)

For case statements with the //synopsys full_case directive, Magellan
can test that the case expression matches at least one case item expression.
To test full-case directives in your design, use a define_aep -fullCase
command in an AEP module in your project file (see Example 121).
Example 121: Full-case AEP and Session Modules
### AEP module ###

define_aep set1 -fullCase


X Assignments (Verilog only)

Magellan can verify that X assignments to signals are never activated. To test
X assignments in your design, use a define_aep -xAssign command in
an AEP module in your project file (see Example 122).
Example 122: X Assignment AEP and Session Modules
### AEP module ###

define_aep set1 -xAssign

Array Boundaries (Verilog only)

For arrays with indexes which cannot be computed when the module is
compiled, Magellan can test that accesses to the array use an index within the
array bounds. To test array boundaries in your design, use a define_aep
-boundsCheck command in an AEP module in your project file (see
Example 123).
Example 123: Array Boundary AEP and Session Modules
### AEP module ###

define_aep set1 -boundsCheck


Arithmetic Overflow (Verilog only)

For arithmetic operations, Magellan can detect cases where the result of some
operation on the right-hand side of an assignment cannot be stored on the
left-hand side without changing its value, assuming the intermediate results
follow the bit-width rules of the IEEE 1364 LRM. To test arithmetic overflow in
your design, use a define_aep -arithOverflow command in an AEP
module in your project file (see Example 124).
Example 124: Arithmetic Overflow AEP and Session Modules
### AEP module ###

define_aep set1 -arithOverflow

Simultaneous Set/Reset (Verilog only)

For sequentials that have asynchronous set and reset inputs (for example, SR
flip-flops), Magellan can check that the set and reset signals are never
asserted at the same time. To test simultaneous set/reset in your design, use
a define_aep -setReset command in an AEP module in your project file
(see Example 125).
Example 125: Simultaneous Set/Reset AEP and Session Modules
### AEP module ###

define_aep set1 -setReset


Multiple Driver Bus Checks (Verilog only)

For buses with multiple drivers, Magellan can check that only one driver is
active at a time (define_aep -multiDriver) and that there is at least one
driver active at all times (define_aep -floatingBus). The tool only
instruments AEPs for multiple-driver buses that have all tristate drivers. If you
run a session that targets -multiDriver or -floatingBus checks and
Magellan finds a multiple-driver bus that contains one or more non-tristate
drivers, the tool issues an error message similar to the following and continues
processing:

BusCheck: Multiply-driven net ‘%s’ in design ‘%s’ is
driven by one or more non-tri gates.
This is a static check at compile time, so there is no need to create an AEP

target for formal testing in such cases. If you see errors like this, review and
modify your RTL. If you have other multiple-driver buses in your design that
have tristate drivers, Magellan creates targets for those and tests them during
the run.
Multiply-driven Buses
Magellan can verify for any bus in the design with multiple tristate drivers that
there is only one active driver at a time. Magellan finds the property false if two
or more drivers are active at the same time, even if the value is the same and
there is no bus conflict. To test multiply-driven buses in your design, use a
define_aep -multiDriver command in an AEP module in your project
file (see Example 126).
Example 126: Multiply-driven Bus AEP and Session Modules
### AEP module ###

define_aep set1 -multiDriver


Floating Buses
Magellan can verify for any bus in the design with multiple tristate drivers that
there is at least one driver active at all times. To test for floating buses in your
design, use a define_aep -floatingBus command in an AEP module in
your project file (see Example 127).
Example 127: Floating Bus AEP and Session Modules
### AEP module ###

define_aep set1 -floatingBus

Conflicting Driver Bus Checks (Verilog only)

Magellan can check buses driven by multiple tristate drivers for conflicts.
Conflicting driver checks fail if any pair of drivers is enabled and their data
inputs are not the same logic value. To test for buses driven by conflicting
drivers in your design, use a define_aep -conflDriver command in an
AEP module in your project file (see Example 128).
Example 128: Conflicting Driver Bus AEP and Session Modules
### AEP module ###

define_aep set1 -conflDriver


Toggle Coverage
You can use Magellan to find inferred sequentials (flip-flops or latches) that
never change state (toggle). Note that Magellan only checks for toggling of
scalar and vector sequentials; it does not check memories or other
multidimensional arrays. To test toggle coverage in your design, use a
define_aep -toggle command in an AEP module in your project file (see
Example 129). You cannot combine toggle checks with any other type of AEP
tests in the same AEP module.
Example 129: Toggle Checks AEP and Session Modules
### AEP module ###

define_aep set1 -toggle

Magellan does not create toggle coverage goals for sequentials that contain X
values after the reset sequence completes. If you have any such sequentials
in your design, Magellan issues an information message similar to the
following:

4 Sequentials with X in reset state cannot be processed using toggle
coverage
You can see a list of these sequentials in the xFile.init report in the
mg_sessionName/user directory when the reset sequence completes.
If you want to run toggle checks on such sequentials, make them not-X in the
reset state using a set_env_reset command in the Environment module of
your project file. For example:
set_env_reset env_1 -value 0 -apply before

Testing Automatically Extracted Properties (AEPs) Testing all AEP Property Goals
Testing all AEP Property Goals

To test all AEP property goals found in your design, use a define_aep
-allProps command in an AEP module in your project file (see
Example 130). When you build and run a session that references this AEP
module, Magellan scans the design source looking for places where parallel
and full case, array boundaries, X assignments, and multiply-driven and
floating bus goals can be targeted.
Example 130: AEP and Session Modules for all Properties
### AEP module ###

define_aep set1 -allProps

Testing all AEP Coverage Goals

To test all AEP coverage goals found in your design, use a define_aep
-allCovs command in an AEP module in your project file (see
Example 131). When you build and run a session that references this AEP
module, Magellan scans the design source looking for places where line,
condition, and FSM coverage goals can be targeted.
Example 131: AEP and Session Modules for all Properties
### AEP module ###

define_aep set1 -allCovs


Limiting the Scope of AEP Properties

You can use add_aep_source commands to specify that Magellan analyze
or ignore different portions of the design. You can limit the targeted tests by
file, module, instance, or signal. Note that for multiDriver or
floatingBus AEPs, the only way to limit the targeted tests is by instance
name (file, module, and signal don’t work). Example 132 shows an AEP
module that restricts Magellan to analyze a module named assert_always.
Example 132: AEP Module That Analyzes One Module in the Design
### AEP module ###

define_aep aep_1 -fullCase
add_aep_source aep_1 -module assert_always
Example 133 shows an AEP module that ignores an instance of

assert_never in the top module.
Example 133: AEP Module That Ignores an Instance
### AEP module ###

define_aep aep_1 -allProps
add_aep_source aep_1 -instance top.assert_never -ignore
Note The add_aep_source command has a number of options that you can use
to analyze portions of your design. For a complete list, type
man add_aep_source at the MG shell prompt.
Isolating Specific AEP Properties

You can test a single inferred property by adding the signal to an AEP module.
For example, to target one or more individual coverage goals, add the signal
names to an AEP module using add_aep_source -signal commands.

Testing Automatically Extracted Properties (AEPs) Limiting the Scope of AEP Properties
You can add as many individual coverage goals as you want using this
methodology, one for each add_aep_source command. Follow these steps:
1 Use a build_session command to build a session that references the

AEP module which includes the line or condition coverage goals that you
want to isolate.
2 Use a list_session_results command to identify the internal signal

names for the line and condition coverage goals that you want the tool to
focus on. The signal names are identified by the Signal lines in the report
(see Figure 55 on page 427).
3 Add the signals that you want to target using add_aep_source -signal
commands, either in the same AEP module you used for the first Magellan
build, or a new AEP module. If you use a new AEP module, you must
include the same set_aep_config -extractOpts and -covInput
commands that were used in the first build. Use one add_aep_source
-signal command for each signal you want to target. The
add_aep_source -signal command does not accept a list of signals.
4 Add the AEP module to a session and run the session. Example 134 shows
an AEP module that targets a single line coverage goal.
Example 134: AEP Module Targeting Single Line Coverage Goal
### AEP module ###

define_aep set1 -line
set_aep_config set1 -extractOpts “-cm_hier file_name”
set_aep_config set1 -covInput path_to_database \
-covDUT instance_path_name # Add if db not from Magellan
add_aep_source set1 -signal inst1.mgvcm_line_I1_L10_ID0

add_session_info s1 -aep set1
Note For information on the -cm_hier file format, see the VCS/VCSi User Guide
($VCS_HOME/doc/UserGuide/vcs.pdf).


11
Testing RTL Signal
Coverage
This chapter provides a coverage overview, explains how to use high-coverage stimulus
generation for RTL signals, and explains how to detect deadlock and livelock conditions for
signals in an RTL coverage goal set.
In This Chapter
Coverage Testing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Selecting RTL Coverage Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Defining RTL Coverage Goal Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Adding RTL Coverage Goals to the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Generating Stimulus for a Coverage Goal Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Detecting Deadlock/Livelock Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Coverage Testing Overview

There are many different aspects to coverage testing and even different ideas
about what coverage convergence means in testing modern designs.
Magellan offers several tools to help improve coverage convergence on your
design blocks. This chapter starts with an introduction to coverage types and
terminology and then explains how to use:
RTL state coverage, where you specify interesting sets of design signals
for Magellan to target (see “Selecting RTL Coverage Goals” on page 383
and “Defining RTL Coverage Goal Sets” on page 384).
Deadlock and livelock detection (see “Detecting Deadlock/Livelock
Conditions” on page 389).
Note You can also use Magellan to test:

Code coverage (see “Testing Code Coverage” on page 391).
Functional coverage (see “Testing Functional Coverage” on page 407).
Coverage Testing Approaches

One of the challenges in RTL verification is achieving completeness.
Completeness involves two different aspects:
Am I checking all the specified behaviors?
Have I exercised all the different scenarios that may be encountered by the
circuit?
The first aspect concerns coverage of the specification. The second aspect
concerns coverage of the state space of possible inputs to the design.
A common way to measure the completeness of the stimulus used to drive the
circuit is to measure coverage on the circuit implementation. There are several
different metrics for measuring circuit coverage, each with strengths and
weaknesses.
Source code coverage is a common technique for measuring stimulus

completeness. It is relatively straight-forward to measure which of the tens or
hundreds of thousands of lines of RTL source code are executed when the

Testing RTL Signal Coverage Coverage Testing Overview
design is subject to a particular stimulus stream. However, stimulus that

generates 100% code coverage may only cover a small fraction of the
possible design behaviors.
State coverage is another way to assess stimulus completeness. The

potential number of discrete states in a design is often extremely large. If there
are 2000 registers, or other state-holding elements in a design, there are
potentially 22000 discrete design states. Many of these states may be
unreachable, meaning that there isn’t any possible sequence of legal input
stimulus that will ever bring the design to that state. Nevertheless, the number
of reachable states by legal stimulus sequences is still astronomically large in
real industrial designs.
State path coverage is an even more detailed measurement of stimulus

completeness. This technique evaluates not only the design states reached,
but the transition paths between states. These transition paths may be further
classified by length. The potential number of state transition paths is infinite for
designs that can process stimulus of arbitrary length. However, measurement
of paths consisting of only two consecutive states covers all the arcs of the
state transition graph.
It is currently not practical to measure state coverage on an entire design

block. However, Magellan allows you to select a subset of the design on which
to measure and optimize state coverage. By targeting a small, potentially
problematic portion of the total design, Magellan can measure state coverage
on particular areas of interest.
Stimulus Generation for RTL State Coverage

Once you’ve identified a set of signals, Magellan uses dynamic formal
techniques to generate stimulus that maximizes state coverage on those
signals. Dynamic formal stimulus generation uses a combination of random
simulation and formal analysis.
Dynamic formal stimulus generation relies on an accurate constraint model

and a reproducible start state, or reset sequence. Under-constrained inputs
may cause Magellan to overestimate the number of reached states.
Over-constrained inputs may cause Magellan to overestimate the number of
unreachable states. See “Over-Constraining and Under-Constraining Inputs”

on page 261 and “Understanding and Controlling the Reset State” on

page 220.
Although a stimulus sequence generated by Magellan may not cover all

behaviors of the entire design, it thoroughly exercises the targeted area of the
design. In conjunction with checkers or reference models monitoring the
design for correct behavior, high-state-coverage stimulus gives a reasonable
assurance of verification completeness for behavior dependent on the
targeted area of the design.
Because Magellan uses formal analysis to guide the stimulus generation, it

may be able to achieve higher coverage with fewer simulation cycles than
random simulation alone.
While Magellan generates stimulus to hit the reachable states for the set of
signals, it also calculates which states are unreachable. Identifying the
unreachable states enables you to quantify the completeness of the coverage
for the reachable states. For example, a goal set of 8 signals has 256 potential
states. If a stimulus sequence only hits 16 states, you might be concerned
about its effectiveness because you have only hit 6% of the states. However, if
Magellan’s analysis indicates that 238 of the states are unreachable, you
know that 89% of the reachable states have been hit. You can focus your time
on reaching the remaining states with longer Magellan runs or more directed
tests.
In the best case, Magellan classifies all potential goal states as reached or
unreachable, and provides a stimulus sequence to hit all the states classified
as reached. However, due to limitations in formal engine capacity, there are
cases where some states remain unclassified. In this case, you may be able to
design a directed test to hit the remaining states, or observe that they are
actually unreachable.

Testing RTL Signal Coverage Selecting RTL Coverage Goals
Selecting RTL Coverage Goals

High-coverage stimulus generation is most useful when you focus on specific
areas of the design. Prime design elements to select for generating
high-coverage stimulus include the following:
Areas with low code coverage
Complex control interactions
Behaviors that may be difficult to reach with directed tests
Interesting signals, such as:
Finite state machine (FSM) control registers
Groups of cooperating FSMs
Status flags
Guards in case statements and nested if-then-else statements
Opcode registers
Properties that remain unclassified (not proven or falsified)
If Magellan cannot find a proof or a violation for a particular property, select
the checker inputs as a coverage goal and generate stimulus that
thoroughly exercises those signals.
Non-synthesizable checkers
Even though the Magellan formal build does not see non-synthesizable
checkers included in your RTL design, they are present in the simulator
build and can function as monitors. With high-coverage stimulus, you can
be reasonably confident that the property is true even though you could not
find a proof. Likewise, if the property is false, with high-coverage stimulus
you are more likely to detect problems.

Defining RTL Coverage Goal Sets
Defining RTL Coverage Goal Sets

A goal set is the group of signals you want to evaluate as part of a Coverage
module. The signals you choose do not have to belong to a logical group.
They can be in the design under test, the constraint model, or a checker.
The maximum number of signals you can include in a Coverage module is 52,
although a more practical limit is around 24.
If cross-state analysis is not important for a goal set, it may be practical to split
a large Coverage module into two or more Coverage modules and then
reference them from one session. As a simple example, if you have six signals
in a Coverage module, there are 64 (26) different states that Magellan
analyzes. If you divide the signal set into two Coverage modules, each with
three signals, and you run them in the same session, Magellan only has to
analyze 16 states (23+23).
Large goal sets that have many reached states generate stimulus files that
can take an extremely long time to run in the simulator. Magellan attempts to
compress the runtime of the stimulus file by removing simulation cycles from
the stimulus trace that did not cause any additional states to be reached.
Adding RTL Coverage Goals to the Project File

Once you’ve identified the signals you want to evaluate, add the goal set to a
Coverage module in the project file (see Example 135). You can have as
many Coverage modules as you want in one project file.
Example 135: Coverage Goal Set

define_coverage goalset1 -comment \
{ Checking control signals }
add_coverage_info goalset1 -signals \
{ qrm.route_current_0q[2:0] qrm.route_current_1q[2:0]}
Each signal identifier starts with the top-level module name and descends
through the instance hierarchy until it reaches the signal.

Testing RTL Signal Coverage Adding RTL Coverage Goals to the Project File
Adding Cross-State Machine Goal Sets

If you’re interested in the cross-coverage analysis of two or more finite state
machines in your design, you may be able to improve Magellan’s performance
by creating a separate Coverage module for each state machine and a
Coverage module for the combined state machine.
Example 136 shows three Coverage modules. Coverage modules cov_a and
cov_b identify each state machine separately. Coverage module cov_ab
combines the two state machines.
Example 136: Cross-State Machine Coverage Goal Sets
### Coverage module for state machine a ###

define_coverage cov_a
add_coverage_info cov_a -signals {
dws.ctlr.rx_ctl.RX_empty
dws.ctlr.rx_ctl.RX_full
}
### Coverage module for state machine b ###

define_coverage cov_b
add_coverage_info cov_b -signals {
dws.ctlt.tx_ctl.TX_empty
dws.ctlt.tx_ctl.TX_full
}
### Coverage module for state machine a and b ###

define_coverage cov_ab
add_coverage_info cov_ab -signals {
dws.ctlr.rx_ctl.RX_empty
dws.ctlr.rx_ctl.RX_full
dws.ctlt.tx_ctl.TX_empty
dws.ctlt.tx_ctl.TX_full
}
### Session module for state machines a and b ###

define_session fsm -env env_1
add_session_info fsm -coverage {
cov_a
cov_b
cov_ab
}

When you combine the three Coverage modules in a Session module,

Magellan first searches for the unreachable and reached states of each state
machine separately. Magellan uses the unreachable state information from
the first searches when it searches the combined states of the state machines,
quickly excluding unreachable states.
Checking FSM State Transition Coverage

You can use Magellan to check state transition coverage for finite state
machines (FSMs). To do this, create a state coverage goal that concatenates
the current state and next state of the FSM you want to examine into a single
coverage goal. Each value of the resulting goal set consists of a pair of state
values, one for the current cycle and one for the previous cycle. With this
technique, you capture all possible transitions of the FSM. Use an
add_coverage_info command in the Coverage module of your project file,
as shown in Example 137.
Example 137: Coverage Module for FSM State Transition Coverage

define_coverage c1
add_coverage_info c1 -signals \
{ current_state[4:0] next_state[4:0] }
You can also use Magellan AEP to test FSM state and transition coverage
targets extracted by VCS using the simulator’s coverage methodology. For
more information, see “Testing Code Coverage” on page 391.
Using VHDL Enumeration Signals in a Goal Set

Magellan interprets user-defined VHDL enumeration types as integers with
the default encoding. The default encoding is a one-to-one association
between the enumeration literals in the order they are specified in the design
file and positive integers starting with zero.

Testing RTL Signal Coverage Adding RTL Coverage Goals to the Project File
If you want to include a signal in a coverage goal set whose value is an

enumeration type, you need to know the number of bits required to store each
enumeration type. Example 138 shows a test VHDL design that has a signal
with an enumeration type which has nine possible states.
Example 138: VHDL Enumeration Type
library IEEE;
entity encoded is
port (
A : in std_logic_vector(7 downto 0);
B : in std_logic_vector(7 downto 0);
C : in std_logic_vector(7 downto 0);
D : in std_logic_vector(7 downto 0);
subout : out std_logic);
end encoded;
architecture behav of encoded is

type operation_t is (accumInit, accumOperand,
accumStatus, statusInit, compareStatusInit,
greaterStatusInit, subtract, add, idle);
signal operation : operation_t;
signal operand : std_logic_vector(7 downto 0);
signal accum : std_logic_vector(7 downto 0);
signal accum2 : std_logic_vector(7 downto 0);
signal status : std_logic_vector(7 downto 0);
begin

Example 138: VHDL Enumeration Type (Continued)
P1: process (A) begin

case (conv_integer(A)) is
when 0 => operation <= accumInit;
when 1 => operation <= accumOperand;
when 2 => operation <= accumStatus;
when 3 => operation <= statusInit;
when 4 => operation <= compareStatusInit;
when 5 => operation <= greaterStatusInit;
when 6 => operation <= subtract;
when 7 => operation <= add;
when 8 => operation <= idle;
when others => operation <= idle;
end case;
end process;
P2 : process (operation) begin

if (operation = subtract) then
subout <= '1';
else
subout <='0';
end if;
end process;
end architecture;
The nine literals require four bits to encode. Magellan classifies the unused
states as unreachable. In Example 138, the positional values 9 through 15 are
unreachable. Example 139 shows the coverage goal set for the enumeration
signal.
Example 139: Coverage Goal Set for an Enumeration Type

define_coverage enum_set
add_coverage_info enum_set -signals \
{ encoded.operation[3:0] }

Testing RTL Signal Coverage Generating Stimulus for a Coverage Goal Set
Generating Stimulus for a Coverage Goal Set

To generate stimulus for a coverage goal set, include the Coverage module in
a session, and then run the session. Example 140 shows a Session module
that runs two coverage goal sets. Each coverage goal set (goalset1 and
goalset2) is defined in a separate Coverage module in the project file.
Example 140: Session Module for FIFO Coverage Goal Set

define_session cov1 -env env1
add_session_info cov1 -coverage { goalset1 goalset2 }
To generate stimulus, read the project into MG shell and then run the session.
If necessary, Magellan automatically rebuilds the design.
Detecting Deadlock/Livelock Conditions

You can use Magellan to detect deadlock and livelock conditions for signals
defined in a coverage goal set. Deadlock occurs when Magellan detects a
state for which there is no exit transition, or the exit transition is not reachable
given legal input stimulus to the design. In this context, a state is a set of
values for the signals in a coverage goal set. Livelock occurs when Magellan
detects a small group of reachable states of a specified size n or smaller. If
there is no transition that leaves the group, this is a livelock condition.
For example, Magellan can detect deadlock conditions where two FSMs get
stuck in a state that they cannot get out of. Magellan can also detect livelock
conditions where there are multiple FSMs that are advancing from one state to
another, but in a circle that they cannot get out of. Livelock looks alive
because of the state transitions, but the subset of the design where this occurs
is stuck. Deadlock and livelock are both indicators of potential bugs in the
design. They can occur in multiple places in the state space for your coverage
goal set.
By default, Magellan reports which states are reached, unreachable, and

unknown for your coverage goal sets. When you enable deadlock or livelock
detection, Magellan reports this additional information when it detects such
conditions. To enable deadlock detection, use a define_coverage

Detecting Deadlock/Livelock Conditions
-deadlock command in the Coverage module of your project file (see

Example 141).
Example 141: Coverage and Session Modules for Deadlock Detection

define_coverage g_deadlock -deadlock
add_coverage_info g_deadlock -signals \
{pparser.cstate[3:0]}

define_session s_deadlock -env env
add_session_info s_deadlock -coverage {g_deadlock}
To enable livelock detection, use a define_coverage -livelock {n}

command in the Coverage module of your project file, where n represents the
maximum number of states you want Magellan to consider when searching for
livelock conditions (see Example 142).
Example 142: Coverage and Session Modules for Livelock Detection

define_coverage g_livelock -livelock {6}
add_coverage_info g_livelock -signals \
{pparser.cstate[3:0]}

define_session s_livelock -env env
add_session_info s_livelock -coverage {g_livelock}
When you run either of these sessions (Example 141 or Example 142),
Magellan attempts to classify all the states in the coverage goal set, and
determines if there are any deadlock or livelock states that are not
unreachable.
When your session run completes, enter a list_session_results

command at the MG shell prompt to see the deadlock or livelock report (see
Figure 47). This sample report shows that Magellan did not detect a deadlock
condition for this test. For more information on interpreting coverage reports,
see “RTL Coverage Goals Detailed Reporting” on page 428.
Figure 47: Deadlock/Livelock Report
DeadLock Report (Count: 0)

12
Testing Code Coverage
This chapter explains how to test and report on code coverage in Magellan.
In This Chapter
Code Coverage Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Using the Automated Flow for Line and Condition Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 395
Specifying Code Coverage Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Using an Input Coverage Database to Focus Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Identifying Intentionally Unreachable Lines (Verilog only) . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Code Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Code Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Using the VCS Uniform Report Generator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Code Coverage Methodologies

You can use Magellan to generate stimulus that achieves high line, condition,
and FSM code coverage. Magellan can also detect lines and conditions that
cannot be covered given the particular set of constraints you provide. The
following sections explain some different usage scenarios:
Block-level Verification Before Testbench Available
Comparing Design Behavior to Non-Synthesizable Reference Model
Filling Coverage Holes from System-Level Testbench Environment
Accelerating Convergence with Parallel Random Simulations
Using the Automated Flow for Line and Condition Coverage
Note To test line and condition coverage in Magellan, you need two additional
licenses: VT_VCS_BETA_Features or VT_UnifiedCoverage, and
VT_SVDesign.
Block-level Verification Before Testbench Available

For block-level verification performed before any testbench is available,
Magellan structural code coverage convergence provides one technique for
validating the correctness of constraints. You can investigate unreachable
lines and conditions to see if they are caused by over-constraint or design
bugs. Similarly, missing constraints can cause lines or conditions to be
reached when not expected. You can later use the constraints you develop for
coverage testing to verify design behavior with less chance of constraint errors
causing false proofs or failures. For information on developing constraints, see
“Constraining Input Signals” on page 260.
Comparing Design Behavior to Non-Synthesizable

Reference Model
When you are verifying the design by comparing its behavior to that of a
non-synthesizable reference model, you can use Magellan line and condition
coverage convergence to drive stimulus generation and measure
completeness. Because Magellan cannot prove that the design and reference
model are equivalent, you must rely on detection of mismatching behavior to

Testing Code Coverage Code Coverage Methodologies
find bugs. If you get high coverage on the design with no mismatches
detected, you can consider the verification to be complete. You can apply this
same completion metric when you have assertions that are too complex for
formal proofs.
To use this methodology, your reference model must be able to react to

stimulus generated by Magellan at the design input-pin level. This often
requires a monitor or bus-functional model (BFM) that extracts reference
model transactions from the design pin activity. The reference model must
also be able to respond to the periodic design resets that Magellan generates
during hybrid search and trace replay. Figure 48 shows a block diagram that
illustrates the high-level flow for this approach.
Figure 48: Using Non-Synthesizable Reference Model and Comparator
Reference
BFM Model
A
B
Y
?
Comparator
Design
Magellan
Under Test
Constraints Pin-level
Coverage
Trans-level
Metrics
Filling Coverage Holes from System-Level Testbench

Environment
In some cases, it may be possible to use Magellan to fill coverage holes
observed in a system-level testbench environment. Though you can easily
collect coverage data from the system-level environment and use it to

describe holes to Magellan, this methodology brings considerable risk of false

or misleading results.
To get valid coverage results from a Magellan run, the constraints must be
both complete and accurate. In the system-level testbench environment,
blocks are “constrained” by other RTL blocks and by the testbench itself. At
the block level in Magellan, constraints are represented by assume properties
or synthesizable transaction generators. It can be difficult to ensure that the
constraints are equivalent in both environments, yet failure to do so may result
in over- or under-approximation of the coverage obtained. For more
information on constraint validation techniques, see “Constraining Input
Signals” on page 260.
Accelerating Convergence with Parallel Random

Simulations
You can also run parallel Magellan sessions that use the same design files
and same basic project file from different working directories to cover more
“easy” line and condition coverage goals faster. To make this work, use a
set_session_info -rsimSeed command in the Session module of each
project file and specify different integers to seed the random number
generator for simulation. For example:
set_session_info sessionName -rsimSeed 384
When you run each session with a different random simulation seed number,
Magellan hits different goals faster in each run. When all the parallel runs
complete, use the URG coverage reporting tool to merge the coverage
databases from each individual run into one coverage database file. Then
feed the merged coverage database file to Magellan using a
set_aep_config -covInput command in the AEP module of your project
file. With the database of “easy” coverage goals in place, run Magellan again
in normal mode to target just the coverage goals that are still unknown in the
input coverage database.
Note For information on using the URG coverage reporting tool to merge the
coverage databases from parallel runs with Magellan, see the Uniform Report
Generator User Guide.

Testing Code Coverage Using the Automated Flow for Line and Condition Coverage

With coverage testing, the overhead required to target every source line and
condition can be considerable. You can minimize this overhead using the
automated coverage flow, which runs some random simulation first (using the
same constraints) to cover many of the easy-to-reach coverage points.
Now Magellan only needs to instrument and target the lines or conditions that
are still uncovered following the initial random simulation run. This gives the
best overall performance by allowing Magellan to focus on fewer targets with
unknown coverability. To use the automated coverage flow, follow these steps:
1 Create an AEP module in your Magellan project file that specifies line
and/or condition coverage tests (see Example 143).
Example 143: AEP Module for Line and Condition Coverage
### AEP module ###

define_aep set1 -line -cond

2 Magellan runs the initial random simulation for 3 minutes by default. While
this is a good heuristic for many designs, you may want to run the initial
random simulation longer or shorter. If so, you can specify the time using a
set_session_info -covSimTime command. The -covSimTime
option expects input in terms of hours. For example, to change the time that
random simulation runs at the start of the automated flow to 6 minutes, add
the following command to the Session module of your project file (0.1 x 60
minutes = 6 minutes):
set_session_info s1 -covSimTime 0.1
Note Simulator messages from the initial random simulation run do not appear in
the transcript or the mgsh_message.log file. Instead, these messages are
stored in the mg_sessionName/sim/covSim.log file.

3 When your project file is complete, run your session with the -covSim
switch. This switch is required to run the automated coverage flow. If you
omit the -covSim switch, Magellan runs the code coverage tests, but does
not use the automated flow (see “Specifying Code Coverage Tests” on
page 397).
mgsh> run_session s1 -covSim
4 When your run completes, you can write out your results using a
list_session_results command:
mgsh(alive...)> list_session_results s1
This report shows coverage results from the session run. It does not
include coverage results from the initial random simulation run.
5 You can also generate VCS Uniform Report Generator (URG) reports using
a write_session_test -urg command:
mgsh(alive...)> write_session_test -urg
This report shows merged coverage results from the initial random
simulation run and the session run.
6 Magellan creates the HTML-based reports in the mg_s1/sim/urgReport/

directory by default. Use your browser to view the coverage reports.

Testing Code Coverage Specifying Code Coverage Tests
Specifying Code Coverage Tests

To specify code coverage tests, use any combination of the following switches
with a define_aep command in an AEP module in your Magellan project file:
define_aep -line -cond -fsmState
These options are equivalent to using -cm line, -cm cond, and -cm fsm
on the VCS or VCS MX command line to enable coverage. You can add any
other valid simulator line, condition, or FSM coverage options to the extract
step using a set_aep_config -extractOpts command (see
Example 144). Line, condition, and FSM coverage goals that you test in any
one session must be in the same AEP module. Also, line, condition, and FSM
coverage tests cannot be combined with other types of AEP tests in the same
AEP module.
Note Code coverage testing for -fsmState is not supported for VHDL designs.
The recommended flow for code coverage testing in Magellan is to first run the
tool in random simulation mode (see “Using the Automated Flow for Line and
Condition Coverage” on page 395).
Any simulator compile options specified with the set_design_info -vcs

or -scs command are also added to the extract build for the coverage goals,
but runtime options specified with the add_env_info -runOpts command
are not used.
Instrumenting and testing line, condition, and FSM coverage goals can be
expensive in terms of tool performance due to the large number of coverage
goals that are created. You can limit the number of coverage goals
instrumented for formal testing using simulator coverage (-cm) switches such

Specifying Code Coverage Tests
as -cm_hier in the options you specify with the set_aep_config

-extractOpts command (see Example 144).
Example 144: AEP Module for Line, Condition, and FSM Coverage
### AEP module ###

define_aep set1 -line -cond -fsmState
set_aep_config set1 -extractOpts “-cm_hier file_name”

Note For information on the -cm_hier file format, see the VCS/VCSi User Guide
($VCS_HOME/doc/UserGuide/vcs.pdf).
You can limit the number of goals extracted using a set_aep_info

-maxGoals command. This can be important when running line and condition
tests on larger designs because too many goals can swamp the capacity of
the tool. The default for the maximum number of goals that Magellan extracts
is 20,000. The following example changes the maximum number of goals for
the set1 AEP module to 900:
set_aep_info set1 -maxGoals 900
If the maximum number of goals is exceeded, the build fails and Magellan
generates an error message similar to the following:

AEP(set1) exceeds max goal limit(1410 > 900)
At this point you need to change the -maxGoals setting or use another
method to limit the number of extracted goals (for example, -cm_hier) before
trying your run again.
You can use code coverage run mode for line, condition, and FSM coverage
tests. This mode is optimized to converge faster on large numbers of
reachable goals. See “Run Code Coverage Mode” on page 147.

Testing Code Coverage Using an Input Coverage Database to Focus Magellan
Using an Input Coverage Database to Focus Magellan

You can optionally use a set_aep_config command and the -covInput
and -covDut options to focus Magellan on just the coverage goals that have
not already been classified as reached in a coverage database (see
Example 145). When Magellan doesn’t have to instrument coverage goals for
items already shown to be reached in a coverage database, you see better
tool performance.
Example 145: AEP for Line, Condition, and FSM Coverage with Input Database
### AEP module ###

define_aep set1 -line -cond -fsmState
set_aep_config set1 -covInput path_to_database \
-covDUT instance_path_name # Add if db not from Magellan

The input coverage database can be from a standalone run with the simulator
(simv.cm) or a previous session with Magellan (design.exe.cm). Use a
set_aep_config -covInput command to specify the path to the input
coverage database. The co1verage database from a previous run with
Magellan is located in mg_sessionName/sim/design.exe.cm. Or, if you use a
write_session_test command to write out a trace and then run the
test.csh script, the resulting coverage database is located in the test directory
you specified as an argument to the write_session_test command, or
the default location:
mg_sessionName/test/testbench/design.exe.cm
If you are using an input coverage database from a standalone run with the
simulator, add the -covDUT option to specify the instance_path_name to
the design module in the input database instance hierarchy. Because the
testbench structure used for generating coverage information in the simulator
is probably different than the one used by Magellan, the tool needs to be able
to map coverage items between the different testbench environments. For

Using an Input Coverage Database to Focus Magellan
example, if you have a coverage signal named instanceA.coverB in the

design, and:
the design instance in the simulator test environment is
testbench.UUTWrap.DUT
the design instance in the Magellan environment is top_myMod.MyMod
you specify the -covDUT as shown in Example 146.
Example 146: Specifying Input Coverage DB with Default Test Name
set_aep_config aepName -covInput path_to/simv.cm \

-covDUT testbench.UUTWrap.DUT
Now Magellan knows to map the testbench.UUTWrap.DUT.instanceA.condB

coverage item in the input coverage database to the Magellan testbench
coverage item (top_myMod.myMod.instanceA.condB). The versions of design
files in the subset of the hierarchy you are mapping must be the same as the
versions of the design files you are testing with Magellan. There is a Magellan
SolvNet article that explains a workaround for this limitation.
Note You cannot use the -covDUT option to specify part of the hierarchy in the
design to test. Use the set_aep_config -extractOpts command with
the -cm_hier option to do that (see Example 144 on page 398).
Specifying Input Coverage Database Name

If you created the input coverage database from a run with the simulator using
a test name other than the default (test), you need to specify the test name for
Magellan using the set_aep_config -covTest option as shown in
Example 147.
Example 147: Specifying Input Coverage DB with User-Specified Test Name
set_aep_config aepName -covInput path_to/simv.cm \

-covDUT testbench.UUTWrap.DUT -covTest name

Testing Code Coverage Identifying Intentionally Unreachable Lines (Verilog only)
Identifying Intentionally Unreachable Lines (Verilog only)

A common practice for designers is to use logic X assignments for certain
conditions which should never happen. Such X assignments are not expected
to be executed during normal operation. These X assignments are
intentionally unreachable—the fact that they cannot be reached or covered
indicates that the design and constraints are operating as expected.
When you use Magellan to test line coverage in your design, you can report on
the status of intentionally unreachable lines. Currently, Magellan defines
intentionally unreachable lines of code as Verilog basic blocks that contain
explicit X assignments (see Example 148).
Example 148: Intentionally Unreachable Line of Code
module mux(clk, d1,d2,d3,d4,cntrl,c);

input clk,d1,d2,d3,d4;
input [1:0] cntrl;
output c;
reg c;

begin
if (cntrl == 2'b00)
c <= d1;
if (cntrl == 2'b01)
c <= d2;
if (cntrl == 2'b10)
c <= d3;
if (cntrl == 2'b11)
c <= 1'bx; // intentionally unreachable
end
endmodule
Configuring the Test

To enable intentional unreachable reporting, add the -modLineIntent
switch to a define_aep command in your Magellan project file. For example:
define_aep aepName -line -modLineIntent

Identifying Intentionally Unreachable Lines (Verilog only)
Alternatively, you can set the -modLineIntent switch with a

set_aep_info command if you have already defined that AEP module for
line coverage testing. Here, the -modLineIntent switch takes a Boolean
flag (1 or 0) that you can toggle as needed. The following example turns on
intentional unreachable line coverage reporting:
define_aep aepName -line

set_aep_info aepName -modLineIntent 1
Note Using the -modLineIntent switch does not automatically imply line
coverage. You need to first specify line coverage testing as shown in the
example above, using a define_aep -line command.
Reporting Intentional Unreachables

You can use a list_session_results -long command to see if the
intentionally unreachable lines of code were reached or not. For example,
using the sample design shown in Example 148, Magellan reports the results
as follows:
...
> ID: [7] Reached -> (Intent=unreach)

- SimTime : 2299
- Update : 10:28:04 - Jan 07
- Elapsed Time : 0:00:11|
- Random Cycles : 24
- Formal Cycles : 0
- Type : Line Coverage
- LineType : IF
- LineIntent : unreach
- Signal : inst1.mgvcm_line_M1_L16_ID0
- File : mux.v
- Line : 16
...
For line coverage target [7] Magellan found a conflict. The designer’s intent
was that the line would be unreachable, but Magellan reached it, as the report
shows. Magellan only shows the Intent part of the report if there was a
conflict between the designer intent and the test results. Magellan always

Testing Code Coverage Identifying Intentionally Unreachable Lines (Verilog only)
shows the LineIntent line even if there was no conflict between the
designer intent and the test results.
There are two types of test results that indicate problems with the design for
reported lines in the coverage report:
Intention was unreachable, but Magellan reached it.
Intention was reachable, but Magellan did not reach it.
You can filter the line coverage report to show just lines that were intentionally
reachable or unreachable using the lineIntent reach or lineIntent
unreach key-value pairs.
Intention Unreachable but Magellan Reached It

For example, to filter your report to show just lines that were reached but were
intentionally unreachable, use the following command:
mgsh(alive...)> list_session_results -state reached \
-filter {lineIntent unreach}
Session Results for: aep_session

AEP Module: set1
[ 7] Reached -> Intent=unreach (Cycles r=24,f=0) (Line

Coverage) - mux (mux.v:16)
Intention Reachable but Magellan did not Reach It

You can also filter the line coverage report to show just lines that were
intentionally reachable but were not reached using the following command:
mgsh(alive...)> list_session_results -state unreachable \
-filter {lineIntent reach}
Session Results for: aep_session

AEP Module: set1
Here, the report is empty because there were no lines in the sample design
(see Example 148) that met the filtering settings (all lines were reached).

Code Coverage Flow
Code Coverage Flow

You can use the Discovery platform’s unified coverage database to leverage
the code coverage information between VCS and Magellan.
Note that the database can contain other coverage items and metrics that do
not apply to Magellan. However, unified coverage tools handle this
transparently.Figure 49 shows the high-level flow.
Note For information on using the URG reporting tool, see the Unified Coverage
Reporting User Guide.
Figure 49: Magellan and VCS Code Coverage Flow
Test_N Test_1 Test_2
Directed/Random Tests
VCS/Vera
design.exe.cm CovDB_1 CovDB_2

write_session_test
Merged
Magellan Coverage
Database
URG
design.exe.cm
design.exe.cm = reached and unreached code coverage goals.

This file is created in the mg_sessionName/sim directory.
design.exe.cm = reached and unreached code coverage goals.

This file is created in the mg_sessionName/test/dirname directory.

Testing Code Coverage Code Coverage Reporting
Code Coverage Reporting

During your session run, Magellan saves information about reachable lines of
code in a test named test and unreachable lines of code in a test named
test_mgunr. These test data are associated with the simulator used in the
run phase of Magellan at:
mg_sessionName/sim/dut.exe.cm
where:
sessionName is the name of the session you are running in Magellan.
dut is the name of the top-level module in the design you are testing.
You can specify a different name for the data using a set_aep_config
-covTest command in the AEP module of your Magellan project file. For
example, to name your tests myTest, use the following command:
set_aep_config myAep -covTest myTest
Now, if you use the VCS Uniform Report Generator (URG) tool to report
coverage results after your run completes, you see two tests in the database:
a test named myTest, which contains information about all lines of code
reached (or covered) during the Magellan run.
a second test named myTest_mgunr, which contains information about all
line or condition coverage targets that Magellan proved unreachable during
the run.
in addition, if you specified intentional unreachable reporting (see
“Configuring the Test” on page 401) Magellan uses the coverage exclude
file mechanism to record lines that are proven unreachable (as intended by
the coder). If you want to ignore these intentional unreachable lines in your
coverage reporting you can find the exclude information saved in a file
named:
mg_sessionName/user/myTest_mgunr.el

Using the VCS Uniform Report Generator Tool
where:
sessionName is the name of the session you are running in Magellan.
myTest is the name of the test.
Using the VCS Uniform Report Generator Tool

You can use the VCS Unified Report Generator tool (urg) to interpret coverage
results from Magellan and VCS. When your code coverage session with
Magellan completes, use a write_session_test -urg command to
generate the HTML-based reports. For example:
mgsh(alive...)> write_session_test -urg
With this command, Magellan generates the reports in the default location
(mg_sessionName/sim/urgReport). You can specify a different name and
location for the report directory by supplying the optional dirname argument to
the write_session_test command.
For information on reporting coverage results from both VCS and Magellan,
see “Code Coverage Flow” on page 404.
For information on interpreting coverage results, see “Understanding

Inconsistent Coverage Results” on page 411.
Note For more information on using the Unified Report Generator tool, see the
Uniform Report Generator User Guide.

13
Testing Functional
Coverage
This chapter explains how to test SVA/OVA functional coverage in Magellan
In This Chapter
Testing SVA/OVA Cover Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Functional Coverage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Functional Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Using the Functional Coverage Database to Focus Magellan . . . . . . . . . . . . . . . . . . . . . . . . 413
Reusing Magellan Functional Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Saving Functional Coverage Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Testing SVA/OVA Cover Statements
Testing SVA/OVA Cover Statements

One aspect of functional verification involves making sure that some events or
sequences of interest happen at least once during testing (for example,
preconditions to properties). You can describe these events or sequences in
SVA or OVA and use the cover directive to test for their occurrence. You can
then use Magellan to automatically locate and generate stimulus based on:
SVA cover constructs in your design
OVA cover constructs in external OVA files or inline OVAs (Verilog only)
When you run a session that includes such coverage goals, Magellan tells you
if each cover is covered (reachable) or uncoverable (not an event that can
happen given legal input stimulus to the design).
Adding SVA/OVA Covers to the Project File

To enable automatic extraction and testing of covers, use a define_env
-sva or -ova command in the Environment module of your project file. To
select which covers you want to test, use an add_coverage_info command
in the Coverage module (see Example 149 and Example 150).
For SVA covers, use an add_coverage_info -scope command.
For OVA covers, use an add_coverage_info -ovaPath or -scope
command.
You can name each cover object explicitly or use the wildcarding feature to
pick up all SVA/OVA cover objects that match a pattern. The names of the
cover objects that you specify must match the names used in the cover
declarations in your SVAs/OVAs. The wildcarding feature works the same way
with SVA/OVA covers as it does with SVA/OVA assertions and constraints
(see “Assertion Naming in Magellan” on page 361).

Testing Functional Coverage Testing SVA/OVA Cover Statements
Example 149: Project File Snippet for Testing SVA Covers

define_env env1 -sva -timeUnits 100ps
add_env_port env1 -name clk_st -clock 100
add_env_port env1 -name rst_st -reset 1
add_env_port env1 -name rst_st -constant 0

define_coverage cover_sva
add_coverage_info cover_sva -scope {*cover_pipe_ctrl*}

add_session_info s1 -coverage cover_sva
Example 150: Project File Snippet for Testing OVA Covers

add_env_block env1 -format ova -files cover.ova
add_env_port env1 -name clk_st -clock 100
add_env_port env1 -name rst_st -reset 1
add_env_port env1 -name rst_st -constant 0

define_coverage cover_ova
add_coverage_info cover_ova -ovaPath {ovaunit.cov*}

add_session_info s1 -coverage cover_ova

Functional Coverage Flow
Functional Coverage Flow

You can use the Discovery platform’s unified coverage database to leverage
SVA/OVA functional coverage information between VCS and Magellan.
Note that the database can contain other coverage items and metrics that do
not apply to Magellan. However, unified coverage tools handle this
transparently. Figure 50 shows the high-level flow.
Figure 50: Magellan and VCS Functional Coverage Flow
Test_N Test_1 Test_2
Directed/Random Tests
VCS/Vera
MG_Reach.db CovDB_1 CovDB_2

write_session_test
Merged
Magellan Coverage
Database
Formal Tests
fcovReport
Reach_DB
UnReach_DB
Reach_DB = asserts falsified and covers reached

UnReach_DB = asserts proven and covers unreachable

Testing Functional Coverage Functional Coverage Reporting
Functional Coverage Reporting

Use the VCS fcovReport tool to merge functional coverage data into the
unified coverage database for reporting purposes. Merging coverage data for
reporting purposes is mainly useful during the final stages of testing when your
design is stable, because as you debug and change your design, the
classifications for coverage goals may change too.
Note For information on merging functional coverage data and using the fcovReport
tool, see the VCS/VCSi User Guide.
Understanding Inconsistent Coverage Results

Because Magellan uses both dynamic simulation and formal methods, it is
possible that these two domains will report inconsistent coverage results. This
is often an indication of coding errors in the design, covers/asserts, or the
design constraints you set up for Magellan. In particular, designs that are not
consistent with synthesis coding guidelines can cause inconsistent results
(see “Diagnosing Mismatches” on page 465).
Coverage Data from Two Different Test Environments

In the pure simulation world (VCS), coverage statistics are often gathered at
the system level, whereas the recommended flow with Magellan is to verify
covers/asserts and line and condition coverage at the block level. System-
and block-level coverage reporting may not agree, depending on the
consistency between block-level constraints and the system-level
environment for the block. If the Magellan environment is over-constrained
compared to the system-level simulation, you may see conflicting results.
Magellan may see a goal as unreachable, yet it is hit in the system-level
simulation. If the Magellan environment is under-constrained, Magellan may
hit goals that can never be hit in the system-level simulation environment.
Investigating Inconsistent Coverage Results

You should investigate inconsistent coverage results, and correct your design
and test environment as necessary. Magellan stores complete functional
coverage information in the output reached and unreachable coverage

Functional Coverage Reporting
databases, even if some of the results conflict. You can debug the causes and
obtain more consistent results in a later run with the tool (see “Saving
Functional Coverage Databases” on page 414). If you merge inconsistent data
back into the unified coverage database, it is highlighted in the reports
generated by the VCS fcovReport tool.
Understanding Discovery Coverage Terminology

VCS and Magellan use different terminology when reporting coverage results
for reached covers and asserts, as shown in Table 11.
Table 11: Coverage Terminology for Magellan and VCS
Reporting Tool Reached Assert Reached Cover
VCS failure real success
Magellan falsified covered

Unreachable Assert Unreachable Cover
VCS N/A N/A
Magellan proven unreachable
Magellan classifies asserts, covers, and line and condition coverage goals that
are not yet reached or proven unreachable as unknown.

Testing Functional Coverage Using the Functional Coverage Database to Focus Magellan
Using the Functional Coverage Database to Focus Magellan

To focus Magellan on covers and asserts that are not already classified in the
functional coverage database, use the database file as input to your session.
This way, you don’t need to modify your project file or create separate
sessions to focus the tool just on the goals that are still unknown.
Note For information on using VCS to build a functional coverage database, see the
VCS/VCSi User Guide.
Use a set_session_info command with the -covInput option in the

Session module of your project file to specify an absolute or relative path to an
input database file that contains functional coverage data, as shown in
Example 151. Add an add_session_info command with the -property
option to point to the Property module where your assert and cover properties
are defined.
Example 151: Session Module for Functional Coverage Using Unified Coverage
Database Input

add_session_info session_1 -property ova_prop
set_session_info session_1 -covInput DB_file \
-covDUT instance_path_name
Reusing Magellan Functional Coverage Data

Magellan stores session results for functional coverage goals in an internal
coverage database. To reuse functional coverage data from a previous
Magellan session, use a set_session_info command with a
-covReuse 1 option in the Session module of your project file, as shown in
Example 152.
Note that -covReuse is mutually exclusive with -covInput and -covDUT. If

you changed any design files since you generated the coverage information,
the database may no longer be valid. In that case, use -covInput and
-covDUT instead (see “Using the Functional Coverage Database to Focus
Magellan” on page 413).

Saving Functional Coverage Databases
Example 152: Session Module Reusing Coverage Info From Same Session

add_session_info session_1 -coverage cover_pipe_ctrl
set_session_info session_1 -covReuse 1
If you want to save coverage data for input to a Magellan run that references a
different Session module, you need to first export the coverage data (see
“Saving Functional Coverage Databases” on page 414).

You can save functional coverage data:
for input to a different session with Magellan
to merge back into the unified coverage database for reporting purposes
Use an export_session_coverage command with the -covOutput

option at the MG shell prompt, as shown in the following example:
mgsh> export_session_coverage -covOutput basePath \

-covDUT instance_path_name
where:
-covOutput specifies the basePath to use when writing the database files:
basePath_unr.db (unreachable coverage information)
basePath_rch.db (reached coverage information)
For example, if you specify the basePath as /u/me/Coverage/cover,

Magellan names the output database files:
/u/me/Coverage/cover_unr.db (unreachable coverage data)
/u/me/Coverage/cover_rch.db (reached coverage data)
Use -covDUT to specify the instance_path_name to the design module in

the output database instance hierarchy. By default, signal names in the output

Testing Functional Coverage Saving Functional Coverage Databases
coverage database are relative to the Magellan testbench environment. For

example, the hierarchical path name of the design in Magellan is:
top_DesignName.DesignName
For compatibility with the VCS test environment, Magellan can replace this
instance_path_name with a name that is meaningful for the VCS testbench
you are using. For example, if you have a coverage signal named
instanceA.coverB in the design, and:
the design instance in the VCS environment is testbench.UUTWrap.DUT
the design instance in the Magellan environment is top_myMod.MyMod
you can map your Magellan coverage results back into the VCS testbench
environment using the following command at the MG shell prompt:
mgsh> export_session_coverage -covOutput basePath \

-covDUT testbench.UUTWrap.DUT
The signal name in the output coverage database is then:
testbench.UUTWrap.DUT.instanceA.coverB
Saving High-Value Regression Tests

When you complete a Magellan session that reaches new coverage goals,
you can use the write_session_test command to write out a simulator
trace and add the test to your regression test suite. The stimulus trace shows
the reached coverage goals.

Knowing When You Are Done with Functional Coverage

With SVA/OVA assertions you are done testing when there are no assertions
being reported as falsified. With SVA/OVA covers, you are done testing when
all your covers are reached or proven unreachable. There are three typical
problems that can lead to unreached covers:
the design does not function as you thought it would (there is a bug)
the design is over-constrained (see “Understanding Inconsistent Coverage
Results” on page 411)
there is a coding error in your SVA/OVA cover statement
You can use the Magellan unreachability database or unified coverage

reporting (see “Saving High-Value Regression Tests” on page 415) to review
SVA/OVA covers that have not yet been reached and refine your test
environment.

14
Reporting and Debugging
This chapter explains how to use Magellan commands to generate reports for AEP, property,
and coverage tests, and how to debug property failures or see how coverage goals were
reached. The chapter also explains how to get special-case reports such as bounded proof
and cone of influence, and how to access test results and create custom reports using
Magellan commands inside Tcl scripts.
In This Chapter
Reporting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Automatically Generated Transcripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Detailed Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Summary Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Accessing Session Results in Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Bounded Proof Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Vacuous Proof Reporting (SVA/PSL only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Witness Trace Reporting (SVA/PSL only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Cone of Influence Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Assertion Cone of Influence Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Debugging Property Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Reporting Overview
Reporting Overview
When you test AEPs, properties, or coverage goals, Magellan automatically
generates transcripts on the screen with updated results as your session runs.
(see “Automatically Generated Transcripts” on page 419).
After the build phase completes, you can generate reports at any time during
or after a run using the list_session_results command (see “Detailed
Reporting” on page 421).
Reports from the list_session_results command are persistent. As long

as you don’t change your project file or delete the mg_sessionName directory
that Magellan creates to store results when you run a session, you can later
read in your project to MG shell and report results from a previous run with the
tool without having to rebuild your design or rerun your session.
You can also use the list_session_results command inside Tcl scripts
that you write to produce custom reports (see “Accessing Session Results in
Tcl Scripts” on page 432).
You can use the report_session command to generate:

Cone of influence reports for a property or coverage goal (see “Cone of
Influence Reporting” on page 439).
Black box forced signals reports (see “Understanding “forces” in RTL
Simulation Models” on page 181).
Note The Magellan GUI (mgui) provides an easy-to-use way to report test results
and debug property failures. For information on getting started with mgui, see
“Invoking the Magellan GUI” on page 108.

Reporting and Debugging Automatically Generated Transcripts
Automatically Generated Transcripts

Magellan generates a transcript on the screen while your session is building
and running. The transcript provides real-time updates on the tool’s progress
toward proving properties or reaching coverage goals. Magellan also saves
the transcript in the mg_sessionName/user/goals.log file. The example in
Figure 51 shows a transcript from a session that tests 16 instances of an SVA
in the s2 Session module.
Figure 51: Transcript Showing SVA Property Goals
In this example, Magellan found progressively deeper bounded proofs for all
16 instances of the SVA specified in the mutex Property module and
concluded by proving them all, as shown in the summary information for the
results printed when you press the Return key after a session run completes.
Transcripts for coverage goals are slightly different, as shown in Figure 52. In
this example, Magellan is running a session (s1) which tests the set1 AEP

Automatically Generated Transcripts
module. As simulation time advances, Magellan classifies more of the

unknown (UNK) coverage goals and finally reaches all of them (RCH).
Unreachable goals are reported as UNR. Transcripts for RTL coverage goals
look just like Figure 52, except that the GoalType column says Coverage in
each line of the report instead of the AEP-Line you see in this example.
Figure 52: Transcript Showing AEP Coverage Goals

Reporting and Debugging Detailed Reporting
Detailed Reporting
Any time after your build completes, you can use a list_session_results
command at the MG shell prompt to see detailed information about the goals
Magellan found or tested in your design (see Table 12).
Table 12: Magellan Goal Statuses/Results
Goal Types Statuses Notes
AEP Property Goals: - proven The ignored status means there

- falsified was a problem such as a replay
full-case
- unknown miss, an X value propagating to
parallel-case
- ignored a goal signal, or a conflict in the
array boundaries
status reported by different
floating buses
formal engines. For more
multiply-driven buses
information, see “Detecting
arithmetic overflow
Simulation/Synthesis
simultaneous set/reset
Assertion Property Goals: - proven SVA and PSL assertion goals

- falsified also report the vacuity status:
SVA
- unknown
OVA vacuous
- ignored
PSL non-vacuous
RTL
Code Coverage Goals: - reached

- unreachable
line
- unknown
condition
- ignored
FSM state
AEP Coverage Goals: - toggled

- constant
toggle
- unknown
- ignored
RTL Coverage Goals - reached For individual or groups of RTL

- unreachable signals, including FSMs.
- unknown
- ignored
Assertion Cover Goals: - covered

- uncoverable
SVA, PSL, OVA
- unknown
- ignored

Detailed Reporting
The list_session_results output follows the same basic format for all
property goal types and SVA/PSL covers. Each goal in the list is assigned an
index number (ID) starting with 0 and gets a separate report section with
details on the results or status of the test. Index numbers are generated for
each module that you test in a Magellan session. If you test more than one
module in a session, you need the module name and ID number to uniquely
identify a goal. Right next to the ID for each goal in the
list_session_results output Magellan shows the goal status. The
list_session_results command generates a one-line report for each
goal in the session by default. If you want to see a more detailed report, add
the -long switch.
The list_session_results command reports on the current session by

default. If you want to see results for a previous session, first read the project
file into MG shell and then specify the Session module name with your
list_session_results command.
mgsh(alive...)> list_session_results [ sessionName ]
Trace Length Reporting

Knowing the lengths of error traces for falsified properties or reach coverage
goals can be important for debugging. Magellan reports the length of error
traces for falsified properties or reached coverage goals in terms of master
design clock cycles since the last reset (see “Internal Generated Master
Design Clock” on page 214). Trace length information is incorporated with the
reports you get from the list_session_results command. For example:
[ 0] Falsified (Non-vacuous) (Cycles r=9,f=0)
In this example, the error trace for the falsified property consisted of 9 cycles
of random simulation (r=9) and 0 cycles of formally-generated stimulus
(f=0).
You may also get a trace length report which shows that only
formally-generated stimulus was used to falsify a property. For example:

(f=20).
The third possibility is that Magellan used a combination of random and formal
stimulus to falsify the property. For example:
(f=56).
When you add the -long switch to your list_session_results

command, the trace length reporting information appears in a slightly different
format, as shown in Example 153.
Example 153: Trace Length Reporting
> ID: [0] Falsified

- SimTime : 2099
- Update : 15:05:47 - Aug 13
- Random Cycles : 9
- Formal Cycles : 0
- Scope : ../u_des_unit0.pipe_ctrl_1

Detailed Reporting
AEP Property Detailed Reporting

If your session includes an AEP module named set2 that specifies full-case
tests, the list_session_results -long command produces a report like
the example shown in Figure 53. Reports for the other AEP property goals are
similar.
Figure 53: AEP Property Detailed Report
AEP Module: set2
> ID: [0] Proven

- Update : 11:10:47 - Jul 14
- Inst : des_chip.u_des_core.u_des_unit0.de_a
- File : ../Rtl/des_a.v
- Line : 86
Magellan reports the SimTime in the detailed reports only for falsified AEP
properties. You can use this information to locate a property failure in the
waveform viewer. The Signal names in the AEP property list show Magellan
instrumented signal names for most of the AEP property types. The Signal
names for toggle coverage, multiply-driven buses, and floating buses
reference the actual signal names in your design. AEP property lists for toggle
coverage, multiply-driven buses, and floating buses do not show File and
Line numbers.

AEP FSM State Coverage Detailed Reporting

If your session includes an AEP module named State that specifies FSM
state coverage tests, the list_session_results -fsm command
produces a report like the example shown in Example 154. The report shows
which FSM states were reached (RCH), unreached (UNR), and unknown (UNK)
for the dev design. In this example, all defined FSM states (idle, first,
second, and third) were reached.
Example 154: AEP FSM State Coverage Detailed Report
AEP Module: State

[ 0] RCH=4,UNR=0,UNK=0 (FSM State Coverage) - dev
(test.v:17)
> RCH : idle
> RCH : first
> RCH : second
> RCH : third

Detailed Reporting
Assertion Property Detailed Reporting

If your session includes a Property module named mutex that specifies tests
for multiple instances of an SVA named assert_mutex, the
list_session_results -long command produces a report like the
example shown in Figure 54. In this example, the same SVA
(assert_mutex) is proven in two different scopes (dd_d and de_d). Reports
for OVA, PSL, and RTL assertions are similar, but vary somewhat. For
example, reports on OVAs contain lines for the bind and unit locations.
Figure 54: Assertion Property Detailed Report
Property Module: mutex

> ID: [0] Proven
- Update : 08:41:04 - Sep 11
- Scope : des_unit0.dd_d.assert_mutex_inst
> ID: [1] Proven
- Update : 08:41:04 - Sep 11
- Scope : des_unit0.de_d.assert_mutex_inst
Each property goal found in the design is given an ID and an index number,
followed by the status (reached, unreachable, or unknown). Magellan
reports the SimTime in the detailed reports only for falsified properties. You
can use this information to locate a property failure in the waveform viewer.

Code Coverage Goals Detailed Reporting

If your session tests an AEP module named set1 that specifies automatic line
and condition coverage tests, the list_session_results -long
command produces a report like the example shown in Figure 55.
Figure 55: Code Coverage Goals Detailed Report
> ID: [1] Reached

- SimTime : 249
- Update : 11:03:43 - Aug 14
- Random Cycles : 2
- Formal Cycles : 0
- Type : Line Coverage
- LineType : IF
- Signal : inst1.mgvcm_line_I1_L11_ID0
- Inst : mux
- File : mux.v
- Line : 11
...
> ID: [708] Reached

- SimTime : 9699
- Update : 09:37:45 - Jun 16
- Random Cycles : 2
- Formal Cycles : 0
- Type : Condition Coverage
- Cond : (o_xfer == 1'b1) && (!(count == 2'h3))
- Signal : inst1.mgvcm_cond_I205_L104_ID1_V10_T2
- Inst : des_chip.u_des_core.u_des_unit2.dd_d
- File : ../Rtl/des_d.v
- Line : 104...
Each code coverag goal found in the design is given an index number,
followed by the status (reached, unreachable, or unknown). Magellan
reports the SimTime in the detailed reports only for reached coverage goals.
You can use this information to locate a reached coverage goal in the
waveform viewer.
For line and condition coverage tests, the File and Line names refer to the
places in your design where Magellan found the line or condition coverage

Detailed Reporting
goals to test. For condition coverage goals, the Cond lines show the
expressions that were tested.
RTL Coverage Goals Detailed Reporting

If your session tests a Coverage module named FIFO_goalset that
specifies a group of RTL signals for coverage tests, the
list_session_results -long command produces a report similar to
Figure 56.
Figure 56: RTL Coverage Goals Detailed Report
Each signal has a

column in the report
A dash means both

bit values are included
The coverage report shows the signals that were tested and displays results
for reached, unreachable, and unknown coverage goals in the form of a
compressed truth table, where a dash means both values (0 and 1) are
included.

Detailed Report Filtering

You can use list_session_results filtering options to get reports on
specific subcategories of goals in a session. You can report results by:
-state to see the status of the search (for example, proven or falsified).
-type to see a specific type of goal (for example, sva, aepLine, or rtl).
-attr to see how an assertion property is being used (for example,
checker or constraint) or if the results for a functional coverage test are
from an input coverage database or the current session with Magellan.
-filter with AEP line and condition tests to see specific kinds of lines or
conditions in the design or to filter by module instance for any Magellan
test.
Filtering on Goal State

You can filter results on the status of the search using the -state option. See
the Statuses column in Table 12 on page 421 for the different legal values you
can specify and which goal types they apply to.
For example, if you are testing an AEP line and condition coverage module,
you can use the -state reached or unreachable options to filter the
report to just those categories as follows:
mgsh(alive...)> list_session_results -state unreachable
Magellan prints a short header at the top of the report that shows the session
name for the AEP module, followed by the filtered report. In this case, the tool
reports only on line and condition coverage goals that are unreachable.
For assertion properties like SVAs, you might want to filter your results to see
just the goals that are proven or falsified. In that case, you could use a
command like this:
mgsh(alive...)> list_session_results -state proven
Or perhaps your run has been going for some time without completing and
you want to see a report for the SVAs that are still unknown, so that you can

Detailed Reporting
separate them out and test them in a separate session with the tool. In that
case, you could use the following command:
mgsh(alive...)> list_session_results -state unknown
Filtering on Types of AEP Lines or Conditions

You can use the -filter option to report AEP test results if the specified
key-value filter pairs match. Legal keys include inst, line, cond, and
bound. The value can be any relevant string or glob pattern:
For the line key, specify a string or glob pattern for an AEP line coverage
type.
For the cond key, specify a string or glob pattern for an AEP condition
coverage expression.
For the bound key, specify a string or glob pattern for an AEP bounds
expression.
You must enclose the two arguments to the -filter option in curly braces.
For example, to see a report for all the AEP line coverage tests on always
blocks, you can use the following command:
mgsh(alive..)> list_session_results -filter {line ALWAYS}
If you ran both line and condition checks in the same session, you can use the
-type option to show results just for that type. For example:
mgsh(alive..)> list_session_results -type aepCondition
Filtering on Checkers or Constraints

Assertion properties such as SVAs can be used either as checkers or
constraints. To report on one category or the other for assertion properties you
can use the -attr options as follows:
mgsh(alive..)> list_session_results -attr checker

Reporting and Debugging Summary Reporting
Filtering Functional Coverage Database Results

You can filter functional coverage results for SVA/OVA asserts and covers to
show results just from an input coverage database or show results just from
the current session using the list_session_results -attr command at
the MG shell prompt as follows:
mgsh(alive..)> list_session_results -attr inputCov
mgsh(alive..)> list_session_results -attr sessionCov
Note For information on all list_session_results options, see the man page
(at the MG shell prompt, type man list_session_results).
Summary Reporting
You can report summary test results any time after the build completes using a
list_session_results -summary command. The example in Figure 57
shows a summary report for an AEP line and condition coverage test defined
in an AEP module named set1.
mgsh(alive...)> list_session_results -summary
Figure 57: Summary Report

AEP Module: set1
---------------------------
> Line Coverage
- # found : 18
- # reached : 18
- # unreachable : 0
- # unknown : 0
> Condition Coverage
- # found : 0
- # reached : 0
- # unreachable : 0
- # unknown : 0
---------------------------
Total Found : 18
Total Passed : 18
Total Failed : 0
Total Unknown : 0

Accessing Session Results in Tcl Scripts
Accessing Session Results in Tcl Scripts

You can use list_session_results -TCL commands in Tcl scripts to
access session results. For example, you can create custom reports any time
after the build is complete. The list_session_results -TCL command
returns data in a Tcl associative array, which consists of key-value pairs for the
module types, names, and goal index numbers for all modules defined in the
specified session. For example, if you are running AEP line and condition
coverage tests included in a Session module named s1, Magellan returns the
following data:
mgsh(running...)> list_session_results s1 -TCL
type {aep} name {set1} idxList {0 1 2 ... n}
In this example, the associative array includes the following key-value pairs:
type is the key and aep is the value for the module type.
name is the key and set1 is the value for the name of the aep module.
idxList is the key and 0, 1, 2 ... n are the index numbers for all the
AEP line and condition coverage goals found in the design for the set1
AEP module.
To get all the AEP module names defined in a session, loop through all the
AEP signals in each module, and report the signal names and statuses for the
coverage goals, you can use a Tcl script like the one shown in Example 155.
Example 155: Tcl Script for Custom Reporting (report.tcl file)
array set goalArray [list_session_results s1 -goalrefs -TCL]

set aepList $goalArray(aeps)
foreach i $aepList {
array set aepArray [list_session_results s1 -goalmod $i -TCL]
set sigList $aepArray(idxList)
foreach j $sigList {
array set sigArray [list_session_results s1 -idx $j -goalmod $i -TCL]
echo "Signal: $sigArray(sig), State: $sigArray(state)"
}
}

Reporting and Debugging Accessing Session Results in Tcl Scripts
For this to work, you must read in the project file where the specified Session
module is defined and then source the Tcl script at the MG shell prompt:
% mgsh project.prj
mgsh> source report.tcl
The report.tcl script returns output similar to Figure 58.
Figure 58: Tcl Script Report Output
Signal: mgvcm_line_I238_L132_ID0, State: Reached

Signal: mgvcm_line_I238_L135_ID0, State: Unknown
Signal: mgvcm_line_I245_L151_ID0, State: Unreachable
...
Note The list_session_results -TCL command returns property names as

the whole path to the signal. If this property name contains square brackets:
dut.testgen[2].p3
and you want to add all instances of this property to a Magellan project file
using the add_property_info -scope command, use four backslashes in
front of each square bracket:
*dut.testgen\\\\[2\\\\].p3

Bounded Proof Reporting
Bounded Proof Reporting

If Magellan finds a bounded proof for a property, you see a message similar to
Example 156 in the automatically generated transcript. In this example, the
Session module is session_ocq and the Property module is prop2. As the
search continues, the bounded proof depth may increase.
Example 156: Bounded Proof Transcript
[Clock: 0:15:12] Running Session: session_ocq

- prop2 Checking...[proven for: 526 cycles])
Magellan calculates bounded proof depths by counting from the Reset State
(see Figure 32 on page 221). Magellan samples the Reset State at the
1/4-cycle point of the system clock, and applies the first set of inputs to the
formal model on the next falling edge. Just before the next rising edge of the
clock, Magellan samples net values. If Magellan can prove that it is impossible
to cause the assertion to fail with the design in the Reset State and legal
values applied to input signals, it reports a bounded proof of depth zero. If
Magellan could violate the property from that state, the error trace would have
a length of zero cycles.
On the next rising edge of the system clock, the design advances to the first
state following the Reset State. If Magellan can prove that there are no legal
input values applied at both the first and second falling edges that can cause
the assertion to fail, it reports a bounded proof depth of one. And so on for
subsequent cycles.
Note that the system clock can be twice as fast as the design clock in some
cases (see “Understanding Magellan’s System Clock” on page 212). Magellan
reports bounded proof depths in terms of the system clock, not the design
clock.
To get the best possible bounded proof results in the shortest time, run
Magellan in bounded proof mode, as shown in the following example:
mgsh> run_session -mode boundedProof sessionName

Reporting and Debugging Vacuous Proof Reporting (SVA/PSL only)
Vacuous Proof Reporting (SVA/PSL only)

Magellan detects and reports vacuous proofs for SVA and PSL asserts which
use the |-> or |=> implication operators. A vacuous proof is one where the
antecedent of the implication can never be true. Note that the antecedent
refers to the expression on the left-hand side of the implication operator. When
Magellan reports vacuous proofs, you should review the code to determine
why this condition occurred, and modify your assertion or design accordingly
before rerunning your test. To disable vacuity reporting, see “Turning Off
Vacuity Reporting” on page 436.
For properties that contain implication operators, the

list_session_results -long report output shows an extra Vacuity
section for each assertion or cover targeted in that session The Vacuity
goals are also assigned index numbers (see Figure 59 and Figure 60).
Figure 59: Non-Vacuous Proof Report Example
> SVA ID [1] Proven

- Vacuity [2]:.Non-vacuous
- Scope: wb_dma_top.u2.check_var
- Instantiation: ./sva_dir/dma_foo.sva:31
- Assertion: myAssert_2
- Assertion Location: ./sva_dir/myAssertFile.v:37
- SV Module: MyAssertMod2
- Parent Location: ./sva_dir/myAssertFile.v:28
Figure 60: Vacuous Proof Report
> SVA ID [1] Proven

- Vacuity [2]: Vacuous
- Scope: wb_dma_top.u2.check_no_underflow_1
- Instantiation: ./sva_dir/dma_engine.sva:318
- Assertion: myAssert_1
- Assertion Location: ./sva_dir/myAssertFile.v:372
- SV Module: MyAssertMod
- Parent Location: ./sva_dir/myAssertFile.v:281

Vacuous Proof Reporting (SVA/PSL only)
The vacuity statuses have the following meanings:

vacuous—antecedent is unreachable, so the consequent is not checked.
non-vacuous—the related property report is valid.
unknown—do not know if the related property is vacuous.
The status of the vacuity property doesn’t matter if the related property is
falsified and there is no replay miss when you run the trace in the simulator.
Note If you use disable iff in your SVAs, it is possible to get vacuous proofs
even when the antecedent to the implication operator is reachable, because
the disable iff expression becomes part of the antecedent for vacuity
checking.
Turning Off Vacuity Reporting

Vacuity reporting is on by default because vacuous properties often indicate
problems. However, you can disable vacuity reporting and possibly improve
runtime performance using a define_session command in your Magellan
project file:
define_session sessionName -noVacuityCheck
Or, you can use a set_session_info -vacuity command to turn off

vacuity reporting by specifying the sessionName and the boolean flag for
vacuity reporting. For example:
set_session_info sessionName -vacuity 0

Reporting and Debugging Witness Trace Reporting (SVA/PSL only)
Witness Trace Reporting (SVA/PSL only)

Magellan can generate witness traces for SVA and PSL asserts. A witness
trace is a series of input vectors that make a property succeed. This is in
contrast to a property proof, which means there is no series of input vectors
that can make a property false.
While there may be multiple input sequences that can make a property true,
Magellan reports the first witness trace that it finds. Generally, this result is
repeatable unless you change your design or add or modify the properties you
are testing in a Magellan session.
By definition, properties that have witness traces and use implication

operators are non-vacuous because the antecedents and consequents of
property sequences must be reachable in order for the witness trace to exist.
Compare this to vacuity reporting, where only the antecedent is checked for
reachability.
Turning On Witness Tracing

Witness tracing is off by default because it can slow tool performance due to
the additional computational complexity. To enable witness trace reporting for
a session, add the -witness switch to a define_session command in
your Magellan project file:
define_session sessionName -witness
Witness Trace Report Examples

With witness tracing enabled, the list_session_results -long report
output shows an extra Witness section for each assertion in that session.
When your test session completes, you can use this command to view the
detailed report:
For example, in Figure 61 Magellan reports that a witness trace caused the
assertion to succeed at simulation time 599 for a property that was also
proven.

Witness Trace Reporting (SVA/PSL only)
Figure 61: Witness Trace Success Report
> SVA ID [3] Proven

- Vacuity [4]: Non-vacuous
- Witness [5]: Reached (at time 599)
- Scope: top.x.y
- Instantiation: foo.v:107
- Assertion: a1
- Assertion Location: bar.v:11
In this next example (Figure 62), Magellan reports that it was unable to
generate a witness trace for a property that was proven. Because the proof is
non-vacuous, we know that the antecedent of the implication operator for this
SVA was reachable. This means that the witness trace was unreachable
because the consequent of the implication was unreachable. This kind of
result is most likely caused by an over-constrained design that leads to
dead-end states (see “Avoiding Dead-End States” on page 288). It can also be
caused by an assertion error or a bug in the design.
Figure 62: Witness Trace Failure Report
> SVA ID [6] Proven

- Witness [8]: Unreachable
- Scope: top.x.y
- Assertion: a2
Magellan also generates bounded witness trace reachability reports while

your session is running. Figure 63 shows a report generated from a
list_session_results -long command while the session was still
running. At this point the property was already proven but the witness trace
had not been reached and must be longer than 9 cycles. If you allow the
session to run to completion, Magellan classifies the witness trace as reached

Reporting and Debugging Cone of Influence Reporting
or unreachable unless the tool’s capacity is exceeded before a witness trace is

found.
Figure 63: Witness Trace Bounded Reachability Report Example
> SVA ID [9] Proven

- Witness [11]: No witness in 9 cycles
- Scope: top.x.y
- Assertion: a3
Note It is also possible to get successful or unsuccessful witness traces on

properties that are falsified.
Cone of Influence Reporting

Magellan has a cone of influence reporting feature that you can use to:
Discover which portions of your design are covered or uncovered by the
properties or coverage goals you are checking in a session. You can use
this information to help decide where additional properties or coverage
goals would improve verification completeness.
Get a list of the primary input signal names that must be properly
constrained in order for Magellan to correctly evaluate the properties or
coverage goals specified in a session (see “Constraining Input Signals” on
page 260).
Find areas in your design upstream from a complex property that Magellan
has been unable to prove or falsify in a satisfactory time, and substitute
several smaller properties in the fanin cone of that unsolved property. With
less sequential depth to evaluate, Magellan may be able to solve the
simpler properties.
Learn which registers in your design are driving signals defined in coverage
goal sets. This can be useful when you are trying to debug property
violations or reachable states.
Explore connectivity for any signal in the design.

Generating Cone of Influence Reports

Cone of influence reports show the primary inputs and sequentials for
registers in the transitive fanin cone of a specified property, coverage goal, or
design signal in your session. Magellan creates individual reports for each
property in a Property module, each SVA/OVA cover goal, and each design
signal. For RTL coverage goal sets specified with the add_coverage_info
-signal command, Magellan creates one combined report because these
goal sets generate state coverage tests in which the cone of influence is the
same for each of the specified signals.
Note Cone of influence reports are on the unoptimized design, so you don’t see the
effect of constant propagation for signals set to constants in your Magellan
project file.
To generate a cone of influence report, use a report_session -cone

command, as shown in the following example:
mgsh(alive...)> report_session -cone \
property | coverage_goal | design_signal
where the property, coverage_goal, or design_signal is defined in the

current session.
Generate a report on multiple properties, coverage goals, or design signals by

enclosing the list with curly braces:
mgsh(alive...)> report_session -cone { prop1 prop2 cov1 }
Note You cannot generate reports for design_signals in the same command
that reports on properties or coverage goals. Use separate calls.
To generate a cone of influence report for all goal sets (including checker and
constraint properties as well as coverage goals and properties) use a
report_session -cone {} command with an empty list, as shown in the
following example:
mgsh(alive...)> report_session -cone {}

Reporting and Debugging Cone of Influence Reporting
Magellan generates cone of influence reports on the screen, unless you add
the -file path_to_report_file option, in which case the report is
generated in the file name and location you specify.
Figure 64 shows a fragment from a cone of influence report for a Property

module named mutex.
Figure 64: Cone of Influence Report for Property
mgsh(running...)> report_session -cone mutex

GoalSet name: mutex[0] Property net:
/des_chip/SvaCheckerMod_2_chkr15/assert_mutex_ended_reg
Fan-in SEQs:
/des_chip/core_o_tval_de seq-distance=2
/des_chip/u_des_core/u_des_unit7/drdy_c_de seq-distance=2
/des_chip/u_des_core/u_des_unit7/dval_c_de seq-distance=2
...
Fan-in Primary Inputs:
/des_chip/i_trdy_de seq-distance=1
/des_chip/i_addr<0> seq-distance=3
/des_chip/i_addr<1> seq-distance=3
...
No. of Primary Inputs: 20 No. of SEQs: 225
The first section of the report lists the registers in the cone of influence along
with their sequential distances (seq_distance=n) from the property
(mutex[0] in this example). The second section of the report lists the primary
inputs in the fanin cone for the property. At the end of the report for each
property, Magellan prints a summary of the number of primary inputs and
sequentials.

Figure 65 shows a cone of influence report for an SVA cover defined in a

Coverage module named cover_sva.
Figure 65: Cone of Influence Report for SVA Cover
mgsh(alive...)> report_session -cone cover_sva

GoalSet name: cover_sva[0] Property net:
/mux/simpleCover_SVA_chkr0/cov_c_0_ended_reg
Fan-in SEQs:
/mux/simpleCover_SVA_chkr0/cov_c_0_inst/state12 seq-distance=1
/mux/simpleCover_SVA_chkr0/cov_c_0_inst/state15 seq_distance=1
/mux/c seq-distance=2
Fan-in Primary Inputs:
/mux/d1 seq-distance=1
/mux/cntrl<0> seq-distance=2
/mux/cntrl<1> seq-distance=2
mux/d4 seq-distance=2
No. of Primary Inputs: 6 No. of SEQs: 3
Reporting Registers and Inputs Outside of the Cone of

Influence
To generate a cone of influence report that shows the primary inputs and
registers that are not in the transitive fanin cone of specified properties,
coverage goals, or design signals in your session, use a report_session
-uncovered -cone command, as shown in the following example:
mgsh(alive...)> report_session -uncovered -cone \
property | coverage_goal | design_signal
where the property, coverage_goal, or design_signal is defined in the

session you are currently running. Generate a report on multiple properties,
coverage goals, or design signals by enclosing the list with curly braces:
mgsh(alive...)> report_session -uncovered -cone \
{ prop1 prop2 cov1 }
To generate a cone of influence report that shows the primary inputs and
sequentials for registers that are not in the transitive fanin cone of any
properties or coverage goals in your session, use a report_session

Reporting and Debugging Assertion Cone of Influence Reporting
-uncovered -cone {} command with an empty list, as shown in the

following example:
mgsh(alive...)> report_session -uncovered -cone {}
Assertion Cone of Influence Reporting

You can use the show_coi command at the MG shell prompt to report the
cone of influence (COI) for properties specified with:
Asserts and covers of any type (for example, SVA, PSL, or OVL)
RTL signals
Run the show_coi command any time after reading in your Magellan project
file (using a read_project command). In order to report on assertion COI,
Magellan first builds a design netlist. Iterative analysis is supported (Magellan
rebuilds the design when needed due to changes in the project state).
For example, to see the COI for all assertions used as checkers in your
design:
mgsh(alive...)> show_coi [sessionName] -scope * -checker
Running the above command on the Verilog tutorial design shipped with the
tool generates a report that looks like Example 157. Because the
des_chip.assert_mutex assertion is bound to a module that is
instantiated 16 times in this design, you get one COI report for each instance.
(See “SVA Combinational Property Proof” on page 41.)
Example 157: show_coi Report Example
--------------------------------------------------
Coi Report For
Goal:des_chip.u_des_core.u_des_unit0.dd_d.assert_mutex_
inst.assert_mutex
--------------------------------------------------
# Constraints: 0
# Inputs: 21
# Sequentials: 225
# Combinationals: 3856 ...

Assertion Cone of Influence Reporting
Alternatively, you can report on assertions used as constraints with the

-constraint switch, covers with the -cover switch, or RTL signals with the
-signal switch.
If a session is currently running or there is only one session in your Magellan

project, you don’t need to specify a sessionName.
Notice that the -scope option supports regular expressions such as * to

specify the names of assertions to be shown in the report.
The show_coi command has the following switches and options, which you
can use to customize the report:
Add the -detail switch to break down the reported nodes into design,
glue logic, and automaton nodes (automatons are created by the assertion
compiler).
Assertion COI analysis normally includes the logic of the assertion, the
design, and any constraints that may be relevant. Use the -isolate
switch to remove the contribution from constraints. Relevant constraints are
those that could possibly control design signals in the COI as determined
by a structural analysis.
Use the -type option to filter the results. Filtering options include:
pi (primary inputs only)
seq (sequentials only)
comb (combinationals only)
constraint (relevant constraints only). Constraint relevance takes
into account multiple clocks and the clock tree.
all (all of the above). This is the default.
Use the -enumerate switch to print node names. The reported names are
not bit-blasted. When you don’t use this switch, the show_coi command
produces a summary report by default.
For example:
mgsh(alive...)> show_coi -scope * -checker -detail \

-isolate -enumerate -type { pi seq }

Reporting and Debugging Debugging Property Violations
This command produces a detailed report that lists the design primary inputs
and sequentials, glue logic sequentials, and automaton sequentials in each
assertion COI without taking into account constraint relevance.
Debugging Property Violations

During or after a session run, you can use a view_session_results
command to automatically start the debugger on any falsified properties or
reached coverage goals. Or you can use a write_session_test command
to save the test stimulus and later use the test.csh test driver to invoke the
debugger on the trace. Alternatively, you can start the Magellan GUI (mgui),
which is especially useful in the debug flow. You can also bring up a single
falsified property in the debugger. This section explains how to use the
different debugging options in the following subsections:
“Setting a Default Debugger” on page 445
“Controlling Dumping” on page 447
“About Waveform Readability” on page 449
“Debugging Without Saving the Test Stimulus” on page 449
“Debugging a Previously Run Session” on page 450
“Saving Test Stimulus for Later Replay” on page 451
“Moving Tests to Another Location” on page 452
“Debugging a Single Falsified Property” on page 453
“Creating VPD Files with VCS (Verilog only)” on page 454
“Creating VPD Files with VCS MX (VHDL only)” on page 455
Setting a Default Debugger

DVE is the default debugger in Magellan. If you want to use Debussy or Verdi
instead as your default debugger, you have several options to configure this:
To set a default debugger at the individual project file level, add a
set_project_info -debugger command to the Project module. For
example:
set_project_info -debugger debussy

To set a global default debugger for all invocations of MG shell, create a

.mgsh_rc file in your $HOME directory that contains a
set_debugger_override command. For example:
set_debugger_override -debussy
This setting has higher precedence than the setting in a Magellan project
file.
You can override the default debugger when you run a command by
specifying the appropriate switch. For example, if your default debugger is
Debussy, you can use Verdi instead by adding the -verdi switch to the
command:
mgsh(alive...)> view_session_results -verdi
The order of precedence Magellan uses when invoking a debugger is:
1 Use the debugger specified with a switch when view_session_results

is run (-debussy, -verdi, or -dve). These switches override any other
settings. Note that if you did not have the same debugger specified when
you ran the session, Magellan generates an error message telling you to
rerun with the same debugger specified so that the required trace file
format is available.
2 Else, use the debugger specified with a set_debugger_override

command in a .mgsh_rc file in the user’s $HOME directory.
3 Else, use the debugger specified with a set_project_info -debugger

command in the Magellan project file.
4 Else, use DVE.

Controlling Dumping
During a session run, Magellan generates VPD or FSDB files for DVE or
Debussy/Verdi, respectively (see “Setting a Default Debugger” on page 445).
By default, Magellan includes all debug data from the top level of the design
on down, including multidimensional array (MDA) data if you enable its
generation using a define_session -dumpMda command in the Session
module of your Magellan project file. Depending on the design you are testing,
this global dumping can be expensive in terms of disk space usage and slower
tool performance. You can refine and control Magellan’s dumping behavior
using a custom Tcl procedure in a file named mg_dump.tcl in the same
directory where you keep your Magellan project file. For example, you might
want to limit the portions of the design hierarchy for which data is dumped. For
more information on how to control waveform dumping see the VCS/VCSi
User Guide ($VCS_HOME/doc/UserGuide/vcs.pdf).
You can either create the Tcl procedure file yourself or copy and modify the
mg_dump.tcl file that Magellan creates in the mg_sessionName/.temp/script
directory during a session run.
When you run a Magellan session, the tool looks first in the project directory
for a user-specified mg_dump.tcl file. If no dump control file is present,
Magellan creates a new mg_dump.tcl file in the mg_sessionName/.temp/script
directory, overwriting any mg_dump.tcl file that may be left over from a
previous run of the same session.

The mg_dump.tcl file includes Tcl procedures for both DVE and
Debussy/Verdi users (see Example 158).
Example 158: Default Dump Control File (mg_dump.tcl)
# This proc controls the VPD dumping used by Magellan.

# The proc mg_dump_vpd must be set.
proc mg_dump_vpd { vpdfile design mgrun } {
if { $mgrun == 1 } {
dump -file $vpdfile -type vpd
}
dump -autoflush on
dump -interval 200
dump -add top_$design -aggregates -depth 0
}
# This proc controls the FSDB dumping used by Magellan.

# The proc mg_dump_fsdb must be set.
proc mg_dump_fsdb { fsdbfile design mgrun } {
if { $mgrun == 1 } {
fsdbDumpfile $fsdbfile
}
fsdbDumpvars 0 "+mda"
fsdbDumpSVA
call "\$fsdbDumpPSL(0, top_$design)"
}
Note that for DVE users. the proc mg_dump_vpd line must be present. For
Debussy/Verdi users, the proc mg_dump_fsdb line must be present.
Magellan uses the mg_dump.tcl file to create VDP or FSDB files during a
session run. You can change the default dumping behavior by supplying your
own mg_dump.tcl file that redefines the Tcl procedures shown in
Example 158. When Magellan calls one of these Tcl procedures, the tool
passes in the vpdfile or fsdbfile name and design name. Add the
desired UCLI dump commands to the procedure. Magellan passes the dump
commands you specify directly to the simulator and does not check them for
correctness, so make sure they are legal commands for the debugger you are
using.

About Waveform Readability

To improve waveform readability for reached goals, Magellan optimizes away
some input changes that have no effect in certain phases of the design clock.
A complete optimization would be costly, so you still may see some input
changes that are not important to goal reachability. For more information, see
the unobservedInputs.log file in the mg_sessionName/user directory. This file
contains two sections:
Unobserved Primary Inputs—lists inputs that cannot affect search results;
Magellan removes them from the set of inputs that receive random stimulus
during the test.
Sensitivity to Primary Inputs—explains why some primary inputs driven by
Magellan need to receive stimulus during certain phases of the design
clock, either because they affect goals, constraints, or sequentials in your
design or environment. This section is relevant primarily for designs that
have complex clocking.
Debugging Without Saving the Test Stimulus

You can use a view_session_results command to bring up the debugger
on a trace (see “Running a Session” on page 140). For example:
mgsh(running...)> view_session_results
Make sure you have the correct debugger specified for viewing the VPD or
FSDB file. If you need to override the default debugger, add the -dve,
-debussy, or -verdi switch. See “Setting a Default Debugger” on page 445.
You can also use MGUI to view the waveforms for the failure. Just type mgui
at the MG shell prompt:
mgsh(running ...)> mgui
The GUI comes up with your current session information already displayed in
the Report tab. You can then click on the results in the Report tab or go to the
Monitor tab to view the results in your selected debugger.

Debugging a Previously Run Session

The view_session_results command supports an optional
sessionName argument that you can use to bring up the debugger on a
previously run session as long as you did not delete the mg_sessionName
directory that Magellan creates when you run the tool. For example:
mgsh(running...)> view_session_results s1
The example in Figure 66 shows the DVE waveform viewer displaying a

violation for an SVA named assert_pipe_ctrl at simulation time 20,000.
Figure 66: SVA Failure in DVE Waveform Viewer

Saving Test Stimulus for Later Replay

If you want to save stimulus traces for later evaluation or replay Magellan
traces in regressions, use a write_session_test command. When the
write_session_test command completes, you can invoke the test driver
script (test.csh) in UNIX. For example:
mgsh(alive...)> write_session_test ./dirname
where dirname is the path name where you want to store the test files. If the
directory does not exist, Magellan creates it. If the directory already exists,
Magellan replaces any existing files with the new test files. If you do not
specify a dirname, Magellan puts the test files in the
mg_sessionName/test/testbench directory by default.
To replay the stimulus file, enter test.csh at the UNIX prompt. For example:
% ./dirname/test.csh
The test.csh script is the driver for the test, which runs in batch mode by
default. To run and then invoke the debugger on the test, add the -dve,
-debussy, or -verdi switch to your test.csh command, depending on
the tool you are using.
If you use the -debussy or -verdi switch, make sure you have
$DEBUSSY_HOME or $VERDI_HOME set to the location of your Debussy or
Verdi installation.
By default, Magellan reduces the runtime of the stimulus file by removing

simulation cycles that are not needed to demonstrate the property violation. If
you want to see all simulation cycles, add the -nocompress switch to your
test.csh invocation.
Note The test.csh script does not track changes in dependencies from previous
invocations. If you change any of your design files or the switches used with
test.csh, you must do a test.csh -clean before rerunning the test. For
more information on test.csh script options, see the man page (type man
test.csh at the MG shell prompt).

Specifying Simulator and Debugger Options

You can specify runtime options for the simulator and debug options for the
debugger by adding the following options to your test.csh invocation:
-compOpts options
-runOpts options
-debugOpts options
If the specified options contain embedded spaces, enclose them in

quotation marks. For example:
% test.csh -runOpts “-ova_success -ova_filter” -dve
The -compOpts, -runOpts, and -debugOpts options are not mutually

exclusive. Make sure the options you specify are appropriate for the simulator
and debugger you are using.
Moving Tests to Another Location

If you want to move a test to another location, be sure to copy the entire test
directory. For example:
% cp -r ./dirname /u/julius
where dirname is the directory name specified with the

write_session_test command.
When you run the test.csh test driver script from the new location, Magellan
reuses the VCS command line specified in your Magellan project file with the
set_design_info -vcs command. If the design files for the test are in a
different location relative to the original project directory, specify the new
container directory for the design files using the -srcDir option to the
test.csh command. For example:
% /u/julius/dirname/test.csh -srcDir mySrcDir
If your Magellan project file uses absolute paths to the design source files
used in the test, do not use the -srcDir option. The absolute paths continue

to work in the new test directory location as long as you run test.csh on the
same network where the original test was run.
Otherwise, specify the -srcDir so that test.csh knows where to find the
directory from which the design source files are referenced in this new
location.
Debugging a Single Falsified Property

You can debug a single falsified property using a view_session_results
command or the test.csh test driver by using the -prop option to specify
the Property or AEP module name and signal index value. After Magellan
falsifies a property, use a list_session_results -long command to get
the property index value—it corresponds to the ID number, which appears
next to the property status in the report output for each goal found in the
session. For example:
> ID: [0] Falsified

- SimTime : 2099
- Update : 14:07:07 - Aug 14
- Random Cycles : 13
- Formal Cycles : 0
- Scope : des_core.u_des_unit0.pipe_ctrl_1
If you want to debug the falsified assert_pipe_ctrl assertion, specify the

property module name (pipe_ctrl) and goal index value (0) for the test. For
example:
mgsh(alive...)> view_session_results -prop pipe_ctrl:0

You can also save the test stimulus using a write_session_test

command and then invoke the test.csh test driver from the default or
user-specified test directory:
% test.csh -dve -prop pipe_ctrl:0
The waveform viewer displays the system clock, system reset, user-specified
design clock, and inputs to the module that caused the assertion to fail.
Replaying Stimulus with ModelSim VHDL

To replay the stimulus file in Model Technology’s ModelSim VHDL simulator,
follow these steps:
1 Set the MODELTECH environment variable, and include it in your PATH

environment variable.
2 Do not change the default ModelSim path name separator from a slash /.
3 Do not use unlabeled processes in your VHDL code.
4 Invoke the test.csh replay script using the following command:

% mg_sessionName/test/dirname/test.csh -mti
Creating VPD Files with VCS (Verilog only)

The VPD file is a compressed binary file that records the standard VCD
information and the order of statement execution in a module. To create a
VPD file, follow these steps:

1 In your Verilog source code, add the $vcdpluson and $vcdplusoff

system tasks. Example 159 shows a code sample that records all signal
data from simulation time 1000 to 5000.
Example 159: VPD Code Sample
initial
begin
#1000 $vcdpluson;
#5000 $vcdplusoff;
end
For more information on the $vcdpluson and $vcdplusoff system

tasks, see the VCS/VCSi User Guide.
2 In the Magellan project file, add the -PP compile-time VCS option to the
command line you specify using set_design_info in the Design
module.
3 When the session that references this environment finishes, use the
following command to view the results:
% vcs -RPP +vpdfile+vcdplus_filename.vpd
The file that VCS creates is named vcdplus.vpd. To create the file with a
different name, use the VCS +vpdfile+filename runtime option. For
more information, see the VCS/VCSi User Guide.
Creating VPD Files with VCS MX (VHDL only)

1 After the run completes, use a write_session_test command to save
the stimulus in VPD format. The dump.cmd file created by the
write_session_test command includes the commands to create the
VPD file. You can change the VPD file name using the -o filename
option to the dump command. For more information on the VCS MX dump

command, see the VCS MX/VCS MXi User Guide,. Example 160 shows
the contents of a dump.cmd file.
Example 160: The dump.cmd File
cd top_netSignal
dump -vpd -o vcsmx.dump -deep *
2 Replay the stimulus file using the test.csh script and the -vpd switch:
% test.csh -vpd
The test.csh script creates a VPD file in the current working directory.

15
Detecting
Simulation/Synthesis
Mismatches
This chapter describes Magellan’s simulation/synthesis mismatch detection feature, and
explains how to diagnose and debug mismatches.
In This Chapter
Understanding Mismatch Detection in Magellan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Checking for Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Responding to Replay Misses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Responding to Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Responding to Unknowns on Goal Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Diagnosing Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Generating VCD Files for Formal Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Understanding Mismatch Detection in Magellan

A simulation/synthesis mismatch occurs when the behavior of the RTL
simulation model does not match the behavior of the formal, or structural
model generated during synthesis. These mismatches cause differences
between the RTL simulation and silicon results. If not corrected, these
differences may affect the quality of Magellan’s verification results, and may
also cause unexpected behavior in the final circuit implementation.
Note Mismatches can occur not only in the design, but also in assertion-style
constraints in the test environment, because Magellan creates formal and RTL
simulation models of constraints too. For more information, see
“Simulation/Synthesis Mismatches with Constraints” on page 274.
Magellan depends on the simulation model and the formal model behaving the
same. Undetected mismatches may cause Magellan to miss defects, report
inconclusive or contradictory results, or generate errors. It is difficult to know if
Magellan is missing defects or reporting inconclusive results because of a
mismatch in the simulation and formal models. As a result, it is a good idea to
use Magellan’s compare functionality to discover mismatches early in the
validation process.
When you run a session for the first time, check for mismatches for at least a
few minutes using a run_session -compareAlways command (see
“Checking for Mismatches” on page 461). Many mismatches are detected
within the first few cycles of simulation.
Repeat this process for each new session you run. Magellan only checks the
target area of the design and the transitive fanin referenced by the coverage
signals and property checkers in the Session module. You should also repeat
this process if you make changes to the design or environment. Interaction
between the design and constraint models in your environment can also
produce mismatches.
If you don’t find any mismatches, proceed with the property or coverage goal
search. If you see subsequent messages indicating a replay miss, run the
session with a run_session -compareReplay command (see
“Responding to Replay Misses” on page 462).

Detecting Simulation/Synthesis Mismatches Understanding Mismatch Detection in Magellan
Mismatch detection in Magellan depends on random simulation; it is not a

formal process. Failure to detect a mismatch does not ensure that a mismatch
will never be found. However, experience has shown that random mismatch
detection is quite effective, and quickly reveals most simulation/synthesis
mismatch problems.
About the Compare Cycle

Magellan provides comparison functionality to identify where mismatches
occur in the design. The compare only occurs when you specify the
appropriate switches to the run_session command (see “Checking for
Magellan compares states in the fanin of your coverage or property signals.

While running a session with comparison enabled, at each clock cycle
Magellan samples the present state and the inputs, and compares the
computed next-state from the simulation and formal engines. This continues
until the search terminates or Magellan finds a mismatch.
Figure 67 shows the compare cycle. Given that the clock period is T, at t=0 the
system clock rises. At T/4, Magellan samples the circuit state and stores the
information for later comparison. At T/2, Magellan applies stimulus to the

primary inputs of the design. Magellan repeats this process for each clock
cycle during the compare.
Figure 67: Simulation/Synthesis Compare Cycle
Sample Sample Sample

State State State
S1 S2 S3
t=0 t=T t=2T
System Clock
Drive Drive
Inputs Inputs
I1 I2
Sample Sample
Nets Nets
At one tick before T, Magellan records all the net values in the design.
Magellan uses this information only if it detects a mismatch.
At one quarter cycle into the second clock period, Magellan downloads the
previous state (S1), the previous inputs (I1), and the current state (S2) from the
simulator. The formal engine reads in the previous state (S1), applies the
inputs (I1), and computes the next state (N). Magellan compares the current
state (S2) from the simulator and the computed state (N) from the formal
engine.
If the comparison passes, Magellan continues with the next cycle and repeats
the process. If the comparison fails, Magellan saves the state information that
identified the mismatch, generates a series of reports, issues an error, and
pauses the run. At this point, you can write out a test to debug the problem or
continue the run (see “Responding to Replay Misses” on page 462).

Detecting Simulation/Synthesis Mismatches Checking for Mismatches
Checking for Mismatches

The run_session command has four switches that you can use to detect
simulation/synthesis mismatches:
-compareAlways
As the session run progresses, Magellan compares every state in the
transitive fanin of the session’s property and coverage goals at every cycle
beginning at time zero. This is extremely slow, but it is the most effective
way to detect mismatches.
Some mismatches may not be easily detectable this way; for example, if
they only appear when the design is in a specific state that has a low
probability of occurring, or if they only appear after a very large number of
cycles. In these cases, use the -compareReplay switch.
-compareReplay
With you use this switch, Magellan only runs the cycle-by-cycle comparison
during the replay of stimulus found by the formal engines. All other
simulation cycles driven by random stimulus run normally. Therefore, this
runs much faster than if you use the -compareAlways switch.
The limitation of this approach is that Magellan only does the comparison
when the formal engines find new stimulus sequences.
-compareFullDesign
This switch is only meaningful in combination with -compareAlways or
-compareReplay. In this mode, Magellan compares all registers and
outputs in the design, not just those in the transitive fanin of your session
goals.
-noCompareX
When you use this switch, Magellan does a weak comparison. A weak
comparison considers any X logic value in the next state to be a “don’t
care.” An X value matches both a logic 0 and a logic 1.
The default is to do a strong comparison, which treats X as a unique value;
in this case, an X value only matches an X value.
Only use this switch if Magellan reports mismatches for X values that you
know are not significant to the correct function of the design.
Use this switch with -compareAlways or -compareReplay.

Responding to Replay Misses
Responding to Replay Misses

When the formal engines find a trace to a new goal state or property violation,
Magellan replays the stimulus sequence in the simulator to make sure that the
expected goal state is reached in the simulation model. If the simulation does
not reach the expected goal, Magellan reports a replay miss. The messages
you see in this situation look similar to the following:
*** Error: (HVSI-045)
Logic compare failure at t=2070776 for goal:sms
Expect:01001000 Actual:10100000

Replay MISS of formal trace
Potential Simulation/Synthesis mismatch!
Magellan records the error as an ignore-miss in the mgsh_messages.log in

the project directory and the goals.log file in the mg_sessionName/user
directory. When you see this type of error, run the Session module again using
the -compareReplay switch to determine the cause of the replay miss:
mgsh> run_session -compareReplay
Debugging Replay Misses

You can use a view_session_results -prop command to bring up the
debugger on a trace that includes ignored signals. For example:
mgsh(running...)> view_session_results -prop prop1:0
Use a list_session_results command to get the index number of the

goal that generated a replay miss and specify that index number with the
-prop option (0 in the example above). The waveform viewer comes up
showing the time when the replay miss occurred. Determine the root cause of
the replay miss and modify the design before trying your run again.

Detecting Simulation/Synthesis Mismatches Responding to Conflicts
Responding to Conflicts
Conflicts occur when Magellan’s formal engines report a goal as unreachable
(for example, prove a property), but the simulator reaches the goal (for
example, falsifies the same property). This can occur in case statements
where the case-guard is not initialized or the case statement is a casez or a
casex. When Magellan detects a conflict, it issues a message similar to the
following:
*** Warning: (HVUT-019)
Property:aep1 Bit:/cases/full_case/outval
Specified(0) both Reached and Ignore
Magellan records the warning as an ignore-conf in the

mgsh_messages.log in the project directory and the goals.log file in the
mg_sessionName/user directory.
Debugging Conflicts
When you see this type of problem, run the Session module again using the
-compareAlways switch to determine the cause of the conflicting results:
mgsh> run_session -compareAlways
Responding to Unknowns on Goal Signals

When a goal signal goes to an unknown value (X) in simulation before it has
been classified by the formal engines during a Magellan run, you get an error
message similar to the following:
*** Error: (HVUT-076)
Signal:rlm.ova_fifo_OVA_chkr5.ova_f_fifo_overflow of
goal:Fifo_check has transitioned to X
A goal signal can be a property you are trying to prove/falsify or a coverage

goal you are trying to reach. In both cases, when a goal signal goes to X in
simulation, you can no longer trust a proof or coverage result for that goal.

Responding to Unknowns on Goal Signals
When a goal signal goes to an unknown value (X) in simulation after it has
been classified by the formal engines, you see a different error message
similar to the following:
*** Error: (HVUT-077)
Signal:rlm.chkr3.ova_one_hot of goal:One_hot_check prop X
transition conflicts with rlm.chkr3.ova_one_hot
classification
Magellan records both of these types of errors as ignore-x in the

mgsh_messages.log in the project directory and the goals.log file in the
mg_sessionName/user directory. The log files show a record similar to the
following:
Fifo_check 0:00:16 10839900 Property [ 16]=ignore-x
Unknowns on goal signals in simulation are typically caused by design errors.
Debugging Unknowns on Goal Signals
You can use a view_session_results -prop command to bring up the

debugger on a trace that includes goal signals which went to unknown values.
For example:
mgsh(running...)> view_session_results -prop prop1:0
Use a list_session_results command to get the index number of the

goal that went to an X value and specify that index number with the -prop
option (0 in the example above). The waveform viewer comes up showing the
time when the goal signal went to an unknown value. Determine the root
cause of the problem and modify the design before trying your run again.

Detecting Simulation/Synthesis Mismatches Diagnosing Mismatches
Diagnosing Mismatches
Magellan uses well-established synthesis techniques to produce the formal
model. There are a variety of HDL coding constructs that can lead to
mismatches between the simulation and formal models. The following
sections explain how to identify some of these constructs and locate the
problems.
Identifying Code That Leads to Mismatches

When Magellan finds a mismatch, it reports the mismatch as shown in the
following message:
*** Information (HVSI-403)
Diagnose mismatch on StateBit:/qrm_top/Mem<1><60>
(synth=1 sim=0)
There are several techniques you can use to find the cause of the mismatch:
Examine the source code where the registers are assigned. Look for
questionable coding styles that could cause the mismatch.
When Magellan pauses, use a write_session_test command to save
the stimulus, and then run the test.csh script with the -nocompress
switch to debug the mismatch in the simulator. You need the
-nocompress switch in order to see all simulation cycles and find the time
step where the mismatch occurred.
Use the vector and diagnosis files that Magellan generates to help identify
the source of the problem (see “Using Magellan’s Mismatch Reports” on
page 471).
Blocking Assignments
Blocking assignments that cause race conditions can also cause
simulation/synthesis mismatches. This is because the evaluation order for
simulation and formal models can differ. The simulator evaluates all blocking
commands first, and then executes non-blocking assignments at the end of
the cycle. The formal model has no concept of blocking and non-blocking
assignments and evaluates them simultaneously.

In a synchronous always block, don’t use blocking assignments.

Example 161 shows a blocking assignment.
Example 161: Blocking Assignment Causing a Mismatch
macromodule regx (Q, D, C);

parameter Size = 1;
output [Size-1:0] Q;
input [Size-1:0] D;
input C;
reg [Size-1:0] Q;
always @(posedge C)
Q = (D + 1’b1);// blocking assignment
endmodule
Example 162 shows the corrected regx module. To correct the mismatch,
replace the blocking assignment with a non-blocking assignment.
Example 162: Non-blocking Assignment Correcting the Mismatch
macromodule regx (Q, D, C);

parameter Size = 1;
output [Size-1:0] Q;
input [Size-1:0] D;
input C;
reg [Size-1:0] Q;
always @(posedge C)
Q <= (D + 1’b1);// non-blocking assignment
endmodule

Latch-based Designs with Zero Delay Between D Input and Clock

In latch-based designs it is possible to have hazards or races between the D
input and the clock that result in simulation/synthesis mismatches in Magellan.
However, this type of mismatch can be difficult to diagnose. One limitation is
that even when you run Magellan with the -compareAlways and
-compareReplay switches hunting for mismatch causes, the diagnose.out
report for this issue does not point to the sequential causing the problem.
Instead it says there are No bad fanin nets detected, as shown in the
following example:
Sequential:top_tc_mpq.tc_mpq.dp_mpq.mpqa.rd_data[7]
(SynVal:0 SimVal:1)
No bad fanin nets detected
But this kind of mismatch can be caused by a problem with a sequential in the
fanin net. Sometimes the root cause is a 0-delay race between clock and data
on a latch, where the formal model resolves the race one way and the
simulation model resolves it the other way. In this case Magellan does not
report the sequential causing the mismatch because the race behavior
happens in the same timestep where the clock happens. Because formal
analysis cannot change the values of sequentials more than once per
evaluation cycle, Magellan needs a minimum setup time of 1 timestep. You
can fix problems like this by putting a #1 delay on the clock instead of a
delta-cycle delay. Put the modified code inside ‘ifdef
MAGELLAN_MISMATCH_FIX or something similar and define that macro in the
VCS command line you specify in the Design module of your Magellan project
file.
Note The diagnose.out report record shown above can also be caused by blocking
assignments (see “Blocking Assignments” on page 465).
Incomplete Sensitivity List

Incomplete sensitivity lists can cause simulation/synthesis mismatches. The
formal model is sensitive to every input signal change. The simulation model
may only be sensitive to a subset of the signals. The result is models that do
not match. Example 163 shows a block with an incomplete sensitivity list.

Example 163: Incomplete Sensitivity List Causing a Mismatch
module test (clk, rst, enable, din, dout) ;

input clk, rst, enable;
input [7:0] din;
output {7:0] dout;
reg [7:0] pre_dout, dout;

pre_dout <= dout;
always @(rst or enable)// Incomplete sensitivity list

if (rst) dout = 0;
else if (enable) dout = din;
else dout = (pre_dout);
endmodule
Example 164 shows the corrected test module. To correct the mismatch,
complete the sensitivity list.
Example 164: Complete Sensitivity List Correcting the Mismatch
module test (clk, rst, enable, din, dout) ;

input clk, rst, enable;
input [7:0] din;
output [7:0] dout;
reg [7:0] pre_dout, dout;

pre_dout <= dout;
always @(rst or enable or din or pre_dout)

// Complete sensitivity list
if (rst) dout = 0;
else if (enable) dout = din;
else dout = (pre_dout);
endmodule

X Values
X assignments can cause mismatches and replay misses if they are in a part
of the design critical to a coverage or property goal or are in the reset
sequence. X and Z values propagate differently in the simulation model and
the formal model. For the best results, initialize values to a known state.
Figure 68 shows two models of a multiplexer: the simulation model and the
gate-level formal model.
Figure 68: Multiplexer Models
a
a 0
y
b 1
y
b
Q Q .
Simulation Model Formal Model
In the simulation model, if both data inputs, a and b, are set to a logic 1, and
the selector, Q, is an X, the y output is a logic 1. However, with these same
inputs, in the formal model the y output is a logic X. This difference in the y
output may result in a simulation/synthesis mismatch.
To minimize the potential for mismatches, Magellan sets X values to a logic 1

or 0. For more information on how Magellan manages X values in the reset
sequence, see “Handling Uninitialized Registers” on page 250.
During the Random Generation phase, Magellan periodically downloads

design state information from the simulator into the formal model as a starting
point for formal analysis. This information is from sequentials inferred by the
synthesis process located in the target area and the target area’s transitive
fanin.
If any of these state-holding elements are logic X or Z at the time of the

download, Magellan sets all state elements with an X or Z value to “don’t
cares” for reachability and unreachability analysis. This reduces the potential

for replay misses (see “Responding to Replay Misses” on page 462).

However, these changes may prevent Magellan from proving that states are
unreachable. For Magellan to prove that a state with a “don’t care” sequential
is unreachable, it must prove the case for both a logic 1 and a logic 0.
Magellan logs messages about X values in the download state. Magellan also
logs when a property signal or a signal in a coverage goal transitions to an X in
the simulator. To view this information, use a report_session -xinfo
command.
Note Magellan cannot change X values in state-holding UDPs. Therefore, you need
to reset them to a logic 0 or 1.
Incorrect Clock Periods (Verilog only)

If your design is written in Verilog, make sure that the sum of all the #delay
statements on any combinational path does not exceed one quarter of the
system clock period. Otherwise, you may get simulation/synthesis
mismatches (see “Specifying Clock Periods and Time Units” on page 208).
Verilog Functions with Incomplete Sensitivity Lists

Verilog functions are only re-evaluated by the simulator when input
parameters to the functions change. They are not re-evaluated when global
signals referenced inside the function change. To prevent difficult-to-debug
simulation/synthesis mismatches with this root cause, avoid using functions
with incomplete parameter lists inside constant assignment expressions.

Using Magellan’s Mismatch Reports

When Magellan discovers a mismatch, it generates a series of vector reports
and a diagnosis report. Use the diagnosis report to help you identify where the
mismatch occurred.
Using Magellan’s Diagnosis Report

Magellan generates a diagnosis report called diagnose.out and saves it in the
mg_sessionName/user directory. This file contains net-by-net comparisons for
the transitive fanin of each state-holding register or logical output where a
mismatch occurred. Studying the source code locations where any
mismatched fanin nets are assigned may help you find the source of the
mismatch.
The diagnose.out file begins with a header line that shows the simulation time
when the mismatch was detected, The rest of the file is formatted as a
sequence of data blocks, where each block is a failing register or output,
followed by nets in the transitive fanin for that register which were also
mismatches.
The format for the sequential or output statement is:

Sequential: RTL_Name (SynVal:LogicVal SimVal:LogicVal)
-or-
Output: RTL_Name (SynVal:LogicVal SimVal:LogicVal)
where:
RTL_Name is a sequential or output name in Verilog or VHDL format.
The top of the hierarchy is the design’s top module or the instance name
of the checker or constraint model.
SynVal is the logic value computed by the formal engine.
SimVal is the simulation value for the sequential or output.
LogicVal is 1, 0, or X.

The format for the failing net compare statement is:
Mismatch: RTL_Name SynVal:LogicVal SimVal:LogicVal
where RTL_Name is a failing net driver, in Verilog or VHDL format. The top of
the hierarchy is the design’s top module or the instance name of the checker
or constraint model.
Figure 69 shows a sample diagnose.out report for a mismatching register with

one mismatching fanin and one mismatching output.
Figure 69: Sample diagnose.out Report for Mismatches
Simulation vs. Synthesis Mismatch Report for Time:513
Sequential:top_ytgz_dma2ocn_top.ytgz_dma2ocn_top.ytcz.y
tcr.ytce.rq_done_reg.i000.L2[5]
(SynVal:1 SimVal:0)
Fanin
Mismatch:top_ytgz_dma2ocn_top.ytgz_dma2ocn_top.ytcz.ytc
r.ytce.rq_done_reg.i000.L1[5]
SynVal:1 SimVal:0
Output:top_test_mismatch.test_mismatch.mem_[0]
(SynVal:0 SimVal:1)

Detecting Simulation/Synthesis Mismatches Generating VCD Files for Formal Traces
Generating VCD Files for Formal Traces

If you want to view waveforms of just the simulation traces generated by the
formal engines, add the -formalVcd switch to the run_session command
when you run a session. With this option enabled, Magellan generates VCD
files for each formal trace replayed in the simulator as your session
progresses, even if the trace generated a replay miss in the simulator (see
“Responding to Replay Misses” on page 462). These VCD files show the logic
values of circuit inputs, sequentials, and nets predicted by the formal engines
when the trace was generated.
The VCD files are named TraceFile.simTime.vcd, where simTime is the

simulation time step when the trace replay began in the Magellan session.
You can find these VCD files in the mg_sessionName/user directory.
Note Formal VCD traces are only long enough to show where a goal was met or a
property falsified in the formal model. They are not simulation results like you
get when you use a write_session_test command after a completed
Magellan run.
When you view the waveforms generated by these VCD files in the simulator,
keep in mind that the RTL simulation model for your design and the formal
gate-level model are different, even if you take care to remove
synthesis/simulation mismatches. For example, there may be nets that exist
only in the formal model. And the formal model only looks at signals in the
transitive fanin of properties or coverage goals defined in that session. This
process is known as pruning or circuit abstraction. Finally, Magellan uses a
system clock to drive the formal model to enable formal analysis of designs
with complicated clocking schemes (for example, derived or gated clocks). In
such cases, Magellan's system clock is represented explicitly in the VCD file.

Generating VCD Files for Formal Traces

Glossary
AEP module. A section of the Magellan project that defines which properties
Magellan should automatically check. You can define any number of AEP
modules in a project.
Assertion. See Property.
Block. A design entity partitioned for reuse, reduction of design and

specification complexity, parallel design and verification efforts, or physical
design considerations.
Bounded proof. A proof which indicates that for any stimulus of N cycles
from the Reset State, the property is always true. See also Proof.
Breakpoint. A point at which simulation pauses. In Magellan, breakpoints

can be user directed or caused by a property violation or simulation/synthesis
mismatch.
Build server. The process started when you enter a build_session

command or start a build with a run_session command. The Build server
process initiates two additional build processes: the Formal build process and
the Simulation build process.
Checker. A piece of verification code that monitors the design for compliance
with a property. The checker asserts an output signal if the design behavior
violates the property.
Classified state. A state or value of one or more goal signals that Magellan
identifies as reached or unreachable. For reached states, Magellan provides a
stimulus sequence to reach the states. For unreachable states, no legal inputs

Glossary
can reach the states. Magellan labels states that it has not yet classified as
unknown.
Combinational loop. A circuit with a signal path that only propagates

through combinational design elements back to itself. A combinational loop is
considered non-state holding if the output is only a function of the current
inputs, and not any previous values.
Compressed truth table. A truth table format reporting a set of binary values
that represent reached, unreachable, and unknown states.
Each signal in the compressed truth table is identified with a particular bit
position. The dashes in a bit position indicate both bit values are included. For
example, the Reached report indicates the following six states were reached:
0000
001- (reached both 0010 and 0011)
10-0 (reached both 1010 and 1000)
1100
Constraint model. A piece of verification code that transforms random inputs

into legal stimulus for the design. You can use more than one constraint model
in a project.
Coverage goal. See Goal set.
Coverage module. A section of a Magellan project that specifies signals to

target while generating high-coverage stimulus. The set of signals included in
a Coverage module is called a goal set. You can define any number of
Coverage modules in a project.
Design module. A section of a Magellan project that describes the design

under test. Here you give the design a name, identify the top module, list the
design files, and list any include directories used in the design files. There is
only one Design module per project.
Dynamic formal verification. A combination of random simulation and

formal analysis. Magellan uses dynamic formal techniques to generate
stimulus that proves or falsifies properties and maximizes state coverage on
signals in a goal set.

Glossary
Environment module. A section of a Magellan project that defines the

verification environment. The environment can include simulation options,
constraint files, additional port descriptions such as clock and reset signals,
and any other supporting files for the design under test. You can define any
number of Environment modules in a project, but only one is used during a
Magellan test run.
Fail signal. An output signal that indicates property failure when it is

asserted. May be found in RTL-based assertions or code generated by an
assertion compiler. See Property.
Formal model. The representation of your design, checkers, and

environment that Magellan’s formal engines process. The formal model is
generated by the Formal build.
Formal build. A process called by the Build server. The Formal build runs the
front-end of the synthesis compiler to create a gate-level model of the design.
Formal verification. A mathematically exhaustive analysis of the possible

behaviors of a design, input constraints, and a property to determine if the
property is always true given any legal input stimulus.
Functional coverage. The fraction of all possible behaviors that the design
can exhibit when exposed to stimulus that may be encountered in actual
usage. Complete functional coverage is defined as the exercise of all specified
behaviors that the design can exhibit when exposed to stimulus that may be
encountered in actual usage.
Goal set. A group of signals you want to target (as defined in a Coverage
module).
MG shell. The hybrid-verification shell (mgsh). This is the Magellan interface

where you enter commands and run scripts.
OpenVera Assertions (OVA). A temporal language that you can use to

describe event sequences and specify assertions based on these sequences.
Open Verification Library (OVL) A library of assertions or properties that

you can instantiate in your design without worrying about implementation
details for vendor tools.

Glossary
Project. The project is a container for all the definitions Magellan needs to
evaluate your design and run tests. Each Magellan invocation operates on
one project at a time.
Project file. A Tcl script of data commands specifying all the project
information.
Project module. A section of a Magellan project that defines the project. In

the Project module you give the project a name and declare any preprocessor
macros or compiler directives. There is only one Project module in a project.
Proof. A proof indicates that for any stimulus sequence of arbitrary length, the
property is always true. See also Bounded proof.
Property. A logical assertion about the behavior of the design. Properties are
typically fragments of the complete design specification. For example, “The
FIFO will never overflow” or “The bus will be granted within 30 clock cycles of
a request.”
Property checker. See Checker.
Property module. A section of a Magellan project that includes one or more

property checkers. You can define any number of Property modules in a
project.
Reachability engine. A process called by the Run server which tries to find
stimulus traces that reach new states of the target goal set or property.
Reference model. A piece of verification code that emulates the function of a

design block. Generally, a reference model implements the complete
functional specification of the block.
RTL model. The representation of your design, checkers, and environment

that Magellan’s simulation engines process. The RTL model is generated by
the Simulation build.
RTL HDL. Register-transfer level (RTL) hardware description language

(HDL). This is a method for modeling a circuit in a form compatible with logic
synthesis tools. HDLs support many levels of abstraction: gate-level,
register-transfer level, behavioral, and algorithmic.

Glossary
Run server. The Magellan process that searches for property proofs and
violations, and generates coverage stimulus. The Run server starts up
multiple processes that concurrently validate the design, including the
simulator, reachability engines, and unreachability engines.
Safety property. A property that specifies a subset of safe states for the
design and requires that the design never leave this subset of safe states. All
possible error traces of a safety property have a finite length.
Session module. A section of a Magellan project that defines a test run with
an environment and one or more coverage goals or property checkers. You
can define any number of Session modules in a project.
Simulation build. A process called by the Build server. The Simulation build
process runs the simulator.
Synthesis policy checker. A tool that evaluates the code in the design to
ensure that it conforms to synthesis rules. Policy checker tools provide an
early evaluation of the code without the expense of running the code through
the full synthesis process.
SystemVerilog Assertions (SVA). A temporal language that you can use to

describe event sequences and specify assertions based on these sequences.
Truth table. See Compressed truth table.
UDP. User-defined primitive (a Verilog feature).
Unbounded proof. See Proof.
Unreachability engine. A process called by the Run server which tries to

prove that a goal state cannot be reached or a property cannot be falsified.
Vera. A Synopsys behavioral language used to write testbenches.

Glossary

Index
Symbols _MgProject 120
! command 111 _MgSession 121
$display 159 _MgToggle 121, 125
$hdl_xmr 203
$isunknown 314 Numerics
$past 306 2X system clock 212
$rose 306 2xSystemClock.rpt 138
$stop 144
+captureState 76 A
+define 163 Accellera 340
+define option 177 building VHDL logical library 351
+incdir 336 Open Verification Library 348
+incdirs 163 see also OVL
+notimingcheck 172 action blocks 306
+systemverilogext+ext option 320 action commands 115
+verilog1995ext+ext option 321 add commands 113
+verilog2001ext+ext option 321 add_aep_source 376, 377
+vpdfile+filename 455 -signal 376, 377
+vpi 77 add_coverage_info 125, 384, 408
_MgAep 121, 125 add_design_info 121
_MgChecker 35, 88, 120, 123 -blackBoxes option 179
_MgCm 121, 125 -vhdlan option 168, 264
_MgConstraint 120, 124 -vlogan option 168, 264
_MgCover 120 add_env_block 164, 264, 271, 334, 335, 358
_MgDesign 120 -files option 334
_MgEnv 120, 123 -format option 334
_MgFsm 120, 125 -interface option 164
_MgOvl 124 add_env_connect 180, 271–273, 358
_MgOvlChecker 121 -connect option 180
_MgOvlConstraint 121 add_env_info

Index
-solveOrder 286 testing all coverage goals 375

add_env_inline 285 testing all property goals 375
add_env_port 164, 180, 181, 257 toggle coverage 147, 374
clock 217 using 368
constant 180, 253, 258 X assignments 370
-interface option 164 -allCovs 375
random 181, 259–260 -allProps 375
reset 181, 223, 224 -allSessions 127
using wildcards 210, 225, 253 always blocks 162
add_project_info 178 amd64 21
-msgFilters option 142 architectures, multiple VHDL 202
add_property_info 349, 350, 357 arithmetic overflow 371
-exclude option 360 -arithOverflow 371
-ovaPath option 363 arrays
pattern matching filters 364 two-dimensional 181
-scope option 363 arrays, port
-type option 322 constant 253
add_session_info 389 cross-module reference 272
AEP FSM coverage 421 ASIC libraries 174
specifying tests 397 ASSERT_ON compiler directive 319
AEP module 117, 475 assertions
generating checkers 369, 370, 371, 372, COI reporting 443
373, 374, 375, 395, 398, 399 why use them? 26
generating stimulus for violations 300 assertions, OpenVera
quick start 36 adding to the project 334–337
AEP properties as property checkers 335
arithmetic overflow 371 as property constraints 261
array boundaries 370 connecting to the design 334, 335, 364
condition coverage 147, 392 example 329
conflicting driver 373 using inline 337
floating buses 373 writing 329
FSM coverage 397 assertions, PSL
FSM state coverage 397 incompatible constructs 340
full-case 369 with Verilog 342
isolating specific 376 with VHDL 345
limiting the scope 376 wrapping for Magellan 341
line coverage 147, 392 assertions, see properties
multiply-driven buses 372 assertions, SystemVerilog
parallel-case 369 adding to the project 320
simultaneous set/reset 371 as property checkers 321, 335
summary reporting 431 assertion-style constraint quick start 52

Index
binding 318 -batch option 130

coding guidelines 313 -bias switch 285
combinational property quick start 41 biasing random inputs 283–285
connecting to the design 312 constraint solver ordering 286
GUI quick start 69 usage example 284
incompatible constructs 312, 324 with constraints 283
inline 319 bidirectional ports
instantiating 318 automatic constraint generation 197
property failure quick start 46 template for constraints 198
usage examples 318 bidirectional signals 197–198
using standard assertion library 319 bit port type 201
using standard assertion library with bit_vector port type 201
mixed-language 89 black box
wrapping for Magellan 313 controlling internal signals 180–181
writing 312 for specific instance 179
asserts, SystemVerilog 322 removing portions of design 178
assumes, SystemVerilog 322 reporting 181, 182
asynchronous latches 192 using with caution 178
controlling 192 Black Box and Forced Signals Log 182
asynchronous loops 193–196 reading report 183
see also combinational loops -blackbox switch 181
asynchronous resets -blackBoxes option 179
handling 317 block 475
automated blocking assignments 465, 466
coverage flow 395 blocking commands 115–116
Automatic Extraction Processor, see AEP -blockmode switch 116
module boolean 201
automatic range extraction bounded proof run mode 146
for vectors and memories 256 bounded proofs 302, 475
automatic stability constraints 192 counting cycle depths 434
automaton 307 reporting 434
degenerate 307 see also proofs
negated 307 boundedProof run option 146
-avoidDeadends -boundsCheck 370
basic option 294 -break options 156
full option 294 -break switch 144
none option 295 breakpoint 144, 475
breakpoint options 156
B build
backslash substitutions partial design 186
with Tcl 111 build script

Index
VCS 76 internal generated master design

Build server 135–136, 475 clock 214
build.log 137 RTL clock generator examples 218
build.rpt 137 specification examples 211
build_session 115, 134, 377 specifying multiple 208
building a session 134 system clock generation 215
remotely 131–132 using RTL clock generators 216
built-in commands 113 VHDL reset sequence 229
buses clock, system 212–214
constant 253 clocks
cross-module reference 272 specifying with wildcards 210
-cm cond 397
C -cm fsm 397
check_licenses 23 -cm line 397
-checker switch 360 -cm_hier 377, 398
checkers 300, 475 codeCoverage run mode 147
adding to the project 356, 369, 370, 371, coi___propName_nonvacuity_n.txt 139
372, 373, 374, 375, 395, 398, 399 combinational constraints 264, 276
and constraint model 260, 301–302 combinational feedback loops 193–196, 476
as coverage goals 300, 383 command line arguments
as property constraints 261 -batch 130
automatically generating 368 -eval 130
connecting to the design 358 -help 109
debugging 365 -port 131
excluding 360 -serverModeOnly 131
instantiated vs. external 355 commands
writing 354 action 115
clock cycle 208 blocking 115–116
clock divider 217 data 115
clock generators entering interactively 118, 135, 143
30 percent duty cycle 219 help on 114, 115
in constraint model 218 log file 137
RTL examples 218 naming conventions 113
two clocks same frequency 218 non-blocking 115–116
-clock option 217 organization 113
clock period report_session 440, 442
preventing mismatches 470 -compareAlways switch 144, 458, 461, 463
clock signal -compareFullDesign switch 461
configuring 208 -compareReplay switch 144, 458, 461, 462
deriving multiple clocks 216 compile.log 138
compiler directives

Index
ASSERT_ON 319 deriving multiple clocks 216

MEM_RESET 73 generator-style constraints 260
SNPS_OVA_FORMAL 332 over-constraining inputs 261, 301
sv_pragma 312 property constraints 261
SVA_CHECKER_FORMAL 313, 320, 340 specifying solve order 286
SVA_CHECKER_NO_MESSAGE 91, stability 192
320 under-constraining inputs 262, 301
completeness, measuring 380–381, 382 see also constraints, writing
compressed truth table 476 constraint solver
-cond 395, 398 ordering examples 286
condition coverage 397 specifying solve order 286
cone of influence -constraint switch 360
assertions 443 constraints
example report 441 excluding 360
generating reports 440 mismatches 274
primary input signals 439 stability 192
registers 439 constraints, writing
using reports 439 accessing internal design
-cone option 440, 443 signals 272–273
configurations, VHDL 202 driving internal design signals 273
-conflDriver 373 generator-style 263–264
conflicting drivers 373 handshakes 279
conflicts legal value selector 278
responding to 463 packet generator 280–281
-constant option 224, 253 random but constant inputs 275
constant signals 253 simple combinational constraints 264, 276
constants see also constraint model
setting with wildcards 253 cookbook
constraint examples AEP tests project file 38
combinational constraint 276 FSM coverage project file 66
handshake 279 RTL state machine coverage 104
legal value selector 278 SVA combinational property project file 43
packet generator 280 SVA constraint project file 55, 60
random but constant inputs 275 SVA cover project file 60
constraint model 476 SVA sequential property project file 48
adding to the project 264 -count 160
and high-coverage stimulus 260, 381 -covDUT 400, 414
and property checkers 260, 301–302 cover
connecting to the design 265, 271 OVA construct 408
constraining inputs 260–281 SVA construct 408
debugging 274 coverage

Index
approaches 380 -covReuse option 414

automated 395 -covSim 396
condition 397 covSim.log 395
convergence 380 -covSimTime 395
debug sim/synth mismatches quick -covTest 400
start 64 cross-module references 263, 271
FSM quick start 64 in checker instantiation 356
FSM state 397 in procedural code 187
inconsistent results 411 with black boxes 180
intentional unreachables 401 with OVAs 271
line 397 custom reporting 432
methodologies 392
overview 380 D
project file example 66 data commands 115, 118
real success 412 datasize 21
reusing data 413 dbgSim.csh script 56, 99, 138, 139
see also unified coverage 404, 410 -deadend 297
types 380 dead-end avoidance
unified 404, 410 constraints and design 294
coverage flow constraints only 293
automated 395 dead-end states 274, 288–295
coverage goals 380–381, 476 automatic avoidance 293, 294
and constraint model 260, 381 avoidance reporting 295
condition 392 causes 288
generating stimulus 389 complete constraints 291
line 392 debugging 297, 462
multiple state machines 385–386 identifying 296
selecting 383 incomplete constraints 291
why use them? 27 linting 293
see also goal set runtime debug 293
Coverage module 118, 476 simulation/synthesis mismatches 291
adding to a Session module 140, 389 what are they? 288
defining a goal set 384–388 deadlock
generating stimulus 389 detecting 389
-coverage option report example 390
add_session_info 389 -deadlock switch 390
covers, SystemVerilog debugging
quick start 58, 101 constraint mismatches 274
-covInput 400 constraint models 274
-covOutput 414 controlling dumping 447
-covReuse 413 dead-end states 274

Index
during session run 445 degenerate automaton 307

MDA 447 design
mismatches 465 connecting SystemVerilog Assertions 312
previously run session 450 connecting to a checker 358
property checkers 365 connecting to an OpenVera
property violations 445, 455 Assertion 334, 335, 364
reset sequences 251 connecting to the constraint model 265,
saving test stimulus 451 271
single falsified property 453 location 136
with Debussy 445, 448 Design Compiler 200
with DVE 51, 445, 448 design files
with Magellan GUI 445 listing 163–168
with mgui 445 Design module 117, 476
with Verdi 445, 448 describing the design 163–168
Debussy 141 design.exe.cm 404
-debussy switch 451 design.map file 247
DEBUSSY_HOME environment variable 451 design_driver.v 138
default values, overriding 271 design_driver.vhd 138
-defaultLen 210 DesignWare Foundation Library components
defaults project file example 200
using smart 120 software requirements 200
-defaultVal 225 using with Magellan 200
+define 177 detailed reporting 421
define commands 113 AEP coverage goals 427
define_aep 369, 370, 371, 372, 373, 374, AEP property example 424
375, 377, 395, 398, 399 custom 432
-cond 397 custom report example 433
-fsmState 397 filtering 429
-line 397 filtering functional coverage results 431
define_coverage 384, 390 filtering on checkers or constraints 430
define_design 22, 164, 186, 349, 350 filtering on goal state 429
-vcs option 169 filtering on types of lines or conditions 430
define_env 208, 408 non-vacuous proof example 435
define_property 334, 350, 351, 357, 363, 364 RTL coverage goals 428
-constraint switch 360 SVA property 426
define_property_info vacuous proof example 435
-checker switch 360 witness trace example 438
define_session 144, 172 diagnose.out 139, 471, 473
-dumpMda 447 example report 472
-witness 437 diagnosis report 471, 473
defineMemoryBlockHV 248 directives

Index
ifdef 176–178, 356 adding OpenVera Assertions 266, 268,

synopsys translate_off 173–174, 184, 356 331, 334, 335, 364
directory structure 136 biasing random inputs 285
disable iff 291, 317, 436 configuring the clock 208
Discovery Visualization Environment configuring the reset sequence 220–251
(DVE) 51, 451 describing for a first build 171–172
disk space required 18 describing the environment 206, 207
distributing Magellan engines specifying constraint solver order 286
server farm 154 environment variables 19, 21–22
don’t cares environment, understanding 206
preserving 185 error messages
downloading software 17–18 constraints have no solution 295
driver template filtering 159
bidirectional ports 198 logic compare failure 462, 463
drivers logic compare X transition conflicts error
conflicting 373 message 464
non-tristate 372 reached and unreachable 463
tristate 372 reporting 159
dump 456 specified both reached and
dump.cmd file 456 unreachable 463
dumping 447 unknowns on goal signals 463
-dumpMda 447 unlinked cells found 175
DVE 50, 72, 96, 141, 451 see also messages
-dve switch 50 error messages log 137
-dwRoot option 200 escaped identifiers
dynamic formal stimulus generation 381 with Verilog 111
dynamic formal verification 476 escaped names
in reset file 231
E -eval option 130
-easy 109 eventuality properties 304
engines -exclude option 360
distributing 154 exit 131
Reachability 143, 478 exit_server 131
Unreachability 143, 479 exploring the design
enumeration 202 remotely 131–132
enumeration types 202, 386–388 export_session_coverage
Environment module 117, 477 command 414
adding constant inputs 253 example 415
adding external checkers 266, 268, 358
adding generator-style constraints 264 F
fail signal 477

Index
fairness properties 304 transition coverage 386

fcovReport 411, 412 -floatingBus 372
feedback loops, combinational 193–196, 476 -force switch 134
files forced signals report 182
2xSystemClock.rpt 138 forcedSignals.log file 138, 182, 198, 200
build.log 137 forceSignals.log file 186
build.rpt 137 formal analysis 381
coi___propName_nonvacuity_n.txt 139 Formal build 135–136, 178, 477
compile.log 138 formal model 458, 469, 477
covSim.log 395 comparing with RTL model 459–460
dbgSim.csh 56, 99, 139 formal only run mode 146
design.map 247 formal proofs
design_driver.v 138 defined 26
design_driver.vhd 138 formal traces
diagnose.out 139, 471, 473 generating VCD files 473
dump.cmd 456 formal verification 477
forcedSignals.log 138, 182, 198 formalOnly run option 146
goals.log 137, 462 -formalVcd 473
.mgsh_rc 112 FSDB 141, 447, 448
latchRemodelWarning.log 138, 190 -fsdb 141
listing sequentials 230 -fsmState 395, 398
loops.rpt 138, 194, 195–196 ftp.synopsys.com 17
meminit.inc 248 -full64 76
meminit.vh 248 -fullCase 369
mg_dump.tcl 447 function commands 113
mgCaptureReset.pl 76 functional coverage 477
.mgsh_rc 112
mgsh_command.log 137 G
mgsh_messages.log 137 gcc 2.95.2 22
ResetFile 223 gcc 3.x problem 22
ResetMem 249 generated files
ResetState.dat 78, 249, 250 user directory 137
resetState.diff 139, 251 generating stimulus 300, 381–382, 389
synopsys_sim.setup 22 generator-style constraints 260
test.csh 451 generics 203, 271
TraceFile.simTime.vcd file 473 overriding 170
unobservedInputs.log 138, 449 simulation_cycle 229
VCD 185 get commands 113
vcdplus.vpd 455 goal set 384–388, 477
xFile.init 137, 222, 231, 250 goal statuses 421
finite state machine goals, coverage 380–381

Index
and constraint model 260, 381 HVB-413 information message 230

generating stimulus 389 HVB-509 error message 398
multiple state machines 385–386 HVB-944 information message 374
selecting 383 HVNL-405 information message 194
goals.log file 137, 462 HVOR-036 warning message 252
-grid 154 HVSI-041 warning message 195
-gridOpts 154 HVSI-043 warning message 462
GUI 418 HVSI-045 error message 462, 463
activity list 108 HVSI-053 warning message 274
activity view 108 HVSI-061 warning message 296
console view 108 HVSI-403 information message 465
debugging with 445 HVUT-019 error message 463
entering MG shell commands 108 HVUT-076 error message 463
invoking 108 HVUT-077 error message 464
MG shell command help 108
mixed-language quick-start 89 I
quick start 69 ID
guideposts 145 number 453
defining 150 -ID switch 24
reporting 152 identifying property checkers 261
running 151 ifdef compiler directive 176–178, 356
using 150 ignore-conf 463
ignore-miss 462
H ignore-x 464
handshake constraints 279 immediate assertions 306
HDL, RTL 478 incompatible OVAs
hdl_xmr excluding 332
VHDL procedure 203 information message log 137
hdl_xmr.tab 203 inline OVA Assertion
-help switch 109 example 337
help, viewing 114, 115 using 337
history 111 input signals
host name 130–131 biasing 283–285
HVB-004 error message 175 clock 208, 216
HVB-114 error message 372 constant 253
HVB-130 warning message 162, 273 constraining 260–281
HVB-175 error message 214 generating 300, 381–382, 389
HVB-176 error message 216 legal 260
HVB-188 information message 212 primary driving asynchronous latches 192
HVB-222 warning message 192 random 212–214, 253–260
HVB-233 warning message 197 replaying 451

Index
saving in a file 454 VT_SVDesign 392

setting during Reset phase 225 VT_UnifiedCoverage 392
undriven nets 162 licensing 16, 20, 23
inputCov option 431 limits
installation, testing 23 datasize 21
installing Magellan 18–19 stacksize 21
integer port type 201 -line 395, 398
intentional unreachables 401 line and condition coverage
-interface listing goals 421
with add_env_block 164 methodologies 392
with add_env_port 164 reporting 406
interfaces specifying tests 397
SystemVerilog 164 summary reporting 434
internal signals with codeCoverage run mode 147
controlling 180–181 with input database 399
forcing 257 line coverage 397
setting during reset phase 225 lineIntent 403
setting to constants 257 Linux 21
RHEL 16
K running 64-bit 142
key, license 20 SUSE 16
linux 21
L list_msgs 159
language, project 163, 167 list_session_results 40, 93, 377, 422, 453
large delays -fsm 425
avoiding in SVAs 316 -long 148
latches -summary switch 431
asynchronous 192 -TCL 432
remodeling 190 livelock
safe 190 detecting 389
unsafe 190 report example 390
latchRemodelWarning.log 138 -livelock option 390
LD_LIBRARY_PATH environment lmreread 20
variable 21, 24, 249 lmstat 20
Leda 27, 176 load sharing facility 154
synthesis policy checker 175 using 154
legal value selector constraints 278 log files
license listing sequentials 230
wait for 20, 23, 134 logic compare failure error message 462, 463
license key 20 logic X assignments
licenses intentional 401

Index
-long 40, 44, 49, 422 memory resources, managing 142

-lookahead option 294 message log 137
loops, combinational feedback 193–196, 476 messages
loops.rpt file 138, 194, 195–196 asynchronous input of latch warning 192
LSF 154 asynchronous loops found 194
using 154 constraints have no solution 295
dead-end state error 293
M dead-end state warning 293, 296
-macroDefs option 178 filtering 142, 159
Magellan logic compare failure error 462, 463
checking environment 24 mismatch 465
checking version 24 primary input node added for undriven net
learning to use 29 warning 162, 273
project files 32, 84 reached and unreachable error 463
quick start 32, 84 replay miss warning 462
tutorials 29 reporting 159
what is it? 26 reset state miscompare warning 252
when to use 27 specified both reached and unreachable
Magellan GUI error 463
debugging with 445 suppressing 142
invoking 108 unable to drive value to unbound port
make utility 22 warning 195
man pages unknowns on goal signals error 463
Presto 115 unlinked cells error 175
viewing 114 X transition conflicts error 464
man pages, viewing 115 see also error messages
manuals see also warning messages
VCS MX Simulation Coding and Modeling MG shell 477
Style Guide 203 command help 114, 115
VCS MX/VCS MXi User Guide 323 creating a project 118
VCS MX/VCS MXi User Guide 323 entering commands interactively 135, 143
master clock 217 remote access 130–131
-maxGoals 398 starting 35, 36, 41, 46, 52, 58, 64, 69, 87,
-maxMemory option 142 109
-maxTime option 144, 180 viewing command line options 109
MDAs 255, 256 mg_common directory 136
debugging 447 mg_force 240
MEM_RESET mg_get 243
compiler directive 73 MG_HOME environment variable 19, 21
meminit.inc file 248 mg_refclock 239
meminit.vh file 248 mg_release 242

Index
mg_run 237 ModelSim 22, 454

mg_session directory 137 MODELTECH environment variable 22, 454
mg_show 244 -modLineIntent 401
mg_time 245 module commands 113
mgCaptureReset.pl script 76, 77 -msgFilters option 142
MgSession 35, 88 -msgTag 159
mgsh 477 -mti switch 22, 454
command help 114, 115 MTI VHDL simulator 22, 454
creating a project 118 multibit ports
-doc switch 109 constant 253
entering commands interactively 135, 143 cross-module reference 272
-ID switch 24 -multiDriver 372
remote access 130–131
starting 35, 36, 41, 46, 52, 58, 64, 69, 87, N
109 natural port type 201
viewing command line options 109 negated automaton 307
-waitlic switch 20, 23, 134 nets
mgsh_commands.log 137 bidirectional 197–198
mgsh_messages.log 137, 159, 462, 463, 464 driven by multiple sources 162, 197
.mgsh_rc file 112 undriven 162
mgui 418, 445, 449 -noCompareReset switch 252
activity list 108 -noCompareX switch 461
activity view 108 -nocompress switch 451
console view 108 -noDebug switch 141
debugging with 445 non-blocking commands 115–116
-easy 109 non-state holding combinational
easy mode 109 loops 193–195, 476
entering MG shell commands 108 non-synthesizable code
MG shell command help 108 ASIC libraries 174
quick start 69 finding 173–175
-mhdl switch 169 managing 176
mismatches modifying 176–180
constraints 274 treating as black box 178
mismatches, see simulation/synthesis mis- UDPs 201
matches VITAL components 175
mixed-language designs non-synthesizable operators 313
specifying files 168 non-tristate drivers 372
Model Technology 22, 454 -noServerMode 110
models +notimingcheck 172
formal 458, 469, 477 -noVacuityCheck 436
RTL 458, 469, 478

Index
O with design parameters 338

-oneDebugFile 141 with write_session_test 303
Open Verification Library (OVL) OVA covers 408
ACCELLERA logical library 351 adding to project file 408
defined 477 testing automatically 408
specifying files for SVA 349 OVA, see OpenVera Assertions
specifying files for Verilog 350 -ova_exp_param switch 339
usage overview 348 -ova_lint_magellan 329, 332
using assertions 348, 351 -ovaPath option 364, 408
using with SVA 348 pattern matching filters 364
using with Verilog 350 over-constraining inputs 261, 301
using with VHDL 351 overriding
OpenVera Assertions 477 default values 271
adding inline 337 generics 170
adding to the project 334–337 parameters 170
as property checkers 335 overriding default values 271
as property constraints 261 OVL 443
checking all instances 363 in SVA 348
checking multiple instances 364 in Verilog 350
checking single instance 363 in VHDL 351
connecting to the design 331, 334, 335, version 1.8 350, 351
364 version 2.1 348
example 329 OVL assertions 348, 351
excluding incompatible assertions 332 activating multiple as checkers 353
past operator caution 332 activating multiple as constraints 353
writing 329 selecting multiple 353
OpenVera Language Reference Manual using wildcards 353
Assertions 338 -ovl switch 350, 351
operators OVL_ASSERT_ON 349
past 314 OVL_COVER_ON 349
options, setting project-wide 163, 167, 178 OVL_COVERGROUP_OFF 349
OVA OVL_GATING_OFF 349
and simulation model 303 OVL_SVA 349
bind example 334 OVL_SYNTHESIS 349
bind syntax reference 333 OVL_XCHECK_OFF 349
handling during reset 303 -ovlScope 124
multiple template instances 336
project file for Verilog 334 P
testing covers 408 packet generator constraints 280–281
using include files 336 parallel engines
using standard unit library 333 running 149

Index
parallel runs procedures 113

random simulation 397 process blocks 162
-parallelCase 369 processes
parameters Build server 135–136, 475
overriding 170 Run server 143, 479
Verilog 271 project 116, 478
-parameters option 271 AEP module 117
add_env_block 271 building 134
set_design_info 170 Coverage module 118, 384–388
parameters, Verilog 271 creating for the first build 171–172
partial designs Design module 117, 163–168
building 186 Environment module 117, 206, 207
-partialDesign 186 project file 118–119
past operator 314 Project module 117, 178
with OpenVera Assertions 332 Property module 117, 334–337, 356
PATH environment variable 21 running 140
performance running in 64-bit 142
multiple state machine goals 385–386 Session module 118, 389
simulation 172 setting options 163, 167
PLI 76 project directory 136
accessing reset functions 249 project file 478
calls 249 adding constraints 264
extracting reset file 247 adding OpenVera Assertions 266, 268,
reset state extraction quick start 73 334–337
policy checker, synthesis 175, 479 adding property checkers 266, 268, 356
port number 130–131 adding SystemVerilog assertions 320
-port option 131 building 134
portable test.csh 452 creating 118
ports creating for the first build 171–172
bidirectional 197–198 defining goal sets 384–388
in bias file 285 describing the design 163–168
multibit constant 253 describing the environment 207–264,
supported VHDL types 201 283–285
undriven nets 162 including macro definitions 178
Verilog reset sequence 228 loading 109, 119
VHDL reset sequence 229 location 136
-PP compile-time option 455 running 140
Presto setting project-wide options 163, 167
man pages 115 Project module 117, 478
primary input signals macro definitions 178
in cone of influence 439 setting project-wide options 163, 167

Index
proofs 300–302, 478 vunits with Verilog 344

defined 26 vunits with VHDL 347
see also bounded proofs with Verilog 342
unbounded 479 with VHDL 345
properties 300, 478 -psl 91, 342, 346
bounded proofs 302, 475 PSL assertions
choosing 304, 368 wrapping for Magellan 341
liveness 313 -pslfile 342, 346
measurable 304
proofs 300–302, 478 Q
simplifying 439 quick start
types 304 AEP tests 38
violations 300, 445, 455 approach 33, 85
why use them? 26 assertion failure and debug 46
property checkers 300, 475, 478 automatically extracted properties 36
adding to the project 356, 369, 370, 371, GUI 69
372, 373, 374, 375, 395, 398, 399 Magellan 32, 84
and constraint model 260, 301–302 mixed-language 89
as coverage goals 300, 383 mixed-language overview 84
as property constraints 261 MX smart defaults 86
automatically generating 368 PLI reset state extraction 73
connecting to the design 358 sample design 33, 85
debugging 365 SVA assertion-style constraint 52
instantiated vs. external 355 SVA combinational property proof 41
writing 354 SVA functional coverage goal 58
property constraints 261 SVA sequential property failure 46
Property module 117, 478 Verilog smart defaults 34
adding checkers 266, 268, 356
adding OpenVera Assertions 334–337 R
adding SystemVerilog Assertions 321 race conditions 227, 465
adding to a Session module 140 zero-delay latches 465
generating stimulus for violations 300 random but constant constraints 275
property report 434 Random Generation phase 253
property trace 434 random inputs 212–214, 253–260
PSL 435, 443 biasing 283–285
current support 345 constraining 260–281
incompatible constructs 340 random simulation 381
inline with Verilog 342 parallel runs 397
inline with VHDL 345 random simulation only run mode 147
usage notes 341 -random switch 259–260
using 340 randomization

Index
x 185 diagnose.out example 472

randomSim run option 147 effort level 148
Reachability engine 143, 478 forceSignals.log 186
reached and unreachable error message 463 latch remodel warning 190
reached states 382, 475 mismatch 471, 473
read_project 119, 134 property 434
real success 412 solver engine 148
records 202 summary 431
Red Hat Linux 21 trace length 422
-refClock 210 vacuous proofs 435
reference model 478 requirements, system 16–17
registers reset
in cone of influence 439 safe design signal 223
setting all 225 setting design signals 224
setting uninitialized 250–251 Tcl-based 223
remote processes 130–132 understanding 222
remove commands 113 reset file
repeatable reset sequence 251–252 example 250
replay misses 462–463 extracting with PLI/VHPI routines 247
asynchronous latches 192 syntax 231
combinational feedback loops 195 reset from file 230
responding to 462 -reset option 223, 224, 225
warning message 462 reset sequence
replaying stimulus 451 adding to the default 226
report_session 144, 390, 470 creating repeatable 251–252
-blackbox 181 debugging 251
-stats 148 default 223, 226
reporting extracting with PLI/VHPI routines 247
effort level 148 PLI extraction quick start 73
solver engine 148 replacing the default 224, 226
trace length 422 reset file example 250
witness trace 437 reset from file 230
reporting results 422 setting all registers to a value 225
reports setting design signals 224
2XSystemClock.rpt 213 specifying length 209
2XSystemClock.rpt examples 213 understanding 221, 222
AEP FSM state 425 Verilog 227–228
assertion COI 443 VHDL 228–229
Black Box and Forced Signals Log 182 Reset State 221
cone of influence 439 turning off compare 252
detailed 421 reset state

Index
PLI extraction quick start 73 -mode options 145, 146, 151

ResetFile 223 randomSim 147
ResetMem files 249 searchOnly 145, 151
resets shortTrace 146
specifying with wildcards 225 run_vcs_mg_reset.csh 77
ResetState.dat file 78, 249, 250 run_vcs_mg_reset_64.csh 77
resetState.diff 139, 251 running
resources, managing memory 142 a session 140
-rsimSeed 394 remotely 131–132
RTL HDL 478 -runOpts option 397
RTL model 458, 469, 478
black box output signals 181 S
comparing with formal model 459–460 -safeReset option 223
signal forces 181 safety properties 304, 479
run control save_project 118
breakpoint options 156 SCC, see strongly connected components
default behavior 144 SCL, see Synopsys Common Licensing
tuning behavior 145 -scope option 349, 350, 364, 408
using run modes 145 pattern matching filters 364
run modes -scoSetupFile option 22
bounded proof 146 -scriptFile 223
code coverage 147 scripts
formal only 146 mgCaptureReset.pl 76, 77
parallel engines 149 simulation 139
random simulation only 147 stimulus 445, 454
search engines only 145 Tcl 32, 84, 128–130
short trace 146 search
using 145 with guideposts 150
Run server 143, 479 searchOnly 152
run_session 115, 141, 144, 145, 152, 155, searchOnly option 145, 151
252 selector constraints 278
boundedProof 146 sensitivity lists, incomplete 467–468
-break examples 156 server farm 154
-break options 156 distributing Magellan engines 154
codeCoverage 147 -serverModeOnly 109, 131
formalOnly 146 servers
-grid 155 Build 135–136, 475
-gridOpts 155 Run 143, 479
man pages 158 -session 126
mismatches 144, 458, 461 Session module 118, 479
-mode examples 145, 151 adding a Coverage module 140, 389

Index
adding a Property module 140 -setReset 371

building 134 SGE 154
running 140 using 154
stopping 144 shortTrace option 146
session results show_coi 443, 444
accessing in Tcl scripts 432 signals
sessionCov option 431 specifying with wildcards 253
set commands 113 signed port type 201
set_aep_config 397 sim directory 137
-covDUT 399 simple combinational constraints 264, 276
-covInput 399 simulation
-extractOpts 397 performance 172
set_aep_info 125, 398 scripts 139
-maxGoals 398 Simulation build 135–136, 178, 479
set_debugger_override 446 simulation/synthesis mismatches 458
set_design_info 163, 164, 188, 200, 349, 350 asynchronous latches 192
-sverilog switch 320 combinational feedback loops 195
-vcs option 163, 336, 339 compare cycle 459–460
-y option 319 debugging 465
set_env_info 192 detecting 458–459, 461
set_env_reset 224, 230, 250, 374 diagnose.out report 472
-defaultVal 225 diagnosing 465–468
-file 78, 231 error messages 462, 463, 464
-refClock 210 incorrect clock period 470
-safeReset 223 messages 465
-scriptFile option 230 reports 471, 473
-taskFile option 230 synopsys translate_off directive 174
-taskFormat option 224 warning messages 252, 462
-taskName option 224 X values 469, 470
set_option 132 zero-delay latches 467
set_project_info 154 simulation_cycle generic 229
-grid 154 simulator
gridOpts 154 default 163
set_server 131, 132 setting 167
set_session_info specifying options 170
-grid 155 see also VCS-MX
-gridOpts 155 see also VCS
-rsimSeed 394 simultaneous set/reset 371
set_session_info command 294, 295, 413 simv.cm 399
-covDUT option 413 smart defaults
-covInput option 413 command style 122

Index
example project 121 states, classified 382, 475

mixing with custom modules 128 status 113, 130, 144
module names 120 constant 421
multiple sessions 126 covered 421
MX quick start 86 falsified 421
running tests 125 ignored 421
using 120 proven 421
Verilog quick start 34 reached 421
with AEP properties 125 toggled 421
with OVL properties 124 uncoverable 421
with RTL FSM coverage 125 unknown 421
with SVA/PSL properties 123 unreachable 421
SNPSLMD_LICENSE_FILE environment std_logic 201
variable 21 std_logic_vector 201
Solaris std_ulogic 201
running 64-bit 142 std_ulogic_vector 201
-solveOrder 286 stimulus
solver engine biasing 283–285
individual reporting 148 clock signal 208, 216
reporting and reuse 148 constant signals 253
summary reporting 148 constraining 260–281
SolvNet 400 generating 300, 381–382, 389
source 119, 129 legal 260
source code coverage 380 random 212–214, 253–260
sparc64 21 replaying 451
sparcOS5 21 saving in a file 454
specified both reached and unreachable error undriven nets 162
message 463 stimulus files
-srcDir 452 location 137
-stability 192 replaying 451
stability constraints 192 saving 454
automatic 192 $stop 144
stacksize 21 stopping a session 144
state coverage 381 strongly connected components 195–196
state holding combinational loops 194–195 -summary 431
state machines summary reporting 431
goal sets 385–386 AEP example 431
state path coverage 381 Sun grid engine
state transition coverage 386 using 154
states SUSE 16
dead-end 274, 288–295 suse32 21

Index
suse64 21 asserts 322

sv_pragma 312 assumes 322
SVA 435, 443, 479 cover 58
action blocks 306 data types 164, 187
bind with VHDL 327 design constructs 163
immediate assertions 306 interfaces 256
inline with VHDL 324 quick start 58
system tasks 306 structures 256
SVA asserts 322 system tasks 306
SVA assumes 322 using interfaces 164
SVA covers 408 SystemVerilog assertions 479
adding to project file 408 action blocks 306
testing 408 adding to project file 320
testing automatically 408 assertion-style constraint quick start 52
SVA, see SystemVerilog Assertions 305 bind with Verilog 318
-sva_bind 90, 327 bind with VHDL 327
SVA_CHECKER_FORMAL compiler coding guidelines 313
directive 313, 320, 340 combinational property quick start 41
SVA_CHECKER_NO_MESSAGE 91, 320 connecting to designs 312
-svaCompOpts 341 constraint examples 275, 278, 280, 282
-svaIsUnk0 314 disable iff 436
-sverilog 91, 163, 320, 321, 349 GUI quick start 69
Synopsys Common Licensing 16 how to write 312
SYNOPSYS environment variable 21, 200 implication operators 435
Synopsys Installer 16 inline with Verilog 319
synopsys translate_off directive 173–174, inline with VHDL 324, 326
184, 356 instantiating 318
SYNOPSYS_SIM environment variable 21 local variable limitations 306
synopsys_sim.setup file 22 property failure quick start 46
synthesis specifying for VCS parsing 320
partial designs 186 usage examples 318
synthesis policy checker 175, 479 using standard library 319
Leda 175 with VHDL 323
-sysReset switch 226 wrapping for Magellan 313
system clock 212–214
2X 212 T
reports 212 -tag 160
system clock evenly divisible by 2 215 tar 19
system requirements 16–17 Tcl
SystemVerilog 163, 341 .mgsh_rc file 112
3.1a LRM 286, 287 backslash substitutions 111

Index
controlling dumping 447 example 420

language constructs 110 transition coverage
loading variables and procedures 112 FSM 386
procedures 113 tristate
project file 118–119 constraining nets 197
reporting scripts 432 drivers 372
scripts 32, 84, 128–130 output bus example 188
sourcing design files 91 truth table 479
Tcl-based reset commands truth table, compressed 476
mg_force 240 tutorials
mg_get 243 Magellan 29
mg_refclock 239 two-dimensional array 181
mg_release 242 types, VHDL user-defined 202
mg_run 237
mg_show 244 U
mg_time 245 UCLI 448
telnet 130–131 UDPs 201, 479
template, driver X values 470
bidirectional ports 198 unbounded proofs 479
test directory 137, 451, 454 -uncovered option 442
test.csh 102, 451, 452 under-constraining inputs 262, 301
-compOpts option 452 undriven nets 162
-debugOpts option 452 unified coverage
-runOpts option 452 condition coverage user flow 404
-srcDir option 452 conflicting results 411
-vpd switch 456 functional coverage user flow 404, 410
test.csh portability 452 line coverage user flow 404
testing the installation 23 metrics 404, 410
tests output databases 414
moving to another location 452 reached database file 414
-timeUnits option 208 running with Magellan 413
-toggle 374 saving regressions 415
Tool Command Language, see Tcl unreachable database file 414
-topModule option 164, 349, 350 using Discovery platform 404, 410
trace Unified Report Generator 406
property 434 Uniform Report Generator User Guide 394,
witness 437 406
trace length reporting 422 uninitialized registers, setting 250–251
TraceFile.simTime.vcd file 139, 473 unknowns on goal signals
transcripts error message 463
automatically generated 419 responding to 463

Index
unobservedInputs.log 138 -ova_lint_magellan switch 329, 332

Unreachability engine 143, 479 -PP compile-time option 455
unreachable coverage states scripts 139
debugging 439 setting for project 163
unreachable states 382, 475 $stop 144
unsigned port type 201 -y option 200
URG 396 VCS MX 16, 248
-urg 396 creating VPD files 455
urg 406 setting for project 167
user directory 137 setting up the environment 22
generated file 137 VCS MX Simulation Coding and Modeling
user-defined primitive 201, 479 Style Guide 203
X values 470 VCS MX User Guide 169
user-defined types, VHDL 202 VCS MX/VCS MXi User Guide 323
-vcs option 163, 164, 350
V VCS/VCSi Release Notes 312
vacuity reporting VCS/VCSi User Guide 312, 411, 447
turning off 436 VCS_CC environment variable 22
vacuous proofs VCS_HOME environment variable 21
reporting 435 vectors and memories
-value option 225 automatic range extraction 256
variable substitution 164, 350 Vera 16, 479
variables, environment 19, 21–22 bias description file 284–285
VCD files 185 VERA_HOME environment variable 21
generating for formal traces 473 Verdi 141
vcdplus.vpd 455 -verdi switch 451
VCS 16, 397 VERDI_HOME environment variable 451
+define option 163 verification
+incdirs option 163 dynamic formal 476
+systemverilogext+ext option 320 evaluating completeness 439
+verilog1995ext+ext option 321 formal 477
+verilog2001ext+ext option 321 Verilog
build script 76 always blocks 162
command-line support 163 creating VPD files 455
creating VPD files 455 escaped identifiers 111
+define 177 parameters 271
forces 257 PLI memory reset extraction 248
incompatible options 164 PLI reset extraction 247
-ova_api option 335 reset sequence 226, 227–228
-ova_file option 335 setting language for project 163
-ova_inline option 335 specifying design files 163

Index
using cross-module references 187 -vpd 96, 141, 456

Verilog-top VPD file 455
specifying designs 169 creating 96
VHDL +vpdfile+filename 455
architectures 202 VT_SVDesign 392
bind SVA 326 VT_UnifiedCoverage 392
configurations 202
creating VPD files 455 W
enumerated types 256 -waitlic 20, 23, 134
enumeration types 202, 386–388 warning message log 137
generics 203, 229, 271 warning messages
inline PSL 345 asynchronous input of latch 192
inline SVA 326 BAD value 292
process blocks 162 dead-end state 293, 296
records 202, 256 primary input node added for undriven
referencing the clock period 229 net 162, 273
reset sequence 226, 228–229 replay miss 462
setting language for project 167 reset state miscompare 252
specifying design files 167 Unable to drive value to unbound port 195
specifying time units 172 see also messages
supported port types 201 -waveform option 209, 216
user-defined types 202, 256 waveform readability 449
using with SVAs 323 wide ports
with inline PSL 345 constant 253
with PSL vunits 347 cross-module reference 272
-vhdlan option 167, 169 wildcards 408
VHDL-top setting signals to constants 253
specifying designs 170 specifying clocks 210
VHPI specifying reset 225
accessing reset functions 249 specifying signals 253
extracting reset file 247 with add_env_port 210, 225, 253
memory reset extraction 248 with SVA/OVA 408
reset extraction 247 -witness switch
-vhpi option define_session 437
registering entry point function 248 witness trace
view_session_results 297, 449, 450, 453, enabling 437
462, 464, 465 report examples 437
-viewFsdb 449 reporting 437
violations, property 300, 445, 455 working directory 136
VITAL components 175 write_session_test 451
VPD 141, 447, 448 mismatch 465

Index
property 454
regressions 415
-urg 406
-urgSes 406
X
x randomization 185
X values 250–251, 469, 470
-xAssign 370
xFile.init file 137, 222, 231, 250, 374
-xinfo 470
XMR 263, 271
in checker instantiation 356
in procedural code 187
with SystemVerilog 187
-xRandom 185

Index

Magellan Ug PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Magellan Ug PDF

Uploaded by

Copyright:

Available Formats

Magellan

3 Verilog Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Magellan User Guide 3

Source File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Mixed-Language Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5 Using MG Shell and Magellan Commands . . . . . . . . . . . . . . . . . . . . . . . . 107

4 Magellan User Guide

Using Magellan Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6 Building and Running a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Magellan User Guide 5

Run Short Trace Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7 Preparing Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

6 Magellan User Guide

Randomizing X Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

8 Preparing the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Magellan User Guide 7

Writing VHDL Reset Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

9 Testing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

8 Magellan User Guide

Choosing Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Magellan User Guide 9

Specifying Which Assertions are Checked . . . . . . . . . . . . . . . . . . . . . . . . 360

10 Testing Automatically Extracted Properties (AEPs) . . . . . . . . . . . . . . . . . . 367

11 Testing RTL Signal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

10 Magellan User Guide

Detecting Deadlock/Livelock Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 389

12 Testing Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

13 Testing Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Magellan User Guide 11

14 Reporting and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

12 Magellan User Guide

15 Detecting Simulation/Synthesis Mismatches . . . . . . . . . . . . . . . . . . . . . . . 457

Magellan User Guide 13

14 Magellan User Guide

Magellan User Guide 15

Using the Synopsys Installer

16 Magellan User Guide

For larger designs, it is desirable to have the following configuration:

Magellan creates multiple processes during formal searches. It runs on

Downloading the Software

To download the Magellan software:

1 Start an FTP session to ftp.synopsys.com:

2 Enter anonymous as your login name:

3 Enter your e-mail address as your password.

Magellan User Guide 17

4 Set the transfer mode to binary:

5 Change to the pub directory:

8 Log off the FTP server:

18 Magellan User Guide

2 Untar the release files. For example, enter:

3 Run the Synopsys Common Installer either in command-line or GUI mode.

Answer the questions as prompted.

Magellan User Guide 19

2 Add the Magellan license key information to the license file.

20 Magellan User Guide

Configuring Environment and Path Variables

MG_HOME Indicates the directory where Magellan is installed.

VCS_HOME Indicates the directory where VCS or VCS MX is installed. This is

SYNOPSYS_SIM Indicates the directory where VCS MX is installed. Do not set

VERA_HOME Indicates the directory where Vera is installed. Vera is only

SYNOPSYS Indicates the directory where Design Compiler is installed. This is

LD_LIBRARY_PATH If you are testing a VHDL or mixed-language design, set

SNPSLMD_LICENSE_FILE The host name of the license server. Set this