RE: [sv-bc] Weakly typed virtual interfaces?

Gord,

I understand your concern, but it seems to me that the issue of defparam
settings of interface instances raises similar questions. A class defined
in the interface may be affected by such a defparam. When a virtual
interface is assigned to new interface instance, surely it is necessary to
check the types of all members referenced by dot notation? This only has to
be done once for each virtual interface / interface instance/ member
reference combination.

A modport is not a data type, strictly speaking, so its compatibility rules
do not have to be the same as a data type. However a modport item has a
data type, and this should follow the same compatibility rules as a dot
reference. This should avoid the fragility.

Peter.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: 13 September 2010 15:38
To: Peter Flake
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Weakly typed virtual interfaces?

I agree with Peter that since the generic interface is bound at elab and
must be "type compatible", one can resolve this correctly per instance of
the context enclosing the subprogram.

Type compatible of course has yet to be clarified --
equivalent? matching? Peter said "if the types and
names of all modport items match" so I assume he had the very strict rule in
mind.

However, I am still concerned with Peter's proposed directions. Since:
    Once a virtual interface has been initialized, all
    the components of the underlying interface instance are
    directly available to the virtual interface via the dot
    notation.
Defining "compatibility" for a virtual interface assignment in terms of
modports is not sufficient.

*All* references to the underlying interfaces through the virtual interface
reference must have the same level of compatibility.

So this means that we'd really have to have a notion of weak type
compatibility on *all* members of the virtual interface.

But that means that if I had a class (or other strong type) defined within
the interface and had elements of that type, I'd be breaking type rules in
SV in general and causing all sorts of other issues.

Peter has focused on the DUT side (port, etc) interactions but we have to
watch the TB side too. We have to seriously consider all the very strange
ways that people are *already* using interfaces and not break that either.

The "weak typing" proposals (and variations thereof) seem to be workable for
synthesis but I just don't see how it all hangs together for the TB side. I
am also concerned about the existence of "strong types" within modport
items; I'm not entirely clear on what that would look like nor what
"weakening" means in such situations.

Are we prepared to require that interfaces not define *any* new strong
types? That would certainly reduce the problems, but could very easily
break existing designs. Are we prepared to say that virtual interface
references to/through strong types can only be made via types that are not
defined within the underlying interfaces? Or are we going to end up having
two sets of type rules -- a "weaker" set for modports and a "stronger" set
for non-modport references?
The latter might be very fragile.

Along with Peter, I am willing to take some simulation time hit for having
interface/virtual interface "weakening", but I am very worried about have
*guarantees* that I don't need to rebuild type relationships (ie.
re-elaborate any expression types, etc) when a virtual interface assignment
occurs. Without substantive restrictions, I don't think I have that
guarantee with any weakening of the system.

Gord

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.