SV-EC committee meeting. Monday December 6 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_6_2010_Minutes.txt ] Meeting number: 75% = 8 out of 11 meetings attended ------------------------------------------------------------------------- 11000000000 10987654321 Meeting Days: ------------------------------------------------------------------------ (02021213101) Day (62851730629) (11111000000) Month (21100998887) (11111111111) Year (00000000000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAAAAAA) Arturo Salz 11 - y 2. (AAAAAAAA-AA) Dave Rich 10 - y 3. (AAAA--AAAAA) Francoise Martinolle 9 - y (75% attendance) 4. (AAAAAAAAAAA) Mehdi Mohtashemi 11 - y 5. (AAAAAAAAAAA) Neil Korpusik 11 - y 6. (AAAAAAAAAAA) Ray Ryan 11 - y 7. (AAAA-AAAAAA) Gordon Vreugdenhil 10 - y 8. (A-AAAAAAAAA) Steven Sharp 10 - y 9. (AAA---A--AA) Heath Chambers 6 - y (2 of last 3) 10. (--AA----AAA) Don Mills 5 - 11. (AAAAAAAAAAA) Mark Hartoog 11 - y 12. (AAAAAAAAA-A) Tom Alsop 10 - y 13. (-AAAAAAAAAA) Jonathan Bromley 10 - y 14. (AA--AAAA--A) Neil S 7 - y (2 of last 3) 15. (----A-AAAAA) Cliff Cummings 6 16. (AAAAAA-A--A) Alex Gran 8 - y (2 of last 3) 17. (---A-AAAAAA) Daniel Schostak 7 18. (------AAAAA) Swapnajit Chakraborti 5 19. (-AA-AAAA---) Linc Jepson 6 - y (2 of last 3) 20. (AAAA-------) Tony Tsai 4 - y (2 of last 3) 21. (AA-A-------) Brandon Tipp 3 - y (2 of last 3) 22. (-A---------) John Halvicek 1 23. (AA---------) Scott Little 2 - y (2 of last 3) 24. (A----------) Dave Gates 1 AMD 25. (A----------) Mark Strickland 1 Cisco 18 people will have voting rights in the next meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// December 6 2010 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Heath Second: Neil S. Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meetings minutes: ------------------------------------------------------ November 8 2010 meeting http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_8_2010_Minutes.txt Move: Gord Second: Francoise Abstain: Opposed: Passed/approved unanimously November 22 2010 meeting minutes [not uploaded yet, next time] 3. Updates from P1800 WG --------------------------------------------------------------------------- Participation and voting guidelines, other updates. Next meeting is on December 9 2010 Neil: I will send you update for last month, suspended the 18th. 3.1 election for chair and co-chair Dave Rich nominated Mehdi and Neil [chair and co-chair] Second: Neil S. Abstain: None Opposed: None Passed/approved unanimously 4. Continue Review and discussion of top 25 issues and categories: ------------------------------------------------------ Review of the top 25 [+10] started last meeting, 1 through 12th were discussed. Will continue with the list below. 3230 from SVBC to review by the committee 2505 class select: what is allowed after the dot? Neil S. - the only change was for the enum example Steven - enum names are legal constant expressions. Move: Steven, approve proposal for mantis 2505 Second: Gordon Abstain: Opposed: Passed/approved unanimously 2845 virtual interface type checking versus interface type that had been defparam'ed Francoise - 2845 version 1, .pdf Gord - had a concern if there was a defparam to only one sub-instance. - What is in the proposal might be stronger than is needed. We could relax it later. Mark - defparams into interfaces are not defined. Francoise - every interface instance needs to be checked. Gord - prefers to change it to be less restrictive Francoise - would need to just say interface instance Steven - an interface instance that has a defparam to it or any of its sub-instances is not compatible. (Can't be assigned to a virtual interface). Neil - the term "sub-instance" doesn't seem to be in the LRM. Steven - There is terminology in the defparam section referring to hierarchy. We may want to refer to hierarchy and not sub-instances. AI/Francoise - update the proposal with these changes. 2848 Is it legal to assign an interface containing class declaration to a virtual interface Francoise - Redid the text based on discussion in our last conference call Gord - if defined the class within the interface, it is a different type for each instance. Steven - would like it to be rewritten such that it is more clear that the declaration is within the interface. - packed struct was not mentioned in the text. AI/Francoise - update the proposal 1356 Interface Classes [Multiple inheritance] 2506 Coverage Scott: put it to the PDF format, and polish. Neil: new text in blue, strike-through. 1356 Interface Classes [Multiple inheritance] Tom - type usage restrictions Is an interface class a first class type? Can an interface class type be used as a parameter? - can we use a type parameter? - Interface class type being used a a parameter value. Brandon and Tom were thinking it shouldn't be allowed. Gord - Not an issues of implementation and use, more a question of having full visability when implementing Consensus on that was yes you do. Need the definition of IC at the point of implements. - can't name a type parameter as something you are implementing. Steven - you need to be able to look at what you are implementing. Can't wait until elaboration. Brandon - can you have a forward typedef? typedef foo bar implements foo Gord - what is the benfit of allowing it? Brandon - it simplifies compilation. Gord - the type which resolves it must be in the same scope. Brandon - it would be in the same compilation scope. The typedef just eliminates any ordering issues. Gord - that is probably not the best way of designing it. - SystemVerilog doesn't distinguish between type parameters and ... - For this construct we need to denote an immediately visible... - typedef, type parameter, class declartion -- new distinction That is not currently in the LRM. - in the typedef construct need to be careful about what it resolves to. Steven - if restrict to a class, you know there aren't any type parameters Gord - if allow typedef here, there are issues to be addressed. Steven - at the parsing stage it must not be a type parameter. Gord - need to invent a way to describe this. Scoping name resolution, elaboration are in the lrm today. This is different. Gord - universe of type happens very late in the process. - diamond shapes could be an issue if done late. Steven - extends from an implemnents. If have to defer checking we wouldn't know... Francoise - a fwd typedef is ok, Gord - the lrm admits various cut points. This doesn't map into one of them. Steven - parsing, multiple passes are typeically required. - "compilation" Steven - typedef class not typedef typedef class. Gord - could say allowed to implement a class name or a class specialization or a typedef that resolves to a class definition. - Could use a type parameter here. - first level obvious examples are trivial. Could restrict it to that and not allow other scenarios. Steven - want to restrict it from going through a type parameter. Gord - forward typedef for c class b then typedef b c - for implements, could limit it to a class definition for c Steven - typedef for a type parameter... (want to disallow) Gord - any use of a type parameter used in the construction of that type is a problem. - There are various sideways compilation ways to do that. we would like to prevent all of them. Steven - It isn't simple to describe. Gord - in interface classes most likely will need to disallow a type parameter there. Brandon - agrees with it. Gord - there are a lot of interacting things going on here. - don't want elaboration requirements on determination of interface class relationships (interface class structure). - as soon as there is a type parameter, things get pushed out to elaboration time. Steven - by the time reach the end of the scope, should be able to see everything that is in the class. AI/Tom - update the proposal with some of the issues being raised. AI/all - review the new proposal before the next meeting. Tom - moving on to nested Interface Classes (ICs) - can an IC be nested within other classes? can other classes be nested within an IC? Mehdi - how is the 2nd one useful? Brandon - if the return type is a ... Grod - a concrete return value from a method within a class - A lot of these could be useful, but we might not want to allow all of it at once. - You can usually reach into a class using :: If an IC inside another class, if only for name scoping it might be ok, but some implications of it need to be worked out. It will most likely be a significant set of rules, mult. inheritance, parameters, etc. It could be tractable with enough work, but would prefer to get other stuff done first, and then come back to these questions. Tom - he is ok with that approach. Tom - casting an IC type when null. - assuming it should be different from a normal class handle. Brandon - casting a null IC to something else. Gord - for literal null there is some agreement for a handle that is null, not sure there is agreement. How much do you pay attention to the type. - pre-existing questions most likely need to be addressed first. Brandon - most likely need to open a new mantis item for the pre-existing questions. Gord - need to answer those questions first. - the diamond situation complicates things. - non-null suggestion is trivial for non mult. inheritance case. - much more nasty for mult. inheritance case. - Need to first decide on the single-inheritance case. - Not sure he supports the single-inheritance case. All coercion with a Null in a handle. If there is a feasible value to be used, it could be reasonable. Don't allow casts to unrelated types. Not just a check on was it this type. Arturo - a static check? (yes) Gord - a static check on the relationship to see if it would allow null. - for MI, at time that look at this, the universe of convergence of type is more complex. the diamond type is a problem. The universe of possible solutions become much larger. Francoise- having a hard time following it. Mehdi - Jonathan had started the discussion on this, not sure if there was an example. Gord - class c, class b. - if completely independent the class it always illegal. Tom - check for polymorphic relationships. Gord - if class e implements c d - there is now a unifying type that goes across types. - Simpler to check in a single inheritance situation. Brandon - no static type checking of classes in a cast. it is dynamic today. casting c to d - will be checked at runtime. Francoise- it is a runtime check? Steven - the implementation could check statically and say mismatch at runtime. - $cast (dynamic casting) Steven - there are other feasible solutions for $cast for single inheritance Gord - if given a null and only allow it if static handle type is a super type of the target. This messes up up-cast(?) Steven - there are a number of solutions that could be reasonable for si Some of those become questionable for multiple inheritance Gord - not sure would support the "right" answer for single inheritance, when it comes to multiple inheritance. - for $cast where source handle represents non-literal null. Mehdi - Jonathan was going to create a new mantis item for this. - Gord has created two others as well. Tom - how resolve defaults in the diamond example. Steven - default argument values for methods in classes. Brandon - it is a mess... - they currently resolve to where the method was declared. Steven - there is another existing issue the defaults are allowed to differ. They go with the implementation. some said - the default should be known to the caller Some amy want them to be virtual. Different defaults could be thought of being a virtual thing. - They implemented them as being virtual. - No one was too interested in addressing it back then. Gord - is thinking the opposite way on this one. Steven - one capabilitiy - default values resolved in the scope of the declaration, thinks it was chosen to mean where it lexically appears. Can't refer to this, only inside a non-static method. Arturo - you could just pass null Gord - they have to all be effectivly constant. - if we tighten up on this , other things become easier. Steven - by putting in the method scope, you can use this. - resolving it to a particular symbol, which is the one in this implementation. If use a default in a method of a derived class and say a=b. The b is with regards to the derrived class. Can't use it in a reference to the method through the base vlass. This seems to be an arguement for treating is as virtual. Tom - It sounds like we should address these other mantis items first. Arturo - could limit to constants. That is usually the intent. Gord - if the constants are identical, doesn't matter which you get. - coudl avoid issue by saying all implemented clases must have the same values. Steven - Mantis 1584 is the old mantis item that is relevant here. Tom - we need to go through the other items and decide what the restrictions shoudl be. 2506 Coverage Scott - it is now in the pdf format - will use blue for new text and red with strike-outs for deleted. 5. Next meetings November and December 2010 ----------------------------------------------------- Monday December 13 2010 Special meeting [if required] Monday December 20 2010 -- NO MEETING Monday January 3 2011 -- NO MEETING Monday January 10 2011 Special meeting [if required] Monday January 17 2011 Regular biweekly Monday January 31 2011 Regular biweekly FOR References: --------------------------------------------------------------------- ============ from December 6 2010 meeting =================== AI: 2845 Francoise - update the proposal with these changes. AI: 2848 Francoise - update the proposal with these changes. AI: 1356 Tom - update the proposal with some of the issues being raised. AI: 1356 all - review the new proposal before the next meeting. ============ from November 22 2010 meeting =================== AI: 2848, 2845; Franocoise update the proposals. AI: 2505; Neil S., update the proposal. AI: 2506; put the proposal into the required format AI: everyone to review and be ready to discuss during next time. ============ from November 8 2010 meeting =================== AI: Minutes; Mehdi - will check for consistency between the left and right sides for the attendance. AI: for 1356 Multiple Inheritance (interface classes) Mehdi - will make a request to the WG on this. General statement about being allowed to work on mantis items that are affected. AI: Jonathan - NULL within $cast AI: Gord - the OVM people would like to have that. Covariant and Contravarianct type extensions. you allow method that do not allow exact type signature of over-written method, but can return the objects of the type of original return type, impact of that would be on Interface classes. AI: Gord - Overwriting of virtual method section AI: Tom - update the proposal (to number 4) ============ from October 25 2010 meeting =================== AI: 1356 Tom - update the proposal, make corrections and more normative text. All - provide more detailed feedback to Tom. ============ from October 11 2010 meeting =================== AI: related to 2505 All - should we allow enum constants to be accessed by the dot? AI: 2953 Mehdi - make 2953 a child of 2506 Mehdi - make a request in this week's P1800 meeting to work on 2506 AI: 2080, 1672, 802 Neil - update the mantis items (3 of them) AI: 251 Mehdi, leave mantis 251 open AI: 2794 Mehdi, reopen mantis item for feedback Jonathan: update AI: 2949 Jonathan: send email to Brad to get clarification on his feedback. ============ from September 27 2010 meeting =================== AI: 3003 Tom - will get feedback on specific examples. (see 18.7 for information on the with-clause) AI: 3003 Jonathan - will get an email discussion going. ============ from September 13 2010 meeting =================== AI: Coverage item Swapnajit - will provide a note for clarification, to be added to Mantis 1802 AI: Coverage item Swapnajit - will put together a proposal for this issue. [related to 19.5.3 wildcard specification] AI: 2848 Francoise - Will do a write-up for this proposal. AI: 2845 Francoise - will try to write-up for this. ============ from August 30 2010 meeting =================== AI:2956 Mehdi making a note to the editor for adding cross reference. AI: 2794 Jonathan will make the friendly amendment. AI:3028 Jonathan create a proposal and upload it for more discussion and vote next meeting. ============ from August 16 2010 meeting =================== AI: 3028 Jonathan - write up the parallel proposals. AI: 2794 Jonathan - add text for the case where indices are x, z AI: 1442 Steven - check if Shalom's comments make this issue moot. AI: 1349 Steven: create the proposal for 1349 AI: 2451 Steven put a proposal together. AI: 2993 Tom; will check internally to see if these meet their needs AI: 2993 Mehdi; upload the email as a note to the mantis item AI: 2993 Arturo; will donate their implementation. ============ from Aguust 2 2010 meeting =================== AI: 1706 Steven put together an email for bc to provide feedback on 4 options Mehdi can send to sv-bc AI: 2993 Swapnajit: add a note to the mantis item as to where we currently are in the process. AI: 2953 Ray - take a look at this one ============ from July 19 2010 meeting =================== AI:Tom get confirmation from users about exact intent of the original request for 3001 AI: Francoise will add a note to the mantis item 2848 AI: Gord will write up a proposal for 3046 AI: Ray will add a bugnote 2999 ============ from June 21 2010 meeting =================== AI/Mehdi - For number 30 on the list, 'no-mantis item 6' send email to Matt about linking this request to mantis 2991. AI/ALL - assigned leaders/champions to start looking at the top 25 items on the list and plan for proposals/discussions/reviews. ============ from June 7 2010 meeting =================== AI/Tom - some examples would be useful [mantis 2987, soft constraints] AI/Cliff - what is actually required. [mantis 2117] Allow extending of covergroups in classes AI/Cliff, John H. - more details on this request, item number 30 [no mantis 6: allow re-use of enumerated names (slide 31) AI/All - find mantis items that can be closed, or easily resolved. - any of the 0.5h estimate items could be considered as well. ============ from May 24 2010 meeting =================== AI/Tom and others: mantis 3002 AOP: any more clarifications from users perspective. AI/users: mantis 1356: Multiple inheritance:what are the particular requests? clarifications. AI/Tom - Mantis 3003, we need more clarification from user base ============ from May 10 2010 meeting =================== AI/Jonathan - create mantis items for No-Mantis-10. Completed action items: ============ from April 26 2010 meeting =================== AI/Mehdi - add a column for enhancement versus clarification AI/Mehdi - add a column for amount of work required. AI/Mehdi - add sheets for the various categores in the Google doc. AI/Mehdi - send out a link to the p1800 spreadsheet. AI/Mehdi - add a column for duplicates AI/All - send input on the list of categories. AI/ALL - until May 5th to provide any inputs on the spreadsheet. ============ from April 12 2010 meeting =================== AI/Mehdi - Look at the Google Docs and creaet spreadsheet for collaborative efforts. Also add cross committee column to the spreadsheet. AI/All - send inputs on any new items by April 24 2010, this is deadline for any item that is not already in the mantis database. AI/All - prioritize and categorize list of items that are in the spreadsheet to be reviewed during the next two sv-ec meetings. AI/Neil - email to cliff on proxy right --------------------------------------------- Summary table: Assigned Lead/Champions --------------------------------------------- 1 2848 Francoise 2 3002 Tom, Dave, Jonathan, Francoise, Arturo, Neil S., Cliff, Gord 3 3046 Gord, Franocise, Mark, Ray 4 1356 Tom [same with 3002] 5 3001 Jonathan, Tom, Francoise 6 2999 Tom, Ray, Arturo, 7 3003 [2987, 2988] Jonathan, Tom, Ray, Arturo, 8 3082 Daniel, Jonathan, 9 2845 Francoise, Mark, Alex Neil S., Gord? 10 2956 Steven, 11 2505 Neil S., Mark, Francoise 12 2735 Arturo, Steven, Gord, 13 1706 Mark, Steven, Francoise, 14 2488 Steven, Francoise, 15 2112 Dave, Steven, 16 3028 Arturo, Ray, Neil S., Mehdi, 17 2950 Francoise, 18 2794 Jonathan, Steven 19 2993 Tom, Ray, Swapnajit (cadence) 20 1442 Steven, 21 2953 Ray 22 1349 Steven 23 2949 Jonathan, Steven 24 2451 Steven, 25 2987 Jonathan (combining 2987, 2988, see 3003) ------------------------------------- [next 10] 26 3006 Ray, Steven, 27 3004 Tom 28 2998 Tom 29 2117 Cliff?? 30 No Mantis 6 could be linked with 2991 with sv-bc 31 2928 Ray, Arturo, 32 2787 ?? (Daniel)?? 33 2972 ?? (Daniel)?? 34 2996 Tom, 35 2988 already assigned (see 3003) 36 No Mantis 4 related to AOP (already covered) -------------------------------------------------------------- == List with estimates ======= hrs top 2t mantis Id 4 1 2848 12 2 3002 1 3 3046 16 4 1356 2 5 3001 3 6 2999 5 7 3003 8 8 3082 4 9 2845 0.5 10 2956 3 11 2505 4 12 2735 1 13 1706 2 14 2488 2 15 2112 2 16 3028 2 17 2950 1 18 2794 4 19 2993 0.5 20 1442 6 21 2953 0.5 22 1349 0.5 23 2949 4 24 2451 4 25 2987 92 total 46 (2hr sessions) 0.5 26 3006 4 27 3004 2 28 2998 4 29 2117 4 30 No Mantis 6 0.5 31 2928 4 32 2787 2 33 2972 2 34 2996 0 35 2988 0 36 No Mantis 4 23 total 11 sessions ====================================== top 25 Id Number of Votes weighted vote Summary Degrees of difficulty Cateogory Sub-Category 1 2848 7 159 Is it legal to assign an interface containing class declaration to a virtual interface med Virtual Interface and class 2 3002 8 125 Aspect Oriented Programming (AOP) features High class constraints 3 3046 8 112 Dotted names within inlined constraints Low class Strings/Arrays 4 1356 6 112 Multiple Inheritance High class Strings 5 3001 9 102 Proper Polymorphic behavior of instantiation low class Arrays 6 2999 7 99 Class Handle reference inside of Constraints med class constraints 7 3003 6 98 Constraint Composition High Randomization Strings 8 3082 7 96 (4) Ambiguity resolution (see slide 10 for examples of parts of the Standard that have been interpreted differently by different simulators) 9 2845 4 84 virtual interface type checking versus interface type that had been defparam'ed high Virtual Interface Misc / function proto 10 2956 4 76 clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5) low Process control 11 2505 4 76 class select: what is allowed after the dot? low class 12 2735 4 73 Ballot Comment #48: Chaining of method calls med class constraints 13 1706 4 72 Meaning of static prefix for virtual interface assignments Virtual Interfaces 14 2488 4 69 Are virtual method calls legal within class constructors? med VI OO classes 15 2112 6 69 Remove restrictions on NBA assigments to class members med class constraints 16 3028 6 68 constraints for unique array elements. Med Randomization 17 2950 4 67 virtual method prototype matching low class 18 2794 4 64 Clarify queue methods return status low class 19 2993 4 63 Cross cover points across different cover groups med Built-in Methods 20 1442 3 63 Clocking blocks legal in modports, missing from text description in 20.9 Functional Coverage 21 2953 6 61 Algorithmic generation of covergroup bin contents high clocking block 22 1349 5 61 fork/join_none: what if parent thread terminates without blocking statement? Functional Coverage 23 2949 4 60 LRM is silent about the semantics of referencing a clocking block output low Process control constraints 24 2451 6 58 Omitting body defaults med clocking block constraints 25 2987 6 56 Soft Constraints med class Misc / function proto 26 3006 5 55 LRM doesn't say explicitly what should happen if null pointer is randomized low class Data Types 27 3004 5 55 Ability to declare/qualify classes/methods/variables/constraints final med class Virtual Interface 28 2998 4 55 Solve Before enhanced low Randomization class 29 2117 3 52 Allow extending of covergroups in classes high Functional Coverage class 30 No Mantis 6 5 51 (3) Allow reuse of enumerated names (slide 31) cross-committee Randomization 31 2928 3 50 ambiguous restriction on function calls in constraint expressions low Randomization Randomization 32 2787 3 50 reference via scope operator to parametrized superclass item med class Randomization 33 2972 3 49 add class constructor/method, task/function overloading High class Randomization 34 2996 4 49 Method overloading High class Randomization 35 2988 2 48 Defaults Constraints med Randomization Process control 36 No Mantis 4 2 47 (1) AOP when-inheritance (slide 31) Class/AOP Functional Coverage