Subject: Re: [sv-cc] Re: Modified Get/Put ... - svGetScopeFromName()/svPut UserData() o verhead+restrictions
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 19 2003 - 13:15:59 PST
Doug,
I'm OK with this if everyone else is.
-- johnS
Warmke, Doug wrote:
> 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 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:18:15 PST