Subject: [sv-cc] Re: Modified Get/Put ... - svGetScopeFromName()/svPutUserData() overhead, restrictions
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 19 2003 - 08:41:27 PST
> 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().
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.
A design may have millions of instances of tiny cells. Without restrictions,
any instance could be referred by a path name passed to svGetScopeFromName().
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.)
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.
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.
Thanks and regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 19 2003 - 08:42:21 PST