RE: [sv-bc] Functions in nested modules (19.6)

Gord,  

I do not understand why in your example you could not bind f to pkg::f
during parsing time.
When resolving a symbol, the compiler should determine if the symbol exists
in 
the current verilog scope where the function f is called.
If the symbol is not locally declared, then it should look into the imported
packages in that scope.
Then I would expect it to find f in the package pkg. If it cannot find the
symbol in the current
scope (including symbols imported) then it should go up the scope and try to
resolve f in the scope containing
the module down_m. If that is a top module, the new scope it should look
into is the compilation unit
scope. See 19.3
These rules are in the LRM, see 19.2.2 and 19.3

Francoise
    '



-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon
Vreugdenhil
Sent: Tuesday, February 28, 2006 10:26 AM
To: Brad Pierce
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Functions in nested modules (19.6)

Brad, this is only one of a long list of name binding issues that I am
worried about.  The current rules aren't terribly clear on all of this and
are very unclear when it comes to interactions with classes, etc.  I am
planning on writing up the issues and a proposed resolution algorithm in a
couple of weeks when I have a bit more time than right now.

For this particular example, I believe that "f" should bind to up_m.f.  If
the user wants to get $unit::f, the user should explicitly state that via
the $unit form of reference.

Note that this is *really* interesting when you start talking about a
function made (potentially) visible via a pkg::* import.  For example:

    package pkg;
       function f; ... endfunction
    endpackage

     ...
    module down_m;
    import pkg::*;
         .... f(...);
    endmodule


Even if down_m is separately compiled, you *cannot* bind "f"
to pkg::f at compile since the instantiation hierarchy trumps the pkg
reference.

Situations like this also make me *extremely* wary about adopting a strategy
of only elaborating packages that have items references that are used (see
the other discussion thread).  In cases like this there is no way to know
until elab time whether "f" is actually used from pkg or not.

This is, well, "not exactly intuitive".

Gord.

Brad Pierce wrote:

> Which version of "f" does "down_inst" call in the skeleton below?
> 
> module container;
> 
>   function f; ... endfunction
> 
>   module up_m; ...
>        function f; ... endfunction
>        down_m down_inst(...);
>   endmodule
> 
>   module down_m; ...
>        ... f(...) ...
>   endmodule
> 
> endmodule
> 
> As I understand it, the function/task names are not resolved until 
> after the design has been elaborated, at which time they are resolved 
> by looking first in the calling instance, then in its parent and so on.
> So when I resolve the name "f" in "down_inst", should I find the 
> version that "down_m" sees in its lexical scope or the version that 
> the parent of "down_inst" sees in its lexical scope?
> 
> -- Brad
>  
>  

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com