[sv-ac] 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.
Received on Wed Jul 4 04:42:18 2012