[sv-cc] DPI and rand qualifier (grammar)

 
Doug's reported grammar facts are accurate. Since the underlying reasons 
aren't always self-evident, here's a summary:

1. Classes don't currently have DPI imports/exports: true, nonterminal
   'class_method' derives production RHSs with native TFs but not with 
   nonterminal, 'dpi_import_export.'

2. The only DPI formals with rand/randc would involve structs or unions:
   nonterminal 'struct_union_member' derives a RHS with the optional 
   nonterminal 'random_qualifier' (which derives 'rand' or 'randc').
   The grammar doesn't arrange this for DPI imports, it's just built into 
   any use of unions or structures and is the only appearance of
   'random_qualifier' outside of classes.
----

3. Rand-qualified actuals matched with DPI formals

   We should also address what happens when an actual (struct/union) declared 
   with a rand/randc qualifier is matched with a DPI formal that lacks those 
   qualifiers. This might happen if a class method used hierarchical reference to 
   reach outside the class and invoke a DPI import in a module that encloses 
   both the class and the DPI import.

   This seems possible since LRM section 12.5 states that all DPI import functions
   "can be invoked by hierachical reference the same as any normal SystemVerilog
   function." One assumes this also applies to DPI tasks, though not, apparently 
   to abnormal SV functions.

4. Change to allow DPI decls inside a class?

   Section 12.5 comments "Only SV functions can be exported (specifically, this 
   excludes exporting a class method.)"  Even if we accept this general restriction, 
   we might allow exporting class static methods or allow DPI imports as class methods.
   These require thinking through various issues, including whether we would allow 
   class method qualifiers to be associated with DPI imports (e.g., virtual, static, 
   et al.). Before considering this, we can address the narrower rand/randc issues.
---

For the moment, let's assume the restrictions of 1 and 4 above, and tackle the issues 
described in 2 and 3.  One promising approach is to combine Andrzej's observation that
these qualifiers can have no existence on the C side and Francoise's concern for 
expressing this in an intuitive way. A possible approach appears below:

"When a datatype that DP I otherwise processes is associated with a SystemVerilog qualifier
(e.g., rand or randc) that specifis simulator mechanics, rather than datatype representation, 
then DPI accepts formal and actual arguments of that datatype with these restrictions: the 
DPI interface does not provide any simulator semantics associated with the qualifier for the
C realm, no extra bits used by the simulator to represent those semantics are passed to C,
and no values for such bits are written when the data passes from C to SystemVerilog."

If group discussion converges on a solution, I'll make a proposal to incorporate such 
text, probably in section F.5.1 Semantic Constraints.

Ralph

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.