Subject: Re: [sv-cc] Perspectives from a "user" of the SV DPI C-layer
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Apr 01 2003 - 16:29:13 PST
> > We need to strike a balance between simulator flexibility in representing
> > data, run-time performance not impaired by inherent copying which may be
> > unnecessary, and finally, ease of use.
>
> johnS:
> The inconsistency between saying small value input bit vectors use
> canonical form but small value output vectors don't, bothers me.
There are orthogonal axes here: small-large, by_value-by_reference.
Some inconsistency seems unavoidable.
For inputs there is inconsistency between passing some values by_value
and passing others by_reference. Passing by_value is a sort of an exception
motivated by the effciency.
For outputs/inout we are consistent: everything is passed by_reference
(svBitPackedArrRef or svLogicPackedArrRef) regardless of size.
Should we treat small values consistently (i.e. they will always use
canonical representation svBitVec32: 'const svBitVec32' for inputs,
'svBitVec32*' for outputs), then outputs will be treated inconsistently,
although always passed by_reference, different types would be used.
> I personally think for small vectors the copying overhead concern is not
> worth the insconsistency for what is gained. The overhead has to be paid
> somewhere. Either the user transfers the 32 bits using a part select
> function outside the call or the implementation wrapper does it internally.
> Since it's a wash, why not err on the side of ease-of-use and let the
> implementation do it thereby keeping consistency ?
>
> -- johnS
Consistency of what? "small_input/small_output" or "all outputs"?
Andrzej
This archive was generated by hypermail 2b28 : Tue Apr 01 2003 - 16:30:04 PST