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

Hi all,
I think this discussion will not make any concrete solution. I am also 
little bit responsible for that as I could not understand clearly Greg's 
comment in reply of Gordon's mail. So I am just writing a complete 
algorithm in my own way to find out the identifier for task enable and 
function call:

-- Search the identifier in the current name space/scope completely and 
any wild card import statement present lexically before that in the same 
scope.
-- If not found, go upper lexical scope to do the complete search, wild 
card import statement to be considered which are present lexically 
before the current name space/scope.
-- Repeat above rule until not found.

Please confirm if my understanding correct.

I am not sure whether it is right platform or not to discuss, but I 
think implementing this is tough though, as we need to defer the 
searching until whole design is processed and the corresponding object 
model is populated. Also we need to keep a list of wild card import 
statements present lexically before and associate this with each nested 
scope and function call/task enable. This will actually impact memory 
overhead for each such vendor tools/simulators just to support this 
peculiar type of searching. That was my actual concern about this 
matter, and I want to avoid it from technical point of view. If you 
people have any better solution please let me know.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] Task function identifier searching rule
From: Greg Jaxon <Greg.Jaxon@synopsys.com>
To: Surya Pratik Saha <spsaha@cal.interrasystems.com>
Cc: Steven Sharp <sharp@cadence.com>, Brad Pierce 
<Brad.Pierce@synopsys.com>, "sv-bc@eda.org" <sv-bc@eda.org>
Date: Saturday, January 10, 2009 12:42:21 PM
> 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.