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

Hi Wilson,

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?

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.

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?

Dave

> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
> Wilson Snyder
> Sent: Wednesday, August 18, 2010 7:56 AM
> To: sv-bc@eda.org; sv-cc@eda.org
> Subject: [sv-cc] Idea to allow $system calls via the DPI
>
>
> Enclosed is an idea to allow $ in DPI calls I've fleshed out
> with a few people, and prototyped. I'd like the group's
> thoughts.
>
> MOTIVATION
>
> SV supports defining external DPI functions and tasks. The
> C interface side of the DPI is simple, portable, and fast.
>
> Legacy Verilog code typically uses user defined $system
> tasks and functions, which often in the case of IP cannot be
> easily migrated to the DPI. $system calls also have the
> advantage of being ignored by almost every physical design
> tool, while DPI is not generally supported. Simulators vary
> a great deal in how user $system calls are plumbed into the
> simulation, and the user needs to know how to use the VPI to
> add them into their code.
>
> The proposal is to allow the user to make an external DPI
> definition with a $ name. This allows Verilog code to call
> a $user system call as before, but it will be dispatched via
> the DPI interface to a modern C routine. This also provides
> an excellent migration path to the DPI, and a speed boost to
> such applications.
>
> Note PLI calls which take variable arguments would need to
> remain PLI, or at least until the DPI is expanded to support
> vararg calls.
>
> SYNTAX A
>
> There are two alternative suggested syntaxes. The first
> would probably be more obvious to users:
>
> import "DPI-C" dpi_sys_task = task $dpi_sys (integer i);
>
> This requires changes to the dpi_task_proto and
> dpi_function_proto grammar rule to allow a
> system_tf_identifier to be declared.
>
> SYNTAX B
>
> The second syntax uses the current import syntax, and
> changes the lookup rules.
>
> import "DPI-C" dpi_sys_task = task \$dpi_sys (integer i);
>
> This already matches the existing dpi_import_export
> grammar rule. The SV parser code which looks up a symbol
> then needs to know to lookup a \ escaped $ call when a
> non-escaped $ call occurs.
>
> I've prototyped this method, and it is working well. (A
> custom preprocessor adds \ escapes to specific recognized
> $calls.) However, I think SYNTAX A is cleaner.
>
> Thoughts?
>
> -Wilson
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

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