Re: [sv-bc] Interesting LRM pli conflict

Steven Sharp wrote:
> I noticed this issue a while back, and we discussed it here.  We
> concluded that the proper solution was
> 
>>   2) layout memories in a "ref integer" compatible way
>>      and disallow tfnodeinfo for memories in SV?
> 
> Any of your other suggestions would affect the behavior of the
> SV language, changing what has been defined in the 1800 LRM.
> 
> The PLI 1.0 interface was deprecated and is no longer part of the
> 1364 standard (and therefore is not part of the 1800 standard).
> The PLI 2.0 interface (AKA VPI) provides a clean way of accessing
> memories, so the tf_nodeinfo kludge is not needed for that any more.
> 
> Yes, this could create some issues with legacy PLI.  But we do
> need to be able to move forward at some point.  When we have added
> a lot of new language constructs that are already not supported by
> legacy PLI, and that PLI interface has been removed from the
> language, it seems like a good point to do that.

I agree.  That is basically the direction that I expected would
be the most favorable.

It might be worthwhile to have an LRM statement of the form:
    SystemVerilog no longer supports tf_nodeinfo access to
    memories, even if such memories are declared in a form
    that is compatible with 1364-2001.

That would make it clear that even access to legacy data
forms from some parts of the deprecated PLI 1.0 cannot
be expected to work.

> Another concern we have run into is performance of the VPI access
> to memories, compared to tf_nodeinfo.  We have created some
> additional VPI access mechanisms to address those concerns.  We
> would be happy to make those available for possible standardization.

That seems reasonable.  I'm assuming at this point that the issue
should be handled by SV-CC since the most likely solutions won't
impact the core language.

Thanks for the feedback.

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.