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.