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 - 16:05:05 PST
Andrzej,
Andrzej Litwiniuk wrote:
> > There was a gap in my understanding of the C-layer that I
> > feel much better about. Read on ...
>
> John,
>
> The proof of pudding is in eating. If there was a gap in your
> understanding,
> or if you got confused, there is only one explanation of it: our LRM in not
> clear enough. Sigh.
johnS:
No, I don't think that's the problem. I had just forgotten
about this section and had not read it recently. I think A.7.7
is stated clearly enough. At least for inputs.
Outputs - a different matter ...
>
>
>
> > Sure enough it states it quite plainly in section A.7.7.
> > My apologies ! I was going to suggest this change but was hesitant to
> > rock the boat. This is great news and my misunderstanding.
> >
> > Common sense would dictate this - I guess I should have realized it !
> >
> > I see where the same applies with output arg values am I correct ?
>
> Unfortunately not.
> And, what is much worse, LRM is not quite clear about it.
> It takes a good deal of exegesis to figure out the right type:
>
> 7.1. "Actual arguments passed by reference typically are passed
> without
> changing their representation from the one used by a simulator."
>
> 7.4. "For arguments passed by reference, their original
> simulator-defined representation shall be used and a reference
> (a pointer) to the actual data object is passed. [...]
> packed arrays can also be passed using generic pointers void*
> (typedefed accordingly to svBitPackedArrRef or
> svLogicPackedArrRef)."
>
> The right type for 'output bit [31:0]' in SV will be 'svBitPackedArrRef"
> in C.
>
> The rationale is that no specific representation shall be assumed for
> bit[31:0]
> nor representation change & copying required.
>
>
> > The only difference is that we use canonical form by reference right ?
> > So, if I have an output arg it would be like this:
> >
> > extern void GetCRC( svBitVec32 *crc ); /* output bit [31:0] crc */
> >
> > Is that right ?
>
> No. svBitPackedArrRef as explained above.
> However, 'int *' would be used for 'output int' in SV.
>
>
> > [...] This alleviates my concerns considerably for
> > small value bit vectors.
>
>
> 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.
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 ?
>
> With our soultion, some things are easier and more efficient than others.
>
> Regards,
> Andrzej
>
-- johnS
__
______ | \
______________________/ \__ / \
\ 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 - 16:06:31 PST