Subject: Re: Poll on ISSUE 1.1
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Dec 02 2002 - 15:26:00 PST
> From owner-sv-cc@server.eda.org Sun Dec 1 16:00:03 2002
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> Subject: Re: Poll on ISSUE 1.1
> To: mittra@juno.com
> cc: sv-cc@server.eda.org
>
> > I would like to put the proposals on ISSUE 1.1 on poll
> > and get a closure on them.
> >
> > There are two parts for the poll:
> >
> > a) Joao/John's proposal
> > b) Kevin's extension.
>
> My vote is:
>
> a) Abstain
> b) No
>
>
> Comment:
>
> I can see the convenience and the power of that new functionality (C calls SV),
> but I simply don't know whether the overhead overweights the benefits of
> the richer functionality, or other way round.
The primary target for C calling SV for me is the fork-join task stuff in
interfaces, i.e. I'd like to be able to hang C models off busses as well as
SV modules - maybe SystemC models.
Calling into SV is likely to be less troublesome than calling out since the
C data types are easily handled in SV (no abstract access required).
> I'm afraid of the performance consequences of allowing context-related calls
> from C. (My mindset is that of an implementor rather than of a designer.)
The only context is the module instance record - which is the same as for most
calls within the simulator kernel - no extra data needs allocated permanently
since C is going to pass data on the stack and SV tasks and functions are
pass-by-value (still). All you need is a single layer (function) to coerce
data to match the call the simulator would normally make to evaluate the task or
function. The impact would mostly come from having to disable inlining on
exported tasks and functions (if that would normally happen).
> Kevin was right that calling a SV function from an instance is similar to
> virtual function calls. Actually it's a bit more complicated, since neither
> compiler, C nor SV, will be able to statically determine whether a particular
> SV function is defined for a particular instance.
> So each SV instance will have to provide some info necesssary to verify
> whether a SV function is defined for such instance and where is its code.
> Note that code cloning resulting from optimizations (if not from module's
> parametrization) may cause instance specific addresses of the code.
Thanks! - please vote yes on (b) :-)
Regards,
Kev.
> Regards,
> Andrzej
This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 15:26:29 PST