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

 
  _____  

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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.