[sv-cc] DPI handling or rand/randc data

Doug,

Here's an attempt to summarize SV-CC's discussion on the 'rand' qualifiers, respond to your recent points, and
introduce a possible compromise solution.

1. As long as any SystemVerilog entity can legally declare data with rand/randc attributes and can declare a 
DPI import or export that uses such data, then SV-CC has to address this issue.  It seems that an SV class 
could do both those things.

2. As an inter-language interface, DPI doesn't implement semantics one language has and the other lacks.  
However, in some cases it does allow data types that reflect capabilities present in only one of the languages.

3. Tagged, packed unions afford an example.  SystemVerilog has tags but C does not.  The LRM says exactly 
where the tag is (pending Mantis items).  Since DPI and the C user know where the tag bits and union member bits
will be for any SV simulator, DPI does pass this data type. Presumably, the tag's contents are valid when it arrives
from SV into C.  However, DPI cannot monitor C writes and thus, cannot guarantee tag validity for any tagged, 
packed union output from C to SV - i.e., DPI can't create reliable tagged union semantics within C.

4. Our imperfect Analogy:

SV randomization 'metadata' is like packed union tags, in that it associates metadata for a capability that C lacks 
with data C otherwise can recognize.  It is unlike packed union tags, in that the LRM doesn't specify that the metadata 
is present _within the data_ and in a set place.

5. Metadata vs. data (what metadata?)

Let the metadata = a rand/not-rand flag and, perhaps, constraint ranges.  If the metadata is stored with the data (e.g., 
in a hidden struct field), DPI can only allow it if the LRM specifies metadata rep & storage conventions in a simulator-
independent way (like tags in LRM 4.11).

If metadata isn't stored with the data value, it isn't the metadata that C might corrupt but the data, itself - i.e., C may 
overwrite a randomized value with another value, one that may be outside constraint block ranges kept in the metadata.
Like the case of packed union tags, the C code may return a data value that its metadata no longer describes correctly.

6.  Consider a Possible Solution

If there is a major simulator storing randomization/constraint metadata within relevant structs etc., then either: 
(a) they change, (b) they get SV-BC to provide a simulator-independent standard for what is stored and where, 
(c) DPI simply cannot support this kind of data in a simulator-independent way.

However, if the metadata isn't stored with the data, then our problem is that the C code can return a value that 
isn't properly randomized or constrained.  If this is the case, consider doing the following: allow DPI to pass such values
with an LRM caveat similar to one used elsewhere:

"Variables with otherwise legal DPI data types that have active rand or randc qualifiers in their SystemVerilog declarations 
can be passed to C across the DPI interface.  However, the simulator may issue a warning if they are passed in inout or 
output mode, since returning values may not conform to the relevant randomization or constraint requirements."