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

On 9/12/2010 6:09 AM, Peter Flake wrote:
> Replying to Jonathan Bromley's message of Friday
>
> Given these two interfaces:
>
> interface IS;
> reg signed [7:0] R;
> modport M(inout R);
> endinterface
>
> interface IU;
> reg [7:0] R;
> modport M(inout R);
> endinterface
>
> The two modports are not compatible because they have R with different data types, one signed and one unsigned.
>
> function foo (interface.M VI);
> ...
> if (VI.R < 0) ...
> endfunction
>
> The example here is analogous to a parameter of type "type" applied to R, which also changes the behaviour.
>
> However, I do not like the use of the generic "interface" here, and I am trying to get away from it with my weak typing proposal. By choosing IU or IS for the modport type in the header, the meaning
> would be settled locally.
>
> Peter Flake
>
>

-- 
--------------------------------------------------------------------
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.