Hi Arturo, It appears that you stepped out of the sv-ec meeting when we were voting on Mantis 2711. Would you be willing to let us know how you would have voted on Mantis 2711? In the email vote I understood you to be against the proposal, however while discussing it during the sv-ec conference call, I got the impression that you were for it. It would be useful for us to hear any feedback that you would like to offer at this time. Neil On 05/12/09 18:39, Mehdi Mohtashemi wrote: > Hi Neil, Brad, > I have looked at my notes again, I do have the following for the vote: > It is strange, but I think I remember that Arturo had to leave to another > meeting in the middle of the vote and then he came back, maybe that is the > reason, in any case he would have voted No/abstain, I believe. Neil, would > 6/4/3 changed the outcome? > - Mehdi > > ..... > id 107 mantis 2711 > Move: Dave > second: Gord > Abstain: Mark [not know enough], Heath, Jonathan [not competent, lead towards conservatism] > Opposed: Steven, Cliff, [passing would lead to chance no vote on the re-ballot] > Francoise: approve > Neil: approve > David: approve > Ray: approve > Don M: not present > Tom: Opposed > ref arg to covergroup problmetaic, non-automatic value, outdated refs > to automatic variables. > > YES: Dave, Gord, David, Ray, Francoise, Neil > NO: Steven, Cliff, Tom, > ABSTAIN: Mark, Heath, Jonathan 6 3A, 3O > > Mehdi: this is too close, need to check the rules later. > .... > > -----Original Message----- > From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] > Sent: Tuesday, May 12, 2009 2:48 PM > To: Brad Pierce > Cc: Mehdi Mohtashemi > Subject: Re: [sv-champions] Champions email vote - ending May 14th > > Hi Brad, > > I am showing that Arturo was in the meeting, both before and > after we voted on 2711. For some reason I am not showing him > as voting for 2711. Mehdi doesn't show Arturo in his summary > that he sent out before the conference call we had on Monday. > > > Neil > > > > On 05/12/09 11:55, Brad Pierce wrote: >> Neil, Mehdi, >> >> Arturo was not there for that vote? >> >> -- Brad >> >> ________________________________________ >> From: Neil.Korpusik@Sun.COM [Neil.Korpusik@Sun.COM] >> Sent: Tuesday, May 12, 2009 11:30 AM >> To: Brad Pierce >> Cc: sv-champions@eda.org; Mehdi Mohtashemi >> Subject: Re: [sv-champions] Champions email vote - ending May 14th >> >> Hi Brad, >> >> I believe the change in mantis 2711 is a clarification, not an enhancement. >> >> Steven Sharp was quite vocal about not wanting to approve this change. It was >> Steven that mentioned that he thought it could possibly cause a no vote on >> the re-ballot of the LRM. Cliff decided to also vote no, after he heard >> Steven mention the part about the no vote on the re-ballot. Tom didn't >> give a reason for his no vote. Tom voted no after hearing Steven and Cliff >> vote no. Tom had voted yes during the email vote. >> >> Below are some details from the email vote: >> >> >> Steven >> I will not approve any further creep in the functionality of ref args >> of covergroups, until it has been specified that the actuals to such >> arguments must be static variables. At present there is nothing to >> prevent passing an actual whose lifetime is shorter than the covergroup. >> >> Arturo >> I don't think these should be allowed. >> >> >> Here are my notes from the conference call on this topic: >> >> Arturo - the clocking event is outside the scope of the covergroup >> Steven - thinks that can be adjusted. >> - thinks we need to say ref args are statics. >> Arturo - doesn't want to make them static >> Steven - mostly concerned about automatics used in this context >> Arturo - what about dyanamic arrays? >> Steven - we get an x value in those cases. That case is more well defined. >> Arturo - we could say the behavior is undefined in that situation. >> Gord - that is a dangerous situation. >> Jonathan - the only problem is that it could mess up the covergroup. >> Steven - in theory there could also be segmentation faults. >> Dave - isn't that a separate issue? >> Steven - has no problem making the list of formals in scope. >> Dave - it is still a separate issue (a covergroup referring to >> dynamic objects) >> Steven - should have put in a ballot comment on the ref issue, and would >> like to push it here now. >> Gord - that issue already exists. Would rather clarify one. >> Steven - thinks this extends something that already has problems. >> - extending the scope of where the existing problem could exist. >> - A ref to an automatic. >> Gord - an event control adds more opportunity for the problem to exist. >> Jonathan - it is ok though, if the automatic outlives the covergroup >> Dave - this proposal doesn't address that issue. >> Gord - would oppose saying that we can only have statics. >> >> >> Neil >> >> >> >> On 05/11/09 23:16, Brad Pierce wrote: >>> Neil, >>> >>> It looks like one of the most controversial issues on this ballot is 2711, regarding ref args of covergroups. >>> >>> http://www.eda-twiki.org/svdb/view.php?id=2711 >>> >>> Could we get some more background from the SV-EC explaining this issue? It makes me nervous that not even a majority of the eligible voters at the meeting voted 'Yes' and that two of the three opposed thought "passing it could lead to a change of no vote on re-ballot". (No reason is given in Mantis for the third opposing vote.) >>> >>> The proposal justs add a sentence >>> >>> "The clocking event can be based on ref arguments of the covergroup." >>> >>> Is this an enhancement? >>> >>> -- Brad >>> >>> >>> ________________________________________ >>> From: owner-sv-champions@eda.org [owner-sv-champions@eda.org] On Behalf Of Neil Korpusik [Neil.Korpusik@Sun.COM] >>> Sent: Thursday, May 07, 2009 7:15 AM >>> To: sv-champions@eda.org >>> Subject: [sv-champions] Champions email vote - ending May 14th >>> >>> Hi Champions, >>> >>> This is a call for an email vote on the following mantis items. >>> The email vote will run for 1 week, ending on Thursday May 14th, 7am (PST). >>> We will also have a conference call the morning of May 14th, 8am (PST). >>> Any items that don't get approved in this email vote will be discussed in >>> that meeting. There will be more mantis items from the sv-bc, sv-cc and the >>> sv-ec. It is my understanding that the sv-ac has completed its work already. >>> >>> The following set of Mantis items are currently in the resolved state: >>> I will send an updated list later today that has links for those that >>> like to click on a link for each item being voted on. >>> >>> 1. 2646 Yes ___ No ___ Abstain ___ >>> SV-AC Assumption in deferred assertion example should be made explicit >>> 2. 2657 Yes ___ No ___ Abstain ___ >>> SV-AC Clarify notion of sequence >>> 3. 2648 Yes ___ No ___ Abstain ___ >>> SV-AC Need an example of cyclic dependencies between sequences >>> 4. 2649 Yes ___ No ___ Abstain ___ >>> SV-AC sequence_actual_arg is used to represent the default argument >>> 5. 2655 Yes ___ No ___ Abstain ___ >>> SV-AC Backward compatibility issue with the clocking specification >>> 6. 2644 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #153 Wrong function named in table 36.9 >>> 7. 2630 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #168 Wrong format type named in Table 38-5 >>> 8. 2653 Yes ___ No ___ Abstain ___ >>> SV-AC Sequence match not shown in timing diagram >>> 9. 2612 Yes ___ No ___ Abstain ___ >>> SV-AC `true should have a backtick in a sequence example >>> 10. 2660 Yes ___ No ___ Abstain ___ >>> SV-AC Add indices to expressions >>> 11. 2478 Yes ___ No ___ Abstain ___ >>> SV-AC Clock flow subclause is not consistent with multiclocked >>> property definition >>> 12. 2661 Yes ___ No ___ Abstain ___ >>> SV-AC "Syntax 16-19" is in blue. >>> 13. 2659 Yes ___ No ___ Abstain ___ >>> SV-AC Backward compatibility issue with sequence property >>> 14. 2541 Yes ___ No ___ Abstain ___ >>> SV-AC syntax errors - missing parenthesis >>> 15. 2516 Yes ___ No ___ Abstain ___ >>> SV-AC Another contradiction of existing text with 2398 needs to be fixed >>> 16. 2496 Yes ___ No ___ Abstain ___ >>> SV-AC non_port_program_item should contain assertion_item >>> 17. 1775 Yes ___ No ___ Abstain ___ >>> SV-CC cbAtEndOfSimTime not in header files >>> 18. 2576 Yes ___ No ___ Abstain ___ >>> SV-CC Failed to remove reference to Reader API when deprecating Data >>> Read API >>> 19. 2621 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #155 vpiSize should return an error when applied >>> on a vpiFunction returning string >>> 20. 2623 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #157 vpiArrayType is labelled bool, should be int >>> 21. 2626 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #162 In Table 38-3 in vpiScalarVal, vpi1 et al >>> should be in bold >>> 22. 2631 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #172 The usage of the the term PLI is confusing >>> 23. 2637 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #146 Term PLI is confusing >>> 24. 2628 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #164 In Arguments section, s_vpi_arrayvalue >>> should be p_vpi_arrayvalue. >>> 25. 2717 Yes ___ No ___ Abstain ___ >>> SV-AC Ballot comment #81 Clarification needed for the usage of >>> severity tasks. >>> 26. 2647 Yes ___ No ___ Abstain ___ >>> SV-AC Clarification about clock glitches in concurrent assertions >>> 27. 2656 Yes ___ No ___ Abstain ___ >>> SV-AC Clarify difference of $global_clock handling in simulation and >>> formal verification >>> 28. 2658 Yes ___ No ___ Abstain ___ >>> SV-AC Default values for untyped formals >>> 29. 2654 Yes ___ No ___ Abstain ___ >>> SV-AC Error in an example of throughout operator >>> 30. 2642 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #151 Need a similar rule for disabled >>> SystemVerilog functions in section 9.6.2 >>> 31. 2643 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #152 Section implies that a SystemVerilog >>> function cannot be disabled >>> 32. 2680 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #32: Writing to an array with an invalid index >>> 33. 2513 Yes ___ No ___ Abstain ___ >>> SV-BC BNF needs fixes to allow checkers in packages >>> 34. 2542 Yes ___ No ___ Abstain ___ >>> SV-BC Config declaration BNF bug >>> 35. 2550 Yes ___ No ___ Abstain ___ >>> SV-BC static variable initialization example has error >>> 36. 2634 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #20 Wording of paragraph implies evaluation >>> 37. 2672 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot Comment #Macro expansion example incorrect in 22.5.1 >>> 38. 2683 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #66: Example mislabelled "delay control" instead >>> of "event control" >>> 39. 2695 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #169: BNF error in edge_sensitive_path_declaration >>> 40. 2652 Yes ___ No ___ Abstain ___ >>> SV-AC Future value functions need clarification >>> 41. 2562 Yes ___ No ___ Abstain ___ >>> SV-AC rand qualifier for checker variables is not reflected in BNF >>> 42. 2650 Yes ___ No ___ Abstain ___ >>> SV-AC Ambiguity in a sequence repetition [*0] definition >>> 43. 2670 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot Comment #130: Module header description is missing the >>> package import list in 23.2.1 >>> 44. 2675 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot Comment #103: Clarification of readmem warning >>> 45. 2676 Yes ___ No ___ Abstain ___ >>> SV-BC Ballot comment #28: port connection warning >>> 46. 1492 Yes ___ No ___ Abstain ___ >>> SV-BC Overriding default lifetime of subroutine formal arguments >>> 47. 2625 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #161 There is a blue change bar at the bottom >>> of the page. >>> 48. 2622 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #156 Arrow missing in VPI Generate diagram >>> 49. 2629 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #167 Function "vpi_get64" should be >>> "vpi_get_long()" >>> 50. 2627 Yes ___ No ___ Abstain ___ >>> SV-CC Ballot comment #163 In Tables 38-3 and 38-5, for decimal >>> characters, "0-9" should be in bold, for consistency. >>> >>> >>> The following list have been resolved by the SV-ec, but the mantis items >>> have not yet been moved to the resolved state. They will be placed into >>> the resolved state today. >>> >>> 51. 2632 Yes ___ No ___ Abstain ___ >>> SV-cc id 16 approved email May 1 2009 >>> 52. 2633 Yes ___ No ___ Abstain ___ >>> SV-cc id 17 approved email May 1 2009 >>> 53. 2705 Yes ___ No ___ Abstain ___ >>> SV-ec id 35 approved email May 1 2009 >>> 54. 2700 Yes ___ No ___ Abstain ___ >>> SV-ec id 36,39,40 approved email May 1 2009 >>> 55. 2682 Yes ___ No ___ Abstain ___ >>> SV-ec id 42 approved email May 1 2009 >>> 56. 2430 Yes ___ No ___ Abstain ___ >>> SV-ec id 43 approved email May 1 2009 >>> 57. 2701 Yes ___ No ___ Abstain ___ >>> SV-ec id 44 approved, may 4 2009 meeting >>> 58. 2430 Yes ___ No ___ Abstain ___ >>> SV-ec id 45 approved email May 1 2009 >>> 59. 2706 Yes ___ No ___ Abstain ___ >>> SV-ec id 46 approved email May 1 2009 >>> 60. 2713 Yes ___ No ___ Abstain ___ >>> SV-ec id 47 approved, may 4 2009 meeting >>> 61. 2719 Yes ___ No ___ Abstain ___ >>> SV-ec id 58 approved email May 1 2009 >>> 62. 2358 Yes ___ No ___ Abstain ___ >>> SV-ec id 67 approved, may 4 2009 meeting [ with spelling correction] >>> 63. 2596 Yes ___ No ___ Abstain ___ >>> SV-ec id 80 approved email May 1 2009 >>> 64. 2710 Yes ___ No ___ Abstain ___ >>> SV-ec id 106 approved email May 1 2009 >>> 65. 2711 Yes ___ No ___ Abstain ___ >>> SV-ec id 107 approved may 4 2009, 6 Yes, 3Abstains, 3 No Votes >>> 66. 2719 Yes ___ No ___ Abstain ___ >>> SV-ec id 117 approved email May 1 2009 >>> 67. 2719 Yes ___ No ___ Abstain ___ >>> SV-ec id 118 approved email May 1 2009 >>> 68. 2719 Yes ___ No ___ Abstain ___ >>> SV-ec id 119 approved email May 1 2009 >>> 69. 2543 Yes ___ No ___ Abstain ___ >>> SV-ec id approved in may 4 2009 meeting >>> 70. 2035 Yes ___ No ___ Abstain ___ >>> SV-ec id 181 approved on may 4 2009 with 2 abstains >>> 71. 2473 Yes ___ No ___ Abstain ___ >>> SV-ec id 184 approved email May 1 2009 (no action taken) >>> >>> >>> Neil >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed May 13 18:17:23 2009
This archive was generated by hypermail 2.1.8 : Wed May 13 2009 - 18:17:24 PDT