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

I think Gord's example is a degenerate case for a number of reasons.
People generally define local types for variables they expect to be
using locally. And virtual interface variables are generally used in
assignments when only one side of '=' is a virtual interface. So going
out of one's way to allow this situation (or to disallow it if that were
the case) seems burdensome.

I've just read Jonathan's reply and it seems he beat me too it, but I
send it anyways to echo his thoughts.

Dave
 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Brad Pierce
> Sent: Friday, January 05, 2007 9:58 AM
> To: SV_EC List
> Subject: RE: [sv-ec] Struct access via virtual interfaces
> 
> >The main problem would be educating the user as to why this is not
> allowed.
> 
> Is the argument that simulation performance must necessarily be
degraded
> by allowing it, or only that allowing it makes life harder for
> implementors?
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jeff
> Freedman
> Sent: Friday, January 05, 2007 9:39 AM
> To: Rich, Dave
> Cc: Mark Hartoog; Vreugdenhil, Gordon; SV_EC List
> Subject: Re: [sv-ec] Struct access via virtual interfaces
> 
> Rich, Dave wrote:
> 
> >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.
> >
> >
> >
> That might be a reasonable restriction.  It would imply that an
> assignment to or from  an unpacked struct (or union or enum) through a
> virtual interface would be illegal if the struct-type was defined
inside
> the interface.  In that case, the example that Gordon provided would
> produce elaboration errors.  The main problem would be educating the
> user as to why this is not allowed.
> 
> 
> --
> 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.