RE: [sv-champions] Email vote - ending August 13th

> List of Mantis items for a Champion's email vote:
> -------------------------------------------------
> 1. 2226  Approve the proposal                  Yes ___ No _x__ 
> Abstain ___

I did not have much time to look at 2226, but the editor has agreed with my reservations regarding the format of the proposal.

A couple of editorial comments:

36.2.4 has

"A VPI program that attempts to refer to an object using an invalid handle is erroneous. A VPI program that attempts to release an invalid handle is also erroneous."

This phrasing is not consistent with LRM style. The LRM does not use "erroneous". As used here, I think it is also not gramatically correct. More consistent would be

"It shall be an error for a VPI program to attempt to refer to an object using an invalid handle or to attempt to release an invalid handle."


36.3.6 has

"The property vpiAllocScheme is more relevant to determining the lifetime of an object in that it discriminates the nature of the scope of the object with respect to how its memory was allocated."

The wording is murky and difficult to understand. It should be reworded.

I also saw some trivial editorial errors, such as fonts and periods, that I do not list here.


> 2. 2088  "Conditionally" approve the proposal  Yes _x_ No ___ 
> Abstain ___

I have no issues with 2088.


> 3. 1900  Approve part2, pages 10-16            Yes ___ No _x__ 
> Abstain ___

I have described my reservations about the description of the assume set in separate mails. Not all my doubts have been settled yet.

I also have some additional issues.

P. 9: "Simulators will assign random values to the variable flag as explained in 17.6.2." Change "will" to "shall", "flag" to Code font.


P. 10: "Simulators assign a random constant value to a constant free variable as explained in  17.6.2." Change "assign" to "shall assign".


P. 10: "Memorizing data". Change to something else, such as "Data integrity checking".


P. 10: "// If start_ev is asserted then the value of in_data has to be
// equal to the value of out_data at the next assertion of end_ev"

Really it is checking the reverse, that out_data at end_ev will be equal to in_data at start_ev.


P. 11: "However at a given time step all occurrences of a non-constant checker variable have the same value, e.g., the assertion

rand bit a;
assert property (@clk a == a); // clk defined elsewhere

is a tautology: though at different time steps a may assume any value: 0 or 1 - this value is the same for both occurrences of a."

I found this extremely confusing. The apparent meaning was so obvious that I looked for a different, less obvious meaning. I was also not sure what was meant my "occurrence". I think this should just be deleted. The way free checker variables get values is described in detail later on anyway.


P. 11: "The right-hand side of a checker variable assignment may contain sequence method triggered (see 16.14.6)." Change "sequence method" to "the sequence method".


P. 13: "All other variables (such as non-free checker variables and checker formals) are always treated as inactive, as are all past values of free checker variables."

"Past values" are just that, past. How could they possibly be treated as active? What is the point of this part of the sentence?


P. 13: "Note that since assumptions are evaluated as simulation assertions as well as being used for randomization, each assume statement potentially contributes many assertions to the pending procedural assertion queue, even though it only contributes once to an assume set." 

This is not clear. What is being referred to? What is an example? Does it even need to be stated?


P. 13: "bar B1(clk, q+r, r);"   "clk" should be "fclk"?


P. 14, et al.: "timestep" should be "time step".


P. 14: "When an implementation is about to begin the Observed region, it must solve for all the active free variables." Change "must" to "shall".


P. 14: "Note that checker procedures and properties execute in the Reactive and Observed regions (see 17.7), and so have the new values available." I think the reference is wrong. It should be 17.6.3 ?


P. 15: "Expressions at the right hand side of checker variable assignments are allowed to include function calls with the same restrictions that are imposed to function calls in concurrent assertions (see 16.6):
¾	Functions that appear in expressions cannot contain output or ref arguments (const ref is allowed).
¾	Functions should be automatic (or preserve no state information) and have no side effects."

Change "to function calls" to "on function calls".

Change "cannot contain" to "shall not contain".
Change "should be automatic" to "shall be automatic".
(Yes, I know that text is copied from 16.6. The changes are needed there also.)


Regards,
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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.