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 - 15:48:45 PST
> 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.
> 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.
With our soultion, some things are easier and more efficient than others.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Tue Apr 01 2003 - 15:50:08 PST