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