-----Non-member (???) submission from ["Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>]----- Subject: RE: [sv-ec] Name resolution and imports Date: Thu, 31 Aug 2006 20:14:15 -0700 Neil, This was certainly my reading (and Mentor's position on the interpretation). We've explicitly talked about this kind of thing in committee and in other contexts without hearing this alternative position from Synopsys before. I was very taken aback (shocked) to hear this position taken by key committee people from Synopsys. That is why I raised the issue with such urgency. I am very opposed to hierarchical references to imports, chained imports, and any other implications of having imported names be visible to outside reference. There are huge issues with name pollution, it corrupts any view of a package having local and controllable effect, etc. Doug has raised other points and there are still others that cause me to object to this position. Gord -----Original Message----- From: Neil Korpusik [mailto:Neil.Korpusik@Sun.COM] Sent: Thu 8/31/2006 5:04 PM To: Vreugdenhil, Gordon Cc: SV_BC List; SV_EC List; sv-ac@verilog.org Subject: Re: [sv-ec] Name resolution and imports =20 Allowing a hierarchical reference to a variable imported into a module instance seems to be equivalent to allowing a hierarchical reference to = a hierarchical reference. I don't believe that we want to allow this. 19.2.1 says the following "The import statement provides direct visibility of identifiers within = packages. It allows identifiers declared within packages to be visible within the = current scope without a package name qualifier." Doesn't this limit the visibility to the "current scope"? Anything = declared in the package isn't part of the scope it is imported into. It's just = visible to the importing scope, it isn't part of that scope. Neil Gordon Vreugdenhil wrote On 08/31/06 10:03,: > All, >=20 > The name resolution working group has encountered an issue that needs >to be resolved at the committee level. The issue is directly >addressed by Mantis 1323 -- "are imported names visible to >hierarchical references". Mentor and Cadence have both taken the >position that they are not; Synopsys has taken the position that they >are. This needs to be resolved quickly as implementations have (and >will continue) to diverge. This also impacts the issue of chained >imports (is a symbol imported into a package available for import) >which is also addressed by Mantis 1323. >=20 > This issue has a direct bearing on back-annotation, pli, and related >issues since it impacts what the system must present as members of a >scope and whether hierarchical names for items in a design are unique >or not. >=20 > Currently Mantis 1323 is listed as a BC issue. I'd like to have this >issue be resolved asap due to the overall impact of the interpretation >differences. >=20 > Question: should this immediately be elevated to the champions level >or is it appropriate to leave for SV-BC? >=20 > Independent of that decision, it would be worthwhile for people to >speak to this from various perspectives so that we can make an >informed decision. >=20 > Gord --=20 --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Senior Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- ------_=_NextPart_001_01C6CD74.B4A073E3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7650.28"> <TITLE>RE: [sv-ec] Name resolution and imports</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <BR> <P><FONT SIZE=3D2>Neil,<BR> <BR> This was certainly my reading (and Mentor's position<BR> on the interpretation). We've explicitly talked about<BR> this kind of thing in committee and in other contexts<BR> without hearing this alternative position from Synopsys<BR> before. I was very taken aback (shocked) to hear this<BR> position taken by key committee people from Synopsys.<BR> That is why I raised the issue with such urgency.<BR> <BR> I am very opposed to hierarchical references to imports,<BR> chained imports, and any other implications of having<BR> imported names be visible to outside reference. There<BR> are huge issues with name pollution, it corrupts any<BR> view of a package having local and controllable effect,<BR> etc. Doug has raised other points and there are still<BR> others that cause me to object to this position.<BR> <BR> Gord<BR> <BR> <BR> -----Original Message-----<BR> From: Neil Korpusik [<A = HREF=3D"mailto:Neil.Korpusik@Sun.COM">mailto:Neil.Korpusik@Sun.COM</A>]< B= R> Sent: Thu 8/31/2006 5:04 PM<BR> To: Vreugdenhil, Gordon<BR> Cc: SV_BC List; SV_EC List; sv-ac@verilog.org<BR> Subject: Re: [sv-ec] Name resolution and imports<BR> <BR> Allowing a hierarchical reference to a variable imported into a = module<BR> instance seems to be equivalent to allowing a hierarchical reference to = a<BR> hierarchical reference. I don't believe that we want to allow this.<BR> <BR> 19.2.1 says the following<BR> <BR> "The import statement provides direct visibility of identifiers = within packages.<BR> It allows identifiers declared within packages to be visible within the = current<BR> scope without a package name qualifier."<BR> <BR> Doesn't this limit the visibility to the "current scope"? = Anything declared<BR> in the package isn't part of the scope it is imported into. It's just = visible<BR> to the importing scope, it isn't part of that scope.<BR> <BR> <BR> <BR> Neil<BR> <BR> <BR> Gordon Vreugdenhil wrote On 08/31/06 10:03,:<BR> > All,<BR> ><BR> > The name resolution working group has encountered an issue that<BR> > needs to be resolved at the committee level. The issue is = directly<BR> > addressed by Mantis 1323 -- "are imported names visible to<BR> > hierarchical references". Mentor and Cadence have both = taken<BR> > the position that they are not; Synopsys has taken the position<BR> > that they are. This needs to be resolved quickly as = implementations<BR> > have (and will continue) to diverge. This also impacts the = issue<BR> > of chained imports (is a symbol imported into a package = available<BR> > for import) which is also addressed by Mantis 1323.<BR> ><BR> > This issue has a direct bearing on back-annotation, pli, and<BR> > related issues since it impacts what the system must present<BR> > as members of a scope and whether hierarchical names for items<BR> > in a design are unique or not.<BR> ><BR> > Currently Mantis 1323 is listed as a BC issue. I'd like to = have<BR> > this issue be resolved asap due to the overall impact of the<BR> > interpretation differences.<BR> ><BR> > Question: should this immediately be elevated to the = champions<BR> > level or is it appropriate to leave for SV-BC?<BR> ><BR> > Independent of that decision, it would be worthwhile for people<BR> > to speak to this from various perspectives so that we can<BR> > make an informed decision.<BR> ><BR> > Gord<BR> <BR> --<BR> ---------------------------------------------------------------------<BR >= Neil = Korpusik &nbs p= ;   ;= &= nbsp; Tel: 408-720-4852<BR> Senior Staff = Engineer &nbs p= ;   ;= Fax: 408-720-4850<BR> Frontend Technologies - ASICs & Processors (FTAP)<BR> Sun Microsystems<BR> email: neil.korpusik@sun.com<BR> ---------------------------------------------------------------------<BR >= <BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C6CD74.B4A073E3--Received on Thu Aug 31 20:26:02 2006
This archive was generated by hypermail 2.1.8 : Thu Aug 31 2006 - 20:26:13 PDT