Subject: RE: [sv-cc] David's update to our extern/export proposal
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 19 2003 - 21:33:16 PST
John,
Joao's statement does mirror normal SV function calling rules.
If we stick with our golden maxim of treating ILFC's as much as
possible like normal system calls, then we shouldn't add the
restriction you are talking about.
On the other hand, this may be difficult to implement.
Actually the only thing straightforward to implement is calling
a function declared right in the current context. Even your
example of scoping upwards to calling something in $root is tricky.
So the limitation should be "only functions declared immediately
in the current context", or what Joao has already written.
****
Andrzej,
As per legal context in which export functions can appear, our
LRM already states that legal contexts are anywhere a normal
function can be declared. That means interface, module,
program, or generate scope. This was one of the results
arrived at during the "gnarly thread".
Thanks and regards,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Tuesday, March 18, 2003 11:53 AM
> To: Joao Geada
> Cc: sv-cc
> Subject: RE: [sv-cc] David's update to our extern/export proposal
>
>
> Joao,
>
> This looks pretty good.
>
> I have only one comment. Regarding this,
>
> "Exported functions can only be invoked if the
> current context refers to an instance from which the named
> function could be
> called in SystemVerilog by an unqualified function call (i.e.
> a call to the function
> with no hierarchical path qualifier). In general this implies
> that an exported
> SystemVerilog function is visible from its declared scope to
> any scope lower
> down in the hierarchy."
>
>
> I don't think we want to say that modules in lower hierchical
> scope have visiblity to functions above them in hierarchy.
> You should only allow visibility to functions in higher
> declarative scope not hierarchical scope.
>
> -------------------------------
> What is allowed:
>
> function root_scope_func( ... )
> ...
> endfunction
>
> module foo
> function f( ... )
> ...
> endfunction
>
> module bar
> // Code inside bar ...
> endmodule
> endmodule
>
> In this case code inside bar *can* call function
> root_scope_func() *and* f() because both are
> defined in enclosing declarative scopes.
>
> -------------------------------
> What is not allowed:
>
> function root_scope_func( ... )
> ...
> endfunction
>
> module foo
> function f( ... )
> ...
> endfunction
>
> bar u1( );
> endmodule
>
> module bar
> // Code inside bar ...
> endmodule
>
> Here, although code inside bar can still call
> root_scope_func() (because root scope encloses
> both bar and foo declarative scopes), code inside
> bar cannot call f() unless it qualifies the name with
> explicit hierarchical reference. Bar is lower in
> hierarchy than foo but f() is not directly visible
> because it is not in a lower nested declarative scope.
>
> You may have meant to say this but the phrase "any scope
> lower in the hierarchy" in the wording above implies visibility
> in lower instantiated scopes rather than lower declarative
> scopes. I think the word hierarchy should be taken out.
> "hierarchy" implies a chain of instantiated scopes not
> nested declarative scopes.
>
> I believe this is what the LRM implies for normal SV function
> and I think this is what we want to follow for import/export
> functions.
>
> -- johnS
>
> > -----Original Message-----
> > From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> > Sent: Tuesday, March 18, 2003 12:11 PM
> > To: sv-cc
> > Subject: [sv-cc] David's update to our extern/export proposal
> >
> >
> > Attached...
> >
>
> --
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 - 21:34:06 PST