Subject: Re: [sv-cc] Modified Get/Put User Data Proposal - function vs. mo dule scope
From: Stickley, John (john_stickley@mentorg.com)
Date: Mon Mar 24 2003 - 09:07:04 PST
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:09:11 PST