[sv-bc] Interesting LRM pli conflict

There appears to be an interesting issue in the LRM that I would
like to raise.  The issue is best expressed as an example.

   module top;
     integer m[9:0];
     task automatic t (ref integer i);
        $some_pli(i);
        i++;
     endtask
     integer other_int;
     initial $some_other_pli(m);
     initial t(m[0]);
     initial t(other_int);

   endmodule

Consider the LRM requirements for memory "m" and for
memory element "m[0]".  Assume that the pli involved
uses the tfnodeinfo structures.  By SV semantics, the
"ref integer" and the word select "m[0]" must reference
the same actual data (pointer passing).  tfnodeinfo
for the "some_other_pli" case assumes that the layout
of "m" is in tf_memory_node compatible layout.  But
tfnodeinfo of "some_pli" will assume that the memory
layout is in vecval form.  Since the "ref" unifies the
pointers, it seems that there is a conflict since the
actual memory layout cannot be in both forms.

What should implementations do in such cases?
   1) layout memories in tfnodeinfo compatible way to
      maximize legacy support and disallow the "ref integer"
      call in the source?
   2) layout memories in a "ref integer" compatible way
      and disallow tfnodeinfo for memories in SV?
   3) adopt "inout" semantics when "ref" conventions are
      used on a memory word for which tfnodeinfo might
      have legacy meaning?  (ie. copy the m[0] to/from a
      temporary integer that is used for the "ref" call)
   4) some LRM defined rule for choosing (1) or (2)?
   5) something else?

This impacts support for legacy designs in an SV environment,
particularly if one wants to overlay an SV testbench over a
legacy Verilog design and use a mix of old pli and new
calling conventions.

Opinions?

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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