RE: [sv-bc] declaration vs reference order issue

Gord,

With due respect, binding the same identifier in the same scope to two
different objects makes no sense. 
How can users debug such situations? When users enter the multiply bound
expression in their favorite debugger, which value is printed? What does
a VCD dump show? Are line numbers (or code position) to become part of
the scope?

I've understood "point of reference" to mean "the scope containing the
reference", certainly not the lexical position of the reference.

It is true that some of these issues were discussed, but we lacked
consensus to resolve all the issues. Simply quoting the LRM, which we
know to be deficient in this respect, to prove a particular
interpretation is not very useful.

	Arturo

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, September 05, 2008 7:52 AM
To: Bresticker, Shalom
Cc: Daniel Mlynek; Arturo Salz; Rich, Dave; sv-bc@eda-stds.org; Mirek
Forczek; Piotr Winter; Sergei Zaychenko
Subject: Re: [sv-bc] declaration vs reference order issue



Bresticker, Shalom wrote:
> Case 1 is clearly illegal.
>  
> Cases 2 and 3 relate to situations where an identifier is referenced, 
> there is a preceding declaration in an outer scope, and there is a
later 
> declaration in the same scope as the reference. The LRM is not clear 
> about this situation, and it was discussed in Mantis 1268, but not 
> resolved.
>  
> What I have seen implemented in tools is to reference the outer 
> declaration until the point of the inner declaration and to reference 
> from there on the inner declaration, but this has indeed not been 
> explicitly specified yet.



 From 1809:

    For a reference to an identifier other than function or task call,
    the locally visible identifiers defined at the point of the
reference
    in the current scope shall be searched. ...

    If no locally visible identifiers match, then the potentially
locally
    visible identifiers defined prior to the point of the reference in
the
    current scope shall be searched. ...

    If the reference is not found within the current scope, the next
outer
    lexical scope shall be searched; ...

The rules here are clearly based from "the point of reference" in the
first part.  Certainly that was the intent of all of the rules and
all the special case rules for task and function "forward" resolution.

The $unit rules in 1809 are also in sync:
    Next, the portion of the compilation-unit scope defined prior to the
    reference is searched

So I think that 1809 makes cases 2 & 3 pretty clear -- the outer "i" is
in
fact the one that is used.  The meaning of a (non-task/function)
reference
can change in the middle of a nested scope as they would in Daniel's
examples.

Gord.




> Regards,
> Shalom
> 
>
------------------------------------------------------------------------
>     *From:* owner-sv-bc@server.eda.org
>     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Daniel Mlynek
>     *Sent:* Friday, September 05, 2008 10:36 AM
>     *To:* 'Arturo Salz'; 'Rich, Dave'; sv-bc@server.eda-stds.org
>     *Cc:* 'Mirek Forczek'; 'Piotr Winter'; 'Sergei Zaychenko'
>     *Subject:* RE: [sv-bc] declaration vs reference order issue
> 
>     THX for responce.
>     I'm getting used to that I get contradictory anwsers from each
>     vendor specialist;) Maybe this is also feature which need to be
>     explicitly addressed - as both of you cannot point LRM text
>     resolvinf the issue. If I can I would choose Arturo's point of
view
>     is more in this case. But I've additional question:
>     case 1 - so for modules the rule : "A variable declaration shall
>     precede any simple reference (non-hierarchical) to that variable.
"
>     is broken in below code - and it should return compiler error?
>     module top;
>      initial $display(i);
>      int i=123;
>     endmodule
>     case2; In below cases classes search rules that local identifier
>     always take precedence  should not work and the results should be
123
>     *)
>     module top;
>      int i=123;
>      module nest;
>       initial $display(i); 
>       int i=456;
>      endmodule
>     endmodule
>     **)
>     module top;
>      int i=123;
>      function automatic f;
>       int j=i;
>       int i=456;
>       $display(j); 
>      endfunction
>       
>      initial f();
>     endmodule
>      
>     If so then this should surely be described - because this all is
far
>     from obvious.
>      
>     DANiel
> 
> ---------------------------------------------------------------------
> 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.

-- 
--------------------------------------------------------------------
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.