SV-EC Ballot Resolution Committee Meeting Tuesday April 12, 2005 2:00pm - 4:00pm [Minutes distributed for approval at next (sv-ec) committee meeting] (011) Day (412) (000) Month (444) (000) Year (555) --------- Attendees ---------- (-AA) Arturo Salz (AAA) Brad Pierce (AA-) Cliff Cummings (AAA) Dave Rich (AAA) Francoise Martinolle (A--) Karen Pieper (AAA) Mehdi Mohtashemi (AAA) Neil Korpusik (AAA) Ray Ryan (AAA) Steven Sharp (AA-) Surrendra Dudani (-AA) Gordon Vreugdenhil (---) Bill Paulsen (---) Dennis Brophy (---) Stu Sutherland (---) Alex Wakefield (---) Yogesh Pandey (---) Don Mills (---) Eugene Zhang (---) David Smith ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi Agenda: 1) Review the IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave Second: Gordon Abstain: Opposed: 2) Review Meeting minutes, April 11th, 2005. http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_11_2005_Minutes.txt Deffered this until Friday meeting, since not too many people had a chance to review it. 3) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls Issue 232: (Mantis- 652) lifetime of variables used in threads Gordon: wording on the html issue is more updated. any automatic variables, Arturo: automatic within a task that contains the fork, LRM takes care of it Gordon: the context that encloses the fork-join. Arturo: they are covered by LRM. Gordon: same issue as ref. Arturo: make illegal to ref.you make thread live as long as it needs to live. Gordon: thread of task, task does not return until fork/join Arturo: stack returns until all threads return, nothing implies stack-based in the LRM. Refering to automatic variable throug ref, agreement was to disallow ref in fork/join, restrictions on the outer of fork/join is problematic. Dave: In vera shadow variables get copied to the thread, here we are trying to the same thing. Arturo: separated the issue of life-time of fork/join-none. you need to keep information around to be able to implement disable. It was agreed and in LRM. Ray: in 6.6, end of 6ht paragraph (73) explains it. Arturo: this refers to the item is being discussed. Gordon: you are extending the LRM says Steven: i believe the intent of this statement was. Dave: that does not matter at this point. Arturo: separate two issues, automatic variables to ref. the other is automatic variable. Issue with refering to automatic variable through ref port, disallow refering to it, inside fork/join (none/any) this could potentially force to garbage collect any reference. Gordon: if we strike the phrase: automatic variables or part of that, strike the deletion Change the following text of the proposal: Section 10.6 Variables declared in the block_item_declaration of a fork...join/join_any/join_none block shall be initialized to their initialization value expression whenever execution enters their scope, and before any processes are spawned. Within a fork...join_any or fork...join_none block, it shall be illegal to refer to automatic variables or formals of arguments passed by reference declared outside a fork block other than in the initialization value expressions of variables declared in a block_item_declaration of the fork. TO: Variables declared in the block_item_declaration of a fork...join/join_any/join_none block shall be initialized to their initialization value expression whenever execution enters their scope, and before any processes are spawned. Within a fork...join_any or fork...join_none block, it shall be illegal to refer to formals of arguments passed by reference other than in the initialization value expressions of variables declared in a block_item_declaration of the fork. Remove: The part that said to delete something from the mantis proposal. Section 6.6 - paragraph 6 - last sentence - change "any fork...join block" -> "any fork block" Dave: The block_item_declarations is where the bridge is created. Ray: Section 6.6, paragraph 6. - The intent of the last sentence was meant to apply to all types of fork/join. He rejoined Move: Gordon, based on the changes above, in 652 attached Second: Steven Abstain: none Opposed: none Approved ** AI (issue 232): Dave update the svdb mantis for this item Issue 233: bit-streaming of class Ray: part of motivation was to do deep-copy for class, greedy algorithm for null references would not be sufficient. Arturo: greedy references. you need to ability to break the recursive, the need to parallel to serial and vice-versa. issues will be here for structs as well if you had a handle. Dave: you can not have a class inside of struct, Steven: are there in struct that are not bit-stream type. you can say that. Dave: that is what the proposal. Artruo: no agreed the semantics. ** Decision: Leave it for Friday, waiting for Surrendra to get any feedback from svac chair. Issue 235: (Mantis- 666) pass by ref for static tasks Steven: issue with static variables, unless you want to keep references, one way to access is through heirarchical references. one possible solution to disallow formal ref arguments. this solution disallow ref arguments in static task declaration. no stale references. Arturo: semantics are not ok, Gordon: static task with refs arguments, Ray: what is value of param before task is called. Arturo: you have the default vlaues Gordon: ref args do not have default values. Ray: if not illegal, once you return from the task, during life of task it has no value when you come back. Gordon: ref args always behave as though it is automatic. Dave: why static tasks with references, Steven: static tasks maybe more efficinet, refernces to large data. Gordon: refs as though automatic, from vpi advantage, Arturo: you want to give the same limitations as automatic. Gordon: no heirarchical references to static ref, and from vpi, Arturo: life-time of argument is enclosed in the block. Steven: forbidding ref args to be declared in static tasks. Arturo: you may want semantics of static tasks, can you say ref static, there is no syntax for task to be static, Dave: static arguemnts, are no use. more restrictive: disallow ref ports in static task, if need it automatic task. ** AI: Gordon to write up the proposal in mantis with the same proposal as in the spreadsheet. Vote will be on Friday, Issue 236: (Mantis 642) in which scope are default expressions evaluated? Ray: two alternatives, function delcared inside a class, default value refers the value inside the class. 2nd proposal, default expression from caller, then the default profie must be known, Arturo: something like extern, Gordon: full profile at the time of compilation Ray: list all the ways that have it legal. Arturo: prop A would be some sort of heriarchical references. use model, passing clock by reference, short-cut, pass constants, passing a function, default value is a function return an id, Brad: can that function be taken out of package and $unit, Dave: proposal a was how it is implemented in Superlog. Gordon: A, expression is evaluated in the context of routine declration, Steven: what about a constants, if need synthesizing it, Move: Dave propsal A with ... removed Second: Gordon abstain: none opposed: none ** AI: Ray make the changes. Keep proposal A, get rid of the "...". Also close Manti 411. 411 was duplicate of this, ballot comment on the same issue Issue 238: using clocking blocks in modules may cause races Ray: either document it, or say that clocking blocks are evaluated first. Arturo: does this mean another region in there in the. Dave: the race is regardless of skew. Arturo: two options, another region. what would happen if a clock driven with a non-blocking assignment. you still have the race condition. Dave: precedence for having certain statements execute first, there are ordering dependencies that have been created other places. ** AI: Ray - Create a mantis item and proposal for 238. - It will be an informative note on the race. - Vote on Friday. Issue 189: (Mantis- 596) Section 16.12, Input Sampling (of clocking blocks) Arturo:The language used in this section should be cleaned up. There is the notion of blocking sampling in Vera. This was not intended for System Verilog. Motion: Arturo; Remove the first sentence of second paragraph. Second: Neil Abstain: none Oppose: none Passed ** AI: Arturo place the proposal in the svdb. Issue 240: (Mantis- ) semantics of a class is based on where it is declared. Dave: What if declare a class in a package and then extend in a program. Utility classes may exist. Arturo: would type of such objects be the same Dave: is there a rule, class in module and extended in program? Arturo: no heirarcharical typedef. if part of method in one region, virtual you can generated code for it. Disallowed heirarchical typedef. Dave: declare a class in package and extend it in program, Francoise: you create an anonymous program, and declare them there. Arturo: can not extend a class across scope, Dave: what about package to program, Arturo: that was a reason we proposed anonymous program. utility functions, call functions within a program, Dave: a class program, for mailbox, could be inside an interface, Gordon: you can not extend in two different scope, Arturo: lots of issues with it. reference to static variable, resolving refernces, arrays of multiple instantiation of modules. Gordon: type parameters, field in struct, heirarchical referencing, what is proposed very significant restriction, class derivation through interfaces. Arturo: if you pass them as type parameters, c++/others non have structural heirarchy and functional heirarchy, putting anonymous program. Gordon: a package defines class another package that extends class. some of Arturo's comments are creating big restrictions on transaction level modeling. Current LRM is very general and doesn't represent the original intent of the author (based on this discussion). Some users have come up with general forms of class extensions. What Arturo is saying would place lots of restrictions on this. type parameter is just a type which in the current LRM is very powerful. We need to ensure that we know the restrictions that exist on class extensions. Some users are expecting a much more general use model. Arturo: not mix and match, otherwise we do not know thigs are you should be able to extend, if a class in package, how do you define the behaviour, anonymous region, and second, ability to extend across scopes. far more restrictive, it is in the LRM. Dave: Big issue. This is the first discussion of this. Gordon: Must go to the P1800 group since there are far-reaching implications. ** AI: Arturo - writeup on issues for 1. region crossings 2. scope extensions - also create a mantis entry. 4) Next meeting Friday April 15th, 2005 8am-10am PST Action items: (4/12/2005) 1) AI(issue 232 Mantis 652): Dave update the svdb mantis for this item 2) AI(issue 235 Mantis 666 ): Gordon to write up the proposal in mantis with the same proposal as in the spreadsheet. 3) AI(issue 236 Mantis 642) : Ray make the changes. Keep proposal A, get rid of the "...". Also close Manti 411. (duplicate) 4) AI(issue 238 Mantis ---): Ray - Create a mantis item and proposal for 238. - It will be an informative note on the race. 5) AI(issue 189 Mantis 596): Arturo place the proposal in the svdb. 6) AI(issue 240): Arturo - writeup on issues for 1. region crossings 2. scope extensions - also create a mantis entry. =========================================== == Issues not yet resolved/voted on ======= Negative / High -----Issue # -- Mantis # ------ 233 235 666 238 240 Positive / High 281 Negative 266 (NoTES) 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 SV-BC approved the proposal in Mantis issue 632 and believes this resolves ballot issue 244. The SV-BC also believe that the SV-EC should review the issue & its resolution in case it conflicts with SV-EC requirements. the previous 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? ------------------------------------------------------ ============== SUMMARY of action items and issue items ============ == Approved issues === on April 12, 2005: Issues approved: 232 ( Mantis- 652 ) [approved on 4/12/05] 236 ( Mantis- 642 ) [approved on 4/12/05] 189 ( Mantis- 596 ) [approved on 4/12/05] 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 sent to other committees for review: 125 294 (sv-ac) (vpi question) 229 644 (sv-bc) (struct initialization) [NOTE: here is what sv-ec received on 229 from April 11th sv-bc meeting: The SV-BC reviewed the proposal to address issue 229 in its April 11th meeting. It was not approved. Here's the message that the committee agreed to convey to the EC: The SV-BC did not pass the proposed resolution to issue 229 as captured in Mantis #644. The motion failed with only abstention. Those abstaining felt that making such a change so late in the lifecycle of the LRM was not a good idea. They had concerns about issues such as: -continuous assignment to variables -initializer passed with with Type through parameters which is a new paradigm. -------------------------------------------------------------- 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. =============================================================== 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 ===================================================================================