Subject: Re: [sv-cc] Re-proposed user data API
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 26 2003 - 13:43:20 PST
Doug, John, Team,
> DOUG:
> Andrzej's latest proposal seems like it will work,
Thanks! I hope so :-)
> but the essence of it is "for some memory savings [...]"
Yes, I favor "pay only for what you use" approach.
(Ok, I agree to pay taxes for the sake of common good :-)
> "[...] put the complexity of managing instance-to-instance
> inter-language connections squarely on the user's shoulders".
> I think this is in
> opposition to the "simple but powerful" spirit of DPI.
Quite contradictory. Simple yet powerful. Few functions. Anything can be
expressed that way and built upon those few primitives.
I cannot predict all users' needs so I don't even try.
Will user need data per function per instance?
One piece of data or more?
Will some functions need to share same data?
What type of data?
What if another application is built upon an existing one, such that it doesn't
add new imported functions to the design, yet it needs to associate its own
data with each instance?
etc., etc.
"the complexity of managing instance-to-instance inter-language connections"
I'm not sure I understand why one of two sets of functions shall be less
complex in use than another, whichever.
> void svPutUserData(svScope instance, int functionID, void* data);
> void* svGetUserData(svScope instance, int functionID);
void myPutUserData(svScope scope, DataKey key, void* userData);
void* myGetUserData(svScope scope, DataKey key);
Well, the only difference is that one of these two sets is provided by
DPI while the other is user-implemented. Big deal?
However, once you have them implemented, the usage of either set is identical,
isn't it?
It's hard to predict all possible needs of the future users of DPI.
The beauty of "separation of concerns" is that you don't need to know
everything upfront.
> From what I understand, others have objected to the fact that all
> nine user data (in our example) need to have static storage allocated,
> even if they are not used. I don't think that is a big deal.
> Several points here:
> a) What needs to be stored is very small, just 32-bits
> b) This is only for context import functions, not all import functions
> c) There won't be a large number of instances of declarative scopes
> containing context import functions. Even 100 would be an
> aggressively large number. 400 bytes storage across the simulation
> is not a lot.
> d) There won't be a large number of context import function
> declarations in any given declarative scope.
I have no clue how many instances may exist.
However, having worked with Verilog compiler, I've seen amazing examples
of designs. A function with 65000 arguments. Millions of instances. Millions of
generated functions. Any weird stuff one may imagine.
Would it be so unimaginable to define a simple cell, instantiate it millions
times, and yet import a couple of functions?
Context functions were invented mainly for sandwich calls SV->C->SV, so
they not necessary require own data per instance.
To be on a safer side (PLI/VPI permitted!), user may mark every imported
function as context, just for case. Maybe it will be called only from initial
block, so the overhead for 'context' will be negligible? Why not make
everything 'context'? So we may end up with context functions for millions of
instances.
All my painful experience teaches me to reject opinions like "There won't be
a large number of ..." immediately.
Sorry, Doug. You may be perfectly right, though. I simply don't know.
> 3. ID-based scheme.
> I believe the motivation here is to only have "pay-as-you-go" storage
> requirements for user data.
yes.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 26 2003 - 13:44:33 PST