Re: [sv-bc] Task function identifier searching rule

Surya Pratik Saha wrote:
> Hi Steven,
> I did not see anything in the LRM as you have commented. So if I write
> the example in a little bit different way by putting the import before
> initial block:
> 
> package p;
> function int f();
> return 1;
> endfunction
> endpackage
> module top;
> int x;
> if (1) begin : b
> import p::*; // line 3
> initial x = f(); // line 2
> end
> function int f();
> return 1;
> endfunction
> endmodule
> 
> Then as per your comment, still top.f will be selected not p::f. I don't
> think it is correct. The particular simulator also selects p::f in this
> case. Also I think by "It doesn't look for imports" you want to mean
> wildcard import only, not explicit import.

But Steven's next sentence said "if the name f was imported already by a
non-hierarchical reference, then the (hierarchical) search will find it."
Your // line 2 is exactly that: a non-hierarchical reference which triggers
the wildcard import of p::f.  When you put lines 2 & 3 back in increasing
numerical order, the reference to f (line 2) no longer triggers the import
(line 3), and so "f" is left unresolved for a later hierarchical search.
Steven's rule (that "hierarchical" resolutions happen too late to trigger
wildcard imports) has consensus support.

Greg


> 
> Hi Brad,
> my proposal is to change the text below the example in the LRM as:
> "f() on line 2 binds to p::f and not to top.f though the import is after
> the function call reference."
> 
> Regards
> Surya
> 
> 
> 
> -------- Original Message  --------
> Subject: Re:[sv-bc] Task function identifier searching rule
> From: Steven Sharp <sharp@cadence.com>
> To: sv-bc@eda.org, spsaha@cal.interrasystems.com
> Date: Saturday, January 10, 2009 1:14:51 AM
>> Surya,
>>
>> The hierarchical search for f does not "find the import".  It doesn't
>> look for imports.  It only looks for the name f.  If the name f was
>> imported already by a non-hierarchical reference, then the search will
>> find it.  In this case, there was no reference that required p::f to be
>> imported.
>>
>> All the responses so far have agreed that the example is correct.  No
>> change is needed.
>>
>> Steven Sharp
>> sharp@cadence.com
>>
>>
>>
>>
>>
> 
> 
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.