RE: [sv-ac] RE: Mantis 3295: assertion control system tasks

Hi Tom,
 
Please include this in the discussion today.
 
Manisha

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Monday, June 27, 2011 6:27 PM
To: sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: Mantis 3295: assertion control system tasks

The syntax includes list_of_modules_or_assertions.

I realize that this did not originate in the current proposal, but it
should not be limited to modules. First, it refers to scope names, not
module names, and second, it is not limited to modules. It also applies
to other types of design elements.

This would be a good time to fix it.

Regards,

Shalom

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Friday, June 24, 2011 9:35 AM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: Mantis 3295: assertion control system tasks

'directive' is used in Clause 16 only twice, and never in a general
sense.

In 16.4: - Syntax: Deferred assertions use #0 after the verification
directive.

In 16.13.9: A followed-by operator is especially convenient for
specifying a cover property directive over a sequence followed by a
property.

Regards,

Shalom

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Friday, June 24, 2011 8:41 AM
To: Bresticker, Shalom; sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: Mantis 3295: assertion control system tasks

Hi Shalom,

There was no reason for keeping assert_task and assert_action_task BNF
separate. I just kept it same as in the previous version. Same goes with
tables 20-8 and 20-9.

You are right about tables 20-5 to 20-7, they are specific to
$assertcontrol.

About calling 'assert', 'cover' etc. directives, looks like they should
be called 'assertion statement kind' based on 16.2. But that is similar
to 'assertion type' that we use for distinguishing different assertions
like Immediate vs. Concurrent. The word directive is used in section 16
but not formally defined although we use this term while discussing
assertions. Any suggestions ?

Thanks.

Manisha

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Thursday, June 23, 2011 12:56 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] RE: Mantis 3295: assertion control system tasks

Also, this proposal refers to "assert", "cover", and "assume" as
"directives".

This is not consistent with the terminology in Clause 16.

Shalom

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Wednesday, June 22, 2011 11:58 AM
To: sv-ac@eda-stds.org
Subject: [sv-ac] Mantis 3295: assertion control system tasks

Hi,

I have not been following this issue closely, but I looked at the
proposal now, and I want to ask whether there is a reason not to combine
the assert_task and and assert_action_task BNFs.

Similarly, is there a reason not to combine Tables 20-8 and 20-9?

Also, the titles of Tables 20-5 to 20-7 refer to
"assertion_control_tasks", but it looks like they are specific to
$assertcontrol.

Regards,

Shalom

Shalom Bresticker

Intel LAD DA, Jerusalem, Israel

+972 2 589 6582 (office)

+972 54 721 1033 (cell)

http://www.linkedin.com/in/shalombresticker

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