Physical interface inside a class

Hi All,

I do have a basic query, Can we call a physical interface inside a class.

I do know that class is dynamic in nature so as the interface is static and we need to declare it as virtual.

But is there any declaration by which we can instantiate a physical interface inside a class.

Thanks,
Nikhil

In reply to nchakravarthy:

No there is not. Interface instantiations are static and can only be done inside of modules. Since classes are dynamic, they can not contain static interfaces, but can reference them via virtual interface handles.

In reply to nchakravarthy:

A class is a dynamic property, which is created at run time while an interface is a static property, which is created at compile time. So, it is not possible to instantiate a physical interface inside a class. But as cgales said, a handle of virtual interface is used to reference a physical interface.

Hi cgales and bdreku,

I agree with the statement that interface is a static property. But I have a question, please clarify. When we are able to declare static properties and methods in a class, Why cant we use interface (which is static) directly inside the class.

Hi cgales and bdreku,

Thanks for your inputs

Here is the code that i have tried and had my observations :

interface chk_1;
  
  logic a = 0;
    
 endinterface

  class a_inst;
    virtual interface static chk_1 intf_chk; //Line under observation
    static bit[1:0] b;
    task run();
      intf_chk.a = 1'b1;
    endtask
  endclass

   //Module described below
   module chk_main();
      initial begin
        a_inst a1;
        a1.run();
      end
   endmodule

Observations:

  1. In the class “a_inst” if i declare the interface as “virtual interface static chk_1 intf_chk”
    the compiler is not shouting any compilation error but if i declare the interface as
    “static chk_1 intf_chk” the compiler is shouting a error. It it the Virtual keyword is
    making the difference if so why ?
  2. Inside a module am calling the run method of the class “a_inst” but over here
    the simulation is shouting a run time error as
    “Error: uninitialized virtual interface object”
    am am unable to assign any values to the variables of the interface.

why the compiler is shouting a compilation error if i declare the interface as “static chk_1 intf_chk” ?

In reply to nchakravarthy:

Nikhil,

There are some problems in the terminology of your questions. You do not call modules or interfaces, you instantiate them. We use the word instantiate to mean come into existence. And modules and interfaces can only be statically instantiated , which means they come into existence at the start of a simulation before time 0. To call something means to activate a procedural set of statements encapsulated in a task or function, and you can call a task or function declared inside an interface. Another problem is in understanding the difference between a variable and the handle that refers to an instance.

Class objects can only be dynamically instantiated by calling its constructor function. However, class variables that eventually hold handles to class objects can be statically or dynamically instantiated. See http://go.mentor.com/class-on-classes for more info on that.

It is certainly possible for a class method to call a function declared inside an interface instance directly. The problem lies in where we want to define the class and keeping the testbench independent from the DUT hierarchy.

Most class-based testbenches are declared inside a package, and packages do not allow any references to objects outside that package except by import of another package. And even if they were allowed, we would not want a hard-coded hierarchical paths inside our testbench code as this makes the class less reusable.

There are at least two ways to deal with referencing hierarchical paths from a class defined in a package. SystemVerilog allows you to declare a virtual interface variable that holds a handle to a static interface instance. From the top level testbench module, you can dynamically construct a class that has a virtual interface variable inside it and then assign the variable with a handle that has the path to interface instance. This works very similar to a class variable with a handle to a dynamic class instance except the instance the variable refers to is now a static instance.

There are a number of limitations when referring to a static instance through a virtual interface variable. The biggest one is the fact that any parameter overrides when instantiating an interface instance have to be matched with parameter overrides when declaring a virtual interface variable. It is very difficult to propagate those parameter overrides to the testbench. So another technique has been developed that avoids virtual interface variables altogether and instead uses abstract classes. But I think you should fully understand the virtual interface issues before exploring getting rid of them.

In reply to dave_59:

Thanks Dave for your inputs.

I have read a concept of Polymorphic Interfaces, and all the components use the abstract class methods to access the interface variables. Is this the one you are talking about?

In reply to dave_59:

Hello Dave,

I know this is an old thread but I just wanted to know if polymorphic interfaces can also be used without UVM/OVM. I am currently working on a bare SystemVerilog testbench and would like to know if the concept applies before I spend hours understanding it and implementing it.

Thanks!

In reply to arquer:

UVM/OVM is SystemVerilog. Any OOP concept applies to whatever you write.

And before you write your own class-based testbench, consider using some of the features, like the report, config_db, and even the component hierarchy before re-writing it yourself.

can we write class inside module and module inside class
I do know that class is dynamic environment and module is static.
But what can be the consequences.
Thanks

In reply to shobhana.swarnkar18:

A class is effectively a user defined data type used to declare a variable. A module is a scope container that gets elaborated (flattened) before the simulation starts.

You may want to read this “Two Kingdoms” paper touches on how the two concepts relate to each other.