RE: [sv-ec] Struct access via virtual interfaces

Mark,

I think we are stuck with the fact that interfaces are structural
instances. They contain things like wires and continuous assignments,
which currently need to go through static elaboration.

But even with that issue aside, the purpose of a virtual interface was
to get a handle to a statically elaborated object and move data between
a dynamic class object and a static object without embedding the
hierarchical path of that static object in the class.

So it seems to me the only practical use of a virtual interface in an
assignment is when it can be statically determined that both sides of
the assignment statement are assignment compatible.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Mark Hartoog
> Sent: Friday, January 05, 2007 8:21 AM
> To: Vreugdenhil, Gordon; SV_EC List
> Subject: RE: [sv-ec] Struct access via virutal interfaces
> 
> Defining the struct in a package clearly makes this legal, but I think
> the fundamental question is what is a interface. If an interface is
> structural, then different instances of the interface create
> different types. On the other hand, if a struct were defined in a
class,
> we would not say that every class instance created a new type of the
> struct.
> 
> So what is an interface? Is it a type like a class or is it a
structural
> instance? Right now the LRM seems to treat an interface as a little of
> both and that is what is creating this problem. If we make an
interface
> more like a type, this problem will go away.
> 
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> > Behalf Of Gordon Vreugdenhil
> > Sent: Friday, January 05, 2007 7:29 AM
> > To: SV_EC List
> > Subject: [sv-ec] Struct access via virutal interfaces
> >
> >
> > We've run into another issue with types and virtual interface
> > handling that we think warrants a restriction in the LRM.
> >
> > The basic issue is that the "type" of a virtual interface is
> > not sufficient to permit compile/elab time type checking for
> > assignments; run-time type checking is required even for
> > non-class objects.
> >
> > The basic reason is that for types such as structs, each
> > *instance* of the interface produces a new type which is NOT
> > assignment compatible with other instances of the same interface.
> >
> > Example:
> >
> >      interface viface12_iface;
> >          typedef struct { int a; } S;
> >          S a,b;
> >      endinterface
> >
> >      module top;
> >          viface12_iface if2();
> >          viface12_iface if1();
> >
> >          virtual viface12_iface ifv1, ifv2;
> >
> >          initial begin
> >              ifv1 = if1;
> >              ifv2 = if2;
> >
> >              ifv1.a = ifv2.b;   // (A)
> >
> >              ifv2 = if2;
> >              ifv1.a = ifv2.b;   // (B)
> >          end
> >      endmodule
> >
> >
> > It is clear that assignment (A) "ifv1.a = ifv2.b" should be
> > illegal since ifv1 and ifv2 are not the same interface
> > instance and therefore the structs are not compatible.
> >
> > Assignment (B), with the current LRM, should be legal since
> > ifv1 and ifv2 are now *the same* interface instance and
> > therefore ifv1.a and ifv2.a are now the same type.
> >
> > In general, any assignment through a virtual interface that
> > involves a type defined by the interface with "type identity"
> > rules for assignment compatiblity is going to be legal if and
> > only if the virtual interfaces refer to the same interface.
> >
> > Worse, one would also have to dynamically check for other
> > situations such as "ifv1.a = top.if1.b" which would only be
> > legal if ifv1 happened to currently refer to "if1".
> >
> >
> > It isn't obvious to us that the extra simulation complexity
> > and performance cost is worthwhile considering that only the
> > trivial cases would end up begin valid.  So, we would like to
> > gather some feedback about disallowing access through a
> > virtual interface to values whose types are defined by the
> > interface and where the types have "type identity"
> > compatibility rules.
> >
> > In the example above this would mean that both (A) and (B)
> > would become illegal.  One would have to lift the type "S"
> > out into a package (or pass it via a type parameter) in order
> > to have the assignments be permitted.
> >
> >
> > 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.
> >
> >
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


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