SV-EC Committee Meeting Monday August 6 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 25 = 19 Meeting number: -------------- 0000000000000000000000000 0000000001111111111222222 1234567890123456789012345 Meeting Days: ------------- (1212020201020201013112020) Day (4815936048825059560415936) (0000111111000000000000000) Month (8899001122112233444566778) (0000000000000000000000000) Year (6666666666777777777777777) ------ Attendees --------- (-AAAAAAAAAAAAAAAAA-AAAA-A) Arturo Salz 22 (--AAA-AAAAAAA-AAAAAAAAAA-) Cliff Cummings 20 (AAAAAAA-AAAAAAAAAAAAAAAAA) Dave Rich 24 (AA-A-AAA-AAAAAAA---AAAAAA) Francoise Martinolle 19 (-AAAAAAAAAAAAAAAAAAA-AAAA) Mehdi Mohtashemi 23 (AAAAAAAAAAAAAAAAAAAAAA-AA) Neil Korpusik 24 (AAAAAAAAAA-AAAAAAAAAAAAAA) Ray Ryan 24 (AAAAAAAAAAAA-AAA---AAA-AA) Gordon Vreugdenhil 20 (AAAAAA--AAAAA-A--AAAAAAAA) Steven Sharp 20 (--AAAA-A-----------------) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A------) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---) Stu Sutherland 17 - No voting rights (-AAAA--AAAA-A-AAAAA-AAAA-) Heath Chambers 18 (-AAAAAA-A----AAAAAAAAA--A) Don Mills 17 - No voting rights (--AA--A---A-AAA--A-AAAA-A) Jonathan Bromley 13 (--A----------------------) Logie Ramachandran 01 - No voting rights (----AAA------------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAAAA) Mark Hartoog 18 (-------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-AAAA) Mike Mintz 08 (------------------AAAAAAA) Geoffrey Coram 07 (-------------------AAAAAA) David Scott - Mentor 06 (------------------------A) Benjamin Chen - Cisco 01 - No voting rights on 8/06/2007 14 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mothashemi ////////////////// August 6, 2007 ///////////////////////// 1. Review IEEE patent policy ------------------------ ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Gordon- 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_July_23_2007_Minutes.txt Move: Gordon- approve meeting minutes of July 23rd 2007 Second: David Scott Abstain: None Opposed: None Passed 3. Discussion on Merged LRM 1800-2008 Draft3 (any updates) Section review list and assignees on the svec site: http://www.eda-stds.org/sv-ec/Minutes/SV-EC_p1800_2008_Draft3_list.txt Neil - there are some editor questions. Dave - there is a list that Shalom created. Neil - that was just for the svbc Jonathan - will go in and check for editor questions. Mehdi - David Scott take over Doug's sections? program block David - Doug was planning to get to this. AI/Mehdi - move those to feedback that still need to be aligned with draft 3a (from last meeting 7/23/07) AI/Mehdi - for the Champions meetings - which mantis items consistent with 3a 4. Mantis item review 1857 : extern class - Gord - July 2 proposal external method definitions and parameterized class types Did not pass the email vote: Yes votes(7): Gord, Mike, David Scott, Geoffrey, Jonathan, Ray, Steven No votes 3): Neil, Francoise, Mark Mark - no bnf for the "collection of block" stuff In section 8.23.3 the example of the collection of out-of-block declarations for a parameterized class repeats the parameters and their default values. I think this is confusing. It makes it look like you are doing template specializations, which I do not think is the intention at all. I don't think the parameter declaration should be repeated on the "extern class" block declaration. Gord - There is only one bnf change required. - There are rules specified in the text, i.e. semantic restrictions Mark - doesn't like the duplication. Gord - similar to other scenarios where full duplication is required. - some people sent email saying that they like the duplication. - same as extern method Jonathan - if we don't show the parameter list, how know if specifying a body for a particular specialization? Gord - today this isn't allowed, the parameter information is redundant. In the future he would like to extend this capability Mark - doesn't like the use of the word extern Arturo - doesn't like the use of extern either - several people he discussed this with were confused by this. - There are now 3 mechanisms for classes methods. Neil - was asking about combining the 3 Gord says there are no restrictions. Steven - class externs, intern? Jonathan - inside Francoise - that is strange - vhdl has a package header and footing Gord - doesn't want to make more changes to the proposal if we have major issues with what is currently there. Francoise - people at Cadence thought that there was no need for the change Gord - all function return types (including expressions) can be resolved even if types are used? - doesn't have a counter-example where not possible today, believes that it will however be difficult. - The reason C++ has requirements is to make sure that there are no ambiguities. It took several major iterations to get it right in C++ for templates. - nested parameterized classes are a concern for him - bounded look-ahead is required to determine if things are types or not. - we could still add this even if it isn't absolutely needed. - Current LRM requires extern class method declarations to be in the same scope. Steve - current lrm has restrictions on what can be inside/outside. This could be used as an additional argument in favor of this proposal. Gord - mostly concerned about the "brick-wall". Francoise - need to support old form and the new form in implementations Steven - can't use a type name not in the same scope. What about a return type for a method that returns a value defined in the class? Gord - normal name binding rules apply for method return types - abstraction hiding is one reason to use extern methods. There are several reasons for wanting to use it. - There are a bunch of things that could leverage this syntax. Arturo - extern methods that return a parameterized type can already use the :: syntax. Gord - The problem is whether using the default specialization or not. c::t // for the extern body case it would be different Referring to c as a type always refers to the default specialization Arturo - but not if a function declaration Gord - the return type c::t function c::t my_function() Arturo - still thinks that the :: syntax can be used Gord - c::t is different from the unspecialized type Specialization versus unspecialized is the issue. d::t, c::t // couldn't these two be different? If deriving from a parameterized class. base::t // how know if this is the specialized base or not? Arturo - just treat the method definitions as though they were inside the class. Steven - That seems to resolve the brick wall issue. Gord - Willing to look at a proposal from Arturo on how to do this. - for templates in C++ you say template... function c#blah return_type name(...); function c#t=1 return_type name(...); C++ requires us to provides definite knowledge Jonathan - Doesn't understand the big objection here Steven - the concept is a good one (from the proposal) "now back in the class scope" - what are the disadvantages, even if not required? One is that we need to support both syntaxes. Francoise - what about constraints, extern constraints Don't we have the same problem with them? Why not seeing a problem today Arturo - not sure if there is a problem with constraints. - The issue is with parameterized classes returning a parameterized type Gord - it would not be difficult to add text for constraints - There are a lot of situations that we haven't seen yet in SystemVerilog designs that C++ has already worked their way through. We should take what C++ requires into account in making our decision. Gord - is willing to make editorial changes and syntax changes to the existing proposal. - Wants to make sure that we are getting agreement in principle before making slight tweaks to it. Francoise - can we just wait to see if people have problems? Mike - there is already a problem that we know of Steven - something needs to be done to be able to do this at all. c::t function c::f() // means unspecialized default We could use Arturo's proposal or we could use Gord's proposal. Arturo - would have voted no on the email vote (wasn't available) Issue is well motivated - returning a parameterized type from an extern method. - Thinks this can be resolved using his approach. The use of the 'extern' keyword didn't make sense to others that he showed the proposal to. Would change his vote to yes if the syntax was changed. (e.g. a different word than extern) - Not in agreement of forcing everything to be syntactically resolved early. Dave - is in favor of the proposal Francoise - still not sure that this change is necessary Requested that Steven send an email to her on the c::t example. - doesn't like the reuse of the keyword extern - doesn't like the idea of having 2 syntaxes for the same thing Mehdi - we should have more discussion on the reflector. We should have have another proposal available by next time (Arturo). There should be a vote at the next meeting. Gord - parameterized class and the default specialization Users are already having problems here. The current form won't help the users, but that would be technically resolvable Mark - wants to leave the parameters off the extern class blocks. Only if we allow specializations should we do that. Gord - Gord thinks there is no issue here. - This requirement is similar to other places in LRM extern modules, port lists, etc. Steven - just the notion of allowing other capabilities makes it useful Jonahthan - thinks that changes are required. Mike - likes to separate declaration from implementation Neil - I like where we are headed with the mantis item, but I do have some issues with the current proposal. Geoffrey - open to the idea, would like to see a different word from extern - some suggestions were offered within, extern, continue continuation - arturo doesn't like this one Gord - adding another layer of special cases would confuse users Has a deep bias against the :: form, because of this reason. Will go along with it if everyone else agrees but doesn't like it. - use of type and use of class as a non-type name Lots of users were seeing warnings on this. AI/Arturo - put up a new proposal for 1857 for the next meeting AI: Place this on the vote on August 20th meeting. 1897: clarify "union of all significant bins" and "overlapping bins" in coverage computation did not pass email vote One no vote, on this, Neil. Aruturo would have voted No. Neil - the only no vote - it seems that this whole proposal came about because the original text used the word union. - there are extra bins due to the way that the names are constructed - why can't an average be used? David - if there were 2 bins - without parameterization - average would give 50% Arturo - would also have voted no. - what does the word union mean here. - how to do the aggregated coverage? This is a corner case. Doesn't advocate this approach. Any union is a bit strange, because you are making it up. Using names can cause you to end up with extra bins. - was originally proposing using an average. - keep each instance coverage How to compute the union is the only issue. Using the names and using the average could both be used. - there is little that can be done with the weighted average Need to preserve the instance information David - they have users that have asked for both ways. - could add a type option to specify how to calculate the overall coverage. Neil - the weighted average should be the default. - there is one typo in the proposal gt::coverage() should be get_coverage() AI/David Scott - will update the proposal 1707, 1384 streaming operator 1707 7/13 streaming reference algorithm - updated for draft 3a? Neil: one friendly amendment, pack operation described, Take out the word 'here' from 1st sentence of last para, page 1 Dave: delete the clean writeup from mantis. Gord: it looks like another change appears in the clean proposal Jonathan: that comes from a different proposal Move: Jonathan approve 1707 (with friendly ammendment) proposal-1707-jb3.pdf is the proposal Second: Neil Abstain: None Opposed: None Passed 1384 streaming operator Neil - see the agenda for the June 9th meeting, there were several changes proposed in the May 14th conference call that have not yet been made. - The section numbers need to be updated - Friendly amendments: 1 From: An associative array or class shall be illegal as a destination type. To: If the type of the destination is an associative array or a class, the operation shall be illegal. 2 From: Reconstruction does not modify any internal properties in the target class object. To: Reconstruction does not modify the internal state of the target class object. 3 From: It shall be illegal to stream a class handle with local or protected members except when streaming the current instance this. To: It shall be illegal to stream a class handle with local or protected members if those members would not otherwise be accessible at the point of use of the streaming operator. AI:Dave update 1384 with the set of friendly ammentments. 1608 7/9 - equality operator Neil - it looks like the latest proposal is a framemaker file. Jonathan - updated a pdf about 2 hours ago - section 11.4.12 update First new item on null Gord - difficult in this context to talk about type. - you have to talk about how the null was expressed. literal null on both branches could have variables c1, c2 - they could be different class types - should be an error The text is probably not as tight as we want. Arturo - need to add some text that mentions using un-compatible class types. Gord - proposed change: If both the 1st expression and the 2nd expression are the literal value null, the result of the entire conditional operator expression is treated as though it were null. Steven - when using handles of base and derived, want to see base type Don't want null to be some sort of super base type. Jonathan - shouldn't the second bullet be updated to say literal null? Gord - yes (2 places need to be updated -- not the last one) Neil - section number 8.18 ---> 11.4.12 Jonathan - change the header and footer of the proposal as well Mehdi - this will be at the top of the agenda for next meeting. 1594 type matching of class handles Neil - it looks like the proposal is a framemaker file. AI/Jonathan - convert to pdf 1715 triggered method of clocking block 1500 forward typedef 1858 item (constraints) 737 text to use for closure. 5. Discussion: mantis items with no proposal 6. Next meeting: Monday August 20 2007 Monday Sept 03, 2007 <--- holiday