[sv-bc] Re: [sv-cc] Idea to allow $system calls via the DPI

>I assume you are just asking for DPI-C routines to be allowed to be
>named with a '$' in front, and these routines will have the same
>functionality as a DPI-C imported routine, and none of the PLI
>functionality. Right?

That is exactly correct.

I was heartened by your "just" in that reply - I believe the
implementation cost is very small; for one tool of mine I
was able to prototype it in under a day with just a tweak to
the grammar and the symbol lookup code. Granted it would
take take even longer to spec out than that ;)

>There is a lot of functionality associated with PLI that you don't get
>with the DPI that many people take advantage of. For example, setup
>during the checktf phase, and callbacks for input changes, dealing with
>arguments of different types in the same positions. So I don't see it
>being as trivial to migrate as you might think.

That's true, but the majority of PLI functions I've used
would work fine as DPI functions. The primary exception is
routines which take formats like $display and as such
require variable arguments or arguments of different types.
Those wouldn't migrate. (And note $display-ish calls should
be a infrequent call - if you care about performance!)

>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?

That was a fall-out of this proposal, not the primary
motivation.

The main motivation is DPI is much higher performance than
PLI, and the secondary motivation is it's much easier to
write a DPI function. For example I can wrap any
non-var-arg C function with a line of code - try that with
PLI!

Un-asked: Why not just use the DPI with a function name
without the $?

Using a DPI function without this $ is often not an option
because code must either operate under Verilog 2001, be
backward compatible with an older PLI library on other
simulators, or must support synthesis. On the backward
compatibility point - you can easily ifdef between using PLI
or DPI for the calls on a per-simulator basis. You'd get
higher performance only on those simulators supporting this.

From a practical standpoint, in most companies only a subset
of the team maintain the PLI library and they could easily
improve simulation performance using this proposal, *since
it's almost invisible to the Verilog code* (minus the DPI
statement which can go in a common header). However it
would be hard, if not impossible politically to advocate,
much less completely replace legacy $ calls in an entire
Verilog code base or in IP code.

-Wilson

P.S. BTW Does anyone listening here know why the very
original DPI implementation didn't require the $, thus
making it look like the PLI? Was that considered?

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