Subject: ISSUE: cmodules vs. external "C" tasks
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Nov 06 2002 - 21:31:16 PST
Team,
I would like to formally create an issue surrounding
the notion of the viability of the DirectC "cmodule"
in our C API.
This issue was originally brought up on October 7th
in the email posting entitled "Technical Discussion
of DirectC". Since then (and especially today!) lots
more action has taken place on email.
I will copy a few excerpts from these mails as the
seed content of this issue. I hope we can discuss
it at the face to face meeting Thursday.
*** From Doug's posting October 7th ***
> Here are some observations on DirectC, along with
> some suggestions for using/modifying/abandoning
> particular features of the donation.
>
> *** DFLI features vs. modeling features ***
>
> DirectC is both a binding mechanism (DFLI) and a
> modeling medium. The special language constructs
> such as the event control statement are what I call
> the modeling medium. Some of the API calls fit into
> there as well. The "extern C" function syntax and
> "cmodule" syntax are the binding mechanisms. (DFLI)
>
> I would like to concentrate on the binding mechanisms.
> The modeling medium has capabilities that are redundant
> with SystemC and TestBuilder (and perhaps a few
> home-brewed C environments). I suggest it is out
> of the scope of SV to create C modeling semantics.
> If we were to create C modeling semantics, why not
> just use SystemC? It has support for hierarchy,
> multiple-driver resolution, channels, and a host of
> other interesting features. Or another C modeling
> facility out there? It doesn't seem like we should
> be making this kind of decision in the context of
> our charter.
*** From Stuart's posting on 10/24/02 ***
>
> 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++.
>
*** Andrej's posting on 11/06/02 ***
> There have been strong demands to add the capability to
> call a task from either of two languages, SV and a
> foreign language. Specifically, to be able to call
> SV tasks from C.
>
> IMO such mechanism is fully orthogonal to external modules.
> It will provide alternative means for synchronization.
>
> It's easy to observe that if C may call SV task and SV may
> call C task (i.e. a function that may block/wait/pass time),
> then the whole synchronization can be expressed in SV.
> Simple SV tasks may be defined in with wait, delay, etc.
> Such tasks can be then used on C side as synchronization
> primitives. So, C function would delay or wait by calling
> primitive SV task which contains the needed delay or wait.
>
> Resuming: external modules and external/exported tasks are
> two indepenedent and orthogonal mechanisms for synchronization.
>
> Are both these mechanisms needed or we will give up one of
> them and pursue only the other one?
>
*** Kevin Cameron wrote on 11/06/02 ***
>
> I'd say that between SV (with the enhancements tabled in
> the EC committee) and SystemC, "cmodule" is redundant
> functionality. If you can cross-call the callee
> probably shouldn't worry about who the caller is.
>
*** John Stickley wrote on 11/06/02 ***
>
> This is an intriguing idea. In fact, this is a nice
> solution for handling raw C environments where underlying
> kernel to kernel synchronization is not automatically
> handled or where the C environment does not even have
> a "kernel" per se.
>
> Each of these time advance primitives could essentially
> be task calls from C to SV and, voila ! You (as a user)
> have instantly created a time advance facility for C
> from scatch by just defining some simple SV primitive
> tasks. Nice idea.
>
> Alternatively in more sophisticated cases such as where
> you have say a SystemC kernel that is automatically
> synchronized with the SV kernel in the vendor supplied
> infrastructure, you would not need to use these primitives.
> You could then just have your "C task" use the native
> SystemC mechanisms for time advance.
>
> Either way the API itself does not get involved with
> time advance semantics.
>
> And, with this "C task" solution, we probably eliminate
> the need for c-modules altogether.
>
*** Andrzej wrote on 11/06/02 ***
>
> You are right that within the space of C++ based HDL-s
> "cmodule" is redundant functionality, definitely inferior
> to SystemC.
>
> But we are not talking about HDL in C/C++.
> We are talking about interface between SV and C/C++.
> IMO external module is a powerful and convenient
> mechanism for connecting "something" to SV. I don't care
> how it's implemented in C++. Perhaps SystemC could be
> plugged-in as an implementation of external modules?
> I'm focusing on the SV side of the interface. And from
> that perspective communication via ports seems natural
> and attractive.
>
More to follow on this ISSUE, I hope!
Regards,
Doug Warmke
This archive was generated by hypermail 2b28 : Wed Nov 06 2002 - 21:31:42 PST