Subject: Re: ISSUE:DirectC:DirectC i/f should support mechanismforcalling Verilog task/function from a DirectC application
From: Stickley, John (john_stickley@mentorg.com)
Date: Thu Oct 24 2002 - 16:13:32 PDT
Stuart,
Some very interesting perspectives you state here that have,
at least for me, provoked a lot of thought.
I have some reponses to at least some selected issues you
raise. I'll probably have more to follow.
Stuart Swan wrote:
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++.
johnS:
I shared this opinion somewhat. But, in addition to finding the syntax
somewhat cryptic - as if learing a new "3rd" language for
concurrency modeling, my real reason for being lukewarm on c-modules
is more because it is a re-invention of capability that already exists
in some of the emerging C++ modeling environments, notably
SystemC, and maybe to some extent TestBuilder.
I question whether it should really be the charter of the SV-CC group
to re-invent yet another way of modeling concurrency and time
consumption on the C side.
It seems more prudent to provide just a simple, concise coupling
interface in the form of zero-time function calls that essentially
provides synchronization points between two threading systems.
Time consumption can always easily be modeled by providing
a pair of time separated 0-time calls rather than a single time
consuming function call.
That way for example a SystemVerilog process could make a zero-time
call to a C process to initiate some time consuming operation
on the C side then wait for a 0-time C to HDL call (or "callback"
I should say) to indicate the operation is complete.
As such, the SystemVerilog kernel makes no assumptions about how
the C kernel works or vice versa. In fact there may not even
be a "C kernel". The C side could just be a dumb single threaded
main that does a bunch of serial tasks and leaves.
Or it may not even be that. It may just be a collection of
disjoint functions that get called, perform localized operations and
return.
And if there *is* a C kernel it may be unified with, tightly coupled
with,
or loosely coupled with the HDL kernel. It should not be the mission
of the DirectC interface API to worry about that. Rather the
tool vendor should worry about it.
Vendors may chose to tightly integrate say a SystemC kernel
with their HDL kernel so they are literally one in the same thing.
Or they may chose to do something like TestBuilder did where
basically they're "joined at the hip" the same Unix process and
cooperate, but still as separate kernels.
Or some vendors may chose the opposite extreme where the C kernel
and the HDL kernel are literally separate UNIX processes.
All of the above should be possible and the DirectC interface should
not discourage or encourage any of those scenarios.
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.
johnS:
Hear, hear !
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.
[...]
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.
johnS:
You've hit the nail on the head about what user's want.
The good news is that its already being worked on in the
form of SystemC and others. Let's not attempt our own
version.
Furthermore, remember that users require that the above concepts
cleanly interoperate across the C/C++ - HDL boundary.
johnS:
Might it be the case that 0-time function calls will naturally allow
this such
that the API itself is neutral to the C/C++ environment - threaded or
otherwise ?
-- johnS
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com <mailto:John_Stickley@mentor.com> \
/
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Thu Oct 24 2002 - 16:16:51 PDT