A couple of additional thoughts here (I'd love to get some feedback to help refine the eventual resolution alg). 1) assume that down_m and up_m are in different compilation units. Assume that "down_m" does not define "f". If the compilation of down_m and up_m both have a visible "f" does one continue to follow the dynamic scoping and resolve "f" into the compilation unit of up_m or do we switch back to lexical scoping and resolve into the compilation unit of down_m? 2) Since this is an SV artifact, we could in fact change the resolution to bias things to lexical scoping rather than dynamic. This would be Ok with me as long as we then provided a way to defeat the lexical scoping. For example, if we said that within down_m a reference to "down_m.f" would require dynamic resolution, that might be more intuitive. The key question here is how backwards compatible we want to be with existing Verilog code. If you have a compilation unit wrapped around a legacy Verilog module, should the name bindings to functions be permitted to change for that module? If the answer is yes, then I'd rather go with lexical binding since I think that it is much more intuitive. Gord. Gordon Vreugdenhil wrote: > 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.comReceived on Tue Feb 28 07:54:40 2006
This archive was generated by hypermail 2.1.8 : Tue Feb 28 2006 - 07:54:58 PST