SV-EC Committee Meeting Monday October 15 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 30 = 22 Meeting number: --------------------------------- 000000000000000000000000000000 000000000111111111122222222223 123456789012345678901234567890 Meeting Days: --------------------------------- (121202020102020101311202020101) Day (481593604882505956041593606715) (000011111100000000000000000011) Month (889900112211223344456677889900) (000000000000000000000000000000) Year (666666666677777777777777777777) ------ Attendees ---------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAA) Arturo Salz 25 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-) Cliff Cummings 22 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAA) Dave Rich 29 (AA-A-AAA-AAAAAAA---AAAAAAAAAAA) Francoise Martinolle 24 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA) Mehdi Mohtashemi 28 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAA) Neil Korpusik 29 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAA) Ray Ryan 29 (AAAAAAAAAAAA-AAA---AAA-AAAAAAA) Gordon Vreugdenhil 25 (AAAAAA--AAAAA-A--AAAAAAAAA-AAA) Steven Sharp 24 (--AAAA-A----------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A-----------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAAA) Stu Sutherland 22 - (2 of last 3) (-AAAA--AAAA-A-AAAAA-AAAA-AAAAA) Heath Chambers 23 (-AAAAAA-A----AAAAAAAAA--AAAAAA) Don Mills 22 - (2 of last 3) (--AA--A---A-AAA--A-AAAA-A-A--A) Jonathan Bromley 15 - No voting rights (--A---------------------------) Logie Ramachandran 01 - No voting rights (----AAA-----------------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAAAAAAAAA) Mark Hartoog 23 (-------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 (------------------AAAAAAAAAAAA) Geoffrey Coram 12 - (2 of last 3) (-------------------AAAAAAAAAA-) David Scott - Mentor 10 - (2 of last 3) (------------------------A-----) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AAA) Mike Burns - Freescale 02 (2 of last 3) on 10/15/2007 [for next meeting] 14 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// October 15, 2007 ///////////////////////// Note: a couple of people got a busy signal when they dialed in. Eventually they were able to get on the call after making several attempts. 1. Review IEEE patent policy ----------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Gord - 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 Move: Gord - October 1st minutes approve Second: Neil Abstain: None Opposed: None Passed unanimously http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_October_1_2007_Minutes.txt Move: Gord - October 1st minutes approve, with Gord's update Second: Heath Abstain: None Opposed: None Passed unanimously 3. P1800 working group, schedule updates and discussion --------------------------------------------------------- a) version D4 of LRM is available b) New schedule from p1800 meeting (October 4 2007) Neil: extension was varied. BC, EC, after one month, they are allowed to work on issues on merge, editor, champion's issues. AC: got 3 months, EC has until December 15th, leaves 2.5 month for editorial Francoise: it should have been a consistent schedule, Gord: it is not Neil: you can contact your DR, working group meeting on Nov 15th schedule should be discussed. Champions' was this thursday but may postpone. Need a conf. call for items. Any mantis that will be worked the original feature freeze should be entered by Nov 12 2005. Dec 15 2005: no more mantis update. 11/12/2007 all committees must open active Mantis items that they are going to complete for this release. They may not work on any item not on in this list. 12/15/2007 SV-BC and SV-EC must complete all items from their Mantis list. Past this date they are only authorized to work on merge, editing and champions issues. NEED TO FINALIZE SV_EC list by end of October 15 2007. The current svec list for remaining time allotted: 412 5.14.1 Queue operator examples use aggregate constructors incorrectly 522 use of concatenation in 5.14.2 (Francoise) 521 pattern assignment for queues (Francoise) 520 example of queues assignment (Francoise) 519 section 5.14,empty array literal syntax (Francoise) 518 queues and arrays (Francoise) 517 concatenation syntax usage section 5.14 (Francoise) 516 5.7 and 5.8 description of type compatible arrays 1702 queue syntax issues 958 dynamic array size method unclear when empty 974 comparison of dynamic arrays/queues to 1-dimensional fixed arrays 1447 Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 and 5.8) 801 Errors in assignment pattern in 5.4 example 1516 arguments to randomize calls [related to name space resolution] 1608 1594 relational ops on class handles 1584 defaults in virtual methods 1256 linked list description 1714 singular type as the mailbox default 1857 external method definitions and parameterized class type 2035 class methods with static lifetime) 2080 "::" is ambiguous in parameterized classes 2087 Semantic intent of qualified BNF terminals must be clarified 4. Review October 10 2007 email vote results ------------------------------------------------- PASSED: 339, 1384, 1615, 1679, 1871, 1897, 1928, 2007. DID NOT PASS: 1336, 1560, 1594, 1608, 1715. 1336 Neil - the requested changes were already made Cliff - non-blocking assignments in a final block now allowed? Gord - Cliff's issue with final block. certain things allowed in a function are now dependent upon where a function is called. Arturo - could leave it there, but it won't fire. Steven - might be best if the final block lists what is allowed instead of relying on the text for functions. Move: Dave Approve the latest proposal for mantis 1336 Second: Arturo Abstain: None Opposed: Stu this does change the rule for final blocks and it does not address that issue. It makes NBA and other scheduled future ones legal in final block. Would change the vote to yes if there is mantis item opened for final block. Objection has been discussed. Maybe better to have final block indicates what is valid/legal in final block. Semantics is all what you need. To be added to the list by 12/15 Passed with one No vote. 14 Yes vote 1560 Neil: voted no, all of queue method used prototype, only this one has syntax. Gord: the word prototype is not appropriate, if syntax is not acceptable. Arturo: the default index for queue would work. Steven: adding in the [] means it isn't a prototype. Stu : do we have to specify int for every call? Steven : it was copied from associative array text Gord: we should fix both places if there is an issue. Arturo: the syntax with invalid argument will not work. Move: Gord - Approve the latest proposal for mantis 1560 Second: Steven Abstain: None Opposed: None Passed unanimously 1594 Neil: just typos, Geoffry's Move: Geoffrey - Approve the latest proposal for mantis 1594 with the two friendly amendments from Neil. Second: Gord Abstain: None Opposed: None Passed unanimously 1608: Neil: sentence is awkward, Steven - could use whose (all agreed) Geoffrey - one other friendly amendment (see Mehdi email) Move: Gord - Approve the latest proposal for mantis 1608, with the two friendly amendments Second: Geoffrey Abstain: Opposed: None Passed unanimously 1715: Neil: part of should be in the text, Jonathan: it is not important, is easier to pull it, LEAVE IT OPEN FOR FUTURE. NO need to vote on this. 5. SV-AC request for feedback on 1648. ------------------------------------------- http://www.eda.org/svdb/view.php?id=1648 [introduces a default disable] The sv-ac has solicited input from the other committees on Mantis item 1648. So far, no feedback has been sent back to the sv-ac. The Working Group discussed this at the meeting held on Oct 4th. P1800 has decided to set a deadline for providing feedback. Please discuss this in your next conference call and send input to the sv-ac by October 24th. Neil: concept of a default disable. Champions requested to get comments from other committees. If this is being added by assertion group the other committees should give input. Dave: thought that this might be useful for covergroups Arturo - the concept of a disable iff was already there in assertions Francoise - it was discussed in the svcc - didn't understand why the expression could be a distribution. Arturo - It then becomes an assume for that case Jonathan - svec doesn't have anything similar. Assertions are long-running Dave - there are on covergroup Jonathan - our situation is more like always_ff - no thread for a cover point that is disabled. - a qualification to say if sample happens or not - for assertions it turns off running assertions. Proposed response from svec to the svac: The svec would like to work on this during the post 12/15 time frame. (just the default disable portion of the proposal). AI: Mehdi, send it to AC, copy the working group. December 15th. 6. Review mantis items with proposals ----------------------------------------- 1857 external method definitions and parameterized class types 1858 Name binding in inline constraints 1851 2021 Relax excessively severe restriction on what can connect to a clocking inout 2055 coverage bin distribution is not even 2087 Semantic intent of qualified BNF terminals must be clarified 2087: 2087 Semantic intent of qualified BNF terminals must be clarified Gord - wants to add this item to prevent misinterpretation of the BNF in the future. Mark was doing a narrow interpretation of the BNF in the name resolution email thread. Mark - there is no place in the LRM where this is addressed. class_identifier in bnf can include a type parameter. Thinks that this is a ludicrous argument. No one thought about this when the LRM was written. Arturo - agreed with this last point Mark - thinks the LRM does not allow it. Arturo - agrees with Gord on the BNF point - agrees with Mark that this is not well thought out. Gord - there are a lot of parallels in the rest of the language. Mark - thinks there are a lot of issues. Mike B. - just because ramifications weren't thought out doesn't mean it isn't allowed. - we have a cross between two features here. Arturo - aware of at least one issue in this area. Gord - it is already part of an implementation and a practice. Mark - just because implemented doesn't mean it is legal Francoise - is it a useful enhancement? Mark - would only want to work on it if we get same extension as ac. Gord - this has been discussed for almost 3 years. Francoise - at the f2f no one was saying it was illegal Arturo - specific problems with type parameters used as base classes Mark - base class of a type is described as a class_identifier Ray - bnf describes the syntax. Dave - can't new a class if pass it as a type parameter? Used to define a container class then try to new it? This also uses class_identifier, so can't say illegal. Mark - Gord is making his argument based on the BNF. Ray - original authors did not understand all issues when wrote LRM. Mark - 1 month extension is not enough time to finish this. Mark - claims that Gord did not give a full proposal. Francoise - at f2f - do users want to extend from opaque types. - why are we now saying not enough time. Mark - there are a bunch of other name resolution issues that have nothing to do with classes. Francoise - Gord to work on a proposal for the other issues. Mike, Gord - both agree with this summary. Gord - can't do everything but we need to get consistent behavior. - There are a lot of issues in 2005 LRM, we need to make some progress in this area. Mark - type parameters used with :: operator. LRM mentions what is allowed on LHS, doesn't mention type parameters. Thinks it is clear that LRM doesn't allow what Gord wants. Gord - Let's get bnf point off the table. We need to get specifics from Arturo on what are the issues. Arturo - willing to have the technical issues. Mark - severely opposed to 2087, will make LRM more obscure Neil - doesn't see anything controversial in the proposal. Gord - things like type in type contexts (typedef, type parameters) are equivalent to types. - typedef of a class is not the same as a class name would be a big issue. Mike - we don't list all of the allowed crossed features of the language. Mark - add clear language about type parameter to the language Arturo - we need to resolve the technical issues. Gord - can rename the description of the proposal. not parameterized types. Move: Neil moves that we approve proposal 2 for 2087 (2087_prop2) Second: Gord Abstain: none Opposed: none Passed Unanimously AI: we need a proposal for typedef passed through a port and used to extend a class. Dave - if not resolved in 1 month this will most likely become a ballot issue. Francoise, Neil - we want to know what all of the issues are... AI: Arturo - write up a list of what all the issues are. Mark - name resolution can be done with existing language. Arturo - there are compromise solutions. Mark - he still hasn't seen Gord's whole proposal. Gord - some of the longer term things don't need to be done by 2008. - the only fairly deep issue is the recognition of types Arturo - thats the Mentor issue, there are other issues. - Mark wants specific verbiage to allow the one case Mark - the type operator can be used in some places to work around it. Gord - we need to determine the direction first Arturo - agrees that we need to write down all of the issues. Mark - sent out his proposal a long time ago - claims to have not seen exactly what Gord proposed. Gord - put together a proposal quite some time ago. Now willing to back off a bit from that original proposal. Arturo - that is inconsistent with the way that parameters work today. Gord - Mark's dynamic rules are implementable but they are bad rules. Neil - prefers the more static approach Mike - his users seemed to not really care. - they will not use "bare names", will use coding rules and linting - they would expect to bind into the opaque type first. If you have names that conflict, don't do that. "You know what you are expecting" Francoise - need to disambiguate with names (don't use bare names) likes it. - good for users and for the tools Arturo - willing to consider the java approach (similar to what Gord was mentioning in the f2f). Mike - randomize with - Freescale expects to resolve to class first. 2-day f2f being considered for early November to address this issue. Special one-time conference call on 10/22 11-1 AI: all - list of mantis items for the list (prioritize the list). send your prioritized list to the alias by end of this week, insert any mantis item you think should be reviewed/feature freeze. 7. Next meetings: -------------------------------- Monday October 29, 2007 Monday November 12, 2007 Monday November 26 ??? Monday December 10