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

 Gordon,

according to 19.3, the instance hierarchy is searched last. So this has been
resolved in 1800.
Extract:
When an identifier is referenced within a scope, SystemVerilog follows the
Verilog name search rules:
- First, the nested scope is searched (P1364 12.6) (including nested module
declarations), including any identifiers
made available through package import declarations
- Next, the compilation-unit scope is searched (including any identifiers
made available through package
import declarations
- Finally, the instance hierarchy is searched (P1364 12.5)

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 11:32 AM
To: francoise martinolle
Cc: 'Brad Pierce'; sv-bc@eda.org
Subject: 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