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

Some responses are embedded. 

> -----Original Message-----
> From: Ralph Duncan [mailto:RDuncan@CloudShield.com] 
> Sent: Wednesday, December 13, 2006 10:21 AM
> To: Warmke, Doug; Jim Vellenga; sv-cc@server.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.

The BNF does not permit DPI imports or exports to be declared
in class scope.  However, 26.1.1 states that DPI imports and
exports may be declared anywhere normal SV tasks and functions
may be declared.  26.1.1 could be revised to disclude class
member functions from that statement.

Even if DPI imports and exports were allowed in class scope,
there is no way their formals could be attributed with "rand"
or "randc".  The BNF productions show that only unpacked
struct/union elements or class properties can be attributed
with "rand" or "randc".

So my original statement above about structs being the only
types that can appear in DPI formals with rand attributes
is correct.

Note that passing a rand-attributed actual to a DPI call
isn't of concern.  Only formal args are of concern.
(For those uninitiated with the finer points of DPI lore)

> 
> >...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.
Done as far as I'm concerned.  Unpacked struct elements.

> 2. Determining if rand structs pose the only DPI 'hidden 
> data' problem for vendors.
I don't know of any others after 3 years of DPI implementation.

> 3. Writing a comprehensive LRM statement about DPI and all(?) 
> types with rand qualifiers.
> 
> Ralph
>  
>  
>  
>  
>