[sv-bc] Pure virtual interfaces

I've been doing some more thinking about the concept of pure virtual
interfaces that I originally proposed as a potential direction for a
solution to the virtual interface issues.

I'm not sure that it is really feasible to go that route.

The main motivation that I had in suggesting that was to broaden
the set of things that would be visible versus the "modports
as types" suggestion made by Jonathon B. (and Peter F.). The
problem with modports is that you can't get at types, etc.
and doing so would likely obviate their usefulness in many ways.

But pure virtual interfaces have other problems whose solutions
would likely end up resulting in some form of an inheritance approach.

Here is an example:

    package pkg;
        pure virtual interface intf_base;
                typedef enum { a,b,c} states;
                states some_reg;
        endinterface
    endpackage

    pkg::intf_base my_vintf;

As you might imagine, one might want to get at "states" as a
type (or at least the enums of the type) in order to interact
with "some_reg". But to what "instance" or a compatible
interface does the type belong? Does a compatible interface
declare "states" or would it inherit the type from the pure virtual
interface?

Without having gone through non-trivial examples, I suspect that
one would end up with something very much like parameterized
classes and inheritance from an abstract base class to a concrete
class by the time one really described how a pure virtual
interface would related to compatible interfaces.

But if that is what the model ends up looking like, I think that
I'd prefer to enhance classes to allow some "interface" kinds
of items rather than trying to make interfaces have all sorts
of semi-class/inheritance behavior.

Removing the "inheritance" problems by restricting what is
permitted in the pure virtual interface to non-types, etc.
would likely end up being almost a wrapper around what
you could do with "modports as types".

The upshot is that I now think that if we can live with some of
the limitations of "modports as types", that such a solution
would be far simpler and preferable at this point.

If we can't live with those limitations (and can't come up with
another way to address the deep issues), then we might need
to once again open up fundamental questions about the
nature of classes and interfaces in the presence of virtual
interfaces.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.