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

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Fri Sep 05 2008 - 07:20:55 PDT
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.
 
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, and is
believed to be clean.
Received on Fri Sep 5 07:22:44 2008

This archive was generated by hypermail 2.1.8 : Fri Sep 05 2008 - 07:23:37 PDT