A Step by Step Guide: UVM Framework Alu Tutorial

UVM Framework
ALU TUTORIAL
A Step By Step Guide
Using UVMF_2019.4
Sept 2016
Agenda
 Introduction
 ALU Overview
 Config Files Explained
 Compile and Simulate Generated Code
 Adding DUT Specific Functionality
© Mentor Graphics Corp. Company Confidential
2 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] overview

Tutorial Aims
 UVM Framework Steps
— The main aim is to take the user through the complete flow (from start to finish) to show how to generate a working
UVM testbench for a simple IP using the UVM Framework (UVMF) code generators
— Each step is explained to help the user understand what information has to be provided to the UVMF code generators
in order to produce the initial testbench infrastructure
— The tutorial also highlights where the user is expected to modify the generated code to add DUT specific functionality
in order to create a fully operational UVM testbench
3 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4]

Tutorial Logistics
 YAML Configuration Files

— YAML configuration files are used as the inputs to the UVM Framework code generators and they determine the content
of the generated code
— A set of completed YAML configuration files for the ALU project are located within the yaml_config_files folder
– The user can optionally use these as a starting point to get the initial code generated
— The UVMF Code Generator will NOT overwrite existing code. This ensures that any edits you have subsequently made
to the generated code cannot be inadvertently overwritten
– If code already exists in the specified output directory then the UVMF Code generators will issue “skipping” messages like the following:
 Completed Solution
— A fully completed version of the ALU UVMF testbench is provided within the completed_solution folder as a
reference to the user
— This contains all of the modification made after the initial code generation to add the DUT specific details
4 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4]

Agenda
 Introduction
 ALU Overview

ALU : Block Diagram
Operand A 8
16 Result
Operand B 8 ALU
valid done
ready
Operator
000 = nop
001 = and
010 = add
011 = xor
100 = mul
111 = rst

ALU : Timing Diagram
clk …
rst
1
operand A
operand B
operator
valid 2
3
ready … 6
5
done
result
4
1. Apply operands & operation on input pins 4. After X cycles, ALU presents result
2. Raise valid for 1 cycle (start) 5. ALU raises done for 1 cycle
3. ALU drops ready signals 6. ALU raises ready signal

Agenda
 ALU Overview
8 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] YAML

YAML Config Files
 YAML (YAML Ain't Markup Language)

— A human readable language used for capturing data
— Has minimal syntax and uses Python style indentation to indicate nesting
— Used in UVMF to capture information at a high level that can subsequently be
used by code generators to construct elements of a UVM testbench code # comments in YAML look like this
uvmf:
interfaces:
“<interface_nameA>”
 YAML File Format <properties>
“<interface_nameB>”
— All UVMF YAML files must be presented as part of a specific top level format <properties>
util_components:
shown opposite
“<util_component>”
— Whitespace indentation is used to denote structure; however, tab characters are <properties>
never allowed as indentation environments:
— Comments start with the number sign (#), can start anywhere on a line and “<env_nameA>”
continue until the end of the line <properties>
— The information can be spread across multiple files or can be contained in a benches:
single file “<bench_nameA>”
<properties>

YAML Config Files
 Number Of Agents
— First need to determine how many interfaces there are for the ALU
— Group signals into interfaces
— Create a YAML configuration file for each interface
– The YAML config file captures the pin information and the transaction information for the interface (agent)
— For the ALU, you have 2 separate interface files, 1 environment file and 1 bench file
 Required ALU Interface Config files

— ALU_IN Interface
o All signals that are associated with specifying the ALU operation to perform
— ALU_OUT Interface
o All signals that are associated with specifying the ALU result

Interface Config File
ALU_in_interface.yaml
uvmf:
interfaces:
ALU_in:
— Tabbed indents are required
— Identifies that subsequent data information is for a UVMF interface to be named ‘ALU_in’
clock: clk
— Identifies the primary clock to be used in the interface agent as ‘clk’ [1]
reset: rst
reset_assertion_level: ‘False’
— Identifies the primary reset to be used in the interface agent as ‘rst’ with active low polarity
NOTES:
1. Clock signal is required. Additional clocks will have to be manually
added after code generation
11 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

config_constraints: []
config_vars: []
— This is where you can specify configuration variables and any corresponding constraints for the agents
— Not being use for this ALU example
hdl_typedefs:
- name: alu_in_op_t
type: enum bit[2:0] {no_op = 3’b000, add_op …….., rst_op = 3’b111}
— Define any types used by the HDL side of the testbench
— Here you define the valid ALU operations and specify the bit values for each operation
hvl_typedefs:
— Define any types used by the HVL side of the testbench

parameters:
- name: ALU_IN_OP_WIDTH
type: int
value: ‘8’
— Defines an integer parameter named ‘ALU_IN_OP_WIDTH’ which has a default value of 8
— Any parameters defined here will impact be passed to multiple classes within the agent

ports:
- dir: output
- name: alu_rst
- width: ‘1’
— Here we define all of the signal names, directions and widths for the
agent/interface
NOTES:
— Direction specified here is in relation to the testbench
o i.e. ‘alu_rst’ is an output from the testbench and an input pin on the DUT
— The agent has to be able to execute a ‘rst_op’ operation and will need to drive the
ALU reset pin in response to such a request
— The ‘a’ & ‘b’ use the ALU_IN_OP_WIDTH parameter which was defined under the
parameters section of the config file

response_info:
data: []
operation: 1’b0
— The data directive allows the user to specify what response data should be passed back from the driver to the
originating sequence. We have no response data for this ALU interface
— The operation directive allows the user to define if the driver should pass any response data back to the sequence.
Here we set the value to 1’b0 which tells the driver not to send back any response
NOTES:
— Failing to disable responses when none are returned, will result in run times errors reporting ‘response queue overflow’

transaction_contraints:
- name : valid_op_c
- value: `{op inside {no_op,add_op, and_op, xor_op, mul_op};}’
— Defines any constraints to be used on the transaction variables

— Here we define a constraint named ‘valid_op_c’ to contain all
valid ALU operands except the rst_op operand (as we only want
to issue rst_op operands in a directed test type mode)
— The syntax for the constraint is pure SystemVerilog

transaction_vars:
- iscompare : ‘True’
- isrand: ‘True’
- name: ‘op’
— Defines any variable to be used by the transaction class.

— Variables in the transaction class reflect the untimed
information used during a transfer on the bus
— For the ALU, the transaction will specify the operation
and the a & b operands
— Each of these transaction variables can be randomized
since we specified isrand: ‘True’
— Within the generated transaction class, each of the
transaction variables will be included in a do_compare
method since we specified iscompare: ‘True’
NOTES:
— Unconstrained arrays cannot be specified
— If you need an unconstrained array, declare a fixed array and
modify the generated code

Generated UVMF Code
ALU_in interface package
 Generating the Interface Code
— Execute the following command to generate the ALU_in agent code
python $UVMF_HOME/scripts/yaml2uvmf.py ALU_in_interface.yaml
— You can create a simple .bat file on Windows to set the $UVMF_HOME
environment variable and then call python on your config file
— All UVMF agent code is placed under uvmf_template_output /

verification_ip / interface_packages
— All generated code for the ALU_in agent will be saved under the ALU_in_pkg
folder [as shown opposite]

parameterized ALU agent
 Impact of Using Parameters
— All classes and interfaces within the generated UVMF code for the ALU agent will be parameterized with the
parameters we specified in the YAML configuration file
— Tip: Only use parameters if you really need them as it does complicate the generated code

Generated UVMF Code
ALU_in
 UVMF Transactors
— ALU_in_driver & ALU_in_monitor are class based and will be
instantiated inside the agent class
— ALU_in_driver_bfm & ALU_in_monitor_bfm are interfaces & will

be instantiated in the top level testbench module (hdl_top)

Generated UVMF Code
ALU_in
 Looking at the ALU_in_pkg directory

 Contains the following key files
— ALU_in_filelist_hdl.f
Compilation list of hdl files (the interface and the 2 BFMs)
— ALU_in_filelist_hvl.f
Compilation list of hvl files (all other files)
— ALU_in_pkg.sv
This is the verification package (HVL) that `includes all the generated classes for our
VIP agent (all from directory src)
— ALU_in_pkg_hdl.sv
This package will be used for the HDL part of the VIP. The HDL part is synthesized
by the emulator.
— compile.do
Contains the compile command for the generated agent. Use on Windows or Linux
— Makefile
Contains the compile commands for the generated agent. Use on Linux
NOTES:
There may be some additional meta-data files generated in the ALU_in_pkg directory. These can be ignored.

Generated UVMF Code
ALU_in
 Looking at the ALU_in_pkg/src directory

— ALU_inreg_adaptor.svh
Template adaptor for UVM register layer. Requires user to fill in functionality.
— ALU_in_agent.svh
Agents class (parameterized)
— ALU_in_configuration.svh
Configuration class for the agent
— ALU_in_driver.svh
Driver class to be instantiated in the agent
— ALU_in_driver_bfm.sv
Bus functional model to convert transactions to protocol pin wiggles. Requires user to fill in
functionality
— ALU_in_if.sv
Signal interface for the agent. User can optionally add protocol assertions in here.
— ALU_in_macros.sv
Defines structs used to pass data between classes, hvl, BFMs and hdl
— ALU_in_monitor.svh
Monitor class to be instantiated in the agent
— ALU_in_monitor_bfm.sv
Bus functional model to convert the protocol pin wiggles to transactions. Requires user to fill in
functionality

Generated UVMF Code
ALU_in

— ALU_in_random_sequence.svh
Starter sequence. Randomizes 1 instance of the ALU_in transaction class
and sends to sequencer.
Extended from ALU_in_sequence_base
— ALU_in_responder_sequence.svh
This sequence class can be used to provide stimulus when an interface
has been configured to run in a responder mode. Requires user to fill in
functionality
— ALU_in_sequence_base.svh
Base class with useful methods that all inherited sequences can utilize
— ALU_in_transaction.svh
This is the sequence item that we will use in our sequences. Extends from
‘uvmf_transaction_base.svh’ which contains global “id” which holds a
unique number for every transaction. Also contains several methods for
printing, comparing, etc
— ALU_in_transaction_coverage.svh
This class records ALU_in transaction information using a covergroup
named ALU_in_transaction_cg.
An instance of this coverage component is instantiated in the
uvmf_parameterized_agent if the has_coverage flag is set

Generated UVMF Code
ALU_in
— ALU_in_typedefs.svh
This file contains defines and typedefs used only in the testbench (HVL) side
of the testbench. Package may not contain any defines or typedefs after
but will still be generated
— ALU_in_typedefs_hdl.svh
This file contains defines and typedefs used by the interface package
performing transaction level simulation activities. This package is used by
the driver/monitor BFMs

ALU_out_interface.yaml
uvmf:
interfaces:
ALU_out:
clock: clk
reset: rst
reset_assertion_level: ‘False’
— Separate YAML configuration file for the ALU output signal interface
— Agent name = ALU_out
— Primary clock = clk
— Primary reset = rst, with active low polarity
25 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

config_vars: []
— No configuration variables or constrains specified for the ALU_out
agent
hdl_typedefs: []
hvl_typedefs: []
— No types declared for the ALU_out agents
parameters:
- name: ALU_OUT_RESULT_WIDTH
- type: int
- value: ‘16’
— Parameter to define the width of the ALU result defined

ports:
- dir: input
name: done
width: ‘1’
— Define names, directions and widths of all signals on the ALU
output interface
NOTES:
— Direction specified here is in relation to the testbench
o i.e. ‘done’ is an output from the ALU (DUT) and an input to the
testbench
— The ‘result’ signal use the ALU_OUT_RESULT_WIDTH
parameter which was defined in the parameter section of the
YAML configuration file

response_info:
data: []
operation: 1’b0
— For the ALU_out agent, we have no response data to be passed back to the sequence
— Leave with empty/default values.

transaction_contraints: []
transaction_vars:
- iscompare: ‘True’
isrand: ‘False’
name: result
type: bit [ALU_OUT_RESULT_WIDTH-1:0]
— The ALU_out agent has no transaction constraints
— The ALU_out agent has a transaction class which contains a single variable called ‘result’. The width of the
variable is defined by the agent parameter ALU_OUT_RESULT_WIDTH), which is set to 16 by default.
— Since we only monitor this interface, there is no need to randomize the transaction so we specify isrand:
‘False’
— We will want to compare the result variable in the transaction class do_compare method so we specify
iscompare: ‘True’

Generated UVMF Code
ALU_out_if
 Generating the Interface Code

— Execute the following command to generate the ALU_in agent code
python $UVMF_HOME/scripts/yaml2uvmf.py ALU_out_interface.yaml
— All UVMF agent code is placed under uvmf_template_output / verification_ip

/ interface_packages
— All generated code for the ALU_out agent will be saved under the ALU_out_pkg
folder [as shown opposite]
— There may be some additional meta-data files generated in the ALU_out_pkg

directory. These can be ignored

ALU Environment Config File
ALU_environment.yaml
 UVMF Environment Packages
— UVMF uses a separate environment level YAML configuration file to generate the environment level classes
— The classes for the environment, its configuration, and sequence are included in the generated environment package
— It can optionally include predictor and scoreboard classes
— The environment package can be reused when a block level UVMF testbench is being used as part of a subsystem/chip
level testbench.
 The environment config file (ALU_environment.yaml) is covered in more detail in the following slides
31 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] env

Environment Config File
uvmf:
environments:
ALU: Tells UVMF code generator to create an
environment with name ‘ALU_env_pkg’
agents:
- name: ALU_in_agent
type: ALU_in
- name: ALU_out_agent
type: ALU_out
Tells UVMF code generator to include 1 x ALU_in agent and 1 x ALU_out agent.
-name defines the instance name
-type is the name of the agent given by the user in the interface YAML configuration file

analysis_components:
- name: ALU_pred
type: ALU_predictor
Tells UVMF code generator to include a component of type ALU_predictor with instance name
ALU_pred.
This ALU_predictor component has not been defined yet and will be described in a separate
YAML configuration file.
analysis_exports: [] These allow the user to specify analysis exports & ports to add to the environment class,
typically implemented when the block level environment is to be utilized within a larger system
analysis_ports: [] level UVM testbench.
We don’t need to specify anything here for the ALU testbench.

config_vars: []
parameters: []
These allow the user to specify environment level configuration variables, configuration
constraints and parameters for the environment class.
Parameters specified here can be passed down into any of the instantiated agents or other
analysis components.
We don’t need to specify anything here for the ALU testbench.

scoreboards:
- name: ALU_sb
sb_type: uvmf_in_order_scoreboard
trans_type: ALU_out_transaction
subenvs: [] The scoreboards entry allow the user to specify any scoreboard components to be added the environment class.
Here we specify the following for ALU testbench

• Add a scoreboard component with instance name = ALU_sb
• The class type for the scoreboard = uvmf_in_order_scoreboard. This is a UVMF base library component
• We define the transaction class that the scoreboard will operate on to be ALU_out_transaction
The subenvs entry allows the user to import other pre-generated UVMF environments, thus creating a
hierarchical environment.
Typically this is used when importing QVIP UVMF environments or creating a system level UVMF testbench that
is reusing block level UVMF environments
We don’t need to specify anything here for the ALU testbench

tlm_connections
- driver: ALU_in_agent.monitored_ap
receiver: ALU_pred.ALU_in_agent_ae
The tlm_connections entry allows the user to specify a point to point connection between 2 ports/exports
The driver entry is the start point

The receiver entry is the end point
For the ALU testbench we specify 3 connections as shown in the diagram below
connection 01
connection 00 connection 02
ALU_predictor ALU_sb
ALU_in ALU_out
ALU dut
agent agent

 TLM Connections : Details
ALU_in_agent : instance name of agent

monitored_ap : fixed name for analysis port on all UVMF agents
ALU_pred : instance name of ALU predictor
ALU_in_agent_ae : fixed name for predictor analysis export
ALU_pred : instance name of predictor

ALU_sb_ap : fixed name for analysis port on scoreboard [‘_ap’ added to inst name]
ALU_sb : instance name of scoreboard
expected_analysis_export : fixed name for scoreboard ‘expected’ analysis export

 TLM Connections : Details (cont)
ALU_out_agent : instance name of agent

monitored_ap : fixed name for analysis port on all UVMF agents
ALU_sb : instance name of ALU scoreboard
actual_analysis_export : fixed name for scoreboard ‘actual’ analysis export

ALU_util_comp_alu_predictor.yaml
 The predictor to be used in our environment can optionally either be

defined in the same YAML file as the environment or in a separate file. For
the ALU testbench we shall use a separate file
uvmf:
util_components: Tells UVMF code generator to create an analysis
ALU_predictor: component with name ‘ALU_predictor’
analysis_exports:
- name: ALU_in_agent_ae
type: ‘ALU_in_transaction #()’ Tells UVMF code generator to create exports/ports with the
analysis_ports: specified names and specified transaction types
- name: ALU_sb_ap
type: ‘ALU_out_transaction #()’
type: predictor Currently the only supported util_component type is predictor. In future
releases of UVMF this will be expanded to include coverage components

Generated UVMF Code
ALU_env_pkg
 Generating the Environment Code
— In order to generate the environment level code, we need to specify the YAML
configuration files for the environment, the predictor component and for each of the
interfaces instantiated in that environment
— Execute the following command to generate the ALU_in environment code
python $UVMF_HOME/scripts/yaml2uvmf.py \
ALU_in_interface.yaml \
ALU_out_interface.yaml \
ALU_util_comp_alu_predictor.yaml \
— You can create a simple .bat file on Windows to set the $UVMF_HOME environment
variable and then call python on your YAML config files as shown below

Generated UVMF Code
ALU_env_pkg
 Files get generated under uvmf_template_output/verification_ip/environment_packages/ALU_env_pkg
 The key files are as follows:
 ALU_environment.svh
— ALU environment class that instantiates the agents, scoreboards, predictors & connects them
 ALU_env_configuration.svh
— Configuration class for ‘ALU’ environment
 ALU_env_sequence_base.svh
— Base sequence class for any environment level sequences
 ALU_env_typedefs.svh
— Contains any defines and typedefs to be compiled for use with the environment package
 ALU_predictor.svh
— Generated predictor class for ALU environment.
— User will need to add code to predictor model to implement the prediction function
 ALU_env_pkg.sv
— ALU Environment package
 compile.do
— Contains the compile commands for the generated environment package. Use on Windows or Linux
 Makefile
— Contains the compile commands for the generated environment package. Use on Linux

ALU Bench Config File
ALU_bench.yaml
 UVMF Top Level Testbench
— The bench config file will be used to generate the UVMF top level testbench
— The top level testbench will instantiate the ALU env (which in turn instantiates the ALU interface agents as well as the
environment configuration class
— It facilitates the top-down configuration of the environment, which in turn configures the agents.
— It provides a default sequences and a default test to run
— It provides a simulation directory and makefile/run.do file for compiling and simulating the generated code
— The code generated from the bench level config file is specific to the DUT it is testing and in general will be non-reusable
code.
 Lets look at the bench config file (ALU_bench.yaml) in more detail
42 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] bench

ALU_bench.yaml
uvmf:
benches: Tells UVMF code generator to create a
ALU: bench with name ‘ALU’
active_passive: Tells UVMF code generator to include the specified

- bfm_name: ALU_in_agent agents & defines if the agents are ACTIVE or
PASSIVE
value: ACTIVE
- bfm_name: ALU_out_agent
value: PASSIVE
For the ALU testbench, the ALU_in_agent will be
generating stimulus and monitoring the signal
interface, so set it ACTIVE.
The ALU_out_agent will not drive stimulus as it

only monitors DUT output signals, so set it
PASSIVE.

ALU_bench.yaml
clock_half_period: 5ns Defines the period and phase offset of

the top level testbench clock
clock_phase_offset: 9ns
Enables user to specify how any underlying BFMs

interface_params: []
should be parameterized. Not used for ALU testbench
reset_assertion_level: ‘False’ Defines the assertion level and duration

reset_duration: 200ns of the top level testbench reset
top_env: ALU The name of the top level environment to instantiate in this
bench. For the ALU testbench this is the ALU environment

Generated UVMF Code
ALU testbench
 Generating the Testbench Code

— In order to generate the top level testbench code, we need to specify the YAML configuration file for the bench and for
each of the environments, predictors & interfaces instantiated in that bench
— Execute the following command to generate the ALU bench code
python $UVMF_HOME/scripts/yaml2uvmf.py \
ALU_in_interface.yaml \
ALU_out_interface.yaml \
ALU_util_comp_alu_predictor.yaml \
ALU_environment.yaml \
ALU_bench.yaml
— You can create a simple .bat file on Windows to set the $UVMF_HOME environment variable and then call python on
your YAML config files as shown below

Generated UVMF Code
project_benches/ALU
 Generates the top level UVMF testbench plus scripts for

compiling and running the simulation
 Files generated under
uvmf_template_output/project_benches/ALU

Generated UVMF Code
project_benches/ALU
 docs
— Placeholder folder for user to place documentation

Generated UVMF Code
project_benches/ALU
 registers
— Placeholder folder for user to place register layer package

Generated UVMF Code
project_benches/ALU
 rtl
— Placeholder folder for user to place RTL DUT code
NOTE:
This is an optional location to place the DUT code.
The user can place their DUT code anywhere they want.
 rtl/verilog/verilog_dut.v
― Dummy Verilog DUT code created by the code generator and instantiated in hdl_top
 rtl/vhdl/vhdl_dut.v
― Dummy VHDL DUT code created by the code generator and instantiated in hdl_top

Generated UVMF Code
project_benches/ALU
 sim
— Directory where user should run simulations
— Contains invoke_questa.bat script for windows users to compile & load

the simulation
— Contains Makefile for Linux users to compile & run testbench
— Contains compile.do for Windows users to compile the testbench
— Contains run.do for Windows users to run the testbench
— Contains wave.do which is populated with agent transactions &
interface signals
— Also contain some other support files for emulation users plus a testlist
for Questa VRM users.

Generated UVMF Code
project_benches/ALU
 tb
— Multiple sub-folders for testbench
 Parameters
— Top level testbench params package (interface names, etc)
 Sequences
— top level sequence and a sequence base class
— register sequence template class
— Sequence package
 testbench
— hdl_top.sv : top level module based TB
— hvl_top.sv : non-synthesizable parts of top level TB
 tests
— default test (test_top), extended from test base class
— Derived test (extended from test_top) template class
— register test template class
— test package

Agenda
 Introduction
 ALU Overview
52 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] sim

Out Of The Box Simulation
project_benches/ALU/sim
 OS Considerations
— Linux
– make debug : compiles and loads the testbench in the Questa GUI (interactive simulation)
– make build : only compiles the generated code
– make run_gui : invokes interactive simulation without recompiling the code
– make run_cli : invokes command line simulation without recompiling the code
— Windows
– do compile.do : compiles the generated testbench code
– do run.do : loads the testbench in Questa
– invoke_questa.bat : invokes Questa and executes the compile.do and run.do TCL files to compiled and
load the simulation
— Makefile sets default OS architecture to 32 bit

– If running on the 64 bit version of Questa on Linux, you can change the OS setting to 64 bit as follows;
make build MACHINE_ARCH=‘-64’

make debug MACHINE_ARCH=‘-64’

 Bench level config file
— Generated Makefile / run.do invokes vsim with +UVM_TESTNAME=test_top
— Also applies several other switches to vsim that are required to run the UVMF simulation
o Example vsim command from the run.do script is shown below
o We recommend that you do not remove any of the switches being applied
vsim -i -32 -sv_seed random +UVM_TESTNAME=test_top \

+UVM_VERBOSITY=UVM_HIGH \
-permit_unmatched_virtual_intf +notimingchecks \
-suppress 8887 -uvmcontrol=all -msgmode both \
-classdebug –assertdebug \
+uvm_set_config_int=*,enable_transaction_viewing,1 \
-do " set NoQuitOnFinish 1; onbreak {resume}; run 0; \
do wave.do; set PrefSource(OpenOnBreak) 0; \
radix hex showbase; " optimized_debug_top_tb

 Loaded Simulation
scoreboard
predictor
ALU_out agent
ALU_in agent
Class based UVM top level
Module based UVM top level
Default example Verilog DUT
Default example VHDL DUT

 Wave Window : Auto populated with UVMF agent interface signals and transactions
― Screen shot shows wave window after running simulation for 500 ns
Transactions generated from the UVMF agent monitors

• Just shows default values for transaction data members.
DUT not driving any values yet.

project_benches/ALU/tb/tests/src
 Default test : top_test.svh

— Extends from uvmf_test_base
— Is parameterized with the

This is the default top level
configuration, environment and virtual sequence that gets
sequence to use executed
— Build phase kicks off top down

configuration

project_benches/ALU/tb/sequences/src
 Default virtual sequence :

ALU_bench_sequence_base.svh
1. Construct ALU_in agent sequence 1
2. Both agents held until reset is de-

2
asserted
3. Placeholder to start a responder 3

sequence
4. Starts agent random sequence 4

and repeats 25 times. (Only the
ALU_in agent was set ACTIVE, so
only one sequence executed here)
5. Wait for 400 clock cycles after 5

sequences have finished to flush
and data from DUT

project_benches/ALU/tb/sequences/src
 Default sequence : ALU_bench_sequence_base.svh

— Sequence body (shown on previous slide)
o creates agent sequences
— The ALU_out agent is passive so it has no default sequence to run
o Repeats each agent sequence to run 25 times
— The default random sequence randomizes and generates 1 transaction.
o Uses utility methods in agent configs to wait for specified number of clocks
— Sequence code (not shown)

o Extends from uvmf_sequence_base
o Defines sequence handles for to run on each active agent.
o Gets the config handles for each agent from the UVM config DB
o Get the sequencer handles for each agent from the UVM config DB

Agenda
 Introduction
 ALU Overview
60 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] DUT-code

Completing the UVMF Testbench
 User modifications to the UVMF Generated Code
— You generated the UVMF testbench from bench level YAML configuration file. Now you need to add DUT
specific code into some of the generated files.
— These modification steps include
1. Adding the DUT & wiring it up to the BFMs and the clock/reset
2. Adding protocol specific information to the driver BFMs
3. Adding protocol specific information to the monitor BFMs
4. Adding DUT specific behavior to the predictor
— You will then need to create additional tests & sequences to exercise the DUT functionality, which requires the
following steps
1. Extending the default test to create a new test which overrides the default sequence
2. Extending the default sequence to create a new sequence that generates the desired stimulus for the test.
 The following slides will look at the code changes required to implement each of the above steps

Instantiate & Wire Up the DUT
project_benches/ALU/tb/testbench/hdl_top.sv
 Clocks & Resets

— The hdl_top module contains simple clock and reset generation code that
the user can modify to change frequencies, add more clocks, etc
depending on the need for their specific DUT
— The clock frequency, clock offset, reset polarity & reset duration were
specified from the bench level YAML configuration file
YAML ALU BENCH CONFIG
— In the case of the ALU IP we can leave this code unmodified

— For other DUTs you may need to modify this code to generate different
frequency clocks or opposite polarity resets

 The DUT
— The DUT RTL model is alu.v
— This file is located at the top level of the tutorial directory.
— You can copy this file into the corresponding rtl folder under your
uvmf_template_output/project_benches/ALU/rtl/verilog which was created when you ran
your python config files
NOTE: You do not have to place the DUT RTL code in this this directory. This is merely a
placeholder location for DUT source code but it can reside anywhere on disk.

 Instantiate the DUT

— Edit the file project_benches/ALU/tb/testbench/hdl_top.sv
— Find the comment that says “Instantiate DUT here”
— Remove the instantiations of ‘dut_verilog’ & ‘dut_vhdl’
— Add instance of the ALU and wire up ports to the corresponding agent interface
Original Code
Modified Code
NOTES:
The following files have define the Systemverilog interface signals:

• uvmf_template_output/verification_ip/interfaces/ALU_in_pkg/src/ALU_in_if.sv
• uvmf_template_output/verification_ip/interfaces/ALU_out_pkg/src/ALU_out_if.sv
The testbench power up reset signal ‘rst’ is passed in to the agent BFM interfaces. However, the
ALU ‘rst’ pin needs to be driven active either when the power up reset is active or when a
RST_OP transaction is generated by a UVM test/sequence. The ALU ‘rst’ is therefore be driven by
the ALU_in agent. You will modify the ALU_in driver BFM file to implement this in a later step.

 Compiling The DUT
— Go to the folder project_benches/ALU/sim
— There is a compile.do for Windows customers and a Makefile for Linux users.
— compile.do :
o Remove the compilation lines for the default verilog_dut.v & vhdl_dut.vhd
Original
o Replace with the vlog command to compile the ALU.v source file
Modified

 Compiling The DUT
— There is a compile.do for Windows customers and a Makefile for Linux users.
— Makefile
o Modify the source file list from the default verilog_dut.sv to use the alu.v source file
Original Modified
o Modify the comp_ALU_dut target to only now compile up a Verilog DUT

Original Modified

 Simulating with the ALU DUT

— LINUX
– Use the Makefile (make build) to compile the testbench
– Check that there are no compile errors
– Use the Makefile (make debug) to load the simulation
– Check that the ALU (instance name DUT) appears in the
hierarchy of hdl_top
— Windows
– Use the invoke_questa.bat script to compile & load the
testbench
– Check that there are no compile errors
– Check that the ALU (instance name DUT) appears in the
hierarchy of hdl_top

Adding Protocol Information To The Driver BFM
verification_ip/interface_packages/ALU_in_pkg/src/
ALU_in_driver_bfm.sv
 Modifying the ALU_in driver BFM

— Go to the folder verification_ip/interface_packages/ALU_in_pkg/src
— Edit the file ALU_in_driver_bfm.sv and locate the ‘initiate_and_get_response’ task
— By default the UVMF generator just has 4 consecutive clock delays inserted in to the driver. No data
is actually driven onto the ALU_in bus interface
— This code needs to be modified to implement the interface protocol
Original Code


— Replace the 4 consecutive clock cycle delays with the following code
Modified Code
NOTES:
The reset op code only drives the ALU reset
pin and is therefore handled separately in it’s
own task.
— Add the following 2 tasks to the module

New Code
NOTES:
Any control signals like the ALU reset & valid must be driven at all times New Code
Any data signals like the ALU operator and operands are only driven for specific
cycles and then set back to ‘Z’ values


— Modify the code that generates the ALU_rst_o signal as shown below
Original Code
Modified Code
NOTES:
• We want to reset the ALU if either the top level reset (rst_i) is active or when a RST_OP operation is received (which drives alu_rst_o low).
So we logically AND the 2 reset driving signals together.


— The driver outputs are declared as type ‘reg’ & given an initial value of ‘z’
— For any DUT controls that need to be at a defined ‘0’ or ‘1’ value, then we need to add code to reset them
Additional Code
NOTES:
• We add an always block inside the driver bfm that is sensitive to the reset to procedurally assign the
storage signals that are continuously driven onto the pins based on INITIATOR/RESPONDER setting.
• For the ALU we set the valid_o and alu_rst_o signals to 0 when reset is activated
• For the ALU we have to also add an always block to set alu_rst_0 when the external reset is removed.

 Checking the driver BFM code changes
— Use the compile.do/run.do or the Makefile (make debug) to check that there are no compilation errors in the code you
have modified/added.
1. If you look at the ALU signals (ALU_in_agent_bus & ALU_out_agent_bus) you will see that the testbench is sending
operations to the ALU and that results are being generated
2. The transactions are still showing incorrect value since the monitor code has not been modified yet. You will fix this next.

Adding Protocol Information To The Monitor BFM
ALU_in_monitor_bfm.sv
 Modifying the ALU_in monitor BFM

— Go to the folder verification_ip/interface_packages/ALU_in_pkg/src
— Edit the file ALU_in_monitor_bfm.sv and locate the ‘do_monitor’ task
— By default the UVMF generator just has 4 consecutive clock delays inserted in to the monitor. No data
is actually read from the ALU_in bus interface
Original Code
NOTES
This is why we see the ALU_in_transactions are all 4 cycles
long and the displayed data values are just the language type
defaults

 Modifying the ALU_in monitor BFM

Modified Code
NOTES
• Wait until either valid goes high or reset goes active
• Read bus values
• If reset active then wait until reset becomes inactive, then assign
RST_OP code

 Checking the monitor BFM code changes
— Use invoke_questa.bat or the Makefile (make debug) to check that there are no compilation errors in the code you
have modified/added.
1. The ALU_in transactions are now showing the actual stimulus data values and the transaction lengths match the corresponding
pin signal activity. Due to simulator randomization variation, you my see different data values being generated.
2. The ALU_out_transactions still have default values since you have not modified the ALU_out_monitor BFM code yet.

verification_ip/interface_packages/ALU_out_pkg/src/
ALU_out_monitor_bfm.sv
 Modifying the ALU_out monitor BFM

— Go to the folder verification_ip/interface_packages/ALU_out_pkg/src
— Edit the file ALU_out_monitor_bfm.sv and locate the ‘do_monitor’ task
— By default the UVMF generator just has 4 consecutive clock delays inserted in to the monitor. No data is actually
read from the ALU_out bus interface
Original Code
NOTES
This is why we see the ALU_out_transactions are all 4
cycles long and the displayed ‘result’ data values are just
the language type defaults

 Modifying the ALU_out monitor BFM

Modified Code
NOTES
• Wait until done_i goes high
• Read result value

 Checking the monitor BFM code changes
— Use the compile.do/run.do or the Makefile (make debug) to check that there are no compilation errors in the code
you have modified/added.
1. The ALU_out transactions are now showing the actual result data values and the transaction lengths match the
corresponding pin signal activity.

Adding DUT Behaviour To The Predictor
verification_ip/environment_packages/ALU_env_pkg/src/ALU_predictor.svh
 Modifying the ALU predictor

— Go to the folder verification_ip/environment_packages/ALU_env_pkg/src
— Edit the file ALU_predictor.svh and locate the ‘write_ALU_in_agent_ae’ task
— Transactions received through ALU_in_agent_ae initiate the execution of this function

— This function performs prediction of DUT output values based on DUT input, configuration and state
— This code needs to be modified to implement the DUT functionality
Original Code
79 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] Prediction

 Modifying the ALU predictor
— Insert the following case statement into the task to implement the ALU operations
— Note that we deliberately ignore the RST_OP op code, taking care not to write a transaction out to the analysis export
(which is connected to the scoreboard).
Modified Code

 Checking the predictor code changes
— Use the invoke_questa.bat or the Makefile (make debug) to check that there are no compilation errors in the code
you have modified/added.
— Run the simulation to the end and examine the transcript
— During the simulation, the scoreboard will generate a message each time it does a compare of the expected data
from the predictor and the actual data from the DUT
— You should see several messages (one for each transaction) similar to the following:
# UVM_INFO
C:/MentorTools/questasim_10.7b/examples/UVM_Framework/UVMF_3.6h/uvmf_base_pkg/src/uvmf_in_order_scoreboard.svh(106) @
2269000: uvm_test_top.environment.ALU_sb [SCBD] MATCH! - EXPECTED: result:0x00fc ACTUAL: result:0x00fc
— The scoreboard will also report a summary of the total number of compares and the number of
MATCHES/MISMATCHES
# UVM_INFO C:/MentorTools/questasim_10.7b/examples/UVM_Framework/UVMF_3.6h/uvmf_base_pkg/src/uvmf_scoreboard_base.svh(234)
@ 6379000: uvm_test_top.environment.ALU_sb [SCBD] SCOREBOARD_RESULTS: PREDICTED_TRANSACTIONS=22 MATCHES=22
MISMATCHES=0
— If you see the above messages, then the predictor and scoreboard are working correctly

Status So Far
 Basic ALU operation appears to be working
1. There should be no errors at this stage. In the wave window there should be no red triangles, which would
indicate UVM Errors from the scoreboard
 Still To Do
— Create a new test & sequence to exercise the RST_OP which is currently not being tested.
— This is due to the constraint we specified back in the YAML config file for the ALU_in interface which only selects
from the following ALU operations.
82 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] Test & Sequence
Creating an interface reset sequence
verification_ip/interface_packages/ALU_in_pkg/src
ALU_in_reset_sequence.svh
 UVMF Generated Sequence
1. ALU_in agent was generated with the following sequence
interface_packages/ALU_in_pkg/src/ALU_in_random_sequence.svh
2. It randomizes ALU operations, selecting from no_op, add_op, and_op, xor_op & mul_op
3. Copy the ALU_in_random_sequence.svh file to ALU_in_reset_sequence.svh
4. Edit the sequence and change all references to ALU_in_random_sequence to ALU_in_reset_sequence.
5. After the randomization of the ALU_in_transaction, set the ALU op = RST_OP
verification_ip/interface_packages/ALU_in_pkg/src
ALU_in_reset_sequence.svh
Modified Code
© Mentor Graphics Corp.
Company Confidential
verification_ip/interface_packages/ALU_in_pkg/ALU_in_pkg.sv
STEPS
• Update the ALU_in_pkg to include the newly created

ALU_reset_sequence.svh file
• The compilation script will compile this package and

therefore all files that it includes
85 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] Test & Sequence Modified Code
Creating a new bench virtual sequence
project_benches/ALU/tb/sequences/src/ALU_random_sequence.svh
 UVMF Generated Sequence

1. ALU_in bench was generated with the following virtual sequence
project_benches/ALU/tb/sequences/src/ALU_bench_sequence_base.svh
2. This is the default sequence that gets ran by the default test.
3. Extend this sequence to create a new sequence called ALU_random_sequence.
4. We have the handle for the ALU_in_random sequence from the base class, but we need to define a
handle for the new ALU_in_reset_sequence
5. Create the sequences
6. Utilize the agent configuration methods to wait until the reset is released and then wait a few clock
cycles more
7. In the body of the sequence we will generate some random ALU operations, followed by a reset
operation and then we will generate some more random ALU operations.
8. Utilize the agent configuration method to wait 50 clock cycles before ending the sequence
Creating a new bench virtual sequence
project_benches/ALU/tb/sequences/src/ALU_random_sequence.svh
8
New Sequence Code
Creating a new bench level sequence
project_benches/ALU/tb/sequences/ALU_sequence_pkg.sv
STEPS
• Update the ALU_sequences_pkg to include the

newly created ALU_random_sequence.svh file
• The compilation script will compile this package

and therefore all files that it includes
Modified Code
Adding a New UVM Test
project_benches/ALU/tb/tests/src/ALU_random_test.svh
 Example derived test provided in

tests/src/example_derived_test.svh
1. Create a new test, ALU_random_test & extend it from test_top
2. In the build phase, specify a factory override of the default sequence (which is
ALU_bench_sequence_base) to replace it with the new sequence ALU_random_sequence.
New Code
Adding a New UVM Test
project_benches/ALU/tb/tests/ALU_tests_pkg.sv
 Add the new test to the ALU_tests_pkg
Modified Code
Simulating The New Test
 Go to the project_benches/ALU/sim folder
 Windows Users
— Edit run.do and modify the modify the last line where +UVM_TESTNAME specifies the test to run
 Linux Users
— Execute ‘make debug TEST_NAME=ALU_random_test’
91 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] Sim 2

Simulating The New Test
 Observe from the wave window
1. No operations occur during the reset
2. 10 random operations are then applied to the ALU
3. A reset is then applied to the ALU
4. 5 further random operations are then applied to the ALU

Adding Colour To The Transactions
verification_ip/interface_packages/ALU_in_pkg/src/ALU_in_transaction.svh
 Edit the file ALU_in_transaction.svh

 Find the function called ‘add_to_wave’
— It contains some comments about adding colour to the transactions
— Add the code highlighted below to the function which will assign a different colour to the transactions
depending on the opcode value

Re-Simulate The New Test
 Observe from the wave window

1. The ALU_in transactions are now colour coded depending on the op code
2. The colours match those specified in the add_to_wave function of the ALU_in_transaction class
 That completes the steps to get the UVMF environment running


www.mentor.com

A Step by Step Guide: UVM Framework Alu Tutorial

Uploaded by

A Step by Step Guide: UVM Framework Alu Tutorial

Uploaded by

UVM Framework

© Mentor Graphics Corp. Company Confidential

2 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] overview

 UVM Framework Steps

© Mentor Graphics Corp. Company Confidential

3 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4]

 YAML Configuration Files

© Mentor Graphics Corp. Company Confidential

4 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4]

© Mentor Graphics Corp. Company Confidential

5 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] overview

© Mentor Graphics Corp. Company Confidential

6 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] overview

7 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] overview

© Mentor Graphics Corp. Company Confidential

8 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] YAML

 YAML (YAML Ain't Markup Language)

© Mentor Graphics Corp. Company Confidential

9 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] YAML

 Required ALU Interface Config files

© Mentor Graphics Corp. Company Confidential

10 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] YAML

© Mentor Graphics Corp. Company Confidential

11 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

12 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

13 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

14 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

15 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

— Defines any constraints to be used on the transaction variables

© Mentor Graphics Corp. Company Confidential

16 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

— Defines any variable to be used by the transaction class.

17 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

python $UVMF_HOME/scripts/yaml2uvmf.py ALU_in_interface.yaml

— All UVMF agent code is placed under uvmf_template_output /

© Mentor Graphics Corp. Company Confidential

18 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

19 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

— ALU_in_driver_bfm & ALU_in_monitor_bfm are interfaces & will

© Mentor Graphics Corp. Company Confidential

20 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

 Looking at the ALU_in_pkg directory

21 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

 Looking at the ALU_in_pkg/src directory

22 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

 Looking at the ALU_in_pkg/src directory

© Mentor Graphics Corp. Company Confidential

23 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

 Looking at the ALU_in_pkg/src directory

© Mentor Graphics Corp. Company Confidential

24 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] in_ifc

© Mentor Graphics Corp. Company Confidential

25 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

© Mentor Graphics Corp. Company Confidential

26 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

© Mentor Graphics Corp. Company Confidential

27 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

© Mentor Graphics Corp. Company Confidential

28 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

— The ALU_out agent has no transaction constraints

© Mentor Graphics Corp. Company Confidential

29 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

 Generating the Interface Code

python $UVMF_HOME/scripts/yaml2uvmf.py ALU_out_interface.yaml

— All UVMF agent code is placed under uvmf_template_output / verification_ip

— There may be some additional meta-data files generated in the ALU_out_pkg

© Mentor Graphics Corp. Company Confidential

30 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] out_ifc

 UVMF Environment Packages

© Mentor Graphics Corp. Company Confidential

31 UVMF ALU Tutorial : Step By Step Guide [UVMF 2019.4] env