Subject: [sv-cc] Remaining technical Issues for discussion on 3/25
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 24 2003 - 21:24:23 PST
Hi team,
There are a few technical issues I would like to iron
out at our meeting tomorrow (3/25):
1) Scope visibility for export function calls from C.
John and Joao briefly discussed this on email, but
no resolution was made. The latest proposal from
Joao sent to SV-EC states that export function calls
have the same unqualified visibility rules as do normal
SV function calls.
That is, based on current context, the function can be
found by searching from the current scope and continuing
to search on an upwards path until $root.
Based on internal discussions, we feel this rule is
overly generous when compared to native SV function
calls, and that it may degrade performance significantly.
The reason is that the scope may be *dynamically* set by
the user's DPI C code. Thus, we will always be in a
situation where we have to dynamically search around
for the proper function definition to call, *at runtime*.
In normal SV, elaboration time can bind the call site
to the proper function definition. Runtime is very fast,
with no searching needed each time a call is made.
Let's stick with the "tight but useful" initial rules here,
and defer such generous function scope binding treatment
to SV 3.2.
2) The user data debate that is currently being led by John.
Let's get that put to bed.
3) Idea of "popping context" for calls to export functions
nested inside of import functions.
The simplest use model has an import function and export
function in the same scope. The C implementation of the
import function can call an export function without any
manual setting of scope with svSetScope().
In a more complex scenario, an import function may want
to call an export function in a different scope by using
svSetScope(). Yet, the import function may have to retain
a handle to the current scope, and set the scope back to
the old scope after the export function returns.
A while ago, Johnny suggested that we have svSetScope()
return a handle to the current scope. That way we could
enable code to be written like this:
void importFunc()
{
svScopeHandle savedScope = svSetScope(newScope);
exportFunc1(); /* Defined in different scope */
svSetScope(savedScope); /* Restore scope */
exportFunc2(); /* Defined in same scope as importFunc */
}
Do we want to go for this?
The alternative is to ask users to write code like this:
void importFunc()
{
svScopeHandle savedScope = svGetScope();
svSetScope(newScope);
exportFunc1();
svSetScope(savedScope);
exportFunc2();
}
4) Joao discovered that unnamed function prototype arguments
are already allowed in SystemVerilog, as per the 3.0 spec.
The 3.1 spec hasn't really done justice to this.
Two questions:
i) Will you (Joao and Andrzej) follow up on this with SV-BC?
ii) Do import function calls or declarations require any
special treatement for unnamed arguments compared to
normal functions?
Note that SV <named_function_proto> is not really intended
for use in true function declarations. Rather, it is intended
for use in function prototype context. We have decided that
import function declarations are equivalent to native SV
function declarations, not SV function prototype decls such
as might be found in an interface declaration.
Native SV function declarations don't support unnamed arguments.
I'm not convinced we should allow this feature for import function
declarations. Let's debate this more fully before deciding to
allow unnamed arguments in import function declarations.
If we decide not to support unnamed arguments in import decls,
we will have to amend the basic SV BNF by creating something
very similar to <named_function_proto>, but without the unnamed
arguments feature. I think this would be the most prudent course
of action for SV 3.1, since it is most obviously implementable
without serious pitfalls and lots of exceptions/rules to know.
We could defer unnamed import declaration args to SV 3.2, when
Peter Flake's true separate-compilation-drive function prototype
declarations would enter the language.
Thanks and regards,
Doug
This archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 21:25:16 PST