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

From: Brad Pierce <brad_pierce@acm.org>
Date: Wed Aug 18 2010 - 08:22:36 PDT

What would be the advantage vs. using the $system function of 20.18.1 ?

-- Brad

On Wed, Aug 18, 2010 at 7:56 AM, Wilson Snyder <wsnyder@wsnyder.org> wrote:

>
> 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.
Received on Wed Aug 18 08:23:07 2010

This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 08:25:49 PDT