Inc. ARM is a registered trademark of ARM Ltd. and is supplied without liability for errors or omissions. stored.com Web: http://www. VCS is a registered trademark of Synopsys. Doulos® is a registered trademark of Doulos Ltd.com . All Rights Reserved The information contained herein is the property of Doulos Ltd. transmitted or reproduced in any form or medium without the written permission of Doulos Ltd. All rights reserved. First published in 2006 by Doulos Doulos Church Hatch 22 Market Place Ringwood Hampshire BH24 1AW UK Tel +44 (0) 1425 471223 Fax +44 (0) 1425 471573 Email: info@doulos.1.VMM for SystemVerilog Companion Guide Version 1. Inc. All Rights Reserved. Copyright © 2006 ARM Ltd. Trademarks/Copyright ©2006 Synopsys. December 2007 Copyright © 2006-2007 Doulos Ltd. No part may be used.doulos.

doulos. can be downloaded from the Doulos web site: http://www. The Companion Guide is not intended to replace either the VMM for SystemVerilog or a proper training course. or the set of methods they have inherited from a certain base class. as outlined on pages 7 to 14. a professional book co-authored by verification experts from ARM Ltd. It assists the engineer in identifying the exact signature of a particular method. and published by Springer Science and Business Media (ISBN 0-387-255389). and Synopsys. Complete code for the Example VMM System. Inc. and also contains reference information on how to use the VMM Standard Library ® with the Synopsys VCS solution.com/knowhow/sysverilog 1 . It is suitable as a very brief technical introduction to the aims and structure of the VMM methodology.VMM for SystemVerilog Companion Guide This Companion Guide provides a handy quick reference for users of the Verification Methodology Manual (VMM) for SystemVerilog.

2 .

The VMM Standard Library provides base classes for key aspects of the verification environment. Other transactors take data items from a channel. gives us much more than is available using event variables. suitably extended to provide any required custom functionality. The testcase is remote from the event-driven world of signals. and notification can have status and timestamp information attached. The creation of channels for any given transaction type is automated by a macro `vmm_channel. are known as command-level transactors. perform some transformation. A notification service. The operation of the notification is defined at configuration time. A generator creates a series of data items. 3 . which chooses. communicating directly with the design by means of a pin-level interface. Some transactors are the source of a data stream. an event notification service. then add the item to a downstream channel. At the top of the object instance hierarchy is the testcase. Another transactor can read the next reference from the channel and perform any required operation on that data before placing the reference in the next channel. based on vmm_env. complex high-grade verification environments by specialized verification engineers. then places references to those date items into a channel. based on vmm_notify. These rules and recommendations can also provide useful guidance for those who are new to complex verification. is where all these objects are instanced. they are said to be functional-level transactors. but has the ability to control the environment at any level. VMM-compliant test environments must use these base classes. Transaction data in a VMM-compliant testbench are objects of one or more user-defined classes derived from the provided base class vmm_data. Transactors pass transactions from one to another through channels. and a message logging service. Such objects are produced by a transactor. It is possible to use concepts from the VMM methodology both in small ad-hoc testbenches for module testing and in the creation of large. generating data according to constraints. scalable verification methodology for SystemVerilog users. The environment. they are known as generators. The VMM for SystemVerilog contains detailed implementation rules and recommendations to aid in the adoption of this methodology. configures and runs a particular environment. Notification is used by transactors and channels to mark activity and for synchronization. Some transactors at the lowest level of the testbench. which is derived from vmm_xactor.Introduction The VMM for SystemVerilog describes a flexible.

localization (identification and control of source). Using a predefined message mechanism gives us consistency (post-processing and interpretation). 4 . The message service. Conversely. multiple sources can be merged into a single stream of transactions using vmm_scheduler.Introduction A single source of transactions can feed many consumers using a vmm_broadcast object. and control (effect on simulation behavior). configurability (control of message severity and type). All textual output from a VMM-compliant test environment should use the message service. based on vmm_log. provides a mechanism for reporting interesting activity to output files or the simulator console.

with the simplest transactions (signal transitions) at the lowest level of DUT interface. Program test_env env = new. Test case Constraints Environment . Connection to the DUT is implemented in a standardized way using the SystemVerilog interface construct – see the extended example. and the section on Command-level transactors. env. and the most complex (scenarios) coming from the generator at the top. for more detail. The transactors that drive the DUT form a protocol stack.vmm_env Generator vmm_atomic_gen Scenario-level scoreboard Scenario-level Callback Callback vmm_channel Transactor vmm_xactor Functional-level scoreboard Monitor vmm_xactor Functional-level Callback Callback vmm_channel Command-level Transactor vmm_xactor Virtual interface vmm_channel Monitor vmm_xactor Virtual interface Test harness Interface Interface DUT Note: Callbacks from a generator use a façade class derived from atomic_gen_callbacks.Introduction The diagram below shows the structure of a small VMM-compliant testbench. but there could be more if required. 5 . the monitoring transactors form a protocol stack.run. Callbacks from other transactors use a façade derived from vmm_xactor_callbacks. Similarly. We show one level of functional-level transactor.

6 .

endclass: packet_trans // Automatically create a channel class packet_trans_channel `vmm_channel(packet_trans) 7 .Example VMM System Defining transaction data We start by describing our transaction data using an extension of vmm_data. etc.log). // User-defined data contents of the transaction. and we supply necessary methods.payload.src == 1. // Example constraint. packet_num++.length==packet. this_packet_num = packet_num. with constraints that define suitable data values. including a deep copy and a method for checking data validity. class packet_trans extends vmm_data. packet. functions such as copy() required by VMM. packet. We describe how a transaction is made up. } function new().new(this.header == 8'h33. // Each transaction is given a unique serial number static byte packet_num. creates a packet with useful values constraint reasonable { packet. super. import types::*. static vmm_log log = new ("packet_trans". "class").size. declared rand rand packet_t packet. endfunction // Other constraints. byte this_packet_num.

new("packet_master". "packet_master_DEFAULT_IN_CHAN"). this.test V. When we construct an object of this type we connect it to a channel. and connected directly to the design by means of a virtual interface: class packet_master extends vmm_xactor.V = V. this. Transactors that sit at the lowest level of the testbench hierarchy are also derived from vmm_xactor. if (in_chan == null) in_chan = new("packet_trans_channel".test V. packet_trans_channel in_chan. int stream_id = -1.in_chan = in_chan. super. virtual ex_intf. packet_trans_channel in_chan = null). function new (string name. we can make some instances of transactions. name). virtual ex_intf. later in this section): packet_trans_atomic_gen gen. endfunction 8 . which we can instance in the environment (see Creating the environment. into which it passes references to the data items it generates.Example VMM System Creating a generator and a command-level transactor Now we have described our transaction data and a channel class to carry it. We declare a class to generate packet_trans objects by using the atomic-generator macro: `vmm_atomic_gen(packet_trans) This declares a class called packet_trans_atomic_gen.

sync <= 1'b1.header) V.wait_if_stopped_or_empty(this. sendapacket(p). end endtask task sendapacket(input packet_trans_data p).get(p). join_none.sync <= 1'b0.cb.data_in <= buffer[i].cb.Example VMM System task main. foreach (buffer[i]) @(V. this. packet_trans p. end endtask // other functions and tasks for stimulus and observation endclass 9 . forever begin this.main().in_chan. fork super. p. else V.cb. if (buffer[i] == p.in_chan).cb) begin V.byte_pack(buffer).packet. logic [7:0] buffer[].

test intf. packet_trans_atomic_gen gen. .. 3) Two channel instances. 5) A master transactor. 6) A monitor. The generator produces a stream of data instances. Now we can make an instance of it: packet_trans_channel in_chan. Then within the transactors we use the channel's methods.. packet_master mst. 2) A connection to the messaging service vmm_log. The master transactor uses the get() method of the channel to retrieve data and stimulate the design. packet_monitor mon.Example VMM System Creating a channel We have already created a channel class to transfer our packet_trans data using the vmm_channel macro. endclass: dut_env This class declaration has several key features: 1) a virtual interface. An atomic generator does this automatically. Creating the environment We bring together all our system building blocks as objects instanced in a derivative of vmm_env. as in the transactor above. and will put each one into the channel gen2mas. 10 . or passive transactor. for connecting to the design. 7) A scoreboard (implementation not described here). virtual ex_intf. packet_trans_channel mon2scb. 4) An atomic generator. class dut_env extends vmm_env. packet_trans_channel gen2mst. dut_sb scb.

gen2mst ). mst. mon2scb = new ("Packet Trans Channel". // Identify the connection gen2mst = new ("Packet Trans Channel". "mon2scb"). endfunction: build 11 . endfunction We complete the build() method of the environment to create instances of all our building blocks. mon = new ("Transaction monitor". mon2scb). scb = new (cfg. begin // callbacks for scoreboard packet_mst_sb_callbacks packet_mst_sb_cb = new(scb).append_callback(packet_mst_sb_cb). gen2mas). virtual ex_intf. super. using the instance name of an appropriate interface and modport in the test harness module: function void dut_env::build().intf.test ifc. In the constructor of the environment.Example VMM System The monitor watches signal activity for transactions and logs them on the scoreboard to which it is connected by another channel instance mon2scb. We must also specify the connection to be made between the design and testbench. 1. mst.build(). super.append_callback(cov_cb). "gen2mst"). we describe the connection to be made between the design and testbench: function dut_env::new(). end gen. 1. ifc. gen = new ("Atomic Gen".test. ifc = ex_top. ifc. 1. end begin // callbacks for coverage collection packet_master_cov_callbacks cov_cb = new(). mon2scb).trans_cnt.stop_after_n_insts = 20.new("DUT_ENV"). mst = new ("Transaction master".

start(). super.init(). scb.start_xactor(). mst. We fill in the start() method with actions necessary to get our testbench going: task dut_env::start().start_xactor(). In this case it is to add the transaction to the scoreboard and to establish coverage of transactions. gen. mon.start_xactor(). each time a transactor does anything it should call a function to provide a hook for optional related actions. endtask: start 12 .Example VMM System Within the build method we are registering callbacks with each transactor. or insert some directed test data using the inject() method that should be found in every transactor. but callbacks can also modify or drop data. In short.

// Run everything. dut_env env. The program takes as input an interface instance to which the test environment will be connected. and will call it automatically env.test). end endprogram: testprogram // DUT Environment instance 13 . initial begin // Create the environment.Example VMM System Test program: This is a SystemVerilog program that constructs an instance of the environment and calls the methods defined in the environment class.run(). program testprogram. The environment will detect that its // build method has not yet been called. connect it to the DUT via modport test // of interface instance intf inside the test harness ex_top env = new(ex_top.intf.

sync) . and the interface instances needed to link it to the VMM-compliant testbench program. // Clocking block specifies direction and synchronization clocking cb @(posedge clk).. module ex_top. endclocking: cb // Modport makes clocking block available to testbench modport test(clocking cb).sync(intf. output sync.clock(clk). endmodule: ex_top 14 . . provides bridge to testbench ex_intf intf. data_in..).. // Interface instance. endinterface: ex_intf • Now we create a module instancing the DUT and interface..Example VMM System Test harness: The test harness is a SystemVerilog module containing the DUT. // DUT instance. This page shows only fragments of the code. directly wired to signals in the interface top_design DUT (. . • First we create the necessary interface definition: interface ex_intf (input bit clk). its supporting connections and clock generators. // Wires for each DUT connection wire [7:0] data_in.

convey and transform objects based on vmm_data. during normal operation of the testbench. vmm_xactor and vmm_channel (including vmm_broadcast and vmm_scheduler) are a base for components of the testbench.Quick Reference Listings Several kinds of base class are defined in the VMM Standard Library. Macros `vmm_atomic_gen and `vmm_scenario_gen simplify the creation of generators – derivatives of vmm_xactor designed to generate streams of transactions based on random constraints. Transaction data objects are likely to be created and destroyed dynamically. vmm_data is a template for data objects/transactions that are manipulated by the system. in large numbers. They create. and together form the verification environment. vmm_env. Objects of these types are likely to be created once only. 15 . as part of the environment’s build procedure. vmm_notify and vmm_log respectively allow control and reporting of what is going on.

virtual function int unsigned byte_unpack ( const ref logic [7:0] bytes [ ]. such as for copying. virtual protected function void copy_data ( vmm_data to ). int scenario_id. virtual function string psdisplay ( string prefix = "" ). virtual function int unsigned byte_size ( int kind = -1 ). input int kind = -1 ). ENDED }. input int len = -1. comparing and checking. int unsigned offset = 0.vmm_data Base class This is the base class from which all user-defined transaction data types should be derived. It provides a set of methods that all data or transaction descriptors need. vmm_notify notify. function new(vmm_log log). STARTED. Virtual methods in bold must be overridden in all derived classes. 16 . output string diff. int kind = -1 ). function vmm_log set_log(vmm_log log). virtual function bit is_valid ( bit silent = 1. input int kind = -1 ). function void display(string prefix = ""). virtual function vmm_data copy ( vmm_data to = null ). int kind = -1 ). int data_id. int stream_id. class vmm_data. virtual function int unsigned byte_pack ( ref logic [7:0] bytes [ ]. virtual function vmm_data allocate ( ). virtual function void save ( int file ). virtual function bit compare ( input vmm_data to. virtual function bit load ( int file ). enum { EXECUTE. input int unsigned offset = 0. virtual function int unsigned max_byte_size ( int kind = -1 ).

or elsewhere in the test harness. Create appropriate derived classes from vmm_xactor (see below) to manipulate the new data type. Optionally. allocate. Details of the standard design patterns for these methods can be found in the VMM book. If the transaction represents a data stream that appears directly at the ports of the DUT. There are no restrictions on user-defined data that can be added to an extension of vmm_data.Creating an extension of vmm_data • First. You should name the constraints in a consistent way so it is easier to document and extend them. but all data fields that represent part of a transaction must be declared rand so that their values can be randomized if required. • • • • • • 17 . 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 the vmm_data extension you have defined. then it will be necessary to create a command-level transactor. The VMM stipulates a few simple rules concerning these user-defined constraints. psdisplay. distribution and validity of your randomly generated data. compare. is_valid. Create constraints that control the randomization of your data fields. Write virtual method definitions for the base class methods that must be overridden: copy. decide what data you need in your transaction. any non-trivial derivative of vmm_data is sure to need its own implementation of the constructor new. and the utility rvmgen (described at the end of this guide) can construct a code skeleton to save you some work. invoke the `vmm_channel macro to construct a channel for the new class. you can find these rules in chapter 4 of the book. The section Class Properties/Data Members in chapter 4 of the VMM book gives more detail of appropriate ways to model transaction data. Immediately after defining the new derived class. Although it is not mandatory. You are free to design these constraints to determine the content.

virtual function void restore_rng_state ( ). It provides a standard set of methods that all transactors need. virtual function void reset_xactor ( reset_e rst_typ = SOFT_RST ). int stream_id = -1 ). vmm_notify notify. virtual function void prepend_callback ( vmm_xactor_callbacks cb ). string instance. vmm_log log.vmm_xactor Base class All transactors are derived from this base class. XACTOR_STARTED. // Macro to simplify the calling of callback methods: `vmm_callback ( callback_class_name. virtual function void save_rng_state ( ). int stream_id. virtual function string get_instance ( ). class vmm_xactor. including bus-functional models. XACTOR_STOPPED. virtual function string get_name ( ). XACTOR_BUSY. protected virtual task main ( ). virtual function void stop_xactor ( ). protected task wait_if_stopped_or_empty ( vmm_channel chan ). monitors and generators. virtual function void start_xactor ( ). method ( args ) ) 18 . virtual function void xactor_status ( string prefix = "" ). protected task wait_if_stopped ( ). function new ( string name. // Enumeration values for the state of the transactor: enum { XACTOR_IDLE. virtual function void append_callback ( vmm_xactor_callbacks cb ). XACTOR_RESET }. virtual function void unregister_callback ( vmm_xactor_callbacks cb ).

the DUT's ports may be connected directly to signals in the interface using the DUT's port connection list. Alternatively. output. It must have a public class property that is a virtual interface whose data type matches the modport described above. Nets in the interface may be connected to corresponding nets in the DUT or test harness by continuous assignment (for unidirectional signals) or by alias statements (for inout signals). The clocking block must be passed through a modport of the interface. class-based world of the testbench and the module-based world of the DUT together with its supporting test harness including clock generators.Command-level transactors At the lowest level of the testbench structure. There is a standard implementation pattern for this bridge. module-to-module interconnections and so on. This interface must contain a clocking block for each different clock signal that it uses. and these nets must be given appropriate direction (input. In summary: Implementation of the test harness • • • The test harness is a module that instances the DUT together with any wiring and supporting models that it requires. clocking and virtual interface constructs. a command level transactor provides the bridge between the object-oriented. • • 19 . At some point in construction of the environment – typically as part of the constructor of the command-level transactor – this virtual interface property must be set to reference the instance of the modport that is required. All signals that will be handled by the testbench must be implemented as Verilog nets (wire) encapsulated in an interface that is instanced in the test harness. No other signals should pass through this modport. Clocks must be generated in module-based code in the test harness. • • • Implementation of the command-level transactor • The command-level transactor is an extension of vmm_xactor. inout) in the clocking block. The transactor now has access to the clocking block via this virtual interface property. exploiting SystemVerilog’s interface. The clocking block must capture all the nets that will be used in the testbench.

Users should invoke the `vmm_channel macro to define a channel class specialized for a particular derivative of vmm_data. class class_name_channel extends vmm_channel. function void reconfigure ( int full = -1. function int unsigned level ( ). int unsigned full = 1. function void sink ( ). Macro `vmm_channel defines a class named class_name_channel. 20 . function int unsigned full_level ( ). It is not usually necessary to modify or extend the resulting specialized channel class class_name_channel. It does not instance anything. function bit is_full ( ). bit fill_as_bytes = 0 ). int unsigned empty = 0. `vmm_channel ( class_name ) This macro creates a new channel class definition. function new ( string name. function void flow ( ). This macro automates the extension of the channel base class vmm_channel. logic fill_as_bytes = 1'bx ). string instance. function int unsigned size ( ). function void flush ( ). Properties and virtual methods of vmm_channel are summarized on the facing page. vmm_notify notify.vmm_channel Macro and base class Base class vmm_channel implements a generic transaction-level interface mechanism. for any user-specified class_name. int empty = -1. vmm_log log. function int unsigned empty_level ( ). derived from base class vmm_channel.

function class_name remove ( ). function void connect ( vmm_channel downstream ). input bit metered = 0 ). int offset = -1 ). task bit playback ( output bit success. function class_name for_each ( bit reset = 0 ). input int offset = 0 ). task tee ( output class_name obj ). function bit is_locked ( bit [1:0] who ). task activate ( output class_name obj. function bit record ( string filename ). task get ( output class_name obj. function bit tee_mode ( bit is_on ). function class_name unput ( int offset = -1 ). input string filename. task put ( class_name obj. function void sneak ( class_name obj. function class_name active_slot ( ). task peek ( output class_name obj. function active_status_e status ( ). input int offset = 0 ).Macro and base class vmm_channel continued function void lock ( bit [1:0] who ). function int unsigned for_each_offset ( ). function void unlock ( bit [1:0] who ). input int offset = 0 ). function class_name complete ( vmm_data status = null ). int offset = -1 ). input vmm_data loader. function class_name start ( ). 21 .

virtual function vmm_data status ( int notification_id ). used for synchronization between concurrent threads or transactors. virtual function bit is_waited_for ( int notification_id ). virtual function void terminated ( int notification_id ). sync_e sync = ONE_SHOT ). reset_e rst_typ = SOFT ). Class vmm_notification is used to describe a notification that can be autonomously set (indicated) or reset based on a user-defined occurrence. class vmm_notification. function new ( vmm_log log ). virtual function int is_configured ( int notification_id ).vmm_notify Base class The vmm_notify class implements an interface to the notification service. virtual function vmm_notify copy ( vmm_notify to = null ). virtual task reset ( ). 22 . virtual task indicate ( ref vmm_data status ). virtual function vmm_notification get_notification ( int notification_id ). virtual function void reset ( int notification_id = -1. virtual function void set_notification ( int notification_id. virtual function int configure ( int notification_id = -1. virtual function bit is_on ( int notification_id ). virtual function time timestamp ( int notification_id ). class vmm_notify. virtual function void indicate ( int notification_id. vmm_data status = null ). virtual task wait_for_off ( int notification_id ). It provides more functionality than is available using event variables. virtual task wait_for ( int notification_id ). vmm_notification ntfy = null ). such as a combination of other notifications or external events.

int unsigned stop_after_n_insts. class_description_string ) Creates class class_name_atomic_gen (see below) class class_name_atomic_gen extends vmm_xactor. class_name_channel out_chan = null ). function new ( string instance. int stream_id = -1. enum { GENERATED }. `vmm_atomic_gen ( class_name. class_name_channel out_chan.Macro vmm_atomic_gen This macro is used to define a class named class_name_atomic_gen for any user-specified class class_name that is derived from vmm_data. The resulting generator class is an extension of vmm_xactor. enum { DONE }. class_name randomized_obj. ref bit dropped ). 23 . virtual task inject ( class_name data.

class_name_channel out_chan. virtual task inject_obj ( class_name obj ). function new ( string instance. virtual task inject ( class_name_scenario scenario ). function int unsigned define_scenario ( string name. class_name_scenario_election select_scenario. class_name_scenario scenario_set [ $ ]. enum { DONE }. class_name_channel out_chan = null ). int unsigned ATOMIC. int unsigned stop_after_n_insts. constraint atomic_scenario. int stream_id = -1. Implements a scenario composed of a single unconstrained transaction. int stream_id. enum { GENERATED }. static vmm_log log. int unsigned max_len ). int scenario_id. 24 . function void redefine_scenario ( int unsigned scenario_kind. int unsigned max_len ). string name. class_description_string ) defines the following classes: class class_name_scenario_gen extends vmm_xactor.vmm_scenario_gen Macro Macro `vmm_scenario_gen ( class_name. function string scenario_name ( int unsigned scenario_kind ). class class_name_atomic_scenario. class class_name_scenario. int unsigned stop_after_n_scenarios. Transactor class to implement a scenario generator.

constraint round_robin. rand int unsigned repeated. class_name_scenario scenario_set [ $ ]. function void allocate_scenario ( class_name using = null ). ref class_name_scenario scenario ). rand class_name items [ ]. class_name using.Macro class class_name_scenario. class class_name_scenario_election. Implements a random selection process for selecting the next scenario descriptor to be randomized. virtual task apply ( class_name_channel channel. function void fill_scenario ( class_name using = null ). Defines a façade for the scenario generator’s callbacks. vmm_scenario_gen continued rand int unsigned scenario_kind. from a set of available descriptors stored in its scenario_set queue variable. 25 . virtual task pre_scenario_randomize ( class_name_scenario_gen gen. int stream_id. int scenario_id. ref int unsigned n_insts ). class class_name_scenario_gen_callbacks. rand int unsigned length. int unsigned n_scenarios. int unsigned next_in_set. rand int select. virtual task post_scenario_gen ( class_name_scenario_gen gen. ref bit dropped ). static int unsigned repeat_thresh. class_name_scenario scenario. int unsigned last_selected [ $ ].

vmm_channel channel. 26 . bit use_references = 1. virtual function void reset_xactor ( reset_e rst_type = SOFT_RST ). virtual function void bcast_off ( int unsigned output_id ).vmm_broadcast Base class If multiple consumers attempt to get transactions from a standard VMM channel. If multiple consumers must each see all the descriptors. virtual protected function bit add_to_output ( int unsigned decision_id. typedef enum { AFAP. References or copies can be set as the default for a vmm_broadcast component. virtual function int new_output ( vmm_channel channel. ALAP } bcast_mode_e. bcast_mode_e mode = AFAP ). If a particular channel needs to change the data without affecting other consumers then it must copy the data. vmm_data obj ). Each output channel of a vmm_broadcast component can be configured to provide either a reference to the transaction or a copy of that transaction. logic use_references = 1'bx ). virtual function void stop_xactor ( ). vmm_channel source. class vmm_broadcast. virtual function void start_xactor ( ). the transaction descriptors are distributed among the consumers so that each of the N consumers sees 1/N descriptors. string instance. virtual function void bcast_on ( int unsigned output_id ). function new ( string name. broadcast_mode ( bcast_mode_e mode ). int unsigned output_id. vmm_broadcast can be used to feed descriptors from one source to an arbitrary number of consumers. vmm_log log.

If a multipointto-point mechanism must follow a specific scheduling algorithm.Base class vmm_scheduler This class is the reverse of the vmm_broadcast class. string instance. a vmm_scheduler component can be used to control the choice of source stream providing the next transaction to the output stream. input vmm_channel sources [ $ ]. vmm_channel source. int instance_id = -1 ). protected vmm_channel out_chan. virtual function void sched_off ( int unsigned input_id ). virtual function void reset_xactor ( reset_e rst_typ = SOFT_RST ). virtual protected task get_object ( output vmm_data obj. 27 . vmm_log log. virtual function void sched_on ( int unsigned input_id ). vmm_scheduler_election randomized_sched. function new ( string name. It handles multiple sources feeding data into a channel with only one consumer. vmm_channel destination. int unsigned input_ids [ $ ] ). int offset ). virtual function int new_source ( vmm_channel chan ). virtual protected task schedule ( output vmm_data obj. class vmm_scheduler. virtual function void start_xactor ( ). virtual function void stop_xactor ( ). int unsigned input_id.

string txt ) `vmm_report ( vmm_log log. string txt ) 28 . string txt ) `vmm_trace ( vmm_log log. for reporting events and interesting occurrences. string instance. int dem_errs. string msg_typ. string txt ) `vmm_error ( vmm_log log. More details can be found in the full description of vmm_log in appendix A of the VMM book. int errors. string msg_typ. virtual function string continue_msg ( string name. virtual function string format_msg ( string name. string txt ) `vmm_note ( vmm_log log. virtual function string pass_or_fail ( bit pass. int fatals. string txt ) `vmm_warning ( vmm_log log. string txt ) `vmm_debug ( vmm_log log. string lines [ $ ] ). string txt ) `vmm_cycle ( vmm_log log. string severity. int dem_warns ). string txt ) `vmm_transaction ( vmm_log log.vmm_log Base classes This class is used to connect to the message service. this is not an exhaustive list. The following macros are a convenient shorthand for using a vmm_log instance to produce a message that can be expressed as one string: `vmm_fatal ( vmm_log log. Note: owing to the size of this class. It is used in the set_format method of vmm_log: class vmm_log_format. string name. string instance. vmm_log_format is a class that describes the formatting of messages. string txt ) `vmm_protocol ( vmm_log log. string lines [ $ ] ). string txt ) `vmm_command ( vmm_log log. int limit ). string instance. string severity. string txt ) `vmm_verbose ( vmm_log log. int warnings. virtual function string abort_on_error ( int count.

virtual function int get_message_count ( int severity = ALL_SEVS.Base classes class vmm_log. WARNING_SEV. INTERNAL_TYP. DEFAULT_SEV. TIMING_TYP. string name = "". string instance = "". virtual function void end_msg ( ). string instance. VERBOSE_SEV. DEBUG_TYP. string name = "". virtual function void enable_types ( int typs. virtual function void is_above ( vmm_log log ). bit recursive = 0 ). PROTOCOL_TYP. virtual function void set_verbosity ( int severity. CONTINUE. virtual function void list ( string name = "/. TRACE_SEV. virtual function string get_name ( ). XHANDLING_TYP. vmm_log under = null ). ALL_SEVS }. REPORT_TYP. bit recurse = 0 ). DUMP_STACK. string name = "". virtual function string get_instance ( ). bit recurse = 0 ). string instance = "/. vmm_log function new ( string name. virtual function void disable_types ( int typs. CYCLE_TYP. bit recursive = 0 ). virtual function int get_verbosity ( ). bit recursive = 0 ). enum { IGNORE. NOTE_TYP. virtual function vmm_log_format set_format ( vmm_log_format fmt ). 29 . STOP_PROMPT. virtual function void log_start ( int file. DEFAULT_TYP. string instance = ""./". virtual function vmm_log copy ( vmm_log to = null ). NORMAL_SEV./". virtual function bit start_msg( int typ. bit recurse = 0 ). DEBUGGER. enum { FATAL_SEV. ABORT_SIM. string name = "". string inst = "". COMMAND_TYP. DEFAULT_HANDLING }. string instance = "". virtual function void stop_after_n_errors ( int n ). string name = "". bit recurse = 0 ). TRANSACTION_TYP. string inst = "". COUNT_ERROR. string inst = "". enum { FAILURE_TYP. ERROR_SEV. ALL_TYPS }. string name = "". DEBUG_SEV. virtual function void log_stop ( int file. int sev = DEFAULT_SEV ).

vmm_notify notify. // Test sequencing methods called by run ( ): virtual function void gen_cfg ( ). virtual task stop ( ).vmm_env Base class This class is used to implement the overall verification environment. User extensions of vmm_env should override these virtual methods to implement the environment’s construction and functionality. Typically. this in its turn calls the test sequencing methods as described below. event end_test. virtual task report ( ). class vmm_env. virtual task start ( ). a testcase creates an environment and then calls its run method. function new ( string name = "Verif Env" ). virtual task reset_dut ( ). virtual task wait_for_end ( ). It is extended to create the desired test environment and contains instances of the class objects used within the particular environment. task run ( ). vmm_log log. virtual task cleanup ( ). 30 . virtual function void build ( ). virtual task cfg_dut ( ).

For comprehensive information. see the VCS product documentation. 31 . The following notes show how to use the VMM Standard Library in simple cases. Creating your code: Be sure to include the VMM Standard Library definitions by invoking `include "vmm. and % simv –gui runs interactively.sv" Compiling with VCS % vcs -sverilog -debug_all -ntb_opts rvm source_files -sverilog -debug_all -ntb_opts rvm enables SV parser enables debug capabilities enables VMM Standard Library Running the executable: % simv runs in batch mode.Using the VMM Standard Library with VCS Synopsys provides you with a ready-to-use implementation of the VMM Standard Library compiled into the tools. across multiple design. verification and modelling languages. and for tool-specific issues and questions. VCS allows you to see objects in your design and transactions in your testbench.

Full duplex 4) Monitor.Utility program rvmgen The rvmgen utility provides an easy way to generate source code templates for VMM-compliant verification components. Functional-level. Full duplex 6) Driver. Physical-level. Options: -L liblist -X -l sv -o fname 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 declaration 1) Transaction descriptor 2) Driver. Half duplex 5) Passive Monitor. Half duplex 3) Driver. Half duplex 7) Driver. Full duplex Select [0-9]: Make the appropriate choice and the code skeleton is generated. Full duplex 8) Monitor. Physical-level. Physical-level. Half duplex 9) Passive Monitor. Functional-level. The transaction descriptor is derived from vmm_data. “Physical interface declaration” constructs a SystemVerilog interface block needed to connect your VMM-compliant testbench to the DUT. drivers and monitors are derived from vmm_xactor. Physical-level. based on answers to a few simple questions. Functional-level. Functional-level. Colon-separated list of user-defined template directories Do not include the standard templates Generate template in SystemVerilog Generate the template in the specified file 32 .

Sign up to vote on this title
UsefulNot useful