Subject: RE: ISSUE:DirectC:DirectC i/f should support mechanismforcalling Verilog task/function from a DirectC application
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Oct 23 2002 - 18:03:49 PDT
You catch it at runtime when it tries to suspend. It would be difficult to
catch it at analysis.
At 05:31 PM 10/23/2002 -0700, Kevin Cameron x3251 wrote:
> > From: "Stuart Swan" <stuart@cadence.com>
> >
> > (Oops, sorry - hit the SEND button too soon on the previous email... )
> >
> > It's nice to see some "out of the box" technical discussion related to
> > the C/C++ integration issues, though it concerns me that there seems
> > to be a recurring warning from some that "We can't think about more
> > general
> > approaches, since that will put our tight schedule at risk." It seems
> > to me that this kind of approach will only result in a lousy standard.
> >
> > I'm in general agreement with the comments from John Stickly about what
> > C/C++ modeling is good for, and what sort of performance can be
> > obtained.
> > Certainly at levels of abstraction above the RTL level (but often times
> > still
> > at the cycle accurate level) very high performance can be achieved. For
> > example,
> > a number of companies today are performing cycle accurate modeling
> > of platforms consisting of processors (ISS models), busses, peripherals,
> > etc, in SystemC and getting 50K - 100K cycles per second on typical PCs.
> >
> > Don't believe me? See (and hear, with audio):
> >
> > http://www.systemc.org/projects/sitedocs/document/ARM1/
> >
> >
> > I don't buy the argument that allowing C/C++ to suspend execution will
> > dramatically complicate the interface, or that it will be too slow or
> > too expensive in memory.
>
>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).
>
> > The obvious approach (which is already used in SystemC) is to have two
> > types of functions that the scheduler can invoke. The first type is
> forbidden
> > from suspending execution. Thus it doesn't need a separate stack.
> > If such a function tries to suspend execution, it's an error caught at
> runtime.
>
>How do you catch that a C routine is not allowed to suspend?
>
> > The second type can suspend, so it needs a C-style stack, courtesy of
> > quickthreads.
> >
> > In fact, I believe the DirectC stuff uses the exact same approach for
> Cmodules,
> > which also rely on quickthreads stacks.
> >
> > 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 :-)
>
>Kev.
>
>
> > ____________________________________________
> > Stuart Swan, Senior Architect
> > System Design Verification Group
> > Cadence Design Systems
> > Building 11
> > 2670 Seely Avenue
> > San Jose, CA 95134
> > Phone +1 408 895 4579
> > Email stuart@cadence.com
> > ___________________________________________
> >
> >
> >
This archive was generated by hypermail 2b28 : Wed Oct 23 2002 - 18:07:33 PDT