SV-EC Committee Meeting Monday March 17 2008 11:00am - 1:00pm PST [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_March_17_2008_Minutes.txt ] With the new calculations for voting rights below ... 3/4 rule = 0.75 * 39 = 29.25 Meeting number: ------------------------------------------------ 00000000000000000000000000000000000000000 00000000011111111112222222222333333333333 12345678901234567890123456789012334456789 Meeting Days: ------------------------------------------------ (12120202010202010131120202010121201102001) Day (48159360488250595604159360671592630772437) (00001111110000000000000000001111111100000) Month (88990011221122334445667788990001122211233) (00000000000000000000000000000000000000000) Year (66666666667777777777777777777777777788888) ------ Attendees ---------------------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAAA*AA*AAAAA) Arturo Salz 34 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-AAA*A*AAAAA) Cliff Cummings 31 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAAAA*A*AAAAA) Dave Rich 38 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAAAA*A*AAAAA) Francoise Martinolle 33 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-AA*A*AAAAA) Mehdi Mohtashemi 36 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAA*A*AAAAA) Neil Korpusik 38 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA*A*AAAA-) Ray Ryan 37 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAAAA*A*A-AAA) Gordon Vreugdenhil 33 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAAAA**AAAAAA) Steven Sharp 33 (--AAAA-A-------------------------*-*-----) Phil Moorby 05 - Non-voting (---AA-AAA-AAAA-AA-A--------------*-*-----) Doug Warmke 12 - Non-voting (AAAAAAA---AA-A-AAAAAAA---AAAAAAAA**AA--AA) Stu Sutherland 29 (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAAAA*A*-AAAA) Heath Chambers 31 (-AAAAAA-A----AAAAAAAAA--AAAAAAA-A*A*AAAAA) Don Mills 30 (--AA--A---A-AAA--A-AAAA-A-A--A--A*-*AA--A) Jonathan Bromley 19 - Non-voting (--A------------------------------*-*-----) Logie Ramachandran 01 - Non-voting (----AAA--------------------------*-*-----) Melvin Cardoza 03 - Non-votings (-----A-AAAAAA-AAAAAAAAAAAAAAAAAAA*A*AAAAA) Mark Hartoog 32 (-------A-------------A-----------*-*-----) Satia (from Intel) 02 - Non-voting (--------AAA----------------------*-*-----) Rob Slater 03 - Non-votings (-------------A-------------------*-*-----) Alex Gran - Mentor 01 - Non-voting (---------------A-AAA-AAAAA--A-AA-*A*A----) Mike Mintz 14 - (2 of last 3) (------------------AAAAAAAAAAAA-A-*-*-----) Geoffrey Coram 13 - Non-voting (-------------------AAAAAAAAAA-AAA*A*AAAAA) David Scott - Mentor 19 - (2 of last 3) (------------------------A--------*-*-----) Benjamin Chen - Cisco 01 - Non-votings (---------------------------AAAAAA*A*-AA-A) Mike Burns - Freescale 10 (2 of last 3) (----------------------------------*A-----) Harry King - Cisco 01 - Non-voting (--------------------------------------A--) Karen Pieper 01 - non-voting on March/17/2008 [for next meeting] 14 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// March 17, 2008 ///////////////////////// Agenda: ------- 1. Review IEEE patent policy ------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Cliff - Assume that the patent policy was read Second: Heath Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: ------------------------------------------------- Previous meeting: March 3 2008, http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_March_3_2008_Minutes.txt Move: Heath Second: David Abstain: Mike Burns (was not at that meeting) Opposed: None Approved 3. Updates from p1800WG -------------------------------------------------- Next meeting on Thursday 27th. Nothing from the champions call of March 13 for sv-ec. Stu - we are still quite a bit aways from having another intermediate draft. 4. Immediate issues to review ----------------------------------------------------------- a) Review/discuss Checkers, and mantis items 2088,2089 [Review meeting held by Dimitry at Intel] http://www.eda.org/svdb/view.php?id=2088 http://www.eda.org/svdb/view.php?id=2089 Mark: Dimitry emailed slides, covered the rational behind the new proposal. Cliff: Steven and Gord were not there. Dave: mostly about motivation, and history. Gord: what concerns me, uncomfortable what we are doing to the language. ok with the motivation. - For several of the issues he raised, the answer was something like: Let's add a new rule for that case, or not yet defined. - Steven has raised issues with loops. There are all sorts of interactions where the rules are not clear. - Concerned about how all of this will play together as the language development progresses. - Doesn't know the cost of adding all of this to the language. Dave - Dmitry presses the point that Gord was ok with a lot of the changes at one point. As long as these features are only in the assertion area. They are now creating a separate language inside checkers. Looping makes it no longer a separate construct. Gord - freevars - hierarchical references, covergroups are still open issues or under-defined. Cliff - has a certain level of discomfort - the amount of material, what he is hearing from vendors. Stu - listened in - tough to hear Dmitry at the white board There were lots of tough questions. There were dozens if not hundreds of open questions. Cliff - not hearing confidence from others. Wants to have a larger group sit down and hash things out. Stu - the LRM is already into 2009 - doesn't care if January or later. We should take the time to get this right. Cliff - thinking of pushing it off. Stu - yes, now 2009 (if goes to a second ballot). Dave - there is a lot of stuff piling up, need to kick out the next standard. - The merge defocused our effort. - The svac work should not have been isolated. Jonathan - svac not used to using an integrated language - For formal, think in a different way than a simulator. Gord - that has made him uncomfortable as well - the way they describe things. Jonathan - they know very specifically what they are specifying. - Trying to join their stuff with the simulation semantics isn't easy. Steven - the LRM is in terms of simulation semantics. - formal tools need to extract information. When define new constructs they are doing it in terms of formal (to make things easier for them). Dave - freevars, etc. are separate issues from checkers. - initial check and always check - might be a misunderstanding of scheduling semantics - inferring a clock instead of making it level sensitive. Cliff - not sure that the proposals don't have technical merit, but hearing a lot of concerns. Steven - the meeting was useful for getting the discussion started. Steven - concurrent assertions in procedural code - didn't know it was already in the 2005 lrm. Expects serious problems. Saying there was precedence and approved doesn't mean that there aren't problems. Gord - the level of concern has been ratcheting up over the past month. At which level will a decision be made? With the time constraints - need the WG to be involved. Not letting it in will most likely also be a problem. Cliff - passing these will reduce consensus. Wants to defer. Mehdi - wanted to know if there were any svec specific issues. Jonathan - 2088 - is it legal to cover a freevar? Gord - not disallowed by the current proposal. That was the answer. Steven - simulation semantics of a freevar are not well defined. - Best semantic today is that the simulator picks a value. - That sounds like constrained randomization. Maybe it should have been that way and then formal should have extracted it. Jonathan - can't really ascribe a meaning to coverage of freevar. Gord - now sure how long it would take to resolve the open issues. - if basic structures can't change - and just patch - that would be a more narrow discussion. - not sure what would result in a more global discussion. Not sure what it would look like. He isn't an expert in formal. - It could be several months. Jonathan - 2088 and 2089 are just the trimmings around the edges. Heath - doesn't think we can hold off on the standard for this. Gord - if it goes to vote as is, doesn't want to accept due to the flaws he sees. Much better off if can find a middle ground. Understands the need to want checkers. Cliff - bc, ec, ac - need people from all three committees to address it. Steven - the issues that Gord has raised earlier are serious. More people are now seeing those issues. Cliff - agrees - 4-6 months Dave - ~6 month Steven - says there are too many variables to estimate... Gord - what gets brought to the table the first time. - if not open to a lot of change - will be tough to deal with. - we understand it is important, need to stick to the sim semantics. - if allowed to go back to the drawing board, with everyone we may see something useful fall out. - there is a lot of inertia to overcome in how people think about things. Mark - concurrent assertions in procedural code - exists today. If want to take it out - big backward compatibility issue. Gord - need to discuss all of this more generally - not just a very narrow focus on specific proposals. Arturo - we need to be constrained by the technical issues. - those that can't be resolved in a timely manner may be pushed out. Steven - do we have a set of people that know both sides? - need to have someone with a higher view that can take another view Cliff - would like to have Harry Foster involved. Mark - assertions look weird for people used to RTL. Steven - not consistent in other areas. Mark - wildcard package imports - we are still trying to figure this out the corner cases. Steven - run into issues with that since others have implemented another way Dave - just like "randomize with" Steven - He has been trying to make the case that continuous assigns in procedural code isn't really in the 2005 LRM. Gord - need the ability to reason about these features and future changes. - Binding of checkers into other places is a big concern. - maybe introducing incompatibilities is best in short term, versus having ad hoc language design. Stu - there will be a very limited number of companies eligible to vote on the LRM. Make sure talk to your DR if you have concerns. Summary of main areas of concerns - Concurrent assertions in procedural code - partially in 2005 - keywords - freevars, continuous assign in checkers. Move: Arturo - re-do the motion from last meeting and approve proposals for 2088 and 2089 Second: Steven Abstain: Neil, David Scott, Mark- doesn't know enough about covergroups - taking it out may also reduce consensus. Prefers to spend time to reach consensus Opposed: Steven - same reason as last time - the concerns are getting deeper. Concern that it will reduce consensus during balloting. Cliff Dave Francoise Gord Stu Heath Don Mike In favor: Arturo Motion failed: 1 yes, 3 abstain, 9 no. b) additional mantis items (permission granted by p1800WG) 1897, 2242, and 2243 http://www.eda.org/svdb/view.php?id=1897 http://www.eda.org/svdb/view.php?id=2242 http://www.eda.org/svdb/view.php?id=2243 David: re-wrote both of them, 2243: Move: David - to approve the proposal for 2243 Second: Arturo Abstain: Opposed: passes unanimously 2242: David: get_coverage and get_inst_covereage with optional arguments to get_coverage() Cliff - didn't realize you could call these on coverpoints. Arturo - might want to just say "for example..." David - get_coverage on multiple instances. Need to count n_bin for all instances. - could spell it out or add one example Heath - would like to see an example. David - will do another update... Thinks he knows what is needed. will be ready for next week's meeting. AI: update the proposal for next week to vote on this. c) from champions feedback. 2183 -- in feedback state Arturo: did agree on semantics rule. Brad and Stu's note. Francoise: We had a discussion on this last time. Neil: Ray had the action item for this one. AI: Ray - the proposal needs to be updated. 2279 -- in feedback state Neil: feeback from 1858 came up with the new 2279 to not affect the 1858. The Tech.Committee may want to adress this problem. Mehdi: will look for volunteer for this. AI: Jonathan, will take a look at 2279. Mantis items 2302 and 2303 contain Champions feedback. The feedback is from reviewing Mantis item 1447. [ The following feedback came from Shalom in the Champions email vote which ended Feb 23, 2008. The feedback was for Mantis item 1447. The Champions decided to create a new mantis item for addressing this issue (during the Feb 25, 2008 conference call). I think there is a contradiction between the following two statements that should be resolved: In 7.4.2: "If an unpacked array has one or more dynamic, associative, or queued dimensions, it is considered a variable-size array." In 7.5: "integer mem[2][]; // Fixed-size unpacked array composed of 2 dynamic subarrays of integers" ] Mike: 2302 essentially about some terminology. - related to terminology. - the point of 1447 was to straighten up the terminology - prefers to not change it based on this feedback. - prefers not to define enclosing array based on what it contains. - Shalom had an issue with bitstream casting or something.... Not sure what the actual passage was. - prefers to get rid of that term "variable-size array" Jonathan - thinks the stream concatination issue has gone away. - 1707 is now compatible with idea of no longer having multi-dimensional arrays. - 13.5.2 outdating references - it uses variable size arrays. Francoise: is it used any where else? Neil: in the email thread, references to fixed-size array, Mike - there is a section that discusses fixed sized arrays. - willing to make a change. 2303: [ from feedback: What is the definition of 'compatible'? Is it the same thing as "assignment compatible"? If so, this should either say "assignment compatible" instead of "compatible", or we should get rid of the "assignment" in "assignment compatible". ] Mike: question is to tell which one, assignement compatible or does it mean matching? intent is to refer to one, matching type, equivalent type, difference between assignment compatible does it requirea cast. Gord: the exact number of elements in question. Mike: that is equivalency, then if they are assignment compatible they are to be decided at the time. Gord: in order to be assignment compatible they must be equivalent for unpacked arrays. for dynamic arrays then equivalent is not a requirement. Jonathan: it maybe harder than that Gord: at least one ref in 1447, compatible is talking about element type of an array rather than the whole . an array is not equivalent because it has an element type compatible. Francoise: assignement compatiblity rues are different? where are they specified. Dave: assignemnet compatible means the implicit cast is there. Steven: assignemetn compatible rules do not say anything special Francoise: if this is an implicit casting rule, then we should specify. Gord: in 14.7.6, this actually claims fixed size arrays are assignment compatible. second point there specifies it. element type: just assignement compatiblity. Francoise: section 6 of type equivalence does not indicate it. chapter 6 they have to have it. Mike: implicit casting rules should be indicative. Jonathan: as a user it is counter-intuitive to me. Gord: need to get the array assigment rules that they can be covered. 5. Next meetings in 2008 ---------------------- March 25th (Tuesday) 9:30 - 11:00 Thursday March 27 - Working Group meeting