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: Wed Oct 23 2002 - 17:31:17 PDT
> 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 - 17:35:07 PDT