Subject: RE: [sv-cc] Modified Get/Put User Data Proposal
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 19 2003 - 07:36:32 PST
John,
Thanks for taking the time to create and write up
this small adjustment (which makes a big difference
to a large class of DPI applications).
Only one minor correction: You wrote "svPutScope()"
but it is actually "svSetScope()". "svPutUserData()"
uses "Put" instead of "Set" for two reasons:
1) Consistency with the VPI equivalent function
2) We really are "putting" data into the SV system
These names more accurately reflect the purpose of
the functions. They're not syntactically identical
i.e. both use "Set" or both use "Put", but that is OK
because they are semantically different anyways.
Regards,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Tuesday, March 18, 2003 7:51 PM
> To: sv-cc
> Subject: [sv-cc] Modified Get/Put User Data Proposal
>
>
> 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 : Wed Mar 19 2003 - 07:37:23 PST