Subject: Re: ISSUE:DirectC:DirectC i/f should support mechanism forcalling Verilog task/function from a DirectC application
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Oct 23 2002 - 10:35:31 PDT
Kevin,
Kevin Cameron x3251 wrote:
> > From: "Swapnajit Mittra" <mittra@juno.com>
> >
> > On Mon, 21 Oct 2002 17:30:56 -0700 "Warmke, Doug"
> > <doug_warmke@mentorg.com> writes:
> > Swapnajit,
> > Some brief comments on your proposal.
> > We can discuss more at the appropriate time in the meeting or in email.
> > >
> > > 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.
>
> The issue of elapsed time has to do with saving the C routine's
> call-stack i.e. if you call any C routine from the simulator kernel
> then you (usually) have to return from that routine to continue
> simulating. If the C routine calls a task that suspends it cannot
> return. The work-around is to not use the CPU stack for saving
> context (cmodule?) or use multiple stacks (which is usually very
> ineffecient because of the CPU context switching overhead [SystemC?]).
>
> That's why it's better to write your functions in SV rather than
> calling external C routines :-)
>
johnS:
Kevin,
I think the issue is more than just context switching.
In fact, that's not the difficulty. That by itself is a pretty routine
operation in all the new C++ kernels - TestBuilder, SystemC
and even non-C++ testbench modeling environments such as Verisity.
In fact, from what I've seen, for pure untimed multi-threaded
testbenches, these environments are pretty efficient (have
a look at systemc.org posting on some benchmarking I did:
http://www.systemc.org/hypermail/systemc-forum/1282.html)
They all seem to use a package called QuickThreads which is a very
efficient non-preemptive threading package. The place where
SystemC performance breaks down is when processing
bit_vectors rather than native machine types such as int or double.
But the 0-time issue is more than just context switching. It tends
to make it difficult to keep coherency between the time state
of the C++ kernel and that of the HDL kernel. By establishing
0-time "synchronization points" you can easily avoid this inconsistency.
-- johnS
>
> Kev.
>
> > Doug,
> >
> > I understand your concern. But, can not these C models
> > be written as cmodules (or be embedded within cmodules) ?
> >
> > 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.
> >
> > 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.
> > --
> > Swapnajit Mittra
> > Project VeriPage ::: http://www.angelfire.com/ca/verilog
--This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ 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 \ / Phone: (201)818-2585 \ / ---------
This archive was generated by hypermail 2b28 : Wed Oct 23 2002 - 10:42:00 PDT