SV-EC Committee Meeting Monday December 17 2007 11:00am - 1:00pm PST Continuation of December 10 2007 meeting. The December 10th and 17th is considered meeting number 34. Attendding either day counts towards attendence for the meeting. An * is used to show the above. With the new calculations for voting rights below (rounded)... 3/4 rule = 0.75 * 34 = 25.5 Meeting number: ------------------------------------- 000000000000000000000000000000000000 000000000111111111122222222223333333 123456789012345678901234567890123344 Meeting Days: ------------------------------------- (121202020102020101311202020101212011) Day (481593604882505956041593606715926307) (000011111100000000000000000011111111) Month (889900112211223344456677889900011222) (000000000000000000000000000000000000) Year (666666666677777777777777777777777777) ------ Attendees -------------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAAA*AA*) Arturo Salz 29 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-AAA*A*) Cliff Cummings 26 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAAAA*A*) Dave Rich 33 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAAAA*A*) Francoise Martinolle 28 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-AA*A*) Mehdi Mohtashemi 31 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAA*A*) Neil Korpusik 33 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA*A*) Ray Ryan 33 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAAAA*A*) Gordon Vreugdenhil 29 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAAAA**A) Steven Sharp 28 (--AAAA-A-------------------------*-*) Phil Moorby 05 - No voting rights (---AA-AAA-AAAA-AA-A--------------*-*) Doug Warmke 12 - No voting rights (AAAAAAA---AA-A-AAAAAAA---AAAAAAAA**A) Stu Sutherland 26 (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAAAA*A*) Heath Chambers 27 (-AAAAAA-A----AAAAAAAAA--AAAAAAA-A*A*) Don Mills 25 (--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*A*) Mark Hartoog 27 (-------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-*A*) Mike Mintz 13 - (2 of last 3) (------------------AAAAAAAAAAAA-A-*-*) Geoffrey Coram 13 - (2 of last 3) (-------------------AAAAAAAAAA-AAA*A*) David Scott - Mentor 14 - (2 of last 3) (------------------------A--------*-*) Benjamin Chen - Cisco 01 - No voting rights (---------------------------AAAAAA*A*) Mike Burns - Freescale 07 (2 of last 3) (----------------------------------*A) Harry King - Cisco 01 - No voting rights on Dec/17/2007 [for next meeting] 15 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// December 17, 2007 ///////////////////////// Agenda: ------- 1. Review IEEE patent policy ------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt 2. Review minutes of previous meetings http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_3_2007_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_10_2007_Minutes.txt Note: Dec 3rd is a continuation of the Nov 26th conference call. ** Did not discuss the meeting minutes in this meeting. 3. p1800 working group meeting update (12/13/2007) --------------------------------------------------- Note: the following contains more detail than what was communicated during the svec conference call. 11/13/07 Technical Committees finish opening Mantis items that they are going to work on for this release. The Committees may not work on any item not on this list. 12/17/07 SV-BC and SV-EC deadline for completing items from their Mantis list. This deadline was extended for sv-bc and sv-ec (used to be 12/15/07). Past this date they are only authorized to work on - LRM merge issues - Editing issues - Champions feedback - 2005 ballot issues - Jeita issues - Mantis 1648 - svec (was originally in svac) - Mantis 2008 - svbc (related to svac 2005) - Mantis 1982 - svbc to review this svac mantis item - Mantis 966 - svbc to review this svac mantis item 01/31/08 SV-BC and SV-EC complete work that could impact the SV-CC 02/15/08 SV-CC deadline for completing items from its Mantis list. Past this date they are only authorized to work on - LRM merge issues - Editing issues - Champions feedback - 2005 ballot issues - Jeita issues - Mantis item 1648 (including any updates made by the svec) 02/28/08 SV-AC and SV-CC freeze SV-AC does not get any leeway for merge, editing nor champions issues. Deadline for sv-ec and sv-ec was extended to end of day 12/17/2007. feature-freeze schedule. 11/12/07 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/17/07 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. 02/15/08 SV-CC must complete all items from its Mantis list. Past this date they are only authorized to work on merge, editing and champions issues. 02/28/08 SV-AC freezes. It does not get leeway for merge, editing and champions issues. Champions: Mike - Mantis item 997 is still in the assigned state. Neil - it won't go to the Champions until it is in the Resolved state - this Mantis item is currently assigned to the svbc 1601 - was sent back to the svec by the Champions (untyped keyword) 1336 - was sent back to the svec by the Champions (creates a contradiction) Next champions meeting on Dec 20 2007. 4. Review/discuss result of email ballot ---------------------------------------- The summary results: Passed: section a) CLOSE the following 412, 517, 518, 519, 521, 801 section b) 958, 2227 Did not pass: section a) 516, 520, 522, 974 section b) 1447, 1858 [both proposals], 2055, 2137, 2181 520 - should stand on its own - see Mike Burns' feedback 516 - can be moved to the children of 1447 522 - can be closed as covered by 1702 (see Jonathan's feedback) 974 - can be moved to the children of 1447 1702 - put it into the resovled state for the next Champion's meeting Discussion: 2055 - the proposal was not updated since the email vote. No action taken. 1447 - Contradictory stmts about unsized array dimensions (5.1 vs. 5.7, 5.8) Mike - Steven had feedback on it. Steven - The proposal suggests that a net is somehow a data type, and a net array is an array of those. The truth is that nets can have data types on them. There is no such thing as an array of nets. "Unpacked arrays are formed from any variable data type, including other packed or unpacked arrays (see 7.4.5). Unpacked fixed-size arrays may also be formed from net data types." Steven - 6.6 already covers it. Mike - is ok making a change to correct this. - updated a new proposal for 1447 during the meeting. "Unpacked arrays are formed from any data type, including other packed or unpacked arrays (see 7.4.5)." Move: Mike Burns - Approve the proposal with friendly amendment from Steven Second: Stenven Abstain: None Opposed: None Passed unanimously 1858: Name binding in inline constraints Gord: lots of discussion on this has occurred. - the grammar is incomplete in the proposal - issue of the semantics of this.x versus x Steven: have disagreement on this behavior, this can have two meanings. Neil: does LRM say anything about this in the in-line constraints. Gord: LRM doesn't say anything about this in the context of inline constraints. Mark: what is it that Gord disagreeing with? this.x behavior to be consistent with other variables. There is no this within a randomized with block. Gord - if x exists inside the randomized object, ok with this.x binding to it, but this semantic causes the following inconsistency. - if there is no x in the randomized object and there is an x in the local context this.x and x are not the same in this case. x would bind within the local context and this.x would not bind. Steven - 'this' is just another variable Maybe 'this' should not resolve into the randomized object. Gord - simple member names within the object Arturo - mapping 'this' to two different places is not good. Mark - sounded like hierarchical reference rules Gord - this keyword in LRM - "the context of object within a method" inside a method - y in randomized object this.x < y // this.x usually means inside this object Mark - constraint inside the object to be randomized - 'this' binds to it Gord - could use macros to build up expressions. this.x and this.y - failiing to resolve might be worse than capturing the wrong ones Steven - macros - local:: allowed in more than constraints? Ray - that gets too dangerous very quickly Arturo - local:: doesn't cause problems. We would need to drop some portion of existing proposal Gord - ok with the rest of the proposal if 'this' portion is dropped. - flagged 9 total issues in the email vote (mostly BNF related) Mehdi - we need to be clear on the agreements. Arturo - ok moving forward without definition of 'this' in the proposal. - the danger is that there would be diverging implementations. - doesn't view it as a deep issue. Neil - can we just disallow the use of this within inline constraints? Gord - current implementations WILL need to support 'this'. Neil - this.x having two interpretations seems very strange Francoise - agrees Steven - this.x binding to the randomized object seems more natural - the only way around it is to reverse the order. - you have a 'this' if you can access the automatic items Arturo - we could decouple the this issue from rest of proposal. Gord - this.x and x symmetry x as a member of containing class x in inline constraint. this.x must match in target or an error. There is an asymmetry in how x may bind to either but this.x can only bind one way. Steven - does not object to the asymmetry Mike - as long as we chose one interpretation we are better off. - would like to decouple the issues. Gord - it appears that the proposal has a lot of support Ray - is the following alowed? local::a.b Arruto - yes Gord - items 2,3,4,5,6,8,9 from the email vote Arturo - 2,3,4,5 - agreed on those Gord - 6 is not a big deal 1) I object to the special handling of "this.x" and the fact that "this.x" and "x" resolve differently if "x" is in a local class context but not the randomize object context. 2) The change does not permit "local::this.x" local:: must be allowed in front of this and super 3) "super" and "this" are not symmetric in the proposal super will be made consistent with this 4) "local::" needs to be permitted in front of a class scope identifier 5) "local::" needs to be permitted in front of type names 6) the proposal is inconsistent in use of the phrases: "the scope containing the randomize method call" and "local scope" 7) should "in-lined constraint" be "inline constraint"? 8) the new proposal still talks about "The scope...from inner to outer...". The list of scopes there is incomplete and incorrect. This should be rewritten to avoid listing the scopes. 9) The phrase "Within the in-line constraint, the following rules apply:" is still in the current proposal. The only new rule here is the one regarding "this" that I objected to above. This phrasing hides the new rule in a collection of otherwise redundant Gord - will review the final proposal to ensure he is ok with it when it goes to the Champions Move: Arturo - approve the proposal for 1858 for local:: 1858-local.pdf with friendly amendments. 2,3,4,5,8,9 from email vote Second: Steven Abstain: Gord - would like to see the text of the friendly amendments before approving it Steven - hasn't seen the friendly amendments. Oppose: Stu - wants to see friendly amendments - not sure ready for the Editor. Passed with 2 abstains and one opposed. AI/Arturo - update the proposal with the friendly amendments. the other half of the 1858, 1858-randomize_with_syntax.htm Gord - the other proposal for 1858 - this approach is the only way to modify constraints without changing the syntax of the contraints themselves. - for macro expanded terms - this proposal is simpler. - the local:: proposal requires changes to the constraint expression itself. Mark - the proposal only does it partially. The problem is with names that can resolve outside the class. Ray - this proposal reverses the one special rule with inline constraints (looking in randomized object first). Gord - today have to add local:: to names in current expression - the list of identifiers in () resolve within the randomized class the others are equivalent to local::y Mark - if you left one off the list it would be a problem. Ray - this just switches the bias... Arturo - when specify empty () Gord - local::{} - not comfortable with this syntax. Arturo - the assertions may want to do something similar - what about types, packages, expressions? Gord - T - a type inside another class - assume it is a type? - ref to T within an inline constarint - allowing it to bind to a type within the target object. The object is completely unknown when compiling the inline constraint. Ray - that is an orthongonal issue Steven - super Gord - this and super could only bind outside - ok with this Steven - concerned if constraint is a complex function with side-effects you would only want to call it once. Francoise - does this proposal add more capability than the other proposal? Gord - allows preventing escaping names without changing constraint expressions. - y - if change class context being randomized. y may now bind to the randomized object With the first proposal you need to use local::y This proposal says, just upate the list within with(). Steven - can see a reason for it, not sure how big a deal Gord - it has been an issue for some users. Neil - agrees that changing the bias is a useful capability. Arturo - has a problem with the identifier list approach. - agrees that the bias change is useful Ray - the randomized constraint itself is similar. Mehdi - any conflict with existing proposal? Arturo - no. - if use local:: it won't be reversed by with() specification Move: Gord -- approve randomize with syntax (randomize_with_syntax) proposal file 1858-randomize_with_syntax.htm Second: Ray Abstain: Steven - doesn't have a good enough understanding of use-model - wants users to decide Arturo - a bit uncomfortable with two lists of identifiers Mark - unconfortable - adds some more felxibilty but at the expense of extra complexity. - the syntax is not that intuitive. Oppose: Stu - 1. Editor - 2 documents - can be fixed(part 1 and part2) 2. wants to see an example with an explanation where names are in the parenthesis. Francoise - redundant with the other proposal - Not sure how important given the added complexity Passed with 9 yes votes, 2 no votes, 3 abstains Cliff, Dave Rich, Neil, Ray, Gord, Heath, Don, David Scott, Mike AI/Gord, Arturo - combine their proposals. Janauary 10th this will be on the agenda. 2181 - Ambiguity in implicit declaration of production variables in randsequence Ray - there is an updated proposal. Neil - There is still one place in the existing LRM that needs to be modified that refers to the first example. Move: Ray - approve proposal for 2181, with the friendly amendment Second : David Scott Abstain: Mike burns - no time to review Steven - not happy about inability to return multiple values (Ray - it would require creating backward compatibility issues to fix that ) Opposed: None Passed with 2 abstains 2137- Some assertion contexts should be procedural Stu - note - meant to be informative? Mike - yes Move: Don - approve proposal for Mantis item 2137 Second: Mark Abstain: None Opposed: None Passed unanimously 5. Next meetings in 2008 ---------------------- Monday January 7 2008 Monday January 21 2008 <--- Martin Luther King Day 3. Other mantis items -------------------------------------------- 3.1) Need to provide sv-ec analysis by end of January 28 2008. Discussion on 1648 516 5.7 and 5.8 description of type compatible arrays 520 example of queues assignment (Francoise) 522 use of concatenation in 5.14.2 (Francoise) 974 1714 singular type as the mailbox default 1256 linked list description 1719 Shallow copy constructor needs clarification 2183 2229 6. Next meetings in 2008 -------------------------------- Monday January 7 2008 Monday January 21 2008 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: Mike B. Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: ------------------------------------------------- http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_12_2007_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_26_2007_Minutes.txt Move: Heath - Approve the meeting minutes of Nov 12th and Nov 26th Second: Mike B. Abstain: None Opposed: None Passed unanimously December 3rd 2007 meeting notes are not yet available on the site. 3. Next Meetings for p1800 and Champions. ----------------------------------------- NextChampions meeting will be December 20th.2007. Next p1800 working group meeting is on December 13 2007. 4.Prioritized list for feature freeze review and plans: --------------------------------------------------------- The list is appended. 2109, 2080 name resolution and related items. [assigned: Gord] [2107, 2106, 2108, 1268, 1809, 1043, 1832, 1508, 1516, 1858, 1583] 1809 forward references into $unit package (was discussed in detail in name resolution meeting of 11/19) Francoise - the new proposal wasn't uploaded to Mantis - Matt has it. - was only sent to the svbc - the reflector was down 1858 Name binding in inline constraints (see emails on name resolution - 11/5 through 11/8) Gord - could writeup his portion for Monday (waiting on local:: proposal) Arturo - can a local:: reference cause a local import? Francoise - we have both import select and wildcard imports. What if use import select and not the wildcard import? Mike - can we refer to imported names as though they are local? Gordon - the only thing import select says is don't look in the class. It binds in the same way as anywhere else a bare name could appear. local:: just turns off the special rules for inline constraints. Otherwise we would need a whole set of special rules for this. Francoise - local::a first looks in current scope and then outer scope? Then would look into the class? Gord - no - we never look into the class when using local:: Mike - can we also use local:: with a hierarchical path? Gord - yes. Ray - can only use local:: inside an inline constraint (not in a regular constraint) AI/Arturo - upload a separate file for local:: to mantis 1858 (Dec 10th) 2164: changing parent to base in several places in the LRM Arturo: removes parents from some place, Gord: no objection to those changes Arturo: do we have nomenclature for derived or sub-class. Move: Mike Burns - Approve the proposal for Mantis item 2164 Second: Cliff Abstain: None Opposed: None Passed unanimously 2149 override of sample method (passing in arguments) David S - didn't like the use of @ in the syntax Mike - doesn't care if we have @ or not Gord - it means there is no implicit sampling in this case. it is opposite of what @ usually implies. would be willing to accept @ but he doesn't like it David S - use word 'with' in place of @ Mike - the word 'with' would only show up in the covergroup declaration Arturo - if move the declaration of sample inside the cg there are several issues. (eg. more than one allowed?, overrideable?, appears first?) Gord - "The formal arguments of an overridden sample method belong to the same scope as the formal arguments to the covergroup" This is a bit strange. Arturo - no hierarchical names - covergroups are dynamic It could be changed to say "lexical scope" Move: Mike Burns - approve the proposal for 2149 with two friendly amendments (@-->with, add word lexical) Second: Heath Abstain: None Opposed: None Passed unanimously 1447 - multidimensional arrays Mike - went through Neil's feedback and has been rewriting the proposal. Some of the problems seem to be due to the merge. - multidim arrays - refers to it as a singular object as opposed to an array of arrays. - he would like to refer to as an array of arrays. Gord - svbc has already started to move to the array of arrays approach Mike - dynamic dimension - will pare down what he will put up for a vote. There is too much there right now to get it all through. - nets not allowed in dynamic arrays or associative arrays Arturo - no, a net is not a type it is a property Mike - if resize a dynamic array, is a ref to an element outdated? Dave - whenever resize a dynamic array, the refs get outdated. Mike - packed vs unpacked - assignment compatible? Francoise - no they are not. Gord - that would only be true if it were bit-streamed out and back in. Mike - assigning to a fixed sized unpacked array from a dynamic (both need to be same size) a runtime check. Arturo - yes, that is correct. Neil: there is one spot that is an enhancement. AI/Mike - try to get portions of it into the email vote (ecd 12/10) 1702 queues Mehdi - Jonathan is not on the call today (he wrote the proposal) Dave - based on user responses from last week there was a user consensus Neil - the current proposal says the refs are outdated? Dave - yes Gord - the concatenation form will always outdate any refs into the queue Cliff - "When any form of assignment updates a queue, references to any element of the original queue shall become outdated." This seems to be a bit overkill. Shouldn't it be clarified? Gord - difference between a ref to box value and the value in the box. Mike - a variable that references a bunch of variables, and they have values. Gord - assigns change values but don't change the queue itself. Fracoise - Proposed clarification: "When the target of an assignment is an entire queue, references to any elements become outdated after the assignment." Cliff - wants to replace up to the comma on existing sentence. Gord - it doesn't clarify other cases (slices - this is a value assign) Arturo - could use language similar to dynamic arrays in 7.5.1 Cliff - it appears that some of the examples that Gord gave are not discussed in the current proposal. Gord - assign to a slice is different from manipulation of queue values, which is what the methods do. Would like to have this in the proposal. Mike - Assignments to a slice don't cause references to go out of date. Gord - What happens if the assign extends beyond the current range by 1? Appending to the q. If use a slice assignment plus adding one element would not outdate references. Slice on LHS don't get outdated refs. Even true if the slice is equivalent to value assignment plus an append. Dave - when using a slice syntax you can't update the queue. Only the values are updated. Can't change size of a queue by indexing out of bounds. Arturo - when assigning to a whole queue it is allowed, but not to a slice Gord - for a queue with 10 elements. q[11] = 5; // when q has 10 elements - invalid [Re: Arturo] Dave - no, that is not valid. Arturo - he checked the LRM during the meeting, it isn't valid. Gord - q[$+1] = 5; // legal - because $ is a special case. This is the case that Gord was thinking about. Mehdi - q[$+3] = 5; // illegal - invalid reference (can only have $+1) Gord - $+1 as a special syntax is odd. we are allowed to index beyond the queue only by 1. Mike - should be allowed to index beyond length by 1 using any expression. Gord - would be glad to get rid of it ($+1). Arturo - striking it would make things simpler. Cliff - what about current users? Gord - more concerned about slicing issues moving forward. - there will be a backward compatibility issue for some users. Will need to support those users if they use this special syntax. Mehdi - do we need to change a different section of LRM? Dave - the Champions may end up kicking it back to the sv-ec. From: "When any form of assignment updates a queue, references to any element of the original queue shall become outdated." To: "When the target of an assignment is an entire queue, references to any element of the original queue shall become outdated." Move: Dave Rich - Approve the proposal for Mantis item 1702 with Francoise's friendly amendment. Second: Arturo Abstain: None Opposed: None Passed unanimously 1714: mailbox issue Neil: can be reviewed later. Dave: can't extend a mailbox class today Arturo - yes, that is true, can't extend and override the behavior. Gord - can't refer to the element type (typeless) Arturo - could write a method that returns some information to allow the type to be determined. Dave - the value of a typeless mailbox is diminished since we now have parameterized classes. Arturo - a mailbox represents a heterogeneous list Gord - that is a weirdness, knowing how to unpack requires knowledge of all possible types of messages in use. Dave - have to know what to get out. Arturo - it is the basis of message passing, anything at the transaction level requires message passing. try_peek() exists today. Gord - that is only an effective strategy if types are not assignment compatible. Arturo - believes that is correct. - probably want to have a parameterized mailbox if want a tighter check. - can use one mailbox for one channel and another for another channel (each using a different message type). Dave - passing a variable number of arguments to a function. want something less strongly typed for that case. Less strongly checked. Gord - described as a parameterized type today in LRM. The untyped part is what is odd. Arturo - what are you trying to accomplish? Gord - being able to extend the mailbox. - today it is complete magic. Arturo - the type must be maintained as part of the message today. Dave - can probably only do an assign and a cast from the untyped. Arturo - people usually use containment not extension. Dave - the concept is similar to the assertion issue (Mantis 1601) Arturo - assertions are more like macros. Dave - mailbox doesn't really use dynamic typing. Need to have an actual type to get the data. only a type check by way of a dynamic cast (e.g. try_put) 5. Upcoming email vote --------------------------- EMAIL vote: 3-day approval period proposal Move: Neil - conduct a 3-day email starting Tuesday and ending Friday. Second: Cliff Abstain: None Opposed: None Passed unanimously Mantis items that Mehdi plans to place on an email vote: (starting Tuesday) 2183 2181 1584 2035 958 1447 AI/Mehdi - put the list of those related to 1702 up for closing in email vote. AI/Everyone - send list of items to add/delete from email vote to Mehdi. AI/Mehdi - call for an email vote on by Tuesday. 5. Next meetings: -------------- Monday December 17, 2007 continuation of Dec 10th meeting 1447: AI: Mike B will update the proposal, For next regular meeting. 1702 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 for 1702: Gord: we need to agree on, any assignment that uses {} form outdates all elements of the queue. Arturo: but if you concatenate then it is not. Gord: if that is identical behavior to pushback then need lots of work Mike: if DaveR: can we leave that as unsepcified. Gord: not an optimization, fundmaental Arturo: if you have asymetric assigment, then i can see the point, but the same size/queue on both sides, not that. MikeB: is there a problem with making go away. Arturo: if we go by Jonathan's normalization, you're going get lots of peopole use it. Cliff: have tauhgt both form, method and {} Stu: only teach the method form. Dave: the use model, queue without deleting any element, just add to it. Gord: if we want to narrowly define the {} and method operation, we can limit it. queues are not arrays, not contiguous dense array, rest of LRM talks about them as though it was an array. MikeB: lot more like C linked-list, Arturo: no not really. Gord: particular implementation of queues that has cauased this. Jonathan's proposal is not accepatable, sv-bc is not going to accept this as is Dave: is the only problem with references? Gord: in the absense of that it is indistiguishable. Don: pass a queue element by reference. MikeB: a case would be pass a reference and then do a pop-front, where is it Arturo: a reference is the real object or MikeB: to the list node. Gord: what happens now if you push-back ... Arturo: we can agree on a few things. what is a queue. homogeneous elements of contiguous. Gord: am not sure Jonathan will be happy with that, Arturo: MikeB.: methods only let you do one element at a time. Steven: maybe it is reasonable to add methods for concatenation. it is flexible, you have problems with references. MikeB.: it is not clear to me that the references are in-validated. Gord: outdated, when you have a ref to for example q[5], and then you do concatenation, at that point q[5] will not get to the same reference of the same q[5] place, the value is there. MikeB: two reasons, performance (large amount), and also retrun value. Gord: if only, this form of {} operations. MikeB.: going out of date is not a major issue, there is a big mess, apart from outdating issue lots of important issues in this proposal. i can accept what Jonathan has now, Dave: i have a problem with the requirement of saying it is outdated. Gord: problem is that if you want to define it that way you will open concatenate dynamic array with one new element, it is tough. Gord: if you do not like it write your own class. Arturo: write your own class. take what BC has done, Gord: most reasonable folks about outdated references is fine. Arturo: two issues, seaparte issues: concat form and outdated references Gord: do not have any problem with out-date ref and method form, but concat form is separate, do not have a problem with method Cliff: do you want to obsolete the concat form? Arturo: obsoleting some of the side-effects, the out-dated references Gord: Jonathan has mentioned it. the other comment would be struck. Steven: Gord: it is ok to have the method and concat behave different with respect to out-dated references? Dave: forcing them is a problem. MikeB: outdated reference to a queue member, it has specific value. Gord: it is specified to be different, MikeB: that issue needs to be decided, always to be different or you can not rely on how it behaves. Dave: like to say it is not rely on how behaves Gord: if peopole are ok with leaving it undefined. email discussion on the reflector, undefined or specific behavior MikeB: would it be just queue assignement concat. if you assign to queue you invalidate the ref. Gord: any assignment to a queue is not specified. Dave: send out the item to the reflector 974 2164 Use "base class" instead of "parent class" in 8.12 [assigned: Arturo] 1714 singular type as the mailbox default 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 5. Review mantis items with proposals ---------------------------------------------------- 2113 Inconsistency in constraining assoc array size 2137 2181 Ambiguity in implicit declaration of production variables in randsequence 2183 http://www.eda-stds.org/svdb/view.php?id=2181 6. Next meetings: -------------------------------- Monday December 10 2007 Monday December 17 2007 -- continuation of December 10 2007 meeting Move: Gord - approve 2214 Second: Mark Abstain: None Opposed: None Passed unanimously 1857 external method definitions and parameterized class types Gord: The second statement, indication function, is not meaningful. Jonathan: we can remove it and still is ok. Maybe we can add a comment. Cliff: adding one more function definitino with real type would be useful. Move: Gord - approve 1857 with friendly amendments Second: Neil Abstain: None Opposed: None Passed unanimously 2211: typedefs are required for some type references 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, 1043, 1832, 1508, 1516, 1858, 1583] 1809 Francoise: Cadence does not like the import of, will be writing a proposal. 1858: inline constraints. leave it for next time. Gord: the other ones are covered, or need proposals or are BC issues. 1702 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 1702: Jonathan: formal definition for concatenation. 1447, Close: 801, Stu: any reason to not use the Jonathan: if you have two nested, without ' Steven: how about one or two element. in assignment pattern, do the first element first. one of the assignment to the union, it acts as the first element. Stu: first assignment to the union name, it takes the first assignment ` to the union. Gord: Tagged unions are discussed. Jonathan: I would be happy to disallow union usage inside these. you need this for the simple cases. Steven: taking a queue and dividing it and assigning it to the next the queue, if there is a copy or not and what we need to do for this. Dave: look for outdated references, discussing something similar to this. section 13.5.2, steven: Dave: in superlog there were no method in queue. Jonathan: did the opportunity to create multiple copies of queues exist? all the standard operation can be done with the methods. 1447: multi-dimensional array. Cliff: assumption is these are closed 2164 Use "base class" instead of "parent class" in 8.12 [assigned: Arturo] 1714 singular type as the mailbox default Dave: mailbox is built in class, if you wanted to extend it, no way to refer to this default value. something should be deprecated. Gord: the way it is described in. Steven: if you want to put a type in this,you would use a tagged union. Dave: depracate the default mailbox parameterized type. Gord: mailbox, magic dynamic singular type as its default., mailbox Stu: bulit-in mailbox can not be inherited. Steven: mailbox can not be extended. Neil: pass a handle through a mailbox. 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 2164 Use "base class" instead of "parent class" in 8.12 [assigned: Arturo] 1714 singular type as the mailbox default 1447 (detailed proposal, fixed up for D4). as part of email vote with Queue. 1584 defaults in virtual methods Gord: arturo and gord are discussing these. 2035 class methods with static lifetime. ( go at the end) 958 dynamic array size method unclear when empty 974 comparison of dynamic arrays/queues to 1-dimensional fixed arrays with 1447. send an email for continuation of meeting today at December 3rd. 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 ======================================================================== http://standards.ieee.org/board/pat/pat-slideset.ppt http://www.eda-stds.org/sv-ec/Minutes/SV-EC_p1800_2008_Draft3_list.txt Note: the meeting time/date is updated on the web: http://www.eda-stds.org/sv-ec/Minutes.html hi Mehdi I've already taken the liberty of marking a large number of old Mantis items, relating to queue syntax, as children of 1702. The idea is that we should aim to close all of them, if everyone's happy that 1702 addresses all their concerns. You may wish to put this on the agenda for the Nov-26 meeting. The items I'd like to see closed, on the grounds that they are subsumed in 1702, are: 412 516-522 inclusive 801 974 Note that closing these items would not be in any way a vote in favour of the current proposal for 1702, but would merely acknowledge that 1702 covers all the concerns of these items. Thanks -- Jonathan Bromley, Consultant