UVM Interview Questions - 6

Q36: What is the Difference between UVM_ALL_ON and UVM_DEFAULT?

UVM_ALL_ON and UVM_DEFAULT are identical. As per the UVM reference manual:

UVM_ALL_ON: Set all operations on (default).
UVM_DEFAULT: Use the default flag settings.

It is recommended to use UVM_DEFAULT instead of UVM_ALL_ON even though they both essentially do the same thing today. At some point in time, the class library may add another "bit-flag" which may not necessarily be the DEFAULT.

If you use UVM_ALL_ON, that would imply that whatever flag it is would be "ON".

Q37: What drain time in UVM?

The drain time means the access time that you use before ending the simulation. Suppose if we are done with input traffic to the DUT didn't mean that nothing else would happen from that point as the DUT may have required some additional time to complete any transactions that were still being processed. Setting a drain time adds an extra delay from the time that all objections were dropped to the stop of the simulation, making sure that there were no outstanding transactions inside DUT at that point.

You can set the drain time in the base test at the end_of_elobration phase as shown below:

class test_base extends uvm_test;
  // ...
  
  function void end_of_elaboration_phase(uvm_phase phase);
    uvm_phase main_phase = phase.find_by_name("main", 0);
    main_phase.phase_done.set_drain_time(this, 10);
  endfunction
  
  // ...
endclass

Q38: What is Virtual interface and how Virtual interface is used?

"Virtual interfaces are class data member handles that point to an interface instance. This allows a dynamic class object to communicate with a Design Under Test (DUT) module instance without using hierarchical references to directly access the DUT module ports or internal signals."

Below shown sample code is the easier way to use the virtual interface handles in the UVM environment. 

module top;
  …
  dut_if dif;
  …
  initial begin

    uvm_config_db#(virtual dut_if)::set(null, "*", "vif", dif);

    run_test();

  end
endmodule

class tb_driver extends uvm_driver #(trans1);
  …
  virtual dut_if vif;
  …
  function void build_phase(uvm_phase phase);
    super.build_phase(phase);

    // Get the virtual interface handle that was stored in the
    // uvm_config_db and assign it to the local vif field.
    if (!uvm_config_db#(virtual dut_if)::get(this, "", "vif", vif))
      `uvm_fatal("NOVIF", {"virtual interface must be set for: ",

     get_full_name(), ".vif"});
   endfunction
  …
endclass 

As shown first the actual interface or physical interface handle, dif, is stored into the uvm_config_db at string location "vif" using the set() command just before the run_test() call in the top level module.

Then it shows the use of the get() function of the uvm_config_db to retrieve the virtual interface handle from the same "vif" location and assign it to the local vif virtual interface handle in the driver class (the same code will be used inside of the monitor class as well).

Q39: How to add a user-defined phase in UVM?

If needed a user can create user-defined phases in the UVM environment. However, this may impact the re-usability of the component. To define a custom phase user need to extend the appropriate base class for phase-type. Following are the available base classes.

    class my_phase extends uvm_task_phase;
    class my_phase extends uvm_topdown_phase;
    class my_phase extends uvm_bottomup_phase;

You can refer to the UVM PHASE IMPLEMENTATION EXAMPLE for complete user-defined phase understanding.

Q40: How interface is passed to components in UVM?

The passing of interface is done using the virtual interface to the component is done using set() and get() methods. consider the below example:

Consider we have defined 2 interfaces as

apb_if intf0(.pclk(clk));

apb_if intf1(.pckl(clk));

Setting the interface:

initial begin

   //put in the database the interface used by APB agent agent0

   uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.env.agent0*", "VIRTUAL_INTERFACE", intf0);

   //put in the database the interface used by APB agent agent1

   uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.env.agent1*", "VIRTUAL_INTERFACE", intf1);

end

Getting the interface:

class cfs_apb_agent extends uvm_component;

   

   //pointer to the interface

   virtual cfs_apb_if vif;

   

   virtual function void build_phase(uvm_phase phase);

      super.build_phase(phase);

     

      if(uvm_config_db::#(virtual apb_if)::get(this, "", "VIRTUAL_INTERFACE", vif) == 0) begin

         `uvm_fatal("ISSUE", "Could not get from the database the virtual interface for the APB agent")

      end

   endfunction

endclass

<< PREVIOUS    NEXT >>

Build smart tests using uvm_report_catcher

Today we will look into a very useful concept of UVM specially when we are doing any erroneous testing. Its all about modifying the severity, id, action, verbosity or the report string itself before the report is finally issued by the report server. 

Normally in our test environment shout for error when any erroneous scenario like CRC error condition or generation of any error interrupt occurs. And we also write erroneous tests to test these scenarios where we end-up with error messages and tests fails. 

The uvm_report_catcher is used to catch messages issued by the uvm report server. Upon catching a report, the catch method can modify the severity, id, action, verbosity or the report string itself before the report is finally issued by the report server.  The report can be immediately issued from within the catcher class by calling the issue method.

The catcher maintains a count of all reports with FATAL, ERROR or WARNING severity and a count of all reports with FATAL, ERROR or WARNING severity whose severity was lowered.  These statistics are reported in the summary of the uvm_report_server.

Example: 

Report catcher class:

class error_report_catcher extends uvm_report_catcher;

  //new constructor

  virtual function action_e catch();

    if(get_severity() == UVM_ERROR && get_id() == "MON_CHK_NOT_VALID") begin

      set_severity(UVM_INFO);

      return CAUGHT;

    end

    else begin

      return THROW;

    end

  endfunction

endclass : error_report_catcher_c

Use of error catcher in testcase: 

class erroneous_test extends base_test_class;

  // report catcher to suppress errors

  error_report_catcher error_catcher ;

  /// \fn new_constructor

   

  /// \fn build_phase

virtual function void build_phase(uvm_phase phase);

    super.build_phase(phase);

      error_catcher = new();

      uvm_report_cb::add(null,error_catcher) ;

      uvm_config_db#(int)::set(this,“uvc.tx_agent","is_active",UVM_ACTIVE);

         

      // User configurations

      env_cfg.print();

      uvm_config_db#(env_config_c)::set(this, "*" , “env_cfg", env_cfg);

      // Calling the error sequence

      uvm_config_db#(uvm_object_wrapper)::set(this, “uvc.tx_agent.tx_sequencer.main_phase","default_sequence",valid_invalid_seq_c::type_id::get());

  endfunction : build_phase

endclass : erroneous_test

UVM - 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:

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

In Code 5.1 you can find the base code pattern which is going to be used in our driver.

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

Code 5.1 – Driver component – simpleadder_driver.sv

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 2.

• 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, 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:

1. 
   
   Get a sequence item
   
   
2. 
   
   Control the en_i signal
   
   
3. 
   
   Drive the sequence item to the bus
   
   
4. 
   
   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 (chapter 5.1), the driver will first be implemented as a normal testbench and then we will reuse the code to implement the run phase (chapter 5.2).

Chapter 5.1 – Creating the driver as a normal testbench

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.

The code is represented in Code 5.2.

//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

Code 5.2 – Clock generation for the normal testbench

The behaviour of the driver follows in Code 5.3.

//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

Code 5.3 – Part of the driver

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 Code 5.4.

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

Code 5.4 - Task for the run_phase()

The ports of the DUT are acessed through the virtual interface with vif.<signal> 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 chapter 6.0.1.

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

Figure 5.2 – State of the verification environment with the driver

UVM - 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.

Figure 4.1 - Relation between a sequence, a sequencer and a driver

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 fromuvm_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 Code 4.1.

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
Code 4.1 – Transaction for the simpleadder

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 Code 5.2.

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
Code 5.2 – Extension of the previous transaction

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 Code 5.3

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
Code 5.3 - Code for the sequencer

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 Code 5.4.

typedef uvm_sequencer#(simpleadder_transaction) simpleadder_sequencer;
Code 5.4 – Extension of the previous transaction

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:

 

Figure 4.2 – State of the verification environment after the sequencer

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 10, and the connection between the sequencer and the driver will be explained on chapter 7.

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