SV12 interface classes — think of them as next-gen modports
SV12 learned its new ‘interface class’ concept from Java. If you are more familiar with SystemVerilog than with Java, your intuition may be misled by the word ‘interface’. Think of these instead as next-gen modport declarations.
An interface class can’t be instantiated. It’s a specification of a protocol that can be implemented by other classes. A protocol describes an API for interacting with an object of the implementing class — hence the ‘interface’ in ‘interface class’.
For example, a class that models a database might implement a variety of views of the data. Or a class that models a RAM might implement a read-only protocol and a read-write protocol.
If you declare the type of a port to be an interface class, then the only objects that can be passed across the port are those whose classes implement the protocol. And the only methods that can be used to interact with the object are those specified in the protocol.
The module port can happily accept many types of class objects, as long as they implement the required protocol. The desire to keep things generic like this is exactly the motivation today for declaring ports ‘interface.mp’. But the danger with generic modports is the over-reliance on names, as pointed out by GV in a comment here. An interface class, however, is a fully defined type.
So a class object passed between modules is like an interface instance, and an interface class is like a modport.
Update: Sergey in a comment points out the strong similarity to SystemC interface/channel/port.