RE: [sv-ac] Example shown in LRM contradicts local variable restriction

Well, I got confused by example illegal_loc_var_formal. Now, I also
think the text is incorrect. But I think this text has some meaning when
users do not specify 'local' in the formal's type. In the last paragraph
of 16.8.2, it says "Untyped arguments provide an alternative mechanism
for passing local variables to an instance of a subsequence, including
the capability to assign to the local variable in the subsequence and
later reference the value assigned in the instantiation context". 

 

So, from this it looks like, either users have to specify type along
with 'local' in the formal or it has to be untyped if it is used as
local variable.

 

Thanks.

Manisha

 

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Wednesday, December 31, 2008 5:36 PM
To: Kulshrestha, Manisha; Surya Pratik Saha; sv-ac@server.eda.org
Subject: RE: [sv-ac] Example shown in LRM contradicts local variable
restriction

 

Hi, Manisha.

 

Where does the text in 16.8.2 say, or even imply, that this rule applies
only if the argument is used as an output, but not as inout?

 

Thanks,

Shalom

	 

	
________________________________


	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Kulshrestha, Manisha
	Sent: Wednesday, December 31, 2008 1:51 PM
	To: Surya Pratik Saha; sv-ac@server.eda.org
	Subject: RE: [sv-ac] Example shown in LRM contradicts local
variable restriction

	Hello Surya,

	 

	Please check clause 16.8.2 for more details. The example below
is correct and also the text. The rule that the 'corresponding formal
argument shall be untyped' only applies if the argument is used as
output (i.e. it is only assigned but not read). There are few examples
in 16.8.2 which make it more clear. Since this example and the text are
from different sections and from different mantis items, it is
confusing.

	 

	Manisha

	 

	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Surya Pratik Saha
	Sent: Wednesday, December 24, 2008 12:41 PM
	To: sv-ac@server.eda.org
	Subject: [sv-ac] Example shown in LRM contradicts local variable
restriction

	 

	Hi,
	In SV 2009 draft LRM, there is an example:
	sequence sub_seq2(local inout int lv);
	(a ##1 !a, lv += data_in)
	##1 !b[*0:$] ##1 b && (data_out == lv);
	endsequence
	sequence seq2;
	int v1;
	(c, v1 = data)
	##1 sub_seq2(v1) // lv is initialized by assigning it the value
of v1;
	// when the instance sub_seq2(v1) matches, v1 is
	// assigned the value of lv
	##1 (do1 == v1);
	endsequence
	
	And later it is mentioned:
	It can be useful to assign a value to a local variable within an
instance of a named sequence and reference the
	local variable in the instantiating context at or after the
completion of a match of the instance. This capability
	is supported under the following conditions:
	- The local variable shall be declared outside the named
sequence, and its scope shall include both the
	instance of the named sequence and the desired reference in the
instantiating context.
	- The local variable shall be passed as an entire actual
argument in the list of arguments of the
	instance of the named sequence.
	- The corresponding formal argument shall be untyped.
	
	Whereas, in the example corresponding formal argument 'lv' is
not untyped for local variable 'v1'. Am I missing anything?

	-- 
	Regards
	Surya

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

	-- 

	This email was Anti Virus checked by Astaro Security Gateway.
http://www.astaro.com

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