Subject: RE: [sv-cc] Re-proposed user data API
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Mar 27 2003 - 08:24:47 PST
Doug,
This approach only allows to associate user_data to function scopes.
How do you share a user_data between multiple function scopes, between all
imported
functions in a single SV scope? do you store it in a static variable of the
Cmodel class.
I thought it was desirable to also have a common user_data for a module scope.
how would you create one single user_data for an entire application if that
application
does not get invoked through SV code but is rather an autonomous parallel
application
which would call SV exported functions.
Francoise
'
At 02:17 PM 3/26/2003 -0800, Warmke, Doug wrote:
>4. Hybrid ID - Function scope approach
> In a way, approach #2 (function scopes) is almost like an ID scheme.
> If we changed that approach to:
> int svGetFunctionID(svScope instance, const char* funcName);
> void svPutUserData(svScope instance, int functionID, void* data);
> void* svGetUserData(svScope instance, int functionID);
>
> Then we have an ID scheme, and there is no confusion with overlapping
> scope concepts. The only drawback is that it's not "pay as you go".
> But consider the mitigating points discussed in 2. above. This is
> already far better than VPI, in which user data must be accessible
> at every call site. There can be many more of those than context
> import function declaration scope instances.
>
> Now, an additional improvement became clear as I was recoding John's
> example below to make use of this approach. In most cases, the
> desired functionID is directly associated with the name of the
> context import function in which C code is running. Rather than
> requiring storage and retrieval of a functionID for such cases,
> we should reserve functionID 0 to denote the functionID of the
> currently executing context import function. This makes John's
> example below much simpler, as I hope you will agree.
>I don't like the idea of using function id 0 to refer to the current
>function ID.
>Since the user requested the ID, he should remember it and use it instead
>of putting the burden on the simulator to have to remember the ID of the
>function
>executing. In the later case, the simulator has to keep the association
>between ID and
>function_name/instance pair.
>
>DOUG: If you look carefully in the example I recoded to use this approach,
>you will see that this is just a short-cut that allows a user *not* to
>request
>a function ID for simple cases. Please check it out. In any case in this
>proposal,
>the simulator always has to keep static ID's around, generated at
>compile/elab time,
>that key individual context import function declarations in a given scope.
>
>Francoise, can you send me your phone number? I'd like to try and talk
>you through this proposal. It's a complex topic, but after thinking
>carefully
>about it for many hours I think I have a handle on it.
>
>Regards,
>Doug
>
This archive was generated by hypermail 2b28 : Thu Mar 27 2003 - 08:25:35 PST