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

I don't agree with Arturo's suggestion about the class name binding;
I'll respond separately on that.

Daniel Mlynek wrote:
> 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. 

I'll respond separately on this point -- I disagree with Arturo on
this point.

 >  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

Yes, this should be an error (if you ignore legacy considerations).

There are some historical reasons why "$display" is a bad example
to use.  The rules for name lookup for a systf allow a hierarchical
lookup of a "scope" (clarified recently) but some implementations
allow any name to be treated "hierarchically" (similar to a function
or task "forward" name resolution).  A better example is:

   module top;
    int j;
    initial j = i;
    int i=123;
   endmodule

for which I would expect all implementations to produce an error.


> 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


Yes, the result should be 123.

Again, something like:

  module top;
   int i=123;
   module nest;
    int j = i;
    initial $display(j);
    int i=456;
   endmodule
  endmodule

removes the legacy interactions that $display might have in some
implementations.


> **)
> module top;
>  int i=123;
>  function automatic f;
>   int j=i;
>   int i=456;
>   $display(j); 
>  endfunction
>   
>  initial f();
> endmodule


This should also be 123.


> If so then this should surely be described - because this all is far 
> from obvious.

Certainly that is the true.

We spent a large amount of time working through name resolution
issues and rules to even get to the point that we're at now.

There are certainly still differences of opinion at
both the philosophical level and the implementation level.
It would have been far better to have additional input
and effort during the process; at this point it is too late
to revisit this in terms of the 2009 spec so there will
certainly be some divergence that will become somewhat
entrenched in vendor implementations.  Resolving these
questions in the next PAR will not be easy.


Gord.



>  
> DANiel
> 
>  
> ------------------------------------------------------------------------
> *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> *Sent:* 4 września 2008 21:22
> *To:* Rich, Dave; Daniel Mlynek; sv-bc@eda-stds.org
> *Cc:* Mirek Forczek; Piotr Winter; Sergei Zaychenko
> *Subject:* RE: [sv-bc] declaration vs reference order issue
> 
> Dave,
> 
>  
> 
> This has been discussed in the past - in the context of randomize-with 
> and package imports. The only consistent way to deal with the 2 cases 
> that Daniel shows is to resolve all class references to the class, that 
> is, in the two examples, an undecorated 'i' always refers to the one 
> inside the class -- both cases should display 2. This is similar to the 
> way in which C++ handles class members: undecorated references to class 
> members always resolve within the class, regardless of the declaration 
> order. And, like SV, C++ also has a declaration-before use rule for 
> other identifiers. BTW, don't forget that resolving names in classes 
> must also consider the inheritance hierarchy, for example:
> 
>  
> 
> int v = 1;
> 
>  
> 
> class B;
> 
>   static int v = 2;
> 
> endclass
> 
>  
> 
> class C extends B;
> 
>   static int w = v;            // this 'v' resolves to the base class 
> B::v (2)
> 
> endclass
> 
>  
> 
> On another note, whether the compiler is a single-pass or multiple-pass 
> is definitely an implementation issue that should not be mandated by the 
> LRM. I recall that Mark Hartoog had proposed a scheme that would support 
> all this, but I don't see it in the text.
> 
>  
> 
>             Arturo
> 
>  
> 
> *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of 
> *Rich, Dave
> *Sent:* Thursday, September 04, 2008 8:49 AM
> *To:* Daniel Mlynek; sv-bc@eda-stds.org
> *Cc:* Mirek Forczek; Piotr Winter; Sergei Zaychenko
> *Subject:* RE: [sv-bc] declaration vs reference order issue
> 
>  
> 
> Mantis 2106 added to 6.21
> 
>  
> 
> A variable declaration shall precede any simple reference 
> (non-hierarchical) to that variable.
> 
>  
> 
> So there can be no tool dependence on this issue. Customers certainly do 
> not like when code compiles on one simulator and not on another. The 
> begrudgingly accept order of evaluation dependencies only if a single 
> implementation cannot guarantee ordering.
> 
>  
> 
> For case 2, I thought we had added text that defines the search rules 
> from the point of the source code, but I can't seem to find it. But 
> given the rule above, there's no way $display(i) can refer to this.i and 
> display 2.
> 
>  
> 
> Dave
> 
>  
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] 
> *On Behalf Of *Daniel Mlynek
> *Sent:* Thursday, September 04, 2008 2:53 AM
> *To:* sv-bc@server.eda-stds.org
> *Cc:* 'Mirek Forczek'; 'Piotr Winter'; 'Sergei Zaychenko'
> *Subject:* [sv-bc] declaration vs reference order issue
> 
>  
> 
> CASE1:
> 
> Does LRM defines rules on how tool should behave if reference to 
> an identifier which is unknown at this point of source code.  Idetnifier 
> is delcared later in code (case1). LRM specifies that both single pass 
> parser and multi pass parser may be used for parsing SV code (LRM:" 
> Implementations may execute compilation in one or more passes") It is 
> obvious that single pass compiler will fail on case like below, while 
> mutli pass can handle with that. So this should be tool dependend if 
> CASE would pass compilation?
> 
>  
> 
> 2nd case is connected - what should happend if in current scope and in 
> higher scope there is an identifier declared. But in current scope 
> declaration is place in code after reference - so which one should be 
> printed by case2. Is it defined or tool dependend?
> 
>  
> 
> LRM:22.9 says:"If an identifier is referenced directly (without a 
> hierarchical path) within a task, function, named block, or generate 
> block, it shall be declared either within the task, function, named 
> block, or generate block locally or within a module, interface, program, 
> task, function, named block, or generate block that is higher in the 
> same branch of the name tree that contains the task, function, named 
> block, or generate block. If it is declared locally, then the local item 
> shall be used; if not, the search shall continue upward until an item by 
> that name is found or until a module,  interface, or program boundary is 
> encountered."
> 
> So imho in both cases "2" should be displayed
> 
>  
> 
>  
> 
>  
> 
> CASE1: 
> 
> module top;
> 
>  
> 
>    class nested;
>        function new ();
>               $display(i);    //  displaying "i" - this should be a 
> failure - as i is unkcnown since here, or 2 shoudl be displayed?
>       endfunction
>       int i = 2;               // local member "i"
>    endclass
> 
>  
> 
>    nested n_inst = new();
> 
>  
> 
> endmodule
> 
>  
> 
> CASE2:
> 
> module top;
>     bit [2:0] i = 0;   // static member "i"
> 
>  
> 
>    class nested;
>        function new ();
>               $display(i);    //  displaying "i" - which i would be 
> displayed - ???????????????
>       endfunction
>       int i = 2;               // local member "i"
>    endclass
> 
>  
> 
>    nested n_inst = new();
> 
>  
> 
> endmodule
> 
>  
> 
>  
> 
>  
> 
> DANiel
> 
> 
> -- 
> 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.

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