Subject: RE: ISSUE:DirectC:DirectC i/f should support mechanismforcalling Verilog task/function from a DirectC application
From: Stuart Swan (stuart@cadence.com)
Date: Thu Oct 24 2002 - 14:27:50 PDT
Kevin, others-
Here are some answers to your questions...
Thanks
Stuart
>
> If the simulation kernel calls Verilog which calls C which
> calls Verilog
> which tries to suspend (e.g. #0;), the kernel has to suspend the whole
> thread process in order to preserve the C's call stack and
> (in order to
> continue) create a new LWP thread. You could use a lot of
> system resource
> doing that and it adds a lot of complexity to the kernel (you need a
> reentrant event queue manager - which will also be slower).
>
It is important that everyone realize that with the current Cmodule
capability in the current DirectC donation we already are talking
about having threads/processes in C/C++ that have their own quickthreads
stack, and these C/C++ threads/processes already need to have the
ability
to perform event notifications to the Verilog side, wait on Verilog
events, etc.
So if the current proposal already allows true C/C++ processes that
can suspend execution based on events/time, etc., what fundamental
capabilities we talking about adding in the current discusion?
I'd say:
1) Ability for a C/C++ process to call a normal C/C++ function/method
and have that function/method suspend execution, possibly waiting
on some Verilog event. (This is useful for example in protocol
modeling in C/C++.)
2) Ability for a C/C++ process to call a Verilog task and have that
verilog task suspend execution on some event.
3) Ability for a Verilog process (always block, etc.) to call a
normal C/C++ function/method and have that function/method
suspend execution, possibly waiting
on some Verilog event. (This is useful for example in protocol
modeling in C/C++.)
I should note that I find the current "cmodule" stuff very distasteful
since it is neither Verilog nor C/C++, but a strange mixture of the two.
No doubt the current implementation recognizes some of the strange
Cmodule
keywords and syntax, and similar to the C-preprocessor, converts it all
into normal C++ for compilation. A far better solution is to just stick
with C++ in the first place, since then the C/C++ code can then be
compiled,
debugged, linted, and understood by normal tools & users. I don't see
anything in the current proposal that cannot be cleanly and concisely
modeled in C++.
Now then, what about all this business related to preserving stacks
when various types of processes suspend, and when Verilog calls C
and vice-versa?
First, forget about modules and so forth, and focus on _processes_.
A process is an independent "thread" in a language such as Verilog,
VHDL, and SystemC. (In Verilog a process is represented by always
blocks,
continuous assigns, etc. In VHDL, processes are, well, processes. In
SystemC, processes are SC_METHODs and SC_THREADs.)
In SystemC, similar to the current Cmodule proposal, SC_THREAD processes
get their own quickthread stacks, and so they can call functions that
can suspend. Doesn't matter if the "function" is in C/C++ or happens
to be a Verilog task or VHDL procedure.
In SystemC, there are also SC_METHOD processes, which don't have their
own stack, but which "borrow" a stack everytime they are activated, and
then must relinquish the stack when they suspend. Such processes cannot
call C/C++ functions that might suspend, or Verilog tasks/VHDL
procedures
that might suspend. (SC_METHODs are in SystemC
for efficiency only -- otherwise SC_THREADs would be sufficient.)
What happens if an SC_METHOD process _does_ call
code that tries to suspend? No problem, its just caught at simulation
time.
The check is simple -- the code in the kernel that suspends a process
just
checks to make sure that process is allowed to suspend. (Akin to
checking
a single bit each time a process suspends.)
In VHDL, _conceptually_ every process has its own stack so every process
is allowed to call code that might suspend. Most VHDL simulators
optimize
in a number of ways, e.g. recognizing processes that don't actually
require their own stacks. In addition, if a process does need a stack,
a normal C/C++ style stack is normally not used since it is too
expensive
in space. But this is all implementation detail, and doesn't change
the fact that VHDL processes, as defined by the language, can call
any code, be it VHDL/Verilog or C/C++, that might suspend.
Verilog, as we all know, is a strange beast indeed. Prior to the
introduction of automatic variables and "reentrant tasks", Verilog
processes really had nothing akin to a stack. With the introduction
of reentrant tasks and automatic variables in Verilog 2001, Verilog
now looks a lot more like VHDL, at least when these features are used.
So the discussion above about VHDL all applies to Verilog 2001 and
later.
So, let me now make a few simplifying assumptions:
1) We abandon DirectC/"Cmodules" etc. and use SystemC for modeling
processes in C++. We would gain a lot by doing so.
2) Users can create both SC_METHOD and SC_THREAD processes in C/C++.
SC_METHOD processes would not be able to call C/C++/Verilog
code that suspends, as described above.
3) Verilog processes can directly call C/C++ functions. To enable
high performance, by default Verilog processes are seen
as SC_METHOD processes from the C/C++ side, meaning that C/C++
code called from Verilog processes cannot suspend by default.
4) If a Verilog process needs to call C/C++ functions that might
suspend, we provide one or more ways for the user to indicate this.
This could include annotating an attribute on the process, or it
could include some sort of attribute associated with the declaration
of the C/C++ function. When a Verilog process calls C/C++ code
in this scenario, it creates a quickthreads stack to hand to the C/C++
code, or it just grabs a previously cached quickthreads stack
associated with the process instance. (Thus the quickthread stack
creation only needs to be done once for each process instance, and
only if the Verilog process instance calls C/C++ code that might
suspend.)
I think this scheme cleanly and simply handles the scenarios
that we wish to support above, and "has room to grow" into
the future.
>
> How do you catch that a C routine is not allowed to suspend?
>
See above.
> >
> > One peculiar thing to me about this discussion is the lack
> of commentary
> > from the Synopsys folks on why the SystemC approach, and
> the many of the
> > benefits that SystemC provides, are not being leveraged in the
> > current discussion related to the SystemVerilog C/C++ interface.
> > Was the SystemC approach investigated and rejected for
> technical reasons,
> > or has it just not been investigated yet?
> >
> > -Stuart
>
> A good question, however if we provide a direct C/C++
> interfaces you should
> be able to use your SystemC code as is, so maybe it's a
> redundant discussion :-)
>
I hope you're joking. Consider that users want to be able to
cleanly model the following in C/C++:
1) Design structure
2) Concurrency
3) Time
4) Communication/synchronization via signals, FIFOs, mutexes, events.
5) Various forms of parameterization
6) Ability to model HDL types (e.g. logic vectors) in C/C++, and
ability to easily pass such HDL types and
complex types between C/C++ and HDL.
Furthermore, remember that users require that the above concepts
cleanly interoperate across the C/C++ - HDL boundary.
This archive was generated by hypermail 2b28 : Thu Oct 24 2002 - 14:28:31 PDT