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.