RE: [sv-cc] Question on "rand" qualifer on struct elements

Doug,

You seem to be thinking of a mechanism that has so far
been outside of my thinking about DPI.  You make the
statement that "there is no way to save off [the
rand or randc metadata], and then pass it back to
SV later."

I'm curious as to what the point of "passing" it between
language domains is.  Can the metadata change on the
SV side between the time that it passes from SV to C
and the time it passes back?  In fact, I have the
same question about the "signed" property.  What is
the point of saving that off and passing it back?  Can
it change on the SV side?

Regards,
Jim

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
]Sent: Friday, December 08, 2006 11:54 AM
]To: Jim Vellenga; sv-cc@eda.org
]Subject: RE: [sv-cc] Question on "rand" qualifer on struct elements
]
]Jim,
]
]Thanks for the response.  Good analogies there.
]The main difference between your analogous concepts
]and rand struct elements is that those concepts have
]a representation in C.  When one sends signed struct
]elements over the boundary, the corresponding C struct
]elements can also be signed or not.  A packed array
]is guaranteed to have the correct number of elements
]copied in and out of C stroage by the system.  Basically,
]there is no "loss" in those operations.
]
]For the metadata associated with rand struct elements,
]there is no representation in C.  There is nowhere to save
]off that data, and then pass it back to SV later.
]The same is true for unpacked tagged unions, which is one
]reason we decided to make those illegal DPI datatypes.
]
]Consider a user who creates a struct in SV with one
]or more rand elements.  They pass it into C, successfully.
]C saves it off, reads and writes the data members, and then
]eventually passes it back to SV at some future time.
]At that time, there will be no way for the system to
]"remember" the correct values of the original metadata.
]Some default values will be plugged in, and the system
]may behave in surprising ways.
]
]One other minor difference compared to your analogies
]is that the metadata associated with rand struct elements
]and unpacked tagged unions is dynamic in nature.  The
]properties of your analogies are static in nature.
]Not sure if that makes a big difference, though.
]
]Regards,
]Doug
]
]
]
]> -----Original Message-----
]> From: owner-sv-cc@server.eda.org 
]> [mailto:owner-sv-cc@server.eda.org] On Behalf Of Jim Vellenga
]> Sent: Friday, December 08, 2006 5:44 AM
]> To: Warmke, Doug; sv-cc@server.eda.org
]> Subject: RE: [sv-cc] Question on "rand" qualifer on struct elements
]> 
]> By the way, I agree with Doug that the LRM specifically
]> allows "rand" and "randc" qualifiers on struct members.
]> Whether or not the qualifiers mean anything in practice
]> outside of a class scope -- well, I don't think anyone
]> has demonstrated that yet.  But when a struct of such
]> a type is instantiated inside a class scope, then
]> the qualifiers definitely mean something.
]> 
]> Doug, your question seems at bottom to revolve around
]> the transmission of metadata.  As you stated, it has
]> to be stored (somewhere) in the simulator for that
]> struct.  But I added the qualifier "(somewhere)" because
]> just where that gets stored is a matter of choice on
]> the part of the engineers implementing the simulator.
]> Would you agree?
]> 
]> Let me try reasoning by analogy, and you can tell me
]> where the analogy breaks down.  For many struct elements,
]> the simulator also has to store (somewhere) whether the
]> type is signed or unsigned.  Yet that metadata doesn't
]> get transferred across the DPI boundary.  In fact,
]> even the size of a packed array doesn't get transmitted
]> as part of the data transfer itself, although we provide
]> a separate function for querying it.
]> 
]> So it seems to me that the data transfer part of DPI
]> transfers only the value parts of any struct or array
]> or other eligible object, and not any of the metadata.
]> The one exception to this is packed tagged unions in the case
]> where the LRM (presumably) specifies exactly where the
]> tags should go.  But since otherwise the LRM does not
]> say where the metadata goes, and the location of that
]> metadata is therefore implementation-dependent, doesn't
]> it make sense to omit it as part of the data transfer?
]> 
]> Regards,
]> Jim
]> 
]> --------------------------------------------------------- 
]> James H. Vellenga                            978-262-6381 
]> Engineering Director                   (FAX) 978-262-6636 
]> Cadence Design Systems, Inc.         vellenga@cadence.com 
]> 270 Billerica Rd
]> Chelmsford, MA 01824-4179
]> "We all work with partial information." 
]> ----------------------------------------------------------  
]> 
]> ]-----Original Message-----
]> ]From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
]> ]Sent: Wednesday, December 06, 2006 11:24 AM
]> ]To: Chuck Berking; Jim Vellenga; sv-cc@eda.org
]> ]Subject: RE: [sv-cc] Question on "rand" qualifer on struct elements
]> ]
]> ]Chuck,
]> ]
]> ]*** From LRM 13.3 ***
]> ]
]> ]An unpacked structure can be declared rand, in which case 
]all of that
]> ]structure's random members
]> ]are solved concurrently using one of the rules listed in this 
]> ]subclause.
]> ]Unpacked structures shall not
]> ]be declared randc. A member of a unpacked structure can be 
]> made random
]> ]by having a rand or
]> ]randc modifier in the declaration of its type. Members of unpacked
]> ]structures containing a union as
]> ]well as members of packed structures shall not be allowed to have a
]> ]random modifier.
]> ]
]> ]*** END of LRM Part ***
]> ]
]> ]This allows one to declare a class that contains a struct member,
]> ]and when the class "randomize()" is called, only the elements of
]> ]the struct declared "rand" will be randomized.
]> ]
]> ]Jim,
]> ]
]> ]When "rand" is associated with a struct element, it does imply some
]> ]extra state must be stored in the simulator for that struct.  Thus
]> ]the SV representation of the struct is pretty far removed from a
]> ]C equivalent (due to the metadata).  It's not quite as far removed
]> ]as say a SV class object is from a C struct, but it's in that 
]> ]direction.
]> ]
]> ]The biggest issue I see revolves around what should happen when such
]> ]a struct is passed from C to SV. e.g. as a DPI import's output arg.
]> ]What should the initial values of that meta data be?  Is it OK just
]> ]to leave that unspecified, and allow simulator vendors to initialize
]> ]it in whatever way they deem prudent?
]> ]
]> ]Thanks guys!
]> ]
]> ]Regards,
]> ]Doug
]> ]
]> ]> -----Original Message-----
]> ]> From: Chuck Berking [mailto:berking@cadence.com] 
]> ]> Sent: Tuesday, December 05, 2006 1:12 PM
]> ]> To: Jim Vellenga; Warmke, Doug; sv-cc@eda.org
]> ]> Subject: RE: [sv-cc] Question on "rand" qualifer on 
]struct elements
]> ]> 
]> ]> I can't see how "rand" decls should be considered legal 
]in structs.
]> ]> In my opinion, structs are not sufficiently scope or class-like to
]> ]> warrant such an extension either.  I.e. would we ever 
]want to allow
]> ]> "S.randomize()" to set their values ? 
]> ]> -Chuck Berking
]> ]> 
]> ]> -----Original Message-----
]> ]> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]> ]> Behalf Of Jim
]> ]> Vellenga
]> ]> Sent: Tuesday, December 05, 2006 11:46 AM
]> ]> To: Warmke, Doug; sv-cc@eda.org
]> ]> Subject: RE: [sv-cc] Question on "rand" qualifer on 
]struct elements
]> ]> 
]> ]> I don't see any reason why they couldn't be treated
]> ]> in DPI just as ordinary struct members are -- i.e.,
]> ]> struct members without the rand and randc qualifiers.
]> ]> The C side wouldn't be able to detect the qualifiers,
]> ]> of course -- but then the client could always use
]> ]> VPI if they need that particular info.
]> ]> 
]> ]> To my mind, the rand and randc qualifiers simply
]> ]> connect the struct members with the built-in functions
]> ]> such as randomize() (and the mode setting functions).
]> ]> Conceptually, one can look at randomize() as a function
]> ]> that does some calculations and then sets the values
]> ]> of certain data values.  Since any other function
]> ]> can do the same thing, I don't think that DPI should
]> ]> handle these struct members any differently.
]> ]> 
]> ]> Clarification:  Does a declaration with rand and randc
]> ]> qualifiers have to appear only inside a class declaration?
]> ]> If so, is there any limitation on how DPI handles objects
]> ]> declared inside classes?
]> ]> 
]> ]> Regards,
]> ]> Jim
]> ]> 
]> ]> --------------------------------------------------------- 
]> ]> James H. Vellenga                            978-262-6381 
]> ]> Engineering Director                   (FAX) 978-262-6636 
]> ]> Cadence Design Systems, Inc.         vellenga@cadence.com 
]> ]> 270 Billerica Rd
]> ]> Chelmsford, MA 01824-4179
]> ]> "We all work with partial information." 
]> ]> ----------------------------------------------------------  
]> ]> 
]> ]> ]-----Original Message-----
]> ]> ]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]> ]> ]Behalf Of Warmke, Doug
]> ]> ]Sent: Wednesday, November 29, 2006 2:47 PM
]> ]> ]To: sv-cc@eda.org
]> ]> ]Subject: [sv-cc] Question on "rand" qualifer on struct elements
]> ]> ]
]> ]> ]Hello SV-CC,
]> ]> ]
]> ]> ]I have a nice DPI question for everyone to ponder.
]> ]> ]
]> ]> ]In SV, it is possible to declare struct elements
]> ]> ]as "rand" or "randc":
]> ]> ]
]> ]> ]struct {
]> ]> ]    int I;
]> ]> ]    rand int J;
]> ]> ]    randc int K;
]> ]> ]} S;
]> ]> ]
]> ]> ]Should structs with these element datatype qualifiers
]> ]> ]be allowed as DPI arguments?
]> ]> ]
]> ]> ]Are there any other similar qualifiers we should watch
]> ]> ]out for?
]> ]> ]
]> ]> ]Thanks,
]> ]> ]Doug
]> ]> ]
]> ]> ]
]> ]> 
]> ]> 
]> ]
]> 
]> 
]