Re: [sv-bc] Wilson Snyder's proposal to add $tasks to DPI calls

>There's a mail thread captured here:
>
>http://www.eda.org/sv-bc/hm/10502.html
>
>Summary of responses:
> - The idea was that DirectC/DPI function calls would be indistinguishable from Verilog calls (also, hence the concept of input/output/inout formal arguments missing in PLI). Thus it would be possible to switch between different implementations (i.e. Verilog vs. C) without modifying the calls.
> - There's a workaround: you can easily ifdef between using PLI or DPI". It's still true with the current syntax., just put $pli_name or DPI_name in ifdef-ed macro and use 'macro in the calls

The follow up to that point was that that wasn't a
workaround for the problem as stated; the point of the
proposal is to not require modification to the IP or other
calling code.

> - About the motivation concerning synthesis tools. What you are really asking for is to add more features to the language for simulation vendor
>to implement so that synthesis vendors don't have to implement anything? How fair is that? Why not just ask synthesis vendors to ignore DPI imported routines?
> - For DPI tasks starting with $, you would have to define the precedence rules relative to system tasks. I assume that you would want the DPI
>task to take precedence.
>
>Big takeways:
> 1. This is in conflict with the initial motivation of the feature

Sorry, the conversation was a while ago so I may have missed
it, but what is in conflict?

> 2. This can be achieved through already available language features

The ultimate purpose of choosing DPI vs VPI can certainly be
done with `ifdefs as can many of the features that have been
recently added. But, that overlooks the point, which was
there's currently no migration path for older code that
doesn't require editing the code. Providing a migration
path to better performance with the DPI is something that
should be of interest to the standard.

It's fine to argue that a "clean" code base which is all
SystemVerilog code doesn't need this, but that's not the
world most of us are in today - with even Verilog 1995 IP
still often encountered.

I'd also add the biggie:

3. Are the total implementation costs worth the percieved
benefits, or not.

>I will add this topic for review during the next SV-BC
>meeting (Oct 25, 2010) and capture a more formal response.

Thanks; I think the proposal helps problems others are
encountering, but even if not it's good to get it settled
and dropped.

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