SV Interface classes in UVM based environment

UVM
, ,
1

Hello,

Is there any paper or example that uses SV interface classes in a UVM environment? I’ve seen some examples over the internet but none of them are “placed” in a UVM environment.

Any pointers to references are much appreciated.

-R

2

In reply to rgarcia07:

There are some idiosyncrasies to using interface classes together with UVM. One of the most annoying I noticed is:


class some_class;

  function do_stuff(some_interface_class arg);

    // fails to compile, because 'print()' is defined in 'uvm_object' and 'arg' is of type
    // 'some_interface_class'
    arg.print(); 

  endfunction

endclass

It’s not possible to say that you have an object that both implements an interface (some_interface_class) and is a uvm_object.

Java has print() and clone() methods embedded in any_object, which every class implicitly extends, so an argument of type some_interface_class would also automatically get these methods. (Java terminology for the methods/classes in the sentence is toString(), clone() and Object, but I wanted to use something similar to the UVM names.)

C++ handles these common operations like printing and copying using operator overloading.

SystemVerilog provides neither of these two mechanisms. You end up having to declare all of your interfaces as printable, clonable, etc. which really defeats the point of using interface classes.

3

In reply to Tudor Timi:

A simple cast takes care of that.

Also, you may wan to check out the second best paper of DVCon 2016 5.1 SystemVerilog Interface Classes - More Useful Than You Thought

DVCon has several other interface class papers using the UVM.

4

In reply to dave_59:

Thank you both for your inputs, and the information

-R

5

In reply to dave_59:

Casting is bad style.

The function didn’t specifically state that it expects something that extends uvm_object as an input. Code where I pass in an implementation of the interface that does not extend uvm_object will compile, but will fail at run time.

Also, if you cast, you get two variables that refer to the same object:


function do_stuff(some_interface_class arg);
  uvm_object arg_as_uvm_object;
  if (!$cast(arg_as_uvm_object, arg))
    $fatal(0, "Cast error");

  // use 'arg_as_uvm_object' because we want to use functions defined in
  // 'uvm_object'
  arg_as_uvm_object.print();
 
  // ... use 'arg' further, because we need to use the functions defined 
  // the interface
  arg.some_cool_function();
endfunction

But it works is not the only criterion by which code should be developed.

6

In reply to Tudor Timi:

Would have been a different story had the UVM been developed with interface classes to begin with.