Subject: Re: [sv-cc] Modified Get/Put User Data Proposal - function vs. mo dule scope
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Mar 21 2003 - 10:32:18 PST
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 - 10:33:57 PST