SV-EC Committee Meeting Monday September 11 2006 11:00am - 1:00pm PST [Minutes distributed for approval at next (sv-ec) committee meeting] (121) Day (481) (000) Month (889) (000) Year (666) --------- Attendees ---------- (-AA) Arturo Salz (--A) Cliff Cummings (AAA) Dave Rich (AA-) Francoise Martinolle (-AA) Mehdi Mohtashemi (AAA) Neil Korpusik (AAA) Ray Ryan (---) Surrendra Dudani (AAA) Gordon Vreugdenhil (AAA) Steven Sharp (--A) Phil Moorby (---) Doug Warmke (AAA) Stu Sutherland (-AA) Heath Chambers (-AA) Don Mills (--A) Jonathan Bromley - From England (--A) Logie (NOTE: 3rd of 3 meeting for voting rights ends with this meeting Sep 11, 2006) ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// September 11th 2006 ///////////////////////// Agenda: 1. IEEE patent policy ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Cliff - Assume that the patent policy was read Second: Steven Abstain: none Opposed: none passed 2. Review Meeting minutes, of and August 14th 2006 http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_August_28_2006_Minutes.txt Move: Dave - Approve the minutes of Aug 28th, 2006 Second: Gord Abstain: none Opposed: none passed 3. Action items review ----------------------------- Action items: August 28th, 2006 ----------------------------- [DONE] AI: general: Mehdi - update status on approved/closed mantis items from August 14th and August 28th. AI: follow-up to mantis 978 Neil - rewrite unique(), the first 2 sentences appear to be contradictory. - Make sure that it is clear that array elements are returned. - Add some examples for unique(). Neil - Array reduction methods can operate on arrays of non-integral values when a with clause is specified, as long as the type of the expression is an integral value. [Not Done] Gord - re-write section 5.15.4 - only the default argument value makes sense. [Not Done] Dave - what order is used for find and find_index (e.g. traversal is left to right of the bounds, associative is min to max) - 5.15.1 - change last sentence in first paragraph. All - can anyone come up with a realistic example? (last example 5.15.4) - not only where you would need it but also what does it mean. [DONE] AI: 1437: Dave, post a proposal. From Previous meetings: [DONE] AI: 890 Cliff and all - send email on the reflector to get the discussion started 4. Name Resolution sub-group update ------------------------------------ Gord - the svbc spent the whole meeting on mantis 1323 - it failed to pass; do imported names become available for re-export? There is a deep disagreement on this point. - Gord will work with Mark to come up with a form for an explicit re-export, i.e. chaining behavior. - users in the svbc meeting seemed to be interested in having 2 forms for package import (one which allows chaining and one that doesn't). - doesn't think that svec needs to take any specific action at this point in time. 5. champions meeting --------------------------- Neil - mantis 1308 was passed by the svec but it doesn't use the proper color-coding scheme. Dave - for 1308 we can just say to replace all of the text AI/Neil - fix 1308 proposal color-coding scheme Dave - mantis 1549 implicit - new keyword being proposed by the svac By default everything is implicit, if want to add a type you add the implicit keyword. - other committees should review it to see if there are other places where this can be reused. (e.g. variable number of arguments, mailbox - already has an implicit type capability) Gord - mailbox case is a bit different - default type is no type - default for mailbox is a singular type, there are fewer restrictions in the ac example - assertions aren't type constructed - Brad was asking about functions and tasks with regards to 'implicit'. Gord would have deeper concerns about allowing that. - if implicit is only in the tf_args in the assertion context, would rather see an existing keyword be used (since it is of such limited scope). Arturo - they could possibly use the parameter keyword Dave - yes, there would be additional semantic constraints on a mailbox Arturo - assertions are instantiated (fundamental difference) - similar to type parameter. - assertions aren't really calls (like functions and tasks) - it is a powerful concept, pushing type checking to instantiation. Dave - type dependent on the caller, not the callee Neil - 1308 - Steven had an issue with default arguments. The champions asked the svec to urge Steven to followup with his concerns. Gord - If you change the value of a default and then call a method, is the default from the dynamic type of object being referred to or is it a static reference? Arturo - it is always referring to a static type Dave - does the expression need to match in a default for virtual methods? Gord - when using a base handle to call a virtual method, which value do you get for the default? Arturo - function void f(int v=2); base obj; obj.f(); // what value do I get? 1 from static type, 2 from dynamic - modifying the expression for the default value of a virtual method. the current wording is that you get it from the base (?) Logi - outlaw overriding of the default then use variable arguments instead. Arturo - that is a different issue. Steven - could check the base handle type, but you still get into situations where it is confusing. Logi - could have a static handle of base type. Arturo - there are type compatible issues here. Gord - it would be an addition to 1308 since 1308 currently doesn't state which default value we get. AI/Mehdi - add to agenda for next meeting. AI/Steven - open a new mantis item for this issue. AI/Mehdi - contact the svac - that we want to have some time to review this. NEED to review the 1308 plus Steven's new mantis item next time. AI/Neil - fix 1308 proposal color-coding scheme AI/Mehdi - add to agenda for next meeting. AI/Steven - open a new mantis item for this issue. AI/Mehdi - contact the svac - that we want to have some time to review this. 6. Review mantis item list. [see below] ----------------------------------------- 1437 04-26-06 Prototype syntax for array locator methods in 5.15.1 is not legal(Dave) Arturo - Should this be merged with 978? AI/Dave - add a note to the proposal for 1437, that it should be applied to the LRM after 978 has been applied. Move: Dave - approve mantis 1437 with 1437_array_locator.pdf [Update after 978 update is done] Second: Heath Abstain: none Opposed: none passed 1459 05-09-06 Mailbox 'new' method should never return null (Dave) Dave - Why make mailbox a special case? Gord - other languages have exception mechanisms. - new can only fail if there is a severe problem. - just for mailboxes seems to make no sense (why not for other classes) - it is an issue with the whole memory management system. Arturo - what could cause it should not be in the LRM - the real issue is whether a call to new should be able to return null and what the behavior should be. Gord - we could agree to 1459 which makes all cases consistent and then open a new issue for the more general situation. Arturo - we need to say if new can or can't return null. - now leaning towards new not returning null Move: Dave - approve mantis 1459 (proposal mb_new.pdf) Second: Cliff Abstain: Oppose: Passed AI/Arturo - create a new mantis item if there is still an issue with new() being able to return null. 1480 05-19-06 method_call_root BNF should use primary, not expression(Brad) Gord - not all primaries are valid (e.g. null) - can have an arbitrary expression as the root of a method call - unparenthesized calls which use the dot operator Ray - can there can be issues with hierarchical references? Steven - there are still holes in the area of '.' - could access static variables inside a function (name conflict case) Gord - whether or not a name matches a dot is immaterial. what you do when you see the name and what you do next is the issue. - system tasks and functions, if pass in a scope, could be an unparenthesized call, you don't know what to do. Arturo - why can't we close all these holes? Gord - f(). <--- can't do this without this change Steven - dots are part of a name today. Arturo - what if we drop the optional parenthesis capability? f(). <--- then have a way to allow this Gord - there is probably a way to come up with a way to do this - if . is allowed to compose selects, as soon as you see function call in it, then treat the rest of the expression as selects. Ray - agrees that optional parens are an issue - if function call, the interpretation changes... ok for users? Arturo - a function today, can't return a scope. Ray - it is a hierarchical separator Arturo - what if a class handle or a virtual interface? Gord - the name resolution group will be addressing part of this. - expects to have to come back to committee due to ambiguity - conditions under which parens are implied are an issue, we need to specify the rules for when these can be optional. - expects it to be extremely confusing to allow optional parens in the middle of an expression. - an actual function call is not a primary. Stu - deprecate optional parens. NOTE: Will come back to 1480 later, after some discussion takes place. 1515 06-25-06 Localparams should be allowed in classes (BNF) (Brad) Move: Gord - approve the proposal bnf_class_local_params_1515.htm for mantis 1515 Second: Arturo Abstain: Oppose: Passed 1545 07-20-06 13.12.1: $urandom example error [Shalom] Arturo - when would random fail? - use void ' in this example. AI/Ray - put together a proposal 1552 08-01-06 Wording of mailbox description - section 14.3 [Neil, Steven] No proposal AI: Neil - add a proposal 1576 08-30-06 In 5.15.1 unique and unique_index need to be reworded No proposal 890 08-31-06 clarifications in program and clocking blocks (Doug) Cliff - Cliff outlined his goals for this mantis item: get vendor agreement eliminate races syntax that is least surprising to users - do we need to use NBA? Arturo - Not really an NBA Dave - we may need to split the mantis item into two. (program, clocking) Jonathan- he only has a small number of remaining issues. - clocking block variables. Is this the same as the same signal that is being driven? output - can't read value just driven LRM is clear on this - and he agrees - does the drive happen for all clock events? No it doesn't... One implementation does drive it all the time. - implicit NBA to a variable is illegal. Dave - it isn't a non-blocking assignment, just scheduled in NBA region. - The NBA restriction for program block, not required any more. Arturo - NBA to program variables - would require a change to the scheduling semantics. Could be just a variable in a program or a program port. Gord - allowing a regular NBA from a clocking block, seems to open a hole in the separation between design and program. Arturo - yes, there are some loopholes. - NBA to program ports is allowed (Dave -- this is a loophole) Dave - port of program block. Is it a program variable or a design variable? - implementations vary on this. - what is the reason for the rule on restrictions to NBA to program variables? Jonathan- outputs are in NBA region from clocking block - users can't see the value of output, so we don't need to discuss it. Dave - single clocking block (resolution performed) multiple clocking block (last drive wins) - thinks of outputs of clocking blocks as separate variables Gord - program ports - question - what can you do with it, determine by fact that a program port, or hicon? Arturo - can't nest programs, means that the output is part of something else. hicon will be part of the design. need a net in design to allow programs to be connected. Gord - NBA behavior to program port from within program, won't happen in the same reactive cycle, would require going around the NBA first, before it propagates. - can't refer to program variables from the design side. - not possible for a program port to be a program variable. - write to program output, can't read new value until next cycle. hicon will be a design value. can't read new value until next pass around loop. Arturo - clocking block is like a trampoline between the design and a program. 6. Next meeting: Proposal: September 25, 2006 ========== ADDITION TO the minutes, not part of regular ============ ========== meeting discussions, informational purposes ============ ========== Action Items updated based on September 11th, 2006 ===== Action items: September 11, 2006 ------------------------- AI: 1308 Neil - fix 1308 proposal color-coding scheme AI: 1308 Mehdi - add to agenda for next meeting. AI: 1308 next Steven - open a new mantis item for this issue. AI: Mehdi - contact the svac - that we want to have some time to review this. AI: Dave - add a note to the proposal for 1437, that it should be applied to the LRM after 978 has been applied. AI: 1459 Arturo - create a new mantis item if there is still an issue with new() being able to return null. AI: 1545 Ray - create a proposal AI: 1552 Neil - add a proposal