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

>
>
> Should
> let ALL_ASSERTS = (CONCURRENT|S_IMMEDIATE|D_IMMEDIATE|EXPECT);
> be changed to
> let ALL_ASSERTS = (CONCURRENT|S_IMMEDIATE|D_IMMEDIATE|EXPECT|
> UNIQUE|UNIQUE0|PRIORITY);
>
> Ben
>
> On Thu, Jul 5, 2012 at 10:39 PM, Kulshrestha, Manisha <
> Manisha_Kulshrestha@mentor.com> wrote:
>
>> 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 Fri Jul 6 12:41:12 2012