SV-EC Ballot Resolution Committee Meeting April 05, 2005 9:30 am to 5:00 pm [Minutes distributed for approval at next (sv-ec) committee meeting] (0) Day (4) (0) Month (4) (0) Year (5) --------- Attendees ------------------ (A) Brad Pierce (A) Cliff Cummings (A) Dave Rich (A) Francoise Martinolle (A) Karen Pieper (A) Mehdi Mohtashemi (A) Neil Korpusik (A) Ray Ryan (A) Steven Sharp (A) Surrendra Dudani (-) Arturo Salz (-) Bill Paulsen (-) Dennis Brophy (-) Stu Sutherland (-) Alex Wakefield (-) Yogesh Pandey (-) Don Mills (-) Eugene Zhang (-) David Smith Agenda: 1) Review the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Karen Second: Ray Abstain: Opposed: 2) Procedures and Process Discussion for Ballot Issue Resolution A. Per Johny: Voting rights for our meetings We are now acting as a Ballot Resolution Committee, and not as the technical committees. As a result, all of the voting priviledges need to be reset. Anyone who shows up for the first 3 meetings can vote. No proxy vote allowed. After that, one needs to attend 2 consecutive meetings to gain voting rights, and 2 of the preceding 3 to retain them. B. Schedule: 1. Absolute deadline to resolve issues is April 19th. Champions meet April 11th, this is the effective date when issues should be resolved. According to Karen, anything up to 19th will most likely go to p1800. Should have an estimate of time for any item to be considered. c. TRACKING: a) Only the approved LRM changes go to svdb. b) All issues are to be tracked in spreadsheet. c) Committees to mark issues as resolved when appropriate. d) Resolved issues go to the champions as well as Stu for editing. e) Issues are sent back to the committees for review and closure. Karen: Spreadsheet will go out with re-balloting. D. Order to resolve issues Small amount of time on low-hanging fruit Negative-high Positive-high Negative-medium Positive-medium etc. Karen: from IEEE guidelines: Committee must address all negative ballot comments. but Johny has decided that committees will adress all ballot comments. Discussion on Consensus Building: - The concept of decreasing consensus was explained as the outcome of the committee making a change that could cause more negative votes in the re-ballot. - The best approach is to only make changes that don't threaten consensus. 3. Issues: http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls Start with low-hanging fruits (possible): Issue 270: Move: Brad Second: Ray Abstain: none Opposed: none Approved [AI: Brad to put this on the svdb] Issue: 271 Move: Dave Second: Surrendra Abstain: Steve (have not read the issue) Opposed: Approved AI: Brad to place this on svdb Issue 272: Move: Surrendra Second: Neil abstain: opposed: Approved Issue 281: Flexibility for the implemention to return value. Returning a positive number, checking for something greater than 0, which is positive. Dave: if it is flexiblity issue, explain what the implementation does so all others will provide same functionality * Decision: Leave it till end of the meeting for now. Not a consenus. For next Monday meeting. Issue 283: Correcting the BNF for the definition., section 5.1,5.6 Dynamic arrays can be multi-dimensional. Dave: Queue of any type, valid type, queue. In 5.1 there is discussion on this but this section is titled NOTES, as part of issue 262 for each committee, need to look at the notes. Cliff: has looked at the spreadsheet looking at the notes. 5.1 was not part of the issue 266 on the ballot. Cliff: proposed correction to 5.3, multi-dimension, Ray: resize the dynamic array, you re-allocate for the big size, index have variable instead of constants. Does not preclude contiguous with bit-padding. Dave: oversight on dynamic array be type-def. Note: Brining new issues is Not allowed by IEEE rules during balloting. Steve: Have to think about this issue, you can not change element sizes. Move: Brad to accept the changes offered in 283 Second: Dave Abstain: Ray (resizing multi-dimenaionl rules need to be looked into). Francoise, Steven, opposed: Cliff (vote no, So all can digest it till Monday). Will have to check the IEEE rules. for simple majority. Quorum as of now:9 people. Approved. Note: I have asked Karen for clarification to the simple majority, so far the vote stands, Issue 283 is approved. [AI: Brad to place it in SVDB] Brad: how about some low hanging Disapprove issues. Issue 250: Brad: The parenthetical comments could be removed from the proposal text. The change is the add the statement to end of page 323 Move: Ray Second: Surrendra Abstain: Opposed Approved. [AI: Ray, to fix the sentence, add to svdb Issue 252: Dave: add the paragraph, 329, 21.4.1, add to before Forexample., after the first sentence of that paragraph. Move: Ray Second: Dave Abstain: Oppose Approved: [AI: Ray, put this in mantis] Issue 255: cross_auto_bin_max is not defined. lets remove. * Decision: Monday to decide to remove it or not * [AI: Brad place the proposal for removing cross_auto_bin_max option in the svdb for everyone's review ] Issue 229: Brad: the concept, is ok, but not complete definition of what should be don, no bnf item Neil: two issues, one initialization for BC issue, and the part for section 13 is more of EC issue. Dave: initialization is not synthesis, BC. Francoise: What is the advantage of initializtion for struct. Brad: how about nets Steven: classes are initialized at instantiation, different for struct. Is there any rule to deal with Nets? Neil: it is usefull. Mehdi: Can we work on a further detailed proposal and leave it for Monday. Steven: is it allowed on dynami. Brad: the '{1,2,3} is not fixed size array. Dave: the dyanmic array is not right example, have to remove it. * Decsion: [Leave it for Monday meeting] * [AI: Mehdi: Send to sv-bc for discussion and review -- specifically first section, initialization, believed to be more of BC issue] * [AI: Dave/Ray to further detail the proposal for discussion on Monday] Issue 11: inside operator/wildcard, Proposal: Mantis item 410, the bug-fix has the proposal. Move: Steven Second: Brad Abstain: Opposed: Approved *[AI: Brad to put in proper html proposal]. Issue 266: Cliff if working on this. Folks need to watch for emails, *[Decision] Will take a look at on Monday. Issue 230: Neil: why event is not in the rewrite. Dave: dynamic is overlaoded word in the LRM. Steven: continuous assignments for automatic is forbidden. How about force, is it an issue? rewording required: Automatic variables and elements of dyanmic (tangential discussion: 14.7 event variables, non-blocking triggers, non-blocking assignments, event merging) "Automatic variables and elements of dynamic variables shall not be written with nonblocking, continuous or procedural continuous assignments. Automatic variables and references to elements of dynamic constructs—class objects and dynamically-sized variables—shall be limited to the procedural context." *[Decision] We will look at Monday, on the revised statement] **At this point in the meeting Randy (from Mentor joined the conf. call) Issue 232: Ray: why introduce stack semantics, Dave: v2k stack. garbage collection is the key. (ref static, check ) *[Decision] We will look at Monday] Issue 233: Dave: does not say what happens for inheritance, How null pointers are taken care of, how inheritance is done in bit-stream pack, how about unpack. bit-stream operator defined in the context of implicit pack/unpack. [AI: clarification, bit-stream operators for class, pack/unpack -- surrendra] *** (on the next issue at 2:15pm, only participants: Mehdi, Neil, Surrendra, Dave, Ray -- Do not have quorem in the meeting) Issue 235: Heirarchical references to ref ports (formal argument), disallowed. static args in verilog, static tasks exist, pass by reference in static tasks and functions.... not backward compatible. Surrendra: overly restrictive, Dave: dangling references to static refs, a problem. *[Decision] We will look at Monday] Issue 236: Ray: default args, evaluation, may not know the profile in Verilog another solutions: profile defined at compilation (prototype) time, what the function is has to resolve it. context of subroutine, you can have member variable in the function call. *[Decision] We will look at Monday] [AI: Ray finish the proposal for Monday meeting] 'the prototype has to be visible, the caller evaluates it' Issue 238: clock domain, sample the value in the postpone of the previous time slot. When does the update occur. *(3:00pm Francoise is on-line) Is there semantics for updating the value for cb.b observed region Can we figure when the actual update of clock block inputs occur. [AI: Ray, looking at couple of options for update/clocking block/ evaluation/register update, in the context of possible race condition'] [AI: Review this in conjunction with issue 189] *[Decision] We will look at Monday] Issue 240: Complex item, leave for Monday. *[Decision] We will look at Monday] Issue 237: Mantis 616 with friendly amendment: add a reference footnote 6 to this (in A.10) Move: Brad (to approve with above friendly ammendment. Second: Dave Abstain: Opposed: Approved [AI: Brad to add to svdb] Issue 239: Move: Ray Second: Surrendra Abstain: Opposed Approved [AI: Brad to add to svdb] Issue 251: Move: Dave Second: Surrendra Abstain: Opposed: Approved [AI: Brad to add svdb] Issue 125: Pass it sv-cc for consideration. Issue 204: Move: Brad to flag as not feasible. "The committe read and considered this feedback. While it has merit, the committee believes it is not feasible to implement at this time." Second: surrendra Abstain: Opposed: Issue 204 is marked 'not feasible Issue 253 & 254 (combined): with the following amendment: add page 333, 21.5 in the one line paragraph, after default -- 'ignored or illegal_bins'. Move: Ray Second: Neil Abstain: Francoise, Steven (no knowledge for covergaroup) Opposed; Approved. *[AI: Mehdi propose, one mantis item] Issue 161: specparam only in modules. Move: Brad Second: Steve Abstain: Opposed Approve *[AI: Brad add to svdb] Issue 109: Move: Brad All can be class items not just type declaration, and implement the proposal in mantis 537 Second: Neil Abstain: Opposed: Approved *[AI: Brad to add to the spreadsheet and mantis] Issue 189: Section 16.12, Mantis 596 Look at it on Monday in conjunction with 238. 4. Next meeting schedule: Tentative: by phone Monday April 11th, 11:00 am to 1:00pm (regularly scheduled meeting, biweekly). 5. Meeting adjourned at 4:40pm