SV-EC Committee Meeting Monday September 17 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 28 = 21 Meeting number: -------------- 0000000000000000000000000000 0000000001111111111222222222 1234567890123456789012345678 Meeting Days: ------------- (1212020201020201013112020201) Day (4815936048825059560415936067) (0000111111000000000000000000) Month (8899001122112233444566778899) (0000000000000000000000000000) Year (6666666666777777777777777777) ------ Attendees ------------ (-AAAAAAAAAAAAAAAAA-AAAA-A--A) Arturo Salz 23 (--AAA-AAAAAAA-AAAAAAAAAA--A-) Cliff Cummings 21 (AAAAAAA-AAAAAAAAAAAAAAAAAAAA) Dave Rich 27 (AA-A-AAA-AAAAAAA---AAAAAAAAA) Francoise Martinolle 22 (-AAAAAAAAAAAAAAAAAAA-AAAAAAA) Mehdi Mohtashemi 26 (AAAAAAAAAAAAAAAAAAAAAA-AAAAA) Neil Korpusik 27 (AAAAAAAAAA-AAAAAAAAAAAAAAAAA) Ray Ryan 27 (AAAAAAAAAAAA-AAA---AAA-AAAAA) Gordon Vreugdenhil 23 (AAAAAA--AAAAA-A--AAAAAAAAA-A) Steven Sharp 22 (--AAAA-A--------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A---------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AA-) Stu Sutherland 20 - No voting rights (-AAAA--AAAA-A-AAAAA-AAAA-AAA) Heath Chambers 21 (-AAAAAA-A----AAAAAAAAA--AAAA) Don Mills 20 (--AA--A---A-AAA--A-AAAA-A-A-) Jonathan Bromley 14 - No voting rights (--A-------------------------) Logie Ramachandran 01 - No voting rights (----AAA---------------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAAAAAAA) Mark Hartoog 21 (-------A-------------A------) Satia (from Intel) 02 - No voting rights (--------AAA-----------------) Rob Slater 03 - No voting rights (-------------A--------------) Alex Gran - Mentor 01 - No voting rights (---------------A-AAA-AAAAA--) Mike Mintz 09 (------------------AAAAAAAAAA) Geoffrey Coram 10 (-------------------AAAAAAAAA) David Scott - Mentor 09 (------------------------A---) Benjamin Chen - Cisco 01 - No voting rights (---------------------------A) Mike Burns - Freescale 01 - No voting rights on 9/17/2007 14 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// September 17, 2007 ///////////////////////// Note: Neil chaired the meeting. Mehdi participated as a regular voting attendee. //////////////////////////////////////////////////////////////////////// 1. Review IEEE patent policy ------------------------ ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave - Assume that the patent policy was read Second: Heath Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: -------------------------------- http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_August_20_2007_Minutes.txt http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_September_6_2007_Minutes.txt Move: Heat- accept both meeting minutes August 20th and September 6th meetings Second: Mehdi Abstain: None Opposed: None Passed 3. Review of Champions meeting/email vote results SV-EC Mantis items passed by the Champions after making friendly ammendments: ----------------------------------------------------------------------------- 1556 failed [Brad, Shalom, Stu] 1336 failed [Shalom] 1615 Shalom 1777 1556 failed [Brad, Shalom, Stu] Neil - the Mantis bug notes contain all of the Champions feedback Dave - a new proposal was uploaded, the example was split into two pieces no longer any race concerns with example ordering issues. Arturo - talked to Brad about it before the Champions vote - the change isn't necessary, people can add static if they want to - if left it out of the code - in one version of LRM it would be an error and in the other (current version) it is static (legal) Dave - how prevalent is the backward compatibility issue? - seeing lots of customers not expecting the variable to be static Arturo - he isn't seeing the complaints, it might be a methodology issue Steven - anyone using this style will run into the problems that Dave has mentioned. Mark - need to add flags to allow the old behavior. May need to leave them in forever. Steven - everyone ignores warnings. People still need to explain it to customers. Arturo - Cadence at one point argued that static wasn't useful Steven - svec removed the need for static, even though not in svec domain svbc was not notified when it was removed. - doesn't like idea of saying it is too late to change it Dave - an action item that wasn't done...??? - backward compat is not compelling enough to always disallow changes - in this case, if find a backward compatibility issue, most likely will also find a bug Gord - agreed, Steven also agreed - lots of people are still relying on the Accellera standard Dave - classes are ok, synthesizable code - not an issue either - v2k initializers in tasks, functions not allowed back then Don - Simply asking the user to state what it is, only needed when there is an initializer. - Only in procedural code. Dave - the requirement for specifying static was removed in P1800-2005. - The original text didn't explain why static was required, nor did it clearly say where required Gord - svbc thinks it shouldn't have been removed Arturo - this change is inconsistent with the rest of the language Move: Dave - approve the latest proposal for 1556 Second: Don More discussions took place before the full vote completed: Arturo - inconsistent with rest of language Gord - we aren't changing the lifetime of the variable Heath - it is a weird syntax requirement, but closes a hole on what users will commonly have a problem with. - "language clutter" - agrees that if find a backward compatibility problem it is probably a bug in the code. That makes it worth changing. Dave - parens around an assignment within expressions, is another example Steven - users expect the code flow to mimic the execution Gord - so subtle and so easy of a problem to make, it isn't worth allowing it. Steven - the code makes it look like the initialization should be re-executed for each pass around the loop. David - static sequential block Arturo - thinks it is straight-forward and don't need this change David - highly disagrees: the proposal is very detailed about the need Geoffery - apostrophe needed in "users". In the 3rd line of the paragraph. Move: Dave - approve the latest proposal for 1556 Second: Don Abstain: none Opposed: Arturo - see previous comments Mark - not serious enough issue to create bwd compat problem for Mehdi - for same reason Passed with 3 no-votes 1336 failed [Shalom] - background process spawned by functions Mehdi - Shalom will still vote no if 1615 not fixed Neil - see bug notes for 1615 for some details and the 1336 bug note Gord - likes Geoffrey's rewording (bottom of 1615 bug note) Steven - why is there an inconsistency between the two , shouldn't always blocks be allowed? Dave - always blocks are different from continuous assigns Gord - this adds new functionality, ok to not allow always blocks Steven - functions versus tasks (always blocks not one of them) - prefers initial and always both (ok with 1336) Gord - then 1615 should be updated to allow always as well? Steven - yes Arturo - do you really need the ability to continuously spawn threads? Gord - initial forever - why allow here and not in always? (was Steven's point - and Gord agrees) - allow in both places unless there is a good reason not to Arturo - we should define "originating in" - thread originated there, right? - a thread has a root Steven - includes any tasks or functions called, but doesn't include fork/joins Gord - is originating in, the same as if originating from initial or always, disable fork of initial would kill you? Ancestry issues. All active descendents of a process. Descendent of an initial or always Steven - could possibly talk about the thread itself we may not need to talk about the ancestry Created by always, initial or fork Arturo - seemed to agree with this idea, he needs to see it in writing Dave - ok with this approach as well Francoise - prefers this approach Gord - open up to always_comb, always_latch? Steven - these don't currently allow fork/join Arturo - fork/join_none are allowed Gord - more of a general issue of fork/join_none in an always-comb versus just an issue of function calls. - various always should probably permit it. Gord - ok with Steven's rewording proposal. Steven - initial, always, fork all ok. AI/Dave - update the proposals for Mantis items 1615 and 1336 (1615 was Arturo's) - send suggested rewording to Shalom for review - let Mehdi, Neil know so that we can set up an email vote - Mehdi - send source file for latest 1615 proposal to Dave 1615 Geoffery - we agreed to send it back to Champions as is. Neil - there were also a couple of friendly amendments (see bug note) 1777 Don - it was updated with the requested changes - updated on sept 6 - thinks there is nothing to do on 2041, we can close that Move: Don - move to approve latest proposal for Mantis 1777 Second: Gord Abstain: Geoffrey - (was not there when this first came up) Oppose: Passed with one abstain 2041: Don: can now be closed. Move: Gord - move to close Mantis 2041, covered by Mantis 1777 Second: Don Abstain: Oppose: Passed unanimously 4. Discussion on Merged LRM 1800-2008 Draft3 and P1800 schedule: October 1, 2007 Draft 4 with changes passed by the P1800 WG last Thursday becomes available November 15, 2007 Feature, corrections and update freeze in the SV* committees November 30ish, 2007 Champions meeting to approve final features December 13, 2007 Feature freeze in the P1800 January 15, 2008 Pre-ballot draft available February 15, 2008 Last editing corrections filed in svdb February 30ish, 2008 Champions meeting March 15, 2008 P1800 approval due March 30, 2008 Balloting begins Feedback for the Working Group on what needs to be accomplished in this draft: ------------------------------------------------------------------------------ 1897 - coverage computation 801 - queue related issues (around 8 of them) 412, 520 522, 801, 1702, 517, 518, 519, 520, 522 --- - name resolution issues Shalom has a list of related mantis items AI/Gord - send that list out 1857 - extern methods - waiting for Arturo on this one Needs to be resolved even if name resolution is not resolved :: restricted to parameterized classes <--- most important part and its extern block form of extern useful <--- less important right now Name resolution - sceptical that we will get done by November 15 A lot depends on the f2f result. 9/24 5. Review mantis items with proposals 1897 coverage computation David - was last discussed 4 weeks ago - added a bug note with a table (doesn't show well) Arturo - the new proposal seems to changed things a bit David - the report is not defined in the LRM Arturo - there was some specificity that is now missing - there is one case that there was disagreement between Arturo and David - table 18-28 change was being discussed Arturo - one was always suppose to be true (first sentence) regardless of per_instance setting. David - what does get_inst_cvg suppose to return if not gathering... - what does "tracked" mean...? Arturo - a method on a cvg object Gord - there is a valid issue here per_instance true versus false means what? Arturo - retain per_instance info or not... for the report - cvg objects are created with a constructor David - report isn't part of LRM Gord - What he thinks Arturo was saying get_inst_cvg - always valid for a cvg inst (re: Arturo) boolean - only specifies if cvg outlives cvg obj Gord - may not track some data if optimize stuff away (eg. per_instance) Arturo - Agreed with Gord's summary... if data outlives the object - may want the report of the per_instance Gord - difference between whether data outlives or exists at all - if doesn't outlive object - per_instance is false need a second flag to tell if need data to persist or not. Arturo - aggregate by union - is on per_instance is false Don't need to have instance data even in existence Gord - thinks both models are useful. believes that there are 3 reasonable ways to track info. (requires another flag) Arturo - could make it an option of aggregate by union - there could be a backward compat issue Gord - could have the new flag default to true Arturo - not happy about complexity but ok with it. Mehdi - could add to email vote 1980 dynamic_array new consistent as new operator Move: Mehdi - approve proposal for 1980 Second: Heath Abstain: Oppose: Passed unanimously [ for next meetings] 1500 Forward typedef of a class 1384 streaming operator 1608 and 1594 type matching of class handles 1715 triggered method of clocking block 1857 external method definitions and parameterized class types 1858 Name binding in inline constraints 6. Name-space resolution face-to-face meeting September 24 2007 Synopsys will host it Dave - use his dial-in number Non-voting meeting Mehdi - building 2 - a big room - by Mary Ave in Sunnyvale Long email discussions 2-pseudo proposals 7. Next meetings: Next SV-EC meeting: Monday October 1, 2007 Monday October 15, 2007