Subject: RE: [sv-cc] more about import/export
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Mar 07 2003 - 16:41:07 PST
Joao,
Perfect clarification. John and I came to this exact
conclusion on a phone call earlier today. Earlier,
when the thinking wasn't so evolved and multiple
declarations were still allowed, we had determined
that the call-site location defined scope. Now it
makes a lot of sense for declaration site to determine
scope, since there is no chance of multiple, redundant,
or conflicting declarations.
I really like John's observation that external function
declarations, while empty, are more analogous to normal
SV function declarations than they are to C prototypes.
Keeping this mental model can clarify reasoning.
Francoise,
Regarding VPI context. I think we need to keep VPI
context separate from SV context. SV context serves
a specific purpose, namely binding ILFC's (InterLanguage
Function Calls) to their respective "proxy" declaration
sites in the foreign language. If you study John's
example (which is present in the tutorial Michael sent out),
you will see first-hand the usefulness of this concept.
VPI context is the classic thing we know: A system task
is instantiated in a specific scope, and VPI allows
queries to be made about that system task's scope.
When we get around to addressing VPI functionality
in SV (maybe in revision 3.2?) we can define that
extern DPI context functions will be instrumented
for VPI support, just as if they were system task
calls rather than external function calls.
Does that sound like a reasonable answer (even if
temporary) to your concerns? Does it change your vote? :)
And finally, thanks for all your help and support.
Your detailed language knowledge is invaluable.
Regards,
Doug
> -----Original Message-----
> From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> Sent: Friday, March 07, 2003 3:19 PM
> To: Francoise Martinolle; Stickley, John; Warmke, Doug
> Cc: 'sv-cc@server.eda.org'
> Subject: RE: [sv-cc] more about import/export
>
>
> I think a number of people are making a mistake confusing the
> context of a function vs the location where a function is
> called. In Verilog, functions run in the context where they
> are defined *not* where they are called from. Specifically,
> the only variables a function can "see" without qualification
> are the variables that occur in its context, not those
> visible in the location where it was called.
>
> For example:
>
>
> module foo(input clk);
>
> reg a, b; // top level decls
>
> function dummy(input bar);
> a = bar;
> endfunction
>
> always @(posedge clk) begin
> ...
> dummy(b); // call 1
> ...
> begin: myblock
> reg a; // local decls
> ...
> dummy(b); // call 2
> end
> ...
> end
>
> endmodule
>
> (plz forgive any syntax erros). In the above example, both
> call 1 and call 2 cause the same variable, the top-level a,
> to be modified, even though in call2's local scope there is a
> different version of "a" available.
>
> In short: for a SV function, context is always where the
> function was declared, not where it was called from. I hope
> this explanation clarifies the definition of "function
> context": it is the context where the function was declared
> (ie where the extern appears, or where the function
> definition of an exported function appears) and is
> conceptually, just the fully qualified name of that function
> (minus the function name part itself).
>
>
> Joao
> ==============================================================
> ================
> Joao Geada, PhD Principal Engineer
> Verif Tech Group
> Synopsys, Inc
> TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300,
> FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================
> ===============
>
This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 16:41:41 PST