I agree with Arturo. I consider the case illegal per the LRM. I might add that in case (d), the remaining hierarchical resolution falls into the case of "upwards name" resolution since (b) was not satisfied. In such cases, the first item of the dotted name is required to be a scope so it should not be resolved to "t" (a variable) in any case. Example "Dotted name 2" in 23.8 indirectly addresses this -- it is clear in that example that "early" resolution of the first name can cause a later scope name to not be used. It doesn't seem consistent to then argue that if you *don't* find an early variable, that we should then allow a variable to be the "anchor" of a real hierarchical resolution. If we did make that change, we'd end up breaking legacy compatibility in which true (instance crossing) upwards references do ignore variables. I am not surprised that various tools might have issues with such references; as others have noted, the composition of the various odd cases in SV, legacy support, permitted function forwards, opaque types, the (very troublesome) optional argument list rules, and various vendor extensions make getting this "right" in an actual implementation difficult for pure LRM and probably impossible for most implementations once you add in the impact of self-legacy support that pragmatic considerations introduce. Gord. On 12/6/2013 11:49 AM, Arturo Salz wrote: > > Francoise, > > You didn't quote the complete LRM. The missing items are shown below: > > c) The name resolves to an imported scope name. The dotted name shall > be resolved in the same > > manner as a hierarchical name prefixed by the package name from which > the name was imported. > > d) The name is not found. The dotted name shall be considered to be a > hierarchical name. > > The example is an embodiment of the last item (d). > > I believe the LRM is perfectly clear. The problem is that dotted > references overload different operations (struct references, class > member references, scoped references, and hierarchical references), > and identifying a valid hierarchical reference can only be done after > elaboration. This is further complicated by the package import rules, > and the support for forward declarations (for legacy reasons ) of > function/tasks calls. > > Because a valid hierarchical reference cannot be determined at compile > (parse) time, all these issues complicate the error checking process, > but the intent of the LRM is clear. I don't' think we should change > the declaration-before-use rules at this point because sorting through > all the issues will create a lot of incompatibility issues and further > stress the error checking. I consider Shalom's example a tool bug -- > an error should be issued in that case. > > Arturo > > *From:*owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of > *Francoise Martinolle > *Sent:* Friday, December 06, 2013 11:09 AM > *To:* Daniel Mlynek; Greg Jaxon > *Cc:* Bresticker, Shalom; Datta, Kausik; 'SV_BC List' > *Subject:* RE: [sv-bc] use before declaration > > The LRM is definitively not super clear about this. > > There is a section 23.7 which talks about how member selects and > hierarchical names (both represented as a dotted name) have to be > resolved. > > (see extract below). > > When a dotted name is encountered at its point of appearance, the > first name in the sequence is resolved as > > though it were a simple identifier. The following are the possible > results: > > a) The name resolves to a data object or interface port. The dotted > name shall be considered to be a > > select of that data object or interface port. > > b) The name resolves to a directly visible scope name. The dotted name > shall be considered to be a > > hierarchical name. > > If you try to apply the algorithm above, you try to resolve t as a > simple identifier, since declarations must appear before simple > identifiers usage (no forward references), It seems to me that that > 't' declaration below cannot be considered as a candidate to resolve t.s. > > But then do we consider this 't' to be a hierarchical reference and > try to resolve it upwards or should the search stop (and an error be > produced) as soon as we found that there is a declaration named t but > it is a forward reference. > > The LRM is not clear about what should happen in that case, I think > that the search should stop since we matched the simple name to a > declaration and that declaration is a struct. > > Francoise > > ' > > *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> > [mailto:owner-sv-bc@eda.org] *On Behalf Of *Daniel Mlynek > *Sent:* Friday, December 06, 2013 3:38 AM > *To:* Greg Jaxon > *Cc:* Bresticker, Shalom; Datta, Kausik; 'SV_BC List' > *Subject:* Re: [sv-bc] use before declaration > > Maybe LRM should be changed here to reflect real life and simple > reference should mean not dotted reference (just a var name) or it > should be removed at all (we should allow forard var references): > "A variable declaration shall precede any simple reference > (non-hierarchical) to that variable." > > Otherwise I find contradition in LRM position : > - one the one hand t.s reference prior to t declaration should be > treat like upward reference or hier reference so no error should occur > at the moment when t.s is spotted in the code ( I do not think that > implicit wire t should be done here) > - on the other hand identifier "t" is declared later as variable so > LRM wants that error should be triggered as it is unknown > - from user perspective "t.s" should be reference to t variable > declared later - basing on rules for dotted name in chapter 23.7 "The > name resolves to a data object or interface port. The dotted name > shall be considered to be a select of that data object or interface port." > > So rule cited by Mr Shalom - which as I suppose should limit the > number of compiler passes through the code - need to be ignored in > real life. > > DANiel > > W dniu 12/5/2013 8:47 PM, Greg Jaxon pisze: > > Shalom, > Speaking for just one compiler, I'd say the reason is "legacy > non-standard extension". > The following message issues with "warning" severity -- at some > design houses that is tantamount to "error", making the threat > almost redundant. > > Forward references to 't' are non-standard. This may be treated as an error in the future. (VER-733) > > Kausik's description is accurate, the resolution of "t" in the > wire initializer is deferred until the end of w's block. > I am not sure why your observation didn't suffice; maybe once the > extended behavior was established, decl-of-t was too-early a > detection point, since the final resolution is still pending. > Other complications there include non-ANSI port names. > > Greg Jaxon > Disclaimer: This opinion does not constitute Synopsys' voting > position, nor any specific product warranty. > > On 12/5/2013 7:47 AM, Bresticker, Shalom wrote: > > But it seems to me that when the compiler reach the > declaration of t, there are only two possible conclusions: > > either t was referenced before its declaration, or there is a > duplicate declaration. > > Shalom > > *From:*Datta, Kausik [mailto:Kausik_Datta@mentor.com] > *Sent:* Thursday, December 05, 2013 15:45 > *To:* Bresticker, Shalom; 'SV_BC List' > *Subject:* RE: [sv-bc] use before declaration > > Hi > > This is because of compiler can only check for this error > after reaching endmodule and that check will be based on the > relative position of "t.s" and "t" if they are in the same > file or relative time of processing of "t.s" and "t" by the > compiler if they are in different files. I don't think > compiler developers will like to add this checking in code. > > Thanks > > Kausik > > *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> > [mailto:owner-sv-bc@eda.org] *On Behalf Of *Radoslaw Nawrot > *Sent:* Thursday, December 05, 2013 6:34 PM > *To:* 'Bresticker, Shalom'; 'SV_BC List' > *Subject:* RE: [sv-bc] use before declaration > > I think that reference to t is a selection. Looks that > (bacause of identical syntax) tool's have problem with that. > BTW "non-hierarchical " supervene only one time in LRM. Maybe > this word should be changed or Glossary should be updated , > > Radek > > ------------------------------------------------------------------------ > > *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> > [mailto:owner-sv-bc@eda.org] *On Behalf Of *Bresticker, Shalom > *Sent:* Thursday, December 05, 2013 1:42 PM > *To:* SV_BC List > *Subject:* [sv-bc] use before declaration > > Hi, > > Why does the following not fail compilation? > > module test; > > wire w = t.s ; > > struct { logic s; } t; > > endmodule > > 6.21 says, "A variable declaration shall precede any simple > reference (non-hierarchical) to that variable." > > The reference to t is non-hierarchical, isn't it? > > Thanks, > > Shalom > > Shalom Bresticker > Communications & Storage Infrastructure Group Silicon Engineering > > Intel Jerusalem, Israel > +972 2 589 6582 (office) > +972 54 721 1033 (cell) > http://www.linkedin.com/in/shalombresticker > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential > material for > the sole use of the intended recipient(s). Any review or > distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential > material for > the sole use of the intended recipient(s). Any review or > distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > and is > believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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 Dec 6 14:11:00 2013
This archive was generated by hypermail 2.1.8 : Fri Dec 06 2013 - 14:11:09 PST