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