Re: SV utilities in non-context task/functions

Hi Jason,

> Here is the paragraph taken from IEEE 1800-2005, that we were debating
> today:

I was reading and re-reading it and there was a couple of things I
noticed:

> "To avoid any unnecessary overhead, imported task and function calls
> in SystemVerilog code are not
> instrumented unless the imported task or function is specified as
> context in its SystemVerilog import declaration.

Notice how this paragraph talks specifically about imported tasks
and function calls.  This paragraph says nothing about non-imported
functions/tasks.

> If those utility functions are used with any noncontext function, a
> system error shall result."

This introduces the term `noncontext function'.  It is not clear if
this refers to those imported functions/tasks that are not specified
as context *or* if it also includes all functions that are not
imported.  To me the text is quite ambiguous.  At the very least it
requires clarification from the SV committee.

> It is my interpretation of this section to mean that these utility
> functions may only be called from within a context imported
> task/function;

This is one possible interpretation.  Another one is that `noncontext
function' refers to only *imported* functions not specified context.
Lets call your interpretation strict and mine loose in the following.

> Here is an example of why I think this restriction is in the
> SystemVerilog specification:

[Example elided]

>  So, if I have some SystemC code for which the HDL compiler knows
> nothing about, I cannot do svGetScopeFromName("top.i0"), because the
> scope doesn't exist, since it has been inlined.  I also cannot do
> svPutUserData() for two reasons: (1) I can't get the scope to top.i0;
> (2) Storage space for svUserData has been optimized away because there
> are no context task/functions declared.

Good analysis.  However, this does not really apply to our case,
assuming we fix the pipe DPI calls to be context.  In the case of
pipes, there will always be context DPI functions in the Verilog
modules of interest which are precisely the modules that have
pipe calls in them so the scope and user data storage space is
always present and should not be optimized away.  So our use
of svGetScopeFromName() etc. cannot be deemed invalid on the basis
on some argument about compiler optimizations.

Furthermore, the loose interpretation do not preclude these
compiler optimizations.  After all, it is a simple matter to
report an error on svGetScopeFromName("top.i0") if the scope does
not exist.  Similarly for svPutUserData() and friends.  It seems
overly restrictive to disallow these calls altogether.

Per