SV-EC Committee Meeting Monday November 26 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 33 = 25 Meeting number: ---------------------------------- 000000000000000000000000000000000 000000000111111111122222222223333 123456789012345678901234567890123 Meeting Days: --------------------------------- (121202020102020101311202020101212) Day (481593604882505956041593606715926) (000011111100000000000000000011111) Month (889900112211223344456677889900011) (000000000000000000000000000000000) Year (666666666677777777777777777777777) ------ Attendees ---------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAAA-) Arturo Salz 27 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-AAA) Cliff Cummings 25 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAAAA) Dave Rich 32 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAAAA) Francoise Martinolle 27 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-AA) Mehdi Mohtashemi 30 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAA) Neil Korpusik 32 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA) Ray Ryan 32 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAAAA) Gordon Vreugdenhil 28 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAAAA) Steven Sharp 27 (--AAAA-A-------------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A--------------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAAAAAA) Stu Sutherland 25 (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAAAA) Heath Chambers 26 (-AAAAAA-A----AAAAAAAAA--AAAAAAA-A) Don Mills 24 - (2 of last 3) (--AA--A---A-AAA--A-AAAA-A-A--A--A) Jonathan Bromley 16 - No voting rights (--A------------------------------) Logie Ramachandran 01 - No voting rights (----AAA--------------------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAAAAAAAAAAAA) Mark Hartoog 26 (-------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-AA-) Mike Mintz 12 - (2 of last 3) (------------------AAAAAAAAAAAA-A-) Geoffrey Coram 13 - (2 of last 3) (-------------------AAAAAAAAAA-AAA) David Scott - Mentor 13 - (2 of last 3) (------------------------A--------) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AAAAAA) Mike Burns - Freescale 06 (2 of last 3) on 11/26/2007 [for next meeting] 15 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// November 26, 2007 ///////////////////////// 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: Steve, Mark Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: ------------------------------------------------- http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_October_15_2007_Minutes.txt http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_October_29_2007_Minutes.txt Move: Heath - approve October 15th, October 29th minutes Second: Stu Abstain: None Opposed: None Passed unanimously special Name-resolution meetings: un-official minutes http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_NameResolution_November_5_2007_notes.txt [Note: the November 5th 2007 meeting minutes were mislabeled Nov11] 3. Update P1800 working group meeting Nov 15.2008 schedule updates and discussion ----------------------------------------------------------- a) version D4 of LRM is available b) New schedule from p1800 meeting (October 4 2007) c) Next p1800 working group meeting: November 15 2007. 11/12/2007 all committees must open active Mantis items that they are going to complete for this release. 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. The current svec list for remaining time allotted [ updated list is appended]. Neil: 93 mantis items, 2 did not pass. The Working Group gave the DRs more time to review the following: 1645 SV-BC behavior of keywords directives at end of compilation unit 1556 SV-EC in-line static variable initialization - require keyword static? 3.1). Next Champions is this Wednesday November 28th, 2007. 4. Updates: Name Resolution meeting (Nov 12th 2007) ---------------------------------------------------- Gord - we spent most time reviewing existing proposals. - 2217 was discussed in svbc - expecting an email vote selects versus hierarchical references. 5. Prioritized list for feature freeze review and plans: --------------------------------------------------------- a. [from Name resolution meeting: had consensus on several mantis items 2215 2214 1857 rewording of that sentence. 2211 forward typedef. b. The list is appended. 2215 LRM isn't clear enough on ways that a default specialization is constituted Gord: clarifies the default specializiation, terminology is being explained. Jonathan: "use of the ..." --> shall denote the specialization. Mike B. : a default specialization is a type Move: Gord - approve 2215 with friendly amendment Second: Cliff Abstain: None Opposed: None Passed unanimously 2214 Interaction of imports, $unit and bind are unclear Francoise: question on the user defined typed names. Mark: it maybe difficult to parse the bind statement. Gord: my recommendation, if you're using types in bind statement, they should be simple type. Jonathan: it could be relaxed in the future. Francoise: Are interface based type not allowed? Gord: normal rule, typed names are resolved in the target context. Target may not exist, the type must be visible at the place where the bind occurs Mark: for a type from a package it is clear Jonathan: type parameters must be matching in both places. types must be both visible and matching friendly amendment: must be visible, and matching in both scopes. The proposal was updated during the meeting Move: Gord - approve 2214 Second: Mark Abstain: None Opposed: None Passed unanimously 1857 external method definitions and parameterized class types Gord: in 8.23 - 2nd para, 2nd sentence The second statement, indication function, is not meaningful. "The return type of an out-of-block declaration shall be specified prior to the out-of-block indication for the method." Jonathan: we can remove it and still is ok. Maybe we can add a comment. Gord : we should be able to just delete that sentence. Jonathan - agrees. Cliff - will others understand the point if we drop that sentence? adding one more function definitino with real type would be useful. Jonathan - suggested adding another method that returns type T; Move: Gord - approve 1857 with friendly amendments Second: Neil Abstain: None Opposed: None Passed unanimously 2211: typedefs are required for some type references Mehdi - what about italicized text? Stu - the Editor may need to make changes. Cliff: maybe there is something there to finish the sentence. Move: Gord - approve 2211 Second: Heath Abstain: None Opposed: None Passed unanimously ========= Items for feature-freeze (11/12/2007) =============== 2109, 1857, 2080 name resolution and related items. [assigned: Gord] 2107 2106 2108 1268 1809 - Francoise - wants more time for this one - Cadence against part of it. Don't want to import a symbol that won't be used. Gord - won't have time to write up such a change. Francoise - will put together a proposal for it. 1043 1832 1508 1516 1858 Gord - latest round of discussions not coming to complete consensus - will send email to see if we can come to agreement before next mtg 1583 1702 and 801 Jonathan- 1702 covers the following topics 1. assignment patterns for queues 2. concats for queues 3. other arrays 4. regularizing assignment compat issues between array types - the following could be closed as being covered by 1702 [Jonathan] 412 516-522 inclusive 801 974 Steven, Cliff - haven't reviewed it Stu - any reason to not use list of values when assign to q? Jonathan - not trivial to ensure it is bullet-proof. - found one implementation that supports what he is proposing, but did find some cases that were being resolved in an arbitrary way. Gord - has reviewed it some, it looks correct so far. - strings - pose some potential confusion for users. can be indexed, but string concat is special. Dave - nested concat an integral concat? Jonathan - two nested {{ - implies inner is a regular concat. Steven - arrays of unions might be a problem. - how know if we should flatten an array of values? - assignment pattern to union - recalls that it goes to first element - tagged union - ??? Stu - agreed with that - true for assignments Jonathan - has not considered this case - would be happy to outlaw union within {} Steven - this is definitely an obscure case - when {union} - don't know how to handle it - when union on LHS also an issue Dave - is it allowed to do an assign to a union as a whole? Jonathan - the array concat stuff is actually just a convenience. The operation can be done a different way. Dave - we should pass this proposal if it improves the LRM, even if there might be some strange corner cases identified. Gord - it is definitely better than what we have in the LRM today Jonathan - 1447 is related. Steven - sometimes there is dynamic sizing on the RHS, which makes it an unknown size initially - can turn it into a queue first. - don't need 2-step process in all cases (statically sized RHS) in worst case can construct a queue and then do the assign. Jonathan - if move items around in a q, references to them may have a problem Gord - agreed. Example from Jonathan's email of Nov 18th: task T(ref int I); #5 ... endtask int Q[$]; initial begin Q = = '{1,2,3,4); fork T(Q[3]); join_none Q = {Q[0:1], Q[3], Q, Q[$]}; // 3 copies of Q[3] end Steven - seems unreasonable to deal with these cases. Dave - 13.5.2 contains relevant text about outdated references but it doesn't cover this case. Gord - 7.11 refers to q-like operations (e.g. adding to a q) Dave - in Superlog there were no q methods. had to use concat. Gord - this proposal can cause problems with the previous LRM. seems to only be represented by non-normative examples. Could get rid of Jonathan's generalization and then only refer to queues. Dave - push or pop a number of elements at once. Not allowed today. - some users want to push one q onto another using a method. Gord - if need to keep q's with outdated references. The concat forms are not equivalent to method operations. Array concat forms wipe out the array. Once provide element of q by ref, any operation using {} concat form will destroy the ref into the q (no longer referenceable). Jonathan - q concat {} - if all elements are unique. (does this help?) Steven - could have slices that are not known at compile time. Gord - possibly toss the regularity and only add something for q's. - we need to lose something Jonathan - could deprecate queue concat form altogether. Gord - that was the svbc position. Steven - is it important for a ref to a q element to still be valid? Users could still use the methods to get the desired behavior. Gord - one application supports all of this. - there will not be end customer happiness if we deprecate it. - we don't know what the current implementation does for all corner cases. Mark - hasn't gotten into this too much. Gord - ok to keep current proposal - but make it clear that it isn't the same as the method operations are for a q. change this -> array concat operation creates brand new array contents. any references to items in the existing q no longer valid. Gord - some of the examples are also affected since a concat it resetting the array contents. Jonathan - assume 1447 is passed? - it touches the same paragraph. Mike B - willing to work with Jonathan on coordinating the 1447 changes. AI/Mehdi - call for an email vote on 1702 - also list of others to agree to as duplicates (list separately) 801 list, covers all queue items [assigned: Jonathan, Francoise, Steven] 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 974 1447 AI/Mehdi - add these to the email vote 2164 Use "base class" instead of "parent class" in 8.12 [assigned: Arturo] Arturo 1714 singular type as the mailbox default Dave - default type - mailbox is a builtin class - if want to extend, no way to refer to the default value - ie no need for a singular type mailbox. Gord - simple suggestion - in place of 1714 - the LRM refers to the mailbox as a parameterized class. - need to carry around extra meta info for a heterogeneous mailbox. Cliff - we need to have Arturo on the call for this discussion Dave - deprecate default mailbox of a parameterized class. want to require a default type. Gord - see G.3 Jonathan - doesn't think there is any need for the current capability - get() need to specify current type. How know which get to use when heterogeneous? Steven - will a dynamic cast work? Gord - can't do a peek. - need to load a tag to allow it to be unloaded. - could use a tagged union. Mehdi - can use the try_peek() option to check and to get the right one eventually. This is how it was intended to be used. Dave - it is only there since Vera didn't have parameterized types. Mehdi - a mailbox is usually a simple fifo. - use a q in most other places. Gord - users want to extend mailbox to inject errors. Mehdi - no, want more control to inject errors. - a mailbox would be a problem if do complex processing. Stu - can we just say can't extend a mailbox? Mehdi - classes were added at a later date. Neil - we definitely need to be able to pass handles through mailboxes. Gord - agreed AI/Gord, Dave - make a proposal 1447 (detailed proposal, fixed up for D4). 1584 defaults in virtual methods 2035 class methods with static lifetime) no proposal can put at the end of the list 958 dynamic array size method unclear when empty Assigned to Neil. Move to end of list. Who added these to the list? 974 comparison of dynamic arrays/queues to 1-dimensional fixed arrays 1256 linked list description 1719 Shallow copy constructor needs clarification 1857 external method definitions and parameterized class types 1858 Name binding in inline constraints 2055 coverage bin distribution is not even 2149 Covergroups sample method with arguments 2211 references to types from forward classes, related to class resolution being used to refer to a type from a type parameter, interface type, or forward type 2211 typedefs are required for some type references 2214 Interaction of imports, $unit and bind are unclear 2215 LRM isn't clear enough on ways that a default specialization 6. Review mantis items with proposals ---------------------------------------------------- 2113 Inconsistency in constraining assoc array size 2137 2181 Ambiguity in implicit declaration of production variables in randsequence 2183 7. Next meetings: -------------------------------- Monday December 3 2007 -- continuation of November 26 2007 meeting Monday December 10 2007 Monday December 17 2007 -- continuation of December 10 2007 meeting