Subject: RE: [sv-cc] Re: Modified Get/Put ... - svGetScopeFromName()/svPut UserData() o verhead+restrictions
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 19 2003 - 13:14:25 PST
John, Andrzej,
I agree with Andrzej's restriction proposal.
But I disagree with John's further constraint.
Let's allow all import/export functions to be
accessible by name.
Regards,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Wednesday, March 19, 2003 10:38 AM
> To: Andrzej Litwiniuk
> Cc: sv-cc@server.eda.org
> Subject: [sv-cc] Re: Modified Get/Put ... -
> svGetScopeFromName()/svPutUserData() o verhead+restrictions
>
>
> Andrzej,
>
> I finally understand what you're getting at !! Please excuse
> my thickheadedness :-)
>
> Yes, yes, yes, by all means let's restrict it to
> import/export functions not functions in general. In fact I
> would possibly go further and say let's restrict it to
> imported functions only.
>
> I think this is a very reasonable restriction. These
> functions were intended only to support the DPI interface and
> nothing more - at least in my mind.
>
> I agree that paying the price for user pointer storage for
> potentially millions of non-imported SV functions would be a
> very bad idea indeed !
>
> -- johnS
>
> Andrzej Litwiniuk wrote:
> > > > > svScope svGetScopeFromName(const char* instancePath);
> > > > >
> > > > > Here svGetScopeFromName can be used to derive a
> module > >
> > > scope handle from a module instance path name. > > >
> > > Andrzej Litwiniuk wrote:
> > > > the unnecessary overhead, that could be possibly
> avoided, if some
> > > > restrictions were imposed on svGetScopeFromName().
> > >
> > > johnS:
> > > It is not clear to me why you don't have the same overhead
> > > concerns about svGetScopeFromName() function (if it is
> > > performance overhead you're referring to). I anticipate that
> > > both of these functions would typically be called at init time,
> > > not run-time so performance overhead should not be a concern.
> > >
> > > I would guess that it probably common for most of today's
> > > users of VPI to only call vpiGetInstanceByName() at init
> > > time and store the handle for frequent subsequent use.
> >
> > John,
> >
> > You got me wrong. I have no problems with the run-time
> performance of
> > any of those functions. Very likely, as you said,
> > svGet(Function)ScopeFromName() will be called during initialization
> > only rather than repeatedly.
> >
> > The only issue is the run-time memory (footprint) needed to support
> > the
> > mapping
> > from names to instances/scopes. And possibly also a memory
> needed for
> > user data
> > if static scheme is used rather then dynamic.
> >
> >
> > > The same paradigm applies here to both
> svGetScopeFromName() > and
> > svGetFunctionScopeFromName().
> >
> > Right. Same memory issue: mapping from functions' names.
> >
> >
> > > johnS:
> > > Actually I think it is rare that the function scope
> functions would
> > > ever be used in conjunction with exported functions. Only
> imported
> > > functions. In fact, I would support making function scope
> handles >
> > illegal for exported functions to avoid confusion as to
> what they're
> > > used for. But I would be flexible on this either way. >
> > > User context pointers typically needed to be retreived
> when imported
> > > functions are called from SV in order to ascertain the
> local C model
> > > context associated with that call.
> >
> > Probably you are right and I should have written "imported" rather
> > than "exported". But that's not the point. My point was that if we
> > restrict svGet(Function)ScopeFromName to some predefined
> names known
> > to SV (exports or imports, whatever), then the mapping
> > from thus limited set of names/modules will be likely
> consuming less
> > memory.
> >
> >
> >
> > > > And there is another source of overhead: space for
> user's data.
> > Since any
> > > > instance can be used via svGetScopeFromName(), any
> instance may
> > have user's
> > > > data associated with it. (To be precise, there is a
> time/memory
> > trade-off;
> > > > a dynamic scheme could be used instead of static
> space per instance.)
> > >
> > > johnS:
> > > True extra storage would be needed for function scope handles if
> > > such handles are used. But in applications that only use module
> > > scopes, implementations would not necessary have to allocate this
> > > storage.
> >
> > SV compiler will not be able to determine what
> functionality is used
> > by an application, specifically, whether an application
> uses function
> > scope or module scope handles. Without restrictions on names that
> > could be used in svGet(Function)ScopeFromName
> > the compiler must assume that every name must be supported.
> > All I want is to restrict the names allowed!
> >
> >
> > > I will also guess that most implementations will already
> > > have allocated function related structures anyway to
> support the >
> > code generated wrappers for each function call.
> >
> > That's the point! Such wrappers will be created only for exported
> > functions.
> > Function svGet(Function)ScopeFromName() as it is
> unrestricted now, allows
> > to use =any= function name or instance name as a key for
> associating data.
> >
> > > Each function will
> > > probably need some internal object that represents its
> context. >
> > Storing user data with such objects is an extra data field in an >
> > object that probably already exists - just as storing user data >
> > pointers in module scoped context objects requires 1 extra data >
> > member.
> >
> > Yes. 1 extra data member per instance. The issue is: per every
> > instance of every module (millions of tiny cells!) or for
> some modules
> > only?
> >
> >
> > > I would also guess - although this may be presumtuous -
> that > the
> > DPI will not be used for modeling millions of primitive objects >
> > implemented in C. I think it is more likely that such primitives >
> > will typically be modeled within SystemVerilog. What will
> be more >
> > typical of DPI use will be to interface with C testbench models >
> > which will most likely number more in the dozens than millions.
> >
> > Exactly. So we will lose nothing by disallowing names of
> > non-import/export functions and names of instances without
> > import/export as arguments to svGet(Function)ScopeFromName.
> >
> >
> >
> > > > I'd like to restrict svGetScopeFromName() such that it will
> > return
> > NULL
> > > > for instances that don't contain exports.
> > >
> > > johnS:
> > > I don't think this will work. As I said, use of function
> > > scopes has very little to do with exported functions
> > > - only imported functions.
> >
> > Maybe the restriction is misformulated and it shoud rather refer to
> > imports.
> >
> > Do you agree that allowing =any= function/instance name would be
> > useless? If so, then what limitations can be imposed?
> >
> >
> >
> >
> > > > BTW, what about instances of interfaces? Is the
> functionality we
> > are > > discussing > > restricted to instances of modules only?
> > Whatever is the answer, it should
> > > > be stated clearly in LRM.
> > >
> > > johnS:
> > > I don't see a reason not to support import/export's for
> interfaces.
> > > This however is a separate issue for discussion whose outcome
> > > is independent of the outcome of the function scope
> handle discussion.
> >
> > Agree. Anyway, it must be explictly addressed in our part of LRM.
> > Maybe all it takes is to add "or interface" to every occurence of
> > "module" in our drafts.
> >
> >
> > Thanks,
> > Andrzej
> >
>
>
> --
>
> This email may contain material that is confidential,
> privileged and/or attorney work product for the sole use of
> the intended recipient. Any review, reliance or distribution
> by others or forwarding without express permission is
> strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 - 13:15:55 PST