RE: [sv-bc] use before declaration

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, and is
believed to be clean.