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.Received on Fri Jan 9 09:30:55 2009
This archive was generated by hypermail 2.1.8 : Fri Jan 09 2009 - 09:31:28 PST