SystemVerilog for Verification

Lab: Advanced OOP

 2016-2017 Mentor Graphics Corporation

All rights reserved.

This document contains information that is trade secret and proprietary to Mentor Graphics Corporation or its
licensors and is subject to license terms. No part of this document may be photocopied, reproduced, translated,
distributed, disclosed or provided to third parties without the prior written consent of Mentor Graphics.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been made.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation of
fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.

MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to FAR
48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/trademarks.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.

End-User License Agreement: You can print a copy of the End-User License Agreement from:
www.mentor.com/eula.

Mentor Graphics
Corporation
8005 S.W. Boeckman Road, Wilsonville, Orego 97070-7777
Telephone:
503.685.7000
Toll-Free Telephone: 800.592.2210
Website:
www.mentor.com
SupportNet: supportnet.mentor.com/

Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form

This is the top level of the test environment. The test class (BaseTest) is instantiated in the top module. It
contains instances of the other testbench classes.
More detail on the class environment is shown on the next pages. The black diamonds indicate a connection
via a virtual interface.
DUT model is in instr_register.sv in the current lab directory. Review the
model to become familiar with its operation. A brief summary of the
operation is:
• The iw_reg register is an array of 32 instruction_t structures, beginning with address 0
• The register is reset asynchronously when input reset_n is low
• A new instruction is written into the register, on a positive edge of clk if load_en is true, at the
address specified by write_pointer
• An instruction_word is continuously being read from the register, at the address specified by
read_pointer

User-defined types used in the DUT model are defined in a package in

instr_register_pkg.sv which can be found in the current lab directory

You will work on modifying the testbench (not the DUT) in this lab.
This diagram shows how classes interact with each other in more detail.

DivideByZero class extends the Transaction class.

All other classes extend the new Component class.

• The solution files to the part 1 of this lab are in lab11_solution sub-directory of the current lab directory
and its class_files sub-directory. Compare your code with these example solutions.
If you would like to view the waveforms generated, and run the simulation in the GUI, there is a
run_part1.do file which compiles, simulates and opens the wave window for part 1 of this lab.
To use this .do file , cd to the lab11_OOP_Advanced directory, and open the Questa GUI by
typing:
% vsim (type at the Linux shell)
Once the QuestaSim GUI is open, type the following command in the Transcript window:
QuestaSim> do run_part1.do
At the end of the simulation, do not exit the GUI. To stay in the GUI and start more simulations,
simply type:
QuestaSim> quit –sim
Note that in UVM, the methods we are mimicking in this lab are called phases, and they are run
automatically without the need for explicitly calling them. However the concept of running all methods, and
each one only doing anything if a component based class has overridden the phase method is the same.
This shows which of the base methods have been overridden by each class (red lines of code).

In each of the BaseTest overridden methods, all three child class methods are executed, for example in the
report method of the BaseTest class:

virtual task report();

drv_h.report();
mon_h.report();
gen_h.report();
endtask : report

If the class hasn’t overridden that particular method, then the empty base method of the base class
(Component) will be executed.

The BaseTest constructor content are moving into its Build method, so it is no longer necessary to have an
explicit constructor in BaseTest.
build and report methods will take no time and could be void functions rather than tasks.
However, for this course we will take the easy approach and use tasks for all.
In UVM they would be function phases

This class structure is similar to UVM's, with all components sharing a common set of phase methods

The solution to this lab is in lab11_solution sub-directory of the current lab directory.
build and report will take no time and could be void functions rather than tasks. However, for this
course we will take the easy approach and use tasks for all. In UVM they would be function phases.

This class structure is similar to UVM's, with all components sharing a common set of phase methods.
The test environment does not use all these phases yet.

Strictly speaking the reset and run tasks in the BaseTest class should contain a fork/join block so that the
methods could run concurrently. However it is not necessary for this simple environment, and has been left
out for simplicity. In UVM, the phase methods that take time all run concurrently.
In UVM, the calling of methods is done automatically. All the initial block would have to do would be to
initiate the test, and the phases would all be called automatically.

If you would like to view the waveforms generated, and run the simulation in the GUI, there is a
run.do file which compiles, simulates and opens the wave window for part 2 of this lab.
To use this .do file , cd to the lab11_OOP_Advanced directory, and open the Questa GUI by
typing:
% vsim (type at the Linux shell)
Once the QuestaSim GUI is open, type the following command in the Transcript window:
QuestaSim> do run.do
At the end of the simulation, do not exit the GUI. To stay in the GUI and start more simulations,
simply type:
QuestaSim> quit –sim