Subject: Re: [sv-cc] Modified Get/Put User Data Proposal - function vs. mo dule scope
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Mar 21 2003 - 13:06:08 PST
Andrzej, John,
I think that there is a difference between the module scope and
the function scope. The function scope is used to be able to associate a
specific user-data
area to a function call, while the module scope can also be used for the
user-data and also to change scope.
I would suggest to create user-data scopes differently and not associate
them with function
names (which seems to be of concern to Andrzej). Why don't we create a new
DPI function which would request an ID. This new DPI function could be used
to be able to associate user-data to a specific id within a normal svScope.
Conceptually the scope user area will be partitioned in several pieces,
each one of them
will be given an id. An imported function will be able to store some
user-data in the svScope
at a particular ID location.
Example:
(int)svGetNewIdForScope( svScopeHdl); this functions returns an id inside
a scope.
This id should be called by the imported C function at init time and saved
for future use.
The function svPutUserData and svGetuserData takes an additional argument
which is the id.
void svPutUserData(const svHandle scope, void* userData, int id);
void* svGetUserData(const svHandle scope, int id);
If no ID is used, the svScope user-data is a single whole entity which is
shared by all functions.
We don't need svGetFunctionScopeFromName and svGetFunctionScope.
Francoise
'
At 01:32 PM 3/21/2003 -0500, Stickley, John wrote:
>Andrzej,
>
>I don't have time to give a thorough response to you
>e-mail today but let me at least give some quick
>comments. I'll follow with the rest by Monday.
>
>-- johnS
>
>Andrzej Litwiniuk wrote:
>> > svScope svGetScope();
>> > void svPutScope(const svScope scope);
>> > svScope svGetScopeFromName(const char* instancePath);
>> > void svPutUserData(const svHandle scope, void* userData);
>> > void* svGetUserData(const svHandle scope);
>> >
>> > To remedy this situation, I'm proposing what I think
>> > is a pretty simple, efficient solution.
>> >
>> > Basically we add 2 new functions to compliment
>> > svGetScopeFromName() and svGetScope() respectively:
>> >
>> > svScope svGetFunctionScopeFromName(
>> > svScope moduleScope, const char *cname );
>> > svScope svGetFunctionScope()
>> >
>> > With these functions, a handle can be returned that
>> > represents a specific function of a specific module
>> > instance as an alternative to a handle representing
>> > just the module instance itself - though the latter
>> > will still be supported.
>> > -- johnS
>>
>>John,
>>
>>I'm a little concerned with the result type of the function
>>svGetFunctionScopeFromName().
>>What does exactly mean "specific function of a specific module instance"?
>>Is it meant solely as a unique key or as an instance? If an instance, then
>>an instance of what?
>
>johnS:
>It is an instance of a module calling a specific function.
>It is a way of, with essentially 1 key, identifing a particular
>instance of a module calling a specific function and letting
>the user associate that combination with his or her own
>data (c-context) pointer.
>
>>Are "function scope handle" and "module handle" similar or different?
>>Should both be of the same type? Can they be used in the same context?
>>I suppose NOT.
>
>johnS:
>They are different and function scopes cannot be used
>where you do an svPutScope(). But they can be used where you
>do an svPutUserData() interchangeably with module scopes. In
>object oriented terms you can think of them being different
>but having a common derivation ancestry or "is a" relation
>with a common parent class.
>
>For example the implementation may chose to define a "class scope"
>then have classes derived from it called "moduleScope" and
>"functionScope".
>
>The svScope itself however can be polymorphically interpreted
>as (i.e. downcast to) a pointer to the base class 'scope'. It
>can use common polymorphic access techniques such as virtual
>functions, class type tagging, etc. to identify which type
>it is and to therefore know what it can and cannot to with it.
>
>The reason I wanted to overload the same svScope for both
>of these purposes is that it reduces the total number
>of functions, data types, and complexity needed in the interface
>thus making things easier for the user.
>
>It is analogous to how vpiHandle is a "one-serves-all" handle
>in the VPI interface. In this case svScope does not "serve all"
>but it does serve function and module scopes.
>
>>Is a scope returned by svGetFunctionScopeFromName() a legitimate module
>>scope? Can it be used as an argument for svPutScope()?
>
>johnS:
>No. Passing a function scope here should cause an error.
>
>>svPutScope sets the scope to be used by an exported SV function.
>>Which instance will be used if a scope is set to "function scope"?
>>It is possible, of course, to map unambiguously a function scope onto
>>a module scope (but not other way round!). Is it what you intended?
>>You intended to use either of those two categories of handles
>>as an argument to svPutUserData(); as in your example:
>> > svPutUserData( funcScope, this );
>> > svPutUserData( dSvScope, this );
>>If, however, both types of handles, "function scope" and "module scope"
>>cannot be used in the same context, then they are apparently two different
>>types.
>
>johnS:
>But they both derive from 'scope' as explained above so, a typical
>application will chose one or the other depending on what it's needs
>are. This adds to the flexiblity of the interface since now you
>can store data at the module instance level or at the function instance
>level. Which solves the basic limitation we identified in the meeting
>of only supporting module instance association with user data.
>
>>If so, then svPutUserData()/svGetUserData() will have to be split into
>>two versions, for functions and for modules. Not big deal.
>
>johnS:
>I would prefer to avoid this. I think it is overkill and unecessary.
>
>>
>>I've been trying to figure out what kind of support may be needed
>>from SV compiler for the above functionality. What will have to be done
>>at a call of imported a function and what kind of data will have to be
>>provided to support run-time (i.e. simulation).
>>This is pretty obvious for supporting modules scope and svGetScopeFromName().
>>I couldn't figure out where exactly function names may be involved
>>(other then for veryfying the correctness).
>>If SV compiler statically reserves/allocates space for "function scope"
>>(have we agreeed upon restrictions, which modules, which functions?),
>>then function names will matter. Static scheme means memory overhead.
>>If, however, a dynamic scheme is used instead of a static one, than
>>a function name will be no more than a unique key solely, and actually any
>>unique string will do! It is merely a convenient coincidence, that C
>>functions names must be unique and therefore may play the role of unique
>>keys.
>
>johnS:
>The difference is that a string cannot be used as a direct, more efficient
>pointer to an object while a handle can. Strings require hashing.
>For handles the implementation may chose to use it as a key for hashing
>but it can also use it as a direct object pointer (which I think most savvy
>implementations will do in the interest of efficiency).
>
>>But, if this is the case, that is, if functions names are just unique keys
>>and no support whatsoever is needed from SV compiler, then that part of
>>the functionality, however useful and desired it may be, doesn't seem
>>to be an inherent part of DPI.
>>C implementation of a specific hash table or an associative array may be
>>a key component of DPI applications, but it is =not= a part of the
>>interface. Similarly as a support for bit manipulations might be a welcome
>>addition to DPI, but wouldn't be a part of the interface per se.
>>I don't mind if sv-cc defines a hash table with <instance,function>
>>as a key. But please, please: do not embed it into DPI. Make it a separate
>>layer. Describe it in a separate annex.
>
>johnS:
>I'll comment more later. Sorry for my hastiness. I acually have
>the day off and am about to go to Vermont !
>
>>
>>Thanks and regards,
>>Andrzej
>>
>> > Now, if I call svPutUserData() passing the function scope
>> > handle rather than the module handle, I'm associating the
>> > user data with a specific imported function instance
>> > and we remove the restriction of only allowing one user
>> > data per module. Now we allow one user data
>> > per function per module.
>> >
>> > Similarly if I call svGetUserData() passing it a function
>> > scope handle, I'll get the user data associated with that
>> > specific function.
>> >
>> > Note, with this approach, I can still support the existing
>> > functionality of only setting one user data per module
>> > if that's all I really need (which often might be the case).
>> > But I can also do it per function.
>> >
>> > The following example illustrates both use models:
>> >
>> > ---------------------------------------
>> > C Side:
>> >
>> > class MyCModel {
>> > private:
>> > svModuleScope dSvScope;
>> > void *processArgs( args ... );
>> >
>> > public:
>> > MyCModel( const char *svModulePath ){
>> > dSvScope = svGetScopeFromName( svModulePath );
>> > svScope funcScope = svGetFunctionScopeFromName(
>> > dSvScope, "MyExternedCFunc" );
>> > svPutUserData( funcScope, this );
>> >
>> > // Note: Here I could have also associated user
>> > // data with a module scope instead as follows:
>> > // svPutUserData( dSvScope, this );
>> > }
>> >
>> > // This imported function is called from SV ...
>> > friend void MyExternedCFunc( args ... ){
>> >
>> > svScope scope = svGetFunctionScope();
>> >
>> > // Note: Here if I wanted to retreive user data for
>> > // module scope rather than a function scope, I could
>> > // have done this in place of the statement above:
>> > //
>> > // svScope scope = svGetScope();
>> > //
>> > // This is identical the current use model as per
>> > // sv_layer_v2.pdf.
>> >
>> >
>> > MyCModel *me = (MyCModel *)svGetUserData( scope );
>> >
>> > me->processArgs( args ... );
>> > }
>> >
>> > public:
>> > // This public method calls an exported SV function ...
>> > void CallExportedFunction( args ... ){
>> > svPutScope( dSvScope );
>> > MyExportedSvFunc( args ... );
>> > }
>> > };
>> >
>> > ---------------------------------------
>> > SV Side:
>> >
>> > module MySvModel();
>> > extern "DPI" context MyExternedCFunc = CFunc( args ... );
>> >
>> > export "DPI" MyExportedSvFunc = function SvFunc;
>> > void function SvFunc( args ... ) begin
>> > ...
>> > endfunction
>> >
>> > endmodule
>> >
>> > This simple context association capability is essential for
>> > conjoining object oriented C testbench environments with the
>> > instance-based SV environment.
>> >
>> > I realize the temptation is to say, let's just keep support
>> > the simple function call paradigm leave context capability out.
>> >
>> > But the reason that approach is inadequate is that we're
>> > trying to bridge a C environment to a fundamentally instanced
>> > based, hierarchical HDL environment where instance context
>> > is such a central concept.
>> >
>> > Also I think it is important for us to recognize some of the
>> > emerging object oriented HVL testbench modeling environments
>> > such as SystemC and others and provide the bare minimum
>> > functionality in our first release to cleanly support them.
>> >
>> > -- 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 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 : Fri Mar 21 2003 - 13:07:04 PST