Subject: Re: [sv-cc] Perspectives from a "user" of the SV DPI C-layer
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Apr 01 2003 - 17:01:59 PST
Andrzej,
Andrzej Litwiniuk wrote:
> > > 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.
johnS:
Yes this is a good inconsistency that is motivated by both efficiency
and ease-of-use. Being able to directly pass canonical form is really
nice for the user.
>
> 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"?
johnS:
What I mean here is that,
Option 1:
If you represent a small output vector
canonically and by reference, the internal implementation has to
assign from the internal representation to the user's svBitVec32
pointed to by the output arg ref.
One the other hand,
Option 2:
If you represent small output vectors as implementation specific
svBitPackedArrRefs, in order to be able to use the data, the user
has to assign from this representation to his own svBitVec32 by
calling svGetBits() anyway (which also does the same assignment
in option 1 - just explicitly).
It has to be done in either case anyway. So why make the user
do more work ? So, since it's a wash, why not choose that 1st
option to make things easier for the user ?
Furthermore, option 2 now requires an extra call to the
svGetBits() function (necessarily non-inlined since it is part
of the binary compatible svdpi.h) which option 1 doesn't.
therefore, there's actually more net overhead with option 2.
So, not only is it more difficult to use, it has more overhead !!
So what I'm saying is that the inconsistency between small_input/output
and large input/output is worth it for both ease-of-use and
efficiency reasons.
The inconsistency between "small inputs" and "small outputs" (i.e.
option 2) is definitely not worth it since it discourages both
ease-of-use and efficiency.
-- johnS
>
> Andrzej
>
--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 : Tue Apr 01 2003 - 17:04:09 PST