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

Ah, but 1364 requires resolution to occur through the hierarchy.
This is the core question -- the SV LRM didn't fully rewrite the
1364 lookup rules and as a result there are gaps.  The
relative priority of lexical binding into a package (per 1800)
and dynamic binding in the instance hierarchy (per 1364) has
not been addressed.  Biasing the answer to the lexical binding
could break legacy designs compiled in an SV context.  As I
said in my second email, if breaking such designs is Ok, I'd
prefer the lexical biasing but I certainly don't think the
answer is obvious.  The answer gets particularly murky since
if we aren't careful, they will be no way to get the dynamic
binding.  If we bias towards dynamic, there is always a
way to get lexical -- using pkg::name.

Gord.

francoise martinolle wrote:

> 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
> 

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