Subject: Re: [sv-cc] Perspectives from a "user" of the SV DPI C-layer
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Apr 02 2003 - 09:27:11 PST
John,
A couple of observations concerning outputs.
1. Predefined types byte, shortint, int, longint may be used to achieve
the desired convenience for small bit vectors.
For example, 'output int' will be passed as 'int*' and user won't be bothered
with canonical representation.
2. I don't think outputs are that common. Usually there is more inputs than
outputs. Single small output often may be replaced by a function result.
Similarly, I expect export functions to be less frequently used than import
functions. Either way (I mean your options), wide vectors may involve use
of canonical representation.
3. You may flip-flop inputs with outputs.
Note the direction of data flow:
input: caller --> callee
output: callee --> caller
The ability to call a function from either side allows to chose inputs or
outputs by calling a function from the appropriate direction.
Thus, export function with outputs may be replaced with import function with
inputs. In either case data will be passed from SV to C.
Specifically, export function may call import function only to facilitate
a more convenient way of passing arguments. Similarly for the other direction.
4. All packed types, regardless of size and direction are uniformly
represented as svBitPackedArrRefs (or svLogicPackedArrRefs), with small
inputs as sole exception.
I don't think that adding another exception for small outputs/inouts
would add more convenience than complexity, although this is a matter
of a subjective judgment.
Regards,
Andrzej
> 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 : Wed Apr 02 2003 - 09:28:22 PST