That is not clear from the LRM. My quick answer is that it would not be but I would like to think about it more. Import clause makes the symbol of the task visible, this is different from declaring that task. The base of my NO answer is that package declared items cannot be selected via oomr syntax. Unfortunately I am leaving for vacation tonight and I cannot discuss this further. I will think about it though. Francoise ' -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Tuesday, February 28, 2006 12:40 PM To: francoise martinolle Cc: 'Brad Pierce'; sv-bc@eda.org Subject: 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.comReceived on Tue Feb 28 13:39:37 2006
This archive was generated by hypermail 2.1.8 : Tue Feb 28 2006 - 13:40:39 PST