Subject: Re: ISSUE:DirectC:DirectC i/f should support mechanism for calling Verilog task/function from a DirectC application
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Oct 23 2002 - 14:56:27 PDT
Swapnajit Mittra wrote:
> >
> > o If an external C function calls a Verilog task, no
> > simulation time must elapse during the execution of that task.
> > (This is, because a C function in DirectC is a zero-time event).
> > However, no such restriction shall be in place when a Verilog
> > task is called from a cmodule.
> >
>
> I think this is overly restrictive. It will not work out well if
> some implementations want to directly integrate C models
> living in a threaded environment (e.g. TestBuilder, SystemC)
> together with HDL models. Let's keep an open mind
> about making large scale changes to DirectC.
>
> Doug,
>
> I understand your concern. But, can not these C models
> be written as cmodules (or be embedded within cmodules) ?
DOUG: Perhaps they could. I'd like to know if you have some
specific reasons for not wanting time to be able to elapse
inside of external C functions (besides those you listed below).
That could help me understand where you're coming from better.
>
> I think (Joao, correct me if I am wrong) a DirectC
> external C function and a cmodule to some sense
> are analogous to a Verilog function and task respectively.
> External C functions are 0-time activities whereas
> cmodules are not.
DOUG: In my mind, a C function is analagous to either
a Verilog function or task. A Cmodule is analagous to
a Verilog module.
What we're creating here is an interface. I believe that
any implementation which does not have an integrated,
threaded C modeling facility should not allow time to
elapse inside of external C functions. As Kevin said,
there would be no way to return control to that function
in the appropriate place.
However, we shouldn't have this interface rule out the
possibility that some implementations might like to
provide integrated coexistence of C and HDL models.
By restricting external C functions to perform in zero time,
we would be ruling out the implementation of procedural
C<->HDL co-existence. Also, if you buy into the analogy
between Verilog tasks and external C functions, then naturally
you would want C functions to be able to suspend time,
as can Verilog tasks.
You have noted that DirectC Cmodules do have constructs
to perform threaded C operations. ( '@' statement, delay
function call.) As I mentioned earlier, DirectC's C modeling
facilities appear to be rather limited compared to those present in
SystemC or TestBuilder. Another thing that is slightly unusual
is that the kind of C code one can write inside of the DirectC
functional interface is different from the kind of code one can
write inside a C module. This lack of orthogonality might be
tough on some users.
I would prefer to omit the DirectC *modeling* facilities
from SV 3.1 and mainly concentrate on the definition
of the inter-language interface.
That would allow more time for us to hash out the C modeling
issues. Also, given our short time frame, it will be easier to
get consensus on the interface.
Obviously the above is a pretty bold statement - please feel free
to jump in and have at it (or me!) everyone.
>
> I would not mind if we change that proposition (that DirectC
> external C functions should be 0-time activity), but my
> concerns there are
>
> o Whether that will break any other basic structure of the
> whole scheme.
>
> o Whether we have sufficient time to undertake this type of
> fundamental changes. Personally I think we should rather be
> late than producing things that are half cooked, but I know
> we are working under some tight schedule here.
DOUG: I would prefer to omit things from SV 3.1 that we feel
are half cooked, and concentrate on producing things that have
value and are fully cooked. That actually reduces our workload,
and makes sure that what we produce will remain valid for a
long time to come.
Thanks for the discussion Swapnajit and others - we are starting
to get some technical traction and that is a good thing.
Regards,
Doug
P.S. To Kevin : Have you looked at the performance of QuickThreads?
It might be pretty surprising. It's possible that it's as fast at switching
user model processes as the speed of native HDL simulators
switching user model processes. (I haven't personally measured this,
but I did eyeball the QT assembly code, which looks lean and mean.)
Clearly writing everything in SystemVerilog has some advantages,
but there are still lots of people out there who would prefer to
write certain kinds of code and tasks in C. For those people, we
should do a good job at providing inter-language communications.
This archive was generated by hypermail 2b28 : Wed Oct 23 2002 - 14:58:14 PDT