KnowHow
Free Technical Resources

From VHDL Records to UVM Transactions

Although VHDL supports record types (structs), it is more common to use types like Std_logic and Std_logic_vector when describing hardware. With UVM, on the other hand, all communcation amongst verification components makes use of transactions. UVM represents transactions using classes, just as UVM represents components using classes. In object-oriented programming, classes are a very general and powerful mechanism that can be used to create an abstract description of anything. In UVM, components and transactions are distinguished by extending different base classes and by defining different methods.

-- VHDL
package my_pkg is
  type my_transaction is
    record
      data: integer;
    end record;
end package;

// UVM
package my_pkg;
  class my_transaction extends uvm_sequence_item;

    `uvm_object_utils(my_transaction)
  
    rand int data;
    // Other attributes of the transaction go here...
  
    function new (string name = "");
      super.new(name);
    endfunction

  endclass: my_transaction
endpackage

Here you can see the second of the three main code templates used in Easier UVM, namely the transaction or sequence item. (The first code template was the component, and the third will be the sequence.) There are a number of differences between the transaction and the component, as shown in the following table:

Component	Transaction
extends uvm_component	extends uvm_sequence_item
contains `uvm_component_utils	contains `uvm_object_utils
may define ports and exports	(no ports or exports)
contains function new(string name, uvm_component parent);    super.new(name, parent); endfunction	contains function new (string name = "");    super.new(name); endfunction
may define phase methods build, connect, run, ...	may define utility methods convert2string, do_copy, do_compare

Having defined a transaction data type, let's now use it. In VHDL, design entities are not permitted to communicate using procedure calls, so a producer might generate transactions by making signal assignments, as shown here:

-- VHDL
entity producer is
  port (my_port: out work.my_pkg.my_transaction);
end entity;

architecture v1 of producer is
begin
  process
  begin
    my_port <= (data => 99);
    wait;
  end process;
end architecture;

whereas in UVM a producer would call put, as was shown above. We will just highlight the key lines here. The producer instantiates a UVM port and passes the transaction type as a parameter:

// UVM
uvm_blocking_put_port #(my_transaction) my_port;

The producer then creates transactions and sends them out through the port by calling put:

my_transaction tx = my_transaction::type_id::create("tx");
my_port.put(tx);

In VHDL, a consumer might have a process wake up whenever it receives an incoming transaction on a signal, as follows:

-- VHDL
use ...
entity consumer is
  port (my_export: in work.my_pkg.my_transaction);
end entity;

architecture v1 of consumer is
begin
  process
  begin
    wait on my_export'TRANSACTION;
    report "Received transaction, .data = " & to_string(my_export.data);
  end process;
end architecture;

whereas as we have already seen a UVM consumer would implement the put method.

// UVM
uvm_blocking_put_imp #(my_transaction, consumer) my_export;

task put(my_transaction arg);
  `uvm_info("", $sformatf("Received transaction, .data = %0d", arg.data), UVM_NONE)
endtask

Once again we can see that the communication mechanism is rather different when comparing VHDL (or Verilog) with UVM: VHDL sends transactions my making signal assignments, whereas UVM makes method calls. The HDL approach is closer to hardware, whereas the UVM approach is faster in terms of simulation speed and much more flexible when we want to customize the behavior of a component for a specific test.

Next:  From VHDL Generics and Verilog Parameters to UVM Configurations
Previous:  From HDL Input and Output Ports to TLM Ports and Exports

Back to Easier UVM - for VHDL and Verilog Users

Back to the full list of UVM Resources