SV-EC Ballot resolution committee meeting. Monday May 4 2009 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_May_4_2009_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 0000 0000 1123 Meeting Days: ------------------------------------------------------------------------ (1220 ) Day (3074 ) (0000 ) Month (4445 ) (0000 ) Year (9999 ) ------ Attendees -------------------------------------------------------- (A-AA) Arturo Salz 3 (A-AA) Cliff Cummings 3 (AAAA) Dave Rich 3 (AAAA) Francoise Martinolle 3 (AAAA) Mehdi Mohtashemi 3 (AAAA) Neil Korpusik 3 (AAAA) Ray Ryan 3 (-AAA) Gordon Vreugdenhil 3 (AAAA) Steven Sharp 3 (A-AA) Stu Sutherland 3 (AAAA) Heath Chambers 3 (AAAA) Don Mills 3 (AAAA) Jonathan Bromley 3 (AAAA) Mark Hartoog 3 (AAAA) Tom Alsop 3 (A-A-) Mike Mintz 2 (AAAA) David Scott 3 17 joined for the call. ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// May 4 2009 ///////////////////////// Agenda: 1. Review IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Heath - assume patent policy was read Second: Mark Abstain: None Opposed: None Approved 2. Approving previous meeting minutes. --------------------------------------- Approving minutes: April 13, 20 combined 2009 meeting minutes http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_April_13_and_20_2009_Minutes_combined.txt April 27 2009 http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_April_27_2009_Minutes.txt Move: Dave will move to pass both minutes (April 13,20 and 27) Second: Cliff Abstain: Opposed: Approved 3. Updates from p1800WG / ------------------------------------------------------ The P1800 Will be meeting this Thursday May 7th. We have until then to request for an extension. 4. Review results of email vote ended May 1 2009 ------------------------------------------------------ [http://www.eda-stds.org/sv-ec/Minutes/sv-ec_email_vote_May_1_2009_results.pdf] The email ballot that ended May 1 2009. Here is the summary. Of 17 eligible voters 13 sent in their votes. Heath, Tom, Jonathan, Steven, David, Neil, Mark, Francoise Gord, Stu, Arturo, Mike Mintz, Don DID NOT PASS: 15 total p1800-2009draft8 listed by ballot id ================================================================ id 19 Francoise I would add the bubble with preponed for showing the PLI region, at least it shows consistency. AI: Francoise - put a proposal for id 19. id 37 in mantis 2700 Arturo id 38 in mantis 2700 Arturo Items 37 & 38 are misleading. The part in Equality and Comparison that says: Each operand can be a string literal or an expression of string type. If one of the two operands is a string literal, it shall be implicitly converted to string type... Can be misinterpreted to mean that when both operands are string literals the operation is a string operation. A better way might be: One or both operands can be an expression of type string; one operand can be a string literal. If only one of the two operands is a string literal, it shall be implicitly converted to string type ? Likewise, the change to concatenation seems to change the semantics of string s = { "a", "b", "c" } and is IMHO less clear than the original text - the only change to concatenation should be to replace "of type string" to "expression of type string". Jonathan - the proposal has been updated. AI: Mehdi - put mantis 2700 up for an email vote. id 44 mantis 2701 Tom, Gord, Arturo Gord [from the email vote result text] I'm going to object to this on the philosophical basis that I think that this change (as well as others) is going way too far in terms of trying to dictate the details of vendor implementations regarding warnings. For issues such as warnings (LRM mandated or not), vendors have legacy reasons, optimization reasons, flow reasons, etc. to not be too tightly bound by the LRM. Vendors will, if business or technical reasons dictate, ignore any such mandates and trying to be too prescriptive in this arena is almost certainly going to be routinely ignored. Mandating a warning is bad enough, trying to dictate the details is not something that I am willing to support. If the reference to a single error per operation is removed, I will grudgingly support the rest. Arturo [from the email vote result text] The new text is way too verbose, less accurate, and way too restrictive regarding when and how many warnings should be issued. There was nothing wrong with the previous verbiage. The issue raised in this item was to clarify the behavior of the assignment of an unbounded queue to a bound queue. I believe this can be better handled by clarifying the behavior of assigning to a bounded queue an aggregate type (i.e., a queue or other unpacked array) in terms of the set of individual assignments. As to the warnings, this proposal is too restrictive to vendors, and the LRM generally gives wider latitude to implementations with respect to warnings. Tom [from the email vote result text] I have a lot of issues with the wording and understanding on this proposal for the new sub-clause 7.11.5. 1. 'Tools' should be 'Implementation'. 2. The third sentence states that "For any such violating operation, a warning shall be issued", but then the next sentence it states "Tools should issue exactly one warning". In clause 1.5 the conventions for 'shall', 'should', 'may', and 'can' are clear. I just want to make sure we are being clear in this new sub-clause WRT to these conventions. Seems like the 4th sentence should read that "Implementations shall issue exactly one warning"? 3. This sentence really confused me "If a violating operation attempts to write more than one element of a bounded queue, any element with index less than or equal to the bound shall be written exactly as it would be if the queue were unbounded." Perhaps an example would help. =================== Gord - now ok with the updated proposal. Steven - ok even it doesn't match the implementation details Move: Tom, to approve the proposal for 2701; 2701-2.pdf Second: Jonathan Abstain: Opposed: Approved Passed unanimously id 47 mantis 2713 Tom. [Stu abstain] -- stu voted no! Stu [from the email vote text] The "see text" that is added by the proposal is not clear. See what text, where? I will change my vote to Yes if ?see text? is replaced with a cross reference. Tom [from the email vote text] Just want to understand why the proposal is using "Error, see text"? What text? Is this something the implementations are expected to print out? Can we just put "Error"? Steven - can add a cross reference. (as described in this sub-clause) AI: Steven - update with a reference to "text above" Move: Stu approve the proposal for mantis 2713 with friendly amendment, 'see text above' Second: Tom Abstain: Opposed: Approved Passed unanimously. id 57 mantis 2698 Tom Tom [from the email vote text] I am not convinced that "pure" is required in order to create what is coined a "pure virtual method". It's really ambiguous and seems like you can create a prototype virtual method and any level of abstract class hierarchy and only be forced to override it when you extend it to a non-abstract class and hence create the object out of it. I guess I am asking what the intent behind the "pure" keyword is? If an abstract class at any level only prototypes a method, does that mean we have to label it "pure". Tom - Dave and Steven already replied to Tom's concerns Move: Tom approve the proposal for mantis 2698 Second: Arturo Abstain: Opposed: Approved Passed unanimously id 60 mantis 2719 Jonathan Jonathan [from the email vote text] The first occurrence of "typedef" in this sub-proposal should be replaced with "type". I will change my vote to YES if this is done. Tom [from the email vote text] Is it just me or did we forget the second 'typedef' change to 'type' in the previous sentence? Gord - for issue 60, the first sentence is a more specific listing. The second sentence is a bit more general. Doesn't object to the use of typedef in the first sentence. Jonathan - "typdef name" seems to be odd. Gord - that isn't a problem. Tom - remove "or type parameter" from second sentence (id 60) Move: Gord - approve the proposal for mantis 2719 with the friendly amendment Second:Tom Abstain: none Opposed: none Passed unanimously id 122 mantis 2543 Arturo - Merge 120, 122 and use 2543 as the mantis for the proposal Arturo, Jonathan - approve the proposal for 2543. Move: Arturo merge 122 and 120 and use 2543, remove 122 from 2719 Second: jonathan Abstain: none Opposed: none Passed unanimously AI: Mehdi - update 2719: friendly amendment for id 60 and remove id 122 id 67 mantis 2358 Mark, Arturo Mark [from the email vote text] Shalom has proposed some additional changes. Arturo [from the email vote text] I'd like to see some of Shalom's feedback incorporated and more carefully reviewed. Mark - uploaded a new proposal that has the change Shalom requested Gord - there are a couple of typos , the word subclass is spelled wrong Stu, Gord - Passed unanimously Move: Stu - move to accept 2358 with the spelling corrections Second: Gord Abstain: none Opposed: none Passed unanimously id 107 mantis 2711 Steven, Arturo Steven [from the email vote text] I will not approve any further creep in the functionality of ref args of covergroups, until it has been specified that the actuals to such arguments must be static variables. At present there is nothing to prevent passing an actual whose lifetime is shorter than the covergroup. Arturo [from the email vote text] I don't think these should be allowed. Arturo - the clocking event is outside the scope of the covergroup Steven - thinks that can be adjusted. - thinks we need to say ref args are statics. Arturo - doesn't want to make them static Steven - mostly concerned about automatics used in this context Arturo - what about dynamic arrays? Steven - we get an x value in those cases. That case is more well defined. Arturo - we could say the behavior is undefined in that situation. Gord - that is a dangerous situation. Jonathan - the only problem is that it could mess up the covergroup. Steven - in theory there could also be segmentation faults. Dave - isn't that a separate issue? Steven - has no problem making the list of formals in scope. Dave - it is still a separate issue (a covergroup referring to dynamic objects) Steven - should have put in a ballot comment on the ref issue, and would like to push it here now. Gord - that issue already exists. Would rather clarify this one. Steven - thinks this extends something that already has problems. - extending the scope of where the existing problem could exist. - A ref to an automatic. Gord - an event control adds more opportunity for the problem to exist. Jonathan - it is ok though, if the automatic outlives the covergroup Dave - this proposal doesn't address that issue. Gord - would oppose saying that we can only have statics. Move: Dave - approve 2711, as written Second: Gord Abstain: Jonathan - doesn't feel confident to vote for, lead towards conservatism. Mark - not sure if he knows enough to vote either way Heath - same reason as Mark. Opposed: Steven, Cliff - passing it could lead to a chance of no vote on re-ballot. At this point Mehdi called for individual to anounce their votes again, note: Don M did not respond to a call. Approve - Gord, Dave, Francoise, David, Neil, Ray 6 Opposed - Steven, Cliff, Tom 3 Abstain - Heath, Jonathan, Mark 3 2711 is approved with 6 Yes, 3 No, 3 Abstain. Mehdi: I am not sure about the rules in here though, I need to check the rules on this after the meeting. AI: Mehdi - for 2711, check the rules for voting, yes/no/abstain items. id 115 Tom This is a small change and makes sense. I would personally suggest just striking out the '(up to N-1) completely as it's just confusing, however the proposed change is more accurate, although again it does not make sense WRT to the "M is 3 and N is 3" example that is provided. Tom - can we just struck the '(up to N-1)' Neil - ok as written. Move: Tom - remove '(up to N-1)' (page 485) second: David abstain: opposed: Passed unanimously AI: Tom - write a proposal for id 115 id 181 mantis 2035 Jonathan, Steven, Gord, Arturo Steven Jonathan [from the email vote text] If it's illegal to have methods with static lifetime, then the word "default" in the first sentence of the proposal should be deleted; methods are automatic whether you like it or not, and there's no question of a default. I will change my vote to YES if this is done as a friendly amendment. Gord [from the email vote text] This seems to be too much to adopt on an email ballot. Arturo [from the email vote text] I'm not sure the simplification is worth the backward incompatibility. Steven - it isn't backward compatible Dave - if someone isn't doing this today, it is most likely a bug. Gord - understands the issue that Steven has raised, but thinks this is the right thing to do. Dave - the bnf was not changed. Dave, Gord - Abstain - Move: Dave - approve the proposal for mantis 2035. second: Gord abstain: Steven - it isn't backward compatible Arturo - doesn't want to be blamed for this change. opposed: approved with 2 Abstains id 182 mantis 2514 Tom, Steven, Gord, Arturo Steven [from the email vote text] I don't have an objection to most of the proposal, which I thought was very well thought out and written. However, I find the syntax "pure constraint" to be misleading. For a "pure virtual" function, the "pure" modifies the "virtual", so that it doesn't appear to suggest that the function is pure. It suggests to me that it is purely virtual, not real yet. But "pure constraint" seems to suggest that there is something pure about the constraint. Was the possibility of the syntax "pure virtual constraint" considered? Would there be any problems with that syntax, aside from being wordier? Gord [from the email vote text] This seems to be too much to adopt on an email ballot. Tom [from the email vote text] I agree with the premise of the proposal, just not with some of the wording as it's not consistent with the draft8 wording. Specifically the references to 'concrete type' (Clause 8.24, third paragraph on page 142). "A generic class is not a type; only a concrete specialization represents a type. In the example above, the class vector becomes a concrete type only when it has had parameters applied to it, for example" But this proposal states "A pure constraint represents an obligation on any concrete (non-virtual) derived class", defining a concrete class to a non-virtual class. I'm just unclear about using the wording of 'concrete'. Arturo [from the email vote text] I agree with the general intent of the proposal, but the use of the term "obligation" for the case in which neither pure nor extern is specified seems too strong. I'd also like to hear more discussion on the need for "extern constrain" since constrains do not exhibit the syntactical ambiguity that forced us to introduce this notation for methods. Is it needed strictly for orthogonality with methods? Jonathan - he uploaded a new proposal. Arturo - we may need an email vote for this one. Steven - "pure constraints", pure sitting there by itself is what he doesn't like. Jonathan - ok to use virtual instead of pure. Arturo - constraints are already virtual. - they are overridden. Gord - sort of in favor of what Steven is saying. - prefers to only have one way to say it, doesn't want an optional word. Cliff - what is difference between virtual and non-virtual constraint? Steven - effectively none. Tom - doesn't think it makes much sense to add virtual Cliff - we almost need another keyword to use in this situation. Gord - ok with this proposal as written. Arturo - 18.5.1 wording, external constraint blocks Tom - doesn't like adding the virtual keyword. Cliff - who wants pure virtual, pure Ray - can't have either by itself. Straw poll: Pure virtual - Don, Heath, Steven Pure - Neil, Tom, Gord, Arturo, Dave - strong preference, Ray, Mark Most were just weak preferences. AI: Mehdi - for id 182 mantis 2514 put the proposal into an email vote id 183 mantis 2510 Jonathan, Steven, Francoise Steven [from the email vote text] It may not be clear enough that 6.21 disallows these things from being clocking variables. We have run into issues elsewhere with what is considered a procedural context. If the problem is that this text is more restrictive than the text in 6.21, then why not just use text more like that section. Leave the sentence, but change "dynamic variables" to "elements or members of dynamic variables", and change "or dynamic arrays" to "or elements of dynamic arrays". Jonathan [from the email vote text] I completely disagree with this change. Clocking blocks are static declarative constructs, fixed at elaboration time, and the linkage between a clocking block and its clocking signals is essentially static. This change may possibly make sense as a future enhancement but I see no reason to implement it at this time. Francoise [from the email vote text] It is not clear what is allowed as a clocking signal and why the text in 6.21 applies to clocking signals. I think the text should be present or at least a reference to a particular paragraph of section 6.21 Jonathan - he misunderstood the issue, and rescinds his no-vote Steven - repeat the text in 6.21 in 14.3 AI: Dave - id 183 mantis 2510 will update the proposal to have a xref to 6.21. AI: Mehdi - id 183 mantis 2510 put up for an email vote NOTE: We ran out of time before finishing the review of email results. 6. Next meetings in 2009 ----------------------------------------------------- Monday May 11 2009 11:00-1:00pm Dave - are there any that we want to request an extension for? Gord - constructor initialization is the big one. Won't be done by 5/14 Steven - repeat the text in 6.21 in 14.3 Arturo - constructor order calls vs. initializations. - base classes constructed before used by derived classes. - Java vs. c++ Gord - mantis 2597, id 49, initialization of properties Arturo - he had an issue with virtual methods in constructors. Gord - that is a separate issue. There are issues even if we don't take virtual methods into account. AI: Arturo - send email on it. Gord - will be busy until Friday (traveling) Cliff - the sv-bc will not be requesting an extension. AI: All - send email for any that remain open that should be done for this PAR. === action items list below is provided for members reference === not part of official meeting minutes ================= Action item list provided for sv-ec =================== ============ from May 4 2009 meeting =================== AI: Francoise - put a proposal for id 19. AI: Mehdi - put mantis 2700 up for an email vote. AI: Steven - mantis 2713 update with a reference to "text above" AI: Mehdi - update 2719: friendly amendment for id 60 and remove id 122 AI: Mehdi - for 2711, check the rules for voting, yes/no/abstain items. AI: Tom - write a proposal for id 115 AI: Mehdi - for id 182 mantis 2514 put the proposal into an email vote AI: Dave - id 183 mantis 2510 will update the proposal to have a xref to 6.21. AI: Mehdi - id 183 mantis 2510 put up for an email vote AI: Arturo - send email on mantis 2597, id 49. AI: All - send email for any that remain open that should be done for this PAR. ============ from April 27 2009 meeting =================== AI: Stu - id 42; write a proposal (the third 'is'). Dave mentioned a second spot also. AI: Jonathan - id 138 put together a proposal (in the coverage section) AI: Mehdi - id 140 put into email vote - consider for next PAR. AI: Gord - id 52 and 64 create a proposal for an update to 8.22. Won't have time to review the whole LRM for other places to change. AI: Francoise - id 52 and 64 will make a more complete proposal. AI: Gord - id 51 will put together a proposal. AI: All - ids 67,53,55,109,111,49 send email on it. AI: Steven - id 21, will gather some input on this. mantis 2715 AI: Steven, Arturo, Gord - review the set of points in mantis 2715 (id 21) AI: Dave - send email to Mehdi on the mantis items that address his AI/s ================= Action item list provided for sv-ec =================== ============ from April 20 2009 continuation meeting =================== AI: Steven - row 146 id 47 create a proposal for updating the table. AI: Mehdi - row 148 id 48 add to an email vote, one of the canned responses should work. AI: Francoise - row 149 id 49 will add and email link to the mantis item. AI: Steven - row 150 id 50 will track down what text he thinks needs to be changed so that we can think of these as class members. AI: Francoise - will have a proposal by next meeting. AI: Arturo - row 151 id 51: take a look at this one (and line 152 id 52) AI: Francoise - add to mantis 2575 (line 150, id 50) AI: Mark - row 153 id 67write up a proposal AI: Francoise - row 154 id 53 write a proposal to move that one sentence earlier in this section. AI: Jonathan - row 158 id 182 will take a look at it. AI: Mehdi - row 167 id 183 add to the email vote. ================= Action item list provided for sv-ec =================== ============ from April 13 2009 meeting =================== AI: Mehdi - conduct an email vote on the trivial items.[requires proposals] AI: Steven - row 128, id 20; put together a proposal, mantis 2634 AI: Steven - row 130, id 21, will gather some input on this. AI: Dave - row 131, id 184; put together a proposal. AI: Arturo - row 132, 133, id 30 & 31; write it up, both 132 and 133 AI: Stu - row 134, id 35; writeup a proposal AI: Jonathan - combine rows 135-139 [ids: 36-40] into one mantis item. AI: Dave - row 140, id 186; put together a proposal. AI: Dave - row 141, id 43; put together a proposal for this AI: Jonathan - row 142, id 44; will put together a proposal. AI: Dave - row 143, id 188; will look into 141, 144 AI: Dave - row 144, id 45; combine this with row 141, id 43 AI: Stu - row 145, id 46; will write a proposal AI: Dave - row 147, id 181; follow-up on thisfor now AI: Gord - row 149, id 49 [not here, but on his list to discuss/review] AI: Francoise - row 150, id 50; will follow-up for now AI: Francoise & Gord - row 151, id 51; will follow-up for now AI: Francoise - row 152, id 52; will follow-up AI: Francoise - row 153, id 67; will look at it. AI: Francoise - row 154, id 53; will follow-up. AI: Francoise - row 156, id 55; will follow-up, non-trvial AI: Cliff - row 157, id 57; put together a proposal AI: Dave - row 158, id 182; follow-up, proposal, maybe trivial. AI: Mehdi - row 159, id 58; editoral, assign to editor. AI: Gord - row 160, id 59; related to id 50. AI: Mehdi - row 160, id 60; editoral, assign to editor AI: Mehdi - row 162, id 61; editoral, assign to editor AI: Gord, & Francoise - rows 163-166, id [59-62]; to follow-up. AI: Dave - row 167, id 183; follow-up, non-trivial AI: Mehdi - row 168, id 80; proposal exists, add to email vote AI: Mehdi - row 169, id 81; send to sv-ac; sv-ec has no change to recommend. AI: Mehdi - row 170, id 101; send to sv-ac AI: Ray - row 171, id 102; put together a proposal AI: Dave - row 172, id 102; follow-up, nontrivial AI: Dave - row 173, id 190; follow-up, nontrivial AI: Mehdi - row 174, id 104; assign to editor. AI: David Scott - row 175, id 105, follow-up, non-trivial AI: David Scott - row 176, id 106, follow-up, maybe trivial AI: David Scott - row 177, id 107, follow-up, non-trivial AI: Mehdi - row 178, id 108; assign to editor. AI: Francoise - row 179, id 109; try to get more information AI: David Scott - row 180, id 110; make sure it is a duplicate AI: Francoise - row 181, id 111; get more clarification. AI: Mehdi - row 182, id 112, assign to editor AI: David Scott - row 183, id 113, follow-up, trivial. AI: Arturo - row 184, id 114, put a proposal together; non-trivial AI: Mehdi - row 185, id 115; no change needed AI: David Scott , Gord - row 186, id 116; follow-up. non-trivial AI: Mehdi - row 187, id 117; assign to editor AI: Mehdi - ro2 188, id 118; assign to editor AI: Mehdi - ro2 189, id 119; assign to editor AI: David Scott- row 190, id 121; follow-up, non-trivial. AI: Mehdi - row 191, id 122; assign to editor AI: Arturo - row 192, id 120, follow-up, non-trivial. AI: Mehdi - row 193, id 134; send it to the sv-bc AI: Mehdi - row 194, id 135; send it to the sv-bc (duplicate of id 134) AI: Mehdi - row 195, id 137; assign to editor AI: Dave - row 196, id 185; follow-up, trivial. AI: Dave - row 197, id 192; follow-up, non-trivial.