SV-EC Ballot Resolution Committee Meeting Thursday April 21st 2005, 11:00am - 1:00pm [Minutes distributed for approval at next (sv-ec) committee meeting] (011112) Day (412581) (000000) Month (444444) (000000) Year (555555) --------- Attendees ---------- (-AAAAA) Arturo Salz (AAAAAA) Brad Pierce (AA--AA) Cliff Cummings (AAAAAA) Dave Rich (AAAAAA) Francoise Martinolle (A-----) Karen Pieper (AAAAAA) Mehdi Mohtashemi (AAAAAA) Neil Korpusik (AAAAAA) Ray Ryan (AAAAAA) Steven Sharp (AA-AAA) Surrendra Dudani (-AAAAA) Gordon Vreugdenhil (------) Bill Paulsen (----A-) 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: Arturo Second: Gordon Abstain: Opposed: 2) Review Meeting minutes, April 18th 2005 http://www.eda.org/sv-ec/Minutes/SV-EC_BallotRes_Meeting_April_18_2005_Minutes.txt Move: Dave to approve the minutes. Second: Ray Abstain: Opposed: approved 3) Miscellaneous P1800 met on Tuesday April 19, 2005: May 2 Monday Champions meeting May 5 Thursday P1800 meeting 8am to 10am May 9 Monday Champions meeting May 11 Wednesday Champions meeting May 19 Thursday P1800 meeting May 24 The draft of the LRM will be available for final review May 27 Comments on the May 24th draft are due to Stu May 31 The Balloting LRM is ready June 2 P1800 meeting to send the balloting draft back to reballot Dave was dialed in, Cliff was at the end of the call. Cliff - response to all negative votes and any changes for positive ballots - ok to be silent on positive comments that we made no changes on - for recirculation ballot - probably a good idea to put responses to all in mantis, spreadsheet to Karen. P1800 will leave some feedback out. - 229 was passed by the champions and the p1800 Next meeting times: Monday April 25th sv-bc 8:00 to 10:00 for BC, with bagles sv-ec 10:00 to 5:00 pm Also: Apr 28th, Thursday 11-1(may be longer) Cliff, Surendra - might have conflicts May 4th, Wednesday 4) Voting rights Johny sent out a clarification on voting rights within the balloting committees. Cliff will contact Johny for any further clarifications that may be required. 5) Continue the resolution of ballot issues http://www.eda.org/sv/sv-champions/P1800_Committee_Assignments_05_03_29.xls Issue 266: - "notes" - Cliff finished his first pass - Normative for some Informative for others - 2 are open - were forwarded to the svcc - svbc is reviewing their items off-line and will send input to Cliff - Gordon reviewed many of them - Surendra - only reviewed svac items so far - Dave reviewed some - API for coverage 30.2.2 - Matt is creating a mantis item for this issue * AI (Issue 266) ALL members svec - please review the items for svec (by next thursday) Issue 240 - mantis 681 We will discuss in the f2f on Monday Gordon will place his latest proposal on the mantis item Arturo plans to sent out feedback to the reflector with Synopsys feedback LEAVE for next Monday. * AI: ALL Please review and raise issues and/or other proposals before our face-to-face meeting on Monday. That will allow others to work with their internal groups. Issue 2 (Mantis 219) (fork-join and existing verilog disables) - From Steven Brad: re-entered the bug from september 2004 Steve: The "return issue" has been resolved. On 'disable' Not happy with the implication of statically by both disable and the dynamic, you have to track sub-processes AI: Arturo, to send something up to Steve. get something out on Mantis Issue 5 - Mantis 319 root thread Brad: just removed the subtree from the bug-note Francoise: do we need to define the value of the seed. Arturo: You can set the seed, and set the global root seed. Steven: there is not defined, I think 370, root thread. Arturo: we should not give it any particular number, Ray: there is an issue there in 370. Lets review issue 8 (Mantis 370) first. Issue 8 (Mantis 370) (chapter 13.13 seed/RNG) For this case, we need to look at 371 and 370 together. Move: Franciose make 371 as duplicate of 370 resolved Second: Brad abstain: opposed: Steven: all the top level threads, always block, initial blocks seed all of these by root number Arturo: we should do number, because switching the order will cause problem Ray: although if you give command-line root seeding that will provide the same value. Arturo: you can change the default value, make it 0 or whatever number Steven: still seeded with the same thing. Ray: the first thing that block can do is to seed itself. Arturo: user would know that they are doing this. If an order dependencies are there, you can do that. Ray: suggestion is to seed all top-level seeds by a default value. Arturo: we should not define the default seed. Steven: $random officially start with 0, but changes. Neil: some people do the seeding individual threads. Arturo: In Vera we did change it once, there was one real root thread, it caused alot of problem, any slight change in order created problem usability. Ray: seed for top-level threads, when does class get created if at declaration you assign new. What threads are they seeded on if not from the default value. Steven: in verilog an initializer is an initial blocks. Ray: you may need to define the seeding for those kinds same as top-level threads. Arturo: for classes each object has its own RNG is seeded from parent thread, the initializer, then what is the parent thread? Ray: if we treat them as top-lelvel threads, it avoides ordering issues. Arturo: if they are at the top-level, it depends on the context. Gordon: if new inside something that has a thread, it should take it from the parent thread. If declartion outside the context of thread then it is at global thread, generate, or package. Steven: how about static inside function or tasks. Arturo: defined in terms of instances not declaration. sync each scope to a random number that statics can get their seeds from Ray: what is the order of initial block, Steven: they all start with the default seed. Surrendra: how about parent thread, any thread that does not have parent thread. Ray: the initial block is seeded by the default, statically declared one will be seeded with the first seed by initial block that is different. Arturo: you use the scope for static objects, static declaration. Steven: if static at module level, and static inside tasks, they would act in different thread. Arturo: they would act as if they are in the scope. static initializers would get their seed from. Ray: it has to be normative * AI: Ray to place the proposal into Mantis for 370. Need to be normative for both 319 and 370. Now back to 319: Steven: we would have to say top-level Francoise: do we define any where the root thread of sub-system. Steven: do we have text in the LRM that defines root-thread. Ray: there is only root-thread of sub-system. it could be any sub-sub-system, Steven: it is root setting of RNG for thread. Ray: the thread and all its children will be sub-system. Arturo: for each object there is a root thread. LEAVE Monday or next Thursday. Issue 188 - Mantis 595 Brad: updated the BNF which allows an example in the LRM to be legal. Section 16.4, bottom of p 194. a "net l_value or variable l_value" might be correct. Adding a semantic restriction to this may be enough. Gordon: page 194, 16.4, it does say, Surrendra: the contatenation will be problem, we can remove it, it is an aliasing it is not assignment, Arturo: it is a way to change the name of a clocking block, Brad: do you think it should be concatenation. Surrendra: constant expression does not make any sense. Steven: is it same restriction that lvalue have, Brad: you want variable lvalues there, everything that can be in the LHS of assignment. Gordon: of actual of port association, sufficinetly constant. Arturo: changing the BNF or wording. Gordon - the description appears to be too restrictive based on the goal - is it everything allowed in an actual of a port instantiation(?) - Need to check 1364 to get the correct wording - can we specify variables? (Surendra says yes). - a concatenation used here must be legal for an output of a port association. (Brad - that would be "expression"). - variable l_value is too permissive - 12.3.4 in 1364 - uses fairly loose language for ports Steven - source side of a port (not the sink side). - it must be a static item Ray - can constants be part of the concatenation. Summary: Use port language to describe this situation since it is similar to what is allowed for the actual for a port connection (ie for the RHS of the clocking block signal). Port formal on the left and port actual on the RHS. * AI Brad - write it up the proposal and place in mantis (normative). LEAVE it for vote next week. Issue 7 (Mantis 344) (anonymous program) Francoise: why ; at end, Brad: because we have packages, function or tasks. Steve - this will get us back to 240 (class semantic issue). Dave - this will most likely be closed as part of 240. Decision - we will discuss it Monday along with 240. Issue 36 (Mantis 270) (enhancement randomize) Mehdi - randomize_display() for getting more input for the failure. Francoise - when randomize methods fail we don't know what happened. Arturo - "implementations may issue warnings" there is no need to add keyword for doing this. "The committe read and considered this feedback. While it has merit, the committee believes it is not feasible to implement at this time." Move: to postpone this using the boiler-plate language - NeilNeil Second: Gordon Abstain: Opposed Issue 162 (Mantis 552) coverage bnf update Move: Brad close as no bug. resovled Second: Ray abstain: opposed: approved Issue 199 (Mantis 607) accessing values in clocking block It appears that 16.12 and 16.14 already cover this. Francoise: in vpi would allow the same thing that is allowed in verilog Steven: it covers both, write and read an output port. Neil: it uses the positive language. Gordon: i am not sure if he is thinking with an input port, Steven: if things are explicitly written or read, if implicitly then no way to use it. Francoise: an input or an output, i am not sure it has acces as a value. Arturo: you can force anything in the language. persumablely a register, Franciose: if there is no way to do it in Verilog, we should not allow it to VPI to changes. * AI: for Mehdi to send charles email for clarification on this issue. next week. Issue 233, Mantis 317 bit-streaming of class Arturo: add at the end of this. Dave: what about class extensio. Arturo: it is there, they shall follow the items of their super class. Ray: Like structs, if a class has non-streaming members it is not bit-stream it Neil: for null handle. Dave: What happens at the top-level. Ray: Does the struct recursion talk about this. LEAVE it for Monday for approval. * AI: ALL review the proposal on svdb for vote next week. Mantis 411 duplicate of 642 (default argument) Move: Brad mark as duplicate as 642 Second: Gordon Abstain: Opposed 411 duplicate Issue 10 (Mantis 409) (ref arguments, Mehdi: thought this was taken care of by 236 Steven: depends on interpretaion. restriction: you can not have non-blocking precdrual assignment to port ref, the other side may be automatic. Arturo: would it not be easier to say refs considered as automatic, Steven: right now ref formals are automatic. Gordon: target automatic ref shall be considered automatic independent of the actual. Steven: if forbid automatic refs where you forbid automatic it will resolve it. if static variable. Dave: the issue with refs is ensuring all of the event controls work. Gordon: are you allowed to wait on an automatic? Arturo: yes, Steven: originally in 3.0 was disallowed, it got changed in 3.1 Gordon: simple statement here, goes in paragraph 11.4.2 page 117, second full paragraph Steven: in restriction where ref formals In 11.4.2 "Using an automatic ref is disallowed wherever an automatic would be illegal." ---> "Any variables passed by ref are automatics." <---- * AI Steven - add this language. Vote on it Monday. 6) Next meetings A) face-to-face: April 25 2005 10:00am-5:00pm B) Possible time slot for Thursday April 28th, 2005 11:00 am - 3:00 pm ======================================================================================== Action items: (4/21/2005): 1) AI(issue 266,): ALL review the latest updates from Cliff, comments 2) AI(issue 240, Mantis 681) Please review and raise issues and/or other proposals before our face-to-face meeting on Monday. 3) AI(issue 2, Mantis 219): Arturo to send write-up to Steve for completion 4) AI(issue 5, Mantis 319): Ray to place the proposal on svdb 5) AI(issue 8, Mantis 370): Ray to place the proposal on svdb 6) AI(issue 188, Mantis 595): Brad to place the proposal on svdb 7) AI(issue 199, Mantis 607): Mehdi to request clarifications from Charles 8) AI(issue 10, Mantis 409): Steven to place proposal to the svdb. =========================================== == Issues not yet resolved/voted on ======= Issue # Mantis # 240 681 semantics of class [We can postpone this till 7 344 combined with 240 233 317 266 Notes issues (from Cliff) 2 219 (disable/fork-join item) 5 319 (root thread) 8 370 ( chap 13.13 seed/RNG) 10 409 (ref arguments, should be taken care of with item 236 188 595 (invalid example clocking block assignment -- proposal) 22 514 ( type for mailbox ) 13 412 23 517 24 520 30 549 41 551 32 553 94 511 ( type assignments) 95 512 (object copying) 96 516 (type compatibility description) 97 518 ( queues, arrays, page 51) 98 519 ( empty array 99 521 ( queues, pattern assignment) 100 522 ( queues concatenation) 101 523 ( queue return type) 122 251 (enhancement -- coverage) 123 253 ( coverage) 171 564 (cross program references) 187 594 ( interface access through clocking block) 190 597 (unnamed clocking blocks in bnf) 199 607 (accessing values in clocking block) 200 608 (clocking block value resolution) 201 609 (##cycle meaning in 16.14 ===================================================================== ============== SUMMARY of action items and issue items ============ == Approved and resolved issues === on April 21, 2005: 36 ( Mantis 270 ) [has merit but not feasilbe at this time] 162 (Mantis 552 ) [Closed as no-bug] on April 18, 2005: 283 ( Mantis 615 and 662 ) [approved on 4/18/05] 1 ( Mantis 93 ) [approved on 4/18/05] 281 ( Mantis 683 ) [approved on 4/18/05] 238 ( Mantis 671 ) [approved on 4/18/05] on April 15, 2005: 235 ( Mantis- 666) [approved on 4/15/05] 236 ( Mantis- 642) [approved on 4/15/05] 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/18/2005): 1) AI(issue 1, Mantis 93): Brad to write up a proposal for description 2) AI(issue 281, Mantis 683): Brad update the proposal in the correct format in svdb 3) AI(issue 2 - Mantis 219): Steven: writeup to cover the common cases. 4) AI(issue 233 ): Arturo write up the rules, Based on what is missing in definition. create a new mantis, place in svdb 3) AI(issue 240 - 681 ): Gordon: write up a straw-man proposal on this concept of virtual classes send it to sv-ec for review Action items: (4/15/2005): 1) AI(issue 233 ): Arturo write up the rules, Based on what is missing in definition. create a new mantis, place in svdb 2) AI(issue 238 - Mantis 671): Dave and Ray for new words on this, place in mantis. 3) AI(issue 240 - ): Gordon/Dave to send email reflector, to get closer to consensus 4) AI(issue 1 - Mantis 93): Brad to write up detailed proposal. 5) AI(issue 244 -Mantis 632 ): Mehdi to report it back to sv-bc. 6) AI(issue 229 - Mantis 644): Mehdi to send it to Champions for their final decision 7) AI(issue 283 - Mantis 615): Dave writeup a new addendum for the section on arrays to clarify. 8) AI(issue 281 - ): Surrendra, create a new mantis, create a proposal and place in svdb. 9) AI(issue 2 - Mantis 219): Steven: writeup to cover the common cases. 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. ---------------------------------------------- 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 ===================================================================================