SV-EC Ballot resolution committee meeting. NON-VOTING meeting Monday June 1 2009 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_June_1_2009_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 000000 000000 112345 Meeting Days: ------------------------------------------------------------------------ (122010 ) Day (307411 ) (000000 ) Month (444556 ) (000000 ) Year (999999 ) ------ Attendees -------------------------------------------------------- (A-AAAA) Arturo Salz 5 (A-AAAA) Cliff Cummings 5 (AAAAAA) Dave Rich 6 (AAAAAA) Francoise Martinolle 6 (AAAAAA) Mehdi Mohtashemi 6 (AAAAAA) Neil Korpusik 6 (AAAAA-) Ray Ryan 5 (-AAAA-) Gordon Vreugdenhil 4 (AAAAAA) Steven Sharp 6 (A-AAAA) Stu Sutherland 5 (AAAAA-) Heath Chambers 5 (AAAAAA) Don Mills 6 (AAAAAA) Jonathan Bromley 6 (AAAAAA) Mark Hartoog 6 (AAAAA-) Tom Alsop 5 (A-A-A-) Mike Mintz 3 (AAAAAA) David Scott 6 Note: this was a non-voting meeting. Everyone that attended gets credit for attending, but it doesn't hurt you if you didn't attend. ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// June 1, 2009 ///////////////////////// Agenda: 1. Review IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt The chair directed everyone's attention to the patent policy. Due to the short notice, this will be a non-voting meeting. We need to address all 22 of the mantis items listed below by June 15th. 2. Updates from p1800WG / ------------------------------------------------------ P1800WG meeting was on May 28, 2009. Neil: At the Working Group meeting is was agreed to allow the committees to continue working on ballot feedback until June 15th. -- All ballot comments need to be responded to. -- WG meets again on June 17th (Wednesday) to do a sanity check on status The IEEE requires that we provide feedback on all ballot comments. At this point in time, I believe that all ballot comments have a mantis item associated with them, except for those that fall into the Editor category. The technical committees need to move all of these mantis items to the resolved state by June 15th. Summary of what the committees are allowed to do: - work on ballot feedback (only ballot feedback is allowed) - write and approve proposals - address feedback from the Champions - resolve mantis items (those that address ballot feedback) - complete all work by June 15th 3. Ballot Comments reviews --------------------------------------------------------- NOTE: Mantis 2736 is the master list for sv-ec ballot feedback. Use it to reference all sv-ec mantis items addressing ballot comments. Neil: There was a concurrent email vote on this, but not too many participated. mistake on 2575, mantis item id 55. copied and pasted description was wrong, number 55 was showing the wrong discreption. email vote was invalid. 3.1 Below is the list of mantis items from the email vote. Concurrent email vote. ------------------------------------------------------------ These should be trivial to resolve. Mantis 2693 id #138 - has a proposal Jonathan - was updated based on the last meeting, just not voted. - 19.5 was updated Mantis 2598 id #52,64 - propose to resolve as a duplicate of 2575 Francoise - Arturo wanted something else. Arturo - merge 2598 with that of 2575. Francoise - we should vote on 2598 separately - then update 2575 with Steven Sharp's feedback. Mantis 2575 id #50,52,55,59,64 - has a proposal See email from Shalom (05/24/09) - bnf issue? Steven - there is a wording issue, class scope prefix, the emphasis was on a particular class. (add word "particular") - that is the whole point of that sentence. - the problem was that the additional text was added to the end of the sentence. Arturo - thinks that some of Shalom's feedback on bnf is not valid. AI: Steven - resend his email vote response to Francoise on this point. AI: Francoise - update the proposal for 2575 with Steven Sharp's feedback. Mantis 2608 id #59 - propose to resolve as a duplicate of 2575 Arturo - thinks 2608 is definitely a duplicate Francoise - we should mark 2608 as being subsumed by 2575 Mantis 2746 id #113 - has a proposal Cliff - it looks like a simple change to an example. David - agrees with the proposal. Mantis 2748 id #19 - propose to resolve as no change required Neil - there is actually only one region, used as both a simulation region and a pli region. Steven - had a question as to whether there could be a way to tell if it is a simulation or pli region. If there is, there is a problem treating it as both a simulation region and a pli region. Francoise - the pli is not suppose to write in that region. Arturo - there are currently some other read-only regions Mantis 2749 id #53 - has a proposal Jonathan - rewording about local and protected property. Arturo - it looks fine Mantis 2750 id #121 - has a proposal Cliff - bnf syntax fix. Neil - the syntax box at the beginning of the section was correct but the text which discusses it is incorrect. Mantis 2745 id #111 - propose to resolve as open Jonathan - no change required - instead of "open" 3.2 The following mantis items are assigned, but don't have proposals --------------------------------------------------------------------- Mantis 2380 id #33,34,56 Jonathan - arrays to be only assignment compatible versus equiv types. - bit stream casting issues certain things are now no longer bit-stream cast going to a variable-sized array is the corner case issue. Cliff - Matt had a concern about this change. Steven - it might be fine in the testbench space. For the design space it might be best to keep the tighter restriction. Dave - the idea is to have tighter checking on aggregate expressions Steven - we need the same set of rules for design and testbench Mark - port expressions would also be affected. Steven - there was some concern about getting input from the sv-bc as well. Cliff - the sv-bc requested that the sv-ec include the sv-bc in the decision making process. Jonathan - 1447 will need to be reworked if we don't make changes here. - Mike Burns wrote most of that one. - A big part of the LRM is badly broken if we leave it as is. Dave - there seemed to be only 2 places where there is a contradiction Mark - is there any contradiction? Jonathan - there is a clear contradiction in the LRM. AI: Mehdi - put up for email vote.- this ballot comment was raised by Cadence. Jonathan - a lot of the LRM would need to be reviewed to check Steven - there may be examples that are invalid Jonathan - LRM is saying things that don't make sense if we insist on the equivalency rule. Dave - concatenation doesn't require equivalent compatibility in the individual expressions. Jonathan - could wrap the entire thing in {} Steven - if have an array in there, it is an aggregate copy for that particular expression. Dave - within each term, require equivalent compatibility. - Jonathan is saying - if there are slices of an array, only require assignment compatibility Steven - re-iterated the idea that Jonathan mentioned with {} Arturo - seemed to be in agreement Steven - Brad thinks this is the one issue that required things to be deferred. Dave - if we now have general consensus we should take that direction. Cliff - should we have Jonathan talk to Matt about it? Steven - thinks we need to make some change, can't just leave it as is. Jonathan - would prefer that his original proposal just went through. - Concern about finding all the places that would need to be changed, if go with a new proposal. Jonathan - willing to put in the work to redo the proposal, but would need to get several people to review it in detail. - 1447 requires a lot of checking, not sure if requires a lot of changes. Steven - it was discussed for quite awhile in the sv-bc today, about as much time as was spent in this meeting... Mantis 1575 id #105, 110 Mehdi - will put it up for an email vote, no change required. Steven - doesn't require a change, but it would possibly help. 3.3 The following mantis items are in the feedback state ---------------------------------------------------------- Mantis 2738 id #115 - we need a pdf file for the proposal AI: Arturo - mantis 2738 create the pdf file. Mantis 2711 id #107 - has a proposal, controversial Dave - the ref arg issue is orthogonal to this issue Steven - ref args should be limited to non-automatics. - adding event controls for ref is creating a bigger issue. Arturo - his concern was that clocking event is not part of the cg. if it is, it would hide the variable in the outer scope. Steven - if have to move it into the scope, it would ... David - it is a bit vague as to whether it is in the scope or not. Arturo - you thought it would be in the scope? David - yes. We have people that have tried this. - the current LRM is not clear on this point. Arturo - yes, there could be an ambiguity in the LRM. David - the ref issues already exist with cg's Steven - if reading something that has gone away, not a big deal - waiting on an event could cause a crash. Dave - both behaviors are currently undefined. Jonathan - that is why we need a 'ref static' Arturo - doesn't think that is the ultimate solution, the compiler should be able to prevent crashes. Jonathan - it seems crazy to add an extension now. David - we view it as resolving an ambiguity. - the argument could be the clock. - if static or not is a legitimate issue, but not related to the ambiguity. Steven - thinks it is worse if we extend the use of refs to events Dave - we want to make cg's more usable. Cliff - Steven - would you be willing to vote no on ballot? - That was my reason for voting no. Steven - Chas is the designated rep. for Cadence Arturo - we could pass it and mention it is in the scope of the cg. - or not allow it. Steven - could stick in a static ref Arturo - that would be less reusable wouldn't it? Steven - treating these as constant refs is a possible solution David - could we just say "it shall be static" Arturo - clocking event based on a class, would then not be allowed. Dave - we could just say a non-automatic. Arturo - we could just add a note that the behavior is undefined. Steven - most loopholes have been plugged. David - "if a clocking event after a ref argument, the behavior would be undefined..." Steven - that would soften my concerns. Arturo - would like to also say the clocking event is within the cg. Mehdi - try to vote on it at the next meeting. AI: David - put together a proposal (do more word-smithing on the reflector) 3.4 The following mantis items are not yet assigned ----------------------------------------------------- Please feel free to write a proposal for one or more of these. Mantis 2694 id #140 Jonathan - thought that no change was required. - too late to make a change. Cliff - "outside of scope"? Jonathan - there are other ways to do this. AI: Mehdi - mantis 2694 add to email vote. Mantis 2692 id #79 Steven - thinks the LRM is currently clear. - is sympathetic to the request. - we could possibly get away with no change. Jonathan - see Shalom's bug note. AI: Mehdi - put up for email vote.- doesn't understand the ballot comment. - isn't it clear in the LRM? Steven - he thinks it is clear. Arturo - he also thinks it is clear. Francoise - can't we just respond that it is clear and point to subclause? "Please make it clear whether for out-of-block functions, default argument values have to be declared in both the prototype and the implementation or just one." Steven - LRM says they have to match, even in defaults, the values don't have to match - if defaults are virtual, don't know which one will be used. - if prototype has a default, all need it. Can't have one if the prototype doesn't have one. Steven - not different in requirement that both must have default, but differ in whether the values must match. - for virtual functions, not sure which one will be used at runtime. Arturo - it sounds like Steven is proposing a runtime check. Steven - if they are allowed to be different he has concluded that they must be virtual - we could change it such that you can only add defaults for derived classes, not remove them. Arturo - it probably best for them to be identical. Cliff - best to leave as is for now. Arturo - there are two issues being discussed. 1. out of body methods declarations need to be identical to the prototype? 2. how does it affect virtual methods in derived classes? Francoise - one could say that out of block definitions are stricter Steven - reviewed Shalom's comments (e.g. interfaces) Mehdi - This requires more discussion Mantis 2606 id #62 Mantis 2607 id #63 Mehdi - Francoise, Gord are listed as to look into this. Mantis 1486 id #190 Jonathan - has written a proposal for this one. AI: Mehdi - put up for email vote. Mantis 1517 id #189 Mantis 1721 id #188 AI: Dave; proposal for 1517 and 1721 Mantis 2715 id #21 Jonathan - sent a long email on his understanding Steven - he added a long bug note on it - it looks like we have found all the places affected. AI: Jonathan - is prepared to write a proposal saying that strings are singular. Mantis 2744 id #109 Francoise - looked at the BNF, though it should be allowed. - only static can be called? Mehdi - ok to say no action needed? Francoise - yes, it is allowed. Asking for people to vote before the meeting. 4. Next meetings in 2009 -------------------------------- Monday June 8 2009 11:00-1:00pm -- voting meeting Monday June 15 2009 11:00-1:00pm -- voting meeting === action items list below is provided for members reference === not part of official meeting minutes ================= Action item list provided for sv-ec =================== ============ from June 1 2009 meeting =================== AI: Steven - 2575 resend his email vote response to Francoise on this point. AI: Francoise - update the proposal for 2575 with Steven Sharp's feedback. AI: Mehdi - mantis 1575 add to email vote. AI: Arturo - mantis 2738 create the pdf file. AI: David - mantis 2711 put together a proposal (do more word-smithing on the reflector) AI: Mehdi - mantis 2694 add to email vote. AI: Mehdi - mantis 2692 add to email vote. AI: Mehdi - mantis 1486 put up for email vote. AI: Dave; proposal for 1517 and 1721 AI: Jonathan - mantis 2715; prepared to write a proposal saying that strings are singular. ============ from May 11 2009 meeting =================== AI: Tom - mantis 2738 id 115 reload as a pdf (Neil can't see it). AI: All - last chance to point out anything that people want to work on. ============ 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 ============ 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.