[sv-ac] RE: mantis 3474: proposal added

Hi Erik,

Currently violation reporting has no relation with assertions defined in Assertions chapter. None of the assertions related features work on them. There is no mention that there is an implicit immediate assert for violation reporting. Unless the language in 12.4 and 12.5 sections is modified and it is stated that they behave as if there is an implicit deferred immediate assertion with default action block, it is going to be confusing for the users what exactly FailOn/FailOff do.

Thanks.
Manisha

-----Original Message-----
From: Prabhakar, Anupam
Sent: Friday, July 06, 2012 4:06 AM
To: Seligman, Erik; Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

Based on the reasoning mentioned in my previous email I would not like FailOff(FailOn) to be same as Off(On) for unique/priority - it does not add any value either. In my opinion use of FailOff/FailOn is very limited and anyone using this is probably only interested in some coverage numbers. To turn off/on assertions or violations On/Off control_type should be used and this will be the more common usage. In the next PAR we can work on aligning different aspects of these violations with immediate assertions.

Anupam

-----Original Message-----
From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Thursday, July 05, 2012 12:53 PM
To: Prabhakar, Anupam; Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

The fundamental principle I want to see preserved is:

- An implicit unique/priority violation check is treated exactly as if there had been an explicit immediate assertion at that line with the same logic.

So, whatever reasoning was originally used to apply On/Off vs FailOn/FailOff to immediate assertions with no action blocks, that same reasoning should be used to determine how these apply to the unique/priority violations.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Prabhakar, Anupam
Sent: Thursday, July 05, 2012 12:37 PM
To: Seligman, Erik; Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: [sv-ac] RE: mantis 3474: proposal added

Hi Eric,

As per the LRM
'If an assert statement fails and no else clause is specified, the tool shall, by default, call $error ...'
I consider this as a default action block. So yes, I would expect FailOn/FailOff to apply to these.
Users can have their assertions 'on' and have FailOff and can still use the assertion counts in a meaningful way.

You argument is that unique/priority should be same as any other assertion and I see your point. But should FailOff be same as Off ? Are simulators required to maintain counts for these ? If these are similar to assertions then a future version of the LRM may clarify that we have to maintain counts for these violations also. Then we will need to change the behavior of FailOff for these violations - no ?

Anupam

-----Original Message-----
From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Thursday, July 05, 2012 12:02 PM
To: Prabhakar, Anupam; Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

But Anupam-- in that case, would you expect FailOn/FailOff to apply to an immediate assert with no action block?

   assert ( my_cond); // no explicit message, but FailOff can deactivate the implicit $error

-----Original Message-----
From: Prabhakar, Anupam [mailto:anupam_prabhakar@mentor.com]
Sent: Thursday, July 05, 2012 11:46 AM
To: Seligman, Erik; Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

My 2 cents ...
FailOn/FailOff (and PassOn/PassOff) are specifically to control action blocks. If unique/priority violations don't have an action block then it does not make sense for FailOn/FailOff to affect these.

We could also leave the description of FaillOn/FailOff as is (without saying it does not apply to violation reports) in the proposal and maybe in the next PAR you can add the concept of default action blocks for violation checks and then FailOn/FailOff would apply to these also.

Anupam

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Thursday, July 05, 2012 10:33 AM
To: Kulshrestha, Manisha; Korchemny, Dmitry; Bresticker, Shalom; sv-ac@eda-stds.org
Subject: [sv-ac] RE: mantis 3474: proposal added

Hi guys-- I'm OK with considering a "violation check" and a "violation report" to be synonyms-- but then the FailOn and FailOff should still affect the violation reporting. Please take another look at the original point I made:

--------

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.

--------

I believe this comment still applies. Just like for the standalone immediate assertion, On/Off and FailOn/FailOff should turn the reports on and off. Having both may be somewhat redundant, but I believe having FailOff turn off the immediate assertion report without turning off similar unique/priority violation reports will be very confusing to users.

-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Thursday, July 05, 2012 5:11 AM
To: Korchemny, Dmitry; Bresticker, Shalom; Seligman, Erik; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

Hi,

I have uploaded another version taking Shalom's comments into account. Please review.

Thanks.
Manisha

-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Wednesday, July 04, 2012 7:27 PM
To: Kulshrestha, Manisha; Bresticker, Shalom; Seligman, Erik; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

Hi Manisha,

This is fine with me.

Dmitry

-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Wednesday, July 04, 2012 15:03
To: Bresticker, Shalom; Seligman, Erik; Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

Hi Erik/Dimitry,

I would like you guys to consider this one more time and let us know what you think about this. I would prefer to control violation reporting only with ON/OFF/KILL. Specially because according to sections 12.4 and 12.5, the only effect of violation checks is violation report.

Thanks.
Manisha

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Wednesday, July 04, 2012 5:26 PM
To: Kulshrestha, Manisha; Seligman, Erik; Korchemny, Dmitry; sv-ac@eda-stds.org
Subject: RE: mantis 3474: proposal added

If the distinction between violation checks and violation reports is correct and consistent.
Still, keep in mind that people are going to ask whether there is a practical difference.

Shalom

> -----Original Message-----
> From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
> Sent: Wednesday, July 04, 2012 14:44
> To: Bresticker, Shalom; Seligman, Erik; Korchemny, Dmitry; sv-ac@eda-
> stds.org
> Subject: RE: mantis 3474: proposal added
>
> Just for my understanding, you are OK if we control the reports using
> FAILON/FAILOFF controls as long as language makes it clear?
>
> Manisha
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Wednesday, July 04, 2012 5:12 PM
> To: Kulshrestha, Manisha; Seligman, Erik; Korchemny, Dmitry;
> sv-ac@eda- stds.org
> Subject: RE: mantis 3474: proposal added
>
> Thanks, I hope others agree.
>
> Shalom
>
> > -----Original Message-----
> > From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
> > Sent: Wednesday, July 04, 2012 14:40
> > To: Bresticker, Shalom; Seligman, Erik; Korchemny, Dmitry;
> > sv-ac@eda- stds.org
> > Subject: RE: mantis 3474: proposal added
> >
> > Thanks Shalom. I'll make these modifications and upload a new
> proposal.
> > Also will make the distinction between violation checks and reports.
> >
> > Manisha
> >
> > -----Original Message-----
> > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > Sent: Wednesday, July 04, 2012 4:46 PM
> > To: Seligman, Erik; Kulshrestha, Manisha; Korchemny, Dmitry; sv-
> ac@eda-
> > stds.org
> > Subject: RE: mantis 3474: proposal added
> >
> > These are the editorial suggestions I mentioned earlier:
> >
> > 1. You reference 12.4.2 and 12.5.3 at the beginning of 20.12. You
> don't
> > have to do so again when you reference violation reports in the rest
> of
> > the section.
> >
> > 2. unique, unique0, and priority should be in keyword font.
> >
> > 3. In the first paragraph of 20.12,
> >
> > "The violation reporting for unique, unique0 and priority if and
> > case constructs can also be controlled using these tasks (see 12.4.2
> > and 12.5.3)."
> >
> > is better ordered as
> >
> > "The violation reporting for unique, unique0 and priority if and
> > case constructs (see 12.4.2 and 12.5.3) can also be controlled using
> > these tasks."
> >
> > 4. The description of assertion_type can be more concisely worded
> > as,
> >
> > "- assertion_type: This argument selects the assertion and violation
> > report types that are affected by the $assertcontrol system task.
> This
> > argument shall be an integer expression. The valid values for this
> > argument are described in Table 20-6. Multiple assertion_type values
> > can be specified at a time by ORing different values. For example, a
> > task with assertion_type value of 3 (which is the same as
> > Concurrent|SimpleImmediate) shall apply to concurrent and simple
> > immediate assertions. Similarly, a task with assertion_type value of
> > 96 (which is the same as Unique|Unique0) shall apply to unique and
> > unique0 if and case constructs. If assertion_type is not specified,
> > then it defaults to 255 and the system task applies to all types of
> > assertions, expect statements and violation reports."
> >
> > 5. In many places, "violation report types" can be shortened to
> simply
> > "violation reports".
> >
> > 6. In some places, it probably would be more precise to say
> "violation
> > checks" instead of "violation reports". It is like the difference
> > between "assertions" and "action blocks".
> >
> > 7. In the description of control_type Off(4):
> >
> > "A value of 4 for this argument shall also disable the violation
> > reporting from all the specified violation report types (see 12.4.2
> and
> > 12.5.3). Currently queued violation reports are not flushed and may
> > still mature, though no new violation reports shall be added to the
> > violation report queue until a subsequent $assertcontrol with a
> > control_type value of 3 (On).The violation reporting can be re-
> enabled
> > subsequently by $assertcontrol with a control_type value of 3 (On)."
> >
> > "violation report queue" is in code font. It should be in either
> > regular font or italicized regular font. Same in control_type
> Kill(5).
> > The last sentence here appears redundant.
> > Note: "Currently queued violation reports" here are called "pending
> > violation reports" in 12.4.2.1.
> >
> > 8. In the code example, the lines
> >
> > let UNIQUE = 32; // unique if and case violation
> > let UNIQUE0 = 64; // unique0 if and case violation
> > let PRIORITY = 128; // priority if and case violation
> >
> > should be placed after
> >
> > let EXPECT = 16;
> >
> > and there should be a blank line after
> >
> > let PRIORITY = 128; // priority if and case violation
> >
> > to delimit it from
> >
> > LET ASSERT = 1;
> >
> > The line
> >
> > let VACUOUSOFF = 11;
> >
> > should be moved to immediately after
> >
> > let FAILOFF = 9;
> >
> >
> > Shalom
> > --------------------------------------------------------------------
> > -
> > 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.

---------------------------------------------------------------------
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 Thu Jul 5 22:39:57 2012