-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions May 21, 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 8. * Karen Pieper 1. Patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt The chair directed everyone's attention to the patent policy. 2. Review of the results of the email vote that ended on May 21st Email ballots were received from the following Champions. Feedback that they had for various proposals has been merged into these minutes. Brad John Shalom (up through item 25 from a list of 53 items) Francoise 2.1 2739 SV-BC Ballot comment 125: Conflict in strength number/name; 5 is not large - Fixed - On May 11, 2009 the SV-BC unanimously approved the attached proposal. Passed by email vote ending May 21, 2009(4y). 2.2 2738 SV-EC Ballot comment #115 Automatic bin creation for coverage points (up to N-1) - Fixed - The SV-EC voted to unanimously accept the following change. This was agreed to in the conference call held on May 4th, 2009. remove "(up to N-1)" (page 485) From John - no - I see no difference in the BEFORE and AFTER of the proposal Neil - I have the same problem. Tom Alsop took an action item to provide a pdf file. Brad, Stu - move to approve the proposal for Mantis 2738, contingent upon getting a pdf file for the changes. Passed unanimously 2.3 2737 SV-EC Ballot Comment #54: restricting access of local paramters inside a class - open - The following resolution was approved by the SV-EC in the email vote which ended on May 1st. "The committee read and considered this feedback. The committee believes it is too broad for the scope of the draft to implement at this time but may be considered for future revisions." Passed by email vote ending May 21, 2009(4y). 2.4 2735 SV-EC Ballot Comment #48: Chaining of method calls - open - The following resolution was approved by the SV-EC in the email vote which ended on May 1st. "The committee read and considered this feedback. The committee believes it is too broad for the scope of the draft to implement at this time but may be considered for future revisions." - From Shalom - abstain - I would like to see Brad's reservations discussed. - From Brad - no I think chaining of method calls is already legal Because the BNF has long accepted method call chaining and there seems to be no prohibition on it in the text, I believe it's allowed unless the committee adds an explicit deprecation. The proposed resolution is not accurate. For completeness, here's an example BNF derivation of obj.method1(5).method2(6) expression ::= primary ::= function_subroutine_call ::= subroutine_call ::= method_call ::= method_call_root . method_call_body ::= primary . method_identifier ( list_of_arguments ) ::= function_subroutine_call . method2(6) ::= subroutine_call . method2(6) ::= method_call . method2(6) ::= method_call_root . method_call_body . method2(6) ::= primary . method_identifier ( list_of_arguments ) . method2(6) ::= obj . method1(5) . method2(6) Brad - now ok with the resolution of open. Shalom - that would leave an ambiguity in the LRM. Dave - thinks there is no ambguity in syntax and behavior. Brad, dave - move to approve the resolution of open for Mantis 2735 Abstain - shalom - someone thought it was not allowed. Passed with one abstain. <next 4 passed - by email vote> 2.5 2730 SV-EC Ballot comment 114: State bins has not been defined before - fixed - The proposal was unanimously approved by the sv-ec in the conference call held on May 11th, 2009. 2.6 2729 SV-EC Ballot comments 30 and 31: Ambiguity regarding valid data types to packed structures/unions 2.7 2724 SV-EC Ballot Comment #51 Clarification of super.new statement in 8.14 2.8 2723 SV-EC Ballot comment #65 class decls must be in the same scope as the forward 2.5-2.8 Passed by email vote ending May 21, 2009(4y). 2.9 2718 SV-EC Ballot comment #102 dist_item occurs twice in Syntax 18-3 From John - no - I don't understand Shalom's note that the proposal does not fix the constraint_block error. Shalom - his objection is no longer relevant. Dave, John - move to approve the proposal for Mantis 2718 Passed unanimously 2.10 2712 SV-EC Ballot comment #116 19.5.6 Value resolution needs to clarify rules in context of wildcard bins From John - abstained - It seems that "cannot apply to wildcard bins" should be changed to "shall not apply to wildcard bins". From Francoise - abstained - with no reason given Shalom - the existing wording is ok John, Shalom - move to approve the proposal for Mantis 2712 Passed unanimously <next 10 passed by email vote> 2.11 2700 SV-EC Ballot feedback items 36-40: type rules for strings 2.12 2698 SV-EC Ballot comment #57: pure keyword SHALL be required 2.13 2691 SV-BC Ballot comment #76: suspension of function execution 2.14 2689 SV-BC Ballot comment #73: x in case expressions 2.15 2688 SV-BC Ballot comment #72: unique-if and x/z values 2.16 2687 SV-BC Ballot comment #70: expression bit-length enhancements 2.17 2686 SV-BC Ballot comment #69: Bit/Part-select errors should be reported uniformly. 2.18 2684 SV-BC Ballot comment #68: Non-constant width part-select enhancement 2.19 2681 SV-EC Ballot comment #41: Bad associative array example 2.20 2679 SV-BC Ballot comment #29: static casting 2.11-2.20 Passed by email vote ending on May 21, 2009(4y). 2.21 2674 SV-BC Ballot Comment #123: Incorrect syntax for $fopen in 21.3.1 - From Shalom - no To be consistent with the rest of Clause 21, 'filename' should be in italics. Dave, Shalom - move to approve the proposal for Mantis 2674, with the friendly ammendment from Shalom. Passed unanimously 2.22 2673 SV-BC Ballot comment #26: Deprecate defparams Resolution of suspended 6.20 says, "NOTE: The defparam statement might be removed from future versions of the language." Yes, please do remove it. From Francoise - no I believe that we should also add a statement saying that defparams is not enhanced for parameters of the new systemVerilog datatypes. That will discourage users to use defparams. Francoise - no statement in LRM stating that defparams don't apply to data types that were added by SystemVerilog. - C.4.1 discusses Defparam statements - there is no limitation today. Shalom - it won't be easy to do something now. Neil - there is no proposal Francoise - we assumed it would be deprecated, it is still there. Shalom - doesn't agree that it would be deprecated. - it isn't even clear what the word deprecated means. Francoise - if used on any data type, will be harder to deprecate later. - wants to say defparam is not enhanced by the SystemVerilog standard. Shalom - even that would be unclear. Francoise - if a defparam was legal in 1364, still legal in SystemVerilog what wasn't legal then, is not legal now either. Shalom - not sure that is correct. Francoise - defparam of a string is allowed? Shalom - did not say that. - not willing at this time to agree, without more extensive investigation. Neil - "the intent was to not extend it beyond 1364." Shalom - what about int? Shalom, Dave - move to approve resolution of suspended for 2673 Abstain - Francoise Opposed - Stu - Francoise raises a serious issue about defparams on systemverilog data types. Passed with 4 in favor 2.23 2671 SV-BC Ballot Comment #127 Deprecate or discourage use of `define Passed by email vote which ended on May 21, 2009(4y). 2.24 2645 SV-CC Ballot comment #154 Properties returning DPI information on task/function declaration are missing - From Shalom - no In Detail (f): "f) vpiAccessType shall return vpiDPIExportAcc for "DPI", and "DPI-C" export functions / tasks, and shall return vpiDPIImportAcc for "DPI" and "DPI-C" import functions / tasks," there should be no comma after the first "DPI". In Detail (g): "g) vpiDPIPure shall return TRUE for pure "DPI", and "DPI-C" import functions," there should be no comma after "DPI". In Detail (h): "h) vpiDPIContext shall return TRUE for context import "DPI" and "DPI-C", functions / tasks," there should be no comma after "DPI-C". Stu - thought DPI string was deprecated - but it isn't in annex C - text in section 35, refers to that string as being deprecated. Shalom - mentioned that in mantis item on deprecation inconsistencies. - 35.5.4 - there is a proposal to change from error to error or warning. - just a compile time warning means it can pass compilation. Stu - looks like DPI was not fully deprecated. - in that case it looks ok Shalom, Stu - move to approve the proposal for Mantis 2645 with the friendly amendments from Shalom. Passed unanimously 2.25 2641 SV-CC Ballot comment #150 Formal argument types for import /export subroutines should include time and integer Passed by email vote which ended on May 21, 2009 (4y). <Dave dropped off at this point> Email vote - to end next Wednesday at noon. Neil - copy john directly (he hasn't been getting all the champions email) <the next 9 will be added to the email vote ending on May 27th, 2009> 2.26 2640 SV-CC Ballot comment #149 Using the string "DPI" should result in a compile time warning 2.27 2639 SV-CC Ballot comment #148 Simplify definition of import/export call chains. Shalom - this is a complex change. 2.28 2638 SV-CC Ballot comment #147 no explicit behavior of a call to a DPI export subroutine 2.29 2636 SV-CC Ballot comment #145 contradition for return value of imported tasks 2.30 2635 SV-CC Ballot comment #144 tasks consuming time contradiction in LRM 2.31 2624 SV-CC Ballot comment #160 Diagram has a blue arrow that should be black 2.32 2611 SV-BC Resolution of names containing :: 2.33 2610 SV-BC Name resolution in presence of type parameters needs to be clarified 2.34 2597 SV-EC Ballot comment #49 When do class property initializers execute in relation with the constructor call 2.35 2593 SV-BC Omitting types in port declaration fixed - From John - no I think that the committee needs to come to a broader consensus when more time is available. I don't see much value in the current proposal, and it might be contradicted by a future proposal with broader support. - From Brad - no I opened this issue, and I'm not fully satisfied with the proposal, even though I voted for it in SV-BC. If it had been passed unanimously, or nearly so, then I would say "good enough is good enough", but actually the proposal barely passed. Even given a moderate amount of additional time, I don't think SV-BC could come up with a proposal that would pass almost unanimously. Neil - leave it unchanged? Brad, John - move to reject the proposal for Mantis 2593 Shalom - I am afraid that the change will be misinterpreted by someone reading the LRM than what was intended. The word data type in that section of the LRM is ambiguous. Passed unanimously <the next 3 will be added to the email vote ending on May 27th, 2009> 2.36 2588 SV-CC Omission of package as a legal context in which DPI imports can be declared 2.37 2580 SV-BC %p should allow radix specification 2.38 2568 SV-BC unpacked array terminology unclear in $readmem $writemem 2.39 2514 SV-EC Ballot comment #182 External constraint blocks not defined well From Francoise - no Comment: It seems to me that the rule below does not support and is not consistent with class inheritance, since it says that the pure constraint in the derived class is ignored and always replaced with the base pure constraint. This is inconsistent with the way class properties which appear in both base and derived classes work. Why? "A virtual class that inherits a pure constraint from its superclass may have a pure constraint of the same name. In this case, the pure constraint in the derived virtual class shall be ignored and a warning may be issued. The superclass's pure constraint shall be inherited as if the duplicate in the derived class were not present." Francoise - The one in the derrived class usually hides the one in the base. - didn't realize this in the svec meeting when it was discussed. 18.5.2, p2, 2nd blue para 18.5.2, p1, 2nd blue para - is a bit different (not virtual derrived class) John - if that paragraph was changed for the virtual derrived class case, would there be any difference in the behavior? Francoise - why do we want to have a different mechanism when the derrived is virtual? John - is there any difference by discarding the base version versus the derrived one? Francoise - if the body is missing, which one should the tool point to? Stu - what is the rule for pure methods? Francoise - 8.10 - may be overridden, and no warning. Neil - it sounds inconsistent. John - it sounds like there is an effect Stu, Francoise - move to reject the proposal for Mantis 2514 - it shoudl follow the same rules as pure virtual methods. when a derrived class has pure constraint of the same name. FM - it needs to be more consistent with normal class inheritance. Passed unanimously <the next 10 will be added to the email vote ending on May 27th, 2009> 2.40 2510 SV-EC Ballot comment #183 Allowed types for clocking signal is too restrictive 2.41 2501 SV-BC implication operator (->) should short-circuit and equivalence operator (<->) should evaluate operands only once 2.42 2486 SV-AC Scope of Annex F definition of "specify" is not clear. 2.43 2477 SV-BC How are values of enumeration constants calculated? 2.44 2468 SV-CC vpiStartLine vpiColumn vpiEndLine vpiEndColumn assertion properties all undefined in include file 2.45 2427 SV-CC vpiEdge, vpiDirection should be int, not bool 2.46 2342 SV-EC Class constructor should not be allowed to be static or virtual (p1800-2009 ballot id 185) 2.47 2288 SV-EC Ballot comment #186 Re: Associative array next() & prev() 2.48 1791 SV-BC atoi(), atohex(), atooct(), atobin() should warn about truncation 2.49 1651 SV-BC $psprintf 2.50 1256 SV-EC Minor problems in description of Linked Lists (Annex H) [p1800-2009 ballot comment id 192] - From Brad - no Would change my vote to 'yes' if the Editor would agree to change 'P1800' to '1800' and remove the space in "1800- 2005". Stu - the IEEE will take out the p. We are suppose to leave it in there. Brad, Shalom - move to approve the proposal for Mantis 1256, with the extra space out and the p left in. Passed unanimously <the next 3 will be added to the email vote ending on May 27th, 2009> 2.51 2621 sv-cc The following concern was noted by the Champions. In the May 14th conference call the Champions unanimously agreed to send the proposal back to the committee for review to make sure that the following was noted by the committee and that they still believe that the proposal is consistent with the rest of the text in the LRM. 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? 37.3.5 only talks about functions with side effects. The other text is unconditional. 2.52 2637 sv-cc In the May 14th conference call the Champions noted that the proposal doesn't make any updates to the subclause that was mentioned in the ballot feedback. There were some changes made in the same general area, but not the specific changes mentioned by the ballot feedback. The ballot comment specifically referenced subclause 35.5.1.3, where there are 2 references to PLI. The proposal does not fix this subclause. 2.53 2654 sv-ac -- the Framemaker files were created for the Editor The proposal failed to pass in the Champions email vote that ended on May 14th, 2009. The Champions noted that the Editor will require new diagrams from the committee. A Framemaker source file for this change to the diagram would be best. The current format for these diagrams cannot be Edited and need to be redone. Shalom - the revotes from cc 51, 52, he is ok with the changes now.Received on Thu May 21 18:30:00 2009
This archive was generated by hypermail 2.1.8 : Thu May 21 2009 - 18:30:04 PDT