SV-EC Committee Meeting Monday October 29 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 31 = 23 Meeting number: --------------------------------- 0000000000000000000000000000000 0000000001111111111222222222233 1234567890123456789012345678901 Meeting Days: --------------------------------- (1212020201020201013112020201012) Day (4815936048825059560415936067159) (0000111111000000000000000000111) Month (8899001122112233444566778899000) (0000000000000000000000000000000) Year (6666666666777777777777777777777) ------ Attendees ---------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAA) Arturo Salz 26 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-A) Cliff Cummings 23 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAA) Dave Rich 30 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAA) Francoise Martinolle 25 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-) Mehdi Mohtashemi 28 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAA) Neil Korpusik 30 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAA) Ray Ryan 30 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAA) Gordon Vreugdenhil 26 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAA) Steven Sharp 25 (--AAAA-A-----------------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A------------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAAAA) Stu Sutherland 23 (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAA) Heath Chambers 24 (-AAAAAA-A----AAAAAAAAA--AAAAAAA) 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-AAAAAAAAAAAAAAAAA) Mark Hartoog 24 (-------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-A) Mike Mintz 11 - (2 of last 3) (------------------AAAAAAAAAAAA-) Geoffrey Coram 12 - (2 of last 3) (-------------------AAAAAAAAAA-A) David Scott - Mentor 11 - (2 of last 3) (------------------------A------) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AAAA) Mike Burns - Freescale 04 (2 of last 3) 16 people (other than chair) currently have voting rights for the next meeting Note: One person got a busy signal when dialing in to the call. ** Minutes taken by Neil Korpusik ////////////////// October 29, 2007 ///////////////////////// Note: Mehdi was not on the call, Neil chaired the meeting. Agenda: ------- 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: Heath Passed unanimously 2. Review minutes of previous meetings ------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_October_15_2007_Minutes.txt 3. Results from the Champions meeting of 10/25/07 -------------------------------------------------- SV-EC items ----------- 1556, 1980, 1623 - passed unanimously 1707 - 2 abstains, neil to add bug note about removing words clause and sub-clause (only require the clause number). Next Champions meeting will be on 11/08 8-10am PST 4. P1800 working group, schedule updates and discussion --------------------------------------------------------- New schedule from P1800 meeting (October 4 2007) Next Working Group meeting will be 11/15/07 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. Need to have a plan for completion of items. For svec we just say all to be done by 12/15(?) 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: 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 2113 - added by neil from Oct 29 meeting 2164 - added by neil from Oct 29 meeting 5. Review October 26 2007 email vote results ----------------------------------------------- The following two Mantis items passed. 885 1609 The following Mantis items had one or more no votes 1384 Dave - already uploaded the changes that Neil suggested Mark - doesn't like the superclass to parent class change Gord - 8.12 has the same problem - thinks 8.12 should be changed Stu - a change in conjunction with nested classes? Gord - should use one term everywhere - add a new mantis for 8.12 Mike - prefers base class (others agreed) Gord - super says to look at names that are visible - prefers to use base class and not immediate - extended is what we use for derived classes Arturo - thought super was best Cliff - likes base class Move: Gord - with friendly amendment to use 'base' instead of 'parent' Second: Stu passed unanimously AI/Gord - open new mantis for parent to base (see Mantis 2164) 1715 Dave Rich, Cliff, Arturo Cliff - what does it mean to pass a cb through a port? - Jonathan - sent email that he updated the proposal and suggested that we might want to not spend too much time on it. Mike burns - thinks it might be easily salvageable Neil - we will move on for now 1723 Cliff, don Cliff - likes num(), prefers not to tie up the word size size could be used in the future for other purposes Steven - how many possible objects are there (could be unlimited) Dave - could check the index type (ie future capability) Gord - normalizes things by having the same name - having the same name outweighs the objections Move: Dave - approve the proposal for 1723 Second: Stu Abstain: Opposed: Cliff, Don - see reasons given above Passed, with 2 no votes 1851 Dave, Gord Gord - local means something different from localparam Stu - requires more than just changing local to localparam Gord - use localparam declarations (to avoid the plural form) AI/Gord - update the bug note, and Dave will make the changes to proposal Move: Gord - approve the proposal for 1851 with the following change, "localparameters" to "localparam declarations" Second: Arturo Passed unanimously 2021 Stu related to 14.15.1 as updated by Mantis 890 Neil - Stu asked for the word note to be removed Cliff - agrees Move: Stu - approve the proposal for 2021 after changing the note to no-note (make it normative) Second: Cliff Passed unanimously AI/Jonathan - make the changes to the proposal. 2055 Arturo, David Scott David - it wasn't unclear in the existing spec. - an arbitrary change - not backwards compatible Mike - this is a nicer approach, but it is not backward compatible Gord - prefers to leave it alone unless there is a good reason to change it. Arturo - suggested that this new dist be an enhancement and that we leave the default behavior alone. - most people use the autobin capability Stu - doesn't think it is a cornercase - wait for a new proposal that doesn't create backward compatibility issues. - could possible use one of the type options to handle it. AI/Stu - add a comment that there is a backward compatibility issue 2113 Neil (with Friendly), Dave Rich, Arturo Ray - this action describes iterative constraints. - another section would need to be changed (17.4) Arturo - why only mention this change for queue? Mike - change 'results' to 'shall result in' move second sentence to 17.4 Ray - more than one sentence needs to be added. Gord - prefers to leave in 'or queue' - strike out the new second sentence and create new mantis for updating section 17.4 Stu - prefers to just have one mantis item for queue portion We agreed to have just one mantis item in the end. 2137 Neil - it should go to svac, Cliff, Mark, Steven Mark - local variables inside a sequence - these aren't even automatics Gord - sequence locals (on a separate thread) Arturo - mixing procedural and ... Steven - these are not structured procedures (his note on email vote) - requires some wordsmithing. - these are the procedural constructs and these other situations also allow what is also allowed in a procedural context. Mike - agreed that he could add a separate paragraph. AI/Mike - send an email to svac on this sequence match items can be used in .... 6. Review mantis items with proposals --------------------------------------------- 2117 why can't covergroups be extended - no proposal Arturo - how to override a property (coverpoint, cross) - it is a complex change - Synopsys is looking at something in this area Gord - getting all of the compositional rules correct is hard. Gord - should have another meeting on name resolution stuff before doing more on the tough ones. Get more consensus from them first. 2141 - Class scope resolution operator :: Gord - the combination of 2141 and 2142 get to the core of some issues of disagreement. Mark - 2141 changes the LRM. adds to what can be on LHS of :: Gord - there are other issues of type reference and we can deal with them separately - "the type parameter must resolve" instead of "it must resolve" Francoise - "the name shall resolve to a class type ..." Gord - can get rid of part about an error, when use 'it shall' - packages are not types (can't pass as a type) - "shall resolve to a class or covergroup type" Mark - "when a type or type parameter is used, the name is used it shall resolve to a class or covergroup type after elab." Mark updated the proposal on the fly during the meeting. Move: Mark - approve the new proposal for mantis 2141 Second: Gord Passed unanimously 2142 - Gord - make a similar change here that we just made to 2142. Mark - don't want covergroup here. When a tp or ty is used in a base class as in class D4 above, the name shall resolve to a class type after elaboration. - putting this in the LRM raises a lot of name resolution issues that we are committed to resolving for this draft. Move: Mark - approve the new proposal for mantis 2142 Second: Gord Passed unanimously 2025 - now has a proposal (Shalom) Mike - doesn't see a need for such a discussion (ie doesn't see the need for describing the difference between string literals and array literals). Arturo - string literals were in 1364. Mike - like a bit vector Arturo - but not a bit vector for strings - a string literal has different semantics when assigned to a string Francoise - yes, described in 7.8 (agrees to delete this sentence as shown in the proposal for 2025) Move: Arturo - approve the proposal for mantis 2025 Second: Mike Burns Passed unanimously 1580 Dave - it went back to champions - can avoid modport by using a hierarchical reference Francoise - when using a full hierarchical path Dave - that avoids the virtual interface - you can always use a full hierarchical reference - some users think that you no longer have access when there is a modport specified. Gord - a legality question being addressed here, not methodology Arturo - it is ugly, but fine Mark - functions and methods can be referred to through a virtual interface Dave - a modport is not a scope Gord - not comfortable with directionality issues in modport Stu - that is a separate issue from 1580 Move: Dave - approve the proposal for mantis 1580 Second: stu Passed unanimously Interface/modport discussion: ----------------------------- Gord - wanted a discussion on modport directionality - 1 extreme - a modport name with input - any assign to it in lval context is illegal Arturo - agreed with this description Gord - can't read from an output port either. Mark - can debate this question for nets. Gord - would like to ensure we are all on the same page. - we need to nail down the rules if we want them to be strict Mark - modports would be an svbc issue - virtual interfaces would be svec Gord - wants to get input from svec to take to svbc - didn't think that a modport had more restrictions than ports - can't do a $display of an output port. Steven - wasn't sure that you can't read it. what Gord mentioned about $display was only one interpretation Dave - a modport is syntactic sugar for having the portlist Mike M. - most code is in this area. Gord - less concerned about what the rules say as to making sure that we just agree on them. modports - just providing visibility? Dave - it is only strict for nets and wires? - if don't have a modport (all wires are inout and vars are ref) - Can use same rules for regular ports for this. Stu - was in agreement on this. Dave - each port creates a new variable... (one interpretation) Steven - can't have 2 continuous assigns to same one. Gord - nets and variables not the same Steven - nets get collapsed and can have >1 driver Arturo - then what if specify as an input? Steven - only used to specify intent. (good old verilog) Gord - what does synthesis do with modports? that is probably the main question. - is modport direction the authority? - verilog users may not worry much about direction specified. AI/Gord - create a mantis item for this and add to list to be done by 12/15. 7. Next meetings: -------------- November 05, 2007 - another name resolution conference call (mark) Monday November 12, 2007 Monday November 26, 2007 ??? Monday December 10, 2007