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

And then the terminology has to be used correctly.

Shalom

> -----Original Message-----
> From: Bresticker, Shalom
> Sent: Wednesday, July 04, 2012 14:05
> To: Bresticker, Shalom; Kulshrestha, Manisha; Seligman, Erik;
> Korchemny, Dmitry; sv-ac@eda-stds.org
> Subject: RE: mantis 3474: proposal added
>
> If there is a distinction to make within the scope of the current LRM,
> it is between 'on/off' (of violation check evaluation) and 'report
> on/off' (of violation reports).
>
> Shalom
>
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Bresticker, Shalom
> > Sent: Wednesday, July 04, 2012 13:06
> > To: Kulshrestha, Manisha; Seligman, Erik; Korchemny, Dmitry; sv-
> ac@eda-
> > stds.org
> > Subject: [sv-ac] RE: mantis 3474: proposal added
> >
> > I don't see the justification for adding a distinction that has no
> > meaning.
> >
> > Shalom
> >
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > > Kulshrestha, Manisha
> > > Sent: Wednesday, July 04, 2012 13:03
> > > To: Bresticker, Shalom; Seligman, Erik; Korchemny, Dmitry; sv-
> ac@eda-
> > > stds.org
> > > Subject: [sv-ac] RE: mantis 3474: proposal added
> > >
> > > 12.4.2 says,
> > >
> > > The keywords unique, unique0, and priority can be used before an if
> > to
> > > perform certain 'violation
> > > checks'.
> > > If the keywords unique or priority are used, a 'violation report'
> > shall
> > > be issued if no condition matches
> > > unless there is an explicit else.
> > >
> > > So the 'violation check' is what is evaluated, like an assertion,
> and
> > > the 'violation report' is what is produced if the check fails, like
> a
> > > fail action block.
> > >
> > > What is the benefit of performing violation checks if violation
> > reports
> > > are suppressed, and vice-versa?
> > >
> > > MK> Actually, currently there is no benefit unless some tools
> > actually
> > > collect some data about these checks which users can see.
> > >
> > > Shalom
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kulshrestha, Manisha
> [mailto:Manisha_Kulshrestha@mentor.com]
> > > > Sent: Wednesday, July 04, 2012 12:45
> > > > To: Bresticker, Shalom; Seligman, Erik; Korchemny, Dmitry; sv-
> > ac@eda-
> > > > stds.org
> > > > Subject: RE: mantis 3474: proposal added
> > > >
> > > > Hi Shalom,
> > > >
> > > > I agree with you and that is the reason my previous version did
> not
> > > > have this distinction and FAILOFF/FAILON had no effect on
> violation
> > > > report generation. But Erik (and I think Dimitry also) do not
> agree
> > > > with me on this so I updated the proposal. They consider
> violation
> > > > reports as assertions and believe that FAILON/FAILOFF should have
> > > same
> > > > effect on violation reports as it has on default fail action
> block.
> > > >
> > > > Now, I do not think FAILON/FAILOFF should be equivalent to ON/OFF
> > as
> > > > that will cause more confusion to the users as this will not be
> > same
> > > > for other assertions.
> > > >
> > > > If I use the term 'violation checks' for ON/OFF/KILL controls and
> > > > 'violation report' term for FAILON/FAILOFF, is that going to make
> > > > things more clear?
> > > >
> > > > Thanks.
> > > > Manisha
> > > >
> > > > -----Original Message-----
> > > > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > > > Sent: Wednesday, July 04, 2012 2:50 PM
> > > > To: Seligman, Erik; Kulshrestha, Manisha; Korchemny, Dmitry; sv-
> > > ac@eda-
> > > > stds.org
> > > > Subject: RE: mantis 3474: proposal added
> > > >
> > > > I was reviewing the proposal and compiling some editorial
> comments,
> > > > when suddenly I realized that there is something more fundamental
> > > that
> > > > I do not understand.
> > > > The proposal seems to make a distinction between violation
> reports
> > > and
> > > > violation fail messages.
> > > >
> > > > This is most prominent in the code example at the end:
> > > >
> > > > // now, after 10 time units, do not disable the violation
> > > > // reporting but disable reporting of fail messages for them.
> > > > // As a result of this, no violation report messages shall be
> > > > // generated by the tool.
> > > > #10 $assertcontrol(FAILOFF, UNIQUE|UNIQUE0|PRIORITY);
> > > >
> > > > // now, after 10 time units, disable violation reporting.
> > > > #10 $assertcontrol(OFF, UNIQUE|UNIQUE0|PRIORITY);
> > > >
> > > > // now, after 10 time units, enable the fail message reporting
> > > > // for violation report types. Although, fail message reporting
> is
> > > > // going to be enabled now, still no messages shall be issued as
> > > > // violation reporting is disabled.
> > > > #10 $assertcontrol(FAILON, UNIQUE|UNIQUE0|PRIORITY);
> > > >
> > > > I don't understand this.
> > > > 12.4.2 and 12.5.3 don't make such a distinction, as far as I can
> > see.
> > > > They talk about 'violation checks' that produce 'violation
> reports'
> > > > when they fail, somewhat parallel to 'assertion evaluation' and
> > > 'action
> > > > blocks'.
> > > > All that the LRM really says is, "A tool-specific violation
> report
> > > > mechanism is then used to report each violation" (12.4.2.1)
> > > > A violation has no effect other than to generate a report.
> > > > Unless maybe you want to distinguish, say, between keeping the
> > > > information on violations in a database and printing messages.
> > > > Like for example, cover assertions that only have pass action
> > blocks,
> > > > but the LRM talks about collecting information on coverage.
> > > > But the LRM doesn't seem to say anything like that for violation
> > > > checks.
> > > > If you want here to make such a new distinction, then you will
> have
> > > to
> > > > be more explicit about it.
> > > > Otherwise, OFF and FAILOFF should be the same for violation
> checks,
> > > or
> > > > say that only one of them applies.
> > > >
> > > > 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 Wed Jul 4 04:09:50 2012