SV-EC Committee Meeting Monday July 9 2007 11:00am - 1:00pm PST With the new calculations for voting rights below... 3/4 rule = 0.75 * 23 = 16 Meeting number: -------------- 00000000000000000000000 00000000011111111112222 12345678901234567890123 Meeting Days: ------------- (12120202010202010131120) Day (48159360488250595604159) (00001111110000000000000) Month (88990011221122334445667) (00000000000000000000000) Year (66666666667777777777777) ------ Attendees --------- (-AAAAAAAAAAAAAAAAA-AAAA) Arturo Salz 21 (--AAA-AAAAAAA-AAAAAAAAA) Cliff Cummings 19 (AAAAAAA-AAAAAAAAAAAAAAA) Dave Rich 22 (AA-A-AAA-AAAAAAA---AAAA) Francoise Martinolle 17 (-AAAAAAAAAAAAAAAAAAA-AA) Mehdi Mohtashemi 20 (AAAAAAAAAAAAAAAAAAAAAA-) Neil Korpusik 22 (AAAAAAAAAA-AAAAAAAAAAAA) Ray Ryan 22 (AAAAAAAAAAAA-AAA---AAA-) Gordon Vreugdenhil 18 (AAAAAA--AAAAA-A--AAAAAA) Steven Sharp 18 (--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 (-AAAA--AAAA-A-AAAAA-AAA) Heath Chambers 17 (-AAAAAA-A----AAAAAAAAA-) Don Mills 17 (--AA--A---A-AAA--A-AAAA) Jonathan Bromley 12 (--A--------------------) Logie Ramachandran 01 - No voting rights (----AAA----------------) Melvin Cardoza 03 - No voting rights (-----A-AAAAAA-AAAAAAAAA) Mark Hartoog 16 (-------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-AA) Mike Mintz 06 (------------------AAAAA) Geoffrey Coram 05 (-------------------AAAA) David Scott - Mentor 04 16 people (other than the chair) currently have voting rights ** Minutes taken by Jonathan Bromley and Mehdi Mothashemi ////////////////// July 9, 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: Mark Abstain: None Opposed: None Passed unanimously 2. Review meeting minutes/Notes: -------------------------------- http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_June_25_2007_Minutes.txt Move: Cliff - approve meeting minutes of June 25th 2007 Second: Heath Abstain: None Opposed: none Passed The number to call for the meeting is always on the agenda. The minutes of last meetings are on the sv-ec Minutes site along with the assignments of sections of the merged LRM list. http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_June_11_2007_Minutes.txt http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_May_14_2007_Minutes.txt http://www.eda-stds.org/sv-ec/Minutes/SV-EC_Meeting_April_30_2007_Minutes.txt 3. p1800 wg meeting on july 12th (discussion) Mehdi: Meeting, to discuss funding and LRM edits, is scheduled for 12 July. Further meetings thru Jan.2008 already scheduled. Françoise: What will happen to Mantis items recently passed by sv-ec? Mehdi: Don't know about individual items, but they WILL be reviewed, controversial items to be passed to champions. Dave: No champions meetings until Aug.15, then Aug.30 they vote on the next batch of Mantis items - anything we want to go into 1800 draft 4 needs to be with champions by Aug.1 Mehdi: Mantis items passed up to end Nov.2006, and 890, have already gone into draft 3; nothing since. The next sv-ec meeting is our last chance to approve other Mantis items in time for draft 4. 4. Discussion on Merged LRM 1800-2008 Draft3 Everyone is urged to review their sections of the merged LRM. http://www.eda-stds.org/sv-ec/Minutes/SV-EC_p1800_2008_Draft3_list.txt 5. Review mantis items with proposals 1623 was re-opened, timeout verbosity Heath: From the changes to 1462 which was closed by sv-bc changes 1462. 1462 is then closed by sv-bc. Add syntax "timeunit 10ns / 100ps;" to reduce verbosity; rationalize BNF syntax for timeunit, timeprecision. Proposal has been renumbered and reworded to fit draft 3a, see file mantis1623_D3.pdf Brief discussion revisiting choice of separator "/" or "," "/" is OK, matches `timescale, but means that future enhancement to allow expressions for time values would need to be in parentheses. Ray: why only / and not other mathematical operators. all the other tokens did not work Steve: more convenient to cut and paste. Heath: there may have been some objection to , most everyone liked the / operator. Cliff: / is more intuitive. Move: Heath - re-approve 1623 with the latest proposal. Second: Cliff Abstain: None Opposed: none Passed 1707: and 1384 discussed togther: * 1707: clarification of streaming operator * 1384: local/protected members in bitstream and streaming operator Needs re-write for Draft3a of the merged LRM. Taken toegther because they both affect the same LRM text. Jonathan has uploaded a new proposal. Jonathan: not received any feedback on this yet. clarifying the syntax of concatenation of streaming. Separate out the concatenation into single stream and the act of slicing it. Dave: we may have to review it next time. Need to define the result of stripped expression. Jonathan: Null class handle, you have a choice of issuing error. If not able to be bit-streamed, would you issue an error? (for example real) Tagged unions for example also not able to stream. Francoise: Why not Tagged-union? Jonathan: Tag is not accessible data object, unpacking it will be an issue. Arturo: you can stream it, but unpacking is a problem, non-symmetrical. Francoise: LRM does not define the encoding the tag? Arturo: the size and the location of the tag is defined. Jonathan: Is it similar to assigning tag to the tagged union. Arturo: what if you tag a wrong thing to tagged object. Asymetrical, so it is Real and Tagged Union types as being outside of this. Françoise: are strings OK to stream? Jonathan: strings count as bit-streamed type. Dave: original intent was to build concatenation of items that need be streamed, using pack/unpack function. Arturo: what is new in the proposal vs. LRM? Jonathan: the writeup is new, not the intent. Intent was to describe effect as a two-step process, but result of first step is never visible, so tools can implement any way they wish that gives the same effect. Arturo: does Jonathan's proposal forbid the use of a streaming_concatenation as an argument to another? Jonathan: that wasn't the intent, but will clarify the wording. Will also attempt to tighten wording around "skipped". General agreement it's OK to forbid streaming of reals and tagged unions. Must a tool follow the two-step streaming implied by Jonathan's proposal? AI: Jonathan General agreement to postpone until next meeting so people can review more carefully. Dave Rich to revise 1384 to fit draft 3a for next meeting. AI: Dave will do the re-write for draft3a. 1857 for email vote? Gord has provided a proposal and some email discussion. In Gord's absence, postpone to next meeting. Arturo: I think we would like to discuss this in the meeting. 1608 equality, inequality and conditional operator rules for class handles [ also mentioned 1594 as related item] Francoise: just refernces to draf3a, and bullets were re-alligned to fix the indentation. Cliff: last bullet, are we ok with 'closest common parent class' ? Francoise: the closest class type in the heirarchy than new. Arturo: compatible with the other class Jonathan: common parent should be sufficient. Arturo: If comparing two class handles of different type even if they have same parent, the comparsion will be false. Jonathan: this is not that comparison. Francoise: you have to chose what the result expression is. Ray: is it not Null defined that it is allways assignable. Type of null allows that. Francoise: can it be assigned to other than class. Arturo: yes, it can be assigend to events, etc. Francoise: How about arrays with null? Ray: Why would closest important? Arturo: It should not be. Ray: Null in any other context, null would not be cast to the types. It may have been the class heirarchy, type of null would be root class if such thing existed. Would there be a case that this gets implemented it would place more restriction. Heath: Null should not have a type cast anywhere. Mike: if null on both sides of comparison would that be valid? Jonathan: what if a type operator asks for the expression. Ray: what would type operator give to Null? Arturo: It is ambigious. Steven: if you're selecting the type of class handle. the expression is done statically, not at run time. Require the result type be assignment compatible. Arturo: the description is overkill for this. Steven: what if neither type is assignment compatible. is it automatically cast to the closest assingment compatilbe. you can forget the null case. Francoise: we may need to add the case for the null expression. Steven: the literal null does not contribute to the type, only has a handle. If a conditional operator, true is class handle and false is null, the type is the class handle, not null. If both are null then there is no type, literal null, type-less item. Ray: the type is first figured out. Jonathan: The third bullet, you need to factor in that if one is literal null the other type is cast. Steven: It would be literal null and no type. Same rules as null would have at that point, no type from either of the operands. Inside an expression that has the actual class handle, at that time it would get mapped. Comparisons cases would have true/false result, the conditional is only that would have return type. Ray: the bullet that gives you type of the result has to define which one is chosen. Regardless of ambigity the result type has to be chosen. Jonathan: either two class handles are identical you return that type, if not identical, the value null is returned. It will be easier once it talks about statically determined type. Francoise: will update with the bullet about what the resulting type will be. AI: Francoise: update it for next time to reword proposal to define "nearest common parent" more clearly, re-word to take account of today's discussion, and (if possible) update 1594 1715 Triggered property of a clocking block Jonathan: would like to close it though, there are workarounds that implement what he needs Arturo: you are suggesting name of clocking block. triggered Steven: Have not looked at any ramifications on this. Inside clocking block, if you have variable called triggered it would be error. Jonathan: if that is the case it is syntax error. Name of the clocking block, stands for an event. Steven: the name of the clocking block is also name of the event if used in that context. Jonathan: you can always create an event off of it and pass it around. General agreement that it would be good if possible to make clocking block name usable like any other event. AI: Jonathan would write up a new proposal on this 1715. 1858: use of item. in inline constraints to force resolution of member names into the target object Mark: Gord originally filed this, but Mark is working with Arturo to finalize a proposal - hard to find time to work together. AI: Mark H and Arturo, write up by July 23rd. 1500: restriction on uses of forward typedef Mark: this is tied in with name resolution in classes. Jonathan: issue with type parameter Mark: issue with type parameter as a base class. The problems with forward typedef will be 'minor'. Language issue, we have to decide to see if we have to introduce complexity on this Arturo: having generic base classes, complex, not sure if it provides any thing of a value. Ray: some discussion used as test methodology, not sure if it is a good idea. Arturo: would like to see an example. Ray: the section reviewed would be 6.18 Mark: if we are comfortable with ruling out 'type parameters for base classes'. Ray: that is much less restriction than saying that forward typedef can be used for classes. Mark: what would happen if static method call into the typedef base classes. The type-resolution. Dave: problem is with name binding. reference to variable of derived class you do not have visibility to that, you do not know where to bind to. Francoise: recursive definition is the only thing that would be usefull. Dave: Matt mentioned forward typedef of struct in their design. Francoise: Why? Mark: he may have things placed in multiple include files. to accomadate everyone then forward typedef. Ray: one example in the LRM is for an int. Dave: the name resolution has to be fixed before this. Real restriction on the 1858. Mark: what exactly was the intent of 1500. Arturo: intent was only classes can create self-referencial. It maybe a backward compatiblity issue. Françoise: should we make BC aware of 1500 implications? Mark: yes, could be serious back-compatibility trouble with existing code that uses forward typedef to non-class things. Dave: there were some issues that you did not know that it was a base class or not. Mark: any typed parameter do not know if it is a class or not. Mike: often uses forward typedef in C++ to hide implementation details - but only for pointers to classes Dave: name resolution should resolve these items. need to fix name resolution issues before we can make much progress on this. Mark: we clearley need to know what results are typed and what are not typed. c++ has some type-named syntax. SV type operator can allow us to get around lexical operator, syntax is already there. Ray: even the . syntax, allowed for other things that are not class Mark: any unpacked array you can apply the . method for it. special name Jonathan: those names are not reserved words. AI: Mehdi to discuss this with Gord. 1871: clarify illegal and ignore transition coverage bins David: in covergroups, ignored or illegabl bins, language specific to state bins not transition bins. The or transition language is not clear. Jonathan: the word invalidate, is it precise engough?, coverage bin will not do anything Ray: it removes it from the bin. illegal bin removes the transition from the coverage bin. David: the language is the same in both area. could chose different wording. Ray: only invalidates the transition not the bin. also later in the same sentence. invalidate ---> removes Arturo: sequence that is contained in other sequence, Ray: the other sequence can not be met with out having the other sequence. AI David Scott: get the proposal ready with three changes for next time's vote. 6. Discussion: mantis items with no proposal 7. Next meeting: July 23rd 2007 Aug 6th 2007