Subject: Re: [sv-cc] Modified Get/Put User Data Proposal - function vs. module scope
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Thu Mar 20 2003 - 15:21:04 PST
> 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?
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.
Is a scope returned by svGetFunctionScopeFromName() a legitimate module
scope? Can it be used as an argument for svPutScope()?
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.
If so, then svPutUserData()/svGetUserData() will have to be split into
two versions, for functions and for modules. Not big deal.
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.
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.
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 archive was generated by hypermail 2b28 : Thu Mar 20 2003 - 15:23:14 PST