RE: [sv-ac] New Types proposal - 1549.

Hi Bassam,

In that text, I am talking about how to pass a formal argument that is
used as an event_control in the assertion.  We can't send the exact
"event_control" syntax that includes the @, but we can send the rest
since any event expression is allowed.  It is a valid question whether
we can send a * or (*) as an actual with the current definition of
event_expression. 

lisa

-----Original Message-----
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Friday, July 28, 2006 1:43 PM
To: Lisa Piper; Bassam Tabbara
Subject: RE: [sv-ac] New Types proposal - 1549.

I meant the following BNF of proposal:

event_expression ::=
[ edge_identifier ] expression [ iff expression ]
| sequence_instance [ iff expression ]
| event_expression or event_expression
| event_expression , event_expression
| ( event_expression )

I thought the BNF above reflects the latest agreed on form with no
hierarchical/*/(*) ... I don't get why the text talks of event_control
instead of event_expression, am I missing something ? 

Thx.
-Bassam.

-----Original Message-----
From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Friday, July 28, 2006 8:32 AM
To: Bassam Tabbara
Subject: RE: [sv-ac] New Types proposal - 1549.

Bassam,

I am referencing A.6.5 event_control in IEEE1800-2005.pdf.  Is there a
"later BNF"?  Sorry!

lisa

-----Original Message-----
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
Sent: Friday, July 28, 2006 10:56 AM
To: Lisa Piper; Bassam.tabbara@synopsys.com; sv-ac@eda-stds.org
Subject: Re: [sv-ac] New Types proposal - 1549.

Hi Lisa,

The text seems to have * and (*) etc... Basically inconsistent with the
latest BNF and needs update.

THX. 
-Bassam

-----Original Message-----
From: Lisa Piper <piper@cadence.com>
To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda-stds.org
<sv-ac@eda-stds.org>
Sent: Fri Jul 28 05:09:02 2006
Subject: RE: [sv-ac] New Types proposal - 1549.

Hi Bassam,

 

I don't understand the comment about event_expression text.  What is
wrong with it?

 

Regarding "anytype", "implicit" does sound nice.  I will wait for more
discussion before making any updates though.

 

Lisa

 

________________________________

From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
Sent: Thursday, July 27, 2006 11:11 PM
To: Lisa Piper; sv-ac@eda-stds.org
Subject: RE: [sv-ac] New Types proposal - 1549.

 

Hi Lisa,

 

Top of page 5, the allowed event_expression text needs update. Also
"anytype" bugs me, ideally I would suggest "implicit" or
"implicit_type", may be we can brainstorm on that one at the meeting.

 

Thx.

-Bassam.

 

 

________________________________

From: owner-sv-ac@eda-stds.org [mailto:owner-sv-ac@eda-stds.org] On
Behalf Of Lisa Piper
Sent: Thursday, July 27, 2006 12:14 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] New Types proposal - 1549.

I have filed a new entry in Mantis - #1549, to add the new types that
were discussed in connection with #928.

Formal arguments to properties and sequences are currently defined for
some but not all possible types. The objective of this proposal is to
expand the list of types so that everything that is allowed to be passed
as an argument can be passed as a typed argument. 

The standard currently defines only operand types (per 17.4.1).
Arguments that are not covered by the current type definitions include
"property", "sequence", "events", and "anytype".  The "anytype" is
introduced to allow arguments that do not have any data type
restrictions to be mixed freely with those that do. 

New Types are proposed as follows:

o        sequence: sequence instances are passed as type sequence

o        property:  property instances are passed as type property

o        event: this is used for passing arguments (4.8) that are used
for clocking purposes

o        anytype: used when there are no data type restrictions, meaning
that any type is acceptible. The implicit type (that of the declaration
of the argument) is used for any semantic checks.  This is equivalent to
listing the argument prior to any typed arguments. 

 

Examples have been improved.

The attached proposal describes the detailed changes that will be
required in the standard.  All changes are RELATIVE to the revisions of
Mantis 928. Also, #1532: "Remove @sequence_instance from event_control
to take care of sequences with arguments" is assumed.