vmm companion guide

8/9/2019 Vmm Companion Guide

1/38


2/38


3/38


4/38

VMM for SystemVerilog

Companion Guide

Version 1.1, December 2007

Copyright 2006-2007 Doulos Ltd. All Rights Reserved

The information contained herein is the property ofDoulos Ltd. and is supplied without liability for errors oromissions. No part may be used, stored, transmittedor reproduced in any form or medium without thewritten permission of Doulos Ltd.

Doulos is a registered trademark of Doulos Ltd.

Trademarks/Copyright 2006 Synopsys, Inc. AllRights Reserved.

VCS is a registered trademark of Synopsys, Inc.

Copyright 2006 ARM Ltd. All rights reserved.

ARM is a registered trademark of ARM Ltd.

First published in 2006 by Doulos

DoulosChurch Hatch

22 Market PlaceRingwoodHampshireBH24 1AWUK

Tel +44 (0) 1425 471223Fax +44 (0) 1425 471573

Email: [email protected]: http://www.doulos.com
http://www.synopsys.com/copyright.htmlhttp://www.doulos.com/http://www.doulos.com/http://www.synopsys.com/copyright.html


5/38

1

VMM for SystemVerilogCompanion Guide

This Companion Guide provides a handy quick reference for users of theVerification Methodology Manual(VMM) for SystemVerilog, a professionalbook co-authored by verification experts from ARM Ltd. and Synopsys, Inc.

and published by Springer Science and Business Media (ISBN 0-387-25538-9).

The Companion Guide is not intended to replace either the VMM forSystemVerilogor a proper training course. It assists the engineer inidentifying the exact signature of a particular method, or the set of methodsthey have inherited from a certain base class. It is suitable as a very brieftechnical introduction to the aims and structure of the VMM methodology, andalso contains reference information on how to use the VMM Standard Library

with the Synopsys VCS solution.

Complete code for the Example VMM System, as outlined on pages 7 to 14,can be downloaded from the Doulos web site:

http://www.doulos.com/knowhow/sysverilog
http://www.doulos.com/knowhow/sysveriloghttp://www.doulos.com/knowhow/sysverilog


6/38

2


7/38

Introduction

3

The VMM for SystemVerilog describes a flexible, scalable verificationmethodology for SystemVerilog users. It is possible to use concepts from the

VMM methodology both in small ad-hoc testbenches for module testing andin the creation of large, complex high-grade verification environments byspecialized verification engineers.

The VMM for SystemVerilog contains detailed implementation rules andrecommendations to aid in the adoption of this methodology. These rules andrecommendations can also provide useful guidance for those who are new tocomplex verification.

The VMM Standard Library provides base classes for key aspects of theverification environment, an event notification service, and a message

logging service. VMM-compliant test environments must use these baseclasses, suitably extended to provide any required custom functionality.

Transaction data in a VMM-compliant testbench are objects of one or moreuser-defined classes derived from the provided base class vmm_data. Suchobjects are produced by a transactor, which is derived from vmm_xactor.Some transactors are the source of a data stream, generating data accordingto constraints; they are known as generators. Other transactors take dataitems from a channel, perform some transformation, then add the item to adownstream channel; they are said to be functional-level transactors. Some

transactors at the lowest level of the testbench, communicating directly withthe design by means of a pin-level interface, are known as command-leveltransactors.

Transactors pass transactions from one to another through channels. Agenerator creates a series of data items, then places references to thosedate items into a channel. Another transactor can read the next referencefrom the channel and perform any required operation on that data beforeplacing the reference in the next channel. The creation of channels for anygiven transaction type is automated by a macro `vmm_channel.

A notification service, based on vmm_notify, gives us much more than isavailable using event variables. The operation of the notification is defined atconfiguration time, and notification can have status and timestampinformation attached. Notification is used by transactors and channels tomark activity and for synchronization.

The environment, based on vmm_env, is where all these objects areinstanced. At the top of the object instance hierarchy is the testcase, whichchooses, configures and runs a particular environment. The testcase isremote from the event-driven world of signals, but has the ability to control

the environment at any level.


8/38

Introduction

4

A single source of transactions can feed many consumers using avmm_broadcast object. Conversely, multiple sources can be merged into asingle stream of transactions using vmm_scheduler.

The message service, based on vmm_log, provides a mechanism forreporting interesting activity to output files or the simulator console. Using apredefined message mechanism gives us consistency (post-processing andinterpretation), localization (identification and control of source),configurability (control of message severity and type), and control (effect onsimulation behavior). All textual output from a VMM-compliant testenvironment should use the message service.


9/38

Introduction

5

The diagram below shows the structure of a small VMM-compliant testbench.The transactors that drive the DUT form a protocol stack, with the simplest

transactions (signal transitions) at the lowest level of DUT interface, and themost complex (scenarios) coming from the generator at the top. We showone level of functional-level transactor, but there could be more if required.Similarly, the monitoring transactors form a protocol stack. Connection to theDUT is implemented in a standardized way using the SystemVeriloginterface construct see the extended example, and the section onCommand-level transactors, for more detail.

Test case

DUT

Environment - vmm_env

Generatorvmm_atomic_gen

Transactorvmm_xactor

Transactor

vmm_xactor

Monitorvmm_xactor

Monitor

vmm_xactor

Functional-level

scoreboard

Scenario-levelscoreboard

vmm_channel

vmm_channel vmm_channel

Interface

Test harness

Command-level

Functional-level

Scenario-levelCallback

Callback

Callback

Callback

Virtual interface

Interface

Virtual interface

Program

test_env env = new;env.run; Constraints

Note:

Callbacks from a generator use a faade class derived fromatomic_gen_callbacks. Callbacks from other transactors use a faadederived from vmm_xactor_callbacks.


10/38

6


11/38

Example VMM System

7

Defining transaction data

We start by describing our transaction data using an extension ofvmm_data.We describe how a transaction is made up, with constraints that definesuitable data values; and we supply necessary methods, including a deepcopy and a method for checking data validity.

class packet_trans extends vmm_data;

import types::*;

static vmm_log log = new ("packet_trans", "class");

// User-defined data contents of the transaction, declaredrand

rand packet_t packet;

// Each transaction is given a unique serial number

static byte packet_num;

byte this_packet_num;

// Example constraint, creates a packet with useful values

constraint reasonable {packet.header == 8'h33;

packet.src == 1;

packet.length==packet.payload.size;

}

function new();

super.new(this.log);

this_packet_num = packet_num;

packet_num++;

endfunction

// Other constraints, functions such as copy() required by VMM, etc.

endclass: packet_trans

// Automatically create a channel class packet_trans_channel

`vmm_channel(packet_trans)


12/38

Example VMM System

8

Creating a generator and a command-level transactor

Now we have described our transaction data and a channel class to carry it,we can make some instances of transactions. We declare a class to generatepacket_trans objects by using the atomic-generator macro:

`vmm_atomic_gen(packet_trans)

This declares a class called packet_trans_atomic_gen, which we caninstance in the environment (see Creating the environment, later in thissection):

packet_trans_atomic_gen gen;

When we construct an object of this type we connect it to a channel, intowhich it passes references to the data items it generates.

Transactors that sit at the lowest level of the testbench hierarchy are alsoderived from vmm_xactor, and connected directly to the design by means ofa virtual interface:

class packet_master extends vmm_xactor;

virtual ex_intf.test V;

packet_trans_channel in_chan;

function new (string name,

int stream_id = -1,

virtual ex_intf.test V,

packet_trans_channel in_chan = null);super.new("packet_master", name);

this.V = V;

if (in_chan == null)

in_chan = new("packet_trans_channel","packet_master_DEFAULT_IN_CHAN");

this.in_chan = in_chan;

endfunction


13/38

Example VMM System

9

task main;

packet_trans p;

forksuper.main();

join_none;

forever begin

this.wait_if_stopped_or_empty(this.in_chan);

this.in_chan.get(p);

sendapacket(p);

end

endtask

task sendapacket(input packet_trans_data p);

logic [7:0] buffer[];

p.byte_pack(buffer);

foreach (buffer[i]) @(V.cb) begin

V.cb.data_in


14/38

Example VMM System

10

Creating a channel

We have already created a channel class to transfer ourpacket_trans datausing the vmm_channel macro. Now we can make an instance of it:

packet_trans_channel in_chan;

Then within the transactors we use the channel's methods, as in thetransactor above. An atomic generator does this automatically.

Creating the environmentWe bring together all our system building blocks as objects instanced in aderivative ofvmm_env.

class dut_env extends vmm_env;virtual ex_intf.test intf;packet_trans_channel gen2mst;packet_trans_channel mon2scb;packet_trans_atomic_gen gen;

packet_master mst;packet_monitor mon;dut_sb scb;...

endclass: dut_env

This class declaration has several key features:

1) a virtual interface, for connecting to the design.

2) A connection to the messaging service vmm_log.

3) Two channel instances.

4) An atomic generator.

5) A master transactor.

6) A monitor, or passive transactor.

7) A scoreboard (implementation not described here).

The generator produces a stream of data instances, and will put each one

into the channel gen2mas. The master transactor uses the get() methodof the channel to retrieve data and stimulate the design.


15/38

Example VMM System

11

The monitor watches signal activity for transactions and logs them on thescoreboard to which it is connected by another channel instance mon2scb.

In the constructor of the environment, we describe the connection to be madebetween the design and testbench:

function dut_env::new();super.new("DUT_ENV");

endfunction

We complete the build() method of the environment to create instances of

all our building blocks. We must also specify the connection to be madebetween the design and testbench, using the instance name of anappropriate interface and modport in the test harness module:

function void dut_env::build();virtual ex_intf.test ifc;super.build();ifc = ex_top.intf.test; // Identify the connectiongen2mst = new ("Packet Trans Channel", "gen2mst");

mon2scb = new ("Packet Trans Channel", "mon2scb");gen = new ("Atomic Gen", 1, gen2mas);mst = new ("Transaction master", 1, ifc, gen2mst );mon = new ("Transaction monitor", 1, ifc, mon2scb);scb = new (cfg.trans_cnt, mon2scb);

begin // callbacks for scoreboardpacket_mst_sb_callbacks packet_mst_sb_cb = new(scb);mst.append_callback(packet_mst_sb_cb);

end

begin // callbacks for coverage collectionpacket_master_cov_callbacks cov_cb = new();mst.append_callback(cov_cb);

end

gen.stop_after_n_insts = 20;endfunction: build


16/38

Example VMM System

12

Within the build method we are registering callbacks with each transactor. Inshort, each time a transactor does anything it should call a function to provide

a hook for optional related actions. In this case it is to add the transaction tothe scoreboard and to establish coverage of transactions, but callbacks canalso modify or drop data, or insert some directed test data using theinject() method that should be found in every transactor.

We fill in the start() method with actions necessary to get our testbenchgoing:

task dut_env::start();

super.start();gen.start_xactor();

mst.start_xactor();

mon.start_xactor();

scb.init();

endtask: start


17/38

Example VMM System

13

Test program:

This is a SystemVerilog program that constructs an instance of theenvironment and calls the methods defined in the environment class. Theprogram takes as input an interface instance to which the test environmentwill be connected.

program testprogram;

dut_env env; // DUT Environment instance

initial begin

// Create the environment, connect it to the DUT via modporttest

// of interface instance intf inside the test harness ex_top

env = new(ex_top.intf.test);

// Run everything. The environment will detect that its // build method has not yet been called, and will call it automatically

env.run();

end

endprogram: testprogram


18/38

Example VMM System

14

Test harness:

The test harness is a SystemVerilog module containing the DUT, itssupporting connections and clock generators, and the interface instancesneeded to link it to the VMM-compliant testbench program. This page showsonly fragments of the code.

First we create the necessary interface definition:

interface ex_intf (input bit clk);

// Wires for each DUT connection

wire [7:0] data_in; ...

// Clocking block specifies direction and synchronization

clocking cb @(posedge clk);

output sync, data_in;

endclocking: cb

// Modport makes clocking block available to testbench

modport test(clocking cb);

endinterface: ex_intf

Now we create a module instancing the DUT and interface.

module ex_top;

// Interface instance, provides bridge to testbenchex_intf intf;

// DUT instance, directly wired to signals in the interface

top_design DUT (.clock(clk), .sync(intf.sync) ...);

endmodule: ex_top


19/38

Quick Reference Listings

15

Several kinds of base class are defined in the VMM Standard Library.

vmm_data is a template for data objects/transactions that are manipulated

by the system. Transaction data objects are likely to be created anddestroyed dynamically, in large numbers, during normal operation of thetestbench.

vmm_env, vmm_xactorand vmm_channel (including vmm_broadcastand vmm_scheduler) are a base for components of the testbench. Theycreate, convey and transform objects based on vmm_data. Objects of thesetypes are likely to be created once only, as part of the environments buildprocedure, and together form the verification environment.

Macros `vmm_atomic_gen and `vmm_scenario_gen simplify the creation

ofgenerators derivatives ofvmm_xactordesigned to generate streams oftransactions based on random constraints.

vmm_notify and vmm_log respectively allow control and reporting of what isgoing on.


20/38

vmm_data Base class

16

This is the base class from which all user-defined transaction data typesshould be derived. It provides a set of methods that all data or transaction

descriptors need, such as for copying, comparing and checking. Virtualmethods in boldmustbe overridden in all derived classes.

class vmm_data;

function new(vmm_log log);

function vmm_log set_log(vmm_log log);

int stream_id;

int scenario_id;int data_id;

vmm_notify notify;

enum { EXECUTE, STARTED, ENDED };

function void display(string prefix = "");

virtual function string psdisplay ( string prefix = "" );

virtual function bit is_valid ( bit silent = 1, int kind = -1 );

virtual function vmm_data allocate ( );

virtual function vmm_data copy ( vmm_data to = null );virtual function bit compare (

input vmm_data to, output string diff, input int kind = -1 );

virtual protected function void copy_data ( vmm_data to );

virtual function int unsigned byte_pack (

ref logic [7:0] bytes [ ], int unsigned offset = 0, int kind = -1 );

virtual function int unsigned byte_unpack (

const ref logic [7:0] bytes [ ], input int unsigned offset = 0,

input int len = -1, input int kind = -1 );

virtual function int unsigned byte_size ( int kind = -1 );

virtual function int unsigned max_byte_size ( int kind = -1 );

virtual function void save ( int file );

virtual function bit load ( int file );


21/38

Creating an extension of vmm_data

17

First, decide what data you need in your transaction. There are norestrictions on user-defined data that can be added to an extension of

vmm_data, but all data fields that represent part of a transaction mustbe declared rand so that their values can be randomized if required.The section Class Properties/Data Members in chapter 4 of the VMMbook gives more detail of appropriate ways to model transaction data.

Create constraints that control the randomization of your data fields.You are free to design these constraints to determine the content,distribution and validity of your randomly generated data. You shouldname the constraints in a consistent way so it is easier to document andextend them. The VMM stipulates a few simple rules concerning these

user-defined constraints; you can find these rules in chapter 4 of thebook.

Write virtual method definitions for the base class methods that must beoverridden: copy, compare, allocate, is_valid, psdisplay.Details of the standard design patterns for these methods can be foundin the VMM book, and the utility rvmgen (described at the end of thisguide) can construct a code skeleton to save you some work.

Although it is not mandatory, any non-trivial derivative ofvmm_data issure to need its own implementation of the constructornew.

Immediately after defining the new derived class, invoke the`vmm_channel macro to construct a channel for the new class.

Optionally, invoke one or both of the generator macros`vmm_atomic_gen or`vmm_scenario_gen to construct new class(es)that can automatically generate randomized streams of objects of thevmm_data extension you have defined.

Create appropriate derived classes from vmm_xactor(see below) tomanipulate the new data type. If the transaction represents a datastream that appears directly at the ports of the DUT, or elsewhere in thetest harness, then it will be necessary to create a command-leveltransactor.


22/38

vmm_xactor Base class

18

All transactors are derived from this base class, including bus-functionalmodels, monitors and generators. It provides a standard set of methods that

all transactors need.

class vmm_xactor;

function new ( string name, string instance, int stream_id = -1 );

virtual function string get_name ( );

virtual function string get_instance ( );

vmm_log log;

int stream_id;virtual function void prepend_callback ( vmm_xactor_callbacks cb );

virtual function void append_callback ( vmm_xactor_callbacks cb );

virtual function void unregister_callback ( vmm_xactor_callbacks cb );

vmm_notify notify;

// Enumeration values for the state of the transactor:

enum { XACTOR_IDLE, XACTOR_BUSY,

XACTOR_STARTED, XACTOR_STOPPED, XACTOR_RESET };

virtual function void start_xactor ( );

virtual function void stop_xactor ( );

virtual function void reset_xactor ( reset_e rst_typ = SOFT_RST );

protected task wait_if_stopped ( );

protected task wait_if_stopped_or_empty ( vmm_channel chan );

protected virtual task main ( );

virtual function void save_rng_state ( );

virtual function void restore_rng_state ( );virtual function void xactor_status ( string prefix = "" );

// Macro to simplify the calling of callback methods:

`vmm_callback ( callback_class_name, method ( args ) )


23/38

Command-level transactors

19

At the lowest level of the testbench structure, a command level transactorprovides the bridge between the object-oriented, class-based world of the

testbench and the module-based world of the DUT together with itssupporting test harness including clock generators, module-to-moduleinterconnections and so on. There is a standard implementation pattern forthis bridge, exploiting SystemVerilogs interface, clocking andvirtual interface constructs. In summary:

Implementation of the test harness

The test harness is a module that instances the DUT together with anywiring and supporting models that it requires.

Clocks must be generated in module-based code in the test harness. All signals that will be handled by the testbench must be implemented

as Verilog nets (wire) encapsulated in an interface that is instancedin the test harness.

This interface must contain a clocking block for each differentclock signal that it uses. The clocking block must capture all the netsthat will be used in the testbench, and these nets must be givenappropriate direction (input, output, inout) in the clocking block.

The clocking block must be passed through a modport of the interface.No other signals should pass through this modport.

Nets in the interface may be connected to corresponding nets in theDUT or test harness by continuous assignment (for unidirectionalsignals) or by alias statements (forinout signals). Alternatively, theDUT's ports may be connected directly to signals in the interface usingthe DUT's port connection list.

Implementation of the command-level transactor

The command-level transactor is an extension ofvmm_xactor. It musthave a public class property that is a virtual interface whose datatype matches the modport described above.

At some point in construction of the environment typically as part ofthe constructor of the command-level transactor thisvirtual interface property must be set to reference the instance ofthe modport that is required.

The transactor now has access to the clocking block via this

virtual interface property.


24/38

vmm_channel Macro and base class

20

Base class vmm_channel implements a generic transaction-level interfacemechanism. Properties and virtual methods ofvmm_channel are

summarized on the facing page.

Users should invoke the `vmm_channel macro to define a channel classspecialized for a particular derivative ofvmm_data. This macro automatesthe extension of the channel base class vmm_channel.

Macro `vmm_channel defines a class named class_name_channel,derived from base class vmm_channel, for any user-specified class_name.

`vmm_channel ( class_name )

This macro creates a new channel class definition. It does not instanceanything.

It is not usually necessary to modify or extend the resulting specializedchannel class class_name_channel.

class class_name_channelextends vmm_channel;

function new ( string name, string instance,

int unsigned full = 1, int unsigned empty = 0, bit fill_as_bytes = 0 );

vmm_log log;

vmm_notify notify;

function void reconfigure (int full = -1, int empty = -1, logic fill_as_bytes = 1'bx );

function int unsigned full_level ( );

function int unsigned empty_level ( );

function int unsigned level ( );

function int unsigned size ( );

function bit is_full ( );

function void flush ( );

function void sink ( );function void flow ( );


25/38

Macro and base class vmm_channel

21

continued

function void lock ( bit [1:0] who );function void unlock ( bit [1:0] who );

function bit is_locked ( bit [1:0] who );

task put ( class_name obj, int offset = -1 );

function void sneak ( class_name obj, int offset = -1 );

function class_name unput ( int offset = -1 );

task get ( output class_name obj, input int offset = 0 );

task peek ( output class_name obj, input int offset = 0 );

task activate ( output class_name obj, input int offset = 0 );

function class_name active_slot ( );

function class_name start ( );

function class_name complete ( vmm_data status = null );

function class_name remove ( );

function active_status_e status ( );

task tee ( output class_name obj );

function bit tee_mode ( bit is_on );function void connect ( vmm_channel downstream );

function class_name for_each ( bit reset = 0 );

function int unsigned for_each_offset ( );

function bit record ( string filename );

task bit playback ( output bit success, input string filename,

input vmm_data loader, input bit metered = 0 );


26/38

vmm_notify Base class

22

The vmm_notify class implements an interface to the notification service,used for synchronization between concurrent threads or transactors. It

provides more functionality than is available using event variables.

class vmm_notify;

function new ( vmm_log log );

virtual function vmm_notify copy ( vmm_notify to = null );

virtual function int configure ( int notification_id = -1,

sync_e sync = ONE_SHOT );

virtual function int is_configured ( int notification_id );virtual function bit is_on ( int notification_id );

virtual task wait_for ( int notification_id );

virtual task wait_for_off ( int notification_id );

virtual function bit is_waited_for ( int notification_id );

virtual function void terminated ( int notification_id );

virtual function vmm_data status ( int notification_id );

virtual function time timestamp ( int notification_id );

virtual function void indicate (int notification_id, vmm_data status = null );

virtual function void set_notification (int notification_id, vmm_notification ntfy = null );

virtual function vmm_notification get_notification ( int notification_id );

virtual function void reset (int notification_id = -1, reset_e rst_typ = SOFT );

Class vmm_notification is used to describe a notification that can beautonomously set (indicated) or reset based on a user-defined occurrence,such as a combination of other notifications or external events.

class vmm_notification;

virtual task indicate ( ref vmm_data status );

virtual task reset ( );


27/38

Macro vmm_atomic_gen

23

This macro is used to define a class named class_name_atomic_gen forany user-specified class class_name that is derived from vmm_data. The

resulting generator class is an extension ofvmm_xactor.

`vmm_atomic_gen ( class_name, class_description_string)

Creates class class_name_atomic_gen (see below)

class class_name_atomic_gen extends vmm_xactor;

function new ( string instance, int stream_id = -1,class_name_channel out_chan = null );

class_name_channel out_chan;

int unsigned stop_after_n_insts;

class_name randomized_obj;

enum { GENERATED };

enum { DONE };

virtual task inject ( class_name data, ref bit dropped );


28/38

vmm_scenario_gen Macro

24

Macro `vmm_scenario_gen ( class_name, class_description_string)defines the following classes:

class class_name_scenario_gen extends vmm_xactor;

Transactor class to implement a scenario generator.

function new ( string instance, int stream_id = -1,class_name_channel out_chan = null );

class_name_channel out_chan;

int unsigned stop_after_n_insts;

int unsigned stop_after_n_scenarios;class_name_scenario scenario_set [ $ ];

class_name_scenario_election select_scenario;

enum { GENERATED };

enum { DONE };

virtual task inject_obj ( class_name obj );

virtual task inject ( class_name_scenario scenario );

class class_name_atomic_scenario;

Implements a scenario composed of a single unconstrained transaction.

int unsigned ATOMIC;

constraint atomic_scenario;

class class_name_scenario;static vmm_log log;

int stream_id;

int scenario_id;

function int unsigned define_scenario (string name, int unsigned max_len );

function void redefine_scenario (int unsigned scenario_kind, string name, int unsigned max_len );

function string scenario_name ( int unsigned scenario_kind );


29/38

Macro vmm_scenario_gen

25

class class_name_scenario; continued

rand int unsigned scenario_kind;rand int unsigned length;

rand class_name items [ ];

class_name using;

rand int unsigned repeated;

static int unsigned repeat_thresh;

function void allocate_scenario ( class_name using = null );

function void fill_scenario ( class_name using = null );

virtual task apply (class_name_channel channel, ref int unsigned n_insts );

class class_name_scenario_election;

Implements a random selection process for selecting the next scenariodescriptor to be randomized, from a set of available descriptors stored inits scenario_set queue variable.

int stream_id;int scenario_id;

int unsigned n_scenarios;

int unsigned last_selected [ $ ];

int unsigned next_in_set;

class_name_scenario scenario_set [ $ ];

rand int select;

constraint round_robin;

class class_name_scenario_gen_callbacks;

Defines a faade for the scenario generators callbacks.

virtual task pre_scenario_randomize ( class_name_scenario_gen gen,refclass_name_scenario scenario );

virtual task post_scenario_gen ( class_name_scenario_gen gen,

class_name_scenario scenario, ref bit dropped );


30/38

vmm_broadcast Base class

26

If multiple consumers attempt to get transactions from a standard VMMchannel, the transaction descriptors are distributed among the consumers so

that each of the Nconsumers sees 1/Ndescriptors. If multiple consumersmust each see all the descriptors, vmm_broadcast can be used to feeddescriptors from one source to an arbitrary number of consumers. Eachoutput channel of a vmm_broadcast component can be configured toprovide either a reference to the transaction or a copy of that transaction. If aparticular channel needs to change the data without affecting otherconsumers then it must copy the data. References or copies can be set asthe default for a vmm_broadcast component.

class vmm_broadcast;

vmm_log log;

typedef enum { AFAP, ALAP } bcast_mode_e;

function new ( string name, string instance, vmm_channel source,bit use_references = 1, bcast_mode_e mode = AFAP );



virtual function void reset_xactor ( reset_e rst_type = SOFT_RST );broadcast_mode ( bcast_mode_e mode );

virtual function int new_output (vmm_channel channel, logic use_references = 1'bx );

virtual function void bcast_on ( int unsigned output_id );

virtual function void bcast_off ( int unsigned output_id );

virtual protected function bit add_to_output ( int unsigned decision_id,int unsigned output_id, vmm_channel channel, vmm_data obj );


31/38

Base class vmm_scheduler

27

This class is the reverse of the vmm_broadcast class. It handles multiplesources feeding data into a channel with only one consumer. If a multipoint-

to-point mechanism must follow a specific scheduling algorithm, avmm_schedulercomponent can be used to control the choice of sourcestream providing the next transaction to the output stream.

class vmm_scheduler;

vmm_log log;

protected vmm_channel out_chan;

function new ( string name, string instance,vmm_channel destination, int instance_id = -1 );



virtual function void reset_xactor ( reset_e rst_typ = SOFT_RST );

virtual function int new_source ( vmm_channel chan );

virtual function void sched_on ( int unsigned input_id );

virtual function void sched_off ( int unsigned input_id );

virtual protected task schedule ( output vmm_data obj,input vmm_channel sources [ $ ], int unsigned input_ids [ $ ] );

virtual protected task get_object ( output vmm_data obj,vmm_channel source, int unsigned input_id, int offset );

vmm_scheduler_election randomized_sched;


32/38

vmm_log Base classes

28

This class is used to connect to the message service, for reporting eventsand interesting occurrences. Note: owing to the size of this class, this is not

an exhaustive list. More details can be found in the full description ofvmm_log in appendix A of the VMM book.

vmm_log_format is a class that describes the formatting of messages. It isused in the set_format method ofvmm_log:

class vmm_log_format;

virtual function string format_msg ( string name,string instance, string msg_typ, string severity, string lines [ $ ] );

virtual function string continue_msg ( string name,string instance, string msg_typ, string severity, string lines [ $ ] );

virtual function string abort_on_error ( int count, int limit );

virtual function string pass_or_fail ( bit pass, string name, string instance,int fatals, int errors, int warnings, int dem_errs, int dem_warns );

The following macros are a convenient shorthand for using a vmm_loginstance to produce a message that can be expressed as one string:

`vmm_fatal ( vmm_log log, string txt )

`vmm_error ( vmm_log log, string txt )

`vmm_warning ( vmm_log log, string txt )

`vmm_note ( vmm_log log, string txt )

`vmm_trace ( vmm_log log, string txt )

`vmm_debug ( vmm_log log, string txt )`vmm_verbose ( vmm_log log, string txt )

`vmm_report ( vmm_log log, string txt )

`vmm_command ( vmm_log log, string txt )

`vmm_transaction ( vmm_log log, string txt )

`vmm_protocol ( vmm_log log, string txt )

`vmm_cycle ( vmm_log log, string txt )


33/38

Base classes vmm_log

29

class vmm_log;

function new ( string name, string instance, vmm_log under = null );virtual function void is_above ( vmm_log log );

virtual function vmm_log copy ( vmm_log to = null );

virtual function string get_name ( );

virtual function string get_instance ( );

virtual function void list ( string name = "/./",string instance = "/./", bit recurse = 0 );

enum { FAILURE_TYP, NOTE_TYP, DEBUG_TYP,

TIMING_TYP, XHANDLING_TYP, REPORT_TYP,PROTOCOL_TYP, TRANSACTION_TYP, COMMAND_TYP,CYCLE_TYP, INTERNAL_TYP, DEFAULT_TYP, ALL_TYPS };

enum { FATAL_SEV, ERROR_SEV, WARNING_SEV,NORMAL_SEV, TRACE_SEV, DEBUG_SEV,VERBOSE_SEV, DEFAULT_SEV, ALL_SEVS };

enum { IGNORE, CONTINUE, DUMP_STACK,STOP_PROMPT, DEBUGGER, COUNT_ERROR,ABORT_SIM, DEFAULT_HANDLING };

virtual function vmm_log_format set_format ( vmm_log_format fmt );

virtual function bit start_msg( int typ, int sev = DEFAULT_SEV );

virtual function void end_msg ( );

virtual function void enable_types (int typs, string name = "", string inst = "", bit recursive = 0 );

virtual function void disable_types (int typs, string name = "", string inst = "", bit recursive = 0 );

virtual function void set_verbosity (

int severity, string name = "", string inst = "", bit recursive = 0 );virtual function int get_verbosity ( );

virtual function void log_start (int file, string name = "", string instance = "", bit recurse = 0 );

virtual function void log_stop (

int file, string name = "", string instance = "", bit recurse = 0 );

virtual function void stop_after_n_errors ( int n );

virtual function int get_message_count ( int severity = ALL_SEVS,

string name = "", string instance = "", bit recurse = 0 );


34/38

vmm_env Base class

30

This class is used to implement the overall verification environment. It isextended to create the desired test environment and contains instances of

the class objects used within the particular environment.Typically, a testcase creates an environment and then calls its run method;this in its turn calls the test sequencing methods as described below. Userextensions ofvmm_env should override these virtual methods to implementthe environments construction and functionality.

class vmm_env;

vmm_log log;

vmm_notify notify;

function new ( string name = "Verif Env" );

task run ( );

// Test sequencing methods called by run ( ):

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

event end_test;


35/38

Using the VMM Standard Library with VCS

31

Synopsys provides you with a ready-to-use implementation of the VMM

Standard Library compiled into the tools.VCS allows you to see objects in your design and transactions in yourtestbench, across multiple design, verification and modelling languages.

The following notes show how to use the VMM Standard Library in simplecases. For comprehensive information, and for tool-specific issues andquestions, see the VCS product documentation.

Creating your code:

Be sure to include the VMM Standard Library definitions by invoking

`include "vmm.sv"

Compiling with VCS

% vcs -sverilog -debug_all -ntb_opts rvm source_files

-sverilog enables SV parser

-debug_all enables debug capabilities

-ntb_opts rvm enables VMM Standard Library

Running the executable:

% simv

runs in batch mode, and

% simv gui

runs interactively.


36/38

Utility program rvmgen

32

The rvmgen utility provides an easy way to generate source code templatesfor VMM-compliant verification components, based on answers to a few

simple questions.

Options:

-L liblist Colon-separated list of user-defined template directories

-X Do not include the standard templates

-l sv Generate template in SystemVerilog

-o fname Generate the template in the specified file

Typical usage:

% rvmgen -l sv

The tool will give you a list of possibilities from the libraries it can see:

From Standard Library:0) Physical interface declaration1) Transaction descriptor2) Driver, Physical-level, Half duplex3) Driver, Physical-level, Full duplex4) Monitor, Physical-level, Half duplex5) Passive Monitor, Physical-level, Full duplex6) Driver, Functional-level, Half duplex

7) Driver, Functional-level, Full duplex8) Monitor, Functional-level, Half duplex9) Passive Monitor, Functional-level, Full duplex

Select [0-9]:

Make the appropriate choice and the code skeleton is generated. Physicalinterface declaration constructs a SystemVerilog interface block neededto connect your VMM-compliant testbench to the DUT. The transactiondescriptor is derived from vmm_data; drivers and monitors are derived from

vmm_xactor.


37/38


38/38

vmm companion guide

Documents