Vera User Guide (Ver. 2005)

Vera User GuideVersion X-2005.12 December 2005

Comments? E-mail your comments about Synopsys documentation to [email protected]

Copyright Notice and Proprietary InformationCopyright 2006 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 DocumentationThe 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 StatementAll 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 readers responsibility to determine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, 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, 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, plus Hierarchical Optimization Technology, High Performance Option, HotPlace, HSIM , 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.

Vera User Guide, version X-2005.12

ii

ContentsKnown Limitations and Resolved STARs . . . . . . . . . . . . . . . . . . . . About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction Overview of Testbench Development . . . . . . . . . . . . . . . . . . . . . . . Components of a Basic Vera Verification Environment . . . . . . . . . . SystemClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Template Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1-4 1-7 1-7 xviii xviii xxii

Vera Interactive Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 Running Vera Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 2. Using Vera The Vera Testbench Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verilog-based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VCS Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2-3 2-6

VHDL-based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

iii

VHDL Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 Simulator Specific Instructions . . . . . . . . . . . . . . . . . . . . . . . 2-16 Mixed HDL-based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Models with Different Simulators. . . . . . . . . . . . . . . . . . VCS-MX (Verilog on top) . . . . . . . . . . . . . . . . . . . . . . . . . . . VCS-MX (VHDL on top) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simplified Use Model for VCS-MX . . . . . . . . . . . . . . . . . . . . ModelSim SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NC-Sim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations and Unsupported Features . . . . . . . . . . . . . . . . SystemC-based Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an OpenVera Interface. . . . . . . . . . . . . . . . . . . . . . Running SystemC with OpenVera . . . . . . . . . . . . . . . . . . . . Calling OpenVera Tasks from SystemC . . . . . . . . . . . . . . . . Calling SystemC from OpenVera . . . . . . . . . . . . . . . . . . . . . 3. Compiling and Running Testbenches Compiler Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . General Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compilation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2 3-2 3-4 2-17 2-20 2-21 2-22 2-24 2-26 2-26 2-27 2-27 2-28 2-29 2-32 2-32

Running Vera with a Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28 Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28 On and Off Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30 Options Requiring User-Specified Values . . . . . . . . . . . . . . . . . 3-35 Passing Data at Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43 Referencing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45

iv

External Declaration of Subroutines . . . . . . . . . . . . . . . . . . . . . . . . 3-45 4. Vera-SystemC Transaction Level Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemC Memory Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemC Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Vera to Create the TLI Infrastructure . . . . . . . . . . . . . . . . Creating the Vera Testbench Program . . . . . . . . . . . . . . . . . . . . Create SystemC main Program . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4-3 4-3 4-5 4-7 4-8 4-9

Compile and Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 5. Randomization in Vera Random Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seeding for Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 5-7

Randomization: Hierarchical Seed Saving . . . . . . . . . . . . . . . . . . . 5-10 randcase Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 Random Number Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14 random() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14 urandom() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15 rand48() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 urand48() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 urandom_range() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17 random_range() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 rand_normal() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18

v

rand_poisson() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 rand_t() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 rand_exponential() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 rand_erlang() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20 rand_chi_square() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20 Constraint Based Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21 Random Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27 Constraint Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Constraint Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditional Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . Array Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variable Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unidirectional Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . Function Calls in Constraints . . . . . . . . . . . . . . . . . . . . . . . . Static Constraint Blocks and Random Variables . . . . . . . . . 5-33 5-34 5-34 5-35 5-36 5-39 5-42 5-44 5-57 5-64 5-69 5-81 5-87

Randomize Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-88 Inline Constraints Using "randomize() with" . . . . . . . . . . . . 5-94 pre_randomize() and post_randomize() . . . . . . . . . . . . . . . . 5-96 Disabling Random Variables . . . . . . . . . . . . . . . . . . . . . . . . 5-98 Disabling Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-101 Dynamic Constraint Modification . . . . . . . . . . . . . . . . . . . . . . . . 5-103 Out of Body Declaration of Constraints . . . . . . . . . . . . . . . . . . . 5-104 Debugging Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-104

vi

Solver Choice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-107 Automatic Solver Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . 5-108 Internal Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-109 Efficient Use of Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110 Constraint Solver Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 5-111 Runtime Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-112 Control of Diagnostic Reporting . . . . . . . . . . . . . . . . . . . . . . 5-113 Solver Runtime Options to Control Memory and CPU Usage . 5-114 Compatibility with Vera Version 5.2 and older . . . . . . . . . . . . . . 5-115 Pre-6.0 Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-118 Random Sequence Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-122 VSG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-122 Production Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-123 Production Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126 Weights for Randomization . . . . . . . . . . . . . . . . . . . . . . . . . 5-126 if-else Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-127 case Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-128 repeat Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-129 break Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-130 continue Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-131 Passing Values Between Productions . . . . . . . . . . . . . . . . . . . . 5-132 Value Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132 Value Passing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-133 6. Data Packing and Unpacking Pack and Unpack by System Functions . . . . . . . . . . . . . . . . . . . . . Pack and Unpack by Class Methods . . . . . . . . . . . . . . . . . . . . . . . . 6-2 6-3

vii

Identifying Data to Pack and Unpack . . . . . . . . . . . . . . . . . . . . . Packing Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unpacking Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Details of Pack and Unpack . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-3 6-4 6-6 6-8 6-9

Pack and Unpack Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 7. Functional Coverage Coverage Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Coverage Models Using Coverage Groups . . . . . . . . . . . Embedded Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . Instantiating Embedded Coverage Groups . . . . . . . . . . . . . 7-2 7-3 7-6 7-8

Class and Coverage Group Definitions in Different Files. . . . . . 7-12 Scoping Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 Additional Header File Needed to Access Sample Point . . . 7-14 Compiler reports mismatch between declaration and definition 7-18 Inheritance Does Not Override Coverage Groups . . . . . . . . 7-19 Multiple definitions of coverage groups is an error . . . . . . . . 7-19 External coverage definition is not possible in an aspect extension of a class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20 Vera Scoping Rules in Coverage Groups . . . . . . . . . . . . . . . . . 7-20 Defining Sampled Coverage Points . . . . . . . . . . . . . . . . . . . . . . Auto Bin Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of User Defined Bins for Coverage Points . . . . . . User-defined States for Coverage Points . . . . . . . . . . . . . . . 7-21 7-25 7-31 7-36

User-defined Illegal States for Coverage Points . . . . . . . . . . . . 7-42 User-defined Transitions for Coverage Points . . . . . . . . . . . 7-43

viii

User-defined Illegal Transitions for Samples . . . . . . . . . . . . 7-50 Cross Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52 User-Defined Cross Coverage Bins . . . . . . . . . . . . . . . . . . . 7-56 Sample Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-63 Types of Sampling Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7-63 Passing Arguments to Coverage Groups. . . . . . . . . . . . . . . . . . 7-70 Expressions within Coverage Group Definitions . . . . . . . . . . . . 7-75 Cumulative and Instance-based Coverage . . . . . . . . . . . . . . . . . . . 7-77 Cumulative Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77 Instance-based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77 Measuring Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-78 Coverage Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-80 Coverage Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-82 Unified Coverage Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-86 Coverage Reporting Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-86 Coverage Data and Post-processing Tools . . . . . . . . . . . . . . . . . . 7-87 Unified Coverage Directory and Database Control . . . . . . . . . . 7-87 Loading Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-89 Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-91 Predefined Coverage Group Tasks and Functions . . . . . . . . . . . . . 7-93 Activation/Deactivation: User Defined Bins . . . . . . . . . . . . . . . . . . 7-100 Coverage Feedback: query() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-106 Pre Vera X-2005.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-115 Compile-Time Option: -covg_compat . . . . . . . . . . . . . . . . . . . . 7-115

ix

Auto-Bin Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-116 Cross Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-121 User-defined Cross Coverage Bins . . . . . . . . . . . . . . . . . . . 7-123 Enhancements to cross coverage . . . . . . . . . . . . . . . . . . . . . . . 7-130 Saving/reporting missing cross product bins . . . . . . . . . . . . 7-131 Disabling generation of automatic cross product bins . . . . . 7-134 Coverage Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-138 8. Reference Verification Methodology (RVM) 9. Temporal Assertions and Expressions Temporal Assertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding OVA Objects to a Testbench . . . . . . . . . . . . . . . . . . . . . Including the VeraOva.vrh Header File . . . . . . . . . . . . . . . . . . . Setting Up the OVAEngine Object . . . . . . . . . . . . . . . . . . . . . . . Controlling OVA Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resetting OVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up the OVAAssert Objects . . . . . . . . . . . . . . . . . . . . . . Instantiating OVAAssert Objects . . . . . . . . . . . . . . . . . . . . . . . . Controlling Evaluation Attempts. . . . . . . . . . . . . . . . . . . . . . . . . Counting Successes and Failures . . . . . . . . . . . . . . . . . . . . . . . Setting Up the OVAEvent Objects . . . . . . . . . . . . . . . . . . . . . . . 9-4 9-4 9-4 9-5 9-5 9-6 9-6 9-6 9-8 9-9 9-9

Instantiating OVAEvent Objects . . . . . . . . . . . . . . . . . . . . . . . . . 9-10 Suspending Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10 Eliminating OVAEvent Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11 Terminating the OVAEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11 Example Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11

x

Compiling and Simulating OVA Objects. . . . . . . . . . . . . . . . . . . 9-13 Running a Vera Simulation with OVA . . . . . . . . . . . . . . . . . . . . . . . 9-13 Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14 The OVAsim Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14 -ova option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 New Vera-OVASIM Flow with Different Simulators . . . . . . . . . . 9-16 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18 Task Invocation from the Simulators Prompt . . . . . . . . . . . . . . . 9-18 Viewing Results with the Report File . . . . . . . . . . . . . . . . . . . . . 9-19 Using OVA Assertions with Vera and Third Party Simulators . . . . . 9-20 Compiling and Simulating with VCS . . . . . . . . . . . . . . . . . . . . . 9-20 Vera and VCS MX simulation Verilog top . . . . . . . . . . . . . . . 9-20 Vera and VCS MX simulation . . . . . . . . . . . . . . . . . . . . . . . . 9-21 Compiling and Simulating with NC-Verilog . . . . . . . . . . . . . . . . 9-22 Compiling and Simulating with NC-VHDL . . . . . . . . . . . . . . . . . 9-23 Compiling and Simulating with MTI Verilog . . . . . . . . . . . . . . . . 9-24 Compiling and Simulating with MTI VHDL . . . . . . . . . . . . . . . . . 9-25 10. Testbench Optimization Vera Performance Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Profiling Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Performance Profiler Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 Vera Memory Profiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7 Profiling Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8 Profiled Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10 Memory Profiler Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12

xi

Memory Profiling Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15 Using vera_profile_object_verbose . . . . . . . . . . . . . . . . . . . 10-15 Verbose Profile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16 Save and Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19 Linking Vera with VCSs Save/Restart . . . . . . . . . . . . . . . . . . . . 10-19 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21 Dynamic Loading of Vera Object Files . . . . . . . . . . . . . . . . . . . . . . 10-24 Creating a Vera Dynamic Executable Object (VDEO) . . . . . . . . 10-24 Loading and Unloading a VDEO File . . . . . . . . . . . . . . . . . . . . . 10-26 Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-26 Unloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29 11. Vera Interactive Debugger Debugger Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 How Debugging Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8 Toolbar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13 Project Workspace Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13 Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20 Local Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22 Global Watch Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24 Debugging with Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26

xii

Stepping Vera Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31 Watching Variables and Expressions . . . . . . . . . . . . . . . . . . . . . . . 11-32 Forcing a Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-33 Finding a String in Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34 Preferences and Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-36 Debugger Settings File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-39 Displaying the simulation log file . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40 Enabling the LogWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40 12. Vera Waveform Interface OpenVera Plot Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 vera_plot() Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5 vera_plot() Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7 Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7 OpenVera Plot Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9 Plotting for VirSim Waveform Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9 Post Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10 Interactive Simulation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10 Plotting for MTI-ModelSim Waveform Tool . . . . . . . . . . . . . . . . . . . 12-11 Post Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13 Plotting for Novas-Debussy Waveform Tool. . . . . . . . . . . . . . . . . . . 12-14 Post Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15 Interactive Simulation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

xiii

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17 13. Project-Based Testbenches Vera Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2 Vera Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Timescale Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3 Clock Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5 Clock Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5 Clock Alias Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6 Connect Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6 Veritask Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9 Template for Vera Configuration File . . . . . . . . . . . . . . . . . . . . . 13-10 Vera Object Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11 Project-based Configuration Simulation . . . . . . . . . . . . . . . . . . . . . 13-11 Main-Specific Plus Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13 Instance-Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14 Mixed HDL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15 14. Testbenches for Verification Intellectual Property Verification IP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2 Creating VIP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2 Protected VIP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Setting Up a VIP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Installing the VIP Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4 Typical VIP Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5

xiv

Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7 Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8 Writing a VIP Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8 Editing the Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10 Configuring the VIP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11 Automated Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11 Passing Properties via HDL Parameters . . . . . . . . . . . . . . . 14-14 C and HDL Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15 VIP Implementation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-15 C Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16 HDL Testbenches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17 Command Interfaces for C and HDL Testbenches . . . . . . . . 14-18 Mixed Vera Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20 Creating Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22 Connection to the Users Testbench . . . . . . . . . . . . . . . . . . . . . 14-22 File Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25 Developing a VIP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25 Avoiding Naming Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26 Connecting to HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27 Automatic Object Loading . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27 Including Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29 Preventing Multiple Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 14-29 VIP File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30 Deliverable Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30 VIP Coding Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31

xv

Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31 Header File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32 Version Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32 Classes and Coverage Object Declarations. . . . . . . . . . . . . 14-34 Multiple Instance Support. . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35 Index

xvi

PrefaceThis preface includes the following sections: About This Guide Customer Support

FIX ME!

xvii

Known Limitations and Resolved STARsInformation about known problems and limitations, as well as about resolved Synopsys Technical Action Requests (STARs), is available in the Vera Release Note in SolvNET. To see the Vera Release Notes, 1. Go to the Synopsys Web page at http://www.synopsys.com and click SolvNet. 2. If prompted, enter your user name and password. If you do not have a SolvNet user name and password, you can obtain them at http://www.synopsys.com/registration. 3. Click Release Notes in the Main Navigation section (on the left), click Vera, then click the release you want in hte list that appears at the bottom. The Vera Release Notes are available through the Vera Document Navigator.

About This GuideThe Vera User Guide introduces you to Vera, an advanced testbench automation solution. This guide covers basic Vera tool operation and testbench design topics. The OpenVera LRM: Testbench and Reference Verification Methodology User Guide documents address, in more detail, the OpenVera hardware verification language and the Reference Verification Methodology, respectively. This guide serves as a supplemental teaching guide as well as a reference for the user.

xviii

AudienceThis book is intended to be used by engineers experienced with either Verilog or VHDL. Because OpenVera is used to create programs that link with Verilog and/or VHDL hardware designs, you should have a fundamental understanding of the hardware description language used in the design. This book assumes basic knowledge of hardware design verification. For assumptions about hardware and software environment go to http://www.synopsys.com/products/sw_platform.html

Related PublicationsFor additional information about Vera see Synopsys Online Documentation (SOLD), which is included with the software release. Documentation on the Web, which is available through SolvNet at http://solvnet.synopsys.com. The Synopsys Print Shop, from which you can order printed copies of Synopsys documents, at http://docs.synopsys.com. The Vera Configuration Guide is available through the Vera Document Navigator.

You might also want to refer to the documentation for the following related Synopsys products: VCS DesignWare Library

xix

FlexModel VirSim

xx

ConventionsThe following conventions are used in Synopsys documentation.Convention Description

Courier

Indicates command syntax. Indicates a user-defined value in Synopsys syntax, such as object_name. (A user-defined value that is not Synopsys syntax, such as a user-defined value in a Verilog or VHDL statement, is indicated by regular text font italic.) Indicates user inputtext you type verbatim in Synopsys syntax and examples. (User input that is not Synopsys syntax, such as a user name or password you enter in a GUI, is indicated by regular text font bold.) Denotes optional parameters, such aspin1 [pin2 ... pinN]

Courier italic

Courier bold

[]

|

Indicates a choice among alternatives, such aslow | medium | high

(This example indicates that you can enter one of three possible values for an option: low, medium, or high.) _ Connects terms that are read as a single term by the system, such asset_annotated_delay

Control-c

Indicates a keyboard combination, such as holding down the Control key and pressing c. Indicates a continuation of a command line. Indicates levels of directory structure. Indicates a path to a menu command, such as opening the Edit menu and choosing Copy.

\ / Edit > Copy

xxi

Customer SupportCustomer support is available through SolvNet and through contacting Vera Support.

Accessing SolvNetSolvNet is the Synopsys electronic knowledge base, which contains information about Synopsys and its tools and is updated daily. To access SolvNet, 1. Go to the SolvNET Web page at http://solvnet.synopsys.com. 2. If prompted, enter your user name and password. If you do not have a SolvNet user name and password, you can obtain them at http://www.synopsys.com/registration. If you need help using SolvNet, click SolvNet Help in the column on the left side of the SolvNet Web page.

Contacting Vera SupportIf you have problems, questions, or suggestions, you can contact Vera Support in the following ways: Send an e-mail message to [email protected].

xxii

Telephone the Synopsys Technical Support Center. - Call (800) 245-8005 from within the continental United States. - Call (650) 584-4200 from Canada.

Open a call to your local support center from the Web by going to http://solvnet.synopsys.com (SolvNet user name and password required), then clicking Enter a Call.

xxiii

xxiv

1Introduction 1Vera is an integral part of the Synopsys Smart Verification platform. It is the comprehensive testbench automation solution for module, block and full system verification. The Vera testbench automation system is based on the OpenVera language. This is an intuitive, high-level, object-oriented programming language developed specifically to meet the unique requirements of functional verification. With Vera, it is easy to quickly model the target environment at a high level of abstraction while automatically generating constrained random stimulus. Veras Constraint Solver Engine is used to automatically generate tests that mimic "real-life" stimuli with the application of the verification engineers constraints. Constrained random stimulus enables the detection of a wide range of bugs including functional and corner cases. These self-checking tests written in OpenVera eliminate the need to analyze manually

1-1

simulation waveforms and reports. Its built-in dynamic coverage analysis provides instant coverage feedback, facilitating the efficient generation of high coverage stimuli. Key benefits of Vera are: It enables the generation of high coverage, constraints-driven random stimulus generation It enables scalable and re-usable testbenches with OpenVera the open source Hardware Verification Language It leverages testbenches across all HDLs including VHDL, Verilog, and SystemC It improves simulation efficiency with intelligent, reactive test generation It increases simulation through the usage of distributed processing It accelerates verification ramp up with a large offering of OpenVera Verification IP It leverages high performance, OpenVera assertions, temporal assertion technology to accelerate the development of monitors and checkers

Introduction 1-2

Overview of Testbench DevelopmentArchitectural and block-level specifications capture the intended functionality of a design. These are the standards that designers rely on to implement as a product. In parallel with the design effort, a verification plan is created. This document prioritizes the various features (whether visible to the end user or not) that need to be tested as the design evolves from specification to implementation. The relative priority of these tests is established in the verification plan, as is the schedule for developing the infrastructure and actual tests for each. The product is typically partitioned hierarchically at several levels; as a system, as a chip, and as constituent functional blocks. Each level of abstraction has a segment of the verification plan dedicated to it. The testbench infrastructure should incorporate self-checking to ease maintainability and ensure the highest degree of automation possible. Each feature test will then report its pass/fail status, which can be aggregated into a snapshot of the design at any time. Self-checking may be implemented by comparing the observed outputs with the expected ones (from a reference model) or via a loopback mechanism. In addition to self-checking, constrained random stimulus generation, along with functional coverage monitoring to calibrate the degree to which the enumerated points in the functional space, as documented in the verification plan, have been tested, completes the picture for a state-of-the art verification methodology. Implementing this using Vera greatly increases the confidence of the project team that the product will work the first time it is fabricated, packaged, and delivered.

Introduction 1-3

Components of a Basic Vera Verification EnvironmentA basic Vera verification environment includes a Vera testbench, a Vera shell file, an HDL design (Device Under Test, or DUT), and a top level HDL file that includes the DUT, the Vera shell file, and a clock generator (see Figure 1-1). Figure 1-1 Components of a Basic Vera Verification Environment Top Level HDL file DUT Vera shellVera Testbenchinterface

clockinput clk SystemClock

input clk CLOCK

~

clock generator

A Vera testbench is a collection of Vera files created to verify a DUT. The OpenVera program construct and at least one OpenVera interface declaration must be included in the testbench. An OpenVera interface declaration specifies a set of signals to be connected to the HDL domain, and a clock signal that controls the driving and sampling of the interface signals. The interface declaration can either be saved as a header file (.vrh) to be included in a Vera file (.vr), or declared in the .vr file itself. The recommended naming convention for an interface declaration file is filename.if.vrh.

Introduction 1-4

Example 1-1 shows an example of an OpenVera interface declaration for a 2-bit round-robin arbiter design, rrarb.if.vrh: Example 1-1 OpenVera Interface Declarationinterface rrarb { input clk CLOCK ; input [1:0] grant PSAMPLE #-1 ; output [1:0] request PHOLD #1 ; output reset PHOLD #1 ; }

The interface declaration shown in Example 1-1 defines three interface signals (grant[1:0], request[1:0], and reset) that are synchronized to the positive edge of the interface clock, clk. Directions of the interface signals are defined from the perspective of a Vera testbench. Vera samples input interface signals and drives output interface signals. Signal skews are specified (-1 for input and 1 for output) to prevent potential race conditions. Example 1-2 shows a basic Vera testbench for a 2-bit round-robin arbiter design. Example 1-2 Basic Vera Testbenchrrarb.vr #include // include Vera pre-defined header file #include "rrarb.if.vrh"// include interface file program rrarb_test { // reset rrarb.request = 2'b00; rrarb.reset = 1; @1 rrarb.reset = 0; // single request @1 rrarb.request[0] = 1'b1;// drive request @2 rrarb.grant == 2'b01;// sample grant printf("Request from device 0:\tgrant = %b\n", rrarb.grant); @1 rrarb.request[0] = 1'b0;// release request rrarb.request[1] = 1'b1;

Introduction 1-5

@2 rrarb.grant == 2'b10 ; printf("Request from device 1:\tgrant = %b\n", rrarb.grant); rrarb.request[1] = 1'b0 ; // round-robin test @1 rrarb.request[0] = 1'b1 ; rrarb.request[1] = 1'b1 ; @2 rrarb.grant == 2'b01 ;// should get grant 0, since last //request was 1 printf("Requests from device 0 and device 1:\tgrant = %b\n", rrarb.grant); @1 rrarb.grant == 2'b10 ; // keep asserting both ports, should // get grant 1 printf("Requests from device 0 and device 1:\tgrant = %b\n", rrarb.grant); rrarb.request[0] = 1'b0 ; rrarb.request[1] = 1'b0 ; } // end of program rrarb_test

The testbench drives the request[1:0] signal, then it samples the grant[1:0] signal and checks for the expected values. After the compilation of a Vera file containing the OpenVera program construct, a Vera shell file is generated. The shell file is an HDL file with port declarations that map to the OpenVera interface declarations in the Vera testbench, and an additional input port, SystemClock. Simulator specific interface calls are included in this shell file. Any modification to the Vera shell file is strongly discouraged. Shell files generated for each supported Verilog simulator are the same. Whereas, shell files generated for VHDL simulators vary. In a top level HDL file, the shell file is instantiated and ports of the instantiated shell file are connected to the desired HDL signals.

Introduction 1-6

SystemClockSystemClock is a Vera internal reference signal used only for the OpenVera system function, get_cycle(), and when using the keyword, CLOCK. Connecting SystemClock to the master clock of a verification environment is recommended. SystemClock can be left unconnected if the get_cycle() function or CLOCK keyword is not used.

The Template GeneratorThe Vera Template Generator provides you with an easy way of creating a set of basic template files for testbench creation. You can then edit these files to suit your needs. The template generator reads in a DUT file and creates a Vera interface declaration file (.if.vrh), a Vera file template (.vr.tmp), and a top level HDL file template (.v, or .vhd). These generated template files provide the framework for coding. Note: The input DUT file for the template generator should contain only valid VHDL or Verilog code. Verilog users should remember that the HDL module name cannot start with a digit (for example, 2mod is not permitted). Ports declared within module declarations, a Verilog 2001 standard, can be used to parse port attributes, such as direction, width, net_type, etc. These are embedded within the module declaration to the template generator.

Introduction 1-7

Three styles of Verilog 2001 standard port declaration are currently allowed, they are:module top (input [3:0] IN1,IN2, output [3:0] OUT1); module top(input wire [3:0] IN1, output reg signed [3:0] OUT1,OUT2); module top (IN1,IN2,OUT1); input wire [3:0] IN1,IN1; output reg signed [3:0] OUT1; ..... .... endmodule

The template generator does not support parameter declarations inside module declarations. To invoke the template generator, enter the following command:vera -tem template_options HDL_filename

template_options: These can ne one or more of the following options:Option Definition Required

-I -c -t | -vhdl_t

Includes the directory in the search path Specifies the DUT clock signal Specifies the Verilog | VHDL module name

no no yes

-I path_name This adds an absolute or relative path to the search path for include files.

Introduction 1-8

-c clock_signal This specifies the clock signal on the HDL module, where clock_signal is the DUT signal to be connected to SystemClock. SystemClock is a clock generated by Vera. When specified, the defined (DUT) clock signal is connected to SystemClock and is identified as CLOCK in the interface specification. If omitted, SystemClock is used as the sampling clock. -t | -vhdl_t module_name and HDL_filename This specifies the top HDL module name. The -t or -vhdl_t option is mandatory. where: - module_name is the name of the top HDL module from which the template is being generated. - HDL_filename is the HDL file from which the template is generated. - The file HDL_filename is either a Verilog (.v file) or a VHDL (.vhd file) containing the top level module instantiated within the test_top.v or test_top.vhd file. For example: VHDL:% vera -tem -vhdl_t rrarb -c clk rrarb.vhd

Here rrarb is the module name, and clk is the clock signal name in the DUT file, rrarb.vhd. Verilog:% vera -tem -t rrarb -c clk rrarb.v

Introduction 1-9

Here rrarb is the module name, and clk is the clock signal name in the DUT file, rrarb.v.

Vera Interactive DebuggerThe Vera graphical debugger is a valuable debugging and testbench analysis tool. Its windowed interface allows easy configurability, simplifying use. Its monitoring mechanisms grant access to variables, signals, and expressions resulting in quick and simple testbench analysis. Details of the debugger are documented in Chapter 11, Vera Interactive Debugger.

Running Vera StandaloneThe Vera cycle-based simulator (vera_cs) can run Vera models stand-alone or linked with additional C models. This simulator is useful for rapid prototyping of a Vera testbench or behavioral model while waiting for the HDL DUT to be ready. It is also very useful for trying out small examples when learning Vera. To use the stand-alone simulator, compile the Vera files and then use the following command line to run the simulation:% vera_cs filename.vro

Note: All drives in vera_cs are ignored, and all samples are received as Xs.

Introduction 1-10

2Using Vera 2A Vera testbench can drive the design under test (DUT) effectively for verification, abstracting the stimulus generation-response checking mechanism for productivity. The DUT can be written in one or more of the existing Hardware Design Languages currently available: Verilog, VHDL, or SystemC. This chapter details the mechanisms through which the DUT is wired to the testbench so that the testbench can drive its inputs and observe its outputs.

Using Vera 2-1

The Vera Testbench FlowThere are numerous ways to construct a Vera testbench. This section outlines a simple flow for Verilog and VHDL-based designs. The Vera template generator is used here to start the process. Figure 2-1 illustrates the components of the Vera testbench. Figure 2-1 Template Generator and Components of a Vera Testbench Testbench top_level file DUT instance Vera Shell File interface

filename.if.vrhfilname.v filename_shell.v or filename_shell.vhd

Vera ProgramTemplate filename.vr.tmp

~ Verilog-based Flow VHDL-based Flow

clock generator

Using Vera 2-2

Verilog-based FlowThe procedure for creating a Vera testbench for Verilog-based designs is as follows: 1. The first step is to invoke the template generator:vera -tem -t module_name -c clock filename.v

2. Rename the template Vera program file from filename.vr.tmp to filename.vr. 3. Add code to the Vera program file (filename.vr). 4. Compile the Vera program file:vera -cmp -vlog filename.vr

This creates two files: a. an object code file .vro file b. a filename_shell.v file, which corresponds to the Vera Shell File component of the top_level depicted in Figure 2-1. The Vera filename.shell.v file acts as the interface between the Vera program and the DUT. Do not edit this file. Note: Using the -vlog switch results in the creation of a Vera shell file named filename_shell.v. If this switch is not used, the compiler will assume that the source is Verilog and will create a Vera shell file named filename.vshell. 5. Create the simv executable:vcs -vera filename.v filename_shell.v \ filename.test_top.v

Using Vera 2-3

6. Run the simulation:simv +vera_load=filename.vro

Note: The command line here is appropriate for VCS on Solaris. For other Verilog simulators, see the Vera Configuration Guide in:$VERA_HOME/doc/config.pdf

After successful simulation, you will see a simulation execution report something like the following:Vera: finish encountered at time 11350 cycle 114 total mismatch: 1 vca_error: 0 fail(expected): 0 drive: 2 force: 1 expect: 1 sample: 4 sync: 102 VCS Simulation Report Time: ___ CPU Time: ___ Data Structure size: __ Date

The information in each line is as follows: total mismatch: Is a counter for all expect failures in which soft is not used. For example, for each failure of the following line:@0 counter.cnt == 8h05;

The mismatch is incremented vca_error: Covers all the VCA errors, as described in the OpenVera LRM: Testbench document.

Using Vera 2-4

fail (expected): Counts the failures you expect. All soft expects which result in failures are counted here. Note, if soft is used for an expect which is bound to fail, then fail (expected) will increment, and not mismatch. If you omit soft, then mismatch will increment. drive: The number of variable assignments to output signals from Vera. expect: The number of times an expect statement was executed regardless of the result. This count is incremented for the following successful expect:@0 counter.cnt == 8h04; //This is the correct expect. ###########END PROGRAM Vera: finish encounter at time 11350 cycle 114 total mismatch: 0 vca_error: 0 fail(expected): 0 drive: 2 expect: 1 sample: 4 sync: 102

sample: The number of times an input signal is sampled and assigned to a variable or signal. sync: The number of times Vera is explicitly synchronized to a clock. For example, each of these statements will increment the count by 1:@(posedge CLOCK); @(posedge a.clk);

Using Vera 2-5

exit_status If the Vera program has exited with non-zero status (usually an indication of an error), exit_status will appear. For example:exit_status: 33

This is the value of the argument passed to Veras predefined exit() task. Do not rely on the value of the simulators exit status to determine if the Vera program terminated normally. The simulators exit status may or may not reflect the exit status of Vera.

VCS ExampleThis example starts with the following design under test (an adder):module adder(in0, in1, out0, clk); input[7:0] in0, in1; input clk; output[8:0] out0; reg[8:0] out0; always@(posedge clk) begin out0 vera.ini

VHDL Example//alu.vhd library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity alu_ent is port ( rst : in std_logic; clk : in std_logic; op : in std_logic_vector(1 downto 0); inp1 : in std_logic_vector(7 downto 0); inp2 : in std_logic_vector(7 downto 0); outp : out std_logic_vector(7 downto 0) ); end; architecture alu_arch of alu_ent is signal outp2 : std_logic_vector(15 downto 0); begin proc1 : process(clk) begin if (clk'event and clk = '1') then if (rst = '1') then outp '0');

Using Vera 2-12

else case op is when "00" => outp outp outp2 alu_ent_inp2, alu_ent_inp1 => alu_ent_inp1, alu_ent_op => alu_ent_op, alu_ent_clk => alu_ent_clk, alu_ent_rst => alu_ent_rst ); dut_inst : alu_ent PORT MAP( outp => alu_ent_outp, inp2 => alu_ent_inp2, inp1 => alu_ent_inp1, op => alu_ent_op, clk => alu_ent_clk, rst => alu_ent_rst ); END

c. The Vera file (alu.vr), which is copied from the Vera template file alu_ent.vr.tmp):#include // define interfaces, and vhdl_node here if necessary #include "alu_ent.if.vrh" // define ports, binds here if necessary // declare external tasks/classes/functions here if necessary // declare hdl_tasks here if necessary // declare class typedefs here if necessary program alu_ent_test { // start of top block // define global variables here if necessary // Start of alu_ent_test // Type your test program here: // // Example of drive:

Using Vera 2-15

// @1 alu_ent.outp = 0 ; // // // Example of expect: // @1,100 alu_ent.inp2 == 0 ; // } // end of program alu_ent_test

// define tasks/classes/functions here if necessary

2. The next step is to compile the alu.vr file, which creates the alu_shell.v and alu.vro files:% vera -cmp -simulator alu.vr

3. And finally, you can run the simulation:echo "vera_load = alu.vro" > vera.ini

Simulator Specific Instructions Compiling and Simulating with MTI-Vhdl 1. vlib work 2. vsim c dut_bench do run all; quit 3. vmap work work 4. vcom filename.vhd filename_shell.vhd filename_top.vhd 5. vsim c dut_bench do run all; quit Compiling and Simulating with VCS-MX 1. vhdlan nc event filename.vhd filename_shell.vhd filename_top.vhd 2. scsim nc dut_bench

Using Vera 2-16

Compiling and Simulating with NC-VHDL 1. mkdir work 2. ncvhdl mefilename.vhd filename_shell.vhd filename_top.vhd 3. ncelab me access +rwc work.dut_bench:dut_bench_arch 4. ncsim me work.dut_bench:dut_bench_arch

Mixed HDL-based FlowA mixed design is defined as a design in which a Verilog module instantiates a VHDL module or vice-versa. That is, the design can be either a Verilog top, or VHDL top design. Vera supports three mixed design simulators: VCS-MX, ModelSim SE and NC-Sim. The following features are supported. Sampling and driving a statically bound Verilog/VHDL signal residing in any layer of the mixed design. Importing a task defined in the top Verilog or inside a VHDL package. Dynamically connecting (binding) a Vera signal to a Verilog/ VHDL signal (through signal_connect()), then driving or sampling the signal. Slices of the vectors can be connected to. The signal can be in any layer of the mixed design.

Using Vera 2-17

Sampling and driving a statically connected signal To statically connect a Vera signal to an intermediate node (that is, a non-port signal in the DUT, which may or may not be a mixed signal), use the keyword hdl_node when specifying the signal connections inside the interface. Consider the following design: 1. Verilog modulesmodule top(a, b, c); // the top module ...... ...... reg d; ...... vh_inst vh_mod(a, d); // Instantiating a VHDL module vl_inst vl_mod(b, c); // Instantiating a Verilog module ...... endmodule module vl_mod(ip, op); ...... reg local; ...... endmodule

2. VHDL moduleentity vh_mod is port (sig1 : IN std_logic; sig2 : OUT std_logic); ...... architecture arch of vh_mod is ...... signal local: std_logic; ...... end arch;

Using Vera 2-18

3. Vera Testbench Assume the top module is instantiated inside the test_top file as dut. The Vera testbench can then access the intermediate nodes like dut.vh_inst.local or dut.vl_inst.local or dut.vh_inst.sig1. These signals are accessed in the same way as any intermediate node in other simulators.interface intf_a { ...... output vh_local PHOLD #1 hdl_node "dut.vh_inst.local"; input vl_local PSAMPLE hdl_node "dut.vl_inst.local" ; output vh_port PHOLD #1 hdl_node "dut.vh_inst.sig1" ; ...... }

Importing a Verilog/VHDL task 1. Place all the VHDL tasks in a separate package. Note that only those VHDL tasks which are defined in a package can be imported and only those Verilog tasks which are defined in the top layer Verilog modules can be imported. 2. Inside the Vera testbench, use the keyword hdl_task to declare all the tasks you want to import. 3. Insert the keywords verilog_task or vhdl_task, as appropriate, enclosed within braces inside the task path......... hdl_task veri_task_imported()"{verilog_task}top.top_veri_task"; hdl_task vhdl_task_imported() "{vhdl_task}work.vhdl_task_pkg.proc0"; hdl_task arg_vh_task_imported(var int a) "{vhdl_task}work.vhdl_task_pkg.proc1"; ........ // The default hdl_task type is verilog_task. ...

Using Vera 2-19

// Vera Program starts program import_task_test() { int b=10; ... veri_task_imported(); vhdl_task_imported(); ... arg_vh_task_imported(b); ... }

Sampling and driving a dynamically connected signal Use the signal_connect() system function in the same way as with other simulators.

Use Models with Different SimulatorsFrom Vera version 6.4 onwards, there are two use models for VCS-MX: 1. The flow where two switches, -vcs_mx and -sro_mx are used for Verilog-top and VHDL-top designs, respectively. 2. The new simplified use model where a single switch, -mx is used for both Verilog-top and VHDL-top designs. These use models are described in the following sections, VCS-MX (Verilog on top) on page 2-21, VCS-MX (VHDL on top) on page 2-22, and Simplified Use Model for VCS-MX on page 2-24

Using Vera 2-20

VCS-MX (Verilog on top)1. Compile the Vera files% vera -cmp -vcs_mx vera_files

If you are using a multiple main flow (project-based approach), then do the following:% vera -cmp -cs filename.vr % vera -proj -vcs_mx filename.proj

2. Analyze the VHDL files% vhdlan vhdl_files

While importing VHDL tasks, the vera_mx shell generator will generate a new vhdl shell file vhdltasks_shell.vhd which also needs to be analyzed 3. Compile the Verilog files You must provide two switches to VCS: -mhdl and -vera, or -mhdl and -vera_dbind, When the two switches -mhdl and -vera are used with VCS, the cli option +cli+4 is enabled by default. You can override this cli option for better performance by explicitly providing the options +cli+2, or +cli+3. The effects of the different cli options are: - +cli+2: if the verilog signals in the bottom layers are only to be read (and not written), +cli+2 is sufficient - +cli+3: if the verilog signals in the bottom layers are to be read as well as written, +cli+3 allows you to do so. +cli+3 enables the write capabilities only on wires, not on registers.

Using Vera 2-21

- +cli+4: if you want to read as well as write any verilog signal, (registers as well wires) you do not need to specify any cli option since +cli+4 is enabled by default when the two switches mhdl and -vera are used together. The usage with VCS is as follows:% vcs -mhdl -vera verilog_files

-vera_dbind is selected when using signal_connect() for dynamic binding.simv +vera_load=filename.vro |+vera_mload=filename.vrl | +vera_pload=filename.proj

VCS-MX (VHDL on top)1. In order to compile the Vera file(s) and to generate the corresponding shell file, enter the command:vera -cmp -sro_mx filename.vr

If you are using a multiple main flow (project based approach), then do the following:vera -cmp -cs filename.vr vera -proj -sro_mx filename.proj

2. Analyze all the Verilog files.vlogan filename.v...filenameN.v

3. Analyze all the required VHDL files, including the shell filevhdlan filename1.vhd ...filenameN.vhd

4. In order to elaborate the design, give the following command:scs configuration_name -verilogcomp "[+cli+n]"

Using Vera 2-22

Refer to the VCS-MX User Guide for more information on using Verilog and VHDL. Note: +cli+n enables capabilities incrementally, that is, +cli+2 enables +cli+1 capabilities, +cli+3 enables +cli+2 capabilities and so on. +cli+n is not necessary if the Vera testbench is connecting Vera signals to VHDL signals in the top VHDL layer. The top layer VHDL signals can be driven and sampled, without giving the +cli option. +cli+1 is sufficient if the Vera testbench is neither driving nor sampling an MHDL signal. Use +cli+2 if the Vera testbench is just sampling a Verilog signal. Use +cli+3 if the Vera testbench is driving a Verilog net. Use +cli+4 if the Vera testbench is driving a Verilog register. 5. Include the vera_load=filename.vro, vera_mload=filename.vrl or the vera_pload=filename.proj options in the vera.ini file. 6. If there were no errors, an executable scsim will be generated. scsim can be executed by entering the command:scsim -include filename

where filename contains the commands for scsim. Refer to the VCS User Guide for Information about the command line options available with scsim. Note: Use +cli+n option judiciously, since this affects performance.

Using Vera 2-23

When connecting HDL signals statically or dynamically, always provide absolute path names (that is, do not use any relative path names). In order to dynamically connect a Vera signal to a mixed HDL signal, use the signal_connect() system task in the same way as you would for other simulators.

Simplified Use Model for VCS-MXWhen compiling Vera files with the -mx switch, the design type no longer has to be specified. The following command line is used for Verilog top mixed designs, VHDL top mixed designs as well as pure VHDL designs.vera -cmp -mx vera_file

Figure 2-3 illustrates the flow:

Using Vera 2-24

Figure 2-3vera -cmp -mx Vera files

Verilog Task shell

VHDL shell

VHDL task shell

vdlan If any hdl_task is being imported vlogan Since there is no -mhdl option in this VCS-MX model, there will not be any default enabling of cli capabilities No -vera simv

vcs +cli+n -mhdl

All the features described in VCS-MX (Verilog on top) on page 2-21 and VCS-MX (VHDL on top) on page 2-22 are supported with this simplified use model. With this use model, an imported hdl_task is a vhdl_task by default. If the user wants to import a Verilog task, it needs to be explicitly specified as follows:hdl_task my_task {verilog_task} top.my_veri_task;

Using Vera 2-25

ModelSim SE1. Compile the Vera filesvera -cmp -mti filename.vr

This generates the filename.vro and the vhdl shell files. 2. Analyze the Verilog filesvlog *.v

3. Analyze the vhdl files including the vhdl shell filevcom *.vhd

4. Run the simulationvsim -c configuration_name

NC-Sim1. Create libvpi.so 2. Set SSI_LIB_FILES to make ncsim load vera_ncvl_mx.dl instead of the default vera.dlsetenv SSI_LIB_FILES $VERA_HOME/lib/vera_ncv1_mc.dl

3. Compile Vera files.vera -cmp -ncvl_mx filename.vr

This generates a Verilog shell file and the vro file. The switch -ncvl_mx should be used only for the Verilog-top mixed design flow with NC-Sim. As of now, VHDL-top mixed design flow is not supported with NC-Sim. 4. Analyze the verilog files including the verilog shell filencvlog *.v

Using Vera 2-26

5. Analyze the VHDL filesncvhd *.vhdl

6. Elaborate the designncelab work.top module

7. Run the simulationncsim work.top module

Limitations and Unsupported FeaturesThe following is not supported: VHDL top flow with NC-Sim Importing Verilog tasks defined below the VHDL layer. Exporting Vera tasks to the mixed HDL side.

SystemC-based FlowOpenVera supports integration with SystemC. The integration supports: statically bound signals, calling OpenVera tasks from SystemC, calling non-time consuming SystemC tasks from OpenVera.

OpenVera is supplied as a static library. This library, along with the SystemC library, is linked with your SystemC code to form a single executable. This executable is able to load and run OpenVera vro files.

Using Vera 2-27

Creating an OpenVera InterfaceTo connect OpenVera to a SystemC design, you need to specify an appropriate collection of interfaces in the OpenVera program file. An interface is a list of signals that crosses the SystemC/OpenVera boundary. SystemC and OpenVera types are not directly equivalent so a mapping from one type to the other must be performed. For example, assume you wish to test a SystemC module named Device, which has the following declaration.SC_MODULE(Device){ sc_in sig1; sc_out sig2; sc_in clk; ... }

This module has an 8-bit logic input, a 1-bit logic output, and a boolean clock. Assuming you wish to have access to all three of these signals from OpenVera, you would define an interface in your OpenVera program, as illustrated below. Except for clk, which is always an input signal, the signal directions are reversed (for example, an sc_in signal is a OpenVera output signal). The skew constants are of course arbitrary and not significant for this example.interface ifc1 { output [7:0] sig1 PHOLD #3; input sig2 NSAMPLE #-3; input clk CLOCK hdl_node "{bool}"; }

The default mapping from an OpenVera type to a SystemC type is to sc_logic for bit vectors of width 1 and to sc_lv for bit vectors wider than 1 bit. The types bool, sc_bv, sc_int, sc_uint, sc_bigint, sc_biguint can be specified using the hdl_node construct as shown in the example above.

Using Vera 2-28

Running SystemC with OpenVeraNote: The SystemC integration does not support dynamically bound signals or integration with a third language. This stage assumes you have created an OpenVera file named test.vr and a SystemC file named test.cpp. The OpenVera file should have an appropriate interface and presumably include code to interact with the SystemC signals. The steps to compile and run the code are as follows: 1. Generate the shell file, the top file and the vro. The shell file is a SystemC header which contains the routines to communicate with the OpenVera runtime. Within it is a SystemC module called vera_shell, which you must instantiate and connect to the SystemC signals. The top file is an example of instantiating the vera_shell module. The top file always requires some modification to suit the particular design being tested. The command to generate these files is:% vera -systemc -cmp -top test.vr

The files produced are: - test_shell.h: the OpenVera shell include file for Vera - test_top.cpp: the top testbench - test.vro: the executable for Vera If the top file has been modified and does not need regenerating, the -top argument should be removed.

Using Vera 2-29

2. Modify the top file. The top file assumes your module is named test. You should rename test to the name of your module and include the header for this module in the top file. For this example you would change test to Device and include Device.h. This assumes Device.h contains the declaration of the Device module. The signal connections should generally be correct for all but clock signals. The generated top file includes a SystemC clock which it ties to the OpenVera SystemClock. This clock should often be tied to the SystemC modules clk signal and in this example the OpenVera interface clk signal. 3. The OpenVera runtime library expects a set of runtime arguments. These are forwarded by the generated top file from the command line of the C++ executable using:VeraSystemC::SetArguments(argc, argv)

where argc and argv are the arguments to sc_main. These arguments can of course be modified, and/or hard-wired at your discretion but no modifications should be required. 4. Compile test_top.cpp. The top file should be compiled into a test_top.o file. The test_top.cpp includes test_shell.h which includes header files stored in $VERA_HOME/include/systemc. These instructions are assuming $SYSTEMC has been set to the location of the users SystemC installation. This environment variable is not otherwise necessary. Using gcc, the command to compile the file is:g++ -g -I. -I$VERA_HOME/include/systemc \ -I$SYSTEMC/include -c test_top.cpp

5. Compile your code. This step should be very similar to compiling test_top.cpp. The OpenVera include directory is of course unnecessary.

Using Vera 2-30

6. Link the final executable. The executable should include the SystemC library, the OpenVera library for SystemC, test_top.o and the your SystemC code. The OpenVera library for SystemC is located at $VERA_HOME/lib/systemc/libVERA.a. Depending on the machine, additional system libraries may be required. The commands below assume the final executable will be called run.x. On Solaris:g++ -g -L$VERA_HOME/lib/systemc \ -L$SYSTEMC/lib-gccsparcOS5 -o run.x \ test.o test_top.o -lVERA -lsystemc \ -lm -lsocket -lnsl -ldl

Note: For machines not qualified for the Synopsys configuration, the -ldl and -lnsl need to be added to the g++ link command. On Linux:g++ -g -L$VERA_HOME/lib/systemc \ -L$SYSTEMC/lib-linux -o run.x \ test.o test_top.o -lVERA -lsystemc -lm -ldl

7. Run the simulation. The executable forwards arguments to the OpenVera runtime. The OpenVera runtime expects to be told the location of vro files. The command to run OpenVera with just test.vro would be:run.x +vera_load=test.vro

Using Vera 2-31

Calling OpenVera Tasks from SystemCThe above description does not include imported and exported functions. To call an OpenVera task from SystemC, you must prefix the declaration in OpenVera with the export keyword. This causes the generated vera_shell module to contain a task, task_taskname, with mapped arguments. For example, the statement:export task parity(reg [47:0] x)

creates a member function of the generated module declared using:static void task_parity(sc_lv x, sc_event *pDone=0)

The sc_event pointer, pDone, is an optional argument. OpenVera calls pDone->notify() when the OpenVera task parity() has completed execution. A null value indicates that no notification is necessary. Var arguments are supported. Only bit-vector and integer types are supported.

Calling SystemC from OpenVeraTo call a SystemC task from OpenVera, you must add a declaration of the form to the OpenVera code:hdl_task vera_taskname (arguments) "C_taskname";

In the generated header this will produce a line of the form:extern void C_taskname (arguments);

where the OpenVera arguments have been mapped to C++ arguments.

Using Vera 2-32

You must then write a task matching the generated extern declarations.

Using Vera 2-33

Using Vera 2-34

3Compiling and Running Testbenches 3This chapter describes how to compile and run testbenches using Vera. It includes the following sections: Compiler Command Line Options Running Vera with a Simulator Runtime Options Passing Data at Runtime Referencing Variables External Declaration of Subroutines

Compiling and Running Testbenches 3-1

Compiler Command Line OptionsThe Vera compiler accepts two types of options: general options, which do not involve the compilation of an OpenVera source code file, and compilation options, which are used when compiling an OpenVera source code file.

General OptionsGeneral options can be passed to the Vera compiler to return tool information and to create template files. When these options are used, the OpenVera source code files are not compiled and therefore no Vera object files are created. The syntax to invoke the compiler is:vera general_options [input_filename ]

general_options is one or more of the following:Option-help -pp -print -proj -rvm_version -tem -v -V -vcon -vmc

DefinitionLists valid Vera executable options Invokes the Vera preprocessor Creates a PostScript file Creates Vera shell files from the project file displays rvm version Invokes the Vera template generator Returns the Vera compiler version Prints complete version information For multiple module support Prints version information for the Vera virtual machine.

-help Lists all the valid Vera executable options.


-pp input_filename invokes the Vera preprocessor on the input file. The preprocessor output file is written to stdout. -D macro_name=value specifies a text macro. See -D macro_name=value. To invoke the ANSI preprocessor, use the -ansi switch. -print filename1 filename2 ... filenameN Prints the specified files to a PostScript file called filename.ps. By default, lines are not wrapped. To specify a line wrap after a certain number of characters, use the -w switch: -w number where number is the number of characters allowed before lines are wrapped. -Pprinter specifies a printer in the network. -proj project_filename Generates a Vera shell file called modulename_shell.v for each module (for VHDL the name is modulename_proj_shell.vhd) contained in the Vera project file. -rvm_version Displays the RVM version available in the Vera installation:vera -rvm_version RVM Class Library Version: 8.5.3

-tem verilog_filename invokes the Vera template generator (see The Template Generator on page 1-7). -v Prints the version number of the Vera installation. For example, a version number will look similar to: 5.1.0


-V Prints complete version information. For example, a complete version will look similar to: VERA 5.1.0 (Beta3) -vcon Generates a .vcon file for use with multiple module support. -vmc Prints version information for the Vera virtual machine, that is, the VRO file version. For example, a VRO version may look like: 4.1

Compilation OptionsThe Vera compiler is primarily used to compile Vera source code using the -cmp option. The syntax is:vera -cmp compiler_options -simulator input_filename output_filename/output_directory_name

compiler_options: Is one or more of the following:Option-all_force -ansi -aop -covg_compat -D -dep_check -dyn -f -F -g

Definitionall signals become forceable. Invokes the ansi preprocessor. Compiles aspect oriented extensions files. Compiles files in pre-2005.12 semantics for coverage. Specifies a macro name. Detects files with circular dependencies. Used to ensure that the VDEO has a unique entry point defined. Automates capturing file dependencies across multiple files. Automates capturing file dependencies across multiple files. Includes debugger information


Option-h -H -HC -HCnu -hnu -Hnu -I -i -i_skew -local

DefinitionUpdates .vrh file Updates .vrh file Updates .vrh file and compiles .vro file Updates .vrh file only if there have been changes and compiles .vro file Updates .vrh file only if there have been changes. Compiles Turns on the -H switch and updates the .vrh file only if it has changed Adds a specified path to the search path for include files. Produces an ASCII interface definition. Specifies default input skew. Includes local variables in auto generated header files when it is specified in combination with one of the header file generation options. All the text that is printed to stdout/stderr is written to a specified log file. Sets the maximum number of errors before compilation failure. No dependency graph generated when using -dep_check. Disables pack warning messages for packing of a null object. Outputs dependencies for source files to standard output. Compiles in quiet mode, without a header. Compiles files in pre-6.0 compatibility mode. Generates SystemC header file. Enables old typedef usage. Generates a VHDL test_top file. Used in conjunction with the -y in conjunction. The compiler will compile the program_file.vr and the files this .vr file is dependent upon. Preprocesses file.vr in non-ANSI mode invokes license polling Generates an IP core. Applies assignment-style widening to expressions passed as task/function arguments. Compiles all .vr files in specified directory.

-log_file -max_error -no_dep_graph -no_warn_null -print_deps -q -random_compat -systemc -tdef -top -top_file

-traditional +ver+lic+wait -vip -widen_args -y


-all_force By default, all signals become forcible when compiling with the -all_force compile-time option. Therefore, the force attribute does not have to be present on the interface signal for the signal to be forced. Note: Force and release are only supported for pure Verilog designs. -ansi Preprocesses the Vera source code in ANSI mode. -aop Supports Veras Aspect-Oriented Extensions. Users need to adopt a methodology that partitions all introductions and advice in separate files from the class definitions, program blocks, etc. Only introductions and advice may be present in such files. These files must be compiled with the -aop switch. The -aop switch may not be used on other Vera code blocks.vera -cmp -aop cov1.vr vera -cmp -aop cov2.vr vera -cmp -aop cov3.vr

The resulting aspect .vro files must be loaded before any non-aspect .vro files. This may be done by either listing the .vro files first in the .vrl file, or by setting the vera_aspects runtime argument to the file names: (see vera_aspects on page 3-35)simv +vera_aspects=cov1.vro,cov2.vro,cov3.vro

Note: The same AOP .vro file should not be listed in both the +vera_aspect list and in the .vrl file.


Example 3-1// foo.vr class foo { integer x; } #include "foo.vrh" // fooAop.vr extends fooAop(foo) { before task new() { printf("New called\n"); } } // top.vr: #include "foo.vrh"// do not include fooAop.vrh program top { foo f; f = new(); }

compilation:vera -cmp -HC foo.vr vera -cmp -aop fooAop.vr vera -cmp top.vr

Note: When using the automated build option, the -aop switch should be specified within the file.list and not on the command line. Using the above example:# file.list -HC foo.vr -aop fooAop.vr top.vr vera -cmp -f file.list -dep_check

Creating the .vrl file: Option 1:// object.vrl // aop files must be first fooAop.vro foo.vro top.vro


Option 2:// object.vrl // must use +vera_aspects=fooAop.vro on simulation // command line foo.vro top.vro

Simulation Option 1:vera_cs +vera_mload=object.vrl

Option 2:vera_cs +vera_mload=object.vrl +vera_aspects=fooAop.vro

The vera_aspects runtime option (see vera_aspects on page 3-35) applies to all OpenVera main programs. If per-main aspects are required in a multiple main simulation, the aspect .vro files should be specified in the project file. The aspect files for a program must be specified first in the program's .vro list:main Master master_cov_aspect.vro ##coverage aspect for master master.vro main slave slave_cov_aspect.vro ##coverage aspect for slave slave.vro

Note: When using VIP, or attributes to load .vro files, use the +vera_aspects runtime option as described above to ensure that the aspect .vro files are loaded first. The woven code itself can also have semantic errors or introduce semantic errors, for example, a reference that was resolved to an integer variable in a super class now resolves to a string variable.


In these cases, either the compiler, or the runtime loader prints error messages that describe the extension, statement, and target scope that caused the error. -covg_compat The -covg_compat option enables Vera to compile the source file in the old (pre-Vera X.2005.12) semantics for coverage and disables, all the new Vera X.2005.12 coverage features such as: - SV style auto binning - New semantics for cross bins - Accurate cross coverage computation - Accurate hole analysis for cover points and crosses - Default coverage goal changed to 100 percentvera cmp covg_compat [-other_compile_options] file.vr

All .vro files given as input at runtime must have been compiled with this option. If not, the runtime loader issues an error message. The database generated using the option cannot be merged with a database generated without using this option and vice versa. -D macro_name=value Specifies a text macro, where macro_name is the string of text to be substituted for and the text macro is optionally set to value. Text macros defined at compile time are particularly useful when using conditional compilation directives.


-dep_check Enables dependency analysis and incremental compilation. Detects files with circular dependencies and issues an error message when Vera cannot determine which file to compile first. -dyn Is used to compile a Vera file into a VDEO. No other switches may be used. This will produce a dynamic.vro file, which can then be loaded at runtime using the vLoad() system call. -f The f option must be supplied with a filename. This file includes a list of all the source files to be compiled. The recommendation is to append the filename with the .list extension to indicate that it is a Vera source list file. -f works equally well with both relative and absolute path names. For example:------------------------

#file.list topTest.vr packet.vr checker.vr -----------------------vera -cmp -f file.list

-F The -F works similarly to the -f option but the supplied path is prepended to all source files contained within the file list. Since the supplied path is prepended, it is recommended that absolute pathnames not be used within the list file when using -F. Assuming file.list:tb1.vr tb2.vr


The command,vera -cmp -F $MY_FILES_DIR/files.list

results in Vera looking within the $MY_FILES_DIR for tb1.vr and tb2.vr. Usage Note More than one F option can be specified within a list file. This can also be used in conjunction with f Assume the following directory structure:Rootdir file.list out // directory rootdir/include include.list tb1.vr rootdir/library library.list tb2.vr tb3.vr file.list -F include/include.list -F library/library.list include.list tb1.vr library.list tb2.vr tb3.vr Compile Command: vera -cmp -HC -f file.list out

File List Structure The following guidelines pertain to the contents of the list file. The suggested naming convention is . The .list is not required as the full name is specified when giving the f and F options.


Rules All Vera compiler options are supported when specified with a source file. (-h, -H, -HC, -hnu, -Hnu, -HCnu, -y, -F, -f, -max_error, -g, -i_skew, - q, -top, -I). These options only apply to the source file which is specified. For example, if q is used the quiet mode only effects the single source file, not the entire compilation. Comments are prefixed with #. It has to be at the start of a line.

When using the file.list, all options on the command line are considered general options that apply to all the files to be compiled. Source file specific options are set within the file.list. General options are specified on the command line and with the 'opts:' command within the file list. Within a list file, a user can specify general options that effect all subsequent source files. The option to do this is with the list file command 'opts:' These general options apply until another opts: command is reached within the file. At this point the previous 'opts:' option is no longer applied. General options supplied via the command line apply to all files unless overridden by local options, while general options supplied via 'opts:' are applied to all files until another 'opts:' command is found. All general options can be overridden with local options supplied at the individual source file level.#file.list opts: -I.. myfile.vr opts: -I. -HC foo.vr -h bar.vr opts: -I../include -I../source test.vr vera -cmp -f file.list

In the above example the following compilation steps occur:vera -cmp -I.. myfile.vr


vera -cmp -I. -HC foo.vr vera -cmp -I. -h bar.vr vera -cmp -I../include -I../source test.vr

Local options can only be set within the file.list.vera -cmp -I. -Ilibrary -f file.list

file.list-I/etc -HC packet.vr -y library

The above example generates the following compilation steps with a single license checkout.# all .vr files in library are compiled vera -cmp -I. -Ilibrary -y library vera -cmp -I. -Ilibrary -I/etc -HC packet.vr

The user may also specify a general output directory or output directories per file: file.list:# example of output directory -y library library/out # example of output file -I/etc -HC packet.vr out

Usage Notes - Individual source options are applied in addition to the general source options. Should a conflict exist between the general and individual settings, a warning message is printed, and the individual options override the general options - The output directory or output file specified in the list file will override the generic output directory (what is given on command line), if specified.


- The list file may contain environment variables for path names. For example-y $TESTDIR $TESTDIR/out

-g Generates debugging information. You must use this switch if you intend to use the graphical debugger. -h Updates the .vrh header file. -H Generates header files (.vrh) with #include and extern declaration from the Vera file (.vr) This switch does not generate a Vera object file (.vro). An additional compilation step without this switch is required to complete the Vera file compilation. For example:vera -cmp -H test.vr vera -cmp test.vr // generates test.vrh file // generates test.vro file

Note: Both -H and -h, generate header files with the same name, therefore, they override each other. Furthermore, the H and h switches are mutually exclusive. The Vera compiler generates an error message if you try to compile with both switches.


Example 3-2 Example 1//file: B.vr class B { ... ... } //file: A.vr: #include "B.vrh" class A { B b; ... ... }

Compile command (note the order):vera -cmp -H A.vr

The generated header file A.vrh includes the #include B.vrh statement. The header file is shown below://////////////////////////////////////////////// // Vera Header file created from A.vr //////////////////////////////////////////////// #ifndef INC__TMP_A_VRH #define INC__TMP_A_VRH #include "B.vrh" extern class A { integer a1; B b; } #endif

Example 3-3 Example 2//file: B.vr extern integer i; extern class C {....} class B { ... ... }


Compile command:vera -cmp -H B.vr

The generated header file includes extern declarations in the B.vr file. The header file is shown below:////////////////////////////////////////////////// // Vera Header file created from B.vr ////////////////////////////////////////////////// #ifndef INC__TMP_B_VRH #define INC__TMP_B_VRH extern integer i; extern class C {... } extern class B { integer i; } #endif

-HC The -HC option automatically creates a header file with extern declarations and include directives for files included in the source files. It updates the .vrh file. An object file is generated. Examplevera -cmp -HC a.vr

will generate the following files:a.vrh a.vro

-HCnu The -HCnu option automatically creates a header file with extern declarations and include directives for files included in the source files. It updates the .vrh file only if it has changed. An object file is generated.


For example:vera -cmp -HCnu a.vr

will generate the following filesa.vrh a.vro //if it has changed

-hnu The -hnu option functions like the -h option except that it on

Vera User Guide (Ver. 2005)

Documents

design compiler

fpga compiler

library compiler

system compiler

vhdl compiler

power compiler

ecl compiler

eco compiler