Hi Jim and Ralph, Thanks for the thoughtful responses. After much discussion with our experts on randomization, I think I have a handle on a good solution. First, for Ralph's questions. Class types are not allowed in DPI formals, so we don't have to worry about those. Structs are the only types that can appear in DPI formals that could have "rand" appear in their declarations. The only applicable metadata I know of is: 1. rand_mode on/off 2. randc's currently cyclical state Adherence to constraints is not part of this metadata. Further, it is legal to manually (i.e., procedurally) assign a value to a rand variable that defies constraints that are in effect. Assuming such an assignment took place and the variable's rand_mode is enabled, the variable will change to a legal value next time randomize() is called. If the variable's rand_mode is disabled, randomize() will fail next time it is called. Since C assignment of out-of-constraint values to rand variables is analagous to procedural assignment to rand variables, there are well-described semantics that govern operation. Now for Jim's questions. A good analogy would be to consider bit-stream casting between two unpacked structs. Both have the same declaration except that one has some rand elements and the other does not. In this scenario, it would be desirable to simply ignore any metadata during the casting operation. When assigning from the 'rand' struct to the non-rand struct, only pure values would be assigned into the destination struct elements. When assigning from the non-rand struct to the rand struct, any metadata in the rand struct would be explicitly untouched. That way the rand destination struct's current rand_mode state wouldn't be affected by the assignment. Dave Rich has volunteered to take care of the above conditions in SV-EC when he handles similar issues for class local and protected data during bitstream casting. I think that DPI interaction with such structs should be considered in an analagous way to the above discussion of bitstream casting. i.e. on copy-in to C, ignore any metadata that might be present in the struct. On copy-out from C, leave any metadata untouched, in its initial state upon entry into the C code. If there is no disagreement on the solution proposed above, I can create a Mantis item and enter an initial proposal. Regards, Doug > -----Original Message----- > From: owner-sv-cc@server.eda.org > [mailto:owner-sv-cc@server.eda.org] On Behalf Of Jim Vellenga > Sent: Monday, December 11, 2006 7:58 AM > To: Warmke, Doug; sv-cc@server.eda.org > Subject: 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 > ]> ]> ] > ]> ]> ] > ]> ]> > ]> ]> > ]> ] > ]> > ]> > ] > >Received on Tue Dec 12 11:50:58 2006
This archive was generated by hypermail 2.1.8 : Tue Dec 12 2006 - 11:51:21 PST