Re: [sv-ec] Struct access via virutal interfaces

>If we make an interface more like a type, this problem will go away.

Interfaces ought to be declarable in packages, too.

On the other hand, modules ought to be instantiatiable in interfaces.

   http://www.eda-stds.org/sv-bc/hm/3473.html
   http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0000902 

Interfaces look like classes that are instantiated at elaboration-time
instead of run-time because their data elements can be wires.
   
-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mark
Hartoog
Sent: Friday, January 05, 2007 8:21 AM
To: Gordon Vreugdenhil; 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.