Disadvantages of abstract classes instead of virtual interfaces?

[gbbrown]

I've got a situation where the interface connecting my DUT to my UVM environment need to be parameterized. I've started by implementing it via parameterized virtual interfaces. This has become a bit unwieldy as I've had to pass the parameters down the hierarchy from the agent to the drivers/monitors.

I'm considering changing the way I'm handling this by converting to using abstract classes for the driver/monitor and then writing the concrete driver/monitor classes inside the interfaces.

My question is: are there any disadvantages that anyone has seen in using the abstract class method of interface connection?

The only thing I can come up with is that it means any classes that inherit from the concrete driver/monitor classes that reside inside the parameterized interfaces would have to ALSO reside inside the parameterized interface code. This might not be the case, but I can't figure out how to extend a concrete class that is inside an interface when the extending class code is located somewhere else (like in the package, etc).

Interested in hearing anyone's experiences in using abstract classes and whether there were any problems you ran into.

Greg

[pratta]

I think that you will likely run into scoping problems if you implement all of your concrete classes within an interface. How will those classes then be made available outside of that interface? For example, at the system level you may have a need for multiple specializations of this interface that the system level controller would need access to.

In general I have been recommending that people avoid parametrized interfaces because of the problems that you are running in to. However, if they cannot be avoided then you can avoid the proliferation of the parameters through your class hierarchy by using a non-parametrized abstract class to provide access to virtual methods that operate on the interface, and then designing the UVM agent to accept that non-parametrized abstract class and doing all interface operations through that. A parametrized concrete class that extends that base class must also be implemented which has a reference to that parametrized interface and which implements all of the virtual methods to actually operate on that interface. The testbench integrator must then declare a specialized version of that extended class and pass it into the agent.

[dave_59]

I think that you will likely run into scoping problems if you implement all of your concrete classes within an interface. How will those classes then be made available outside of that interface? For example, at the system level you may have a need for multiple specializations of this interface that the system level controller would need access to.

Pratta, the rest of your post seems to answer your own question. An abstract class is declared in a packages outside of a parameterized interface. It is free from any dependencies on parameters used by the interface. More likely, some subset of parameters used by the interface may be needed by the abstract class and will be more manageable to deal with at the system level.

I don't understand the need to extend the concrete class. It is just there to provide access to the signals and methods in the interface or module. Since you can't extend the interface/module, why would you need to extend the class?

FYI, the concrete class does not need to be inside your interface. It could be defined in another module/interface, or in an interface that is bound into your interface.

[brianmanee]

An abstract class cannot support multiple inheritance, but an interface can support multiple inheritance. Thus a class may inherit several interfaces but only one abstract class.

 

An interface is an empty shell, just only the signatures of the methods. The methods do not contain anything. The interface can't do anything. It's just a pattern. An Abstract class is a class which will contains both definition and implementation in it. More about....Abstract Class and Interface

 

Brian

 

[apfitch]

Hi Brian,

  your post may be correct when comparing SystemVerilog Interface Classes to SystemVerilog Abstract Classes, but the original poster was talking about SystemVerilog Interfaces, not SystemVerilog Interface Classes,

 

regards

Alan