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, and is believed to be clean.Received on Fri Dec 6 00:38:24 2013
This archive was generated by hypermail 2.1.8 : Fri Dec 06 2013 - 00:38:41 PST