Subject: [sv-cc] Re: Modified Get/Put ... - svGetScopeFromName()/svPutUserData() overhead+restrictions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 19 2003 - 10:30:23 PST
> > > 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 archive was generated by hypermail 2b28 : Wed Mar 19 2003 - 10:31:50 PST