Subject: Re: [sv-cc] Oops - a possible problem with 2nd get/set user data proposal
From: Stickley, John (john_stickley@mentorg.com)
Date: Mon Mar 24 2003 - 11:41:00 PST
Francoise,
Oops ! I just thought of a reason your proposal may not
work.
Let me give an example:
Support an SV module calls an imported function "foo".
How in 'foo' do I access the allocated ID to fetch the
user data when the ID itself was stored with the user
data I'm trying to fetch ? !!
Example:
// imported function foo
void foo( ... ){
svScope scope = svGetScope();
MyCModel *me = (MyCModel *)svGetUserData( scope, ?? );
// ^
// What do I put here ? ------------------------------
// The ID will most likely have been stored in my
// local instance of MyCModel which is the pointer I'm
// ultimately trying to obtain !
}
Maybe I'm missing something here. Can you explain
what you had in mind to solve this ?
I think this illustrates why we may not be able to avoid
the calls to,
svScope fscope = svGetFunctionScope();
MyCModel *me = (MyCModel *)svGetUserData( fscope );
In this case the handle returned by svGetFunctionScope()
is the default current function instance scope structure
that only the infrastructure can possibly know. Do you see
what I'm getting at ?
-- johnS
John Stickley wrote:
> Francoise,
>
> You're probably right. And it keeps the explanation simpler.
> The only reason I suggested it was because it was compatible
> with the existing usage and with my proposal that allows one
> to retain the "per-module instance" user data attachment.
>
> But you're right. If applications want to use it in this way
> they simply call svGetUserDataIdForScope() once and use the
> same returned ID for all their imported functions called from a
> module scope.
>
> And end-user applications can do so knowing that they won't
> conflict with ID's used by IP models that may themselves have
> discreetly made their own call to svGetUserDataIdForScope()
> to allocate their own IDs.
>
> I like it !
>
> So, I guess by not special casing ID=0 we keep things really
> simple and don't lose anything. Do you agree ?
>
> Just to clarify, another reason I had suggested the reserved
> ID=0 was as a possible way of handling something you said in
> your original proposal:
>
> Francoise Martinolle wrote:
> > If no ID is used, the svScope user-data is a single whole entity
> which is
> > shared by all functions.
>
> I guess what we're saying now is that at least one ID is *always*
> used but applications which don't need per-function user data
> association can just share the same one ID. So really there's no
> such thing as using "no ID" is that correct ?
>
> -- johnS
>
> Francoise Martinolle wrote:
>
>> John,
>>
>> I think that your comment in this paragraph brings up the problem that
>> different users using the same id may get the user-data of each other.
>>
>> Therefore we should recommended that always the user application (whether
>> it is an IP provider of a regular user), requests a unique id from DPI
>> by calling the new function.
>> We don't need to reserve the id 0 for module scope, if the user
>> application
>> does not need different ids for all the functions, it just requests a
>> new id
>> and uses it for all its user data. Reserving 0 for module scope and IP
>> providers only is dangerous if you have 2 or more vendor ip instances
>>
>> in the same module scope.
>>
>>
>> This is the paragraph I am taling about in your write up.
>>
>> - While storage of user data for ID=0 can be combined with storage
>> for specific ID's, it is recommended that vendor supplied C
>> model IP always use allocated ID's and that only end-user
>> applications use ID=0.
>>
>> different
>>
>
>
--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 : Mon Mar 24 2003 - 11:43:39 PST