Manisha-- Most of it looks good, but I'm not sure we are specifying the correct action for FailOn and FailOff:
------------
- FailOn: A value of 8 for this argument shall enable execution of the fail action of all the specified assertions and expect statements. An assertion that is already executing, including execution of the pass or fail action, is not affected. This task also affects the execution of the default fail action block. A value of 8 for
this argument shall also enable issuing of violation reports for the specified violation report types. This control_type value does not affect violation report types.
- FailOff: A value of 9 for this argument shall stop execution of the fail action of all the specified assertions and expect statements until a subsequent $assertcontrol with a control_type value of 8 (FailOn). An assertion that is already executing, including execution of the pass or fail action, is not affected. By default, the fail action is executed. This task also affects the execution of default fail action block, i.e., $error, which is called in case no else clause is specified for the assertion. This control_type value does not affect violation report types.
---------------
Right now, if an assertion has no explicit fail action block, will FailOn/FailOff affect the implicit $error? I think the answer is yes, based on the text in 16.3: "If an assert statement fails and no else clause is specified, the tool shall, by default, call $error, unless
$assertcontrol with control_type 9 (FailOff) is used to suppress the failure."
assert ( my_cond); // no explicit message, but FailOff can deactivate the implicit $error
If so, then I think FailOn/FailOff should also affect the unique/priority violation reports.
-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Monday, July 02, 2012 12:18 AM
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: [sv-ac] RE: mantis 3474: proposal added
Hi,
I have uploaded new version of the proposal which uses existing ON/OFF/KILL control types to control violation reports also. Also, please read motivation section about why I am not extending control types for action blocks for now. Please review.
Thanks.
Manisha
-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Thursday, June 28, 2012 7:16 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added
Hi Manisha,
Several minor comments:
* This task also provides capability to control the violation report creation from unique, unique0 and priority if and case constructs based on construct type (see 12.4.2 and 12.5.3).
Should be
This task also provides *the* capability to control the violation report creation from unique, unique0 and priority if and case constructs based on construct type (see 12.4.2 and 12.5.3).
* "expect" should be typeset as a keyword (bold courier new 9).
Thanks,
Dmitry
-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Monday, June 25, 2012 08:12
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added
Hi,
I have uploaded a new version which includes case statements also. Please review.
Thanks.
Manisha
-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Saturday, June 23, 2012 11:04 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added
Hi Manisha,
This is fine with me.
Dmitry
-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Friday, June 22, 2012 20:06
To: Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: [sv-ac] RE: mantis 3474: proposal added
Hi Dimitry,
I am thinking about combining same type of if and case together e.g. unique-if and unique-case will be controlled by the same option. Do you see any issues with that? Keeping them separate will add three more entries in the table. What do you think?
Manisha
-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Friday, June 22, 2012 6:00 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added
Hi Manisha,
I think unique and priority case should also be added.
Thanks,
Dmitry
-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Kulshrestha, Manisha
Sent: Friday, June 22, 2012 08:41
To: sv-ac@eda-stds.org
Subject: [sv-ac] mantis 3474: proposal added
Hi,
I have added a proposal for mantis 3474 for controlling violation reports using assertion control tasks. Please review and send me your comments.
Thanks.
Manisha
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.
Received on Mon Jul 2 09:53:04 2012
This archive was generated by hypermail 2.1.8 : Mon Jul 02 2012 - 09:53:23 PDT