SV-EC Committee Meeting Monday October 1 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 29 = 22 Meeting number: ---------------------------- 00000000000000000000000000000 00000000011111111112222222222 12345678901234567890123456789 Meeting Days: ------------- (12120202010202010131120202010) Day (48159360488250595604159360671) (00001111110000000000000000001) Month (88990011221122334445667788990) (00000000000000000000000000000) Year (66666666667777777777777777777) ------ Attendees ------------ (-AAAAAAAAAAAAAAAAA-AAAA-A--AA) Arturo Salz 24 (--AAA-AAAAAAA-AAAAAAAAAA--A-A) Cliff Cummings 22 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAA) Dave Rich 28 (AA-A-AAA-AAAAAAA---AAAAAAAAAA) Francoise Martinolle 23 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAA) Mehdi Mohtashemi 27 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAA) Neil Korpusik 28 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAA) Ray Ryan 28 (AAAAAAAAAAAA-AAA---AAA-AAAAAA) Gordon Vreugdenhil 24 (AAAAAA--AAAAA-A--AAAAAAAAA-AA) Steven Sharp 23 (--AAAA-A---------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A----------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAA) Stu Sutherland 21 - (2 of last 3) (-AAAA--AAAA-A-AAAAA-AAAA-AAAA) Heath Chambers 22 (-AAAAAA-A----AAAAAAAAA--AAAAA) Don Mills 21 - (2 of last 3) (--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-AAAAAAAAAAAAAAA) Mark Hartoog 22 (-------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--A) Mike Mintz 10 - No voting rights (2 of last 3) (------------------AAAAAAAAAAA) Geoffrey Coram 11 - (2 of last 3) (-------------------AAAAAAAAAA) David Scott - Mentor 10 - (2 of last 3) (------------------------A----) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AA) Mike Burns - Freescale 02 (2 of last 3) on 10/1/2007 [for next meeting] 15 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// October 1, 2007 ///////////////////////// 1. Review IEEE patent policy ----------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Steven - Assume that the patent policy was read Second: Mark Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: ------------------------------------------------- http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_September_17_2007_Minutes.txt Will review the meeting minutes next meeting. 3. Review of Champions meeting/email vote results -------------------------------------------------- 3a) Mantis items which received one no-vote by champions 1928: - open another mantis item if needed. Gord - there are some valid concern about the language in the proposal Some of that is due to the particular section of the LRM. - Mostly about how things are expressed, as opposed to content - terminology for enumeration value, for example - at one level, does agree it would be good to update it. - This is a fairly narrow technical issue - Want to get the change in, there is an important technical point 1871: David - There is a legitimate issue here. - there were two proposals, the first might have been more correct - Suggested a way to fix the problem identified. Combining the first and second proposals. - This mantis item contains a crucial clarification Arturo - Needs to see it written up before being able to comment. AI: David - make the update and send it to the alias. 4. P1800 working group updates and Discussion on Merged LRM 1800-2008 Draft3 and p1800 schedule: ----------------------------------------------- 1927: SV-EC clarification of default sequence transition bin in covergroup There was a comment from Brad (Champions email vote) - should be "none ... remain" pending, not "none ... remains pending", see, for example, David - thinks it is correct, Stu agrees 1459: SV-EC Mailbox 'new' method should never return null Neil - It was left in the feedback state by mistake Mehdi - It should have been put into Resolved state. Stu - is about to send out the merged LRM draft 4 this evening. Working Group 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 5. updates: name-space resolution face-to-face ----------------------------------------------- Gord: SV-BC passed a resolution for one-month delay for schedule, sv-ac has requested 3 1/2 month delay. Neil: the set of items related to queues, number about 10 Gord: also the list issues, 1857 is still open Dave: there are also name resolution issues Move: Arutro to ask p1800 feature freeze by one month; 12/15 (feature freeze) Second: Dave Abstain: none Opposed: none passes unanimously 6. JEITA proposed questions on mantis items ------------------------------------------- Jeita - the Japanese consortium. Balloting period for P1800-2005 for SV-EC 737 - Bind for class discussion - new - sv-ec agreed to close - won't fix We have put the reason, just Update the mantis items. AI: Mehdi - update mantis database 7. Review mantis items with proposals ---------------------------------------- 1897: coverage computation David - Uploaded a new proposal. We discussed the proposal at length during the last meeting. Arturo - applies to any type? get_inst_coverage (in table) - seems to imply always applies. - Wants to nail down when it applies. (eg only if merge_instances set) AI: David - update the proposal with this one change. AI: Mehdi - send it out for an email vote. 1500: Forward typedef of a class Dave - original question was about if a forward typedef allowed for other types? Arturo - part of name resolution, and shouldn't be needed now. Dave - concerned about not getting anything done if we do all at once. Gord - this proposal prevents circularities "can't extend a forward typedef" Arturo - instead of parent --> base Mark - you can get circular definitions anyway, and this is no different. Arturo - users could include the base class definition before the extended class. Mike - having a base class where you don't know the definition doesn't seem right. Arturo - doesn't have a strong objection Neil - can't we just say that circularities are not allowed? Gord - only want to disallow when structural - the language is tough to phrase. Move: Dave, delete the last statement and approve the rewording contained in the proposal. Second: Arturo Abstain: none Opposed: none passed unanimously AI: Dave - update the proposal and also add a bugnote mentioning that the actual proposal is very different from original mantis item. 1336, 1615 Dave: 1336 and 1615, it was repeated in both places. took the wording that was in 1615 and placed it in 1336. 1336 now has everything in it Neil - 9.3.2 (See 13.4) Functions --> (See 13.4 Functions) Arturo - need to say what the error is in 13.4.4 - A violation of these conditions shall trigger an error at compile time or runtime when the conditions... AI: Dave - update it. AI: Mehdi - email vote on it 1384: streaming operator Dave: needs to be updated for draft 3a. Francoise: "internal properties" not defined anywhere Arturo - why not changing internal properties? Gord - anything not explicitly declared in a class Mike - what if there is reconvergence? (2 handles to same object) - will stream into two separate objects Gord - same object gets updated twice Arturo - this is a way to get around the strong type checking, use it with care. "the unpack operator will not update any implicit properties (such as coverage and random number information) for the target." AI: Dave - update it with new section numbers - work on sentence about reconstruction... Arturo questioned it AI: Mehdi - put up for email vote 1608: draft 3 updates Neil - bug note saying it has not been updated to draft 3a. AI: Francoise - remove the headers and footers from the proposal AI: Mehdi - add to email vote 1594: type matching of class handles AI: Mehdi - add to email vote 1715: triggered method of clocking block Arturo - thought it was a nice enhancement. Doesn't remember our discussion AI: Mehdi - add to email vote 1980 dynamic_array new consistent as new operator (voted last time) 1857 external method definitions and parameterized class types Gord - needs another round of rewrite. He needs to get input on a couple of questions that were previously asked. - c::t is only valid for disambiguation of this class It shouldn't mean two different things, one inside of parameterized classes and another otherwise. - block form of external class definition Mark - choice of keywords was the only issue on the block form Arturo - could we split this into two mantis items? Gord - block form is needed for nested parameterized classes Francoise: block form also applies to constraints? Gord - yes Gord - c::t c::g as an out of body declaration is ok c::t is only valid within the scope of a parameterized class c::t never means t within the default specialization Mark - not backward compatible Gord - agrees You end up with c::t as being ambiguous (a mess today) If c::t ever means t in the default specialization, requires a different set of rules in a parameterized class. Arturo - within definition of a method. Gord - not a good approach - extern definition and the out of body can't be cut and pasted. Mark - wants type parsed in the context of the class. Arturo - a class with no default, there is only one meaning that makes sense c::t makes sense there. Gord - defaults are required today. c::t should only be for name disambiguation Mark - this is currently one of the most confusing areas of parameterized classes for users. Gord - Allowing the name c to mean a default specialization was a big mistake. - if treat c::t as anything other than name resolution in a parameterized class - a nightmare - c::t today is ambiguous in certain cases, doesn't care which way we resolve the ambiguity, but wants clear rules for this. Francoise: it is always bad to have the same syntax to mean 2 things Mark - thinks it isn't ambiguous.... Gord - clearly not the case - the LRM says it means two things - in a parameterized class - name resolution and default parameterization Dave - right now, no way to rename a parameterized class, without specializing it. Issue if want to pull it into a package. Mark - there are 2 solutions 1. delay resolutions of identifiers until have the name of the functions (????) Gord - requires a deferred processing of whole stream 2. Gord - c::t needs to mean only one thing - (unwillingly) ok with it meaning default specialization Arturo - that would not be backward compatible. Gord - Default specialization - was there for mailbox... Mark - c:: means generic class in an extern function decl name context Gord - Arturo arguing that needs to be extended to return types, etc. Gord - backward compatibility issue depends on your interpretation of the LRM. Mark - c::t in a nested parameterized class c is enclosing class Arturo - wants to have different meanings for c::t in different usages. - c::t in context of a method declaration means name disambiguation - Mark believes there is no ambiguity today. Gord - c::t - Mark says it means the default specialization. Arturo - wants to add an explicit exception Gord - the syntax inside the class extern function c::t f() // cut and past issue Mark - best solution is to come up with an extern declaration Gord - within a parameterized class we need to clearly define this. Arturo: agrees with Gord that there is an ambiguity. Gord - ok with either solution, but we need to decide on which one... Mark - people using parameterized classes do seem to cause user problems - they get very confused. Don - they have run into lots of problems with parameterized classes Gord - there needs to be a clear solution c as a scope name or default parameterized needs to be resolved. Arturo : defining the extern blocks might get us to an agreement. Gord - concerned about nested classes in that case. - outside of a parameterized class - should only mean name disambig. - #() this syntax already exists c::t should be for scope resolution (disambiguation) // prefers Mike - why would I ever want to refer to the default parameterized class? - wants it to mean generic class (unspecialized class) Mark - why in a nested class can't specify same way as unnested? Gord - outer::t param_class::t // t in default specialization, how refer to non-default specialization - there were several small examples back in the name resolution emails. non-specialized form is the right decision // Gord - for c::t should mostly be for scope resolution // Gord - for Francoise AI: Mehdi, Neil - decide how to approach it 1858 Name binding in inline constraints 8. Next meetings: -------------------------------- Monday October 15, 2007 11:00 - 1:00pm Monday October 29, 2007 Monday November 12, 2007