Subject: RE: [sv-cc] Modified Get/Put User Data Proposal - function vs. mo dule scope
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 24 2003 - 09:46:34 PST
John,
Nice write-up on the issues.
I really like Francoise's proposal with your amendments.
My informal poll response is "go for it".
Also, I agree with you that this user data association
is critical for efficient implementation of systems that
rely on DPI context functions. Sorry Andrzej, but I don't
believe this is "2nd layer" functionality that can be
postponed, since without it context functions are not
able to reach close to their full power.
Regards,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Monday, March 24, 2003 9:07 AM
> To: Francoise Martinolle
> Cc: Andrzej Litwiniuk; sv-cc@server.eda.org
> Subject: Re: [sv-cc] Modified Get/Put User Data Proposal -
> function vs. mo dule scope
>
>
> Francoise,
>
> This is not a bad proposal and I see it as an alternative to
> mine that can be probably be implemented just as efficiently
> (and probably nicely addresses Andrzej's concerns if my response
> on Friday did not).
>
> It think the only difference between your and my proposals is
> that yours reserves an index for a specific user data storage
> pointer in a module scope area and mine reserves an object keyed
> to a specific function that can be called from a module scope.
> Both solutions imply that the implementation will create some
> additional structure that can be attached to the internal
> representation of a module scope that can be used to store
> user specified data pointers.
>
> As I said, I think both could be equally efficient can
> solve the original problem that was identified, namely,
>
> "For a given module instance scope, we need to allow multiple
> independent C models to be able to associate their local model
> context (a.k.a. user data) with the specific module instance."
>
> This facilitates provision of multiple IP models in the form
> of imported functions in C models that can be utilized by a
> given SV module.
>
> Let me re-frame your proposal and make a couple of minor
> suggestions for modifications. Then, below, I have another
> message address to the team to try to reach closure on
> one of the two proposals so we can be sure this important
> enhancement gets incorporated into the 1st revision of DPI.
>
> Here are my suggestions:
>
> 1. Perhaps we can just reserve ID=0 to denote module scope
> and all other ID's to be some valid id returned by
> svGetNewIdForScope()
>
> 2. Let me suggest a slightly less vague name for your new
> function. How about,
>
> int svGetUserDataIdForScope( svScope moduleScope );
>
> I'm open to other suggestions.
>
> -- johnS
>
> Team,
>
> So at this point, I would like to request to the committee that
> we bring quick closure to this issue as time is running out
> for freezing the content of the LRM and I think it is really
> important that we reach consensus on either my or Francoise's
> proposals ASAP. I personally am open to either - in fact
> I now rather slightly favor Francoise's proposal at this point.
>
> My main objective is to address the problem that is the
> original reason we're having this discussion. Let's go
> back and review what that is.
>
> We had already defined and agreed to a need to be able to
> associate some user data object point with an instance of
> an SV module. Some of my examples demonstrate why C model
> to SV module instance association, at a bare minimum, is
> essential to any application that utilizes DPI context
> functions.
>
> This feature alone is very useful and could probably
> serve a large class of applications quite nicely
> (certainly the type of applications we've been working with).
>
> However, at one of our meetings members of the team
> justifiably raised a concern that different bodies of
> C code provided from possibly different sources or vendors
> may want to provide IP in the form of imported functions/
> C models that can a given SV module may want to make use of.
> A single user data pointer association capability just does
> not address this scenario.
>
> So the challenge is to provide a *very* simple, efficient
> extension to what we already have to allow for this capability.
> To do that, Francoise and I have come up with 2 proposals
> which I'll summarize here:
>
> 1. JohnS Proposal:
>
> In my proposal, the underlying assumption is that each
> of these "C model vendors" may provide their own
> imported C function which essentially serves as the
> entry point or "method" to their C model code. With
> that assumption then, it is enough to be able to have a
> way of creating a handle representing "that function of that
> module instance" so that the combination can be
> uniquely identified by the code in question. So to do
> that I proposal 3 additional functions in my proposal
> which is detailed here:
>
> http://www.eda.org/sv-cc/hm/1110.html
>
> 2. Francoise's Proposal
>
> Francoise's proposal solves the same problem and, in my
> view, does so equally as efficiently. It requires only
> one additional function but a change to the existing
> svGet/PutUserData functions to now require an extra
> 'id' parameter.
>
> Here's a re-framed description of Francoise's proposal
> (Her original text is included in the following posting
> http://www.eda.org/sv-cc/hm/1137.html ):
>
> - Allow association of multiple user defined data pointers
> with module instances by allocating unique ID's denoting
> each.
>
> - The following new function is defined to request an ID:
>
> int svGetUserDataIdForScope( svScope moduleScope );
>
> - This function can be called at model initialization time
> and the returned ID can be stored in the C model and later
> be frequently referenced during run-time.
>
> - The functions svPutUserData() and svGetuserData() now
> require the additional ID argument:
>
> void svPutUserData(
> const svScope moduleScope, int userDataId, void* userData);
> void* svGetUserData(
> const svScope moduleScope, int userDataId );
>
> - ID=0 is reserved for association of user data with an
> overall module scope. Simpler applications that only
> need simple Cmodel-to-SV module association can simply
> pass id=0 to the svGetUserData() function and therefore
> not have to call svGetUserDataIdForScope() at initialization.
>
> - While storage of user data for ID=0 can be combined with storage
> for specific ID's, it is recommended that vendor supplied C
> model IP always use allocated ID's and that only end-user
> applications use ID=0.
>
> I would like to request an informal poll that we quickly
> choose one of these two approaches so we can formally
> incorporate this feature into the spec.
>
> Thanks,
> -- johnS
>
>
> Francoise Martinolle wrote:
> > 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 archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 09:47:40 PST