Pages on Pedro Araújo

UVM Guide for Beginners

Tue, 18 Mar 2014 00:00:00 +0000

UVM Guide for Beginners

Due to the lack of UVM tutorials for complete beginners, I decided to create a guide that will assist a novice in building a verification environment using this methodology. I will not focus on verification techniques nor in the best practices in verifying a digital design, this guide was thought in helping you to understand the UVM API and in helping you to successfully compile a complete environment.

The simulator used is Synopsys VCS but the testbench should compile in any HDL simulator that supports SystemVerilog.

The code for the environment can be download in this GitHub repository: https://github.com/pedro-araujo/uvm-testbench-tutorial-simple-adder

Introduction

As digital systems grow in complexity, verification methodologies get progressively more essential. While in the early beginnings, digital designs were verified by looking at waveforms and performing manual checks, the complexity we have today don’t allow for that kind of verification anymore and, as a result, designers have been trying to find the best way to automate this process.

The SystemVerilog language came to aid many verification engineers. The language featured some mechanisms, like classes, covergroups and constraints, that eased some aspects of verifying a digital design and then, verification methodologies started to appear.

UVM is one of the methodologies that were created from the need to automate verification. The Universal Verification Methodology is a collection of API and proven verification guidelines written for SystemVerilog that help an engineer to create an efficient verification environment. It’s an open-source standard maintained by Accellera and can be freely acquired in their website.

By mandating a universal convention in verification techniques, engineers started to develop generic verification components that were portable from one project to another, this promoted the cooperation and the sharing of techniques among the user base. It also encouraged the development of verification components generic enough to be easily extended and improved without modifying the original code.

All these aspects contributed for a reduced effort in developing new verification environments, as designers can just reuse testbenches from previous projects and easily modify the components to their needs.

These series of webpages will provide a training guide for verifying a basic adder block using UVM. The guide will assume that you have some basic knowledge of SystemVerilog and will require accompaniment of the following resources:

Accellera’s UVM User’s Guide 1.1
Accellera’s UVM 1.1 Class Reference
Verification Academy’s UVM Cookbook
Book “SystemVerilog for Verification: A Guide to Learning the TestBench Language Features”, by Chris Spear
Book “Comprehensive Functional Verification: The Complete Industry Cycle”, by John Goss

This guide will be divided in 3 different parts:

The first part, starting on “Chapter 1.1 - The DUT”, will explain the operation of the device under test (DUT): the inputs, the outputs and the communication bus
The second part, starting on “Chapter 1.2 - Defining the verification environment”, will give a brief overview of a generic verification environment and the approach into verifying the DUT
The third part, starting on “Chapter 1.3 - Top Block”, will start to describe a possible UVM testbench to be used with our DUT with code examples. It’s important to consult to the external material in order to better understand the mechanism behind the testbench.

The DUT

This training guide will focus on showing how we can build a basic UVM environment, so the device under test was kept very simple in order to emphasize the explanation of UVM itself.

The DUT used is a simple ALU, limited to a single operation: the add operation. The inputs and outputs are represented in Figure 1.1.

This DUT takes two values of 2 bits each, ina and inb, sums them and sends the result to the output out. The inputs are sampled to the signal of en_i and the output is sent at the same time en_o is signalled.

The operation of the DUT is represented as a timing diagram and as a state machine in Figure 1.2.

The code for this DUT can be found here:

simpleadder.v

Defining the verification environment

Before understanding UVM, we need to understand verification.

Right now, we have a DUT and we will have to interact with it in order to test its functionality, so we need to stimulate it. To achieve this, we will need a block that generates sequences of bits to be transmitted to the DUT, this block is going to be named sequencer.

Usually sequencers are unaware of the communication bus, they are responsible for generating generic sequences of data and they pass that data to another block that takes care of the communication with the DUT. This block will be the driver.

While the driver maintains activity with the DUT by feeding it data generated from the sequencers, it doesn’t do any validation of the responses to the stimuli. We need another block that listens to the communication between the driver and the DUT and evaluates the responses from the DUT. This block is the monitor.

Monitors sample the inputs and the outputs of the DUT, they try to make a prediction of the expected result and send the prediction and result of the DUT to another block, the scoreboard, in order to be compared and evaluated.

All these blocks constitute a typical system used for verification and it’s the same structure used for UVM testbenches.

You can find a representation of a similar environment in Figure 2.1.

Usually, sequencers, drivers and monitors compose an agent. An agent and a scoreboard compose an environment. All these blocks are controlled by a greater block denominated of test. The test block controls all the blocks and sub blocks of the testbench. This means that just by changing a few lines of code, we could add, remove and override blocks in our testbench and build different environments without rewriting the whole test.

To illustrate the advantage of this feature, let’s imagine a situation where we are testing a another DUT that uses SPI for communication. If, by any chance, we want to test a similar DUT but with I2C instead, we would just need to add a monitor and a driver for I2C and override the existing SPI blocks, the sequencer and the scoreboard could reused just fine.

UVM Classes

The previous example demonstrates one of the great advantages of UVM. It’s very easy to replace components without having to modify the entire testbench, but it’s also due to the concept of classes and objects from SystemVerilog.

In UVM, all the mentioned blocks are represented as objects that are derived from the already existent classes.

A class tree of the most important UVM classes can be seen in Figure 2.2.

The data that travels to and from our DUT will stored in a class derived either from uvm_sequence_item or uvm_sequence. The sequencer will be derived from uvm_sequencer, the driver from uvm_driver, and so on.

Every each of these classes already have some useful methods implemented, so that the designer can only focus on the important part, which is the functional part of the class that will verify the design. These methods are going to addressed further ahead.

For more information about UVM classes, you can consult the document Accellera’s UVM 1.1 Class Reference.

UVM Phases

All these classes have simulation phases. Phases are ordered steps of execution implemented as methods. When we derive a new class, the simulation of our testbench will go through these different steps in order to construct, configure and connect the testbench component hierarchy.

The most important phases are represented in Figure 2.3.

A brief explanation of each phase will follow:

The build phase is used to construct components of the hierarchy. For example, the build phase of the agent class will construct the classes for the monitor, for the sequencer and for the driver.
The connect is used to connect the different sub components of a class. Using the same example, the connect phase of the agent would connect the driver to the sequencer and it would connect the monitor to an external port.
The run phase is the main phase of the execution, this is where the actual code of a simulation will execute.
And at last, the report phase is the phase used to display the results of the simulation.

There are many more phases but none of them are mandatory. If we don’t need to have one in a particular class, we can just omit it and UVM will ignore it.

More information about UVM phasing can be consulted in Verification Academy’s UVM Cookbook, page 48.

UVM Macros

Another important aspect of UVM are the macros. These macros implement some useful methods in classes and in variables. they are optional, but recommended.

The most common ones are:

`uvm_component_utils - This macro registers the new class type. It’s usually used when deriving new classes like a new agent, driver, monitor and so on.
`uvm_field_int - This macro registers a variable in the UVM factory and implements some functions like copy(), compare() and print().
`uvm_info - This a very useful macro to print messages from the UVM environment during simulation time.

This guide will not go into much detail about macros, their usage is always the same for every class, so it’s not worth to put much thought into it for now.

More information can be found in Accellera’s UVM 1.1 Class Reference, page 405.

Typical UVM class

All this said, a typical UVM class will look a lot like the one described in the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


class generic_component extends uvm_component;
 `uvm_component_utils(generic_component)

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);

 //Code for constructors goes here
 end_function: build_phase

 function void connect_phase(uvm_phase phase);
 super.connect_phase(phase);

 //Code for connecting components goes here
 endfunction: connect_phase

 task run_phase(uvm_phase phase);
 //Code for simulation goes here
 endtask: run_phase

 function void report_phase(uvm_phase phase);
 //Code for showing simulation results goes here
 endfunction: report_phase
endclass: generic_component

The code listed here, is the most basic sample that all components will share as you will see from now on.

SimpleAdder UVM Testbench

After a brief overview of a UVM testbench, it’s time to start developing one. By the end of this guide, we will have the verification environment from the Figure 2.4.

This guide will begin to approach the top block and the interface on “Chapter 1.3 - Top Block”, then it will explain what data will be generated with the sequences and sequencers on “Chapter 1.4 - Sequences and sequencers”.com/uvm-guide-for-beginners/chapter-4-transactions-sequences-and-sequencers/).

Following the sequencers, it will explain how to drive the signals into the DUT and how to observe the response in chapters “1.5 - Driver” and “1.6 - Monitor” respectively.

Subsequently, it will explain how to connect the sequencer to the driver and the monitor to the scoreboard in “1.7 - Agent”. Then it will show to build a simple scoreboard in “1.8 - Scoreboard”.

And finally, the test will be executed and analyzed.

The testbench can be run with the execution of a Makefile provided in the repository. As I mentioned previously, this Makefile uses Synopsys VCS but it should be easily modifiable to be executed with any HDL simulator.

Top Block

In a normal project, the development of the DUT is done separately from the development of the testbench, so there are two components that connects both of them:

The top block of the testbench
A virtual interface

The top block will create instances of the DUT and of the testbench and the virtual interface will act as a bridge between them.

The interface is a module that holds all the signals of the DUT. The monitor, the driver and the DUT are all going to be connected to this module.

The code for the interface can be seen in the following code (simpleadder_if.sv).

1
2
3
4
5
6
7
8


interface simpleadder_if;
 logic    sig_clock;
 logic    sig_ina;
 logic    sig_inb;
 logic    sig_en_i;
 logic    sig_out;
 logic    sig_en_o;
endinterface: simpleadder_if

After we have an interface, we will need the top block. This block will be a normal SystemVerilog module and it will be responsible for:

Connecting the DUT to the test class, using the interface defined before.
Generating the clock for the DUT.
Registering the interface in the UVM factory. This is necessary in order to pass this interface to all other classes that will be instantiated in the testbench. It will be registered in the UVM factory by using the uvm_resource_db method and every block that will use the same interface, will need to get it by calling the same method. It might start to look complex, but for now we won’t need to worry about it too much.
Running the test.

The source for the top block is represented in the following code (simepladder_tb_top.sv).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


`include "simpleadder_pkg.sv"
`include "simpleadder.v"
`include "simpleadder_if.sv"

module simpleadder_tb_top;
 import uvm_pkg::*;

 //Interface declaration
 simpleadder_if vif();

 //Connects the Interface to the DUT
 simpleadder dut(vif.sig_clock,
 vif.sig_en_i,
 vif.sig_ina,
 vif.sig_inb,
 vif.sig_en_o,
 vif.sig_out);
 initial begin
 //Registers the Interface in the configuration block
 //so that other blocks can use it
 uvm_resource_db#(virtual simpleadder_if)::set(.scope("ifs"), .name("simpleadder_if"), .val(vif));

 //Executes the test
 run_test();
 end

 //Variable initialization
 initial begin
 vif.sig_clock = 1'b1;
 end

 //Clock generation
 always
 #5 vif.sig_clock = ~vif.sig_clock;
endmodule

A brief explanation of the code will follow:

The lines 2 and 3 include the DUT and the interface into the top block, the line 5 imports the UVM library, lines 11 to 16 connect the interface signals to the DUT.
Line 21 registers the interface in the factory database with the name simpleadder_if.
Line 24 runs one of the test classes defined at compilation runtime. This name is specified in the Makefile.
Line 34 generates the clock with a period of 10 timeunits. The timeunit is also defined in the Makefile.

For more information about interfaces, you can consult the book “SystemVerilog for Verification: A Guide to Learning the TestBench Language Features”, chapter 5.3.

The files can be found here:

Sequences and sequencers

The first step in verifying a RTL design is defining what kind of data should be sent to the DUT. While the driver deals with signal activities at the bit level, it doesn’t make sense to keep this level of abstraction as we move away from the DUT, so the concept of transaction was created.

A transaction is a class object, usually extended from uvm_transaction or uvm_sequence_item classes, which includes the information needed to model the communication between two or more components.

Transactions are the smallest data transfers that can be executed in a verification model. They can include variables, constraints and even methods for operating on themselves. Due to their high abstraction level, they aren’t aware of the communication protocol between the components, so they can be reused and extended for different kind of tests if correctly programmed.

An example of a transaction could be an object that would model the communication bus of a master-slave topology. It could include two variables: the address of the device and the data to be transmitted to that device. The transaction would randomize these two variables and the verification environment would make sure that the variables would assume all possible and valid values to cover all combinations.

In order to drive a stimulus into the DUT, a driver component converts transactions into pin wiggles, while a monitor component performs the reverse operation, converting pin wiggles into transactions.

After a basic transaction has been specified, the verification environment will need to generate a collection of them and get them ready to be sent to the driver. This is a job for the sequence. Sequences are an ordered collection of transactions, they shape transactions to our needs and generate as many as we want. This means if we want to test just a specific set of addresses in a master-slave communication topology, we could restrict the randomization to that set of values instead of wasting simulation time in invalid values.

Sequences are extended from uvm_sequence and their main job is generating multiple transactions. After generating those transactions, there is another class that takes them to the driver: the sequencer. The code for the sequencer is usually very simple and in simple environments, the default class from UVM is enough to cover most of the cases.

A representation of this operation is shown in Figure 4.1.

The sequence englobes a group of transactions and the sequencer takes a transaction from the sequence and takes it to the driver.

To test our DUT we are going to define a simple transaction, extended from uvm_sequence_item. It will include the following variables:

rand bit \[1:0\]ina
rand bit \[1:0\]inb
bit \[2:0\]out

The variables ina and inb are going to be random values to be driven to the inputs of the DUT and the variable out is going to store the result. The code for the transaction is represented in the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class simpleadder_transaction extends uvm_sequence_item;
 rand bit[1:0] ina;
 rand bit[1:0] inb;
 bit[2:0] out;

 function new(string name = "");
 super.new(name);
 endfunction: new

 `uvm_object_utils_begin(simpleadder_transaction)
 `uvm_field_int(ina, UVM_ALL_ON)
 `uvm_field_int(inb, UVM_ALL_ON)
 `uvm_field_int(out, UVM_ALL_ON)
 `uvm_object_utils_end
endclass: simpleadder_transaction

An explanation of the code will follow:

Lines 2 and 3 declare the variables for both inputs. The rand keyword asks the compiler to generate and store random values in these variables.
Lines 6 to 8 include the typical class constructor.
Lines 10 to 14 include the typical UVM macros.

These few lines of code define the information that is going to be exchanged between the DUT and the testbench.

To demonstrate the reuse capabilities of UVM, let’s imagine a situation where we would want to test a similar adder with a third input, a port named inc.

Instead of rewriting a different transaction to include a variable for this port, it would be easier just to extend the previous class to support the new input.

It’s possible to see an example in the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class simpleadder_transaction_3inputs extends simpleadder_transaction;
 rand bit[1:0] inc;

 function new(string name = "");
 super.new(name);
 endfunction: new

 `uvm_object_utils_begin(simpleadder_transaction_3inputs)
 `uvm_field_int(inc, UVM_ALL_ON)
 `uvm_object_utils_end
endclass: simpleadder_transaction_3inputs

As a result of the class simpleadder_transaction_3inputs being an extension of simpleadder_transaction, we didn’t need to declare again the other variables. While in small examples, like this one, this might not look like something useful, for bigger verification environments, it might save a lot of work.

Sequence

Now that we have a transaction, the next step is to create a sequence.

The code for the sequencer can be found in the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


class simpleadder_sequence extends uvm_sequence#(simpleadder_transaction);
 `uvm_object_utils(simpleadder_sequence)

 function new(string name = "");
 super.new(name);
 endfunction: new

 task body();
 simpleadder_transaction sa_tx;

 repeat(15) begin
 sa_tx = simpleadder_transaction::type_id::create(...

 start_item(sa_tx);
 assert(sa_tx.randomize());
 finish_item(sa_tx);
 end
 endtask: body
endclass: simpleadder_sequence

An explanation of the code will follow:

Line 8 starts the task body(), which is the main task of a sequence
Line 11 starts a cycle in order to generate 15 transactions
Line 12 initializes a blank transaction
Line 14 is a call that blocks until the driver accesses the transaction being created
Line 15 triggers the rand keyword of the transaction and randomizes the variables of the transaction to be sent to the driver
Line 16 is another blocking call which blocks until the driver has completed the operation for the current transaction

Sequencer

The only thing missing is the sequencer. The sequence will be extended from the class uvm_sequencer and it will be responsible for sending the sequences to the driver. The sequencer gets extended from uvm_sequencer. The code can be seen on the following code.

1

typedef uvm_sequencer#(simpleadder_transaction) simpleadder_sequencer;

The code for the sequencer is very simple, this line will tell UVM to create a basic sequencer with the default API because we don’t need to add anything else.

So, right now our environment has the following structure:

You might have noticed two things missing:

How does the sequence connects to the sequencer?
How does the sequencer connects to the driver

The connection between the sequence and the sequencer is made by the test block, we will come to this later on “Chapter 1.10 - Test”, and the connection between the sequencer and the driver will be explained on “Chapter 1.7 - Agent”.

For more information about transactions and sequences, you can consult:

Accellera’s UVM 1.1 User’s Guide, page 48
Verification Academy’s UVM Cookbook, pages 188 and 200

The code for this chapter can be found here:

simpleadder_sequencer.sv

Driver

The driver is a block whose role is to interact with the DUT. The driver pulls transactions from the sequencer and sends them repetitively to the signal-level interface. This interaction will be observed and evaluated by another block, the monitor, and as a result, the driver’s functionality should only be limited to send the necessary data to the DUT.

In order to interact with our adder, the driver will execute the following operations: control the en_i signal, send the transactions pulled from the sequencer to the DUT inputs and wait for the adder to finish the operation.

So, we are going to follow these steps:

Derive the driver class from the uvm_driver base class
Connect the driver to the signal interface
Get the item data from the sequencer, drive it to the interface and wait for the DUT execution
Add UVM macros

In the following code (simpleadder_driver.sv) you can find the base code pattern which is going to be used in our driver.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


class simpleadder_driver extends uvm_driver#(simpleadder_transaction);
 `uvm_component_utils(simpleadder_driver)

 //Interface declaration
 protected virtual simpleadder_if vif;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);
 void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name(.scope("ifs"), .name("simpleadder_if"), .val(vif)));
 endfunction: build_phase

 task run_phase(uvm_phase phase);
 //Our code here
 endtask: run_phase
endclass: simpleadder_driver

The code might look complex already but what it’s represented it’s the usual code patterns from UVM. We are going to focus mainly on the run_phase() task which is where the behaviour of the driver will be stated. But before that, a simple explanation of the existing lines will be given:

Line 1 derives a class named simpleadder_driver from the UVM class uvm_driver. The #(simpleadder_transaction) is a SystemVerilog parameter and it represents the data type that it will be retrieved from the sequencer.
Line 2 refers to the UVM utilities macro explained on “Chapter 1.2 - Defining the verification environment”.
Lines 7 to 9 are the class constructor.
Line 11 starts the build phase of the class, this phase is executed before the run phase.
Line 13 gets the interface from the factory database. This is the same interface we instantiated earlier in the top block.
Line 16 is the run phase, where the code of the driver will be executed.

Now that the driver class was explained, you might be wondering: “What exactly should I write in the run phase?”

Consulting the state machine from the “Chapter 1.1 - The DUT”, we can see that the DUT waits for the signal en_i to be triggered before listening to the ina and inb inputs, so we need to emulate the states 0 and 1. Although we don’t intend to sample the output of the DUT with the driver, we still need to respect it, which means, before we send another sequence, we need to wait for the DUT to output the result.

To sum up, in the run phase the following actions must be taken into account:

Get a sequence item
Control the en_i signal
Drive the sequence item to the bus
Wait a few cycles for a possible DUT response and tell the sequencer to send the next sequence item

The driver will end its operation the moment the sequencer stops sending transactions. This is done automatically by the UVM API, so the designer doesn’t need to to worry with this kind of details.

In order to write the driver, it’s easier to implement the code directly as a normal testbench and observe its behaviour through waveforms. As a result, in the next subchapter (“Driver”), the driver will first be implemented as a normal testbench and then we will reuse the code to implement the run phase.

For our normal testbench we will use regular Verilog code. We will need two things: generate the clock and idesginate an end for the simulation. A simulation of 30 clock cycles was defined for this testbench.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


//Generates clock
initial begin
 #20;
 forever #20 clk = ! clk;
end

//Stops testbench after 30 clock cyles
always@(posedge clk)
begin
 counter_finish = counter_finish + 1;

 if(counter_finish == 30) $finish;
end

The behaviour of the driver follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


//Driver
always@(posedge clk)
begin
 //State 0: Drives the signal en_o
 if(counter_drv==0)
 begin
 en_i = 1'b1;
 state_drv = 1;
 end

 if(counter_drv==1)
 begin
 en_i = 1'b0;
 end

 case(state_drv)
 //State 1: Transmits the two inputs ina and inb
 1: begin
 ina = tx_ina[1];
 inb = tx_inb[1];

 tx_ina = tx_ina << 1;
 tx_inb = tx_inb << 1;

 counter_drv = counter_drv + 1;
 if(counter_drv==2) state_drv = 2;
 end

 //State 2: Waits for the DUT to respond
 2: begin
 ina = 1'b0;
 inb = 1'b0;
 counter_drv = counter_drv + 1;

 //After the supposed response, the TB starts over
 if(counter_drv==6)
 begin
 counter_drv = 0;
 state_drv = 0;

 //Restores the values of ina and inb
 //to send again to the DUT
 tx_ina <= 2'b11;
 tx_inb = 2'b10;
 end
 end
 endcase
end

For this testbench, we are sending the values of tx_ina and tx_inb to the DUT, they are defined in the beginning of the testbench (you can see the complete code attached to this guide).

We are sending the same value multiple times to see how the driver behaves by sending consecutive transactions.

After the execution of the Makefile, a file named simpleadder.dump will be created by VCS. To see the waveforms of the simulation, we just need to open it with DVE.

The waveform for the driver is represented on Figure 5.1.

It’s possible to see that the driver is working as expected: it drives the signal en_i on and off as well the DUT inputs ina and inb and it waits for a response of the DUT before sending the transaction again. Chapter 5.2 - Implementing the UVM driver

After we have verified that our driver behaves as expected, we are ready to move the code into the run phase as seen in the following code (run_phase()).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


virtual task drive();
 simpleadder_transaction sa_tx;
 integer counter = 0, state = 0;
 vif.sig_ina = 0'b0;
 vif.sig_inb = 0'b0;
 vif.sig_en_i = 1'b0;

 forever begin
 if(counter==0) begin
 //Gets a transaction from the sequencer and
 //stores it in the variable 'sa_tx'
 seq_item_port.get_next_item(sa_tx);
 end

 @(posedge vif.sig_clock)
 begin
 if(counter==0) begin
 vif.sig_en_i = 1'b1;
 state = 1;
 end

 if(counter==1) begin
 vif.sig_en_i = 1'b0;
 end 

 case(state)
 1: begin
 vif.sig_ina = sa_tx.ina[1];
 vif.sig_inb = sa_tx.inb[1];

 sa_tx.ina = sa_tx.ina << 1;
 sa_tx.inb = sa_tx.inb << 1;

 counter = counter + 1;
 if(counter==2) state = 2;
 end

 2: begin
 vif.sig_ina = 1'b0;
 vif.sig_inb = 1'b0;
 counter = counter + 1;

 if(counter==6) begin
 counter = 0;
 state = 0;

 //Informs the sequencer that the
 //current operation with
 //the transaction was finished
 seq_item_port.item_done();
 end
 end
 endcase
 end
 end
endtask: drive

The ports of the DUT are acessed through the virtual interface with vif. as can be seen in lines 4 to 6.

Lines 12 and 50 use a special variable from UVM, the seq_item_port to communicate with the sequencer. The driver calls the method get_next_item() to get a new transaction and once the operation is finished with the current transaction, it calls the method item_done(). If the driver calls get_next_item() but the sequencer doesn’t have any transactions left to transmit, the current task returns.

This variable is actually a UVM port and it connects to the export from the sequencer named seq_item_export. The connection is made by an upper class, in our case, the agent. Ports and exports are going to be further explained in “Monitor”.

This concludes our driver, the full code for the driver can be found in the file simpleadder_driver.sv. In Figure 5.2, the state of the verification environment with the driver can be seen.

The source of the driver can be accessed here:

simpleadder_driver.sv

Monitor

The monitor is a self-contained model that observes the communication of the DUT with the testbench. At most, it should observe the outputs of the design and, in case of not respecting the protocol’s rules, the monitor must return an error.

The monitor is a passive component, it doesn’t drive any signals into the DUT, its purpose is to extract signal information and translate it into meaningful information to be evaluated by other components. A verification environment isn’t limited to just one monitor, it can have multiple of them.

The monitors should cover:

The outputs of the DUT for protocol adherence
The inputs of the DUT for functional coverage analysis

The approach we are going to follow for this verification plan is: sample both inputs, make a prediction of the expected result and compare it with the result of the DUT.

Consequently, we are going to create two different monitors:

The first monitor, monitor_before, will look solely for the output of the device and it will pass the result to the scoreboard.
The second monitor, monitor_after, will get both inputs and make a prediction of the expected result. The scoreboard will get this predicted result as well and make a comparison between the two values.

A portion of the code for both monitors can be seen in monitor_before and in monitor_after.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class simpleadder_monitor_before extends uvm_monitor;
 `uvm_component_utils(simpleadder_monitor_before)

 uvm_analysis_port#(simpleadder_transaction) mon_ap_before;

 virtual simpleadder_if vif;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);

 void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name (.scope("ifs"), .name("simpleadder_if"), .val(vif)));
 mon_ap_before = new(.name("mon_ap_before"), .parent(this));
 endfunction: build_phase

 task run_phase(uvm_phase phase);
 //Our code here
 endtask: run_phase
endclass: simpleadder_monitor_before

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


class simpleadder_monitor_after extends uvm_monitor;
 `uvm_component_utils(simpleadder_monitor_after)

 uvm_analysis_port#(simpleadder_transaction) mon_ap_after;

 virtual simpleadder_if vif;

 simpleadder_transaction sa_tx_cg;

 covergroup simpleadder_cg;
 ina_cp:     coverpoint sa_tx_cg.ina;
 inb_cp:     coverpoint sa_tx_cg.inb;
 cross ina_cp, inb_cp;
 endgroup: simpleadder_cg

 function new(string name, uvm_component parent);
 super.new(name, parent);
 simpleadder_cg = new;
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);

 void'(uvm_resource_db#(virtual simpleadder_if)::read_by_name(.scope("ifs"), .name("simpleadder_if"), .val(vif)));
 mon_ap_after= new(.name("mon_ap_after"), .parent(this));
 endfunction: build_phase

 task run_phase(uvm_phase phase);
 //Our code here
 endtask: run_phase
endclass: simpleadder_monitor_after

The skeleton of both monitors is very similar to the driver, except for Lines 4. They represent one of the existing UVM communication ports. These ports allow different objects to pass transactions between them. In the section 6.0.1 you can consult a brief explanation of UVM ports.

The monitors will collect transactions from the virtual interface and use the analysis ports to send those transactions to the scoreboard. The code for the run phase can be designed the same way as for the driver but it was omitted in this section.

The full code for both monitors can be found in the file simpleadder_monitor.sv.

The the state of our verification environment after the monitors can be consulted in Figure 6.1.

TLM ports

In “Sequencers and sequencers”, it was mentioned that transactions are the most basic data transfer in a verification environment but another question arises: how do transactions are moved between components? We have already talked about TLM before when we were designing the driver. The way the driver gets transactions from the sequencer, it’s the same way the scoreboard gets them from the monitors: through TLM.

TLM stands for Transaction Level Modeling and it’s a high-level approach to modeling communication between digital systems. This approach is represented by two main aspects: ports and exports.

A TLM port defines a set of methods and functions to be used for a particular connection, while an export supplies the implementation of those methods. Ports and exports use transaction objects as arguments.

We can see a representation of a TLM connection in Figure 6.2.

The communication is very easy to understand. The consumer implements a function that accepts a transaction as an argument and the producer calls that very function while passing the expected transaction as argument. The top block connects the producer to the consumer.

A sample code is provided in Table 6.1.

The class topclass connects the producer’s test_port to the consumer’s test_export using the connect() method. Then, the producer executes the consumer’s function testfunc() through test_port.

A particular characteristic of this kind of communication is that a port can only be connected to a single export. But there are cases when we might be interested in having a special port that can be plugged into several exports.

A third type of TLM port exists to cover these kind of cases: the analysis port.

An analysis port works exactly like a normal port but it can detect the number of exports that are connected to it and every time a required function is asked through this port, all other components whose exports are connected to an analysis port are going to be triggered.

In Figure 6.2 it’s represented an analysis port communication.

The communication models mentioned here are part of Transaction Level Modeling 1.0. There is another variant, TLM 2.0, that works with sockets instead of ports, but they aren’t going to be mentioned in this training guide.

A brief summary of these ports and exports can be seen in Table 6.2.

For more information about TLM, you can consult:

Accellera’s UVM 1.1 User’s Guide, page 11.

Agent

We have both monitors, the sequencer and the driver, so the next step is to connect them up. This is a job for the agent.

An agent doesn’t require a run phase, there is no simulation code to be executed in this block but there will be a connect phase, besides of the build phase.

We will construct the monitors, the sequencer and the driver in the build phase. We will also need to create two analysis ports, these ports will act as proxies for the monitors to be connect to an external scoreboard through the agent’s ports.

Note: We could have made the connection from the monitors directly to the scoreboard within the ‘Env’ class without passing by the agent’s ports. There are cases when this is the best option, or other cases when it’s not. It’s always up to the designer to decide the best option.

After we have constructed the components we need, we have to make the connections between them. Using the concepts learned in the “Monitor” chapter about TLM ports, we can connect each port to its destination.

A part of the code for the agent can be seen on the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


class simpleadder_agent extends uvm_agent;
 `uvm_component_utils(simpleadder_agent)

 //Analysis ports to connect the monitors to the scoreboard
 uvm_analysis_port#(simpleadder_transaction) agent_ap_before;
 uvm_analysis_port#(simpleadder_transaction) agent_ap_after;

 simpleadder_sequencer        sa_seqr;
 simpleadder_driver        sa_drvr;
 simpleadder_monitor_before    sa_mon_before;
 simpleadder_monitor_after    sa_mon_after;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);

 agent_ap_before    = new(.name("agent_ap_before"), .parent(this));
 agent_ap_after    = new(.name("agent_ap_after"), .parent(this));

 sa_seqr        = simpleadder_sequencer::type_id::create(...
 sa_drvr        = simpleadder_driver::type_id::create(...
 sa_mon_before    = simpleadder_monitor_before::type_id::create(...
 sa_mon_after    = simpleadder_monitor_after::type_id::create(...
 endfunction: build_phase

 function void connect_phase(uvm_phase phase);
 super.connect_phase(phase);
 sa_drvr.seq_item_port.connect(sa_seqr.seq_item_export);
 sa_mon_before.mon_ap_before.connect(agent_ap_before);
 sa_mon_after.mon_ap_after.connect(agent_ap_after);
 endfunction: connect_phase
endclass: simpleadder_agent

In Figure 7.1, it’s represented the current state of our testbench.

Accellera’s UVM 1.1 User’s Guide, page 43
Verification Academy’s UVM Cookbook, page 42

The source of the agent component can be found here:

simpleadder_agent.sv

Scoreboard

The scoreboard is a crucial element in a self-checking environment, it verifies the proper operation of a design at a functional level. This component is the most difficult one to write, it varies from project to project and from designer to designer.

In our case, we decided to make the prediction of the DUT functionality in the monitors and let the scoreboard compare the prediction with the DUT’s response. But there are designers who prefer to leave the prediction to the scoreboard. So the functionality of the scoreboard is very subjective.

In the agent, we created two monitors, as a result, we will have to create two analysis exports in the scoreboard that are going to be used to retrieve transactions from both monitors. After that, a method compare() is going to be executed in the run phase and compare both transactions. If they match, it means that the testbench and the DUT both agree in the functionality and it will return an “OK” message.

But we have a problem: we have two transaction streams coming from two monitors and we need to make sure they are synchronized. This could be done manually by writing appropriated write() functions but there is an easier and cleaner way of doing this: by using UVM FIFO.

These FIFO will work as it’s represented in Figure 8.1.

The FIFO are instantiated similarly to ports/exports, with uvm_tlm_analysis_fifo #(generic_transaction) generic_fifo and they already implement the respective write() functions that are called from the monitors. To access their data we just execute the get() method from each FIFO.

The code from the scoreboard follows in the following code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


class simpleadder_scoreboard extends uvm_scoreboard;
 `uvm_component_utils(simpleadder_scoreboard)

 uvm_analysis_export #(simpleadder_transaction) sb_export_before;
 uvm_analysis_export #(simpleadder_transaction) sb_export_after;

 uvm_tlm_analysis_fifo #(simpleadder_transaction) before_fifo;
 uvm_tlm_analysis_fifo #(simpleadder_transaction) after_fifo;

 simpleadder_transaction transaction_before;
 simpleadder_transaction transaction_after;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 transaction_before    = new("transaction_before");
 transaction_after    = new("transaction_after");
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);
 sb_export_before    = new("sb_export_before", this);
 sb_export_after        = new("sb_export_after", this);

 before_fifo        = new("before_fifo", this);
 after_fifo        = new("after_fifo", this);
 endfunction: build_phase

 function void connect_phase(uvm_phase phase);
 sb_export_before.connect(before_fifo.analysis_export);
 sb_export_after.connect(after_fifo.analysis_export);
 endfunction: connect_phase

 task run();
 forever begin
 before_fifo.get(transaction_before);
 after_fifo.get(transaction_after);
 compare();
 end
 endtask: run

 virtual function void compare();
 if(transaction_before.out == transaction_after.out) begin
 `uvm_info("compare", {"Test: OK!"}, UVM_LOW);
 end else begin
 `uvm_info("compare", {"Test: Fail!"}, UVM_LOW);
 end
 endfunction: compare
endclass: simpleadder_scoreboard

In Figure 8.2, it’s represented the current state of our testbench.

For more information about scoreboards you can consult:

Accellera’s UVM 1.1 User’s Guide, page 72
Verification Academy’s UVM Cookbook, pages 155 and 163
Comprehensive Functional Verification: The Complete Industry Cycle, page 82

The code for the scoreboard can be consulted here:

simpleadder_scoreboard.sv

Env

We are getting close to have a working testbench, there are two classes missing: the env and the test.

The env is a very simple class that instantiates the agent and the scoreboard and connects them together.

The source is represented as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class simpleadder_env extends uvm_env;
 `uvm_component_utils(simpleadder_env)

 simpleadder_agent sa_agent;
 simpleadder_scoreboard sa_sb;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);
 sa_agent    = simpleadder_agent::type_id::create(...
 sa_sb        = simpleadder_scoreboard::type_id::create(...
 endfunction: build_phase

 function void connect_phase(uvm_phase phase);
 super.connect_phase(phase);
 sa_agent.agent_ap_before.connect(sa_sb.sb_export_before);
 sa_agent.agent_ap_after.connect(sa_sb.sb_export_after);
 endfunction: connect_phase
endclass: simpleadder_env

In Figure 9.1, it’s represented the current state of our testbench. There is only one component left now: the test class.

The code for the env can be found here:

simpleadder_env.sv

Test

At last, we need to create one more block: the test. This block will derive from the uvm_test class and it will have two purposes:

Create the env block
Connect the sequencer to the sequence

You might be wondering why are we connecting the sequencer and the sequence in this block, instead of the agent block or the sequence block.

The reason is very simple: by specifying in the test class which sequence will be going to be generated in the sequencer, we can easily change the kind of data is transmitted to the DUT without messing with the agent’s or sequence’s code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


class simpleadder_test extends uvm_test;
 `uvm_component_utils(simpleadder_test)

 simpleadder_env sa_env;

 function new(string name, uvm_component parent);
 super.new(name, parent);
 endfunction: new

 function void build_phase(uvm_phase phase);
 super.build_phase(phase);
 sa_env = simpleadder_env::type_id::create(...
 endfunction: build_phase

 task run_phase(uvm_phase phase);
 simpleadder_sequence sa_seq;

 phase.raise_objection(.obj(this));
 sa_seq = simpleadder_sequence::type_id::create(...
 assert(sa_seq.randomize());
 sa_seq.start(sa_env.sa_agent.sa_seqr);
 phase.drop_objection(.obj(this));
 endtask: run_phase
endclass: simpleadder_test

Line 21 starts a sequencer in the desired sequence for this test.

In Figure 10.1, it’s represented the current state of our testbench.

Our testbench is finally ready, now it’s time to execute it and check the results.

The source of the test component can be found here:

simpleadder_test.sv

Running the simulation

To run the simulation, we simply execute the provided Makefile in the GitHub repository:

1

$ make -f Makefile.vcs

The testbench will generate random inputs and then those inputs will be sent to the DUT. The monitors will capture the data in the communication bus and make a prediction of the expected result. Finally the scoreboard will evaluate the functionality by matching the DUT’s response with the prediction made by one of the monitors. If the DUT and the prediction match, an “OK” message will be outputted, otherwise, we will se a “Fail” message.

So, in the output of the simulation, we must find for the messages starting with UVM_INFO because the compare() method from the scoreboard is going to print a message using the macro `uvm_info() with the result of the test.

The result of the simulation can be seen below:

***********       IMPORTANT RELEASE NOTES         ************

You are using a version of the UVM library that has been compiled with `UVM_NO_DEPRECATED undefined. See http://www.eda.org/svdb/view.php?id=3313 for more details.

(Specify +UVM_NO_RELNOTES to turn off this notice)

UVM_INFO @ 0: reporter
\[RNTST\]
Running test simpleadder_test… UVM_INFO simpleadder_scoreboard.sv(49) @ 70: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 130: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 190: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 250: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 310: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 370: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 430: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 490: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 550: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 610: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 670: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 730: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 790: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO simpleadder_scoreboard.sv(49) @ 850: uvm_test_top.sa_env.sa_sb
\[compare\]
Test: OK! UVM_INFO ../uvm-src/uvm-1.1d/src/base/uvm_objection.svh(1268) @ 900: reporter
\[TEST\_DONE\]
‘run’ phase is ready to proceed to the ’extract’ phase

-– UVM Report Summary —

** Report counts by severity UVM_INFO :   16 UVM_WARNING :    0 UVM_ERROR :    0 UVM_FATAL :    0 ** Report counts by id
\[RNTST\]
     1
\[TEST\_DONE\]
     1
\[compare\]
    14 $finish called from file “../uvm-src/uvm-1.1d/src/base/uvm_root.svh”, line 430. $finish at simulation time                  900 V C S   S i m u l a t i o n   R e p o r t Time: 900 ns CPU Time:      2.040 seconds;       Data structure size:   0.2Mb

This chapter concludes this beginner’s guide. You can access all the code in this repository.

Master's Thesis

Sun, 23 Feb 2014 00:00:00 +0000

Master’s Thesis

This thesis’ project was proposed by Synopsys Portugal and it’s going to be carried out under the Integrated Master’s Degree in Electrical and Computer Engineering of the Faculdade de Engenharia da Universidade do Porto.

Subject: Development of a reconfigurable multi-protocol verification environment using UVM methodology

Team:

Teacher Supervisor: José Carlos Alves (jca \[at\]fe.up.pt)
Company Supervisors: Luis Cruz (lcruz \[at\]synopsys.com) & Domingos Terra (dterra \[at\]synopsys.com)

During the last decades, electronic circuits have grown in complexity and in production costs which compelled engineers to research and develop new methods to verify the electronic design in more comprehensive, detailed and efficient ways.

The UVM methodology is one of the results of the increasing need of digital verification. It’s is designed in a way that allows to structure the verification environment in a reconfigurable architecture, so it can be possible to reuse the same environment across multiple technologies. This methodology is an industry standard recognized by Accellera System Initiative and it’s comprised of a library for the SystemVerilog language (IEEE 1800) and a set of verification guidelines.

The purpose of this work is to take advantage of the best features of UVM and develop a reconfigurable verification environment that supports multiple protocols with minimal development effort. The project will start with the analysis of an existing environment used in a specific technology and then followed by an analysis of the verification techniques that could be used across different protocols.

The goals defined for this project are:

Analysis of an existing verification environment and removal of all design logic specific to the original protocol
Revision of the verification environment in order to support multiple protocols
Creation of generic blocks to support the revised environment
Configuration and application of the generic environment to another existent protocol

Work plan

The objective of this project is to develop a reconfigurable verification environment that supports multiple protocols using the UVM methodology.

The first step will be to study and analyze the existing verification environment in order to see how it’s structured and to identify what components will have to be replaced. Then, with basis on that study, it will be proposed and discussed possible modifications to be applied to the studied system. After the discussion, the chosen approach will be implemented in the environment. Finally, to prove it’s working, the envinroment will verify a platform yet to be defined.

The distribution of the work throughout the semester is described on the following table:

Task	Description	Start	Finish
Task 1	Study of the existing UVM environment	3 Feb	21 Feb
Task 2	Proposal of possible implementations	24 Feb	28 Feb
Task 3	Implementation	3 Mar	2 May
Task 4	Aplication of the researched solution to an existing platform	5 May	16 May
Task 5	Writing of the dissertation	19 May	6 June

The following figure represents the Gantt chart of the work plan:

The project will be realized in the offices of Synopsys Porto using the company’s resources. It’s foreseen the usage of the tools:

VCS: Verilog Compiled code Simulator - Synopsys’ HDL compiler and simulator. Verilog and SystemVerilog code will be compiled with this tool.
DVE: Discovery Visualization Environment - It’s an advanced debugger and waveform visualization environment from Synopsys. This tool will be used to debug the developed environments.
UVM Reference Implementation. The UVM API that is freely available at Accellera’s website: http://www.accellera.org/downloads/standards/uvm

The following references are going to be consulted for this project:

Accellera’s UVM User’s Guide 1.1
Accellera’s UVM 1.1 Class Reference
Verification Academy’s UVM Cookbook
Book “SystemVerilog for Verification: A Guide to Learning the TestBench Language Features”, by Chris Spear
Book “Comprehensive Functional Verification: The Complete Industry Cycle”, by John Goss

Preliminary report

This is the preliminary report that details how the work was planned for the semester and that contains some initial research about hardware verification languages and the evolution of verification methodologies.

Preliminary report

Progress Report 1 - 16th of February

This is the first progress report of my master’s thesis. It’s the first of many more that I’ll keep posting as I’ll progress through the work.

You can find the link to the document here:

Progress Report 1 - 16th of February

Progress Report 2 - 7th of March

You can find here the second progress report:

Progress Report 2 - 7th of March

Progress Report 3 - 16th of March

Third progress report:

Progress Report 3 - 16th of March

Progress Report 4 - 2nd of April

Fourth progress report:

Progress Report 4 - 2nd of April

Progress Report 5 – 30th of April

Fifth progress report:

Progress Report 5 – 30th of April

Progress Report 6 – 6th of June

Sixth progress report:

Progress Report 6 – 6th of June

Final Document

The final document of the Master’s Thesis can be found here.

About me

Mon, 01 Jan 0001 00:00:00 +0000

My name is Pedro Araújo and I am a GPU Hardware Verification Engineer working at Arm, in Sweden.

I have a Master’s Degree in Electrical and Computer Engineering from FEUP and I also studied at Chalmers Tekniska Högskola in Sweden.

Some useful links:

Contact:

pedroaraujo [at] colorlesscube.com

Search

Mon, 01 Jan 0001 00:00:00 +0000

Pages on Pedro Araújo

Archives

UVM Guide for Beginners

UVM Guide for Beginners

The DUT

Defining the verification environment

Top Block

Sequences and sequencers

Driver

Monitor

Agent

Scoreboard

Env

Test

Running the simulation

Master's Thesis

Master’s Thesis

Work plan

Preliminary report

Progress Report 1 - 16th of February

Progress Report 2 - 7th of March

Progress Report 3 - 16th of March

Progress Report 4 - 2nd of April

Progress Report 5 – 30th of April

Progress Report 6 – 6th of June

Final Document

About me

Search