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

Sure enough -- Ok, so lexical does win.  I had looked at
the package rules but not the 19.3 compilation unit rules.
This is actually a good thing since that is what we
currently do (I was worried about having to fix this!).


So a question -- once a name becomes visible due
to a package import, can it be matched in an upwards resolution?

i.e:

    package pkg;
       task t; endtask
    endpackage

    module top;
       task t; endtask
       mid m();
    endmodule

    module mid;
       import pkg::*;
       bot b();
       initial t();
    endmodule

    module bot;
       initial t();
    endmodule


Does bot's reference to t bind to pkg::t or to top.t?

The question is whether an imported and visible identifier
is referencable via a hierarchical reference.

Gord.

francoise martinolle wrote:

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

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