Technical Committee Chairs, I finished updating the set of Mantis items that have been reviewed by the Champions in the May 14th conference call. There were some Mantis items that were sent back to the Committees. Attached are the minutes of the Champions meeting. There will be another Champions meeting on May 21st. Changes will need to be done quickly in order for them to be processed by the Champions. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions May 14, 2008 Conference call Thursday 8-10am PDT Attendees: ---------- 1. * Stu Sutherland 2. * Brad Pierce 3. * Francoise Martinolle 4. * Shalom Bresticker 5. * John Havlicek 6. * Dave Rich 7. * Neil Korpusik 1. patent policy Dave, John - assume that the patent policy has been read Passed unanimously 2. Review of the results of the email vote that ended on May 14th All of the champions responded to all of the items on the email vote. There was some feedback on 16 of the mantis items. 51 passed unanimously Below is a summary of the feedback received from the email vote. Those items that have no comments shown below passed unanimously. There were some duplicates in this email vote. This happened due to the way that the email vote was put together. The sv-ec in particular, sometimes voted on particular ballot comments where the same mantis item covered multiple ballot comments. 2.1 2646 SV-AC Assumption in deferred assertion example should be made explicit 2.2 2657 SV-AC Clarify notion of sequence 2.3 2648 SV-AC Need an example of cyclic dependencies between sequences 2.4 2649 SV-AC sequence_actual_arg is used to represent the default argument 2.5 2655 SV-AC Backward compatibility issue with the clocking specification 2.6 2644 SV-CC Ballot comment #153 Wrong function named in table 36.9 2.7 2630 SV-CC Ballot comment #168 Wrong format type named in Table 38-5 2.8 2653 SV-AC Sequence match not shown in timing diagram 2.9 2612 SV-AC `true should have a backtick in a sequence example 2.10 2660 SV-AC Add indices to expressions 2.11 2478 SV-AC Clock flow subclause is not consistent with multiclocked property definition 2.12 2661 SV-AC "Syntax 16-19" is in blue. 2.13 2659 SV-AC Backward compatibility issue with sequence property Stu no The wording of the proposed change is awkward and confusing. I suggest the proposed note be changed to: NOTE-The IEEE Std 1800-2009 semantics for a sequence_expr definition is not backward compatible with IEEE Std 1800-2005. The IEEE Std 1800-2009 equivalent to a sequence_expr as defined in IEEE Std 1800-2005 is strong(sequence_expr). Shalom yes with a comment Editorial note: "IEEE Std 1800-2005 semantics for a sequence_expr is changed" will sound better if "is changed" is changed to "were changed". ----------- Stu - Not objecting to the change itself. John - There have been debates as to whether semantics can be used as a singular or not. - Stu's wording is better. - Stu's just doesn't say it was changed, - The rewording contains all the points in the original. Stu, John - motion to send the proposed wording back to committee chair, the chair has the option to ask the committee for input. Passed unanimously AI/Neil - send it back to Dmitry 2.14 2541 SV-AC syntax errors - missing parenthesis 2.15 2516 SV-AC Another contradiction of existing text with 2398 needs to be fixed 2.16 2496 SV-AC non_port_program_item should contain assertion_item Stu No I agree with the decision of the AC, but think it would have been appropriate to add explicit wording, instead of having readers of the LRM jump search vague, round-about inferences to figure out that deferred assertions are illegal in program blocks. ----------- Neil - you are requesting additional text? Shalom - the bug note written by Dmitry explains the reasoning. John - the requested change would have allowed something that is not allowed today. Stu - would like to explicitly state that "deferred assertions are not allowed in programs". Dave - prefers to just have a note Stu - the original ballot request is being denied since deferred assertions would be allowed in programs. Shalom - the bnf change would be wrong, since it is not allowed today FM - not sure that anything else is required in the text. Neil - there are a bunch of places in the LRM where you have to go to the bnf. Stu - missed the part about the bnf change, agrees with no change. Now changes his vote to yes. Passed unanimously - after the discussion in the champions meeting. 2.17 1775 SV-CC cbAtEndOfSimTime not in header files 2.18 2576 SV-CC Failed to remove reference to Reader API when deprecating Data Read API 2.19 2621 SV-CC Ballot comment #155 vpiSize should return an error when applied on a vpiFunction returning string Shalom abstain The proposal says, "If the vpiSize of the vpiReturn variable is defined (see 37.17, detail 9) and can be determined without evaluating the function (see 37.3.5), vpiSize for the function shall return the same value as vpiSize for the vpiReturn variable... For all other cases the behavior of vpiSize is undefined." 37.3.5 talks specifically about evaluating functions with side effects, not about function evaluation without side effects. Is this consistent? ----------- Shalom - would like to have the svcc take another look at it to make sure that they noted this, and this was their intent. FM - thinks this was discussed in the committee. Shalom - 37.3.5 only talks about functions with side effects. The other text is unconditional. AI/Neil - send a note to svcc 2.20 2623 SV-CC Ballot comment #157 vpiArrayType is labelled bool, should be int 2.21 2626 SV-CC Ballot comment #162 In Table 38-3 in vpiScalarVal, vpi1 et al should be in bold 2.22 2631 SV-CC Ballot comment #172 The usage of the the term PLI is confusing 2.23 2637 SV-CC Ballot comment #146 Term PLI is confusing Shalom - no The ballot comment specifically referenced subclause 35.5.1.3, where there are 2 references to PLI. The proposal does not fix this subclause. ----------- Shalom - the proposal deletes references in the same general area, but not the specific places noted by the proposal. Neil - it sounds like you are not against what was changed, you just think additional changes are needed Shalom - it deletes references in other places. Stu - 2631 also deleted some references. Shalom - it references an appendix, the other one is section 37 Dave - we need an explanation. AI/Neil - The Champions need an explanation... The proposal doesn't address the ballot comment directly. Why didn't the proposal change the section mentioned in the ballot feedback? 2.24 2628 SV-CC Ballot comment #164 In Arguments section, s_vpi_arrayvalue should be p_vpi_arrayvalue. Shalom yes with a comment The correct subclause for the second change is 38.35, not 37.35. ----------- AI/Neil - add an editorial note to the bug notes. The proposal was passed by the champions. 2.25 2717 SV-AC Ballot comment #81 Clarification needed for the usage of severity tasks. 2.26 2647 SV-AC Clarification about clock glitches in concurrent assertions 2.27 2656 SV-AC Clarify difference of $global_clock handling in simulation and formal verification 2.28 2658 SV-AC Default values for untyped formals 2.29 2654 SV-AC Error in an example of throughout operator Stu no I am voting NO from the editor's point of view. Years ago, the SV-AC provided the diagrams in the assertions chapters in a format that could be pasted into FrameMaker, but cannot be edited. In order to make the changes requested in this proposal, the AC committee will need to create new diagrams and provide them to the editor. ----------- Stu - the existing diagrams are images, pasted into framemaker. - if he pastes what is shown here, they will look different. AI/Neil - request a diagram from the sv-ac. The Editor needs a framemaker source file. 2.30 2642 SV-BC Ballot comment #151 Need a similar rule for disabled SystemVerilog functions in section 9.6.2 2.31 2643 SV-BC Ballot comment #152 Section implies that a SystemVerilog function cannot be disabled 2.32 2680 SV-BC Ballot comment #32: Writing to an array with an invalid index Stu abstain I abstain from voting because I don't want to suggest that I am now in favor of not addressing this ballot issue at this time, but will abide by the vote of the BC committee at the champions level. Shalom abstain I abstain because the current behavior is inconsistent with the behavior for associative arrays (7.9.6) and queues(7.11.1), where warnings are mandatory. Note that the committee was almost evenly split: 7 for, 6 against. ----------- Stu - the committee didn't have time to converge. John - he feels that way as well. They need to be allowed to just not converge. The proposal is passed by the Champions with 2 abstains. 2.33 2513 SV-BC BNF needs fixes to allow checkers in packages 2.34 2542 SV-BC Config declaration BNF bug 2.35 2550 SV-BC static variable initialization example has error 2.36 2634 SV-BC Ballot comment #20 Wording of paragraph implies evaluation 2.37 2672 SV-BC Ballot Comment #Macro expansion example incorrect in 22.5.1 2.38 2683 SV-BC Ballot comment #66: Example mislabelled "delay control" instead of "event control" 2.39 2695 SV-BC Ballot comment #169: BNF error in edge_sensitive_path_declaration 2.40 2652 SV-AC Future value functions need clarification 2.41 2562 SV-AC rand qualifier for checker variables is not reflected in BNF Shalom no The proposal says [rand] data_declaration where data_declaration ::= [ const ] [ var ] [ lifetime ] data_type_or_implicit list_of_variable_decl_assignments ; ... That is, according to this, rand must come before const. 17.7 has examples: const rand bit [5:0] idx; const rand bit [$bits(in_data)-1:0] mem_data; Apparently the examples should be changed so that rand precedes const. ----------- Shalom - this proposal fixes a problem in the bnf, there are examples that now conflict with the proposal. Brad - or the bnf could be modified to allow both. - parallel to the way it was done with constant. AI/Neil - Doesn't rand need to precede const? The proposal should either change the bnf or the examples in order for the proposal to be consistent with the rest of the text. 2.42 2650 SV-AC Ambiguity in a sequence repetition [*0] definition 2.43 2670 SV-BC Ballot Comment #130: Module header description is missing the package import list in 23.2.1 2.44 2675 SV-BC Ballot Comment #103: Clarification of readmem warning Shalom Yes with comments I would change "are not modified by the operation" to "shall not be modified by the operation" ----------- Neil - editorial? Stu - ok AI/Neil - add a bugnote for the editorial comments. The proposal is considered passed by the Champions. 2.45 2676 SV-BC Ballot comment #28: port connection warning 2.46 1492 SV-BC Overriding default lifetime of subroutine formal arguments 2.47 2625 SV-CC Ballot comment #161 There is a blue change bar at the bottom of the page. 2.48 2622 SV-CC Ballot comment #156 Arrow missing in VPI Generate diagram 2.49 2629 SV-CC Ballot comment #167 Function "vpi_get64" should be "vpi_get_long()" 2.50 2627 SV-CC Ballot comment #163 In Tables 38-3 and 38-5, for decimal characters, "0-9" should be in bold, for consistency. 2.51 2632 SV-CC Ballot comment #16 Unimplemented Preponed PLI region clutters description 2.52 2633 SV-CC Ballot comment #17 Unimplemented Post-Observed PLI region clutters description 2.53 2705 SV-EC Ballot Comment #35: Add example of string literal assignment 2.54 2700 SV-EC Ballot feedback items 36-40: type rules for strings Shalom no The proposal references "Ballot items #37-39", but 37 and 38 were not approved. I don't know what changes in the proposal, if any, were rejected. John no - the item is not in the resolved state ----------- Neil - it was approved in the May 11th conference call. It is now in the resolved state. AI/Neil - add to the next Champion's email vote 2.55 2682 SV-EC Ballot comment #42: Change "is" to "shall be" 2.56 2430 SV-EC associative array .first example should not have wildcard index (p1800-2009 ballot comment 43 & 45) John Abstain (was later changed to a yes) I could not understand the meaning of the coloring and markings in the proposal. Shalom The meaning is to replace "*" with "int". ----------- The proposal is considered passed by the Champions. 2.57 2701 SV-EC Ballot feedback item #44: Clarify rules for assignment to a bounded queue 2.58 2430 SV-EC <listed twice, please ignore this one> 2.59 2706 SV-EC Remove reference to coding convention for class names (ballot id 46) 2.60 2713 SV-EC Ballot comment #47, misleading text in Table 8-1 2.61 2719 SV-EC Editorial changes; For ballot IDs: 58,60,61,104,108,112,117,118,119,122,137 2.62 2358 SV-EC (ballot 67) Actual arguments for base class cannot be specified by super.new call and extends clause in the same class 2.63 2596 SV-EC Ballot comment #80 Anachronistic and misleading text in 14.16 Synchronous Drives 2.64 2710 SV-EC clarify what happens with output arguments of a covergroup (ballot issue 106) Shalom abstain I'm not very happy with the addition of "as described in 13.5". This sounds like it means that 13.5 describes arguments to covergroups, which it does not. "A output" should be "An output". ----------- AI/Neil - add a bug note with Shalom's feedback. The proposal is considered passed by the Champions. 2.65 2711 SV-EC Is it possible for the clocking event to refer to arguments of covergroup? (ballot issue 107) Brad no There was no SV-EC consensus on this issue, so it should have been deferred until the next revision. Arturo - via email of May 13th I'd like to assert my opposition to Mantis 2711. I participated in the meeting in which this item was discussed, however, I had to step out momentarily and was thus unable to cast a vote. Had I been able to cast a vote, I would have voted "no". The meeting notes did capture my opposition during the discussion. I'm quoted as having said "I don't think these should be allowed" and "the clocking event is outside the scope of the covergroup". Steven Sharp raised an issue regarding the safety of ref arguments in this context, but I believe that is an orthogonal issue that is nonetheless not addressed by the current proposal. I'm aware that several implementations already support this feature - including our own - but I feel that this is incorrect and that this resolution was rushed through without due discussion. ----------- Neil - the sv-ec made a procedural mistake when they conducted the vote on this proposal. During the vote the chairs were assuming that it had passed: 6 yes, 3 abstains, 3 no votes - Based on the text in the latest version of the Operating Guidelines this does not constitute a majority vote in favor of the proposal. The Chair should have voted, but did not, since we were thinking in the meeting that it had passed. The Champions should not be voting on this one since the proposal was not resolved by the committee. 2.66 2719 SV-EC id 117 approved email May 1 2009 Shalom no In ballot ID 117, it should be noted that additional indentations were changed. Otherwise, the Editor may miss them. Mantis 2719 also covered Ballot ID 104. I don't see that in this email ballot. In ballot ID 104, which adds to 19.1 an additional bullet, "Coverage Computation", the "C" in "Computation" should be lower case. ----------- Shalom - in 117, there is formatting that the Editor may not notice. Stu - he did see this. Neil - item 2.61 covers ballot id 104 AI/Neil - add a bug note to help alert the Editor to the changes for ballot comment #117 Dave, stu - move to approve the proposal. Passed unanimously 2.67 2719 SV-EC id 118 approved email May 1 2009 <2719 shows up multiple times in this email ballot - see 2.61 and 2.66> 2.68 2719 SV-EC id 119 approved email May 1 2009 <2719 shows up multiple times in this email ballot - see 2.61 and 2.66> 2.69 2543 SV-EC Ballot id #120 and #122 19.7.1 Declaration after procedural code Shalom abstain Shouldn't the following also be changed? gc::type_option.comment = "Here is a comment for covergroup g1"; ----------- Shalom - this is not mandatory at this point. - wouldn't hold it up for this AI/Neil - create a new mantis for Shalom's comment 2.70 2035 SV-EC Ballot comment #181 Deprecate class methods with static lifetimes John Abstain I am not comfortable with the disagreement given the number of voters. Shalom abstain The mix of "method" and "task" in the text is confusing. ----------- Neil sent out the following response right before the meeting: "I am showing 15 voters in that meeting (not including the chair). The vote was 13 yes, 2 abstain" John - he is now comfortable, now that he sees how many people voted. AI/Neil - change the bugnote to reflect the number of people that voted, - create a new mantis for Shalom's feedback. 2.71 2473 SV-EC Ballot comment #184 bit-stream cast to destination class must be constructed or made illegal NeilReceived on Sat May 16 20:37:39 2009
This archive was generated by hypermail 2.1.8 : Sat May 16 2009 - 20:37:44 PDT