Subject: Re: ISSUE:DirectC:DirectC i/f should support mechanism forcalling Verilog task/function from a DirectC application
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Oct 23 2002 - 11:25:21 PDT
> From john_stickley@mentorg.com Wed Oct 23 10:37:06 2002
>
> Kevin,
>
> Kevin Cameron x3251 wrote:
>
> > > From: "Swapnajit Mittra" <mittra@juno.com>
...
> > 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)
Throughput depends on the ratio of context switching time to actual
model evaluation, most of the C/C++ activity is currently at the
testbench level (and cycle based) there aren't that many threads and
the models are complex. As a general approach to simulation it doesn't
work because a lot of the code is too short (from @/# -> @/#). Also
if you don't know the call-depth for the C/C++ then you have to
allocate a "big enough" stack for each thread which is inefficient
in memory (you'ld blow your 2G Linux limit fairly easily).
> 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.
I don't think the DirectC approach requires a seperate C++ kernel, so
it's less of a problem.
I'd prefer leave the topic of handling genuine parallelism and multiple
stacks etc. to the Enhancement Committee for a later rev of SV.
Kev.
> -- 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 - 11:29:16 PDT