Subject: Re: ISSUE:DirectC:DirectC i/f should support mechanism for calling Verilog task/function from a DirectC application
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Oct 23 2002 - 09:50:22 PDT
> From mittra@juno.com Wed Oct 23 01:14:48 2002
>
> On Mon, 21 Oct 2002 09:55:02 -0700 (PDT) "Kevin Cameron x3251"
> <Kevin.Cameron@nsc.com> writes:
> > > From owner-sv-cc@server.eda.org Sat Oct 19 20:56:07 2002
> > > X-Original-From: "Swapnajit Mittra" <mittra@juno.com>
> > > To: sv-cc@server.eda.org
> > > cc: mittra@juno.com
> > > Subject: ISSUE:DirectC:DirectC i/f should support mechanism for
> > calling
> > > Verilog task/function from a DirectC application
> > > From: "Swapnajit Mittra" <mittra@juno.com>
> > >
> > > ISSUE:DirectC:DirectC i/f should support mechanism
> > > for calling Verilog task/function from a DirectC
> > > application
> > >
> > > [...]
> > >
> > > o The called Verilog task or function can be specified from
> > > the DirectC domain by Verilog full pathname. (This will
> > > allow us to call a specific Verilog task or function in
> > > the design hierarchy. We need to think about the actual
> > > syntax of this).
> >
> > I would suggest considering module instances as being like class
> > instances in C++. You could get the handle to a module instance
> > using the standard PLI mechanisms and then use it in C++ as a
> > class instance pointer with the tasks and functions of the module
> > as virtual functions.
> >
> > Doing this stuff in C rather than C++ is awkward because C doesn't
> > support overloading of names, so you would have to come up with
> > some name mangling scheme.
> >
> > Kev.
> >
> > PS:
> > Previous post - http://www.eda.org/sv-cc/hm/0005.html
> >
>
> Kevin,
>
> I like what you are proposing. I have few concerns:
>
> o I believe we should not depend on a PLI feature
> in order to implement a DirectC mechanism. IMHO,
> these two mechanisms, as far as possible, should be
> independent of each other.
We can't deprecate the PLI, so I think we would be wasting
time trying to engineer a replacement which would have to
co-exist.
If I did want a new mechanism (for C++) I would probably
just convert the VPI methods to C++ virtual functions.
> o If we need to get a handle to a module instance etc.,
> that may confuse people who only plan to use the
> direct access.
Cross-calling and navigating the hierarchy are often
seperate activities i.e. you find the various modules
(handles) at startup and hang on to them for later
when you need to cross-call.
> o As you have mentioned, we can not ignore people
> who will be using only C. (Let us not give them the
> impression that this is actually Direct"C++" :-).
Note: if you call C++ from SV you could use the calling
object handle as "this" for call-backs etc.
For C use the object handle can usually be decoded as
a function table pointer and data reference e.g.:
Verilog
module foo;
task t1
...
endmodule
Called from C++
mod_inst = find("top.f1"); // user func.
mod_inst->t1(); // call task t1
C equivalent
(*mod_inst->fn_table[foo__t1])(mod_inst);
> May I propose this:
>
> DirectC will provide a built-in function (for both
> direct and abstract access)
>
> dc_call_vlog_tf(&return_val, "verilog_full_pathname");
>
> The function dc_call_vlog_tf() will essentially implement
> your scheme, but will hide the details from the end user.
> The &return_val will be a NULL pointer for tasks.
>
> Comments ?
For effeciency you want to split that - doing a look-up on the
instance path on every call isn't going to be fast.
Note: using C++ virtual functions makes the methods unique to
the instance. If your simulator is actually a conglomeration
of kernels (e.g. SuperLog,VCS,Vera,Nanosim) then each kernel's
instances can have different implementations of the methods
without the name-space collisions you would get with C.
Regards,
Kev.
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
This archive was generated by hypermail 2b28 : Wed Oct 23 2002 - 09:59:12 PDT