Subject: RE: DirectC: C layer
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Dec 17 2002 - 11:53:23 PST
Joao,
Thanks, this last email clarifies a lot; I do like what you say but I found
your statements in contradiction with Andrzej's.
You say: "The SV implementation is free to choose whether providing
pointers to simulation objects or pointers to temporaries."
But Andrzej 's proposal I found:
>There will be no copying of arguments (other than resulting from coercing)
>Please recall item 10 from "17 items"!
>[10a: "xf must not modify the values of its input args'
> 10b: "The initial values of formal output args are unspecified and may be
> implementation dependent."]
>
>
>The actual arguments passed by reference by and large will be passed as
>they are, without changing their representation from the one used by a
>simulator.
>(Again, there are some exceptions, mainly for the 'open' alias 'unsized'
>arrays.)
>
>
>Therefore there will be no overhead on argument passing because no copying or
>translation between different representations will be required.
Then if the last sentence from Andrzej is true (" no copying or translation
between different
representations will be required"). Yes there may not be any copying or
translation by the SV
simulator but we would be doing the copying on the C side with the
canonicalization functions? The
overhead resides in the canonicalization get and put functions.
Andrzej provides 2 header files: directc.h and sverilog.h. The directc.h
provides implementation
dependent definitions. That is the vendor would provide the internal
representations of 2 state and 4 state values and the user code has to be
written that way.
I think that the only way we may not be doing any copying is IFF simulation
objects are
passed by reference ( a pointer to the simulation object value is passed to C)
AND the vendor simulator reveals the internal representation of such
simulation objects.
This may not be that simple. internal representation may defer depending on
optimizations,
net expansion, net bit sharing, port collapsing... and if you want to
enforce a certain
internal representation to be able to be accessed by the directC stuff, you
may have to give up
some things on the SV side (and you may loose even more on performance). I
think John Stickley suggested to provide a compile switch so that the C
programmer can instruct SV that
he wants to use directC internal representations otherwise he will not know
if he can use it.
Why not: define (as a standard) the representation of SV types on the C
side (like in Andrzej 's
proposal) and leave it to the simulator to make sure the values are either
internally represented as
in the directC API (for example this will be true for C like types) or will
be transformed to look like it
(for example for logic types). Why do we need the functions sv*put and sv*get?
Thanks,
Francoise
'
At 11:34 AM 12/17/2002 -0500, Joao Geada wrote:
>Francoise:
>
>You said
> > A direct memory interface may also restrict the optimizations on the SV
> side
> > since it reveals the internal memory layout which will need to stay stable.
>Please note that, with the proposed interface no such thing is required.
>It is *permitted*, not *required*.
>
>For output/inout ports passed by "reference", an implementation is free to
>choose whether it is providing
>pointers to datastructures inside the simulator or pointers to some
>temporaries. In either case the implementation
>has to propagate any changes made by the user into the simulator (for a
>direct pointer implementation this
>is "merely" invoking the propagation functions of the necessary signals,
>for an indirect pointer implementation,
>this means first copying out the new data and then propagating)
>
>As I have stated before, you are free to implement this whichever way you
>choose. It is even legitimate for
>an implementation to use both approaches for different types of data or in
>different usage modes. Note also
>that a user application really has no means of identifying which
>implementation approach is being used (other
>than perhaps by benchmarking).
>This works because, semantically, the interface relies on the following:
>1- user must *never* write to input ports (ie input ports are "const")
>2- propagation occurs *only* when a DirectC call returns
>These items ensure that, from the SV side, a DirectC call behaves the same
>as a SV function call
>(ie as-if pass-by-value had occurred).
>
>Joao
>
>==============================================================================
>Joao Geada, PhD Principal Engineer Verif Tech Group
>Synopsys, Inc TEL: (508) 263-8083
>344 Simarano Drive, Suite 300, FAX: (508) 263-8069
>Marlboro, MA 01752, USA
>==============================================================================
>
This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 11:54:01 PST