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

I believe that this suggestion is not about $system, but about the fact that many tools know to ignore system tasks and functions, built-in or user-defined, because they begin with the '$'. If one were to enable DPI calls to be denoted by leading '$' then potentially one would not have to train these same tools to ignore DPI, they would do it implicitly.

Matt

--
Matt Maidment
mmaidmen@ichips.intel.com
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Brad Pierce
Sent: Wednesday, August 18, 2010 8:23 AM
To: sv-bc@eda.org; sv-cc@eda.org
Subject: [sv-cc] Re: [sv-bc] Idea to allow $system calls via the DPI
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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.