I agree. ________________________________ From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com] Sent: Thursday, November 20, 2008 6:40 PM To: Francoise Martinolle; Mark Hartoog; sv-bc@eda.org Subject: RE: [sv-bc] Task and function name binding Francoise, Your description is what I thought was intended, but the text seems, at least to me, to say something different. It seems to say that only the current scope is searched to the end for locally visible symbols, rather than all the outer scopes too. From: Francoise Martinolle [mailto:fm@cadence.com] Sent: Thursday, November 20, 2008 3:32 PM To: Mark Hartoog; sv-bc@eda.org Subject: RE: [sv-bc] Task and function name binding I believe that in your second example both function calls should bind to top.b.f In the algorithm I outlined in the first draft of the name resolution, the current scope and upper scopes where searched in a while loop until no more scopes or a declaration was found. First the current scope is searched for local visible symbols, then the imported packages at that scope, then current_scope wast set to upper scope and we started the same search again. The definition of the function f is in the first outer scope of the named block. It appears in a scope that is closer to the named block than the scope where the import statement is found. The basic difference between task/functions and other identifiers, is that for task and functions the entire scope is searched, for other identifiers only the declarations preceding the reference matter. Francoise ' ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Mark Hartoog Sent: Thursday, November 20, 2008 5:48 PM To: sv-bc@eda.org Subject: [sv-bc] Task and function name binding I have been studying the language in 23.8.1 Task and Function name resolution and 26.3 Referencing data in packages with regards to task/function name resolution. Section 26.3 says: <quote> For a reference to an identifier other than function or task call, the locally visible identifiers defined at the point of the reference in the current scope shall be searched. If the reference is a function or task call, all of the locally visible identifiers to the end of the current scope shall be searched. If a match is found the reference shall be bound to that locally visible identifier. If no locally visible identifiers match, then the potentially locally visible identifiers defined prior to the point of the reference in the current scope shall be searched. If a match is found, that identifier from the package shall be imported into the current scope, becoming a locally visible identifier within the current scope, and the reference shall be bound to that identifier. </quote> There is then this example in 23.8.1: package p; function void f(); $display("p::f"); endfunction endpackage module top; import p::*; if (1) begin : b // generate block initial f(); // reference to "f" function void f(); $display("top.b.f"); endfunction end endmodule This example should print "top.b.f" which is consistent with text in 26.3, but suppose I change this to: package p; function void f(); $display("p::f"); endfunction endpackage module top; import p::*; if (1) begin : b // generate block initial begin : block f(); // reference to "f" end initial f();// reference to "f" function void f(); $display("top.b.f"); endfunction end endmodule There is now an additional reference to 'f' in the named block 'block', which is a scope. At the end of the scope 'block' there is no 'f' defined locally. Does this now make 'p::f' locally visible in module top and then bind the function call to 'p::f' so that this now print "p::f"? Was the intent here that these two calls to f() should bind differently without producing any error message? -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 20 15:42:46 2008
This archive was generated by hypermail 2.1.8 : Thu Nov 20 2008 - 15:42:56 PST