Subject: RE: ISSUE:DirectC:DirectC i/f should support mechanismforcalling Verilog task/function from a DirectC application
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Oct 24 2002 - 15:38:34 PDT
> From stuart@cadence.com Thu Oct 24 14:26:33 2002
>
> Kevin, others-
>
> Here are some answers to your questions...
>
> Thanks
> Stuart
I think we need to step back a bit.
There are two kinds of threads we need to think about:- those with
a volatile stack (kept by the CPU hardware), and those with no stack
or a non-volatile stack for handling routine calls.
Traditional simulators tend to implement the call stack by creating
structures in memory rather than using the CPU stack (the last VHDL
simulator I worked on did). SystemC does not use a special compiler
so it can't do that and is therefore forced to use a (OS) light-weight
process (LWP) to maintain the stack for threads that call routines
that suspend.
I think it is possible to support both types in SV, but I think it's
an Enhancement Committee decision to add support for LWPs (as an
extension of the process statement?). Automatically creating LWPs so
that a user can randomly call back and forth from SV to C seems like
a bad idea to me. LWPs should be considered when the EC committee
looks at semaphores (from the testbench donation), channels, and
process control.
I think for simplicity (and the time being) it should just be illegal
to suspend from a C/C++ routine or an SV task called by a C/C++ routine
originally called from SV. Similarly you would not be allowed to call
SV functions that can modify simulation kernel data from non-kernel
LWPs. That doesn't preclude running SystemC in seperate LWPs, it just
limits how much direct access it has.
Kev.
> >
> > 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 tochecking
> 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 - 15:39:04 PDT