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.