The details are attached. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. The following 7 people were eligible to vote. 5 Champions participated in the vote. 1. * Stu Sutherland 2. - Surrendra Dudani 3. * Brad Pierce 4. - Francoise Martinolle 5. * Shalom Bresticker 6. * John Havlicek 7. * Dave Rich This email vote ran for 6 days, ending on Wednesday, August 13th (7pm PST). Summary of email vote results: ------------------------------ 1. 2226 Approve the proposal - motion failed (3y,1n,1a) Yes : Dave Yes : Brad -- see details below Yes : Stu -- see details below Abstain: John -- see details below No : Shalom -- see details below 2. 2088 "Conditionally" approve the proposal - motion passed (5y,0n,0a) 3. 1900 Approve part2, pages 10-16 - motion failed (2y,3n,0a) No : Dave -- see details below Yes : Brad -- see details below No : Stu -- see details below Yes : John No : Shalom -- see details below Notes: a. Mantis 2088 is a set of changes on top of Mantis 1900. This vote is to "conditionally approve" 2088. Mantis 2088 will pass, only if 2088 "conditionally" passes in this email vote and mantis 1900 ends up passing. The reason for doing this is to get out on the table any issues that the Champions have with 2088. b. Mantis 1900, part2 was only partially reviewed in the meeting today. The purpose of this email vote is to get out on the table any remaining issues with the remainder of the proposal. Detailed feedback: ------------------ Dave: 1. 2226 Approve the proposal Yes _X_ No ___ 2. 2088 "Conditionally" approve the proposal Yes _X_ No ___ 3. 1900 Approve part2, pages 10-16 Yes ___ No _X__ [DR] I echo Stu's comments. Although the SV-SystemC has made great progress (and none of that effort will go to waste) I am not comfortable going to ballot in its current state. Stu: 1. 2226 Approve the proposal Yes _X_ No ___ Abstain ___ My Yes vote is conditioned on the CC committee updating the proposal to align with draft 6, and the CC committee reviewing and approving the update. 2. 2088 "Conditionally" approve the proposal Yes _X_ No ___ Abstain ___ 3. 1900 Approve part2, pages 10-16 Yes ___ No _X_ Abstain ___ I vote No because there has been a lot of very recent e-mail traffic with questions and issues, which indicates that the proposal needs further clarification and review. To the SC committee's credit, they have been very quick to fine tune the proposal in response to some of the e-mail traffic, but I am concerned that these revisions are bypassing the review and approval process of the full SC committee. Brad: I vote 'Yes' on all 3, with the comments that --- 2226-1 --- I consider the noted issues to be editorial issues, some of which Stu can unilaterally resolve, and some of which he requires some help from the SV-CC. Approval of the resolution now will not prevent Stu's (with assistance from SV-CC) doing a good editorial implementation of the intended changes. --- 1900-1 --- The following formulation is strange "A checker may be instantiated wherever a concurrent assertion may appear (see 16.15). It shall be illegal to instantiate checkers in fork...join, fork...join_any, or fork...join_none blocks." I assume the first sentence is intended to imply that a checker may not appear in places where concurrent assertions may not appear. But then wouldn't the second sentence be redundant? Shouldn't it be "In particular, it is illegal to instantiate ..."? It's also strange that this second sentence begins a new paragraph. --- 1900-2 --- Because these are redundant "modules, interfaces and programs shall not be either declared or instantiated inside checkers" "Modules, interfaces and programs shall not be instantiated inside checkers." In the first sentence it would be better to delete "either" and "or instantiated". --- 1900-3 --- A checker can be declared within a checker, yet checker declarations are not listed after "A checker body may contain the following elements ..." --- 1900-4 --- Why is there no mention of packages in this sentence? "Checkers may be declared inside modules, programs, interfaces, and other checkers, but modules, interfaces and programs shall not be either declared or instantiated inside checkers." John: 1. 2226 Approve the proposal Yes ___ No ___ Abstain _X_ 2. 2088 "Conditionally" approve the proposal Yes _X_ No ___ Abstain ___ 3. 1900 Approve part2, pages 10-16 Yes _X_ No ___ Abstain ___ Rationale for abstention on 2226: - The proposal is not aligned to Draft 6. - 36.2.2, Note 4, says that vpi_free_object is deprecated. We have discussed before that deprecated items should not be mentioned in the LRM body. I'm not sure whether it is admissible to mention a deprecated item in a note like this. - I agree with the concerns of Shalom and Stu about the conventions used for representing changes in this proposal and the large amount of locator text. - In Part 2, 37.x vpi_release_handle, the following language does not conform to LRM style: It is erroneous to call vpi_release_handle() on an invalid handle and the tool may crash. I think something like vpi_release_handle() shall not be called on an invalid handle. is better. - In Parts 4 and 5, should the comments about deprecated items be removed? Shalom: > > 1. 2226 Approve the proposal Yes ___ No _x__ 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 ___ 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.) NeilReceived on Fri Aug 15 18:04:48 2008
This archive was generated by hypermail 2.1.8 : Fri Aug 15 2008 - 18:05:10 PDT