Subject: [sv-cc] Modified Get/Put User Data Proposal
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Mar 18 2003 - 19:51:15 PST
Team,
As mentioned in the meeting today this is a slight addition
to the DPI context handle functions to support getting and
setting of user data pointers in specific function scopes
rather than just restricting it to module scopes as we
currently have it.
Recall that the original context handle support functions
were these (please refer to section A.8 of the rev-2
C-layer document, c_layer_v2.pdf for details):
svScope svGetScope();
void svPutScope(const svScope scope);
svScope svGetScopeFromName(const char* instancePath);
void svPutUserData(const svHandle scope, void* userData);
void* svGetUserData(const svHandle scope);
Here svGetScopeFromName can be used to derive a module
scope handle from a module instance path name.
svPutUserData() can then be used to associate a user pointer
(usually some C-model or data object) with the module's
instanced scope.
svGetUserData can then be used later (usually during runtime)
to retreive the user data that was stored with a module scope.
We've had this capability since we reached agreement
on the context proposals that were discussed at length
last fall. User data pointers are essential to support
any body of C code that needs to associate specific
instances of C objects with specific HDL scopes.
What we realized a couple of meetings ago is that,
while this capability is essential, it is limited in
that it only allows giving 1 user pointer for an entire
module instance. Specific user pointers cannot be
associated with specific functions imported to a module.
This means that IP providers of different C models
may conflict with each other if they're providing
extended functionality to be associated with the same
specific HDL model.
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.
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 : Tue Mar 18 2003 - 19:52:26 PST