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

From: Kulshrestha, Manisha <Manisha_Kulshrestha_at_.....>
Date: Mon Oct 01 2007 - 02:52:35 PDT
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 = $;

"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.

-- 
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.
Received on Mon Oct 1 02:53:07 2007

This archive was generated by hypermail 2.1.8 : Mon Oct 01 2007 - 02:53:13 PDT