Subject: Re: Pls. review and comment the requirements for a directforeignlanguage interface
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Aug 12 2002 - 11:32:56 PDT
> ....
> >
> > > We don't require the ability to call a Verilog function or task from the foreign code.
> > > The rationale is as follows.
> > > Verilog functions/tasks are usually defined within some context (module or interface scope)
> > > and may access non-local data (functions/tasks declared in $root are an exception).
> > > Hence a caller should provide the context of a call (e.g. a module or interface instance).
> > > In a non-Verilog part such context is simply not visible/available.
> > > The interface specification should not attempt to enhance the other
> > > programming language with new constructs for supporting Verilog.
> >
> > Agreed. Beware.
> >
> > > Usage:
> > > -----
> > >
> > > - the learning curve should be minimal
>
I posted a message a while back about using C++ with System Verilog, I suspect it went out before
everyone was on the reflector -
http://www.eda.org/sv-cc/hm/0005.html
The "context" for tasks in Verilog is much the same as a class instance in C++ and a task is like
a class method.
From a user perspective it's a lot easier if there is a defined translation of the Verilog calls into C++
and vice versa rather than the PLI/VPI approach of passing handles around. Since most Verilog is
compiled these days I don't think it would be too hard to supply that kind of interface.
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Aug 12 2002 - 11:35:06 PDT