RE: [sv-cc] DPI and "rand" qualifers in general

I may be mistaken, but it seems to me that the actual
DPI transfers are really transferring bit patterns
rather than metadata, and that it's really up to
the application designer to look at the DPI
declarations in SystemVerilog and ask for the
data appropriate to the DPI-related C function
that he or she is implementing.

I like Doug's idea that when data is copied from
C back to SystemVerilog, the metadata (in this case
the "rand/randc" metadata) remains untouched.  For
that matter, the "signed" and size information
and storage class metadata all also remain untouched.

The SystemVerilog DPI C layer does include some
functions (such as svSize) which can obtain some
metadata in a standard format.  I did not, though,
see a function for determining whether a passed
argument is signed or unsigned, at least not in
a quick glance.  But if there were sufficient demand,
couldn't we provide additional routines to obtain
metadata information of choice about actual arguments?
I know Michael has expressed a desire for routines of
this nature.

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: Ralph Duncan [mailto:RDuncan@CloudShield.com] 
]Sent: Wednesday, December 13, 2006 1:21 PM
]To: Warmke, Doug; Jim Vellenga; sv-cc@eda.org
]Cc: Rich, Dave
]Subject: RE: [sv-cc] DPI and "rand" qualifers in general
]
]In response to Doug's email:
]
]>Structs are the only types that can appear in DPI formals
]>that could have "rand" appear in their declarations.
]
]LRM section 13.3 states that class variables that are 
]"singular variables 
]of any integral type," arrays, individual array elements, et 
]al., can be 
]declared with rand qualifiers.  An SV class object with a DPI 
]import (26.1.1),
]therefore, appears capable of declaring any of these as a DPI 
]formal with rand.
]Whether ModelSim or any other simulator attaches rand-relevant 
]'hidden data' 
]to any data type other than structs is a separate question.
]
]>...it is legal to manually (i.e., procedurally) assign a 
]value to a rand 
]>variable that defies constraints that are in effect...C assignment of 
]>out-of-constraint values to rand variables is analagous...
]
]Thanks, that is helpful to know.
]
]>I think that DPI interaction with such structs should be 
]considered in an
]>analagous way to the above discussion of bitstream 
]casting...If there is 
]>no disagreement on the solution proposed above, I can create 
]a Mantis item 
]>and enter an initial proposal.
]
]There is disagreement -- on what data types DPI can see with 
]active rand qualifiers 
]-- and there's non-knowledge about the scope of rand 'hidden 
]data' issues.
]
]Is it reasonable for a vendor who's hiding extra data in rand 
]structs to 
]ignore it for both bitstream casting and data passage to 
]another language?
]Probably so.
]
]Should our definitive LRM remarks on DPI and rand/randc 
]qualifiers revolve 
]primarily on what _may_ be one implementation's issue with 
]what may be a small 
]subset of relevant data types?  Probably not.
]
]Instead, let's tackle the matter one issue at a time by: 
]1. Determining what data types with rand qualifiers DPI could 
]encounter.
]2. Determining if rand structs pose the only DPI 'hidden data' 
]problem for vendors.
]3. Writing a comprehensive LRM statement about DPI and all(?) 
]types with rand qualifiers.
]
]Ralph
] 
] 
] 
] 
]