Regards Surya
RE: [sv-bc] Task function identifier searching rule
Surya,
No, that is not a correct description.
For a simple identifier that is not a task/function name
you never resolve in a forward manner to later declarations
in the scope. Your description seems to imply that
one does that. The 2009 Draft LRM has quite a bit of
detail in regards to the search rules and the various
cases, including dotted names (which may or may not
be hierarchical names), function/task names, and $unit.
Obviously I am not going to discuss implementation details;
that would be inappropriate in this forum. However, the fact
that key implementation people at Mentor, Synopsys, and Cadence
have agreed to the rules in the LRM is an indicator that
they at least believe that the bar for implementing this
is not unreasonable.
As I have recommended before, the best way to really
understand all of this is to participate in committee
discussion during the process; I certainly don't have
the time to completely explain the context of the
rules and the surrounding discussion, much of which is
relevant to the questions you are asking. The rules
in the LRM are reasonably complete, but it still
takes a significant effort to completely integrate
the implications and details into an implementation.
Gord.
-----Original Message-----
From: owner-sv-bc@server.eda.org on behalf of Surya Pratik Saha
Sent: Sat 1/10/2009 1:39 AM
To: Greg Jaxon
Cc: Steven Sharp; Brad Pierce; sv-bc@eda.org
Subject: 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.
This archive was generated by hypermail 2.1.8 : Sat Jan 10 2009 - 19:28:21 PST