[sv-ec] Struct access via virutal interfaces

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Fri Jan 05 2007 - 07:28:45 PST
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.
Received on Fri Jan 5 07:29:11 2007

This archive was generated by hypermail 2.1.8 : Fri Jan 05 2007 - 07:29:41 PST