vera_ug3.0

8/8/2019 vera_ug3.0

1/515

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

Vera

User Guide

Version 6.3 September 2004

8/8/2019 vera_ug3.0

2/515

ii

Copyright Notice and Proprietary InformationCopyright 2004 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietaryinformation that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement andmay be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation maybe reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, withoutprior 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 mustassign 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 todetermine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITHREGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, DesignCompiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, I, iN-Phase, InSpecs, in-Sync, Leda,MAST, Meta, Meta-Software, ModelAccess, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler,PowerMill, PrimeTime, RailMill, Raphael, RapidScript, Saber, SiVL, SNUG, SolvNet, Stream Driven Simulator, Superlog,System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks ofSynopsys, Inc.

Trademarks ()abraCAD, abraMAP, 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, CircuitAnalysis, 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, DesignAnalyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, 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, HDL Advisor, HDL Compiler,Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace,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, Proteus OPC, Protocol Compiler, PSMGen, Raphael-NES,RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, SiliconBlueprint, 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, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-OPC,Taurus-Process, Taurus-Topography, Taurus-Visual, Taurus-Workbench, 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 ofSynopsys, 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.

Printed in the U.S.A.

Document Order Number: 37196-000 VAVera User Guide, v6.3

8/8/2019 vera_ug3.0

3/515

iii

Contents

Whats New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

1. Introduction

Overview of Testbench Development . . . . . . . . . . . . . . . . . . . . . . . 1-3

Components of a Basic Vera Verification Environment . . . . . . . . . . 1-4

SystemClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

The Template Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Vera Graphical Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Running Vera Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

2. Using Vera

The Vera Testbench Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Verilog-based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

VCS Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

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

8/8/2019 vera_ug3.0

4/515

8/8/2019 vera_ug3.0

5/515

v

SystemC Memory Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

SystemC Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Interface Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Using Vera to Create the TLI Infrastructure . . . . . . . . . . . . . . . . 4-7

Creating the Vera Testbench Program. . . . . . . . . . . . . . . . . . . . 4-8

Create SystemC main Program. . . . . . . . . . . . . . . . . . . . . . . . . 4-9

Compile and Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

5. Randomization in Vera

Random Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Seeding for Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Constraint Based Randomization . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18

Random Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24

Constraint Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29

External Constraint Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30

Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31

Set Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32

8/8/2019 vera_ug3.0

6/515

vi

Distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33

Conditional Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35

Hierarchical Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38

Variable Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40

Dynamic Constraint Modification . . . . . . . . . . . . . . . . . . . . . 5-43

Array Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43

Default Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58

Randomize Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-65

Inline Constraints Using "randomize() with" . . . . . . . . . . . . 5-66

pre_randomize() and post_randomize() . . . . . . . . . . . . . . . . 5-68

Disabling Random Variables . . . . . . . . . . . . . . . . . . . . . . . . 5-70Disabling Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72

Static Constraint Blocks and Random Variables . . . . . . . . . . . . 5-74

Dynamic Constraint Modification . . . . . . . . . . . . . . . . . . . . . . . . 5-74

Debugging Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-75

Solver Choice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77

Internal Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77

Efficient Use of Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78Compatibility with Vera Version 5.2 and older . . . . . . . . . . . . . . 5-79

Pre-6.0 Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82

Random Sequence Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86

VSG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86

Production Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-87

Production Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-89

Weights for Randomization . . . . . . . . . . . . . . . . . . . . . . . . . 5-90if-else Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-91

case Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-92

repeat Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-93

8/8/2019 vera_ug3.0

7/515

vii

break Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94

continue Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94

Passing Values Between Productions . . . . . . . . . . . . . . . . . . . . 5-95Value Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-95

Value Passing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-96

6. Data Packing and Unpacking

Pack and Unpack by System Functions . . . . . . . . . . . . . . . . . . . . . 6-2

Pack and Unpack by Class Methods. . . . . . . . . . . . . . . . . . . . . . . . 6-3

Identifying Data to Pack and Unpack . . . . . . . . . . . . . . . . . . . . . 6-3Packing Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4

Packing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Unpacking Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

Details of Pack and Unpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

Pack and Unpack Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

7. Functional CoverageCoverage Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Defining Coverage Models Using Coverage Groups . . . . . . . . . . . 7-3

Embedded Coverage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Instantiating Embedded Coverage Groups . . . . . . . . . . . . . 7-8

Vera Scoping Rules in Coverage Groups . . . . . . . . . . . . . . . . . 7-13

Defining Sampled Coverage Points . . . . . . . . . . . . . . . . . . . . . . 7-14

State and Transition Bins for Coverage Points . . . . . . . . . . . 7-17Auto-Bin Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17

Overview of User Defined Bins for Coverage Points . . . . . . 7-22

User-defined States for Coverage Points . . . . . . . . . . . . . . . 7-27

8/8/2019 vera_ug3.0

8/515

viii

User-defined Illegal States for Coverage Points . . . . . . . . . . . . 7-34

User-defined Transitions for Coverage Points . . . . . . . . . . . 7-35

User-defined Illegal Transitions for Samples . . . . . . . . . . . . 7-42

Cross Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43

User-defined Cross Coverage Bins . . . . . . . . . . . . . . . . . . . 7-46

Enhancements to cross coverage . . . . . . . . . . . . . . . . . . . . . . . 7-53

Saving/reporting missing cross product bins . . . . . . . . . . . . 7-54

Disabling generation of automatic cross product bins . . . . . 7-57

Sample Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-61

Types of Sampling Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7-62

Passing Arguments to Coverage Groups. . . . . . . . . . . . . . . . . . 7-69

Expressions within Coverage Group Definitions . . . . . . . . . . . . 7-74

Cumulative and Instance-based Coverage . . . . . . . . . . . . . . . . . . . 7-76

Cumulative Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-76

Instance-based Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-76

Measuring Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77

Coverage Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-79

Coverage Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-81

Persistent Storage of Coverage Data and Post-processing Tools . 7-87

File Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-88

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-89

Loading Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-90

Test Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-93

Test Grading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-96

Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-97

8/8/2019 vera_ug3.0

9/515

ix

Predefined Coverage Group Tasks and Functions . . . . . . . . . . . . . 7-98

Activation/Deactivation: User Defined Bins . . . . . . . . . . . . . . . . . . 7-107

Coverage Feedback: query() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-113

8. Reference Verification Methodology (RVM)

9. Temporal Assertions and Expressions

Temporal Assertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

Adding OVA Objects to a Testbench . . . . . . . . . . . . . . . . . . . . . 9-4

Including the VeraOva.vrh Header File . . . . . . . . . . . . . . . . . . . 9-4

Setting Up the OVAEngine Object . . . . . . . . . . . . . . . . . . . . . . . 9-5

Controlling OVA Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

Resetting OVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

Setting Up the OVAAssert Objects . . . . . . . . . . . . . . . . . . . . . . 9-6

Instantiating OVAAssert Objects . . . . . . . . . . . . . . . . . . . . . . . . 9-6

Controlling Evaluation Attempts. . . . . . . . . . . . . . . . . . . . . . . . . 9-8

Counting Successes and Failures . . . . . . . . . . . . . . . . . . . . . . . 9-9

Setting Up the OVAEvent Objects . . . . . . . . . . . . . . . . . . . . . . . 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

Compiling and Simulating OVA Objects. . . . . . . . . . . . . . . . . . . 9-13

Running a Vera Simulation with OVA . . . . . . . . . . . . . . . . . . . . . . . 9-13

Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14

8/8/2019 vera_ug3.0

10/515

x

New Features and the New OVAsim Flow . . . . . . . . . . . . . . . . . 9-14

-ova option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16

New Vera-OVASIM Flow with Different Simulators . . . . . . . . . . 9-16Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-21Compiling 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 and Debugging in Vera

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

Memory Profiling Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13

Using vera_profile_object_verbose . . . . . . . . . . . . . . . . . . . 10-14

Verbose Profile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15

8/8/2019 vera_ug3.0

11/515

xi

Save and Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17

Linking Vera with VCSs Save/Restart . . . . . . . . . . . . . . . . . . . . 10-18

Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20Dynamic Loading of Vera Object Files . . . . . . . . . . . . . . . . . . . . . . 10-22

Creating a Vera Dynamic Executable Object (VDEO) . . . . . . . . 10-23

Loading and Unloading a VDEO File. . . . . . . . . . . . . . . . . . . . . 10-25

Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25

Unloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25

Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28

Vera Interactive Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29

Compiling Vera Source Code for Debugging . . . . . . . . . . . . . . . 10-29

Launching the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30

Debugger Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31

Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34

File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34

Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-35Toolbars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-41

Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-42

11. Vera Waveform Interface

OpenVera Plot Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

vera_plot() Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

vera_plot() Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7

OpenVera Plot Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9

8/8/2019 vera_ug3.0

12/515

xii

Plotting for VirSim Waveform Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9

Post Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10

Interactive Simulation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10Plotting for MTI-ModelSim Waveform Tool . . . . . . . . . . . . . . . . . . . 11-12


Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13

Plotting for Novas-Debussy Waveform Tool. . . . . . . . . . . . . . . . . . . 11-14


Interactive Simulation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17

12.Project-Based Testbenches

Vera Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

Vera Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Timescale Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Clock Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5Clock Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5

Clock Alias Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6

Connect Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6

Veritask Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9

Template for Vera Configuration File . . . . . . . . . . . . . . . . . . . . . 12-10

Vera Object Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11

Project-based Configuration Simulation . . . . . . . . . . . . . . . . . . . . . 12-11

Main-Specific Plus Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . 12-13

Instance-Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14

8/8/2019 vera_ug3.0

13/515

xiii

Mixed HDL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15

13.Testbenches for Verification Intellectual Property

Verification IP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

Creating VIP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

Protected VIP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

Setting Up a VIP Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

Installing the VIP Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

Typical VIP Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5

Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7

Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8

Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9

Writing a VIP Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9

Editing the Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11

Configuring the VIP Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11

Automated Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12Passing Properties via HDL Parameters . . . . . . . . . . . . . . . 13-15

C and HDL Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16

VIP Implementation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16

C Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17

HDL Testbenches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18

Command Interfaces for C and HDL Testbenches. . . . . . . . 13-19

Mixed Vera Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-21

Creating Verification IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23

Connection to the Users Testbench . . . . . . . . . . . . . . . . . . . . . 13-23

8/8/2019 vera_ug3.0

14/515

xiv

File Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-26

Developing a VIP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-26

Avoiding Naming Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . 13-27Connecting to HDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-28

Automatic Object Loading . . . . . . . . . . . . . . . . . . . . . . . . . . 13-28

Including Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-30

Preventing Multiple Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 13-30

VIP File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31

Deliverable Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31

VIP Coding Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-32

Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-32Header File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-33

Version Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-33

Classes and Coverage Object Declarations. . . . . . . . . . . . . 13-35

Multiple Instance Support. . . . . . . . . . . . . . . . . . . . . . . . . . . 13-36

Index

8/8/2019 vera_ug3.0

15/515

xv

Preface FIX ME!

This preface includes the following sections:

Whats New in This Release

About This Guide

Customer Support

Whats New in This Release

This section describes the new features, enhancements, andchanges included in OpenVera 1.4.1 and Vera version 6.3.

For details of these new features and enhancements, see the Vera

6.3 Release Notes. A list of Vera documents, including the latest

release notes, is available through the Vera Document Navigator:

Vera Document Navigator

Enter the following command in a UNIX prompt to bring up the

Navigator:

%vera -doc
http://../Navigator/navigator.pdfhttp://../Navigator/navigator.pdf

8/8/2019 vera_ug3.0

16/515

8/8/2019 vera_ug3.0

17/515

xvii

Enhancement to -dep_check -print_deps

Reference Verification Methodology Enhancements rvm_log performance improvement

pre-defined atomic & scenario generators included

Known Limitations and Resolved STARs

Information about known problems and limitations, as well as about

resolved Synopsys Technical Action Requests (STARs), is availablein the Vera Release Notein SolvNET.

To see the VeraRelease Note,

1. Go to the Synopsys Web page at http://www.synopsys.com andclick SolvNET.

2. If prompted, enter your user name and password. If you do nothave a SolvNet user name and password, you can obtain them at

http://www.synopsys.com/registration.

3. Click Release Notes. Click Vera Release Notes then, open VeraRelease Notes version 6.3.

The Vera Release Notes are available through the Vera DocumentNavigator.

8/8/2019 vera_ug3.0

18/515

xviii

About This Guide

The Vera User Guide introduces you to Vera, an advanced testbench

automation solution. This guide covers basic Vera tool operation andtestbench 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.

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 languageused 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 Publications

For additional information about Vera see

Synopsys Online Documentation (SOLD), which is included withthe software release.

Documentation on the Web, which is available through SolvNETat http://solvnet.synopsys.com
http://user_guide.pdf/http://../lrm/lrm.pdfhttp://../rvm/rvm.pdfhttp://../rvm/rvm.pdfhttp://../lrm/lrm.pdfhttp://user_guide.pdf/

8/8/2019 vera_ug3.0

19/515

xix

The Synopsys Print Shop, from which you can order printedcopies of Synopsys documents, at http://docs.synopsys.com

The Vera Installation Guide is available through the VeraDocument Navigator.

You might also want to refer to the documentation for the following

related Synopsys products:

VCS

DesignWare Library

FlexModel VirSim

8/8/2019 vera_ug3.0

20/515

8/8/2019 vera_ug3.0

21/515

xxi

Customer Support

Customer support is available through SolvNet and through

contacting Vera Support.

Accessing SolvNet

SolvNet is the Synopsys electronic knowledge base, which containsinformation 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 canobtain 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 Support

If you have problems, questions, or suggestions, you can contact Vera

Support in the following ways:

Send an e-mail message to [email protected].

8/8/2019 vera_ug3.0

22/515

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 tohttp://solvnet.synopsys.com (SolvNet user name and passwordrequired), then clicking Enter a Call.

8/8/2019 vera_ug3.0

23/515

1-1

1Introduction 1

Vera 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 developedspecifically to meet the unique requirements of functionalverification.

With Vera, it is easy to quickly model the target environment at a highlevel 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 bugsincluding functional and corner cases. These self-checking tests

written in OpenVera eliminate the need to analyze manually

8/8/2019 vera_ug3.0

24/515

1-2

Introduction

simulation waveforms and reports. Its built-in dynamic coverageanalysis 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-drivenrandom 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 testgeneration

It increases simulation through the usage of distributedprocessing

It accelerates verification ramp up with a large offering ofOpenVera Verification IP

It leverages high performance, OpenVera assertions, temporalassertion technology to accelerate the development of monitorsand checkers

8/8/2019 vera_ug3.0

25/515

1-3

Introduction

Overview of Testbench Development

Architectural and block-level specifications capture the intendedfunctionality of a design. These are the standards that designers rely

on to implement as a product. In parallel with the design effort, averification 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; asa 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 aloopback 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.

8/8/2019 vera_ug3.0

26/515

1-4

Introduction

Components of a Basic Vera Verification Environment

A basic Vera verification environment includes a Vera testbench, aVera 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 aclock generator (see Figure 1-1).

Figure 1-1 Components of a Basic Vera Verification Environment

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 thedriving 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 recommendednaming convention for an interface declaration file is filename.if.vrh.

clock generator~

Vera Testbench

Vera shellDUT

interface

input clk SystemClock

input clkCLOCKclock

Top Level HDL file

8/8/2019 vera_ug3.0

27/515

1-5

Introduction

Example 1-1 shows an example of an OpenVera interfacedeclaration 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 threeinterface 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-robinarbiter design.

Example 1-2 Basic Vera Testbench

rrarb.vr#include // include Vera pre-defined header file#include "rrarb.if.vrh"// include interface file

program rrarb_test{

// resetrrarb.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 grantprintf("Request from device 0:\tgrant = %b\n", rrarb.grant);@1 rrarb.request[0] = 1'b0;// release requestrrarb.request[1] = 1'b1;

8/8/2019 vera_ug3.0

28/515

1-6

Introduction

@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 1printf("Requests from device 0 and device 1:\tgrant = %b\n",

rrarb.grant);@1 rrarb.grant == 2'b10 ; // keep asserting both ports, should

// get grant 1printf("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 thisshell file. Any modification to the Vera shell file is strongly

discouraged. Shell files generated for each supported Verilogsimulator 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.

8/8/2019 vera_ug3.0

29/515

1-7

Introduction

SystemClock

SystemClockis a Vera internal reference signal used onlyfor the

OpenVera system function, get_cycle(), and when using thekeyword, CLOCK. Connecting SystemClockto the master clock of

a verification environment is recommended. SystemClockcan be

left unconnected if the get_cycle() function or CLOCK keyword is notused.

The Template Generator

The Vera Template Generator provides you with an easy way ofcreating a set of basic template files for testbench creation. You canthen edit these files to suit your particular needs.

The template generator is for DUT designed using Verilog. For VHDL

designed DUTs, see page 2-11).

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 templatefiles provide the framework for coding. The Template Generatorsupports the Verilog flow only.

To invoke the template generator enter the following command:

vera -temtemplate_optionsHDL_filename.v

Note:

Verilog users should remember that the HDL module name

cannotstart with a digit (for example, 2mod is not permitted).

8/8/2019 vera_ug3.0

30/515

1-8

Introduction

template_options:

is one or more of the following options:

-I path_name

adds an absolute or relative path to the search path for include

files.

-c clock_signal

specifies the clock signal on the HDL module, where clock_signal

is the DUT signal to be connected to SystemClock. SystemClockis 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 module_name and HDL_filename

specifies the top HDL module name. The -t option ismandatory.

where:

- module_name is the name of the top HDL module from which

the template is being generated.

- HDL_name is the HDL file from which the template isgenerated.

Option Definition Required

-I Includes the directory in the search path no

-c Specifies the DUT clock signal no

-t Specifies the Verilog module name yes

8/8/2019 vera_ug3.0

31/515

8/8/2019 vera_ug3.0

32/515

1-10

Introduction

When the standalone debugger has started, test the menus andopen a file via the File Open dialog box. If all these steps work, you

should be ready to run a real debug session.

Running Vera Standalone

The Vera cycle-based simulator (vera_cs) can run Vera modelsstand-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 asXs.

8/8/2019 vera_ug3.0

33/515

2-1

Using Vera

2Using Vera 2

A 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 themechanisms through which the DUT is wired to the testbench so thatthe testbench can drive its inputs and observe its outputs.

8/8/2019 vera_ug3.0

34/515

2-2

Using Vera

The Vera Testbench Flow

There 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

Verilog-based Flow

VHDL-based Flow

VeraProgram

~

top_level file

Testbench

clock generator

filename.if.vrh

interface

filename_shell.v

Template

filename.vr.tmp

filname.v

DUT Verainstance Shell

File

or

filename_shell.vhd

8/8/2019 vera_ug3.0

35/515

2-3

Using Vera

Verilog-based Flow

The 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 -tmodule_name -c clock filename.v

2. Rename the template Vera program file from filename.vr.tmp tofilename.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 ShellFile component of the top_level depicted in Figure 2-1.

The Vera filename.shell.v file acts as the interface between theVera program and the DUT. Do notedit this file.

Note:

Using the -vlog switch results in the creation of a Vera shellfile 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

8/8/2019 vera_ug3.0

36/515

2-4

Using Vera

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 Installation Guide in:

$VERA_HOME/doc/install.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: 1vca_error: 0

fail(expected): 0drive: 2expect: 1sample: 4sync: 102

VCS Simulation ReportTime: ___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 Language

Reference Manual: Testbench document.
http://../lrm/cover.pdfhttp://../lrm/cover.pdfhttp://../lrm/cover.pdfhttp://../lrm/cover.pdf

8/8/2019 vera_ug3.0

37/515

2-5

Using Vera

fail (expected):

counts the failures you expect. All soft expects which result in

failures are counted here. Note, if soft is used for an expectwhich 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 thefollowing successful expect:

@0 counter.cnt == 8h04; //This is the correct expect.

###########END PROGRAM

Vera: finish encounter at time 11350 cycle 114total mismatch: 0

vca_error: 0fail(expected): 0

drive: 2expect: 1

sample: 4sync: 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);

8/8/2019 vera_ug3.0

38/515

2-6

Using Vera

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 exitstatus may or may not reflect the exit status of Vera.

VCS Example

This 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)beginout0

8/8/2019 vera_ug3.0

39/515

2-7

Using Vera

interface adder{output [7:0] in0 OUTPUT_EDGE OUTPUT_SKEW;output [7:0] in1 OUTPUT_EDGE OUTPUT_SKEW;

input [8:0] out0 INPUT_EDGE #-1;input clk CLOCK;

} //end of interface adder

#endif

b. The test_top file (adder.test_top.v):

module adder_test_top; //adder.test_top.vparameter simulation_cycle = 100;

reg SystemClock;wire [7:0] in0;

wire [7:0] in1;wire [8:0] out0;assign clk = SystemClock;

vera_shell vshell( //Vera shell file.SystemClock(SystemClock),.adder_in0 (in0),.adder_in1 (in1),.adder_out0 (out0),.adder_clk (clk),);

ifdef emu

/*DUT is in emulator, so not instantiated here*/elseadder dut(

.in0 (in0),

.in1 (in1),

.out0 (out0),

.clk (clk),);endif

initial begin //clock generatorSystemClock = 0;forever begin

#(simulation_cycle/2)SystemClock = ~SystemClock;

endend

endmodule

8/8/2019 vera_ug3.0

40/515

2-8

Using Vera

c. The Vera file (adder.vr), which is copied from the Vera templatefile (adder.v.tmp):

// adder.vr (copied from the template adder.v.tmp)

#define OUTPUT_EDGE PHOLD#define OUTPUT_SKEW #1#define INPUT_EDGE PSAMPLE#include

// define any interfaces, and verilog_node here

#include "adder.if.vrh"

// define any ports, binds here// declare any external tasks/classes/functions here// declare any hdl_task(s) here// declare any class typdefs here

program adder_test{ // start of top block

// define any global variables here// Start of adder_test// Type your test program here:

// Example of drive:// @ 1 adder.in0 = 0;

// Example of expect:// @ 1,100 adder.out0==0;

// Example of what you are to add:

@ (posedge adder.clk); // line up to first clock@0 adder.in0=8hff; // drive "ff" to the design@2 adder.out0 == 9h1fe; // expect "1fe" from the design

} // end of program adder_test

// define any tasks/classes/functions here

8/8/2019 vera_ug3.0

41/515

2-9

Using Vera

d. The Vera shell file (adder_shell.v; do notedit this file):

// adder_shell.v

module vera_shell(SystemClock,adder_in0,adder_in1,adder_out0,adder_clk

);input SystemClock;output [7:0] adder_in0;output [7:0] adder_in1;input [8:0] adder_out0;inout adder_clk;//Nest which VMC will reference

// System clock:SystemClockwire SystemClock;

// Other components of this file are not listed here...

endmodule

2. The next step is to compile the adder.vr file, which creates theadder_shell.v and adder.vro files:

% vera -cmp -vlog adder.vr

3. Now you can create the simv executable:

% vcs -vera adder.v adder_shell.v adder.test_top.v

4. And finally, you can run the simulation:

% simv +vera_load=adder.vro

Figure 2-2 summarizes the testbench setup flow using the TemplateGenerator.

8/8/2019 vera_ug3.0

42/515

2-10

Using Vera

Figure 2-2 Testbench Flow using the Template Generator

adder.v

Verilog Source

adder.vr

Vera Template

adder.vshell

Verilog Interface Shell

adder.vro

Vera Object File

adder.test_top.v

Test Top File

adder.if.vrh

Interface Header File

adder.vr.tmp

Temporary File

vcs -vera adder.v adder.test_top.v adder.vshell

VCS Compile

simv +vera_load=adder.vro

Run Simulation

adder.test_top.v

Test Top File

adder.if.vrh

Interface Header File

adder.vr.tmp

Temporary File

Rename & Edit

Vera Compile

vera -cmp -g adder.vr

Generate Template

vera -tem -t adder -c clock adder.v

8/8/2019 vera_ug3.0

43/515

2-11

Using Vera

VHDL-based Flow

The procedure for creating a Vera testbench for VHDL-based

designs is as follows:

1. The first step is to invoke the template generator:

$vera -tem -vhdl_t top_entity[-c clk] filename.vhd

top_entity

defines the name of the top entity.

filename

is the VHDL design

The vhdl_t option reads the top module name.

Invoking the template generator results in three files being generated:

- An interface file: filename.if.vrh

- A top-level file: filename_top.vhd- A skeletal Vera program file: filename.vr.tmp

2. Edit the interface (.if.vrh) file: The signal width for anyuser-defined types has to be specified.

3. Rename the template Vera program file from filename.vr.tmp tofilename.vr.

4. #include filename.if.vrh and add code to the Vera program file

(filename.vr).

5. Compile the Vera program file:

vera -cmp -simulator filename.vr

8/8/2019 vera_ug3.0

44/515

2-12

Using Vera

This creates two files:

- an object code file .vro file

- a filename_shell.vhd file

The Vera filename_shell.vhd file acts as the interface between

the Vera program and the DUT. Do not edit this file.

6. Run the simulation:

echo "vera_load = filename.vro" > vera.ini

VHDL Example

//alu.vhdlibrary ieee;

use ieee.std_logic_1164.all;use ieee.std_logic_unsigned.all;

entity alu_ent isport (

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 issignal outp2 : std_logic_vector(15 downto 0);

begin

proc1 : process(clk)begin

if (clk'event and clk = '1') thenif (rst = '1') then

outp '0');

8/8/2019 vera_ug3.0

45/515

2-13

Using Vera

else

case op iswhen "00" =>outp outp outp2

8/8/2019 vera_ug3.0

46/515

8/8/2019 vera_ug3.0

47/515

2-15

Using Vera

SystemClock => system_clock,alu_ent_outp => alu_ent_outp,alu_ent_inp2 => 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 templatefile 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:

8/8/2019 vera_ug3.0

48/515

2-16

Using Vera

// @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 thealu_shell.v and alu.vro files:

%vera -cmp -simulatoralu.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.vhdfilename_top.vhd

2. scsim nc dut_bench

8/8/2019 vera_ug3.0

49/515

2-17

Using Vera

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 Flow

A mixed design is defined as a design in which a Verilog module

instantiates a VHDL module or vice-versa.

There are two flows according to which HDL is on top:

VCS-MX - Verilog is on top.

VCS-MX - VHDL is on top.

Each of these flows is explained in the following sections.

VCS_MX (Verilog on top)

The following features are supported:

Sampling and driving a statically bound Verilog/VHDL signalresiding in any layer of the mixed design.

Importing a task defined in the top Verilog layer or inside a VHDLpackage.

Dynamically connecting (binding) a Vera signal to a Verilog/VHDL signal (through signal_connect()) and driving/sampling it.Here, we can also connect slices of the vectors and of course, thesignal can be in any layer of the mixed design.

8/8/2019 vera_ug3.0

50/515

2-18

Using Vera

Sample/drive statically connected signal. If you want to staticallyconnect a Vera signal to an intermediate node (a non-port signal in

the design under test, which may or may not be a mixed signal), use

the keyword hdl_node when specifying the signal connections insidethe interface.

Consider the following design.

1. Verilog modules

module top(a, b, c); // the top module............

reg d;......vh_inst vh_mod(a, d); // Instantiating a VHDL modulevl_inst vl_mod(b, c); // Instantiating a Verilog module......

endmodule

module vl_mod(ip, op);......reg local;......

endmodule

2. VHDL module

entity vh_mod isport (sig1 : IN std_logic; sig2 : OUT std_logic);

......architecture arch of vh_mod is

......signal local: std_logic;......

end arch;

8/8/2019 vera_ug3.0

51/515

2-19

Using Vera

Vera Testbench. Say the top module is instantiated inside thetest_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 asany intermediate node in other simulators.

interface{......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 onlythose Verilog tasks that are defined in the top Verilog layermodules can be imported.

2. Inside the Vera testbench, use the keyword hdl_task to declareall the tasks you want to import.

3. Insert the keywords verilog_task or vhdl_task, as appropriate,enclosed within braces inside the task path.

For example:

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

...

// Vera Program starts

8/8/2019 vera_ug3.0

52/515

2-20

Using Vera

program import_task_test(){

int b=10;...

veri_task_imported();vhdl_task_imported();...arg_vh_task_imported(b);...

}

Sampling/driving dynamically connected signal. Usesignal_connect() in the same way as with other simulators.

Running the Simulation.

1. Set the environments for Vera, VCS-MX and VCS:

setenv VERA_HOME set path = ($VERA_HOME/bin $path)setenv VCS_HOME /* VCS 7.0 release onwards */set path = ($VCS_HOME/bin $path)setenv SYNOPSYS_SIM

/* Scirocco 2002.12 release onwards */source ${SYNOPSYS_SIM}/admin/setup/environ.csh

2. Compile the Vera files:

Use the switch -vcs_mx with Vera.

% 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

3. Analyze the VHDL files:

% vhdlan vhdl_files

8/8/2019 vera_ug3.0

53/515

2-21

Using Vera

Note:

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.

4. 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, thecli option +cli+4 is enabled by default. You can override this clioption by explicitly providing the options +cli+2, or +cli+3. Theeffects of the different cli options are:

- +cli+2: if the verilog signals in the bottom layers are only to beread (and not written), +cli+2 is sufficient

- +cli+3: if the verilog signals in the bottom layers are to be readas well as written, +cli+3 allows you to do so. +cli+3 enablesthe write capabilities only on wires, not on registers.

- +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 clioption since +cli+4 is enabled by default when the two switchesmhdl 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 dynamicbinding.

simv +vera_load=filename.vro |+vera_mload=filename.vrl |+vera_pload=filename.proj

8/8/2019 vera_ug3.0

54/515

2-22

Using Vera

VCS-MX (VHDL on top)

Using this type of mixed flow you can:

Sample and drive a statically bound signal, which might reside inany layer of the mixed design (static binding).

Sample and drive a dynamically bound signal, which might residein any layer of the mixed design (dynamic binding).

Import VHDL tasks, which are defined in a package.

You cannot import Verilog tasks.

To statically connect a Vera signal to an MHDL signal, use thekeyword hdl_node when specifying the signal connections inside the

interface. When specifying the signal path, absolute paths from the

top need to be given. The colon, : , is the HDL separator.

Consider the design shown in Figure 2-3.

Figure 2-3 Example of a Mixed Flow Design

top_vhdlis a VHDL entity, and has dut_vhdland shell_vhdlas

components of its architecture.

dut_vhdlhas vlog_modas one of its components,

vlog_modis a module written in Verilog.

top_vhdl (created by Vera or manually written)

dut_vhdl shell_vhdl

vlog_modreg veri_reg; //a register in vlog_mod

8/8/2019 vera_ug3.0

55/515

2-23

Using Vera

Assume that the instance for vlog_mod is vlog_inst and the instancefor dut_vhdl is dut_inst. To access the register veri_reg, the path is

top_vhdl: dut_inst: vlog_inst: veri_reg".

The declaration in the interface file is:

interface interface_name{

...inout vl_reg PSAMPLE PHOLD #1 hdl_node

"top_vhdl:dut_inst:vlog_inst:veri_reg";...

}

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.

Running the Simulation.

1. Set the environments for Vera, VCS-MX and VCS.

setenv VERA_HOME set path = ($VERA_HOME/bin $path)

setenv VCS_HOME /* VCS 7.0 release onwards */set path = ($VCS_HOME/bin $path)setenv SYNOPSYS_SIM /* Scirocco 2002.12 onwards */source ${SYNOPSYS_SIM}/admin/setup/environ.csh

2. In order to compile the Vera file(s) and to generate thecorresponding 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.vrvera -proj -sro_mx filename.proj

8/8/2019 vera_ug3.0

56/515

2-24

Using Vera

3. Analyze all the Verilog files.

vlogan filename1.v ... filenameN.v

4. Analyze all the required VHDL files, including the shell file

vhdlan filename1.vhd ... filenameN.vhd

5. In order to elaborate the design, give the following command

scs configuration_name -verilogcomp "[+cli+n]"

where 'n' is a number between 1 and 4 (inclusive of 1 and 4).+cli+n is optional. If you dont use +cli+n then you should give

scs configuration_name -verilogcomp ""

Refer to the VCS-MX Reference Manual for more information onusing Verilog inside VHDL.

Note:

+cli+n enables capabilities incrementally, i.e., +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 connectingVera signals to VHDL signals in the top VHDL layer. The top

layer VHDL signals can be driven and sampled, without givingthe +cli option.

+cli+1 is sufficient if the Vera testbench is neither driving norsampling 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.

8/8/2019 vera_ug3.0

57/515

8/8/2019 vera_ug3.0

58/515

2-26

Using Vera

Creating an OpenVera Interface

To connect OpenVera to a SystemC design, you need to specify an

appropriate collection of interfaces in the OpenVera program file. Aninterface is a list of signals that crosses the SystemC/OpenVera

boundary. SystemC and OpenVera types are not directly equivalentso a mapping from one type to the other must be performed. For

example, assume you wish to test a SystemC module namedDevice, 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 (e.g., an

sc_insignal is a OpenVera outputsignal). 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 shownin the example above.

8/8/2019 vera_ug3.0

59/515

2-27

Using Vera

Running SystemC with OpenVera

Note:

The SystemC integration does not support dynamically boundsignals 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 aSystemC header which contains the routines to communicatewith the OpenVera runtime. Within it is a SystemC module calledvera_shell, which you must instantiate and connect to theSystemC signals. The top file is an example of instantiating thevera_shell module. The top file always requires somemodification 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.

8/8/2019 vera_ug3.0

60/515

2-28

Using Vera

2. Modify the top file. The top file assumes your module is namedtest. You should rename test to the name of your module andinclude the header for this module in the top file. For this example

you would change test to Device and include Device.h. Thisassumes Device.hcontains the declaration of the Device module.The signal connections should generally be correct for all butclock signals. The generated top file includes a SystemC clockwhich it ties to the OpenVera SystemClock. This clock shouldoften be tied to the SystemC modules clk signal and in thisexample the OpenVera interface clk signal.

3. The OpenVera runtime library expects a set of runtime

arguments. These are forwarded by the generated top file fromthe command line of the C++ executable using:

VeraSystemC::SetArguments(argc, argv)

where argc and argv are the arguments to sc_main. Thesearguments can of course be modified, and/or hard-wired at yourdiscretion but no modifications should be required.

4. Compile test_top.cpp. The top file should be compiled into a

test_top.ofile. The test_top.cpp includes test_shell.hwhichincludes header files stored in $VERA_HOME/include/systemc.These instructions are assuming $SYSTEMC has been set to thelocation of the users SystemC installation. This environmentvariable is not otherwise necessary. Using gcc, the command tocompile 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 compilingtest_top.cpp. The OpenVera include directory is of courseunnecessary.

8/8/2019 vera_ug3.0

61/515

2-29

Using Vera

6. Link the final executable. The executable should include theSystemC library, the OpenVera library for SystemC, test_top.oand the your SystemC code. The OpenVera library for SystemC

is located at $VERA_HOME/lib/systemc/libVERA.a. Dependingon the machine, additional system libraries may be required. Thecommands below assume the final executable will be calledrun.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 theOpenVera runtime. The OpenVera runtime expects to be told thelocation of vro files. The command to run OpenVera with justtest.vro would be:

run.x +vera_load=test.vro

8/8/2019 vera_ug3.0

62/515

2-30

Using Vera

Calling OpenVera Tasks from SystemC

The above description does not include imported and exported

functions. To call an OpenVera task from SystemC, you must prefixthe 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. OpenVeracalls 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 OpenVera

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

8/8/2019 vera_ug3.0

63/515

2-31

Using Vera

You must then write a task matching the generated extern

declarations.

8/8/2019 vera_ug3.0

64/515

2-32

Using Vera

8/8/2019 vera_ug3.0

65/515

3-1

Compiling and Running Testbenches

3Compiling and Running Testbenches 3

This 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

8/8/2019 vera_ug3.0

66/515

3-2


Compiler Command Line Options

The Vera compiler accepts two types of options: general options,

which do not involve the compilation of an OpenVera source codefile, and compilation options, which are used when compiling an

OpenVera source code file.

General Options

General 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 thereforeno Vera object files are created. The syntax to invoke the compiler is:

vera general_options [input_filename ]

general_optionsis one or more of the following:

-help

lists all the valid Vera executable options.

Option Definition

-help Lists valid Vera executable options

-pp Invokes the Vera preprocessor

-print Creates a PostScript file

-proj Creates Vera shell files from the project file

-rvm_version displays rvm version

-tem Invokes the Vera template generator

-v Returns the Vera compiler version

-V Prints complete version information

-vcon For multiple module support

-vmc Prints version information for the Vera virtual

machine.

8/8/2019 vera_ug3.0

67/515

3-3


-pp input_filename

invokes the Vera preprocessor on the input file. The preprocessor

output file is written to stdout.-D macro_name=valuespecifies 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 numberwhere numberis 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_versionRVM Class Library Version: 8.5.3

-tem verilog_filename

invokes the Vera template generator (see The Template

Generator on page 1-7).

-vprints the version number of the Vera installation. For example, a

version number will look similar to: 5.1.0

8/8/2019 vera_ug3.0

68/515

8/8/2019 vera_ug3.0

69/515

8/8/2019 vera_ug3.0

70/515

3-6


-ansi

preprocesses the Vera source code in ANSI mode.

-aop

supports Veras Aspect-Oriented Extensions. Users need to

adopt a methodology that partitions all introductionsand advice

in separate files from the class definitions, program blocks, etc.

Only introductionsand advicemay be present in such files.

These files must be compiled with the -aop switch. The -aopswitch may not be used on other Vera code blocks.

vera -cmp -aop cov1.vr

vera -cmp -aop cov2.vrvera -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 runtimeargument to the file names:

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.vrclass foo {

integer x;}// fooAop.vr:#include "foo.vrh"extends fooAop(foo) {

before task new() {printf("New called\n");

}}// top.vr:#include "foo.vrh"

8/8/2019 vera_ug3.0

71/515

3-7


// do not include fooAop.vrhprogram top {

foo f;f = new();

}compilation:

vera -cmp -HC foo.vrvera -cmp -aop fooAop.vrvera -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.vrtop.vrvera -cmp -f file.list -dep_check

Creating the .vrl file:

Option 1:

// object.vrl

// aop files must be firstfooAop.vrofoo.vrotop.vro

Option 2:

// object.vrl// must use +vera_aspects=fooAop.vro on simulation// command linefoo.vrotop.vro

SimulationOption 1:

vera_cs +vera_mload=object.vrl

8/8/2019 vera_ug3.0

72/515

3-8


Option 2:

vera_cs +vera_mload=object.vrl +vera_aspects=fooAop.vro

The vera_aspects runtime option applies to all OpenVera mainprograms. 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 theprogram's .vro list:

main Mastermaster_cov_aspect.vro ##coverage aspect for mastermaster.vro

main slaveslave_cov_aspect.vro ##coverage aspect for slaveslave.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 aninteger 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.

-D macro_name=value

specifies a text macro, where macro_nameis 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 whenusing conditional compilation directives.

8/8/2019 vera_ug3.0

73/515

3-9


-dep_check

Enables dependency analysis and incremental compilation.

Detects files with circular dependencies and issues an errormessage 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 includesa 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.vrchecker.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 absolutepathnames not be used within the list file when using -F.

Assuming file.list:

tb1.vrtb2.vr

8/8/2019 vera_ug3.0

74/515

3-10


The command,

vera -cmp -F $MY_FILES_DIR/files.list

results in Vera looking within the $MY_FILES_DIR for tb1.vrand tb2.vr.

Usage Note

More than one F option can be specified within a list file. Thiscan also be used in conjunction with f

Assume the following directory structure:

Rootdirfile.list

out // directoryrootdir/include

include.listtb1.vr

rootdir/librarylibrary.listtb2.vrtb3.vr

file.list-F include/include.list-F library/library.list

include.listtb1.vr

library.listtb2.vrtb3.vr

Compile Command:vera -cmp -HC -f file.list out

8/8/2019 vera_ug3.0

75/515

3-11


File List Structure

The following guidelines pertain to the contents of the list file. The

suggested naming convention is . The .list isnot required as the full name is specified when giving the f and

F options.

Rules

All Vera compiler options are supported when specified with asource file. (-h, -H, -HC, -hnu, -Hnu, -HCnu, -y, -F, -f, -max_error,-g, -I_skew, - q, -top, -I). These options only apply to the sourcefile 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 allsubsequent 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.

8/8/2019 vera_ug3.0

76/515

3-12


#file.listopts: -I..myfile.vropts: -I.

-HC foo.vr-h bar.vropts: -I../include -I../sourcetest.vrvera -cmp -f file.list

In the above example the following compilation steps occur:

vera -cmp -I.. myfile.vrvera -cmp -I. -HC foo.vrvera -cmp -I. -h bar.vrvera -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

-letc -HC packet.vr-y library

The above example generates the following compilation steps with a

single license checkout.

# all .vr files in library are compiledvera -cmp -I. -Ilibrary -y libraryvera -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

-Ietc -HC packet.vr out

8/8/2019 vera_ug3.0

77/515

3-13


Usage Notes

- Individual source options are applied in addition to the general

source options. Should a conflict exist between the generaland individual settings, a warning message is printed, and theindividual options override the general options

- The output directory or output file specified in the list file willoverride the generic output directory (what is given oncommand 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 // generates test.vrh filevera -cmp test.vr // generates test.vro file

8/8/2019 vera_ug3.0

78/515

3-14


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 compilergenerates an error message if you try to compile with both

switches.

Example 1

file: B.vrclass 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/////

Date post:	10-Apr-2018
Category:	Documents
Upload:	kuani-lee
View:	221 times
Download:	0 times

vera_ug3.0

Documents