Sunday, 2 April 2017

Events in SV and UVM

In this blog, we will see the details of UVM functions use for uvm_event and it can be used in place of SV (system verilog) event.

In system verilog, event data type is used for synchronization of different processes and similar concept is there in UVM which have “uvm_event” class. Here, we will see the similarities between them.

Below is the example code for usage of sv event (Figure 1) and uvm event (Figure 2). Output is shown just below the figure.

In the example, two events (e1_* and e2_*) are used. Both events are triggered followed by waiting on the same event. But due to, "@" operator and "wait_trigger()" method, it doesn't get the event triggered and it waits for the event e1_* to be triggered. In case of, e2_* event, "wait(event.triggered)" and "wait_ptrigger()" method is used which allows process to be unblocked as event is triggered in the same simulation time. From output, the same behavior can be observed.



OUTPUT:

#  e2_sv is triggered at                   20

#  e2_uvm is triggered at                20

#  e2_sv is triggered at                   40
#  e2_uvm is triggered at                40
#  e2_sv is triggered at                   60
#  e2_uvm is triggered at                60


SV & UVM events comparison:


Event Triggering:

In SV, events can be triggered via the “-> event” operator which unblock all processes currently waiting on that event.
In UVM, "event.trigger()" method is used to trigger the event to unblock the processes.

Waiting for event:
In SV, "@(event)" operator is used to wait for an event to be triggered.
In UVM, "event.wait_trigger()" method is used to wait for an event to be triggered.

Persistent trigger:
In SV, "wait (event.triggered)" will unblock the waiting process whether the wait executes before or at the same  simulation time as the trigger operation.
In UVM, "event.wait_ptrigger()" method will unblock the waiting process at same simulation time as the trigger operation.


Thursday, 2 March 2017

How to find UVM port connections between components in the testbench?

UVM provides ports for communicating between components. So that, we can easily transfer packets from one component to another component in blocking/non-blocking mode. These ports can be connected to any components in the testbench based on the requirements. In env, we connect these ports with respective port/export/implementation port to get packets. Occasionally, we come across a situation when a driver put the packet in the port but the packet is not received in the respective component.

Here, first question comes to our mind is, whether the ports are connected properly or not. For that, UVM has provided “debug_connected_to” and “debug_provided_to” methods which gives a print of procedural connected components  through TLM which make debugging task easier. So, if the components are not connected properly then we can update the port connection to resolve the problem.

debug_connected_to” method gives display of the implementation/export to which this port is connected i.e. port is driving packets to which port/export/imp. “debug_provided_to” methods gives display of the port/export to which this imp/export is connected i.e. imp/export is getting data from which port/export.

Below is an example of port-export connection which is similar to the example given in UVM 1.2 Class Reference (Topic 14. TLM1 Interfaces, Ports, Exports and Transport Interfaces).

Figure 1 

Here, comp1, subcomp1 and leaf1 components are connected via port and leaf1 component put the packets on the port. Components comp2, subcomp2 and leaf2 components are connected through export and in leaf2 component contains implementation put method. Components comp1 and comp2 are connected through port-export connection.

  • Output of “out.debug_connected_to()” of “comp1”:
It describes the export-imp connection chain of all components with full hierarchy details and port type i.e. where the put method is implemented.

# UVM_INFO @ 0: env.comp1.out [debug_connected_to] This port's fanout network:
#   env.comp1.out (uvm_blocking_put_port)
#     |
#     |_env.comp2.in (uvm_blocking_put_export)
#         |
#         |_env.comp2.subcomp2.in (uvm_blocking_put_export)
#             |
#             |_env.comp2.subcomp2.leaf2.in (uvm_blocking_put_imp)
#   Resolved implementation list:

#   0: env.comp2.subcomp2.leaf2.in (uvm_blocking_put_imp)

As shown above, comp1’s put port (out) is connected with comp2’s put export (in) which is connected with subcomp2’s put export (in) and its implementation method is n leaf2 component which has put imp (in). 
  • Output of "out.debug_provided_to()" of "comp1":
It describes the port connection chain of all components with full hierarchy details and port type i.e. from where the component put the packet on the port.

# UVM_INFO @ 0: env.comp1.out [debug_provided_to] This port's fanin network:
#   env.comp1.out (uvm_blocking_put_port)
#     |
#     |_env.comp1.subcomp1.out (uvm_blocking_put_port)
#         |
#         |_env.comp1.subcomp1.leaf1.out (uvm_blocking_put_port)

As shown above, comp1’s out port is connected with subcomp1’s out port which is connected with leaf1’s out port. Here, leaf1 component drives packets on the port. So, up to “leaf1.out” port hierarchy is printed in the output.


Similarly, we can get information for any port/export. Below is the output for “in” export of comp2 component.
  • Output of “in.debug_connected_to()” of “comp2”:
             # UVM_INFO @ 0: env.comp2.in [debug_connected_to] This port's fanout network:
             #   env.comp2.in (uvm_blocking_put_export)
             #     |
             #     |_env.comp2.subcomp2.in (uvm_blocking_put_export)
             #         |
             #         |_env.comp2.subcomp2.leaf2.in (uvm_blocking_put_imp)
             #
             #   Resolved implementation list:
             #   0: env.comp2.subcomp2.leaf2.in (uvm_blocking_put_imp)
  • Output of “in.debug_provided_to()” of “comp2”:
             # UVM_INFO @ 0: env.comp2.in [debug_provided_to] This port's fanin network:
             #   env.comp2.in (uvm_blocking_put_export)
             #     |
             #     |_env.comp1.out (uvm_blocking_put_port)
             #         |
             #         |_env.comp1.subcomp1.out (uvm_blocking_put_port)
             #             |
             #             |_env.comp1.subcomp1.leaf1.out (uvm_blocking_put_port)

Thursday, 2 February 2017

How to disable triggering of an UVM event

As VIP developers, we have to develop our VIP flexible, so that user can achieve his requirement easily without our dependency. For that, user should have support of configurations, callbacks, factory override etc. in the VIP. In this blog, we will see a feature of UVM which helps user to control the data flow or processes.

In my previous blog "Synchronization using UVM features" (Feb'16), we saw that, how to use UVM events and barrier for synchronization of processes. In this blog, we will see how to disable the triggering of any UVM event which gives control to user by avoiding further processing of data/packet.

As a testbench component developer, we may use the UVM events for synchronization of processes for example once packet is driven properly from driver and relative response is received then triggers an event which do further processing and put that packet on to the analysis port for scoreboarding or coverage sampling. This driver component may be used by number of people and as a VIP developer we don’t know their requirements.

Consider a case where a user don’t want to receive any erroneous packet in scoreboard or coverage. Here, we can provide support for user to disable the triggering of event in his testbench. So that, packet will not be broadcasted on analysis port. This can be achieve using configuration also. But it requires extra variables in the testbench.

To disable triggering of UVM event, UVM event callback class is required. User has to register an UVM event callback class with the specific event. In that callback class, user can override the “pre_trigger” method to disable the triggering of the event. If this method returns "1" then event will not be triggered otherwise it will be triggered. This method is called before triggering of any event.
This method has two arguments:
(1) uvm_event: The event which is calling this callback method
(2) uvm_object: UVM Object class can be passed with the triggering of the event

Below is the example to disable the triggering of UVM event which demonstrate the usage.

module top();
  ...
  uvm_barrier b;

  class my_object extends uvm_object;
    int cntr;
    ...
   endclass

  class my_event_callback extends uvm_event_callback;
  
    ... 
    virtual function bit pre_trigger (uvm_event e, uvm_object data);
      my_object obj;
      $cast(obj, data);
      if(obj.cntr >= 3) return 1;
      else return 0;
    endfunction
  endclass

  // Task - 1
  task task_a(input uvm_barrier _b);
    int delay;

    repeat(5) begin
      delay = $urandom_range(10, 100);
      #delay;
      _b.wait_for();
    end
  endtask : task_a

  // Task - 2
  task task_b(input uvm_barrier _b);
    int delay;

    repeat(5) begin
      delay = $urandom_range(50, 100);
      #delay;
      _b.wait_for();
    end
  endtask : task_b

  task get_event(output uvm_event e_max_process);
    uvm_event_pool e_pool;
    
    if(e_pool == null)
      e_pool = new("e_pool");

    e_pool = e_pool.get_global_pool();
    e_max_process = e_pool.get("e_max_process");
  endtask
  
  initial begin
    // Creates a barrier object named "Barrier" and it's threshold value will
    // be 3.
    b = new("Barrier",3); // Wait for 3 process to be completed
    fork
      task_a(._b(b));
      task_b(._b(b));
      trigger_event(b);
      process_on_event();
    join
  end

  task trigger_event(uvm_barrier b);
      uvm_event e_max_process;
      my_event_callback cb;
      my_object obj;
      int cntr;

      obj = new();
      cb = new();
      get_event(e_max_process);
      e_max_process.add_callback(cb);
      forever begin
        b.wait_for(); 
        #0;
        ++cntr;
        obj.cntr = cntr;
        $display($time," e_max_process[%0d] event being triggered",b.get_threshold());
        e_max_process.trigger(obj);
        #10;
        $display($time," e_max_process event[%0d] reset being done",b.get_threshold());
        e_max_process.reset();
     end
 endtask

  task process_on_event();
    uvm_event e_max_process;

    get_event(e_max_process);
    forever begin
      e_max_process.wait_trigger();
      $display($time," e_max_process event triggered");
      e_max_process.wait_off(); 
    end 
  endtask
endmodule

As shown above, there is an event "e_max_process" which is triggered (in trigger_event task) once synchronization done between "task_a" and "task_b" through "uvm_barrier" followed by resetting the same event. In "process_on_event" task, first it waits for the triggering of same event and followed by waiting on resetting it.

With "e_max_process" event, "my_event_callback" class is registered and with triggering  of the event object of "my_object" class is passed as an argument. So before triggering this event, "pre_trigger" method of callback class is called and it has data of "my_object" passed with the event. 

In the "pre_trigger" method, when the "cntr" field of "my_object" is greater than or equals to 3 then it returns 1 otherwise it returns 0. That means, when cntr value is greater than or equals to 3, the event will not be triggered. This "cntr" field is incremented to one before triggering of the event.

Below is the simulation result of the example which shows "e_max_process" event is triggered on 85ns and 185ns i.e. 2 times it triggered. Then it is not triggered as "pre_trigger" function returns 1.

##################### 
Output:
#####################
    85 e_max_process[3] event being triggered
    85 e_max_process event triggered
    95 e_max_process event[3] reset being done
   185 e_max_process[3] event being triggered
   185 e_max_process event triggered
   195 e_max_process event[3] reset being done
   268 e_max_process[3] event being triggered
   278 e_max_process event[3] reset being done
   368 e_max_process[3] event being triggered
   378 e_max_process event[3] reset being done
   447 e_max_process[3] event being triggered
   457 e_max_process event[3] reset being done




Monday, 2 January 2017

How to use Parameters in SystemVerilog

In this blog, we will see how to set and overwrite the parameters in the testbench. As we know, whenever changes required in define, we have to compile the code before simulate it. But in case of parameters, we can directly pass its value through simulation time argument and we don't need to compile the code again.


Consider case of AMBA protocols where you may need to have different address/data width and also need to generate data based on the width of the signal. So here, we can use parameter to generate different values.


For overwriting the parameter field, user has to pass “+floatparameters” during optimization [with vopt command]. If the design is not optimized then similar command could be passed with simulation time [with vsim command]. The parameter field should be passed during simulation time with “-g” prefix.

Below is a demo example which has a parameter “DATA_WIDTH” which defines the width of signals. 

Below is the example for usage of parameter with Questa-Sim.

module adder(in1, in2, en, clk, out);
  parameter DATA_WIDTH=4;
  output [DATA_WIDTH : 0] out;
  input [(DATA_WIDTH-1):0] in1;
  input [(DATA_WIDTH-1):0] in2;
  input en;
  input clk;

  reg [DATA_WIDTH:0] r_out;

  assign out = r_out;

  always @(posedge clk)
  begin
    if (en) begin
      r_out <= in1 + in2;
    end
  end
endmodule

module testbench();
  parameter DATA_WIDTH=2;
  wire  [DATA_WIDTH : 0]  out;
  wire [(DATA_WIDTH-1):0] in1;
  wire [(DATA_WIDTH-1):0] in2;
  wire en;
  wire clk;

  reg [(DATA_WIDTH-1):0] r_in1;
  reg [(DATA_WIDTH-1):0] r_in2;
  reg r_en;
  reg r_clk;

  assign clk = r_clk;
  assign en  = r_en;
  assign in1 = r_in1;
  assign in2 = r_in2;

  initial begin
    r_clk <= 0;
    $monitor(in1, in2, out);
    forever begin
      #5 r_clk = ~r_clk;
    end
  end

  initial begin
    r_en <= 0;
    r_in1 <= 0;
    r_in2 <= 0;

    #5 r_en = 1;
    #10 r_in1 = $urandom_range(128,0);
          r_in2 = $urandom_range(128,0);
    #10 r_in1 = $urandom_range(128,0);
           r_in2 = $urandom_range(128,0);
    $finish;
  end
  
  adder#(DATA_WIDTH) add(in1, in2, en, clk, out);

endmodule


Compile command: vlog file.sv


The following command should be used to simulate above example:
vsim -novopt -do "log -r *;run -a" testbench -voptargs="+floatparameters" -gDATA_WIDTH=6 –c


So, it will take "DATA_WIDTH" value "6" in the entire testbench. User can pass different values of "DATA_WIDTH" with "-g" option. If this parameter is not passed during simulation time, then "DATA_WIDTH" value will be "2" which is set as default in the testbench.



Note that, by this method, the parameters defined in the packages will not be overridden. So that, the testbench component can not use this overriden value.




Monday, 7 November 2016

UVM Random Stimulus Generator

In verification using UVM, most of the people create sequences from sequence item and start the same sequence from the testcase. In this blog, we will see a different method to drive transactions without creating any sequence. UVM provides “uvm_random_stimulus” class which generates random transactions and put it on to “blocking_put_port”. So by using this port, we can get the random transaction and drive them on to the interface. “uvm_random_stimulus” class contains “generate_stimulus” method whose arguments are the transaction class and number of transaction to be generated. User can override this method to have his own implementation. It also contains “stop_stimulus_generation” function which stops generation of stimulus.

As we know, the integration of any VIP in the testbench is not completed until a sequence is driven from the driver and monitor samples interface properly. When we integrate any VIP, it may consume time in creating sequences and testcase which could be done later. Here if any error is generated, then user has to find whether there is any problem with component integration or it is related to the sequence or testcase. As this random stimulus generator method doesn’t include any sequences, one can easily stabilize the integration of VIP in the testbench. Error can be generated only because of integration problem (Note that, simulation time error will be printed for erroneous transactions. So constraints should be proper.). So, this method of transaction generation is very useful for the AE(application engineer) and also for a new user of the VIP.

There can be various ways of integrating this random stimulus generator:
One way is, you can create an extra port (put implementation) in the driver and connect it with the stimulus generator put port (“blocking_put_port”). In run phase, get the transaction either from put implementation or seq_item_port based on configuration. In that case, driver contains two ports for getting transactions and it may break the existing functionality.

Another way is, you can override the “get_next_item” method in the sequencer. So without updating the driver code, you can easily integrate the stimulus generator in the testbench. You just need to configure the agent whether to get transaction from sequences or from stimulus generator. Below is the demo example which demonstrates usage of “uvm_random_stimulus” component:
Random Stimulus Generator


// Enum to select transaction generation from sequence or random stimulus generator.
typedef enum 
{
    RANDOM_GENERATOR,
    SEQUENCE_GENERATOR
} txn_generator;

//********************
// Transaction class 
class a_item extends uvm_sequence_item;
    ...  
endclass : a_item

//********************
// Driver class
class a_driver extends uvm_driver#(a_item);
    ... 
    task run_phase(uvm_phase phase);
        super.run_phase(phase);
        forever begin
          seq_item_port.get_next_item(req);
          ...
          seq_item_port.item_done();
        end
    endtask : run_phase
endclass : a_driver

//********************
// Sequencer class
`uvm_blocking_put_imp_decl(_rand)
class a_seqr extends uvm_sequencer#(a_item);
    txn_generator gen=SEQUENCE_GENERATOR;
    uvm_blocking_put_imp_my #(a_item, a_seqr) put_imp;
    ...
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        void'(uvm_config_db#(txn_generator)::get(this,"","gen",gen));
        // Creating implementation port when RANDOM_GENERATOR is selected
        if(gen == RANDOM_GENERATOR)
            put_imp = new("put_imp", this);
    endfunction : build_phase

    // Put implementation
    virtual task put_rand(a_item seq);
        if(seq == null) $display("ERROR: TXN NULL");
        else m_req_fifo.put(seq);
    endtask

    task get_next_item(output a_item t);
        a_item req_item;
  
        if (get_next_item_called == 1)
            uvm_report_error(get_full_name(),
            "Get_next_item called twice without item_done or get in between", UVM_NONE);

        // Calling m_select_sequence method only when transaction from sequences
        // are required. This is the only modification. 
        // Other code remains same as base implementation.
        if ((!sequence_item_requested) && (gen == SEQUENCE_GENERATOR))
            m_select_sequence();

        // Set flag indicating that the item has been requested to ensure that item_done 
        // or get is called between requests
        sequence_item_requested = 1;
        get_next_item_called = 1;
        m_req_fifo.peek(t);
    endtask
endclass : a_seqr

//********************
// Agent class
class a_agent extends uvm_agent;
    a_driver drv;
    a_seqr   seqr;
    a_item   item;
    txn_generator gen=SEQUENCE_GENERATOR;
    uvm_random_stimulus #(a_item) rand_txn_generator;
    int num_rand_txn=20;
    ...
    function void build_phase(uvm_phase phase);
        ...
        // Getting transaction generator
        void'(uvm_config_db#(txn_generator)::get(this,"","gen",gen));
        // Setting transaction generator to sequencer
        uvm_config_db#(txn_generator)::set(this,"seqr","gen",gen);
        // Getting how many transaction should be generated from random stimulus
        // generator.
        uvm_config_db#(int)::get(this,"","num_rand_txn",num_rand_txn);

        `uvm_info("build_phase", $sformatf("Transaction generator is:%0s",gen.name()), UVM_LOW)
        drv  = a_driver::type_id::create("drv", this);
        seqr = a_seqr::type_id::create("seqr", this);

        // Creating random stimulus generator
        if(gen == RANDOM_GENERATOR)
        begin
      rand_txn_generator = uvm_random_stimulus#(a_item)::type_id::create ("rand_txn_generator", this);
          item = a_item::type_id::create("item");
        end
    endfunction : build_phase

    function void connect_phase(uvm_phase phase);
        super.connect_phase(phase);
        drv.seq_item_port.connect(seqr.seq_item_export);
        if(gen == RANDOM_GENERATOR)
            rand_txn_generator.blocking_put_port.connect(seqr.put_imp);
    endfunction : connect_phase
  
    task run_phase(uvm_phase phase);
        super.run_phase(phase);
        if(gen == RANDOM_GENERATOR)
        begin
            phase.raise_objection(this);
            rand_txn_generator.generate_stimulus(item, num_rand_txn);
            phase.drop_objection(this);
        end
    endtask : run_phase
endclass : a_agent

//********************
// Environment class
class m_env extends uvm_env;
    a_agent a_ag;
    ...  
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        a_ag = a_agent::type_id::create("a_ag", this);
        ...
    endfunction : build_phase
    ...
endclass :m_env

//********************
// Testcase 
class test extends uvm_test;
    m_env env;
    ...
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        uvm_config_db#(txn_generator)::set(this,"env.a_ag","gen",RANDOM_GENERATOR);
        uvm_config_db#(int)::set(this,"env.a_ag","num_rand_txn",50);
        ...
        env = m_env::type_id::create("env", this);
    endfunction : build_phase
endclass : test

As shown in the example, txn_generator is an enum which is used to select transaction generation from random stimulus generator or from sequences. Here, a_item is a sequence item class and a_driver is a driver class. Sequence item class and driver class implementation doesn't require any extra modification. 

a_seqr is a sequencer class which contains "put_imp" implementation port. When txn_generator is set to RANDOM_GENERATOR, transaction will be put into m_req_fifo from random stimulus generator otherwise it will be put from sequences. Note that, get_next_item method is overridden in the sequencer class. "m_select_sequence" method is called only when txn_generator is set to SEQUENCE_GENERATOR.

In a_agent class, rand_txn_generator is created which is a random stimulus generator component and it's "blocking_put_port" is connected with "put_imp" of sequencer class. In run phase, "generate_stimulus" method is called which generates "num_rand_txn" number of random transactions.

In the testcase, we are just setting "txn_generator" to "RANDOM_GENERATOR" and "num_rand_txn" (number of random transaction to be generated) to 50. So, 50 random transaction will be generated.

This way, without using any sequence user can generate random transactions and drive them on to interface. So, VIP integration task will become much simple.

Note: You may get fatal ("Driver put a response with null sequence_id") if driver is calling "put_response" task for putting response. To avoid it, you can compile with"+define+CDNS_NO_SQR_CHK_SEQ_ID".