SV-EC Ballot Resolution Committee Meeting April 11, 2005 11:00am - 1:00pm [Minutes distributed for approval at next (sv-ec) committee meeting] (01) Day (41) (00) Month (44) (00) Year (55) --------- Attendees ------------------ (-A) Arturo Salz (AA) Brad Pierce (AA) Cliff Cummings (AA) Dave Rich (AA) Francoise Martinolle (A-) Karen Pieper (AA) Mehdi Mohtashemi (AA) Neil Korpusik (AA) Ray Ryan (AA) Steven Sharp (AA) Surrendra Dudani (-A) Gordon Vreugdenhil (--) 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: Brad Second: Cliff Abstain: Opposed: 2) Review Meeting minutes, April 5th, 2005. http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_5_2005_Minutes.txt Move: Dave Second: Surrendra Abstain: Opposed: 3) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls A) Issues that have been resolved in previous meetings and required proposals. Couple require some fixes to proposals: Issue: 250: (Mantis 636) it should be page 322 (not 232) Spreadsheet is different from what Ray added. Ray: sentence to end of paragraph. implicit sampling is not defined - last sentence in first section, should not be in (). - "it has no effect" --> "it shall have no effect" - Second section: "Other types option" --> "Other type options" Move: Brad with changes noted above. Second: Ray Abstain: none Opposed: none Approved -- reapprove with changes [AI: Ray to fix the 250 and upload ] Issue: 252 (Mantis 637) Brad: is not the same as the spreadsheet. Ray: the period was not supposed to be there. explicit call to sample, that sampled event will increment once one increment for sampled call. Neil: clocking event is mostly used in that Arturo: definition says. Ray: a reference to the example preceding to this text. "A transition bin is incremented at most once per clocking event" -- proposed "A transition bin is incremented at most once per sample". -- agreed Left it "as-is" in the mantis writeup. Move: Brad Second: Ray Abstain: none Opposed: none Issue 252 passes (re-approved with changes) B) Issues not resolved in previous meeting Issue: 229 (Mantis 644) Dave: tried to pass in BC but too many abstain. recommendation was for BC; SVBC has no objection but punted it back to SVEC. Francoise: old proposal Dave: removed dynamic type inside the struct, explicit for unpacked struct containing union, as well as packed struct shall not be initialized. Brad: also syntax box 4-1, 4-4 modified (proposed as the BC), Dave: state variables of randomization structure Brad: if continuous assignmen-- error Dave: by existing rules initialization is procedural assignment, not allowed to initialize and drive a value to it. Brad: maybe ignored instead of error. Arturo: struct as automatic variable. Brad: if continuous assign, is error, because it is a variable. Ray: error checking is difficult Gord: because you would not know if there is a continous driver, deal with initialization is odd way. making error is in line with other checks. initialized proceduraly, continous Brad: no example was available, you can initialize things already, why does the initializer follow the type. Arturo: it is part of the type. Brad: the synthesis would allow the initializer to accept Dave: been added to 13.3, it has to be inside of a class randomized method applies to structure inside a class. Arturo: in that example if not in class. Move: Dave, to accept the amendemnt as written 644 with the change to syntax box 4-1 and 4-4. -- new, endclass keyword should be bold Second: Neil Abstain: Opposed: [AI: Dave update the proposal Mantis 644 with changes listed above] Issue 230: Mantis 646 Dave: change the note to normative, continuous or procedural continuous assignment (it is a force). Francoise: class, static. Brad: why do we have to define it Arturo: take the last sentence. Arturo: if you do a procedural assignemnt, assignement creates a new dynamic array. now enable it to the object as a whole, but not an individual member Gord: issue here dynamic array contain object, update ref will be ok dynamic array of ints, will be problematic Arturo: passing references to dynamic arrays, Gord: with refs it is explicit about it, it is determined by the call. Ray: if continous assignemnt to dynamic array, how often dynamic array get re-allocated. Arturo: wheneve array or index changes Ray: can do a new on the array, Brad: no, it is a procedural assignment. Steven: force, cand they do it. how do you consider dynamic array in the RHS, or event control, element of old array, or new array. Arturo: switch to the new array. change the within, it would be restrictive. if we want to add explanatory clause, you can have entire dynamic variable to be written by procedural. Move: Dave, with the following changes to the proposal 1. Remove last sentence in proposal (Arturo says it is misleading if placed here). "A class object handle or dynamic object as a whole can be declared as automatic or static, but its members are always dynamic." 2. "shall be limited to within procedural blocks" --> "shall be limited to procedural blocks" Second: Arturo Abstain: Opposed: [AI: Davet update the proposal Mantis 646] Issue 232: for/join life-time Gordon - there can be a ref to an automatic used in a fork/join_none, fork/join_any. Lifetime issues. Not a compile-time issue. May have no knowledge of what a task will do. Ok to allow to be passed to functions (just not tasks). Don't know the prototype of pass by ref early on. Arturo has some particular cases in mind when he desires to retain this capability. Would be useful if users could specify which automatics to preserve. Only in the tasks that contain join_any or join_none would it be necessary to flag which automatics could be used this way. OK with: Within join_none,_any use of refs of automatics only allowed in declarations used immediately in the fork/join block. Arturo - Says that some of Gordon's issues are optimization issues. Too restrictive to not allow automatics to be passed by ref. It looks like this change is getting too close to implementations. There are places where you can "see" that an automatic variable could potentially be passed by reference to a task. Sometimes want to pass a ref instead of a large variable. Disable fork creates a similar issue. Steven - automatics are based on a stack-based implementation Could be very expensive to not use a stack-based approach. Could dramatically slow-down existing v2k code. Dave - this wasn't discussed in the bc. Seven - did mention issue with operations on references. [AI: Gordon, create a mantis and put a proposal rewised for further discussion -- Mantis 652 created (April 11, 2005) ****] Issue 233: Surrendra: clarification of the null-pointer, Ray: existence of null-pointer in both sides, what would happen Arturo: what would you do if this is struct, a handle is not an streamable type. can not stream an embedded handle. Ray: if a class that has an embedded class, Gord: class insntance can be bit streamed, what you do a bout a Null. how do you decode it. Ray: you use a greedy algorithm, assume the class does exist and encode Arturo: all of these issues are with struct Ray: if you have struct with another struct is not the same as class with another class. Surrendra: the intent is to go recursively on the class. do not get the same result. Ray: is the cyclic illegal? Dave: what is the precedent for dynamic vs class Arturo: cyclic will be undefined. Francoise: built-in operator on the class will be good. Brad: why is this necessary, Arturo: came from ac, wanted bit-stream, serialize the data, If reconstruction is required, Surrendra: the greedy algorithm will not create the same object, Neil: it looks like to ignore the handle. Steven: the user supplies the method of what they want. [AI: Surrendra find out from AC chair: is reconstruction important, not allowed to traverse the embedded handle. Issue: 163 (Mantis 554) Move: Arturo Second: Brad Abstain: Neil (not read the proposal [read later -ok]) Opposed: none Issue: 255 (Mantis 641) Move: Arturo Second: Brad Abstain: Neil (not read the proposal) Opposed: none 255 approved 4. Next meeting time Because of short time left till next week's P1800 WG meeting two time slots are reserved: a) Tuesday April 12, 2005. 2:00pm-4:00pm PST b) Friday April 15, 2005 - 8:00am-10:00am PST ============== SUMMARY of action items and issue items ============ == Approved issues === on April 11, 2005: Issues approved: 250 ( Mantis- 636 ) [approved on 4/5/05, re-approved 4/11/05] 252 ( Mantis- 637 ) [approved on 4/5/05, re-approved 4/11/05] 229 ( Mantis- 644 ) 230 ( Mantis- 646 ) 163 ( Mantis- 554 ) [one abstain -- Neil, (not read)] 255 ( Mantis- 641 ) [one abstain -- Neil, (not read)] on April 5, 2005: 11 ( Mantis- 410 ) 109 ( Mantis- 537 ) 161 ( Mantis- 550 ) 237 ( Mantis- 616 ) 250 ( Mantis- 636 ) 251 ( Mantis- 643 ) 252 ( Mantis- 637 ) 253 ( Mantis- 649 ) [combined with 254 into one Mantis (649) 254 ( Mantis- 649 ) [2 abstains: Francoise & Steven, no knowledge of coverage] 270 ( Mantis- 638 ) 271 ( Mantis- 639 ) [one abstain: Steven, not read the proposal] 272 ( Mantis- 640 ) 283 ( Mantis- 615 ) [Votes: 4 yes(Brad,Neil,Dave, Surrendra), & Mehdi 3 abstain:(Ray,Francoise, Steven), and 1 No (cliff)] Issues marked not feasible 204 Issues to be sent to other committees for review: 125 --> sv-cc 229 --> sv-bc (the first portion) Action items: (4/11/2005) 1) Issue 250 (Mantis- 636): Ray to place updated proposal on SVDB. 2) Issue 252 (Mantis- 637): Ray to place updated proposal on svdb. 3) Issue 229 (Mantis- 644): Dave update proposal on svdb. 4) Issue 230 (Mantis- 646): Dave update proposal on svdb. 5) Issue 232 (Mantis- 652): Gordon to create a new proposal/svdb. 6) Issue 233 (Mantis- ? ): Surrendra to ask svac chair for clarifications. ================================== == Issues not yet resolved ======= Negative / High -----Issue # -- Mantis # ------ 232 652 233 235 236 238 & (together) 189 596 240 Positive / High 281 Negative 266 (NoTES) Negative / High -- Issue # --- Mantis # ------ 255 Positive High -- Issue # --- Mantis # ------ 2 5 7 8 10 13 22 23 24 30 31 551 32 553 36 270 94 511 95 512 96 516 97 518 98 519 99 521 100 522 101 523 Positive / Low -- Issue # --- Mantis # ------- 122 251 123 253 162 552 171 564 187 594 188 595 190 597 199 607 200 608 201 609 Issues sent to sv-ec from other committees 1 from sv-bc 244 from sv-bc ------------------------------------------------------ For issue 244, the feedback was: "Currently, the actuals of interface ports are not restricted in terms of hierarchical references to interface instantiations. This can cause problems similar to other circular elaboration dependencies with generates that IEEE-1364 very carefully avoids." And the proposed addition to the LRM forbids interface port actuals from being hierarchical references through arrays of intances or generated instances: At the end of 20.2, ADD If the actual of an interface port connection is a hierarchical reference to an interface or a modport of a hierarchically referenced interface, the hierarchical reference shall refer to an interface instance and shall not resolve through an arrayed instance or a generate block. The SV-BC thought the SV-EC should know about such a restriction. Would you please run this by the EC? ------------------------------------------------------ ==== Issues sent to other committees for review ==== 125 294 (sv-ac) (vpi question) 229 644 (sv-bc) (struct initialization) =============================================================== Action items: (4/5/2005) 1) For issues 270: Brad to place it on SVDB. -- Mantis: 638 2) For issues 271: Brad to place it on SVDB. -- Mantis: 639 3) For issues 272: Brad to place it on SVDB -- Mantis: 640 4) for issue 250 Ray, to fix the sentence, add to svdb -- Mantis: 636 5) for issue 252: Ray to place it in svdb. -- Mantis: 637 6) for issue 255: Brad to place proposal in the database -- Mantis: 641 7) for issue 229: Mehdi to send it to sv-bc for review/discussion of -- Sent to BC the first portion, initialization 8) for issue 229: Dave/Ray to put further details to the proposal for -- Mantis:644 review next Monday. 9) for issue 11: Brad to place the proper html proposal in svdb -- Mantis: 11 10) for issue 230: Dave to do the rewrite/rewording of the proposal -- Mantis: 646 11) for issue 233: Surrendra to write more clarification to the bit-stream operators for class, pack/unpack (for Monday discussion) 12) for issue 236: Ray to finish the proposal for default args, for -- Mantis: 642 Monday discussion, 'has to be visible, by caller..' 13) for issue 237: Brad to place into the svdb -- Mantis: 616 14) for issue 239: Brad to place into the svdb -- Mantis: 617 15) for issue 251: Brad to place into the svdb -- Mantis: 643 16) for issue 125: Mehdi to send to sv-cc for review -- sent to CC 17) for issues 253 & 254: Mehdi to add the proposal into svdb -- Mantis: 649 18) for issue 161: Brad to place into the svdb -- Mantis: 550 19) for issue 109: Brad to place into the svdb (Mantis 537) -- Mantis: 537