Re: [sv-ac] another small flaw in 1549 Annex F

Hi Manisha:

There is not general agreement on how to cast $ into a type
or whether to treat it as a "special value" that is not 
really cast.  There has been criticism of the example of 
assigning $ to an int parameter.

See the discussion in the description and notes of Mantis 
items 1982, 1350, and 0966.

I don't think we have time to converge on these questions for
this revision of the LRM.

By restricting the way $ is passed, we can avoid having to
solve these problems now without creating any additional backward 
compatibility traps.

J.H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 1 Oct 2007 02:52:35 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] another small flaw in 1549 Annex F
> Thread-Index: AcgDiDeu8sCpBG9hQg+pTFSsK1U6SwAatbtA
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> X-OriginalArrivalTime: 01 Oct 2007 09:52:37.0157 (UTC) FILETIME=[CC2D5550:01C80410]
> 
> Hi John,
> 
> I was just wondering why we are putting this restriction about having
> untyped arg for passing '$'. In general in the LRM '$' can be assign to
> int types. Here is an example for $isunbounded in 19.6.3:
> 
> parameter int foo =3D $;
> 
> "The terminal $ may be an actual argument in an instance of a named
> sequence, either declared as a default actual argument or passed in the
> list of arguments of the instance.  If $ is an actual argument, then the
> corresponding formal argument shall be untyped and each of its
> references either shall be an upper bound in a
> cycle_delay_const_range_expression or shall itself be an actual argument
> in an instance of a named sequence."
> 
> Thanks.
> Manisha
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of John Havlicek
> Sent: Sunday, September 30, 2007 11:04 PM
> To: sv-ac@server.eda-stds.org
> Subject: [sv-ac] another small flaw in 1549 Annex F
> 
> Hi Folks:
> 
> I am really trying to finish with 1549 Annex F changes.
> 
> I found another small flaw.  It amazes me how troublesome parentheses
> are.
> 
> The flatten_property function returns a parenthesis-enclosed
> expression.  If a "disable iff" appears inside the declaration of a
> named property that is instantiated as the top-level property in an
> assertion directive, then the result is that the "disable iff" is
> enclosed in an extra set of parentheses.
> 
> On this point, we need to use the abstract syntax to judge what is
> legal because the extra parentheses are not allowed in the Annex A
> syntax.
> 
> The extra parentheses are already allowed in the abstract syntax if
> there is a local variable declaration, but they are not allowed if
> there is no local variable declaration.
> 
> I have puzzled about how to fix this easily.  The best way I have
> thought of is to add a "parenthesis" form for the top-level property
> grammars for T and U.  This means adding some trivial cases to the
> top-level satisfaction relations, but that is not hard.  I just have
> to go find that other Mantis item that is already fixing the
> descriptions of those relations to ensure that the changes are
> aligned.
> 
> Comments or alternative suggestions?
> 
> J.H.
> 
> --=20
> This message has been scanned for viruses and
> dangerous content by 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.