CUSTOMER EDUCAT ION SERVICES
SystemVerilog Testbench Workshop
Student Guide 50-I-052-SSG-001 2005.06-SP1
Synopsys Customer Education Services
700 East Middlefield Road
Mountain View, California 94043
Workshop Registration: 1-800-793-3448
www.synopsys.com
Synopsys Customer Education Services
Copyright Notice and Proprietary Information Copyright 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 Documentation The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential
numbers to all copies. These copies shall contain the following legend on the cover page: “This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of __________________________________________ and its employees. This is copy number __________.”
Destination Control Statement All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to determine the applicable regulations and to comply with them.
Disclaimer SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®) Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™) 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, 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, 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, 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. Document Order Number: 50-I-052-SSG-001 SystemVerilog Testbench Student Guide
Table of Contents
Synopsys 50-I-052-SSG-001 i SystemVerilog Test Bench Workshop
Day 1
Unit i: Introduction & Overview
Introductions ..................................................................................................................... i-2
Facilities............................................................................................................................ i-3
Workshop Goal ................................................................................................................. i-4
Target Audience................................................................................................................ i-5
Workshop Prerequisites .................................................................................................... i-6
Agenda: Day 1 .................................................................................................................. i-7
Agenda: Day 2 .................................................................................................................. i-8
Agenda: Day 3 .................................................................................................................. i-9
Icons Used in this Workshop .......................................................................................... i-10
Unit 1: The Device Under Test (DUT)
Unit Objectives ................................................................................................................ 1-2
What Is the Device Under Test? ...................................................................................... 1-3
A Functional Perspective ................................................................................................. 1-4
The Router Description.................................................................................................... 1-5
Input Packet Structure...................................................................................................... 1-6
Output Packet Structure ................................................................................................... 1-7
Reset Signal ..................................................................................................................... 1-8
The DUT: router.v ........................................................................................................... 1-9
Unit Objectives Review ................................................................................................. 1-10
Unit 2: SystemVerilog Verification Environment
Unit Objectives ................................................................................................................ 2-2
What is Verification? ....................................................................................................... 2-3
Verification Goal ............................................................................................................. 2-4
Process of Reaching Verification Goal............................................................................ 2-5
The SystemVerilog Test Environment............................................................................. 2-6
SystemVerilog Testbench Building Process.................................................................... 2-7
Create Verilog Test Harness File..................................................................................... 2-8
Creating SystemVerilog Interface File ............................................................................ 2-9
Define Test Program Interface Port ............................................................................... 2-10
Build Testbench ............................................................................................................. 2-11
Sample Testbench .......................................................................................................... 2-12
Driving Synchronous Device Signals ............................................................................ 2-13
Sampling Synchronous Device Signals ......................................................................... 2-14
Table of Contents
Synopsys 50-I-052-SSG-001 ii SystemVerilog Test Bench Workshop
Advancing Simulation Time ......................................................................................... 2-15
Create SystemVerilog Harness File ............................................................................... 2-16
Complete Top Level Harness File ................................................................................. 2-17
Compile RTL & Simulate w/ VCS NTB ....................................................................... 2-18
SystemVerilog Run-Time Option .................................................................................. 2-19
Getting Help with VCS.................................................................................................. 2-20
Lab 1 Introduction ......................................................................................................... 2-21
Unit Objectives Review ................................................................................................. 2-22
Appendix........................................................................................................................ 2-23
Compiling and Running with VCS................................................................................ 2-24
Legacy Code Issues ....................................................................................................... 2-25
Testbench Debug: Getting Started ................................................................................ 2-26
Unit 3: SystemVerilog Language Basics
Unit Objectives ................................................................................................................ 3-2
SystemVerilog Testbench Code Structure ....................................................................... 3-3
SystemVerilog Lexical Convention................................................................................. 3-4
2-State Data Types (1/2) .................................................................................................. 3-5
2-State Data Types (2/2) .................................................................................................. 3-6
4-State Data Types (1/2) .................................................................................................. 3-7
4-State Data Types (2/2) .................................................................................................. 3-8
Floating Point Data Type................................................................................................. 3-9
String Data Type............................................................................................................ 3-10
Enumerated Data Types................................................................................................. 3-11
Data Arrays (1/4) ........................................................................................................... 3-12
Data Arrays (2/4) ........................................................................................................... 3-13
Data Arrays (3/4) ........................................................................................................... 3-14
Queue Manipulation Examples...................................................................................... 3-15
Data Arrays (4/4) ........................................................................................................... 3-16
Associate Array Examples............................................................................................. 3-17
Array Loop Support ....................................................................................................... 3-18
Array Locator Methods (1/4) ......................................................................................... 3-19
Array Locator Methods (2/4) ......................................................................................... 3-20
Array Locator Methods (3/4) ......................................................................................... 3-21
Array Locator Methods (4/4) ......................................................................................... 3-22
Recommended Usage Model ......................................................................................... 3-23
System Functions: Randomization ................................................................................ 3-24
User Defined Types and Type Cast ............................................................................... 3-25
Operators........................................................................................................................ 3-26
Know Your Operators! .................................................................................................. 3-27
Sequential Flow Control ................................................................................................ 3-28
Subroutines (task and function) ..................................................................................... 3-29
Subroutine Arguments ................................................................................................... 3-30
Test For Understanding ................................................................................................. 3-31
Table of Contents
Synopsys 50-I-052-SSG-001 iii SystemVerilog Test Bench Workshop
Scope and Lifetime Of Variables................................................................................... 3-32
Code Block Lifetime Controls ....................................................................................... 3-33
Unit Objectives Review ................................................................................................. 3-34
Appendix........................................................................................................................ 3-35
Import and Export Subroutines...................................................................................... 3-36
Packed Arrays ................................................................................................................ 3-37
Array Querying System Functions ................................................................................ 3-38
Array Querying System Functions Examples................................................................ 3-39
Data Structure ................................................................................................................ 3-40
Data Union ..................................................................................................................... 3-41
........................................................................................................................................ 3-42
Unit 4: Drive and Sample DUT Signals
Unit Objectives ................................................................................................................ 4-2
Driving & Sampling DUT Signals................................................................................... 4-3
SystemVerilog Testbench Timing ................................................................................... 4-4
SystemVerilog Scheduling .............................................................................................. 4-5
Synchronous Drive Statements ........................................................................................ 4-6
Synchronous Drive Example ........................................................................................... 4-7
Sampling Synchronous Signals ....................................................................................... 4-8
Signal Synchronization .................................................................................................... 4-9
Test For Understanding (1/2)......................................................................................... 4-10
Test For Understanding (2/2)......................................................................................... 4-11
Lab 2 Introduction ......................................................................................................... 4-12
Unit Objectives Review ................................................................................................. 4-13
Day 2
Unit 5: Concurrency
Unit Objectives ................................................................................................................ 5-2
Day 1 Review................................................................................................................... 5-3
Day 1 Review (Building Testbench Files)....................................................................... 5-4
Day 1 Review (Testbench Architecture) ......................................................................... 5-5
Concurrency in Simulators .............................................................................................. 5-6
Creating Concurrent Processes ........................................................................................ 5-7
How Many Child Processes? ........................................................................................... 5-8
Join Options ..................................................................................................................... 5-9
Process Execution .......................................................................................................... 5-10
Table of Contents
Synopsys 50-I-052-SSG-001 iv SystemVerilog Test Bench Workshop
Process Execution Model............................................................................................... 5-11
Subtleties in Concurrency (1/5) ..................................................................................... 5-12
Subtleties in Concurrency (2/5) ..................................................................................... 5-13
Subtleties in Concurrency (3/5) ..................................................................................... 5-14
Subtleties in Concurrency (4/5) ..................................................................................... 5-15
Subtleties in Concurrency (5/5) ..................................................................................... 5-16
Unroll the for-loop ......................................................................................................... 5-17
Solution (1/2): automatic Variable ................................................................................ 5-18
Solution (2/2): Wait Control .......................................................................................... 5-19
Disable Forked Processes .............................................................................................. 5-20
Helpful Debugging Features .......................................................................................... 5-21
Unit Objectives Review ................................................................................................. 5-22
Unit 6: Inter-Process Communications
Unit Objectives ................................................................................................................ 6-2
Inter-Process Communications (IPC) .............................................................................. 6-3
Event Based IPC .............................................................................................................. 6-4
Event Based IPC Example ............................................................................................... 6-5
Event Wait Syntax ........................................................................................................... 6-6
Trigger Syntax ................................................................................................................. 6-7
Controlling Termination of Simulation ........................................................................... 6-8
Resource Sharing IPC...................................................................................................... 6-9
Semaphores .................................................................................................................... 6-10
Semaphores .................................................................................................................... 6-11
Creating Semaphores ..................................................................................................... 6-12
Acquiring Semaphore Keys ........................................................................................... 6-13
Returning/Creating Semaphore Keys ............................................................................ 6-14
Arbitration Example ...................................................................................................... 6-15
Mailbox.......................................................................................................................... 6-16
Mailboxes....................................................................................................................... 6-17
Creating Mailboxes........................................................................................................ 6-18
Putting Messages into Mailboxes .................................................................................. 6-19
Retrieve Messages from Mailboxes (1/2) ...................................................................... 6-20
Retrieve Messages from Mailboxes (2/2) ...................................................................... 6-21
Lab 3 Introduction ......................................................................................................... 6-22
Unit Objectives Review ................................................................................................. 6-23
Table of Contents
Synopsys 50-I-052-SSG-001 v SystemVerilog Test Bench Workshop
Unit 7: OOP Encapsulation
Unit Objectives ................................................................................................................ 7-2
Abstraction Enhances Re-Usability of Code ................................................................... 7-3
OOP Encapsulation (OOP Class) .................................................................................... 7-4
Creating OOP Objects ..................................................................................................... 7-5
Accessing Object Members ............................................................................................. 7-6
Initialization of Object Properties.................................................................................... 7-7
OOP Data Hiding (Integrity of Data) .............................................................................. 7-8
Protect Against Unintentional Corruption ....................................................................... 7-9
Protect Against Data Corruption.................................................................................... 7-10
Working with Objects – Handle Assignment ................................................................ 7-11
Working with Objects – Garbage Collection................................................................. 7-12
Working with Objects – Static Properties...................................................................... 7-13
Best Practices (1/2) ........................................................................................................ 7-14
Best Practices (2/2) ........................................................................................................ 7-15
Unit Objectives Review ................................................................................................. 7-16
Appendix........................................................................................................................ 7-17
Virtual Interfaces .......................................................................................................... 7-18
Unit 8: OOP Randomization
Unit Objectives ................................................................................................................ 8-2
Why Randomization?....................................................................................................... 8-3
Alternatives to Exhaustive Testing? ................................................................................ 8-4
When Do We Apply Randomization? ............................................................................. 8-5
OOP Based Randomization ............................................................................................. 8-6
Randomization Example.................................................................................................. 8-7
Issues with Randomization .............................................................................................. 8-8
Distributed Constraints (1/2) .......................................................................................... 8-9
Distributed Constraints (2/2) ........................................................................................ 8-10
Array Constraint Support............................................................................................... 8-11
Implication and Order Constraints................................................................................. 8-12
Constraint Solver Order ................................................................................................ 8-13
Can randomize() Fail? ................................................................................................... 8-14
VCS Will Find Value if Solution Exist ......................................................................... 8-15
Effects of Calling randomize()....................................................................................... 8-16
Applying pre_randomize()............................................................................................. 8-17
Applying post_randomize() ........................................................................................... 8-18
Inline Constraints ........................................................................................................... 8-19
Controlling rand Property Randomization..................................................................... 8-20
Selective Randomization of Properties.......................................................................... 8-21
Controlling Constraint at Runtime................................................................................. 8-22
Table of Contents
Synopsys 50-I-052-SSG-001 vi SystemVerilog Test Bench Workshop
Nested Objects with Random Variables ........................................................................ 8-23
Lab 3 Introduction ......................................................................................................... 8-24
Unit Objectives Review ................................................................................................. 8-25
Day 3
Unit 9: OOP Inheritance
Unit Objectives ................................................................................................................ 9-2
Object Oriented Programming: Inheritance..................................................................... 9-3
Object Oriented Programming: Inheritance..................................................................... 9-4
OOP: Polymorphism........................................................................................................ 9-5
OOP: Polymorphism........................................................................................................ 9-6
Data Protection: Local ..................................................................................................... 9-7
Data Protection: Protected ............................................................................................... 9-8
Test For Understanding ................................................................................................... 9-9
Test For Understanding: Answer ................................................................................... 9-10
Test For Understanding: Solution.................................................................................. 9-11
Unit Objectives Review ................................................................................................. 9-12
Unit 10: Functional Coverage
Unit Objectives .............................................................................................................. 10-2
Phases of Verification.................................................................................................... 10-3
The Testbench Environment/Architecture..................................................................... 10-4
Combinational Logic Example ...................................................................................... 10-5
State Transition Example............................................................................................... 10-6
Cross Correlation Example ............................................................................................ 10-7
Functional Coverage in SystemVerilog......................................................................... 10-8
Functional Coverage Example....................................................................................... 10-9
State Bin Creation (Automatic) ................................................................................... 10-10
Measuring Coverage .................................................................................................... 10-11
Automatic State Bin Creation Example....................................................................... 10-12
State and Transition Bin Creation (User) .................................................................... 10-13
Cross Coverage Bin Creation (Automatic) .................................................................. 10-14
Specifying Sample Event Timing ................................................................................ 10-15
Determining Coverage Progress .................................................................................. 10-16
Coverage Measurement Example ................................................................................ 10-17
Coverage Attributes ..................................................................................................... 10-18
Major Coverage Options (1/2) ..................................................................................... 10-19
Table of Contents
Synopsys 50-I-052-SSG-001 vii SystemVerilog Test Bench Workshop
Major Coverage Options (2/2) ..................................................................................... 10-20
Coverage Result Reporting Utilities ............................................................................ 10-21
Sample HTML Report ................................................................................................. 10-22
Lab 6 Introduction ....................................................................................................... 10-23
Unit Objectives Review ............................................................................................... 10-24
Unit 11: RVM-SV (VMM) Overview
Unit Objectives .............................................................................................................. 11-2
Coverage-Driven Verification ....................................................................................... 11-3
The Testbench Environment/Architecture..................................................................... 11-4
Testbench Considerations: Abstraction ......................................................................... 11-5
Testbench Considerations: Re-Use................................................................................ 11-6
What Does RVM-SV Provide?...................................................................................... 11-7
RVM-SV Base Classes and Macros .............................................................................. 11-8
RVM Guiding Principles ............................................................................................... 11-9
Implementing RVM Testbench.................................................................................... 11-10
Environment Execution Flow ...................................................................................... 11-11
Execution Flow – Under the hood ............................................................................... 11-12
Example: Basic RVM Environment ............................................................................ 11-13
Testing Basic RVM Environment................................................................................ 11-14
Example: RVM Test Configuration............................................................................. 11-15
Testing RVM Configuration........................................................................................ 11-16
Set Specific RVM Testcase Configuration.................................................................. 11-17
Example: RVM Stimulus Generation .......................................................................... 11-18
Testing RVM Atomic Generator ................................................................................. 11-19
Example: RVM Transactor Class ................................................................................ 11-20
Example: RVM Coverage (Callbacks) ........................................................................ 11-21
RVM Coverage Continued .......................................................................................... 11-22
RVM Coverage Continued .......................................................................................... 11-23
Testing RVM Coverage ............................................................................................... 11-24
Example: Implementing RVM Scoreboard ................................................................. 11-25
Example: RVM Scoreboard Continued ....................................................................... 11-26
RVM Scoreboard Callbacks ........................................................................................ 11-27
RVM Scoreboard Callbacks ........................................................................................ 11-28
Summary: RVM Guiding Principles............................................................................ 11-29
Unit Objectives Review ............................................................................................... 11-30
Appendix...................................................................................................................... 11-31
RVM-OV vs. RVM-SV ............................................................................................... 11-32
Planning for RVM-SV ................................................................................................. 11-41
Table of Contents
Synopsys 50-I-052-SSG-001 viii SystemVerilog Test Bench Workshop
Customer Support
Synopsys Support Resources ........................................................................................ CS-2
SolvNet Online Support Offers: ................................................................................... CS-3
SolvNet Registration is Easy ........................................................................................ CS-4
Support Center: AE-based Support............................................................................... CS-5
Other Technical Sources ............................................................................................... CS-6
Summary: Getting Support ........................................................................................... CS-7
Introduction & Overview
SVTB
i-1© 2006
Synopsys Customer Education Services© 2006 Synopsys, Inc. All Rights Reserved Synopsys 50-I-052-SSG-001
System VerilogTestbench
VCS 2005.06-SP1
Introduction & Overview
SVTB
i-2© 2006
2i-
Introductions
� Name
� Company
� Job Responsibilities
� EDA Experience
� Main Goal(s) and Expectations for this Course
EDA = Electronic Design Automation
Introduction & Overview
SVTB
i-3© 2006
3i-
Facilities
Building Hours
Restrooms
Meals
Messages
Smoking
Recycling
Phones
Emergency EXIT
Please turn off cell phones and pagers
Introduction & Overview
SVTB
i-4© 2006
4i-
Workshop Goal
Acquire the skills to write a SystemVerilog
testbench to verify Verilog/SystemVerilog RTL
code with coverage-driven random stimulus.
Introduction & Overview
SVTB
i-5© 2006
5i-
Target Audience
Design or Verification engineers
writing SystemVerilog testbenches
to verify Verilog or SystemVerilog code.
Introduction & Overview
SVTB
i-6© 2006
6i-
Workshop Prerequisites
� You must have experience in the following areas:
� Familiarity with a UNIX text editor
� Basic programming skills in Verilog, VHDL or C
� Debugging experience with Verilog, VHDL or C
Introduction & Overview
SVTB
i-7© 2006
7i-
Agenda: Day 1
DAY
1111
SystemVerilog Verification Environment2
The Device Under Test (DUT)1
SystemVerilog Language Basics3
Drive and Sample DUT Signals4
Introduction & Overview
SVTB
i-8© 2006
8i-
Agenda: Day 2
Object Oriented Programming (OOP)
– Encapsulation7
Concurrency5
DAY
2222
Object Oriented Programming (OOP)
– Randomization8
Inter-Process Communications6
Introduction & Overview
SVTB
i-9© 2006
9i-
Functional Coverage10
Customer SupportCS
9Object Oriented Programming (OOP)
– Inheritance
Agenda: Day 3
DAY
3333
SystemVerilog RVM (VMM) Overview11
Introduction & Overview
SVTB
i-10© 2006
10i-
Lab Exercise Caution
RecommendationDefinition of
Acronyms
For Further Reference
“Under the Hood”
InformationGroup Exercise
Question
Icons Used in this Workshop
!
Lab Exercise: A lab is associated with this unit, module, or concept.
Recommendation: Recommendations to the students, tips, performance boost, etc.
For Further Reference: Identifies pointer or URL to other references or resources.
Under the Hood Information: Information about the internal behavior of the tool.
Caution:Warnings of common mistakes, unexpected behavior, etc.
Definition of Acronyms: Defines the acronym used in the slides.
Question: Marks questions asked on the slide.
Group Exercise: Test for Understanding (TFU), which requires the students to work in groups.
The Device Under Test (DUT)
SVTB
1-1© 2006
11-
Agenda
DAY
1111
SystemVerilog Verification Environment2
The Device Under Test (DUT)1
SystemVerilog Language Basics3
Drive and Sample DUT Signals4
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
The Device Under Test (DUT)
SVTB
1-2© 2006
21-
Unit Objectives
After completing this unit, you should be able to:
� Describe the function of the Device Under Test
(DUT)
� Identify the control and data signals of the DUT
� Draw timing diagram for sending and receiving
a packet of data through the DUT
The Device Under Test (DUT)
SVTB
1-3© 2006
31-
What Is the Device Under Test?
A router:
16 x 16 crosspoint switch
router
din [15:0] dout [15:0]
frame_n[15:0] frameo_n [15:0]
valido_n [15:0]
reset_n
valid_n [15:0]
clock
The router has 16 input and 16 output ports. Each input and output port consists of 3 signals, serial data, frame and valid. These signals are represented in a bit-vector format, din[15:0], frame_n[15:0], valid_n[15:0], dout[15:0], frameo_n[15:0] and valido_n[15:0].
To drive an individual port, the specific bit position corresponding to the port number must be specified. For example, if input port 3 is to be driven, then the corresponding signals shall be din[3], frame_n[3] and valid_n[3].
To sample an individual port, the specific bit position corresponding to the port number must be specified. For example, if output port 7 is to be sampled, then the corresponding signals shall be dout[7], frameo_n[7] and valido_n[7].
The Device Under Test (DUT)
SVTB
1-4© 2006
41-
0
1
2
3
4
port port
inputs outputs
frame_n[0]
valid_n[0]
din[0]
frameo_n[0]
valido_n[0]
dout[0]
A Functional Perspective
partial view
0
1
2
3
4
The Device Under Test (DUT)
SVTB
1-5© 2006
51-
The Router Description
� Single positive-edge clock
� Input and output data are serial (1 bit / clock)
� Packets are sent through in variable length:
� Each packet is composed of two parts
� Header
� Payload
� Packets can be routed from any input port to any
output port on a packet-by-packet basis
� No internal buffering or broadcasting (1-to-N)
The Device Under Test (DUT)
SVTB
1-6© 2006
61-
Input Packet Structure
� frame_n:
� Falling edge indicates first bit of packet
� Rising edge indicates last bit of packet
� din:
� Header (destination address & padding bits) and payload
� valid_n:
� valid_n is low if payload bit is valid, high otherwise
clock
din[i] A0 A3A2A1
valid_n[i]
d0 ....x dndn-1 x
frame_n[i]
pad payload
x
x x x x x
dest. address
The Device Under Test (DUT)
SVTB
1-7© 2006
71-
Output Packet Structure
clock
dout[i]
valido_n[i] x
dn-3 xx
frameo_n[i]
x
dn-2 dn-1xd1d0 x xd2x d3
� Output activity is indicated by:
frameo_n, valido_n, and dout
� Data is valid only when:
� frameo_n output is low (except for last bit)
� valido_n output is low
� Header field is stripped
The Device Under Test (DUT)
SVTB
1-8© 2006
81-
Reset Signal
� While asserting reset_n, frame_n and valid_n
must be de-asserted
� reset_n is asserted for at least one clock cycle
� After de-asserting reset_n, wait for 15 clocks
before sending a packet through the router
clock
reset_n
frame_n[i]
15 clock cycles
During these 15 clock cycles, the router is performing self-initialization. If you attempt to drive a packet through the router during this time, the self-initialization will fail and the router will not work correctly afterwards.
The Device Under Test (DUT)
SVTB
1-9© 2006
91-
The DUT: router.v
� The Design Under Test, router.v, is a Verilog file:
� Located under the rtl directory
� From the lab workspace: ../../rtl/router.v
router.vlab1/ lab2/ lab6/
lab work files
lab1/ lab6/
solutions/labs/ rtl/
~
The Device Under Test (DUT)
SVTB
1-10© 2006
101-
Unit Objectives Review
Having completed this unit, you should be able to:
� Describe the function of the Device Under Test (DUT)
� Identify the control and data signals of the DUT
� Draw timing diagram for sending and receiving
a packet of data through the DUT
SystemVerilog Verification EnvironmentSVTB
2-1© 2006
12-
Agenda
DAY
1111
SystemVerilog Verification Environment2
The Device Under Test (DUT)1
SystemVerilog Language Basics3
Drive and Sample DUT Signals4
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
SystemVerilog Verification EnvironmentSVTB
2-2© 2006
22-
Unit Objectives
After completing this unit, you should be able to:
� Describe the process of reaching verification
goals
� Create templates for a SystemVerilog testbench
� Use these templates as a starting point for
writing SystemVerilog testbench code
� Compile and simulate SystemVerilog testbench
SystemVerilog Verification EnvironmentSVTB
2-3© 2006
32-
What is Verification?
Verification is the process of verifying the transformation
steps in the design flow are executed correctly.
Algorithm
Architecture/
Spec RTL Gate GDSII ASIC
End
productIdea
Product
Acceptance
Test
Transformations
C-Model
Spec
Acceptance
Review
Simulation/
Code Review
Formal Functional/
Timing
Verification ATE
Sign-Off
Review
SystemVerilog Verification EnvironmentSVTB
2-4© 2006
42-
Verification Goal
� Ensure full conformance with specification:
� Must avoid false positives (untested functionalities)
???Pass
Fail
Good Bad(bug)
RTL code
√√√√Tape out!
Debug
testbench
Debug
RTL code
Testbench
Simulation
result
False positive results in shipping
a bad design
How do we achieve this goal?
SystemVerilog Verification EnvironmentSVTB
2-5© 2006
52-
Process of Reaching Verification Goal
Phases of verification
Time
Goal
Build verification environment
Broad-SpectrumVerification
PreliminaryVerification
Difficult to reachCorner-caseVerification
Corner-caseVerification
% Coverage
The process of reaching the verification goal starts with the definition of the verification goal.
What does it mean to be done with testing? Typically, the answer lie in the functional coverage spec within a verification plan. The goal is then to reach 100% coverage of the defined functional coverage spec in the verification plan.
Once the goal has been defined, the first step in constructing the testbench is to build the verification environment.
To verify the the environment is set up correctly, preliminary verification tests are usually executed to wring out the rudimentary RTL and testbench errors.
When the testbench environment is deemed to be stable, broad-spectrum verification based on random stimulus generation is utilized to quickly detect and correct the majority of the bugs in both RTL code and testbench code.
Based on functional coverage analysis, the random-based tests are then constrained to focus on corner-cases not yet reached via broad-spectrum testing.
Finally, for the very difficult to reach corner cases, customized directed tests are used to bring the coverage up to 100%.
Verification is complete when you reach 100% coverage as defined in the verification plan.
SystemVerilog Verification EnvironmentSVTB
2-6© 2006
62-
The SystemVerilog Test Environment
Testprogram
interface
Monitor
TransactorSelf Check
Observes datafrom DUT
Identifiestransactions
Checkscorrectness
Coverage
Driver
Generator
DUT
Transactor
ConfigureChecks
completeness
Top level harness file
SystemVerilog Verification EnvironmentSVTB
2-7© 2006
72-
SystemVerilog Testbench Building Process
simv
router.vr.tmp
ntb_template -t router router.v
router.if.vrh
router.test_top.sv
Discard
vcs –sverilog router.test_top.sv router.tb.sv router.if.sv router.v
router.if.sv router.tb.sv
Top level harness Interface Test program
router.test_top.v
router.v
SystemVerilog Verification EnvironmentSVTB
2-8© 2006
82-
Create Verilog Test Harness File
� Use VCS template generator
� Generates three files:
� router.test_top.v Verilog test harness file
� router.if.vrh Discard (for OpenVera only)
� router.vr.tmp Discard (for OpenVera only)
� -t router Specifies DUT module name
� router.v DUT source code file
� router.test_top.v will be used to help build
SystemVerilog testbench files
ntb_template -t router router.v
router.v must be the last entry in the ntb_template command.
SystemVerilog Verification EnvironmentSVTB
2-9© 2006
92-
interface router_io(input logic clock);
logic reset_n ;
logic [15:0] din ;
//wire clock;
logic [15:0] frame_n ;
logic [15:0] valid_n ;
logic [15:0] dout ;
logic [15:0] busy_n ;
logic [15:0] valido_n ;
logic [15:0] frameo_n ;
endinterface
module router_test_top;
parameter simulation_cycle = 100;
reg SystemClock ;
wire reset_n ;
wire [15:0] din ;
wire clock ;
wire [15:0] frame_n ;
wire [15:0] valid_n ;
wire [15:0] dout ;
wire [15:0] busy_n ;
wire [15:0] valido_n ;
wire [15:0] frameo_n ;
`ifdef SYNOPSYS_NTB
...
`endif
router dut( … );
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
endmodule
Creating SystemVerilog Interface File
� Create interface file from router.test_top.v
� Encapsulate signals in interface block
router.test_top.v
Move clock to
input argument
cp router.test_top.v router.if.sv
Change wire to logic
router.if.sv
Create from default harness fileChange module to interface
Delete all except wires
SystemVerilog Verification EnvironmentSVTB
2-10© 2006
102-
Define Test Program Interface Port
� By default all interface signals are asynchronous
� Synchronous signals can be created via clocking
block and connected to test program via modport
interface router_io(input logic clock);
logic reset_n ;
logic [15:0] din ;
logic [15:0] frame_n ;
logic [15:0] valid_n ;
logic [15:0] dout ;
logic [15:0] busy_n ;
logic [15:0] valido_n ;
logic [15:0] frameo_n ;
clocking cb @(posedge clock);
default input #1 output #1;
output reset_n;
output din;
output frame_n;
output valid_n;
input dout;
input busy_n;
input valido_n;
input frameo_n;
endclocking
modport TB(clocking cb, output reset_n);
endinterface
Create synchronous
by placing signals into clocking block
Define connection
for test program with modport
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
Direction w/respect to test
Synchronous Asynchronous
router.if.sv
Sample/drive skew
If unspecified, the sample and drive skew defaults to:
default input #1 output #0;
SystemVerilog Verification EnvironmentSVTB
2-11© 2006
112-
program automatic router_test(router_io.TB router);
// develop test code in initial block:
initial begin
$vcdpluson; // Dumping file control
$display(“Hello World”);
end
endprogram
Build Testbench
� Testbench is encapsulated in program block
� List interface signals in argument
router.tb.sv
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
Both synchronous and
asynchronous signals are encapsulated in modport
SystemVerilog Verification EnvironmentSVTB
2-12© 2006
122-
program automatic router_test(router_io.TB router);
//testbench code in initial block:
initial begin
$vcdpluson; // Dumping file control
// $display(“Hello World”);
end
initial begin
reset();
end
task reset();
router.reset_n <= 1’b0;
router.cb.frame_n <= 16’hffff;
router.cb.valid_n <= ~(’b0);
##2 router.cb.reset_n <= 1’b1; // reset_n can be both synchronous and asynchronous
repeat(15) @(router.cb);
endtask
endprogram
Sample Testbench
� Develop test program code in initial block
interface router_io(input logic clock);
logic reset_n ;
logic [15:0] din ;
logic [15:0] frame_n ;
logic [15:0] valid_n ;
...
clocking cb @(posedge clock);
default input #1 output #1;
output reset_n;
output din;
output frame_n;
output valid_n;
...
endclocking
modport TB(clocking cb, output reset_n);
endinterface
Asynchronous signals are
driven without reference to
clocking block
Advance clock cycles
via clocking block
Synchronous signals are
driven via clocking block
SystemVerilog Verification EnvironmentSVTB
2-13© 2006
132-
Driving Synchronous Device Signals
� Must be driven with <= (non-blocking assignment)
� Can be specified with ##num of clocks delay
Equivalent to:repeat(num) @(router.cb);
router.din[3] <= #input_skew_value var_a;
router.cb.din[3] = 1’b1; // error (must be non-blocking)
var_a
din[3]
##1 router.cb.din[3] <= var_a;
clock
Statement executes here Variable expression evaluates
Apply drive here Next statement executes
[##num] interface.cb.signal <= <value> or <variable expression>;
SystemVerilog Verification EnvironmentSVTB
2-14© 2006
142-
Sampling Synchronous Device Signals
� No delay attribute (## num)
� Variable is assigned the sampled value
� Sampling of output signal is not allowed
Examples:
data[i] = router.cb.dout[7];
all_data = router.cb.dout;
@(posedge router.cb.frameo_n[7]);
$display(“router.cb.din = %b\n”, router.din); //error
if(router.cb.din[3] == 1’b0) //error
variable = interface.cb.signal;
SystemVerilog Verification EnvironmentSVTB
2-15© 2006
152-
Advancing Simulation Time
� Asynchronous (Verilog coding style):
#delay;
@(negedge interface.signal);
� Synchronous (advancing clock cycles):
� Verilog coding style:
@(posedge interface.clock_signal);
repeat (10) @(posedge interface.clock_signal);
� SystemVerilog coding style (clocking block):
@(interface.clocking_block);
repeat (10) @(interface.clocking_block);
� Each clocking block specifies a clock signal and edge:
interface router_io(input logic clock);
clocking cb @(posedge clock);
...
endclocking
endinterface
In order for the syntax @(posedge interface.clock_signal); to work. The clock_signal must be passed in as an additional asynchronous signal argument to the modport for the test program connection:
interface router_io(input logic clock);
logic reset_n ;
logic [15:0] din ;
logic [15:0] frame_n ;
logic [15:0] valid_n ;
logic [15:0] dout ;
logic [15:0] busy_n ;
logic [15:0] valido_n ;
logic [15:0] frameo_n ;
clocking cb @(posedge clock);
default input #1 output #1;
output reset_n;
output din;
output frame_n;
output valid_n;
input dout;
input busy_n;
input valido_n;
input frameo_n;
endclocking
modport TB(clocking cb, output reset_n, input clock);endinterface
SystemVerilog Verification EnvironmentSVTB
2-16© 2006
162-
module router_test_top;
parameter simulation_cycle = 100;
reg SystemClock ;
wire reset_n ;
wire clock ;
wire [15:0] frame_n ;
wire [15:0] valid_n ;
wire [15:0] din ;
wire [15:0] dout ;
wire [15:0] busy_n ;
wire [15:0] valido_n ;
wire [15:0] frameo_n ;
`ifdef SYNOPSYS_NTB
...
`endif
router dut( … );
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
endmodule
Create SystemVerilog Harness File
� Create harness file from router.test_top.v
router.test_top.sv
mv router.test_top.v router.test_top.sv
module router_test_top;
parameter simulation_cycle = 100;
reg SystemClock ;
router dut( … );
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
endmodulerouter.test_top.sv
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
Delete all wire declarations and all OpenVera stuff
SystemVerilog Verification EnvironmentSVTB
2-17© 2006
172-
module router_test_top;
parameter simulation_cycle = 100;
reg SystemClock ;
router dut(
.reset_n(reset_n),
.clock(clock),
.frame_n(frame_n),
.valid_n(valid_n),
.din(din),
.dout(dout),
.busy_n(busy_n),
.valido_n(valido_n),
.frameo_n(frameo_n));
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
endmodule
Complete Top Level Harness File
� Instantiate test program and interface in harness file
router.test_top.sv
module router_test_top;
parameter simulation_cycle = 100;
reg SystemClock;
router_io top_io(SystemClock);
router_test test(top_io);
router dut(.reset_n(top_io.reset_n),
.clock(top_io.clock),
.frame_n(top_io.frame_n),
.valid_n(top_io.valid_n),
.din(top_io.din),
.dout(top_io.dout),
.busy_n(top_io.busy_n),
.valido_n(top_io.valido_n),
.frameo_n(top_io.frameo_n));
initial begin
SystemClock = 0 ;
forever begin
#(simulation_cycle/2)
SystemClock = ~SystemClock ;
end
end
endmodule
Instantiate
interface
Instantiate
test program
Connect SystemClock
to interface block
Update DUT
instantiation using
interface connection
If the DUT module was already constructed with SystemVerilog interface, the connection would simplify to:
router dut(top_io);
SystemVerilog Verification EnvironmentSVTB
2-18© 2006
182-
Compile RTL & Simulate w/ VCS NTB
� Compile HDL code: (generate simv simulation binary)
> vcs –sverilog [-debug] router.test_top.sv \
router.tb.sv router.if.sv router.v
� Get vcs compiler switch summary:
> vcs -help
� Simulate DUT with SystemVerilog testbench: (running simv)
> ./simv
router.test_top.svMonitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
router.tb.sv
router.if.sv
router.v
SystemVerilog Verification EnvironmentSVTB
2-19© 2006
192-
SystemVerilog Run-Time Option
� Set SystemVerilog run-time option with +argument
� Retrieve +argument value with $value$plusargs()
> ./simv +ntb_random_seed=100
User seed is 100
initial begin
int user_seed;
if ($value$plusargs("ntb_random_seed=%d", user_seed))
$display(“User seed is %d", user_seed);
else
$display(“Using default seed");
end
SystemVerilog Verification EnvironmentSVTB
2-20© 2006
202-
Getting Help with VCS
� Get vcs compiler switch summary:
shell> vcs -help
� Read vcs manuals:
shell> vcs –doc
� Examples
� $VCS_HOME/doc/examples
� Email Support:
� On-line knowledge database
� http://solvnet.synopsys.com
� SystemVerilog LRM
� www.Accellera.org or
� www.eda.org/sv
SystemVerilog Verification EnvironmentSVTB
2-21© 2006
212-
DUT
Lab 1 Introduction
30 min
Build Simulation
Environment
program automatic router_test;
initial begin
$vcdpluson;
$display(“Hello”);
end
initial begin
reset();
end
task reset(); ...
endprogram
Generate Template Files
Write Test Code
Compile & Simulate
SystemVerilog Verification EnvironmentSVTB
2-22© 2006
222-
Unit Objectives Review
Having completed this unit, you should be able to:
� Describe the process of reaching verification goals
� Create templates for a SystemVerilog testbench
� Use these templates as a starting point for writing
SystemVerilog testbench code
� Compile and simulate SystemVerilog testbench
SystemVerilog Verification EnvironmentSVTB
2-23© 2006
Appendix
Useful VCS compile and run time switches
Debugging with DVE & Testbench Debugger
SystemVerilog Verification EnvironmentSVTB
2-24© 2006
242-
� Compile:vcs -sverilog –debug top.sv test.sv dut.sv
� -sverilog Enable SystemVerilog constructs
� -debug Enable debug except line stepping
� -debug_all Enable debug including line stepping
� Run:
simv +user_tb_runtime_options
� -l logfile Create log file
� -gui Run GUI
� -ucli Run with new command line debugger
� -i cmd.key Execute UCLI commands
Compiling and Running with VCS
See the VCS User Guide for all options
SystemVerilog Verification EnvironmentSVTB
2-25© 2006
252-
� SystemVerilog has dozens of new reserved keywords such as bit, packed, logic that might conflict with existing Verilog code
� Keep your Verilog-2001 code separate from SystemVerilog
code and compile with:
vcs –sverilog new.v +verilog2001ext+.v2k old.v2k
� or
vcs +systemverilogext+.sv old.v new.sv
Legacy Code Issues
// Old Verilog-1995/2001 legacy code
integer bit, count;initial begin
count = 0;
for (bit = 0; bit < 8; bit = bit + 1)
if (adrs[bit] === 1'bx)
count = count + 1;
end
SystemVerilog Verification EnvironmentSVTB
2-26© 2006
262-
Testbench Debug: Getting Started
� Invoke DVE
� Start separate testbench debugger
� Simulator -> TB-Debugger
> simv -guiNeed VCS
2005.06-6
SystemVerilog Verification EnvironmentSVTB
2-27© 2006
272-
Testbench Debug: Getting Started
� The testbench debugger is separate from DVE
� TB_Debugger > Enable
� Testbench window will open when simulator starts
� Default = off
� Option is saved from one session to the next
� TB_Debugger > Debug on Error
� Testbench window will open upon error
� Default = off
� TB_Debugger > Start
� Testbench window will open at start of Simulator
� Default = off
� Simulator > Start
� Starts simulator
� Testbench debugger window will open depending whether or not TB_Debugger.Debug_on_start or TB_Debugger.Start is set
SystemVerilog Verification EnvironmentSVTB
2-28© 2006
282-
Testbench Debug: Getting Started
� Testbench Debugger window
Watch
variables
Source
code
tracing
Active
threads
Local
variables
SystemVerilog Language BasicsSVTB
3-1© 2006
13-
Agenda
DAY
1111
SystemVerilog Verification Environment2
The Device Under Test (DUT)1
SystemVerilog Language Basics3
Drive and Sample Signals4
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
SystemVerilog Language BasicsSVTB
3-2© 2006
23-
Unit Objectives
After completing this unit, you should be able to:
� Define the structure of a SystemVerilog program
� Declare variables in a SystemVerilog program
� Describe variable visibility in program, local blocks and sub-routines
� Use flow control constructs to implement SystemVerilog verification testbench
SystemVerilog Language BasicsSVTB
3-3© 2006
33-
SystemVerilog Testbench Code Structure
� Test code is embedded inside program block
� program code is instantiated in the top-level harness fileprogram automatic router_test ( … );
initial begin
$vcdpluson;
reset();
end
task reset();
router.reset_n <= 1'b0;
router.cb.frame_n <= ~('b0);
...
endtask
endprogram
// root global variablesprogram [automatic] name(interface);// `include files// program global variablesinitial begin// local variables// top-level test code
endtask task_name(…);// local variables// code
endtaskendprogram
From Lab 1:
module router_test_top;
router_io top_io(SystemClock);
router_test test(top_io);
router dut(.reset_n (top_io.reset_n),
.clock (top_io.clock),
.… (top_io.…));
…;
endmodule
SystemVerilog Language BasicsSVTB
3-4© 2006
43-
SystemVerilog Lexical Convention
� Same as Verilog
� Case sensitive
� White Spaces are ignored except within strings
� Comments:
� // …
� /* … */ (Do not nest!) /* /* */ */
� Number Format:<size>’<base><number>
’b (binary) :[01xXzZ]
’d (decimal) :[0123456789]
’o (octal) :[01234567xXzZ]
’h (hexadecimal) :[0123456789abcdefABCDEFxXzZ]
� Can be padded with ‘_’ for readability:16’b_1100_1011_1010_0010
32’h_beef_cafe
SystemVerilog Language BasicsSVTB
3-5© 2006
53-
2-State Data Types (1/2)
� 2 state logic (0, 1)
� Variable initialized to ’0 if initial_value is not specified
� Defaults to 0 for x or z values
bit [msb:lsb] variable_name [=initial_value];
� Sized as specified
� Defaults to unsigned
byte variable_name [=initial_value];
� 8-bit data type
� Defaults to signed
Examples:
bit flag; bit[15:0] sample, temp = 16’hdeed;
byte a = -55, b;
byte unsigned ref_data = ’hff;
Explicit 2-state variables allow more compiler optimizations, giving better performance.
BUT – they will not propagate X or Z, so keep away from DUT
SystemVerilog Language BasicsSVTB
3-6© 2006
63-
2-State Data Types (2/2)
shortint variable_name [=initial_value];
� 16-bit data type
� Defaults to signed
int variable_name [=initial_value];
� 32-bit data type
� Defaults to signed
longint variable_name [=initial_value];
� 64-bit data type
� Defaults to signed
Examples:
shortint temp = 256;
int sample, ref_data = -9876;
longint a, b; longint unsigned testdata;
SystemVerilog Language BasicsSVTB
3-7© 2006
73-
4-State Data Types (1/2)
� 4 state logic (0, 1, x or z)
� Variable initialized to ’x if initial_value is not specified
reg [msb:lsb] variable_name [=initial_value];
� Sized as specified
� Defaults to unsigned
� Used when 4-state retention for sampled signal is required
integer variable_name [=initial_value];
� 32-bit data type
� Defaults to signed
Examples:
integer temp = ’1, ref_data = ’x;
reg[15:0] sample;
sample = router.cb.dout[da];
SystemVerilog Language BasicsSVTB
3-8© 2006
83-
4-State Data Types (2/2)
logic [msb:lsb] variable_name [=initial_value];
� Sized as specified
� Defaults to unsigned
� Used for general I/O connections
time variable_name [=initial_value];
� 64-bit unsigned integer
Examples:
interface router_io(input logic clock);
logic reset_n;
logic [15:0] din; ...;
endinterface
time start_time = $time;
In SystemVerilog, the old reg type has been extended so it can be driven by single drivers (gates, modules, continuous assignments) like a wire. It has a new name logic. It can not have multiple drivers – use a wire.
SystemVerilog Language BasicsSVTB
3-9© 2006
93-
Floating Point Data Type
� Real number variables:
� Variable initialized to 0.0 if initial_value is not specified
real variable_name [=initial_value];
(Equivalent to double in C)
� Used as functional coverage return value
Example:
real alpha, beta, coverage_result;
alpha = 100.3;
beta = alpha;
coverage_result = $get_coverage();
if (coverage_result == 100) ...;
SystemVerilog Language BasicsSVTB
3-10© 2006
103-
String Data Type
� Strings:
� Variable initialized to “” if initial_value is not specified
string variable_name [=initial_value];
� Can be created with $psprintf() VCS system function
� Built-in operators and methods:
� ==, !=, compare() and icompare()
� itoa(), atoi(), atohex(), toupper(), tolower(), etc.
� len(), getc(), putc(), substr() (See manual for more)
Example:string name, s = “Now is the time”;
for (int i=0; i<4; i++) begin
name = $psprintf(“string%0d”, i);
$display(“%s, upper: %s”, name, name.toupper());
end
s.putc(s.len()-1, s.getc(0)); // change e->s
$display(s.substr(s.len()-4, s.len()-1));
The resulting print out on terminal is:
string0, upper: STRING0
string1, upper: STRING1
string2, upper: STRING2
string3, upper: STRING3
tims
SystemVerilog Language BasicsSVTB
3-11© 2006
113-
Enumerated Data Types
� Create enumerated data types:
� Data type defaults to int
� Variable initialized to ’0 if initial_value is not specified
� enum variables can be displayed as ascii with .name property
typedef enum [data_type] {named constants} enumtype;
� Create enum variables:
enum [data_type] {named constants} enumvar, …;
enumtype variable_name [=initial_value];
Example:
typedef enum {IDLE, TEST, START} state;
enum bit[2:0] {S0=’b001, S1=’b010, S2=’b100} st;
state c_st, n_st = IDLE;
$display(“st = %3b, n_st = %s”, st, n_st.name);
Variable creation
What will be displayed on screen?
Type creation
What’s printed to screen:
st = 0, n_st = IDLE
The reason st is printed as 0 is because enum variables default to 0 if not initialized or assigned an enum value.
SystemVerilog Language BasicsSVTB
3-12© 2006
123-
Data Arrays (1/4)
� Fixed-size Arrays:
type array_name[size] [=initial_value];
� Out-of-bounds write ignored
� Out-of-bounds read returns ’0 for 2state, ’x for 4state arrays
� Multiple dimensions are supported
Examples:
integer numbers[5]; // array of 5 integers, indexed 0 – 4
int b[2] = {3,7}; // ( b[0] = 3, b[1] = 7)
int c[2][3] = {{3,7,1},{5,1,9}};
bit[31:0] a[2][3] = c; // array copy
for(int i=0; i<$dimensions(a))
$display($size(a, i+1)); // 2 3 32
Returns dimension
Returns size of particular dimension
$dimensions (array_name)
Returns the # of dimensions in the array
$size (array_name, dimension)
Returns the total # of elements in the specified dimension ($high - $low +1)
bit [3:0] Bytes [0:2][0:5];
dimension numbers
1 23
bit [3:0] Bytes [3][6];
same as:
SystemVerilog Language BasicsSVTB
3-13© 2006
133-
Data Arrays (2/4)
� Dynamic Arrays:
type array_name[] [=initial_value];
� Array size allocated at runtime with constructor
� Out-of-bounds read/write results in simulation error
� Single dimension only
Examples:
reg[7:0] ID[], array1[] = new[16];
reg[7:0] data_array[];
ID = new[100]; // allocate memory
data_array = new[ID.size()] (ID); // copy
data_array = new[$size(ID)] (ID); // copy
data_array = ID; // copy
ID = new[ID.size() * 2] (ID); // double the size
data_array.delete(); // de-allocate memory
Returns size of array
SystemVerilog Language BasicsSVTB
3-14© 2006
143-
Data Arrays (3/4)
� Queues:
type array_name[$] [=initial_value];
� Array memory allocated and de-allocated at runtime with:
� push_back(), push_front(), insert()
� pop_back(), pop_front(), or delete()
� Array memory can not be allocated with new[]
� bit[7:0] ID[$] = new[16]; // Compilatin error!
� Index 0 refers to lower (first) index in queue
� Index $ refers to upper (last) index in queue
� Out-of-bounds read/write results in simulation error
� Can be operated on as an array, FIFO or stack
� Single dimension only
SystemVerilog Language BasicsSVTB
3-15© 2006
153-
Queue Manipulation Examples
int j = 2, q[$] = {0,1,3,6}, b[$] = {4,5};
q.insert(2, j); // {0,1,2,3,6}
// same as q = { q[0:1], 2, q[2:$] };
q.insert(4, b); // {0,1,2,3,4,5,6}
// same as q = { q[0:3], b, q[4:$] };
q.delete(1); // {0,2,3,4,5,6}
// same as q = { q[0], q[2:$] };
q.push_front(7); // {7,0,2,3,4,5,6}
// same as q = { 7, q };
j = q.pop_back(); // {7,0,2,3,4,5} j = 6
// same as j = q[$]; q = q[0:$-1];
q.push_back(8); // {7,0,2,3,4,5,8}
// same as q = { q, 8 };
$display($size(q)); // 7
q.delete(); // delete all elements
// same as q = { };
$display(q.size()); // 0
SystemVerilog Language BasicsSVTB
3-16© 2006
163-
Data Arrays (4/4)
� Associative Arrays:type array_name[index_type]; // indexed by specified type
type array_name[*]; // indexed by any type
� Index type can be any numerical, string or class type
� Dynamically allocated and de-allocated
integer ID_array[*];
ID_array[71] = 99; // allocate memory
ID_array.delete(71); // de-allocate one element
ID_array.delete(); // de-allocate all elements
� Array can be traverse with:
� first(), next(), prev(), last()
� Number of allocated elements can be determined with num()
� Existence of a valid index can be determined with exists()
� Out-of-bounds read returns ’0 for 2state, ’x for 4state arrays
� Single dimension only
function int num();
Returns the number of entries in the array. If the array is empty, it returns 0:
function void delete( [input index] );
Deletes a specified element or the entire array.
function int exists( input index );
Returns 1 if element exists, otherwise returns 0:
function int first( ref index );
Returns the index of the first valid index of an array via a pass by reference int variable. If the array contains at least one element, the function return value will be 1 and the argument variable will be modified to reference the first valid index. If the array is empty, the function return value will be 0 and the argument variable is left unmodified:
function int last( ref index );
Similar to first except the last valid index is returned instead of first:
function int next( ref index );
Returns the index of the next valid element. If there is a next valid element after the index argument, the argument variable will be modified to contain the index of the next valid element and the return value of the function will be 1. Otherwise, the argument variable is left alone and the return value of the function will be 0:
function int prev( ref index );
Similar to next except the prev valid index is returned:
SystemVerilog Language BasicsSVTB
3-17© 2006
173-
Associate Array Examples
byte b_array[string], t[*], a[*]; int index;
b_array[“byte0”] = -8; // create index “byte0” memory
for (int i=0; i<10; i++)
t[i<<i] = i; // create 10 array elements
a = t; // array copy
$display("size of t array is: %0d", t.num()); // array size
if (t.first(index)) begin // locate first valid index
$display("t[%0d] = %0d", index, t[index]);
while(t.next(index)) // locate next valid index
$display("t[%0d] = %0d", index, t[index]);
end
SystemVerilog Language BasicsSVTB
3-18© 2006
183-
Array Loop Support
� Loop support for all array types: foreach
program test;
int unsigned array_size, data[];
array_size = $random;
array_size = (array_size % 3) + 2;
data = new[array_size];
foreach(data[i]) begin
data[i] = $random % 256;
$display(“data[%0d] = %0d”, i, data[i]);
end
endprogram
Compile and simulate the above code, you will see something like the following result:
data[0] = 172
data[1] = 29
data[2] = 191
data[3] = 201
SystemVerilog Language BasicsSVTB
3-19© 2006
193-
Array Locator Methods (1/4)
function array_type[$] array.find()
with (expression)
� Finds all the elements satisfying the with expression
� Matching elements are returned as a queue
function int_or_index_type[$] array.find_index()
with (expression)
� Finds all the indices satisfying the with expression
� Matching indices are returned as a queue
� item references the array elements during search
� Empty queue is returned when match fails
SystemVerilog Language BasicsSVTB
3-20© 2006
203-
Array Locator Methods (2/4)
Example:program test_program;
bit[7:0] SQ_array[$] = {2, 1, 8, 3, 5};
bit[7:0] SQ[$];
int idx[$];
SQ = SQ_array.find() with ( item > 3 );
// SQ[$] contains 8, 5
idx = SQ_array.find_index() with ( item > 3 );
// idx[$] contains 2, 4
endprogram
SystemVerilog Language BasicsSVTB
3-21© 2006
213-
Array Locator Methods (3/4)
function array_type[$] array.find_first()
[with (expression)]
� First element satisfying the with expression is returned
� If with expression is omitted, first element is returned
� First matching element is returned in array_type[0]
function int_or_index_type[$]
array.find_first_index() [with (expression)]
� First index satisfying the with expression is returned
� If with expression is omitted, first index is returned
� First matching index is returned in int_or_index_type[0]
� item references the array elements during search
� Empty queue is returned when match fails
SystemVerilog Language BasicsSVTB
3-22© 2006
223-
Array Locator Methods (4/4)
Example:program test_program;
int array[] = new[5];
int idx[$], Value[$];
foreach(array[i])
array[i] = 4 – i;
Value = array.find_first() with ( item > 3 );
// Value[0] = 4
idx = array.find_first_index() with ( item < 0 );
// idx.size() = 0;
endprogram
More array methods are available See LRM
Examples of other array methods are: (please check release note and LRM for support)
.find_last()
.find_last_index()
.unique()
.unique_index()
.sum()
.product()
.and()
.or()
.xor()
.min()
.max()
.reverse()
.sort()
.rsort()
.shuffle()
SystemVerilog Language BasicsSVTB
3-23© 2006
233-
Recommended Usage Model
� Fixed-size Arrays:
� Size known at compile time
� Contiguous data
� Multi-dimensional arrays
� Dynamic Arrays:
� Size unknown at compile time
� Contiguous data
� Queues:
� FIFO/Stack
� Associative Arrays:
� Sparse data – memories
� Index by number or string
SystemVerilog Language BasicsSVTB
3-24© 2006
243-
System Functions: Randomization
� $random: Return an 32-bit signed random number
� $urandom: Return a 32-bit unsigned random number
� $urandom_range(max, min): specify range of
unsigned random number
� $srandom(seed): Set random seed
� Or use run-time switch: +ntb_random_seed=seed_value
� randcase: Select a weighted executable statement
randcase
10 : f1();
20 : f2(); // f2() is twice as likely to be executed as f1()50 : x = 100;
30 : randcase … endcase; // randcase can be nestedendcase
File I/O (from Verilog 2001):
program test();
/* Assume file contains:
0 1 2 3
4 5 6 7
8 9
*/
initial begin
int i, file;
file = $fopen("stimulus.txt", "r");
while (! $feof(file)) begin
if ($fscanf(file, "%d", i) == 0) break;
$display("i = %0d", i);
end
$fclose(file);
end
endprogram
SystemVerilog Language BasicsSVTB
3-25© 2006
253-
User Defined Types and Type Cast
� Use typedef to create a synonym for another type
� Use <type>’(<value>|<variable>) to dynamically convert data types
Example:
typedef bit [31:0] uint;
bit[7:0] payload[];
int temp = $random;
payload = new[(temp % 3) + 2];
payload = new[(uint’(temp) % 3) + 2];
payload = new[(unsigned’(temp) % 3) + 2];
typedef bit [31:0] uint;
typedef bit [0:5] bsix_t; // Define new type
bsix_t my_var; // Create 6-bit variable
What are the possible sizes of the array?
payload = new[(temp % 3) + 2]; will result in possible size of 0, 1, 2, 3 or 4 because temp % 3 have the following possible values: -2, -1, 0, 1 and 2.
payload = new[(uint’(temp) % 3) + 2]; will result in possible size of 2, 3 or 4 because uint’(temp) % 3 have the following possible values: 0, 1 and 2.
payload = new[(unsigned’(temp) % 3) + 2]; will result in possible size of 2, 3 or 4 because unsigned’(temp) % 3 have the following possible values: 0, 1 and 2.
$cast() can also be used to convert data types.
SystemVerilog Language BasicsSVTB
3-26© 2006
263-
+ - * / arithmetic ~ bitwise negation% modulus division & bitwise and++ -- increment, decrement &~ bitwise nand> >= < <= relational |~ bitwise nor! logical negation | bitwise inclusive or&& logical and ^ bitwise exclusive or|| logical or ^~ bitwise exclusive nor== logical equality != logical inequality & unary and=== case equality ~& unary nand!== case inequality | unary or==? wildcard case equality ~| unary nor!=? wildcard case inequality ^ unary exclusive << shift left ~^ unary exclusive nor>> shift right ?: conditional (ternary)
{} concatenation
Assignment:= += -= *= /= %= <<= >>= &= |= ^= ~&= ~|= ~^=
Operators
SystemVerilog Language BasicsSVTB
3-27© 2006
273-
Know Your Operators!
Example pitfall to watch out for:
What is printed to console with following code?
reg[3:0] sample, ref_data;
sample = dut.cb.dout[3:0];
if (sample != ref_data) $display(“Error!”);
else $display(“Pass!”);
� When sample = 4’b1011 & ref_data = 4’b1010?
� When sample = 4’b101x & ref_data = 4’b1010?
� When sample = 4’b101x & ref_data = 4’b101x?
Avoid false positives by checking for pass condition!
sample = dut.cb.dout[3:0];
if (sample == ref_data) ;
else $display(“Error!”);???Pass
Fail
Good BadRTL
√√√√Tape out!
Debug testbench
Debug RTL code
TB
In Verilog, the == and != operator will return x as the result if any operand contains x or z. The if statement then treats x as a failure. Therefore, in the example above, if either sample or ref contains x or z, the else condition will always execute.
SystemVerilog Language BasicsSVTB
3-28© 2006
283-
Sequential Flow Control
� Conditional:
� if (x==7) a=7; else a=8;
� a = (x == y) ? 7 : 8;
� case statements
� Loops:
� repeat(…) begin … end
� for(…) begin … end
� foreach() begin … end
� while(…) begin … end
� do begin … end while (…);
� break to terminate loop
� continue to terminate current loop iteration
SystemVerilog Language BasicsSVTB
3-29© 2006
293-
Subroutines (task and function)
� Tasks can block
� Functions can not block
function automatic int factorial(int n);
static int id = 0;
int my_id = id++;
if (n < 2) factorial = 1;
else factorial = n * factorial(n-1);endfunction
…
Result = factorial(my_value);
Pass by value
function name returns value
task print_sum(ref integer a[], input int start=0);
automatic int sum = 0;
for (int j=start; j<a.size(); j++)
sum += a[j];
$display(“Sum of array is %0d”, sum);endtask
…print_sum(my_array);
Default value
Pass by reference
task does not return value
Subroutines in program
block defaults to staticcan be made automaticSubroutines in class
defaults to automatic
Subroutine variables
defaults to subroutine scope and lifetime. Can be made automatic or static
Since functions can not block, you will not be able to call a task within a function.
To make your subroutines as flexible as possible (usable in both function and task), you should develop your subroutines are functions if you know for sure that time passage will not be required.
SystemVerilog Language BasicsSVTB
3-30© 2006
303-
Subroutine Arguments
� Type is sticky, following arguments default to that type
� input - copy value in at beginning - default
� output - copy value out at end
� inout - copy in at beginning and out at end
� ref – pass by reference, makes the argument variable the same as the calling variable
� Changes to argument variable will change calling variable immediately
� const ref – pass by reference but read only
� Saves time and memory for passing arrays to tasks & functions
task T3(a, b, output bit [15:0] u, v, const ref byte a[]);
Default dir is input,default type is logic
a, b: input logicu, v: output bit [15:0]
Read-only pass via reference
SystemVerilog Language BasicsSVTB
3-31© 2006
313-
Test For Understanding
� What’s the direction and data type of each argument?
task T3(ref byte a[], reg[15:0] b, c, output u, v);
b = c;
foreach(a[i])
a[i] = i;
endtask
dir is ref,type is byte
program test();
initial begin
reg[15:0] B = 100, C = 0, D = 0, E = 0;
byte A[] = {1,3,5,8,13};
T3(A, B, C, D, E);
foreach(A[i])
$display(A[i]);
$display(B, C, D, E);
end
endprogram What will be displayed on screen?
dir is ?type is ?
dir is ?type is ?
Argument direction type
a[] ref byte
b ref bit[15:0]
c ref bit[15:0]
u output bit[15:0]
v output bit[15:0]
The program test results is as follows:
0
1
2
3
4
0 0 X X
To make b and c pass via value, change the declaration to:
Task T3(ref byte a[], input bit[15:0] b, c, output u, v);
SystemVerilog Language BasicsSVTB
3-32© 2006
323-
Scope and Lifetime Of Variables
int max = 10;
int n;
program top;
int n;
initial begin : top_initial
automatic int i;
n = 1;
for (i=2; i<=max; i++)
n += i;
my_test();
end : top_initial
task my_test();
int n = 1;
for (int i=2; i<=max; i++)
n += i;
$root.n <= n;
end
endprogram
data dec
lared in
side pro
gram
is static
by defa
ult and
access
ible by
all task
s and
functio
ns in th
at prog
ram
i is automatic and local to this block
data declared outside of
program is static and global
Root global n
can only be set
with non-blocking
assignment
n is static and local to my_test()
local n
Root global
max variable
Code blocks can be labeled (useful for debugging)
Any data declared outside a module, interface, task, or function, is global in scope (can be used anywhere after its declaration) and has a static lifetime (exists for the whole elaboration and simulation time).
SystemVerilog data declared inside a module or interface but outside a task, process or function is local in scope and static in lifetime (exists for the lifetime of the module or interface). This is roughly equivalent to C static data declared outside a function, which is local to a file.
Data declared in an automatic task, function or block has the lifetime of the call or activation and a local scope. This is roughly equivalent to a C automatic variable. Data declared in a static task, function or block defaults to a static lifetime and a local scope.
Verilog-2001 allows tasks and functions to be declared as automatic, making all storage within the task or function automatic.
SystemVerilog allows specific data within a static task or function to be explicitly declared as automatic. Data declared as automatic has the lifetime of the call or block, and is initialized on each entry to the call or block. SystemVerilog also allows data to be explicitly declared as static. Data declared to be static in an automatic task, function or block has a static lifetime and a scope local to the block. This is like C static data declared within a function.
SystemVerilog adds an optional qualifier to specify the default lifetime of all variables declared in task, function or block defined within a module, interface or program. The lifetime qualifier is automatic or static. The default lifetime is static.
SystemVerilog Language BasicsSVTB
3-33© 2006
333-
Code Block Lifetime Controls
� Execution of the program ends
� When all initial blocks in program reaches end of code block
� Or, when $finish is executed
� Simulation ends when all programs end
� Execution of a subroutine ends
� When the associated end statement is encountered:
� endtask, endfunction
� Or, when return is executed
� Execution of a loop ends
� When the associated end statement is encountered
� end
� Or, when break is executed
� When continue is executed, the current loop execution ends, simulation advances loop to next iteration
SystemVerilog Language BasicsSVTB
3-34© 2006
343-
Unit Objectives Review
Having completed this unit, you should be able to:
� Define the structure of a SystemVerilog program
� Declare variables in a SystemVerilog program
� Describe variable visibility in program, local blocks and sub-routines
� Use flow control constructs to implement SystemVerilog verification testbench
SystemVerilog Language BasicsSVTB
3-35© 2006
Appendix
Advanced SystemVerilog Constructs
Import and Export subroutines
Packed array
Struct
Union
SystemVerilog Language BasicsSVTB
3-36© 2006
363-
Import and Export Subroutines
// Root level subroutine
task root_task(); $display("I'm Root Task"); endtask
module bfm(router_io.BFM bfm_io); // BFM’s that implement I/O via SystemVerilog interface
// Subroutine to be accessed by test program
task bfm_io.bfm_task(); $display("I'm BFM task"); endtask
endmodule
module vip(…); // BFM’s that do not implement I/O via SystemVerilog interface
// Subroutine to be accessed by test program
task vip_task(); $display("I'm VIP task"); endtask
endmodule
interface top_io(); // SystemVerilog Interface to be used by test program
// Subroutine to be accessed by test program
task interface_task(); $display("I'm Interface task"); endtask
// Wrapper for non-SystemVerilog BFM’s
task vip_task();
test_top.VIP.vip_task(); // XML reference via top-level instance
endtask
modport TB(import task interface_task(), import task bfm_task2(), import task vip_task());
modport BFM(export task bfm_task());
endinterface
program automatic TB(top.TB test);
initial begin
$root.root_task(); // direct $root access
test_top.VIP.vip_task(); // VIP XML access via top module
test_top.BFM.bfm_task(); // BFM XML access via top module
test.vip_task(); // interface VIP access
test.bfm_task(); // interface BFM access
test.interface_task(); // interface access
end
endprogram
module test_top;
top_io IO(…);
tb TB(IO);
router DUT(IO);
bfm BFM(IO);
vip VIP(…);
endmodule
SystemVerilog Language BasicsSVTB
3-37© 2006
373-
Packed Arrays
Bytes[2] = 32’hbeef_deed;
Bytes[1]Bytes[2]
Bytes[0] 01234567 0123456701234567 01234567
01234567 0123456701234567 01234567
01234567 0123456701234567 01234567
type [msb:lsb] [msb:lsb] name [constant];
Bytes[0][3] Bytes[0][1][6]
bit [3:0][7:0] Bytes [3]; // 3 entries of packed 4 bytes
Bytes[2][2][5:4] = Bytes[1][3][4:3]; Bytes[1][0] = Bytes[2][1];
Bytes[2] 01111101 01111011 1011011111110111
� Defines a packed array structure
SystemVerilog Language BasicsSVTB
3-38© 2006
383-
Array Querying System Functions
� $dimensions (array_name)� Returns the # of dimensions in the array
� $left (array_name, dimension)� Returns MSB of specified dimension
� $right (array_name, dimension)� Returns LSB of specified dimension
� $low (array_name, dimension)
� Returns the min of $left and $right
� $high (array_name, dimension)� Returns the max of $left and $right
� $increment (array_name, dimension)� returns 1 if: $left is >= $right,
� returns –1 if: $left is < $right.
� $size (array_name, dimension)
� Returns the total # of elements in the specified dimension ($high - $low +1)
bit [3:0][7:0] Bytes [0:2][0:5];
dimension numbers
1 23 4
SystemVerilog Language BasicsSVTB
3-39© 2006
393-
Array Querying System Functions Examples
int c[2], a[2][2];
bit[31:0] b[0:2][0:1]={{3,7},{5,1},{0,4}};
$display($dimensions(a));
for (int i=1; i<=$dimensions(a); i++) begin
$display("a dimension %0d size is %0d", i, $size(a, i));
$display("a dimension %0d left is %0d", i, $left(a, i));
$display("a dimension %0d right is %0d", i, $right(a, i));
$display("a dimension %0d low is %0d", i, $low(a, i));
$display("a dimension %0d high is %0d", i, $high(a, i));
$display("a dimension %0d increment is %0d", i, signed'($increment(a, i)));
end
$display($dimensions(b));
for (int i=1; i<=$dimensions(b); i++) begin
$display("b dimension %0d size is %0d", i, $size(b, i));
$display("b dimension %0d left is %0d", i, $left(b, i));
$display("b dimension %0d right is %0d", i, $right(b, i));
$display("b dimension %0d low is %0d", i, $low(b, i));
$display("b dimension %0d high is %0d", i, $high(b, i));
$display("b dimension %0d increment is %0d", i, signed'($increment(b, i)));
endSee note section below for print out
3 3
a dimension 1 size is 2 b dimension 1 size is 3
a dimension 1 left is 0 b dimension 1 left is 0
a dimension 1 right is 1 b dimension 1 right is 2
a dimension 1 low is 0 b dimension 1 low is 0
a dimension 1 high is 1 b dimension 1 high is 2
a dimension 1 increment is -1 b dimension 1 increment is -1
a dimension 2 size is 2 b dimension 2 size is 2
a dimension 2 left is 0 b dimension 2 left is 0
a dimension 2 right is 1 b dimension 2 right is 1
a dimension 2 low is 0 b dimension 2 low is 0
a dimension 2 high is 1 b dimension 2 high is 1
a dimension 2 increment is -1 b dimension 2 increment is -1
a dimension 3 size is X b dimension 3 size is 32
a dimension 3 left is X b dimension 3 left is 31
a dimension 3 right is X b dimension 3 right is 0
a dimension 3 low is X b dimension 3 low is 0
a dimension 3 high is X b dimension 3 high is 31
a dimension 3 increment is X b dimension 3 increment is 1
SystemVerilog Language BasicsSVTB
3-40© 2006
403-
Data Structure
� Defines a wrapper for a set of variables
� Similar to C struct or VHDL record
typedef struct {
data_type variable0;
data_type variable1;
} struct_type [, …];
Example:
typdef struct {
int my_int;
real my_real;
} my_struct;
my_struct var0, var1;
var0 = { 32, 100.2 };
var1 = { default:0 };
var1.my_int = var0.my_int;
struct {
data_type variable0;
data_type variable1;
} struct_variable [, …];
Example:
struct {
int my_i;
real my_r;
} my_var0, my_var1;
my_var0 = { 32, 100.2 };
my_var1 = { default:0 };
my_var1.my_i = my_var0.my_i;
SystemVerilog Language BasicsSVTB
3-41© 2006
413-
Data Union
� Overloading variable definition
� Similar to C union
typedef union {
data_type variable0;
data_type variable1;
} unio_type;
Example:
typdef union {
int my_int;
real my_real;
} my_struct;
my_struct var0, var1;
var0.my_int = 32;
var1.my_real = 100.3;
var1.my_int = var0.my_int;
union {
data_type variable0;
data_type variable1;
} union_variable;
Example:
union {
int my_i;
real my_r;
} my_var0, my_var1;
my_var0.my_i = 32;
my_var1.my_r = 100.3;
my_var1.my_i = my_var0.my_i;
SystemVerilog Language BasicsSVTB
3-42© 2006
This page was intentionally left blank.
Drive and Sample DUT Signals
SVTB
4-1© 2006
14-
Agenda
DAY
1111
SystemVerilog Verification Environment2
The Device Under Test (DUT)1
SystemVerilog Language Basics3
Drive and Sample DUT Signals4
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
Drive and Sample DUT Signals
SVTB
4-2© 2006
24-
Unit Objectives
After completing this unit, you should be able to:
� Drive DUT signals in Device Driver routines
� Sample DUT signals in Device Monitor routines
� Synchronize to known point in simulation
Drive and Sample DUT Signals
SVTB
4-3© 2006
34-
Driving & Sampling DUT Signals
� DUT signals are driven in the device driver
� DUT signals are sampled in the device monitor
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
Drive and Sample DUT Signals
SVTB
4-4© 2006
44-
SystemVerilog Testbench Timing
� Program code defaults to Cycle-based Simulation for synchronous drives and samples:
� Events occur at interface clock-block clock edges
router.test_top.sv
DUT
SystemClock
router.tb.sv
SVTBprogram
clock
Simulation TimeSample
Drive
t0t0 – input skew t0 + output skew
SystemVerilog Testbench (SVTB)Synchronous program code execution
router.v
modport
router.if.sv
clock block
async signalsCollection of signals
DUT signals
modport
Drive and Sample DUT Signals
SVTB
4-5© 2006
54-
SystemVerilog Scheduling
� Each time slot is divided into 5 major regions (plus PLI)
� Prepone Sample signals before any changes (#1step)
� Active Design simulation (module), including NBA
� Observed Assertions evaluated after design executes
� Reactive Testbench activity (program)
� Postpone Read only phase
clock
data
REGION
ACTIVITY
NextPrevious
Prepone Observed Reactive PostponeActive
designsample assertions testbench $monitor
Current
Assertion and testbench events can trigger more design evaluations in this time slot
Drive and Sample DUT Signals
SVTB
4-6© 2006
64-
Synchronous Drive Statements
� Drive must be non-blocking
� ##num specified clock cycle delays
� Driving of input signal is not allowed
router.cb.din[3] = 1’b1; //error
##1 router.cb.dout[3] <= 1’b1; //error
##2 router.din[3] <= 1’b1; //error
var_a
din[3]
##1 router.cb.din[3] <= var_a;
clock
Statement executes hereexpression evaluates
Apply drive here
Next statement executes
[##num] interface.cb.signal <= [##num] <value | expression>;
##2 router.cb.din <= var_a; next_statement; is similar to:
#2 router.cb.din <= var_a; next_statement;
In that, time advances first, var_a is then evaluated, the assignment is scheduled for the non-blocking region (+output delay) and next_statement is executed.
router.cb.din <= ##2 var_a; next_statement; is similar to:
router.cb.din <= #2 var_a; next_statement;
In that, var_a is evaluated immediate, the assignment is scheduled for the second valid clock edge from now (+output delay) and next_statement is executed without time advancing.
Explanation for the errors:
The first error is due to driving using blocking assignment.
The correction is to make the drive a non-blocking assignment:
router.cb.din[3] <= 1’b1;
The second error is an illegal drive of input signal. No correction is possible
The third error is caused by forgetting to drive via the clocking block.
The correction is to reference the clocking block:
##2 router.cb.din[3] <= 1’b1;
Drive and Sample DUT Signals
SVTB
4-7© 2006
74-
clock
var_b
router.din[3]
var_a
Synchronous Drive Example
Example:
3cycles
1cycle
##1 router.cb.din[3] <= 1;
var_a = var_b;
##3 router.cb.din[3] <= var_b;Current clock edge
var_a = var_b executed after one clock cycle
signal driven after delayvariables
Drive and Sample DUT Signals
SVTB
4-8© 2006
84-
Sampling Synchronous Signals
� No delay attribute (## num)
� Variable is assigned the sampled value
� Sampling of output signal is not allowed
Examples:
data[i] = router.cb.dout[7];
all_data = router.cb.dout;
@(negedge router.frameo_n[7]); //error
$display(“din = %b\n”, router.cb.din); //error
if(router.cb.din[3] == 1’b0) begin … end //error
variable = interface.cb.signal;
Drive and Sample DUT Signals
SVTB
4-9© 2006
94-
Signal Synchronization
� Synchronize to clock edge specified in clocking block
� Synchronize to any edge of signal
@(router.cb); // continue on next clock edge specified in cb
repeat (3) @(router.cb); // Wait for 3 cb clock cycles
@(router.cb.frameo_n[7]); // continue on any edge
@(posedge router.cb.frameo_n[7]); // continue on posedge
@(negedge router.cb.frameo_n[7]); // continue on negedge
wait (router.cb.valido_n==0); // wait for expression
// no delay if already true
Drive and Sample DUT Signals
SVTB
4-10© 2006
104-
clock
router.cb.frameo_n[7]
Test For Understanding (1/2)
On what edge is the following detected?
@(negedge router.cb.frameo_n[7]);
Does this work for when monitoring output of DUT?
Current clock edge
A B C D E
The negedge will be detected at clock edge D (not C).
This is the edge that you need your monitor transactors to be at when observing the output of the DUT. The monitoring routines at clock edge D acts as the capture flip-flop for the signals launched by clock edge C.
Drive and Sample DUT Signals
SVTB
4-11© 2006
114-
clock
reset_n
Test For Understanding (2/2)
Complete the timing diagram for the following:initial begin
router.reset_n <= 0;
#100 router.cb.reset_n <= 1;
router.cb.frame_n <= ’1;
router.cb.valid_n <= ##3 ’1;
##2 router.cb.frame_n <= ’0;
repeat(3) @(router.cb);
end
0 100 200 300 400
frame_n
valid_n
A B C D E
500
SystemVerilog’s behavior is exactly the same as Verilog.
Non-blocking assignments does not advance time for the next line.
##0 means current simulation time. ##1 means next valid clock edge.
In either case, synchronous signals can only be driven at a valid clock edge + output skew.
Drive and Sample DUT Signals
SVTB
4-12© 2006
124-
Lab 2 Introduction
90 min
Develop Generator, Transactor & Device Drivers to drive one packet through the router
Driver
Generator
DUT
Transactor
reset()Generator,
Transactor &
Device Drivers
Generator, Transactor & Device Drivers
Compile & Simulate
Check Result with GUI
Drive and Sample DUT Signals
SVTB
4-13© 2006
134-
Unit Objectives Review
Having completed this unit, you should be able to:
� Drive DUT signals in Device Driver routines
� Sample DUT signals in Device Monitor routines
� Synchronize to known point in simulation
Drive and Sample DUT Signals
SVTB
4-14© 2006
This page was intentionally left blank.
Concurrency
SVTB
5-1© 2006
15-
Agenda
Object Oriented Programming (OOP)– Encapsulation
7
Concurrency5
DAY
2222
Object Oriented Programming (OOP)– Randomization
8
Inter-Process Communications6
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
Concurrency
SVTB
5-2© 2006
25-
Unit Objectives
After completing this unit, you should be able to:
� Divide a testbench into multiple current processes to execute parallel tasks
Concurrency
SVTB
5-3© 2006
35-
Day 1 Review
Phases of verification
Time
Goal
Build verification
environment
Broad-Spectrum
Verification
Preliminary
Verification
Directed
Verification
Corner-case
Verification% Coverage
Concurrency
SVTB
5-4© 2006
45-
Day 1 Review (Building Testbench Files)
simv
router.vr.tmp
ntb_template -t router router.v
router.if.vrh
router.test_top.sv
Discard
vcs –sverilog router.test_top.sv router.tb.sv router.if.sv router.v
router.if.sv router.tb.sv
Top level harness Interface Test program
router.test_top.v
router.v
Concurrency
SVTB
5-5© 2006
55-
Day 1 Review (Testbench Architecture)
Test
program
Monitor
TransactorSelf Check
Observes data
from DUT
Identifies
transactions
Checks
correctness
Coverage
Driver
Generator
DUT
Transactor
Configure
interface
Checks
completeness
Top level
harness file
Concurrency
SVTB
5-6© 2006
65-
Ready events
process 1
process 3
process 2
process 4
t0
statement 1;
statement 2;
statement 3;
statement a;
statement b;
statement c;
t1 t2
Concurrency in Simulators
What does concurrency mean?
In all concurrent processes, events scheduled for the current time will execute before any event scheduled for a future time executes.
Future events
Concurrency
SVTB
5-7© 2006
75-
Creating Concurrent Processes
� Concurrent processes are created in a fork - join block:
� Statements enclosed in begin-end in a fork-join block are executed sequentially as a single concurrent child process
� No pre-determined execution order for concurrent processes
� All child processes share the parent variables
int a, b, c;
fork
statement0;
begin
statement1;
statement2;
end
join_all | join_any | join_none
statement3;
Concurrency
SVTB
5-8© 2006
85-
fork beginrecv();
endbeginsend();
endjoin
fork recv();send();
join
forkbeginrecv();send();
end join
A:
B:
C:
How Many Child Processes?
forkbegin begin
send();recv();
endcheck();
endjoin
D:
Concurrency
SVTB
5-9© 2006
95-
Join Options
all -child processes execute and all child processes must complete before statement3 is executed
any -child processes execute and one child process must complete before statement3 is executed
none -statement3 executes, child processes are queued but not executed until the parent process encounters a wait statement or completes
fork
statement1;
statement2;
join_all | join_any | join_none
statement3;
fork
join_all
fork
join_any
fork
join_none
Concurrency
SVTB
5-10© 2006
105-
Process Execution
� Once a process executes, it continues to execute until a wait statement is encountered:
� Child processes generated by the executing process are queued
� When the executing process encounters a wait statement, a queued ready process executes
� Time advances when all processes are in a wait state
Wait statements examples:
@(router.cb);
##1 router.cb.din <= 4’hf;
join_any
join_all
Concurrency
SVTB
5-11© 2006
115-
Process Execution Model
� One executing process, all other processes reside on queues
� READY - to be executed at current simulation time
� WAIT - blocked from execution until wait condition is met
� When the executing process goes into a wait state, it moves to a WAIT queue, the next READY process then executes
� Simulation time advances when all processes are in WAIT
Schedule for executionat current simulation time
READY WAIT
process blocked process
blocked process
blocked process
process
child process
Executing thread
At start of simulation:program
Moves to READY queue when wait condition is met
Concurrency
SVTB
5-12© 2006
125-
a = 0;
fork
begin
while ( a != 5 )
if ( $time > MAX_TIME )
$finish;
end
begin
##5 bus.reg <= 1’b1;
a = 5;
end
join
Will this work?
Subtleties in Concurrency (1/5)
Concurrency
SVTB
5-13© 2006
135-
In multi-threaded programs, all threads must be finite or advance the clock!
a = 0;
fork
begin
while ( a != 5 )
if ( $time > MAX_TIME )
$finish;
else
@(bus.cb);
end
begin
##5 bus.reg <= 1’b1;
a = 5;
end
join
Subtleties in Concurrency (2/5)
Concurrency
SVTB
5-14© 2006
145-
program fork_join1;
initial begin
integer a=0, b=1;
fork
begin
integer d=3;
a = b + d;
end
begin
integer e=4;
b = a + e;
end
join
$display(“a = %0d”, a);
$display(“b = %0d”, b);
end
endprogram
Can the child process assess a and b?
What are the final values of a and b?
Subtleties in Concurrency (3/5)
Child processes share the same parental variables
Concurrency
SVTB
5-15© 2006
155-
Subtleties in Concurrency (4/5)
Desired output:
program test;
initial begin
for (int i = 0; i < 16; i++) begin
fork
send(i);
join_none
end
end
task send(int i);
$display(“Driving port %0d”, i);
while (1) begin
#1;
break;
end
endtask
endprogram
automatic.sv
Driving port 0
Driving port 1
Driving port 2
Driving port 3
Driving port 4
Driving port 5
Driving port 6
Driving port 7
...
Concurrency
SVTB
5-16© 2006
165-
Subtleties in Concurrency (5/5)
� Simulation output:
Driving port 16
Driving port 16
Driving port 16
Driving port 16
…
Simulation stopped at time 0
What happened to ports 0-15?
Why did simulation stop at time 0?
Concurrency
SVTB
5-17© 2006
175-
Unroll the for-loop
program test;
initial begin
int i = 0;
fork
send(i);
join_none
i++; // i = 1;
fork
send(i);
join_none
i++; // i = 2;
fork
send(i);
join_none
i++; // i = 3;
… (repeated 16 times total)
end
endprogram
Scheduled for executionat current simulation time
But i = 16 before they execute
READY
{ send(i) }
{ send(i) }
{ send(i) }
{ send(i) }
Simulation terminates when all procedural code inside program block reaches end
Concurrency
SVTB
5-18© 2006
185-
Solution (1/2): automatic Variable
Desired output:// program automatic test;
program test;
initial begin
for (int i = 0; i < 16; i++) begin
automatic int index = i;
fork
send(index);
join_none
end
end
task send(int i);
$display(“Driving port %0d”, i);
...
endtask
endprogram
Driving port 0
Driving port 1
Driving port 2
Driving port 3
Driving port 4
Driving port 5
Driving port 6
Driving port 7
...
� automatic variables:
� Copied from parent when the child process is queued
� Once created, variables are local to the child thread
Simulation terminates when all procedural code inside program block reaches end
Concurrency
SVTB
5-19© 2006
195-
Solution (2/2): Wait Control
program automatic test;
initial begin
for (int i = 0; i < 16; i++) begin
int index = i;
fork
send(index);
join_none
end
wait fork;
end
task send(int i);
$display(“Driving port %0d”, i);
...
endtask
endprogram
� wait fork suspends process until all children
have completed execution
Blocking statement to control proper termination of
simulation (more in later units)
Another mechanism you can use is wait(…) or @(…). Example:
program automatic router_test(router_io.TB router);
int done = 0;
initial begin
for (int i=0; i<16; i++) begin
int j = i;
fork
send(j);
join_none
end
wait(done >= 16);
end
task send(int i);
$display("Driving port %0d", i);
while(1) begin
#1;
done++;
end
endtask
endprogram
Concurrency
SVTB
5-20© 2006
205-
Disable Forked Processes
program automatic test;
task recv();
fork: recv_wd_timer
begin
@(negedge router.cb.frameo_n[da]);
end
begin
repeat(1000) @(router.cb);
$display(“Timed out!”);
error_handler(); // user subroutine
end
join_any: recv_wd_timer
disable fork; // kill all child processes
// disable recv_wd_timer; // kill children in named block
get_payload();
endtask
endprogram
� Watch-dog timer:
� disable fork terminates all child processes
The consequence of disable fork is to kill ALL child processes. This include all other fork-join constructs within the executing process. This may not be desirable. One way to manage this is to label the fork-join construct and disable just the named fork-join block. Example:
program automatic router_test(router_io.TB router);
initial begin
fork
begin #100 $display($time); end
join_none
fork: test1
begin $display("This is a test"); end
begin #10 $display("Did I execute?"); end
join_any : test1
disable test1;
// disable fork;
wait fork;
$display($time);
end
endprogram
Concurrency
SVTB
5-21© 2006
215-
Helpful Debugging Features
� Use %m and $display() to print the simulation time, and location of call
task check();
int status;
string message;
status = compare(message);
case (status)
0: begin
$display("[ERROR]%0t: %s\n%m\n", $time, message);
$finish;
end
...
endcase
$display("[ERROR]%0d: Unsupported status %0d\n%m\n", $time, status);
endtask
What to print for debugging?
Indicate message type (ERROR, DEBUG, etc.)
Simulation time
Source code location
Concurrency
SVTB
5-22© 2006
225-
Unit Objectives Review
Having completed this unit, you should be able to:
� Divide a testbench into multiple current processes to execute parallel tasks
Inter-Process Communications
SVTB
6-1© 2006
16-
Agenda
Object Oriented Programming (OOP)
– Encapsulation7
Concurrency5
DAY
2222
Object Oriented Programming (OOP)
– Randomization8
Inter-Process Communications6
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
Inter-Process Communications
SVTB
6-2© 2006
26-
Unit Objectives
After completing this unit, you should be able to:
� Establish order of execution using event flag
� Avoid resource collision with Semaphores
� Pass data via Mailbox
Inter-Process Communications
SVTB
6-3© 2006
36-
Inter-Process Communications (IPC)
� Concurrent processes require communication to
establish control for sequence of execution
� Three types are covered in this unit
Event based
Resource sharing
Data passing
thread
1
thread
2resource
thread
1
thread
2
event
thread
1
thread
2IPC
Inter-Process Communications
SVTB
6-4© 2006
46-
Event Based IPC
� Synchronize operation of concurrent processes via
event variables:
� Process waits for event to be triggered
� Higher priority process triggers the event to enable the waiting process to be placed into the READY queue
� Mainly used to control sequence of execution
process
1
process
2
event
Inter-Process Communications
SVTB
6-5© 2006
56-
program sync_trigger;
event A;
fork
my_func1();
my_func2();
join
task my_func1();
wait(A.triggered);
$display(“Print 2nd”);
endtask
task my_func2();
$display(“Print 1st”);
->A;
endtask
endprogram
Event Based IPC Example
Controlling order of execution.
Parent my_func1 my_func2
fork
…
join
wait(A.triggered) …
$display …
->A; …
}
$display …
}
}
Inter-Process Communications
SVTB
6-6© 2006
66-
Event Wait Syntax
� Wait until event has been triggered (one shot):
@(event_var [, event2]);
� Will be satisfied by events which occur after the execution of this statement
� Wait until event has been triggered (persistent):
wait(event_var.triggered);
� Similar to @(event_var), but will also be satisfied by events which happens during later during same simulation time
� Can be used to eliminate potential race condition
Inter-Process Communications
SVTB
6-7© 2006
76-
Trigger Syntax
->eventN;
� event variables are handles
� Assigning an event to another makes both event the same event
Example:
event a, b, c;
a = b;
-> c;
-> a; // also triggers b
-> b; // also triggers a
a = c;
b = a;
-> a; // also triggers b and c
-> b; // also triggers a and c
-> c; // also triggers a and b
Inter-Process Communications
SVTB
6-8© 2006
86-
program automatic router_test(router_io.TB router);
event DONE;
initial begin
fork
gen();
check();
join_none
for (int i=0; i<16; i++)
fork
send(i);
recv(i);
join_none
wait(DONE.triggered);
end
task check();
while(1) begin
if (($get_coverage() == 100) || ...)
->DONE;
...
end
endtask
endprogram
Controlling Termination of Simulation
Blocking statement to
prevent termination of
simulation until done
Trigger event when
termination condition
is detected
Inter-Process Communications
SVTB
6-9© 2006
96-
Resource Sharing IPC
� Synchronize operation of concurrent Processes via
access to shared resources:
� Process requests for a shared resource before executing a critical section of code
� Process waits if the requested resource is unavailable
� Process resumes execution when the requested resource becomes available
Process
1
Process
2resource
Inter-Process Communications
SVTB
6-10© 2006
106-
Semaphores
� Each Semaphore is a set of buckets in which keys can
be deposited and removed:
� A process tries to acquire keys from a semaphore bucket
� Process execution waits until keys requested are available in the semaphore bucket
� When the requested keys becomes available, process execution resumes and the requested keys removed from the semaphore bucket
� Mainly used to prevent multiple processes from
accessing the same hardware signal or using same
software resource
Inter-Process Communications
SVTB
6-11© 2006
116-
Semaphores
� Semaphores are supported via built-in semaphore class:
class semaphore;
function new(int keyCount = 0);
task put(int keyCount = 1);
// the following is blocking:
task get(int keyCount = 1);
// the following is non-blocking: 1 for success 0 for failure
function int try_get(int keyCount = 1);
endclass
Inter-Process Communications
SVTB
6-12© 2006
126-
Creating Semaphores
� Each semaphore bucket is an semaphore object
semaphore sem[];
sem = new[4];
foreach (sem[i]) begin
sem[i] = new(3);
end
T
T
T T
T
T
sem[0] sem[1]
T
T
T T
T
T
sem[2] sem[3]
Inter-Process Communications
SVTB
6-13© 2006
136-
Acquiring Semaphore Keys
sem[0].get(2);
sem[0]
sem[0]
Before
T
T T
T
After
if (!sem[0].try_get(2)) // does not block
$display(“Failed”);
sem[0].get(2); // blocks until two keys are available
Inter-Process Communications
SVTB
6-14© 2006
146-
Returning/Creating Semaphore Keys
sem[0]
sem[0]
Before
After
T
T
T T
sem[0].put(2);
Inter-Process Communications
SVTB
6-15© 2006
156-
program automatic router_test(router_io.TB router);
semaphore sem[];
...;
sem = new[16];
foreach(sem[i])
sem[i] = new(1);
...;
task send();
sem[da].get(1);
send_addrs();
send_pad();
send_payload();
sem[da].put(1);
endtask
...;
endprogram
Arbitration Example
Create semaphore array to
represent each output port
Block if others are driving
the chosen output port
Construct each individual
semaphore bucket
Re-deposit keys when
done with driving port
Inter-Process Communications
SVTB
6-16© 2006
166-
Mailbox
� Messages are passed between processes via mailbox:
� A process sends data by putting messages a mailbox
� A process retrieves data by getting messages from the mailbox
� If a message is not available, the process can wait until there is a message to retrieve
� Process resumes execution once the message becomes available
� Mainly used for passing data between processes
process
1
process
2data
Inter-Process Communications
SVTB
6-17© 2006
176-
Mailboxes
� Mailboxes are supported via built-in semaphore class:
class mailbox #(type T = dynamic_singular_type);
function new(int bound = 0);
function int num(); // return # of messages
task put(T message); // wait if exceed bound
task get(ref T message); // wait if no message
task peek(ref T message);
function int try_put(T message);
function int try_get(ref T message);
function int try_peek(ref T message);
endclass
#(type T = dynamic_singular_type) is not yet supported.
Bounded size is not yet supported.
try_put() is not yet supported.
Inter-Process Communications
SVTB
6-18© 2006
186-
Creating Mailboxes
typedef mailbox #(string) my_mbox;
mailbox mbx[]; // messages can be any type
my_mbox mbx_typed = new(); // messages must be string type
mbx = new[4];
for (int i=0; i<mbx.size(); i++) begin
mbx[i] = new(i+2); // mbx[i] bound to max of i+2 messages
end
mbx[0] mbx[1] mbx[2] mbx[3] mbx_typed
string
string
unbounded
Typed mailbox is not yet supported.
Bounded mailbox is not yet supported.
Inter-Process Communications
SVTB
6-19© 2006
196-
Putting Messages into Mailboxes
task put(message); // block if exceeds bound
function int try_put(message); // non-blocking
Example:
int status;
bit[15:0] test_data = 16’hcafe
mailbox mbox = new();
mbox.put(test_data);
mbox.put(“café”);
mbox
“café”
16’hcafe
try_put() is not yet supported.
Inter-Process Communications
SVTB
6-20© 2006
206-
Retrieve Messages from Mailboxes (1/2)
task get(ref message); // block if mailbox is empty
// simulation error if message type mismatches
function int try_get(ref message); // non-blocking
// return 1 if successful, 0 if no message, -1 if mismatch
Example:
int status;
bit[15:0] test_data = 16’hcafe
mailbox mbox = new();
mbox.put(test_data);
mbox.put(“cafe”);
mbox.get(test_data);
$display(“test_data = %0h”, test_data); // test_data = cafe
status = mbox.try_get(test_data); // status = -1
mbox.get(test_data); // simulation error!
mbox
“café”
16’hcafe
Inter-Process Communications
SVTB
6-21© 2006
216-
Retrieve Messages from Mailboxes (2/2)
task peek(ref message); // block if mailbox is empty
function int try_peek(ref message); // non-blocking// return number of message in mailbox if successful,// 0 if no message, -1 if mismatch
Example:int status; bit[15:0] test_data = 16’hcafe;
string s; mailbox mbox = new();
mbox.put(test_data);
mbox.put(“café”);
$display(“# of message = %0d”, mbox.num()); // 2 messages
mbox.peek(test_data); // still 2 messages left
status = mbox.try_peek(test_data); // still 2 messages
mbox.get(test_data);
mbox.get(s);
status = mbox.try_peek(test_data); // status = 0;
mbox.peek(s); // blocks, if new message is not string, type error!
mbox
“café”
16’hcafe
Inter-Process Communications
SVTB
6-22© 2006
226-
Monitor
Transactor
Self Check
Driver
gen()
DUT
send()
reset()
Lab 3 Introduction
Add Concurrent
Monitor & Self-check
Compile & Simulate
Add Monitor & Self-Check
Validate self-check
Self-check90 min
Inter-Process Communications
SVTB
6-23© 2006
236-
Unit Objectives Review
Having completed this unit, you should be able to:
� Establish order of execution using event flag
� Avoid resource collision with Semaphores
� Pass data via Mailbox
Inter-Process Communications
SVTB
6-24© 2006
This page was intentionally left blank.
OOP Encapsulation
SVTB
7-1© 2006
17-
Agenda
Object Oriented Programming (OOP)
– Encapsulation7
Concurrency5
DAY
2222
Object Oriented Programming (OOP)
– Randomization8
Inter-Process Communications6
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
OOP Encapsulation
SVTB
7-2© 2006
27-
Unit Objectives
After completing this unit, you should be able to:
� Raise level of abstraction by building data
structure with self-contained functionality:
� OOP encapsulation
� Protect integrity of data in OOP data structure:
� OOP data hiding
� Simplify data initialization process:
� OOP constructor
OOP Encapsulation
SVTB
7-3© 2006
37-
Abstraction Enhances Re-Usability of Code
Tests-A Tests-BRe-usable
Re-usable
Project A Project B
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT A
Transactor
Configure
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT B
Transactor
Configure
Create OOP representations
OOP Encapsulation
SVTB
7-4© 2006
47-
OOP Encapsulation (OOP Class)
� Similar to a module, an OOP class encapsulates:
� Variables (properties) used to model a system
� Subroutines (methods) to manipulate the data
� Properties & methods are called members of class
class DriveXactor;
string name;
bit[3:0] sa, da;
bit[7:0] payload[];
task send();
send_addrs();
send_pad();
send_payload();
endtask
task send_addrs(); ... endtask
task send_pad(); ... endtask
task send_payload(); ... endtask
endclass
Class properties are global inside the class
OOP Encapsulation
SVTB
7-5© 2006
57-
program Main;class DriveXactor;
DriveXactor driver1;DriveXactor driver2;driver2 = new();…
endprogram
Creating OOP Objects
� OOP objects are created from class definitions:
� Similar to instance creation from module definition
� Object memory is allocated by calling new()
class Packet;
Packet obj_hdl = new();
Handle
driver1Handle
driver2
Memory
Memory
Handle
obj_hdl
Classes can be declared inside the program block or outside the program block ($root). When declared inside the program block, the class definition is only visible within the program block in which the class is declared. When declared outside the program block, the class definition is accessible by all program blocks.
With VCS2005.06-SP1, when compiling SystemVerilog code in which classes are declared at the $root scope, the “–ntb_opts svp” compile switch must be set.
OOP Encapsulation
SVTB
7-6© 2006
67-
Accessing Object Members
� Object members are accessed via the object handle:
� Similar to accessing instance signals and subroutines
program Main;
class DriveXactor;
bit[3:0] sa, da;
byte payload[];
task send();
...
endclass
DriveXactor driver;
initial begin
driver = new();
driver.sa = 3; // access property
driver.da = 7; // access property
driver.send(); // access method
end
endprogram
OOP Encapsulation
SVTB
7-7© 2006
77-
Initialization of Object Properties
� Define constructor new() to initialize properties:
� No return type in declaration
� Executes immediately after object memory is allocated
� Not accessible via dot (.) notation
program Main
class Packet;
bit[3:0] sa, da;
bit[7:0] payload[];
function new(bit[3:0] sa, da, int payload_size);
this.sa = sa;
this.da = da;
this.payload = new[payload_size];
endfunction
endclass
initial begin
Packet pkt1 = new(3, 7, 2);
pkt1.new(5, 8, 3); // syntax error!
end
endprogram
“this” keyword
unambiguously refers
to class properties or
methods of the
current instance.
OOP Encapsulation
SVTB
7-8© 2006
87-
OOP Data Hiding (Integrity of Data)
� Unrestricted access of object properties can cause
unintentional data corruption
program Main;
class rectangle;
int width, length, area, perimeter;
task print_area();
$display(“area = %0d\n”, area);
endtask
function new();
width = 0; length = 0; area = 0; perimeter = 0;
endfunction
endclass
initial begin
rectangle recObj = new();
recObj.width = 20; // directly set width
recObj.length = -5; // directly set length
recObj.area = recObj.width * recObj.length;
recObj.print_area(); // correct area value?
end
endprogram Are all class data correct?
OOP Encapsulation
SVTB
7-9© 2006
97-
Protect Against Unintentional Corruption
� Hide properties & methods via “local”:
� Object members are public by default
� “local” members of object can not be accessed directly
� Constructor new() can not be local
program Main;
class rectangle;
local int width, length, area, perimeter;
local task print_area(); …
function new(); …
endclass
initial begin
rectangle recObj = new();
recObj.width = 20; // Compile error!
recObj.length = 5; // Compile error!
recObj.print_area(); // Compile error!
end
endprogram How can “local” members be accessed?
OOP Encapsulation
SVTB
7-10© 2006
107-
Protect Against Data Corruption
� Create public class method to access local members
� Ensure data integrity within the method
program Main;
class rectangle;
local int width, length, area, perimeter;
function new(); …
function int set_width(int w);
if (w <= 0) begin
set_width = 0; return;
end
else set_width = 1;
width = w;
area = width * length;
if (length != 0)
perimeter = 2 * (width + length);
endfunction
endclass
initial begin
rectangle recObj = new();
if(!recObj.set_width(20)) $display(“[ERROR]”);
end
endprogram
Ensure integrity
of object data
Ensure integrity
of subroutine callExecute
functionality
OOP Encapsulation
SVTB
7-11© 2006
117-
What happens when one object handle is assigned to
another?
Like any variable, the target takes on the value of the source.
class Packet;
int payload_size;
...
endclass
…
Packet pkt1 = new();
Packet pkt2 = new();
…
pkt1 = pkt2;
pkt1.payload_size = 5; // whose payload_size is set ?
pkt2
Memory
pkt1
Memory
Working with Objects – Handle Assignment
What happens to the pkt1 object memory?
See next slide for answer.
OOP Encapsulation
SVTB
7-12© 2006
127-
Working with Objects – Garbage Collection
� VCS garbage collector reclaims memory automatically:
� When an object memory is no longer accessible
� And, the object has no scheduled event
� Object can be manually de-referenced
� Making an exact duplication of object memory:
pkt1 = null;
class Packet;
int count;
...
endclass
…
Packet packet1 = new();
Packet packet1_copy; // handle only…
packet1_copy = new packet1; // shallow copy
// deep copy not support in SVTB
Every time a constructor task new() is called, new memory is allocated. The handle is removed from the old memory and re-assigned to the new memory. If there are no events scheduled in the old memory, the old object memory is reclaimed by the garbage collector.
OOP Encapsulation
SVTB
7-13© 2006
137-
program router;
class Packet;
static int count = 0;
string str_var;
...
endclass
initial begin
Packet packet1 = new();
Packet packet2 = new();
...
packet1.count++;
packet2.count++;
...
$display(“Count: %0d”, packet1.count);
$display(“Count: %0d”, packet2.count);
end
endprogram
� Static properties:
� Associated with the class, not the object
� Shared by all objects of that class
What values get printed?
Working with Objects – Static Properties
OOP Encapsulation
SVTB
7-14© 2006
147-
class node;
static int count = 0;
string str;
node next;
...
task ping();
...
endtask
endclass
class node;
static int count = 0;
string str;
node next;
...
extern task ping(); // prototype
endclass
task node::ping();
...
endtask
Place class name and double-colons before method name
Best Practices (1/2)
� Methods can be placed outside of the class block:
� Inside class block, declare a extern prototype
� Outside class block, use a pair of colons :: to associate the method with its class
� Double-colon is a scope/name resolution operator
OOP Encapsulation
SVTB
7-15© 2006
157-
Best Practices (2/2)
� Useful methods for Data classes:
� display()
� Print object variables to console
� Helpful for debugging
� compare()
� Returns match, mismatch and other status base on results of comparing object variables to variables of another object
� Simplifies self-check
� copy()
� Copy selected variables or nested objects
� Useful when exact duplication is not desirable
OOP Encapsulation
SVTB
7-16© 2006
167-
Unit Objectives Review
Having completed this unit, you should be able to:
� Raise level of abstraction by building data structure
with self-contained functionality:
� OOP encapsulation
� Protect integrity of data in OOP data structure:
� OOP data hiding
� Simplify data initialization process:
� OOP constructor
OOP Encapsulation
SVTB
7-17© 2006
Appendix
SystemVerilog Virtual Interface
OOP Encapsulation
SVTB
7-18© 2006
187-
Virtual Interfaces
� Allow grouping of signals by function
� Create a handle to an interface
� Virtual interfaces can be passed via routine argument
� Promotes reuse by separating testbench from
implementation names
Advanced
topic
din1[15:0]
frame_n1[15:0]
valid_n1[15:0]router_1
din3[15:0]
frame_n3[15:0]
valid_n3[15:0]router_3
16x16
ROUTER
16x16
ROUTER
16x16
ROUTER
16x16
ROUTERreset_n
SystemClock
OOP Encapsulation
SVTB
7-19© 2006
197-
Virtual Interfaces
� STEP 1: Define a physical interface
� Similar to creating interface for just the single instance
� The difference is that common connections are removed
interface router_io(input logic clock);
// logic reset_n;
logic [15:0] din, frame_n, valid_n;
logic [15:0] dout, valido_n, frameo_n;
clocking cb @(posedge clock);
default input #1 output #1;
output din, frame_n, valid_n;
input dout, valido_n, frameo_n;
endclocking
modport TB(clocking cb);
// instead of modport TB(clocking cb, output reset_n);
endinterface
OOP Encapsulation
SVTB
7-20© 2006
207-
Virtual Interfaces
� STEP 2: Connect the interface
module router_test_top;logic SystemClock;logic reset_n;router_io io_0(SystemClock);router_io io_1(SystemClock);router_io io_2(SystemClock);router_io io_3(SystemClock);router_test test(io_0, io_1, io_2, io_3, reset_n);router dut(
.clock (SystemClock);
.reset_n (reset_n);
.din0 (io_0.din),
.frame_n0 (io_0.frame_n),
.valid_n0 (io_0.valid_n),
...
.din1 (io_1.din),
.frame_n1 (io_1.frame_n),
.valid_n1 (io_1.valid_n),
...);
endmodule
Connect common
signals separately
One interface
per instance
Connect unique signals with
a specific interface object
OOP Encapsulation
SVTB
7-21© 2006
217-
Virtual Interfaces
class DriverClass;string name;
virtual router_io.TB router;...
function new(string name = "Driver",virtual router_io.TB router);
this.name = name;this.router = router;
endfunction
virtual task send_addrs(); router.cb.frame_n[sa] <= 1'b0;for(int i=0; i<4; i++) beginrouter.cb.din[sa] <= da[i];@(router.cb);
endendtask
endclass
� STEP 3: Pass virtual interface in via constructor
� STEP 4: Drive/Sample signals with virtual interface
� This class is now re-useable for any router instance
Create virtual
interface instance
Pass virtual connections
via constructor argument
Drive/Sample signals
using virtual interface
Requires –ntb_opts svp switch
OOP Encapsulation
SVTB
7-22© 2006
227-
Virtual Interfaces
� STEP 5: Connect Virtual to physical
program automatic router_test(router_io.TB r0, r1, r2, r3output logic reset_n);
class BFM_environment;DriverClass driver[16];function new(virtual router_io.TB router);...endfunction
endclassBFM_environment bfm[4];initial begin
bfm[0] = new(r0);bfm[1] = new(r1);bfm[2] = new(r2);bfm[3] = new(r3);...
endtask reset();
reset_n <= 1’b0; ...;endtask
endprogram
module router_test_top;
logic SystemClock, reset_n;
router_io io_0(…),io_1(…),io_2(…),io_3(…);
router_test test(io_0, io_1, io_2, io_3, reset_n);
router dut(...);
...
endmodule
Connect Virtual to physical
OOP Randomization
SVTB
8-1© 2006
18-
Agenda
Object Oriented Programming (OOP)– Encapsulation
7
Concurrency5
DAY
2222
Object Oriented Programming (OOP)– Randomization
8
Inter-Process Communications6
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
OOP Randomization
SVTB
8-2© 2006
28-
Unit Objectives
After completing this unit, you should be able to:
� Explain why randomization is needed in verification
� Randomize variables
� Constrain randomization of variables
OOP Randomization
SVTB
8-3© 2006
38-
Why Randomization?
How long will simulation run if exhaustive testing of a 32-bit adder is required?
Assume that one set of input and output can be verified every 1ns.
A day?
A week?
A year?
+32
32
32
A[31:0]
B[31:0]
SUM[31:0]
It will take over 500 years to verify this simple adder.
The point is that exhaustive simulation testing is impossible!
OOP Randomization
SVTB
8-4© 2006
48-
Alternatives to Exhaustive Testing?
� The best known mechanism is randomization:
� Randomization of data
What is the goal of verification if exhaustive testing is unachievable?
Answer: Verify with sufficient set of vectors to gain a level of confidence that product will ship with a tolerable field-failure rate.
OOP Randomization
SVTB
8-5© 2006
58-
When Do We Apply Randomization?
Time
Goal
Build verification
environment
Broad-Spectrum
Verification
Trivial
Verification
Difficult to reach
Corner-case
Verification
Corner-case
Verification
% Coverage
Directed*
Broadly
Constrained
Randomization
Narrowly
Constrained
Randomization
Directed*
OOP Randomization
SVTB
8-6© 2006
68-
OOP Based Randomization
� Two types of random properties are supported:
� rand
� randc
� rand and randc properties are randomized when the class method randomize() is called:
� Randomize property value to full range of data type
� randomize() is built-in with every class
� 1 is returned if successful, 0 if randomization failed
� rand properties can assume any legal value:
� Values can repeat without exhausting all possible values
� randc properties can be up to 16 bits:
� Exhaust all values before repeating any individual value
� For non-repeating bit values > 16 bits, use concatenation
OOP Randomization
SVTB
8-7© 2006
78-
Randomization Example
program automatic router_test;
class Packet;
randc bit[3:0] sa, da;
rand bit[7:0] payload[];
endclass
Packet randomized_obj = new();
mailbox out_box = new();
int run_for_n_packets = 2000;
initial begin
reset();
gen();
...
end
task gen();
Packet pkt;
for (int i=0; i<run_for_n_packets; i++) begin
if (!randomized_obj.randomize()) $display(“ERROR”);
pkt = new randomized_obj;
out_box.put(pkt);
...
end
endprogram
Declare random properties in class
Create an object to be randomized
Randomize content of object
Pass copy of randomized object to next transactor
What would happen with:out_box.put(randomized_obj);
OOP Randomization
SVTB
8-8© 2006
88-
Issues with Randomization
program automatic router_test;
class Packet;
rand bit[3:0] sa, da;
rand bit[7:0] payload[];
function void display();
$display(“sa = %0d, da = %0d”, sa, da);
$display(“size of payload array = %0d”, payload.size());
foreach(payload[i])
$display(“payload[%0d] = %0d”, i, payload[i]);
endclass
initial begin
Packet pkt = new();
pkt.randomize();
pkt.display();
end
endprogram
� How do you control
� The value range for sa and da?
� The size of payload[]?
What does pkt.display() show for sa, da and payload.size()?
What if sa, da are int type? rand int sa, da;
Since sa and da are unsigned four bit type, the sa and da values will be in { 0:15 }.
Because memory for payload array is not allocated, the size of payload array will always be 0.
If sa and da were to be changed to int type, then the full range of integer values will be possible. This means that there is a 50% chance for sa and da values to be negative numbers.
OOP Randomization
SVTB
8-9© 2006
98-
� Class properties are constrained in a constrain block
� Use operator or distribution specification
� Arrays can be constraint with aggregates like size()
� For distribution specification:
� Distributed over a specified range with keyword inside:
� Excluded from a specified range with !:
constraint Limit1 {
sa inside { [5:7], 10, 15 } ;
// 5,6,7,10,15 equally weighted probability
payload.size() >= 2;
payload.size() <= 4;
}
Distributed Constraints (1/2)
constraint Limit2 {
!( sa inside { [1:10], 15 } );
// not 1 through 10 or 15
!( payload.size() inside { [100:200] } );
}
OOP Randomization
SVTB
8-10© 2006
108-
constraint Limit {
sa dist {[5:7]:=10, 9:=20};
}
// 5 = weight 10
// 6 = weight 10
// 7 = weight 10
// 9 = weight 20
constraint Limit {
da dist {[5:7]:/60, 9:=40};
}
// 5 = weight 20
// 6 = weight 20
// 7 = weight 20
// 9 = weight 40
equal weights divided weights
Distributed Constraints (2/2)
� Constraint values can also be weighted over a specified range using keyword dist and:
� := (apply the same weight to all values in range)
� :/ (divide the weight among all values in range)
OOP Randomization
SVTB
8-11© 2006
118-
Array Constraint Support
� Members can be constrained within foreach loop
� Aggregates can be used to constraint array
� size(), sum() and more (see release notes)
� Set membership can be used to reference content
class rectangle;
rand byte array[10];
rand bit drivers_in_use[16];
rand int num_of_drivers, one_element_of_array;
constraint limit {
num_of_drivers inside { [1:16] };
drivers_in_use.sum() == num_of_drivers;
foreach(array[i])
(i >= 3) -> array[i] == i;
one_element_of_array inside array;
}
endclass Requires –ntb_opts new_constraints switch
OOP Randomization
SVTB
8-12© 2006
128-
Implication and Order Constraints
� Implication operators:� ->
� if ( … ) … [ else … ]
� Bidirectional implication� One side being true implies the other side is true.
typedef enum { low, mid, high } AddrType;
class MyBus;
rand bit[7:0] addr;
rand AddrType atype;
constraint addr_range {
(atype == low ) -> addr inside { [0:15] };
(atype == mid ) -> addr inside { [16:127] };
(atype == high) -> addr inside { [128:255] };
// same as:
// if (atype == low) addr inside { [0:15] };
// if (atype == mid) addr inside { [16:127] };
// if (atype == high) addr inside { [128:255] };
}
endclass
OOP Randomization
SVTB
8-13© 2006
138-
Constraint Solver Order
� randc properties are solved before rand properties
� Can not constraint randc properties with rand property
� Use solve – before construct to set solving order
� Can not be used to force rand property to be solved before randc properties
class MyBus;
rand bit flag;
rand int addr;
constraint addr_range {
if ( flag == 0 ) addr == 0;
else addr inside { [1:1024] };
solve flag before addr;
// solve addr before flag; // what’s the difference?
}
endclass
OOP Randomization
SVTB
8-14© 2006
148-
Can randomize() Fail?
What if high equals 0?
randomize() produces this simulation warning:
and returns a status value of 0.
Solver failed when solving following set of constraints
integer high = 0;
rand integer x; // rand_mode = ON
constraint Limit // (constraint_mode = ON)
{
( x > 0 ) ;
( x < high ) ;
}
Constraint solver failed - Constraints are inconsistent
and cannot be solved.
class demo;byte high = 9;
rand int x;constraint Limit{ x > 0; x <= high; }task new();
int status;status = randomize();
endtaskendclass
OOP Randomization
SVTB
8-15© 2006
158-
VCS Will Find Value if Solution Exist
� Constraint limits can be random variables:
What random values are generated for high?
randomize() will eliminate values <= 0 from possible values for high.
If there is no legal value for high, then randomize()prints warning and returns a 0. (variables left unchanged)
class demo;
rand byte high;
rand int x;
constraint Limit {
x > 0;
x <= high;
}
endclass
OOP Randomization
SVTB
8-16© 2006
168-
Effects of Calling randomize()
� When randomize() executes, three events occur:
� pre_randomize() is called
� Randomization is executed
� post_randomize() is called
� pre_randomize()
� Optional
� Set/Correct constraints before randomization
� post_randomize()
� Optional
� Make corrections after randomization
� Example: CRC
class Packet;
rand bit[3:0] sa, da;
rand bit[7:0] payload[];
bit[15:0] crc;
constraint LimitA {
sa inside { [0:7] };
da inside { [0:7] };
payload.size() inside { [2:4] };
}
function void pre_randomize();
payload.delete();
endfunction
function void post_randomize();
gen_crc();
endfunction
endclass
OOP Randomization
SVTB
8-17© 2006
178-
Applying pre_randomize()
� Use pre_randomize() to:
� Set/Correct constraints before randomization
� Reset effects of prior randomizations
program automatic router_test;
class Packet;
rand bit[3:0] sa, da;
rand bit[7:0] payload[];
constraint LimitA { payload.size() inside {[2:10]}; }
function void pre_randomize();
payload.delete();
endfunction
endclass
initial begin
int status
Packet pkt = new();
for(int i=0; i<10; i++)
if(!pkt.randomize())
$finish;
else $display(“Size of payload = %0d”, pkt.payload.size());
end
endprogram
What will $display() show after a few iteration of
randomization if payload.delete() is not
executed?
The randomize() method can allocate new memory if the existing memory size of the array is insufficient to accommodate the randomized payload.size() values. However, if the existing memory of the array is large enough to accommodate the randomized payload.size() value, then the existing memory will be used. The effect is as illustrated below:
Let’s assume that the first randomization of the pkt object above resulted in picking payload.size() to be 5. Since, in the beginning there are no memory already allocated for pkt.payload, therefore randomize() will allocate payload array to payload = new[5] and populate all five indices with random value.
For the second randomization, let’s assume that payload.size() is picked to be 7. Since the existing memory size is insufficient, randomize() will allocate payload array to payload = new[7] (payload) and populate all seven indices with random value.
For the third randomization, let’s assume that payload.size() is picked to be 3. Since there is sufficient memory, randomize() will simply randomize the contents of indices 0 through 2. If you were to display the size of the payload array at this point, the payload.size() will be 7 NOT 3. For many applications, this will lead to errors.
To prevent this behavior from becoming a problem, you should de-allocate the payload array before randomization. The proper place to do this is in the pre_randomize() method.
OOP Randomization
SVTB
8-18© 2006
188-
Applying post_randomize()
� Use post_randomize() to:
� Make necessary corrections after randomization
� Print debug messages
program automatic router_test;
class Packet;
rand bit[3:0] sa, da;
rand bit[7:0] payload[];
bit[15:0] crc;
constraint LimitA { … }
function void pre_randomize(); … endfunction
function void post_randomize();
crc = gen_crc();
endfunction
endclass
initial begin
int status
Packet pkt1 = new();
status = pkt1.randomize();
...
end
endprogram
Does it make sense to randomize crc?
rand bit[15:0] crc;
It does not make sense to randomize crc of a packet. However, if crc is left undefined after randomize() method completes, the Packet object now contains invalid information. The simple way around this is to update all dependent variables (like crc) in post_randomize() method.
OOP Randomization
SVTB
8-19© 2006
198-
program automatic test;
class demo;
local rand int x, y, z;
constraint Limit1 { x > 0; x <= 5; }
...
endclass
initial begin
int status;
demo obj_a = new();
status = obj_a.randomize() with { x > 3 && x < 10; };
...
end
endprogram
Inline Constraints
� Individual invocations of randomize() can be customized
� syntax: obj.randomize( ) with { <new constraints> };
Sometime, the constraint defined within the object being randomized is insufficient to get the desired result. The with { … } construct allows one to solve this problem without the need to go back and modify the original definition of the class. The constraints specified with the with { … } construct is added to the constraints already defined in the original class definition.
For this construct to work effectively, the constraints defined within the original class definition should be as broad as possible within the limits of the DUT spec.
OOP Randomization
SVTB
8-20© 2006
208-
Controlling rand Property Randomization
� Turning randomization for properties on or off with:
1 - enable constraint (default )
0 - disable constraint
When called as function return state of constraint (0 or 1)
task/function int object_name.property.rand_mode ( 0 | 1 );
program automatic test;
class Node;
rand int x, y, z;
constraint Limit1 {
x inside {[0:16]}; y inside {[23:41]};
z < y; z > x;
}
endclass
initial begin
Node obj1 = new();
obj1.x.rand_mode(0);
if (!obj1.randomize()) ...;
end
endprogram
OOP Randomization
SVTB
8-21© 2006
218-
Selective Randomization of Properties
� Randomize selected properties in class by embedding properties in randomize() argument
� The arguments designate the complete set of random variables within that object to be randomized
� All other variables in the object are considered state variables and not randomized
class CA;
rand byte x, y;
byte v, w;
constraint c1 { x < v && y > w );
endclass
CA a = new();
a.randomize(); // random variables: x, y state variables: v, wa.randomize( x ); // random variables: x state variables: y, v, wa.randomize( v, w ); // random variables: v, w state variables: x, ya.randomize( w, x ); // random variables: w, x state variables: y, v
OOP Randomization
SVTB
8-22© 2006
228-
program automatic test;
class demo;
local rand int x, y, z;
constraint Limit1 { x > 0; x <= 16; }
static constraint Limit2 { x > 3; x <= 32; }
endclass
initial begin
demo obj_a = new();
obj_a.Limit1.constraint_mode(0);
if (!obj_a.randomize()) ...;
end
endprogram
Controlling Constraint at Runtime
� Control constraints blocks with:
0 - enable constraint (default )
1 - disable constraint
When called as function return state of constraint (0 or 1)
task/function int object_name.constraint_block_name.constraint_mode ( 0 | 1 );
If a constraint block is declared as static, then calls to constraint_mode() shall affect all instances of the specified constraint in all objects. Thus, if a static constraint is set to OFF, it is off for all instances of that particular class.
OOP Randomization
SVTB
8-23© 2006
238-
Nested Objects with Random Variables
randomize( ) will follow a linked list of object handles, randomizing each linked object to the end of the list.
program automatic test;
class Node;
rand int x, y, z;
constraint Limit1 { x >= 0; x <= 16; }
rand Node next;
Node previous;
...
endclass
initial begin
Node pkt1 = new();
Node pkt2 = new();
...
pkt1.next = pkt2;
...
status = pkt1.randomize( );
end
endprogram This will randomize objects pkt1 and pkt2
OOP Randomization
SVTB
8-24© 2006
248-
Lab 3 Introduction
Encapsulate datain Packet Class
Driver
DUT
90 min
gen()
configure
send()
Encapsulate datain Packet Class
Compile & Simulate
Monitor
recv()Self Check
Packet object
OOP Randomization
SVTB
8-25© 2006
258-
Unit Objectives Review
Having completed this unit, you should be able to:
� Explain why randomization is needed in verification
� Randomize variables
� Constrain randomization of variables
OOP Randomization
SVTB
8-26© 2006
This page was intentionally left blank.
OOP InheritanceSVTB
9-1© 2006
19-
Functional Coverage10
Customer SupportCS
9Object Oriented Programming (OOP)
– Inheritance
Agenda
DAY
3333
SystemVerilog RVM (VMM) Overview11
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
OOP InheritanceSVTB
9-2© 2006
29-
Unit Objectives
After completing this unit, you should be able to:
� Create OOP extended classes
� Access class members in inheritance hierarchy
OOP InheritanceSVTB
9-3© 2006
39-
Object Oriented Programming: Inheritance
� Object-oriented programming
� New classes derived from original (base) class
� Inherits all contents of base class
class MyPacket extends Packet;
DA
SA
DATA
CRC
task display();
...
endtask
function bit[31:0] compute_crc();
...
endfunction
is_goodfunction bit[31:0] compute_crc()
crc = super.compute_crc();
if (!is_good) crc = $random;
endfunction
Can overridemethods
in base class
Can call overriddenbehavior
Packet
MyPacket
my_packet
packet
UML
OOP InheritanceSVTB
9-4© 2006
49-
Object Oriented Programming: Inheritance
� Derived classes compatible with base class
� Can reuse code
task transmit(Packet pkt);
...
endtask
Packet pkt = ...;
transmit(pkt);
MyPacket my_pkt = ...;
transmit(my_pkt);
OK
Packet
MyPacket
Use$cast()
pkt = my_pkt;
Error my_pkt = pkt;
OK $cast(my_pkt, pkt);
Compatible
Compatible
Base class
Derived class
OOP InheritanceSVTB
9-5© 2006
59-
� Which method gets called?
OOP: Polymorphism
MyPacket extends Packet
DA
SA
DATA
CRC
function bit[31:0] compute_crc();
...
endfunction
is_goodfunction bit[31:0] compute_crc();
...
endfunction
Packet p1 = new();
MyPacket p2 = new();
p1.crc = p1.compute_crc();
P2.crc = p2.compute_crc();
p1.crc = crc(p1);
p2.crc = crc(p2);
p
function bit[31:0] crc(Packet pkt);
crc = pkt.compute_crc();
endfunction
OOP InheritanceSVTB
9-6© 2006
69-
� If compute_crc() is virtual
OOP: Polymorphism
my_packet extends packet
DA
SA
DATA
CRC
virtual
function bit[31:0] compute_crc();
...
endfunction
is_goodvirtual
function bit[31:0] compute_crc();
...
endfunction
p
Packet p1 = new();
MyPacket p2 = new();
p1.crc = p1.compute_crc();
P2.crc = p2.compute_crc();
p1.crc = crc(p1);
p2.crc = crc(p2);
function bit[31:0] crc(Packet pkt);
crc = pkt.compute_crc();
endfunction
OOP InheritanceSVTB
9-7© 2006
79-
Data Protection: Local
� Local members of a base class are not accessible
in the derived class
MyPacket extends Packet
DA
SA
DATA
CRC
task display();
...
endtask
function bit[31:0] compute_crc();
...
endfunction
Good/Badfunction bit[31:0] compute_crc();
crc = super.compute_crc();
if (!is_good) crc = $random;
DONE = 1’b1;
endfunction
Packet
MyPacket
local int DONE;
Error
OOP InheritanceSVTB
9-8© 2006
89-
Data Protection: Protected
� Protected members of a base class are accessible
in the derived class, but not to external code
MyPacket extends Packet
DA
SA
DATA
CRC
task display();
...
endtask
function bit[31:0] compute_crc();
...
endfunction
Good/Badfunction bit[31:0] compute_crc();
crc = super.compute_crc();
if (!is_good) crc = $random();
DONE = 1’b1;
endfunction
Packet
MyPacket
protected int DONE;
Good
OOP InheritanceSVTB
9-9© 2006
99-
Test For Understanding
� Will the following code compile?
� Which one of the task new() is executed?
class A;
protected int a;
function int get_a(); begin get_a = a; endfunction
function new(int b); begin a = b; endfunction
endclass
class B extends A;
int b = 1000;
task print_a(); begin $display("a is %d", get_a()); endtask
endclass
class C extends B;
int a;
function new(int c); begin a = c; endfunction
endclass
program test;
C test_c = new();
test_c.print_a();
endprogram
OOP InheritanceSVTB
9-10© 2006
109-
Test For Understanding: Answer
� VCS will attempt to execute every task new()
� If task new is not defined, VCS inserts one:
function new(); begin super.new(); endfunction
� Resulting in syntax error:
class A;
protected int a;
function int get_a(); begin get_a = a; endfunction
function new(int b) begin a = b; endfunction
endclass
class B extends A;
int b = 1000;
task print_a(); begin $display("a is %d", get_a()); endtask
function new(); begin super.new(); endfunction
endclass
class C extends B;
int a;
function new(int c); begin super.new(); a = c; endfunction
endclass ...
Mismatching argument list
OOP InheritanceSVTB
9-11© 2006
119-
Test For Understanding: Solution
� Always call super.new() as the first statement in constructor
� If super.new() is called anywhere except as the first statement, a syntax error will also result
� In the super.new() call, provide the correct argument set
class A;
protected int a;
function int get_a(); begin get_a = a; endfunction
function new(int b); begin a = b; endfunction
endclass
class B extends A;
int b = 1000;
task print_a(); begin $display("a is %d", get_a()); endtask
function new(int a); begin super.new(a); endfunction
endclass
class C extends B;
int a;
function new(int c); begin super.new(c); a = c; endfunction
endclass ...
OOP InheritanceSVTB
9-12© 2006
129-
Unit Objectives Review
Having completed this unit, you should be able to:
� Create OOP extended classes
� Access class members in inheritance hierarchy
Functional Coverage
SVTB
10-1© 2006
110-
Functional Coverage10
Customer SupportCS
9Object Oriented Programming (OOP)
– Inheritance
Agenda
DAY
3333
SystemVerilog RVM (VMM) Overview11
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
Functional Coverage
SVTB
10-2© 2006
210-
Unit Objectives
After completing this unit, you should be able to:
� Define functional coverage structures
� Specify the coverage sample mechanisms
� Define signals and variables to be sampled
� Specify the expected values that indicate functionality
� Utilize parameterization to make coverage instances unique
� Use coverage attributes to customize individual coverage structures
� Measure coverage dynamically
Functional Coverage
SVTB
10-3© 2006
310-
Phases of Verification
� How do you know
� When verification goal has been reached?
� When to switch to corner-case Verification?
� When to write directed tests for difficult to reach corner-case Verification?
Time
Goal
Build verification
environment
Broad-Spectrum
Verification
Preliminary
Verification Difficult to reach
Corner-case
Verification
Corner-case
Verification
% Coverage
The process of reaching the verification goal starts with the definition of the verification goal.
What does it mean to be done with testing? Typically, the answer lie in the functional coverage spec within a verification plan. The goal is then to reach 100% coverage of the defined functional coverage spec in the verification plan.
Once the goal has been defined, the first step in constructing the testbench is to build the verification environment.
To verify the the environment is set up correctly, preliminary verification tests are usually executed to wring out the preliminary RTL and testbench errors.
When the testbench environment is deemed to be stable, broad-spectrum verification based on random stimulus generation is utilized to quickly detect and correct the majority of the bugs in both RTL code and testbench code.
Based on functional coverage analysis, the random-based tests are then constrained to focus on corner-cases not yet reached via broad-spectrum testing.
Finally, for the very difficult to reach corner cases, customized directed tests are used to bring the coverage up to 100%.
Verification is complete when you reach 100% coverage as defined in the verification plan.
Functional Coverage
SVTB
10-4© 2006
410-
The Testbench Environment/Architecture
� Implement functional coverage to answer these
questions
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure Are we there yet?
Functional Coverage
SVTB
10-5© 2006
510-
2 to 4
D ecod er
In [0 ]
In [1 ]
O u t[0 ]
O u t[1 ]
O u t[2 ]
O u t[3 ]
In[1] In[0] Out[3] Out[2] Out[1] Out[0]
0 0 0 0 0 1
0 1 0 0 1 0
1 0 0 1 0 0
1 1 1 0 0 0
Combinational Logic Example
Goal: Check all combinations of input and output patterns
� Create state coverage bins to track input & output bit
patterns
� Define sample timing for coverage bins
� Track state coverage bin results
Functional Coverage
SVTB
10-6© 2006
610-
S1 ⇒⇒⇒⇒ S2 ⇒⇒⇒⇒ S3 ⇒⇒⇒⇒ S1 ⇒⇒⇒⇒ S4 ⇒⇒⇒⇒ S2 ⇒⇒⇒⇒ S2 ⇒⇒⇒⇒ S3 ⇒⇒⇒⇒ S1
State Transition Example
Goal: Check temporal state transitions
� Create state coverage bins to monitor states
� Create transition coverage bins to monitor state transitions
� Define sample timing for coverage bins
� Track transition coverage bin results
S1
S4 S2
S3
RESET
10
11
01
0
0
Functional Coverage
SVTB
10-7© 2006
710-
Cross Correlation Example
Goal: Check all input ports have driven all output ports
� Create cross coverage bins to correlate activities of input ports with respect to output ports
� Define sample timing for coverage bins
� Track cross coverage bin results
Router
1415
1515
……
20
10
00
Output portInput port
Functional Coverage
SVTB
10-8© 2006
810-
Functional Coverage in SystemVerilog
� Create a coverage group which encapsulates:
� Coverage bins definitions
� State
� Transition
� Cross correlation
� Coverage bins sample timing definition
� Coverage attributes
� Example: coverage goal
� Instantiate coverage object(s) from coverage group
� Query coverage object to determine progress of verification
� Scope of variable visibility is same as subroutines
Functional Coverage
SVTB
10-9© 2006
910-
Functional Coverage Example
covergroup fcov(bit[3:0] sa, bit[3:0] da, event port_event) @(port_event);
coverpoint sa { bins input_ports[] = { [0:15] }; }
coverpoint da { bins output_ports[] = { [0:15] }; }
cross sa, da;
option.goal = 100;
endgroup
program router_test;
byte sa, da;
event port_event;
fcov port_fc = new(sa, da, port_event);
...
while (!($get_coverage() == 100)) begin
...
sa = pkt_ref.sa;
da = pkt_ref.da;
->port_event;
// port_fc.sample(); // alternative form of updating of bins
end
...
endprogram
Create coverage group
Instantiate and construct
coverage object
Query coverage result
The covergroup can also be embedded inside a class. The advantage of creating the covergroup inside the class definition is that the covergroup automatically has access to all properties of the class without having an I/O argument. The down side is that, this covergroup can not be re-used.
class Scoreboard; Packet pkt2send, pkt2cmp;bit[3:0] sa, da;covergroup router_cov; coverpoint sa;coverpoint da;cross sa, da;option.goal = 100;
endgroupfunction new(...);router_cov = new(); // still need to be constructed
endfunctiontask check();... if (pkt2send.compare(pkt2cmp, message)) beginsa = pkt2send.sa;da = pkt2send.da;router_cov.sample();coverage_result = $get_coverage(); if ((coverage_result == 100) || (...)->DONE;
endendtask
endclass
Functional Coverage
SVTB
10-10© 2006
1010-
State Bin Creation (Automatic)
� SystemVerilog automatically creates state bins
� Bin name is “auto[value_range]”
� The value_range are the value range which triggered that bin
� By default, VCS create 64 bins. Values are equally distributed
in each bin
� Can be controlled using the auto_bin_max attribute
� Bins are allocated with equal number of states
covergroup cov1 @(posedge router.clock);
coverpoint sa;
coverpoint da;
port_comp: coverpoint (sa > da);
port_comb: coverpoint {sa, da} {
option.auto_bin_max = 256;
}
endgroup
Functional Coverage
SVTB
10-11© 2006
1110-
Measuring Coverage
Without auto binning:
� Coverage is:
With auto binning:
auto_bin_max limit the number of bins used in the
coverage calculation
� Coverage is:
# of bins covered (have at_least hits)
min( possible values for data type | auto_bin_max)
# of bins covered (have at_least hits)
# of total bins
Functional Coverage
SVTB
10-12© 2006
1210-
Automatic State Bin Creation Example
bit[3:0] x, y;covergroup cov1 @(router.cb);coverpoint x;coverpoint y;option.auto_bin_max = 2; // maximum of 2 auto-created bins
endgroup…cov1 = new(); x = 1;y = 8;@(router.cb);
$display(“%0d covered”, $get_coverage());x = 9;y = 9;@(router.cb);
x = 3;y = 5;@(router.cb);
$display(“%0d covered”, $get_coverage());
y
x
Var
1auto[8:f]
1auto[0:7]
#HitBin
1auto[8:f]
y
x
Var
2auto[8:f]
1auto[0:7]
#Hitbin
1auto[8:f]x
Var
2auto[0:7]
#Hitbin
(50% covered)
(75% covered)
2auto[8:f]y
1auto[0:7]
(100% covered)
Functional Coverage
SVTB
10-13© 2006
1310-
State and Transition Bin Creation (User)
� Define state bins using ranges of values
� Define transition bins using state transitions
covergroup MyCov() @(cov_event);
coverpoint port_number {
bins s0 = { [0:7] }; // creates one state bin
bins s1[] = { [8:15] }; // creates 8 state bins
// s1_0 through s1_f
ignore_bins ignore = { 16, 20 }; // ignore if hit
illegal_bins bad = default; // terminates simulation if hit
// default refers to undefined values
bins t0 = ([0:7], 9 => [8:15] => 0); // creates one transition bin
bins t1[] = (8, [0:7] => [8:15]); // creates 72 transition bins
bins other_trans = default sequence; // all other transitions
// illegal_bins bad_trans = default sequence; // terminates simulation
}
endgroup
Functional Coverage
SVTB
10-14© 2006
1410-
Cross Coverage Bin Creation (Automatic)
� VCS automatically creates cross coverage bins
� Cross bins are create automatically as each set of
unique cross values is seen
� Can be controlled with cross_auto_bin_max
� defaults to all possible combinations
covergroup cov1 @(posedge router.cb);
coverpoint sa;
coverpoint da;
cross sa, da {
option.cross_auto_bin_max = 256;
}
endgroup
Functional Coverage
SVTB
10-15© 2006
1510-
Specifying Sample Event Timing
� Define sample_event in coverage_group
� Valid sample_event_definition:
� @([specified_edge] signals | variables)
� Bins are updated asynchronously as the
sample_event occurs
� Can also use cov_object.sample() to update the bins
� Can be made to update bins at end of simulation time slot by setting option.strobe = 1 in covergroup
covergroup definition_name [(argument_list)] [@(sample_event)];coverpoint coverage_point { ... }
}
Functional Coverage
SVTB
10-16© 2006
1610-
Determining Coverage Progress
� $get_coverage() returns testbench coverage percentage
as a real value
covergroup cov1(int x, int y) @(posedge router.cb);
mode1: coverpoint x {
bins S_1[] = { [34:78], [1:27] };
}
endgroup
program Main;
int a;
real cov_percent;
cov1 c_obj1 = new(a, b);
while (1) begin
cov_percent = $get_coverage();
$display(“%0d covered\n”, cov_percent);
...
end
endprogram
Functional Coverage
SVTB
10-17© 2006
1710-
� Each covergroup contributes equally
� Within covergroup, each coverpoint/cross block
contributes equally
� Attributes change
contributions
Coverage Measurement Example
Cover Group 2
sample % x .33 +
cross % x .33 +
cross % x .33 =
group coverage %
Group 1 % x 0.5 +
Group 2 % x 0.5 =
Coverage Percent
For the coverpoint definition in Group 2,
If there are 10 bins with the default weight of 1,
when 6 bins have at_least hits, the definition’s
contribution to the covergroup is:
.33 x .6 x 1 = .198
If the cross definitions set weight to 0, they
contribute zero, Group 2 will contribute:
(.198 + 0 + 0) x .5 = .1
to the total coverage.
Cover Group 1 Cover Group 2
coverpoint
coverpoint
coverpoint
cross
cross
.5
.5
.33
.33
.33
Functional Coverage
SVTB
10-18© 2006
1810-
Coverage Attributes
� Coverage attributes are defined for entire coverage groups or for individual sample definitions
� Attributes at the coverage group level are overridden at the sample
and cross level
� Attributes may be different for each instance of a coverage object
by passing arguments
covergroup cov1(int var1) @(cov_event);
option.auto_bin_max = var1; // entire group
coverpoint x {
option.auto_bin_max = 4; // just for x
bins lower = { [1:8] };
...
endgroup
Functional Coverage
SVTB
10-19© 2006
1910-
Major Coverage Options (1/2)
� at_least (1):
� Minimum number of times for a bin to be hit to be considered covered
� auto_bin_max (64):
� Maximum number of bins that can be created automatically
� Each bin contains equal number of values
� goal (90):
� Percentage as an integer for a coverage group, cross, or sample to be considered covered
� weight (1):
� Multiplier for coverage bins
Functional Coverage
SVTB
10-20© 2006
2010-
Major Coverage Options (2/2)
� cross_auto_bin_max (231-1):
� Maximum number of bins that can be created automatically
� Beyond this number, hits are dropped
� per_instance (0):
� Specifies whether to collect coverage statistics cumulatively or per instance for a coverage group
Functional Coverage
SVTB
10-21© 2006
2110-
Coverage Result Reporting Utilities
� VCS writes coverage data to a binary database file
� The database file is named <program_name>. db
� Convert to HTML:
ntbCovReport –cov_report <file|directory>
� Convert to Text:
ntbCovReport –cov_text_report <file|directory>
� If file, generate report for the single coverage database file
� If directory, then the data in all coverage database files in
that directory are merged and reported
Functional Coverage
SVTB
10-22© 2006
2210-
Sample HTML Report
Functional Coverage
SVTB
10-23© 2006
2310-
Lab 6 Introduction
Implement Functional Coverage
Compile & Simulate
Implement
functional coverage
Monitor
recvClasscheck()
Driver
DUT
30 min
gen()
sendClass
reset()
build()
configure
coverage
Functional
Coverage
Stop simulation
if coverage goal is met
Functional Coverage
SVTB
10-24© 2006
2410-
Unit Objectives Review
Having completed this unit, you should be able to:
� Define functional coverage structures
� Specify the coverage sample mechanisms
� Define signals and variables to be sampled
� Specify the expected values that indicate functionality
� Utilize parameterization to make coverage instances unique
� Use coverage attributes to customize individual coverage structures
� Measure coverage dynamically
RVM-SV (VMM) OverviewSVTB
11-1© 2006
111-
Functional Coverage10
Customer SupportCS
9Object Oriented Programming (OOP)
– Inheritance
Agenda
DAY
3333
SystemVerilog RVM (VMM) Overview11
© 2006 Synopsys, Inc. All Rights ReservedSynopsys 50-I-052-SSG-001
RVM-SV (VMM) OverviewSVTB
11-2© 2006
211-
Unit Objectives
After completing this unit, you should be able to:
� Describe the RVM-SV testbench architecture
� Describe the RVM-SV environment execution
sequence
� Describe the RVM-SV testcase development
Methodology
RVM-SV (VMM) OverviewSVTB
11-3© 2006
311-
Coverage-Driven Verification
Phases of random stimulus based verification
Time
Goal
Build verification environment
Broad-SpectrumVerification
PreliminaryVerification
Difficult to reachCorner-caseVerification
Corner-caseVerification
% Coverage
The process of reaching the verification goal starts with the definition of the verification goal.
What does it mean to be done with testing? Typically, the answer lie in the functional coverage spec within a verification plan. The goal is then to reach 100% coverage of the defined functional coverage spec in the verification plan.
Once the goal has been defined, the first step in constructing the testbench is to build the verification environment.
To verify the the environment is set up correctly, preliminary verification tests are usually executed to wring out the preliminary RTL and testbench errors.
When the testbench environment is deemed to be stable, broad-spectrum verification based on random stimulus generation is utilized to quickly detect and correct the majority of the bugs in both RTL code and testbench code.
Based on functional coverage analysis, the random-based tests are then constrained to focus on corner-cases not yet reached via broad-spectrum testing.
Finally, for the very difficult to reach corner cases, customized directed tests are used to bring the coverage up to 100%.
Verification is complete when you reach 100% coverage as defined in the verification plan.
RVM-SV (VMM) OverviewSVTB
11-4© 2006
411-
Testbench
The Testbench Environment/Architecture
RTL
Monitor
TransactorSelf Check
Observes datafrom DUT
Identifiestransactions
Checkscorrectness
Coverage
Driver
Generator
DUT
Transactor
Configure
Interfaces
Configures testbench and DUT
Drive DUT
Executestransactions
Createsrandom
transactions
Checkscompleteness
Testcase
RVM-SV (VMM) OverviewSVTB
11-5© 2006
511-
Testbench Considerations: Abstraction
Monitor
TransactorSelf Check
Coverage
Driver
Generator
DUT
Transactor
Configure
Signals(interface)
Device Drivers and Monitors
Transactors
CreatesTest Scenarios
TestcaseCreate individual
Test Cases
RVM-SV (VMM) OverviewSVTB
11-6© 2006
611-
Testbench Considerations: Re-Use
TransactorSelf Check
Coverage
Driver
DUT
Testcase
Monitor
program;
Time
Goal
% Coverage
EnvironmentClass
Transactor
Generator
Test
Configure
� Encapsulate testbench components in OOP Class
RVM-SV (VMM) OverviewSVTB
11-7© 2006
711-
What Does RVM-SV Provide?
� Philosophy
� One environment many tests
� Coverage-driven
� Modeling Approach
� Transactions
� Variant Data
� Transactor Control
� Transactor Interfacing
� Simulation Control
� Coding Standards
� Data & Transactions
� Transactors
� Verification Environments
� Building Blocks
� Transaction Interface
� Message Service
� Event Notification
Codin
g G
uid
elines
Codin
g G
uid
elines
Base ClassesBase Classes
Class LibraryClass Library
RVM-SV (VMM) OverviewSVTB
11-8© 2006
811-
� Base classes:
� vmm_env
� vmm_data
� vmm_xactor
� Class libraries:
� vmm_log
� vmm_notify
� vmm_broadcast
� vmm_scheduler
RVM-SV Base Classes and Macros
� Macros:
� `vmm_channel
� `vmm_atomic_gen
� `vmm_scenario_gen
� `vmm_callback
� `vmm_fatal
� `vmm_error
� `vmm_warning
� `vmm_note
� `vmm_trace
� `vmm_debug
� `vmm_verbose
Provided in the vmm.sv library file:
RVM-SV (VMM) OverviewSVTB
11-9© 2006
911-
� Top-down implementation methodology
� Emphasizes “Coverage Driven Verification”
� Maximize design quality� More testcases� More checks� Less code
� Approaches� Reuse
� Across tests
� Across blocks
� Across systems
� Across projects
� One verification environment, many tests� Minimize test-specific code
RVM Guiding Principles
Constrainable
Random Generation
Functional
Coverage
Many runs,different seeds
Identifyholes
Addconstraints
Minimal Code
Modifications
Directed
Testcase
RVM-SV (VMM) OverviewSVTB
11-10© 2006
1011-
Implementing RVM Testbench
� Need a class to encapsulate verification environment
� Reused by all tests
� Instantiates
� Generators
� Transactors
� Scoreboard
� Coverage model
� Signal Interfaces
� Controls
� Configuration
� Start of simulation
� End of simulation
� Pass/Fail report
TransactorSelf Check
Coverage
Driver
DUT
Monitor
program;
Transactor
Configuration
Generator
env.run();
gen_cfg();
build();
cfg_dut();
start();
wait_for_end();
stop();
cleanup();
report();
vmm_env
reset_dut();
RVM-SV (VMM) OverviewSVTB
11-11© 2006
1111-
program automatic test;
initial begin
dut_env env = new();
env.run();
end
endprogram
Environment Execution Flow
� Conceptually...
task vmm_env::run();
this.gen_cfg();
this.build();
this.reset_dut();
this.cfg_dut();
this.start();
this.wait_for_end();
this.stop();
this.cleanup();
this.report();
endtask
class dut_env extends vmm_env;virtual function void gen_cfg();
...endfunctionvirtual function void build();
...endfunctionvirtual task reset_dut();
...endtaskvirtual task cfg_dut();
...endtaskvirtual task start();
...endtaskvirtual task wait_for_end();
...endtaskvirtual task stop();
...endtaskvirtual task cleanup();
...endtaskvirtual task report();
...endtask
endclass
Randomize test
configuration descriptor
Start components
Allocate and connect
environment components
Download test
configuration into DUT
Stop data generators &
Wait for DUT to drain
Check recorded stats &
sweep for lost data
End-of-test detection
Reset DUT
Report simulation results
RVM-SV (VMM) OverviewSVTB
11-12© 2006
1211-
Execution Flow – Under the hood
� Methods in base class manage
sequencing by ensuring the
previous one has been called
� "state" registers records how far simulation has progressed
� run() calls cleanup() followed by report()
gen_cfg()
build()
cfg_dut()
start()
wait_for_end()
stop()
cleanup()
report()
run_t()
If already been called bytestcase, will not called again
(same for all methods)
If a call to super.method()is left out, the chain is broken
extern class vmm_env {
static int CFG_GENED;
static int BUILT;
static int DUT_RESET;
static int DUT_CFGED;
static int STARTED;
static int RESTARTED;
static int ENDED;
static int STOPPED;
static int CLEANED;
task run();// Do not override
...}
reset_dut()
RVM-SV (VMM) OverviewSVTB
11-13© 2006
1311-
Example: Basic RVM Environment
extern class vmm_env;
vmm_log log;
vmm_notify notify;
...// event flags
function new(string name = “Verif Env");
task run(); // Do not override
virtual function void gen_cfg();
virtual function void build();
virtual task reset_dut();
virtual task cfg_dut();
virtual task start();
virtual task wait_for_end();
virtual task stop();
virtual task cleanup();
virtual task report();
...// other optional methods
endclass
class dut_env extends vmm_env;
virtual function void gen_cfg(); super.gen_cfg(); endfunction
virtual function void build(); super.build(); endfunction
virtual task reset_dut(); super.reset_dut(); endtask
virtual task cfg_dut(); super.cfg_dut(); endtask
virtual task start(); super.start(); endtask
virtual task stop(); super.stop(); endtask
virtual task wait_for_end(); super.wait_for_end(); endtask
virtual task cleanup(); super.cleanup(); endtask
virtual task report(); super.report(); endtask
function new(string name=“Environment”); super.new(name); endfunction
endclass
Extend from vmm_env
gen_cfg();
build();
cfg_dut();
start();
wait_for_end();
stop();
cleanup();
report();
DUT
Generator
program automatic router_test;
`include “vmm.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.run();
end
endprogram
reset_dut();
Instantiate environment object in program
then execute run()
The first step in constructing a SystemVerilog RVM testbench is to build the environment class. This class must inherit from the vmm_env base class.
Within the environment class, 9 methods must be overriden: gen_cfg(), build(), reset_dut(), cfg_dut(), start(), wait_for_end(), stop(), cleanup(), report().
Within the overriden methods, the super class method must be called first.
Once this skeleton structure is built, it can be instantiated and tested immediately within a
SystemVerilog program block.
RVM-SV (VMM) OverviewSVTB
11-14© 2006
1411-
Testing Basic RVM Environment
program automatic router_test;
`include “vmm.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.build();
env.log.set_verbosity(vmm_log::TRACE_SEV);
env.run();
end
endprogramTrace[INTERNAL] on Environment() at 0:
Reseting DUT...
Trace[INTERNAL] on Environment() at 0:
Configuring...
Trace[INTERNAL] on Environment() at 0:
Starting verification environment...
Trace[INTERNAL] on Environment() at 0:
Saving RNG state information...
Trace[INTERNAL] on Environment() at 0:
Waiting for end of test...
Trace[INTERNAL] on Environment() at 0:
Stopping verification environment...
Trace[INTERNAL] on Environment() at 0:
Cleaning up...
Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
If the program block consists only of:
program automatic router_test;
`include “vmm.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.run();
end
endprogram
Simulation will run and finish at time 0 with the following message:
Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
If you want to trace the method executions for debugging purposes, then through the default log instance in the vmm_env class, you can turn on tracing and see the result as shown in slide. (Note: this should be done after the build() phase of the RVM environment is executed.
env.log.set_verbosity(vmm_log::TRACE_SEV);
RVM-SV (VMM) OverviewSVTB
11-15© 2006
1511-
Example: RVM Test Configuration
DUT
gen_cfg();
build();
cfg_dut();
start();
wait_for_end();
stop();
cleanup();
report();
reset_dut();
Configuration
program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.run();
end
endprogram
class dut_env extends vmm_env;
dut_cfg cfg;
function new(string name=“Environment”);
super.new(name);
this.cfg = new();
endfunction
virtual function void gen_cfg();
super.gen_cfg();
if (!this.cfg.randomize()) `vmm_fatal(…);
endfunction
...
endclass Randomize Configuration object
class dut_cfg;
string name
rand int run_for_n_packets;
rand reg drivers_in_use[];
rand reg receivers_in_use[];
rand int num_of_drivers;
rand int num_of_receivers;
constraint valid {
run_for_n_packets >= 0;
num_of_drivers inside {[1:16]};
num_of_receivers inside {[1:16]};
drivers_in_use.sum() == num_of_drivers;
receivers_in_use.sum() == num_of_receivers;
}
function new(string name = “Configuration”);
this.name = name;
drivers_in_use = new[16];
receivers_in_use = new[16];
end function
function void display(string prefix = “”);
...
endfunction
endclass
Create Configuration
The configuration class is intended to define the parameter for a given testcase. You should test the working of the configuration class immediately after creation.
RVM-SV (VMM) OverviewSVTB
11-16© 2006
1611-
Testing RVM Configuration
program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.gen_cfg();
env.cfg.display();
env.run();
end
endprogram
[Configuration] run_for_n_packets = 363730487, num_of_drivers = 9, num_of_receivers = 9
[Configuration] valid input ports: 0, 1, 3, 5, 6, 9, 10, 11, 13,
[Configuration] valid output ports: 0, 1, 2, 3, 5, 7, 8, 9, 10,
Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
If the program block consists only of:
program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.run();
end
endprogram
Simulation will run and finish at time 0 with the following message:
Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
If you want to see what the configuration object contains, you can use the display() method of the configuration object: (Note: this should be done after the gen_cfg() phase of the RVM environment is executed.
env.cfg.display();
RVM-SV (VMM) OverviewSVTB
11-17© 2006
1711-
Set Specific RVM Testcase Configuration
program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.cfg.run_for_n_packets.rand_mode(0);
env.cfg.num_of_drivers.rand_mode(0);
env.cfg.num_of_receivers.rand_mode(0);
env.cfg.run_for_n_packets = 16;
env.cfg.num_of_drivers = 16;
env.cfg.num_of_receivers = 16;
env.gen_cfg();
env.cfg.display();
env.run();
end
endprogram
[Configuration] run_for_n_packets = 16, num_of_drivers = 16, num_of_receivers = 16
[Configuration] valid input ports: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
[Configuration] valid output ports: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
� RVM philosophy: one environment, many tests
� Limit modification to the program block
Although the properties within the configuration object are all set to be random variables, you can
still set these properties to ones of your choosing in the program block.
One way is as shown in the slide: disable randomization then set the properties to your chosen value.
The second way it can be done is to extend from the existing configuration class, modify the
constraint, then replace the configuration object in the environment object with the new
configuration object as shown below:program automatic router_test;`include "vmm.sv"`include “dut_cfg.sv"`include “dut_env.sv"class testConfig extends dut_cfg;constraint test {run_for_n_packets == 16;num_of_drivers == 16;num_of_receivers == 16;
}endclassinitial begindut_env env = new();testConfig cfg = new();env.cfg = cfg;env.gen_cfg();env.cfg.display();env.run();
endendprogram
RVM-SV (VMM) OverviewSVTB
11-18© 2006
1811-
Example: RVM Stimulus Generation
class Packet extends vmm_data;
rand reg[3:0] sa, da;
rand reg[7:0] payload[*];
constraint valid { ... }
...;
endclass
`vmm_channel(Packet)
`vmm_atomic_gen(Packet)
Create Transaction class Packet_atomic_gen extends vmm_xactor;
int stop_after_n_insts, DONE, GENERATED;
Packet randomized_obj; Packet_channel out_chan;
task main(); fork super.main(); join_none
while (stop_after_n_insts …) begin
Packet obj;
if (!randomized_obj.randomize()) begin ...; end
$cast(obj, randomized_obj.copy());
out_chan.put_t(obj);
this.notify.indicate(this.GENERATED, obj);
end
this.notify.indicate(this.DONE);
endtask
endclass
gen_cfg();
build();
cfg_dut();
start();
wait_for_end();
stop();
cleanup();
report();
DUT
program automatic router_test;
initial begin
Environment env = new();
env.run();
end
endprogram
reset_dut();
Configuration
Generator
class Environment extends vmm_env; ...
Packet_atomic_gen gen;
virtual function void build(); ...
gen = new(“Generator”, 0);
gen.stop_after_n_insts = cfg.run_for_n_packets;
gen.out_chan.sink();
endfunction
virtual task start(); ...;
gen.start_xactor();
endtask
virtual task wait_for_end(); ...;
gen.notify.wait_for(Packet_atomic_gen::DONE);
endtask
virtual task stop(); ...;
gen.stop_xactor();
endtask
endclass
Instantiate, build
and start Generator object
Macro
automatically creates generator
RVM-SV (VMM) OverviewSVTB
11-19© 2006
1911-
Testing RVM Atomic Generator
program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “Packet.sv”
`include “dut_env.sv”
class testPacket extends Packet;
function void post_randomize();
super.post_randomize();
this.display(“Randomized Packet”);
endfunction
endclass
initial begin
dut_env env = new();
testPacket pkt = new();
env.build();
env.gen.randomized_obj = pkt;
env.run();
end
endprogram
[Randomized Packet] Packet #0.0.0: sa = 6, da = 3 payload.size() = 1
[Randomized Packet] Packet #0.0.0: payload[0] = 197
[Randomized Packet] Packet #0.0.1: sa = 15, da = 2 payload.size() = 5
[Randomized Packet] Packet #0.0.1: payload[0] = 69
[Randomized Packet] Packet #0.0.1: payload[1] = 244
[Randomized Packet] Packet #0.0.1: payload[2] = 108
[Randomized Packet] Packet #0.0.1: payload[3] = 103
[Randomized Packet] Packet #0.0.1: payload[4] = 140
[Randomized Packet] Packet #0.0.2: sa = 15, da = 8 payload.size() = 3
[Randomized Packet] Packet #0.0.2: payload[0] = 217
[Randomized Packet] Packet #0.0.2: payload[1] = 169
[Randomized Packet] Packet #0.0.2: payload[2] = 170
…
class Packet extends vmm_data;
rand reg[3:0] sa, da;
rand reg[7:0] payload[*];
constraint valid { ... }
...;
endclass
`vmm_channel(Packet)
`vmm_atomic_gen(Packet)
� One environment, many tests applies here also
If the program block consists only of:program automatic router_test;
`include “vmm.sv”
`include “dut_cfg.sv”
`include “Packet.sv”
`include “dut_env.sv”
initial begin
dut_env env = new();
env.run();
end
endprogram
Simulation will run and finish at time 0 with the following message:Simulation PASSED on /./ (/./) at 0 (0 warnings, 0 demoted errors & 0 demoted warnings)
$finish at simulation time 0
If you want to see what the generator created, you can modify the post_randomize() method in randomized_obj with a call to the display() method. To do this, first, extend the existing Packet class with a new testPacket class defintion and add the new post_randomize() method. Then, instantiate and replace the randomize_obj in the generator with the newly created one. (Note: this should be done after the build() phase of the RVM environment is executed)
RVM-SV (VMM) OverviewSVTB
11-20© 2006
2011-
Example: RVM Transactor Class
class DriveXactor extends vmm_xactor;
Packet pkt2send;
Packet_channel in_chan;
function new(...); ...
task send_packet(); ...
virtual protected task main();
fork super.main(); join_none
while(1) begin
wait_if_stopped_or_empty(in_chan);
in_chan.get(pkt2send);
`vmm_callback(DriveXactor_callbacks, pre_transaction(pkt2send));
send();
begin
Packet pkt;
if (!$cast(pkt, pkt2send.copy()) `rvm_fatal(...);
`vmm_callback(DriveXactor_callbacks, post_transaction(pkt));
end
end
endtask
...
endclass
Create input transactor from vmm_xactor base class
Embed functionality in main() method
Callback for error injection
Callback for
coverage, scoreboard pass copied object
RVM-SV (VMM) OverviewSVTB
11-21© 2006
2111-
Example: RVM Coverage (Callbacks)
class Packet_atomic_gen extends vmm_xactor;
virtual protected task main(); ...
while (...) begin
Packet obj;
if (!randomized_obj.randomize()) ...
if (!$cast(obj, randomized_obj.copy()) ...
begin
bit drop = 0;
out_chan.put(obj);
`vmm_callback(Packet_atomic_gen_callbacks, post_inst_gen(this, obj, drop));
this.notify.indicate(this.GENERATED, obj);
end
end
endtask
endclass
� RVM philosophy: coverage-driven verification
� Implementing functional coverage is a four step process:
� Insert callback method in transactor with `vmm_callback macro
� Build callback façade class
� Define callback class functionality
� Register callback objects in environment
Name of
callback façade class
Callback macro
callback method
Step 1 is already done for you when you use
`vmm_atomic_gen macro
RVM-SV (VMM) OverviewSVTB
11-22© 2006
2211-
RVM Coverage Continued
class Packet_atomic_gen_callbacks extends vmm_xactor_callbacks;
virtual task post_inst_gen(Packet_atomic_gen gen, Packet obj, ref bit drop);
endtask
endclass
� Step 2: build callback façade class
� Step 3: define callback class functionality
Callback method prototype with empty body
callback method
class Packet_gen_cov_callbacks extends Packet_atomic_gen_callbacks;
bit[3:0] sa, da;
covergroup gen_port_cov;
coverpoint sa;
coverpoint da;
cross sa, da;
endgroup
function new(); gen_port_cov = new(); endfunction
virtual task post_inst_gen(Packet_atomic_gen gen, Packet pkt, ref bit drop);
this.sa = pkt.sa;
this.da = pkt.da;
gen_port_cov.sample();
endtask
endclass
Define callback functionality
Trigger coverage bin update
Create coverage bins
Construct coverage object
Step 2 is already done for you when you use
`vmm_atomic_gen macro
RVM-SV (VMM) OverviewSVTB
11-23© 2006
2311-
RVM Coverage Continued
� Step 4: register callback objects in environment
� Once registered, the callback method for functional
coverage will be executed every time the generator
deposits an object into out_chan
class dut_env extends vmm_env;
dut_cfg cfg;
Packet_atomic_gen gen;
Packet_gen_cov_callbacks gen_cov_cb;
function new(); ...
virtual function void gen_cfg(); ...
virtual function void build();
super.build();
gen = new("gen", 0);
gen.stop_after_n_insts = cfg.run_for_n_packets;
gen.out_chan.sink();
gen_cov_cb = new();
gen.append_callback(gen_cov_cb);
endfunction
virtual task reset_dut();
...
endclass
Create callback coverage object
Construct callback coverage object
Register callback coverage object
RVM-SV (VMM) OverviewSVTB
11-24© 2006
2411-
Testing RVM Coverage
program automatic router_test;
`include "vmm.sv"
`include “dut_cfg.sv"
`include "packet.sv"
`include “gen_cov_cb.sv"
`include “dut_env.sv"
initial begin
dut_env env = new();
env.run();
end
endprogram
./simv | tee log
ntbCovReport -cov_report ./
class Packet_gen_cov_callbacks
...
covergroup gen_port_cov;
coverpoint sa;
coverpoint da;
cross sa, da;
endgroup
...
endclass
RVM-SV (VMM) OverviewSVTB
11-25© 2006
2511-
Example: Implementing RVM Scoreboard
class dut_sb extends vmm_xactor;
static int DONE;
static int pkts_generated = 0, pkts_sent = 0, pkts_received = 0, pkts_checked = 0;
Packet sentPkts[$];
function new(...);
virtual function void deposit_sentpkt(Packet pkt);
virtual function void deposit_receivedPkt(Packet pkt);
virtual function void deposit_genpkt(Packet pkt);
string message;
genPkts.push_back(pkt);
pkts_generated++;
if (check_coverage(message))
this.notify.indicate(this.DONE);
$display(message);
endfunction
virtual function bit check_coverage(ref string message);
coverage_result = $get_coverage();
if ( coverage_result == 100 || ... ) begin
message = $psprintf(“Coverage = %0d", coverage_result));
check_coverage = 1;
end
else ...;
end
endfunction
virtual task final_check();
virtual function void report();
endclass
Inherit from vmm_xactor
Scoreboard track matrix variables
Methods for transactors to deposit objects to scoreboard
Detecting terminating conditions
Indicates terminating condition found
Cleanup and report methods
RVM-SV (VMM) OverviewSVTB
11-26© 2006
2611-
Example: RVM Scoreboard Continued
class Packet_atomic_gen extends vmm_xactor;
virtual protected task main(); ...
while (...) begin
Packet obj;
if (!randomized_obj.randomize()) ...
if (!$cast(obj, randomized_obj.copy()) ...
begin
bit drop = 0;
out_chan.put(obj);
`vmm_callback(Packet_atomic_gen_callbacks, post_inst_gen(this, obj, drop));
this.notify.indicate(this.GENERATED, obj);
end
end
endtask
endclass
� Then, link scoreboard to transactors via callbacks
� Same four step process:
� Insert callback method in transactor with `vmm_callback macro
� Build callback façade class
� Define callback class functionality
� Register callback objects in environment
Do nothing in step 1 if you have already inserted callbacks for coverage
RVM-SV (VMM) OverviewSVTB
11-27© 2006
2711-
RVM Scoreboard Callbacks
class Packet_gen_sb_callbacks extends Packet_atomic_gen_callbacks;
dut_sb sb;
function new(dut_sb sb);
this.sb = sb;
endfunction
virtual task post_inst_gen(Packet_atomic_gen gen, Packet pkt, ref bit drop);
sb.deposit_genpkt(pkt);
endtask
endclass
� Step 2: Build callback façade class
� Already done if coverage was implemented
� Step 3: Define callback class functionality
Pass in scoreboard handle in constructor
Pass object to scoreboard via scoreboard handle
class Packet_atomic_gen_callbacks extends vmm_xactor_callbacks;
virtual task post_inst_gen(Packet_atomic_gen gen, Packet obj, ref bit drop);
endtask
endclass
Build scoreboard callback class
RVM-SV (VMM) OverviewSVTB
11-28© 2006
2811-
RVM Scoreboard Callbacks
� Step 4: register callback objects in environment
class dut_env extends vmm_env;
...;
Packet_atomic_gen gen;
Packet_gen_cov_callbakcs gen_cov_cb;
dut_sb sb;
Packet_gen_sb_callbacks gen_sb_cb;
function new(); ...
virtual function void gen_cfg(); ...
virtual function void build();
...;
gen = new("gen", 0);
...;
sb = new("sb", "class", cfg);
gen_cov_cb = new();
gen_sb_cb = new();
gen.append_callback(gen_cov_cb);
gen.append_callback(gen_sb_cb);
endfunction
virtual task wait_for_end();
sb.notify.wait_for(sb.DONE);
endtask
endclass
Create scoreboard and callback object
Construct scoreboard callback object
Register scoreboard callback object
RVM-SV (VMM) OverviewSVTB
11-29© 2006
2911-
� Top-down implementation methodology
� Emphasizes “Coverage Driven Verification”
� Maximize design quality� More testcases� More checks� Less code
� Approaches� Reuse
� Across tests
� Across blocks
� Across systems
� Across projects
� One verification environment, many tests� Minimize test-specific code
Summary: RVM Guiding Principles
Constrainable
Random Generation
Functional
Coverage
Many runs,different seeds
Identifyholes
Addconstraints
Minimal Code
Modifications
Directed
Testcase
RVM-SV (VMM) OverviewSVTB
11-30© 2006
3011-
Unit Objectives Review
Having completed this unit, you should be able to:
� Describe the RVM-SV testbench architecture
� Describe the RVM-SV environment execution
sequence
� Describe the RVM-SV testcase development
Methodology
RVM-SV (VMM) OverviewSVTB
11-31© 2006
Appendix
RVM-OV vs. RVM-SV
RVM-SV (VMM) OverviewSVTB
11-32© 2006
3211-
RVM-OV vs. RVM-SV
� Classes
rvm_log
rvm_env
rvm_data
rvm_channel_class
rvm_xactor
rvm_notify
rvm_broadcast
rvm_scheduler
vmm_log
vmm_env
vmm_data
vmm_channel
vmm_xactor
vmm_notify
vmm_broadcast
vmm_scheduler
RVMRVM--OVOV RVMRVM--SVSV
RVM-SV (VMM) OverviewSVTB
11-33© 2006
3311-
RVM-OV vs. RVM-SV
� Macros
rvm_fatal
rvm_error
rvm_warning
rvm_note
rvm_trace
rvm_debug
rvm_verbose
rvm_channel
rvm_atomic_gen
rvm_scenario_gen
rvm_OO_callback
RVMRVM--OVOV RVMRVM--SVSV
`vmm_fatal
`vmm_error
`vmm_warning
`vmm_note
`vmm_trace
`vmm_debug
`vmm_verbose
`vmm_channel
`vmm_atomic_gen
`vmm_scenario_gen
`vmm_callback
RVM-SV (VMM) OverviewSVTB
11-34© 2006
3411-
RVM-OV vs RVM-SV
� Functions are nonblocking in SV
rvm_env::gen_cfg()
rvm_env::build()
rvm_env::reset_dut_t()
rvm_env::cfg_dut_t()
rvm_env::start_t()
rvm_env::wait_for_end_t()
rvm_env::stop_t()
rvm_env::cleanup_t()
rvm_env::report()
RVMRVM--OVOV RVMRVM--SVSV
vmm_env::gen_cfg()
vmm_env::build()
vmm_env::reset_dut()
vmm_env::cfg_dut()
vmm_env::start()
vmm_env::wait_for_end()
vmm_env::stop()
vmm_env::cleanup()
vmm_env::report()
No "_t"No "_t"
"_t" "_t" --> task> task
functionfunction
tasktask
Changed from function to taskChanged from function to task
RVM-SV (VMM) OverviewSVTB
11-35© 2006
3511-
RVM-OV vs RVM-SV
� Input channels (RVM-OV)
� Becomes (RVM-SV)
tr = in_chan.get_t();
tr = in_chan.peek_t();
tr = in_chan.activate_t();
FunctionsFunctions
in_chan.get(tr);
in_chan.peek(tr);
in_chan.activate(tr);
TasksTasks
Functions areFunctions are
nonblockingnonblocking in SVin SV
RVM-SV (VMM) OverviewSVTB
11-36© 2006
3611-
RVM-OV vs RVM-SV
� Class-level symbolic values (RVM-OV)
� Becomes (RVM-SV)
log.set_verbosity(log.DEBUG_SEV);
Static class propertyStatic class property
in OVin OV
log.set_verbosity(vmm_log::DEBUG_SEV);
ClassClass--level level enumenum
in SVin SV
RVM-SV (VMM) OverviewSVTB
11-37© 2006
3711-
RVM-OV vs RVM-SV
� Waiting for next transaction (RVM-OV)
� Use (RVM-SV)
vmm_xactor::next_transaction(chan)
rvm_xactor::next_transaction_t(chan)
Does notDoes not
existexist
DeprecatedDeprecated
vmm_xactor::wait_if_stopped_or_empty(chan);
chan.peek(tr);
rvm_xactor::wait_if_stopped_or_empty_t(chan);
tr = chan.peek_t();
Notifications automatically handledNotifications automatically handled
(XACTOR_IDLE, XACTOR_BUSY)(XACTOR_IDLE, XACTOR_BUSY)
RVM-SV (VMM) OverviewSVTB
11-38© 2006
3811-
RVM-OV vs RVM-SV
� Time unit display
� Part of format string in OV
� Time unit defined by Vera shell timescale
� Uses built-in %t formatter in SV
� Use %t and $timeformat()
� Time unit globally defined
� Also applies to RVM-OV in NTB
RVM-SV (VMM) OverviewSVTB
11-39© 2006
3911-
RVM-OV vs RVM-SV
� Physical interfaces
� In OV
� Define interface for each clocking domain, connect using hdl_node
� Define virtual port
� Bind interface signals to virtual port instance
� Class written using virtual port
� Pass virtual port instance to class via constructor
RVM-SV (VMM) OverviewSVTB
11-40© 2006
4011-
RVM-OV vs RVM-SV
� Physical interfaces
� In SV
� Define interface for each signal bundle
– Signals defined as wire
– One clocking block per clocking domain
– One modport per agent
� Instantiate interface in top-level module, connect using continuous assign
� Class written using virtual modport
� Pass modport instance to class via constructor
RVM-SV (VMM) OverviewSVTB
11-41© 2006
4111-
Planning for RVM-SV
� When using RVM-OV
� Keep all functions nonblocking
� Only block tasks
� Do not wait on clock edges
� Use void expects or drive
RVM-SV (VMM) OverviewSVTB
11-42© 2006
This page was intentionally left blank.
Customer Support CS-1© 2005
Customer Support
© 2005 Synopsys, Inc. All Rights Reserved 20050516
Customer Support CS-2© 2005
2CS-
Synopsys Support Resources
1. Build Your Expertise: Customer Education Services� www.synopsys.com
� Workshop schedule and registration� Download materials (SolvNet id
required)
2. Empower Yourself: solvnet.synopsys.com
� Online technical information and access to support resources
� Documentation & Media
3. Access Synopsys Experts: Support Center
Customer Support CS-3© 2005
3CS-
� Immediate access to the latest technical information
� Thousands of expert-authored articles, Q&As, scripts and tool tips
� Enter-a-call online Support Center access
� Release information
� Online documentation
� License keys
� Electronic software downloads
� Synopsys announcements (latest tool, event and product information)
SolvNet Online Support Offers
Customer Support CS-4© 2005
4CS-
SolvNet Registration is Easy
1. Go to solvnet.synopsys.com/ ProcessRegistration
2. Pick a username and password.
3. You will need your “Site ID” on the following page.
4. Authorization typically takes
just a few minutes.
Customer Support CS-5© 2005
5CS-
Support Center: AE-based Support
� Industry seasoned Application Engineers:
� 50% of the support staff has > 5 years applied experience
� Many tool specialist AEs with > 12 years industry experience
� Access to internal support resources
� Great wealth of applied knowledge:
� Service >2000 issues per month
� Remote access and debug via ViewConnect
� Contact us:
� Web: Enter A Call from solvnet.synopsys.com
� See http://www.synopsys.com/support
for local support resources
Fastest access
Customer Support CS-6© 2005
6CS-
Other Technical Sources
� Application Consultants (ACs):
� Tool and methodology pre-sales support
� Contact your Sales Account Manager for more information
� Synopsys Professional Services (SPS) Consultants:
� Available for in-depth, on-site, dedicated, custom consulting
� Contact your Sales Account Manager for more details
� SNUG (Synopsys Users Group):
� www.snug-universal.org
Customer Support CS-7© 2005
7CS-
Summary: Getting Support
� Customer Education Services
� SolvNet
� Support Center
� SNUG
Customer Support CS-8© 2005
This page was intentionally left blank.