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

Yes, this looks as a bug also to me. Surya, you are welcome to file a Mantis item about it. I also found the same issue in legal_loc_var_formal and illegal_loc_var_formal examples.

Thanks,
Dmitry

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Wednesday, December 31, 2008 8:01 PM
To: Bresticker, Shalom; Surya Pratik Saha; sv-ac@server.eda.org
Subject: 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<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.