Subject: [sv-cc] Re: Modified Get/Put ... - svGetScopeFromName()/svPutUserData() o verhead, restrictions
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 19 2003 - 09:16:23 PST
Andrzej,
Andrzej Litwiniuk wrote:
> > svScope svGetScopeFromName(const char* instancePath);
> >
> > void svPutUserData(const svHandle scope, void* userData);
> >
> > Here svGetScopeFromName can be used to derive a module
> > scope handle from a module instance path name.
> >
> > svPutUserData() can then be used to associate a user pointer
> > (usually some C-model or data object) with the module's
> > instanced scope.
> >
> > We've had this capability since we reached agreement
> > on the context proposals that were discussed at length
> > last fall. User data pointers are essential to support
> > any body of C code that needs to associate specific
> > instances of C objects with specific HDL scopes.
>
> Team,
>
> I'm not going to question the need for or the usefulness of the above
> functionality. I'm concerned, however, with the overhead, especially
> 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.
The same paradigm applies here to both svGetScopeFromName()
and svGetFunctionScopeFromName().
>
> I suppose that the intended use of svGetScopeFromName()/svPutUserData()
> is to associate a user pointer with the instance that exports DPI
> functions rather than with an arbitrary instance of any module.
> The specification of svGetScopeFromName() does not, however, restrict
> its use to instances that contain exports.
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.
>
> A design may have millions of instances of tiny cells. Without
> restrictions,
> any instance could be referred by a path name passed to
> svGetScopeFromName().
johnS:
But hopefully only at init time as mentioned above.
> Technically, there are no problems with implementing svGetScopeFromName(),
> even though a design may be transformed by compiler optimizations, modules
> inlined, etc. The only issue is the memory overhead for mapping path
> names onto
> instances. In the case of PLI, this has to be explicitly enabled and is
> avoided
> in default mode. In the case of DPI, such mapping shall be enabled whenever
> DPI is enabled.
>
> 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. 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. 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.
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.
>
> SV compiler will not analyze C code and therefore will not be able
> to determine which instances are actually used and may have user's data
> associated with them. Whatever is allowed by the language defintion and
> cannot
> be excluded by analyzing SV code, is deemed possible and thus must be
> supported.
>
> I don't see much sense in bearing the overhead for unused functionality, so
> 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.
>
> I'm not sure whether the above restriction could affect the
> interoperability
> of DPI and PLI; anyway, svScope seems be of no use for PLI.
>
> 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.
> Thanks and regards,
> Andrzej
>
__
______ | \
______________________/ \__ / \
\ 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 - 09:19:46 PST