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

This would need to be raised as a ballot issue and then approved during the ballot review in order for the correction to be made in the LRM.

Stu
~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
(503) 692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surya
> Pratik Saha
> Sent: Friday, January 09, 2009 9:30 AM
> To: Greg Jaxon
> Cc: Gordon Vreugdenhil; sv-bc@eda.org
> Subject: Re: [sv-bc] Task function identifier searching rule
> 
> I agree with Greg. So can I expect the LRM is going to correct the
> example soon.
> 
> Regards
> Surya
> 
> 
> 
> -------- Original Message  --------
> Subject: Re:[sv-bc] Task function identifier searching rule
> From: Greg Jaxon <Greg.Jaxon@synopsys.com>
> To: Gordon Vreugdenhil <gordonv@model.com>
> Cc: Surya Pratik Saha <spsaha@cal.interrasystems.com>, "sv-bc@eda.org"
> <sv-bc@eda.org>
> Date: Friday, January 09, 2009 10:28:38 PM
> > I concur with Gordon.  The name was already introduced in the scope
> > when the wildcard import is seen.  Wildcards never perturb names
> > that already exist in the importing scope.
> >
> > Greg
> >
> > Gordon Vreugdenhil wrote:
> >
> >> import makes names visible at the point of import down; forward
> >> function references are not sufficient to actually bring the function
> >> name in from the package.  Imports just create "potentially
> >> visible" names.  So imports are never considered as late as you
> >> are suggesting.
> >>
> >> Gord.
> >>
> >> Surya Pratik Saha wrote:
> >>
> >>> One interesting note. One standard simulator behaves as mentioned in LRM
> >>> example. But failed to get the function call body if the function
> >>> declaration removed from module body. So it can't get the function body
> >>> reference from package at all even the import declaration is there. Is
> >>> it the intended behavior?
> >>>
> >>> Regards
> >>> Surya
> >>>
> >>>
> >>>
> >>> -------- Original Message  --------
> >>> Subject: [sv-bc] Task function identifier searching rule
> >>> From: Surya Pratik Saha <spsaha@cal.interrasystems.com>
> >>> To: sv-bc@eda.org <sv-bc@eda.org>
> >>> Date: Friday, January 09, 2009 6:34:03 PM
> >>>
> >>>> Hi,
> >>>> As per the SV 2009 draft LRM, task/function identifier has to be
> >>>> searched in the complete local scope first and then will go to the
> >>>> scope lexically above. With that algorithm, the example shown in "26.3
> >>>> Referencing data in packages" is contradictory.
> >>>>
> >>>> *Example 3:
> >>>> package p;
> >>>> function int f();
> >>>> return 1;
> >>>> endfunction
> >>>> endpackage
> >>>> module top;
> >>>> int x;
> >>>> if (1) begin : b
> >>>> initial x = f(); // line 2
> >>>> import p::*; // line 3
> >>>> end
> >>>> function int f();
> >>>> return 1;
> >>>> endfunction
> >>>> endmodule
> >>>>
> >>>> f() on line 2 binds to top.f and not to p::f since the import is after
> >>>> the function call reference.*
> >>>>
> >>>> If we go by the rule, function 'f' has to be searched in the complete
> >>>> scope of 'b', and there the import statement is found. So why it will
> >>>> be bound to 'top.f' is not clear to me. I did not see LRM mentioned
> >>>> that import statement should be considered after completing the
> >>>> searching of scope lexically above. Am I missing anything?
> >>>> --
> >>>> Regards
> >>>> Surya
> >>>>
> >>>>
> >>>> --
> >>>> This message has been scanned for viruses and
> >>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
> is
> >>>> believed to be clean. --
> >>>> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.astaro.com
> >>>>
> >>> --
> >>> This message has been scanned for viruses and
> >>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> >>> believed to be clean.
> >>>
> >> --
> >> --------------------------------------------------------------------
> >> Gordon Vreugdenhil                                503-685-0808
> >> Model Technology (Mentor Graphics)                gordonv@model.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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.