SV-EC committee meeting. Monday January 17 2011 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_January_17_2011_Minutes.txt ] Meeting number: 75% = 9 out of 12 meetings attended ------------------------------------------------------------------------- 111000000000 210987654321 Meeting Days: ------------------------------------------------------------------------ (102021213101) Day (762851730629) (011111000000) Month (121100998887) (111111111111) Year (100000000000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAAAAAAA) Arturo Salz 12 - y 2. (AAAAAAAAA-AA) Dave Rich 11 - y 3. (AAAAA--AAAAA) Francoise Martinolle 10 - y 4. (AAAAAAAAAAAA) Mehdi Mohtashemi 12 - y 5. (AAAAAAAAAAAA) Neil Korpusik 12 - y 6. (-AAAAAAAAAAA) Ray Ryan 11 - y 7. (AAAAA-AAAAAA) Gordon Vreugdenhil 11 - y 8. (AA-AAAAAAAAA) Steven Sharp 11 - y 9. (-AAA---A--AA) Heath Chambers 6 - y (2 of last 3) 10. (A--AA----AAA) Don Mills 6 - 11. (AAAAAAAAAAAA) Mark Hartoog 12 - y 12. (AAAAAAAAAA-A) Tom Alsop 11 - y 13. (A-AAAAAAAAAA) Jonathan Bromley 11 - 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---A-AAAAAA) Daniel Schostak 8 18. (-------AAAAA) Swapnajit Chakraborti 5 19. (A-AA-AAAA---) Linc Jepson 6 - y (2 of last 3) 20. (-AAAA-------) Tony Tsai 4 - y (2 of last 3) 21. (AAA-A-------) Brandon Tipp 4 - y (2 of last 3) 22. (--A---------) John Halvicek 1 23. (AAA---------) Scott Little 3 - 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 ////////////////// January 17 2011 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Francoise Second: Mark Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meetings minutes: ------------------------------------------------------ November 22 2010 meeting http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_22_2010_Minutes.txt Move: Gord Second: Mark Abstain: Opposed: Passed/approved unanimously December 6 2010 meeting http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_December_6_2010_Minutes.txt [ Was uploaded today, it will be reviewed in the next meeting.] 3. Updates from P1800 WG --------------------------------------------------------------------------- Participation and voting guidelines, other updates. [meetings on Dec 9, 2010, January 13 2011] Neil: WG meeting 1/13/2011, it could be up to a year before FAQ arrives, we will continue as is, most likely same for our PAR part of problem is 'enforcement procedure' Gord: it has to be much more restrictive Neil: discussion about a new data base, may require login for everyone. Gord: Part of this is the standard. Mark: Distribution of the standard was always restrictive. Neil: September Feature freeze in the TC's. 31 Mantis items were approved by the WG (not yet updated) 25 + 6 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. 2845 virtual interface type checking versus interface type that had been defparam'ed Francoise - uploaded the corrected one, with feedback from last meeting, Jonathan - interface heirarchy -- is it defined any place in the LRM? - Dec 6th. defparam section was referred to in minutes(23.10.1). Mehdi - doesn't think it will be a problem Gordon - sv-bc is looking at interfaces, should we wait until bc finishes their pure interface, etc. - these may need to be undone in the future. Arturo - defparam has been deprecated, this might be a good reason for not making this change. - this proposal is attempting to disallow something related to a deprecated feature. Mehdi - the sv-bc work could change a lot of things, not just this. Move: Francoise accept 2845-v3.pdf proposal for this mantis Second: Jonathan Abstain: Gord, Arturo [no inherent objection, but this could potentially complicate sv-bc changes] [no inherent objection, this has to do with a deprecated syntax/feature] Opposed: Passed/approved [13 people were on line at the time of the vote] Arturo - given that defparam is deprecated, it would be undefined. Francoise - it isn't realistic to deprecate defparam - it is better to limit defparam to prevent further usage. 2848 Is it legal to assign an interface containing class declaration to a virtual interface Francoise - has updated the proposal to 2848-v3.pdf Jonathan - third sentence is not necessary. Mark - the 'containing' what does this mean, some concern about the proposal. Arturo - also thinks this is a mouthful. - if not used from outside, why is it illegal? Francoise - it doesn't matter, it still changes the type of the interface. Mark - that is debatable. Gord - agrees with Arturo in principle, there is no issue. - there would otherwise be possible issues defining what is a reachable view. It becomes a global problem, which might be determinable, but we would need to be very careful to define it. - Just talking about variables would not be sufficient. - what is in the proposal is very conservative. Mark - vendors won't be able to implement this restriction. It is too restrictive. Arturo - if nothing reaches into it, not a problem. - thinks it is a bad idea to define types inside interfaces which are to be used as a virtual interface. Gord - virtual interfaces move around. - a reference to a module is static. Mark - if declare a class in a module, with a variable, and there are multiple instances. - a hierarchical reference to each are not compatible. Gord - for the module case, can make that determination at elaboration time. For virtual interfaces we can't. Francoise - doesn't want a runtime check Gord - philosophically agrees with Arturo, Mark. - if all referenceable parts of the interface don't have this structural issue, it is ok. - there would be a fair amount of work required to get it right. Gord - interfaces could define interesting behavior. There could be classes within an interface for saving state, for example. Mark - this rule is so conservative it makes all uses of VI illegal. Francoise - no, has seen several examples that would continue to work. Mark - lots of people are using enums that aren't in packages. Gord - could define what is referenceable. (Mark, Arturo concern). - If someone wants to write up a set of rules along those lines we could go down that path. Mark - there is a difference between referenceable and actually used. Francoise - it would be complex to state what is allowed and what isn't. - not sure that it is the right thing to do in the first place. - need to take into account all potential access to that VI. Gord - that turns into a global problem. Couldn't do this check until all components become available. Mark - a hierarchical reference to a variable of a class defined in an module (similar issue) Mehdi - surprised there is so much discussion after our previous meetings on this same mantis item. Francoise - most of today's sv-bc meeting was devoted to interfaces Gord - 3 potential directions are being explored. - which direction to go in has not yet been decided. Mehdi - prefers to talk to Matt about this first... - we can come back to this later (maybe in a couple of months). AI: Mehdi - hold this off for the next 3 or 4 sessions. 1356 Interface Classes [Multiple inheritance] Tom - there is a list of 5 issues to close on (itemized below) - there are a couple of other mantis items that are now prerequisites to 1356. - The proposal was last updated on Oct 25th (1) Prerequisite mantis items. 3278 and 3279 (2) Type usage restrictions type arguments. - interface class T Don't allow implements of T in that class - Can't use a parameter as the specification of an 'implements' - typedef not allowed - if use 'implements' it must be a class. It can't be something that can change. - 8.25.2 Dave - "known at the point of reference" is some terminology that has been used before. - can rely on this terminology to disallow forward typedefs Mark - a forward typedef must resolve to a type. Dave - a similar type of rule is required here. Steven - forward typedef will tell you it is a type, but won't tell you if something is an interface class. Jonathan - we could extend typedef for an interface class Gord - the need is to ensure that the contract of the interface class is satisfied by the implements. - ok with a forward type. Brandon - would create a compile-order requirement, if don't allow typedef Arturo - this is the way that Java and C++ also work. Steven - might need to have the whole design available to do checking. Brandon - that seems like a useless thing to do. Not sure what contract will need to be fulfilled. Gord - forward typedefs across the whole design causes problems. - the various implementations split elaboration and compilation in different ways. It complicates the decision making process for things like this. Tom - it sounds like we should just not allow forward typedefs for this Gord - in the future, if there is a real need for it, we could possibly relax this restriction. - this construct is really not a first-class type given the way that we are describing it. Mark - extends type_parameter --- this is ok today implements type_parameter --- not allowed? (users will ask why) Gord - we may end up with a different set of rules for extends and implements. His sense is that we will end up with differences for them. (3) nested interface classes Tom - can they be nested or not? Gord - nested interface classes within an interface class... would need to be convinced that this is a true requirement. Would need to see a real use model that requires it. - a hugely complex set of interfaces for this. Why is this level of complexity required? Brandon - class and interface class permutations. - one inside another - The following two are open questions. IC in an IC Ic in a class Mark - original need for nested classes was to avoid polluting the name space (e.g. for java and C++). - Less of an issue for SystemVerilog since classes tend to end up in packages. Gord - from an abstraction perspective, would like be able to define within a class to encapsulate it. Tends to be much less of a concern to SVTB use models. Steven - the outer class could be parameterized - the nested class could then use those parameters without being parameterized itself. Tom - IC in a class? -- is this still an option? Gord - could come up with a reason to want it, but not sure that we want it initially. - already have to deal with coverage, visibility, types, etc. Prefer to keep new complexity down. - prefers to not allow anything to be nested in an IC. Steven - disallow the 3 new combinations? Arturo - a nested class in the implementation should be allowed. Gord - yes. Francoise - it is what is already allowed today. Tom - for now, will only allow a class nested within another class AI: Tom/Team state the differences between extensions and inheritance. (4) Casting of interface types Needs a new mantis Mehdi - see 3293 "Clarify $cast behaviour on class handles" (5) Diamond pattern Brandon - default values for arguments Steven - there are issues with the use of default values for base class versus the derived class - there is an existing mantis item on this - see mantis 1584 3278 virtual method type rules Gord - rules for a matching type are stronger than an equivalent type - do default values also need to match? - 1'b1 versus 1 -- is this a match? - this is also related to 3279, with regards to the return type - willing to be flexible on the final set of rules. 3279 Enhance method override rules to allow covariant typing Mehdi - it looks like we will need to discuss 3278 and 3279 together Gord - yes, that is correct. Gord - the basic question is about how tight the rules need to be. Arturo - thinks there is strong agreement that they need to be the same. Gord - what about port directionality? - default values might end up being the most problematic of these. - This is also related to parameterized classes. Steven - derived classes can also add in new defaults. - can only leave out the defaults if through a base handle. Gord - won't be able to write a proposal for either proposal. NOTES: [Gord - is very busy in Feb, March - can't commit for more manti right now] [Francoise sent email to the alias after the meeting volunteering to take a look at both of above and make proposals] 2506 Coverage 2900 - Associative array should consider the context of an lvalue to create an entry 3254 - 18.5.6 if-else constraints mistakenly uses the work "block" when it means "set" 2993 Coverage Cross cover points across different cover groups 3003 constraint composition 3082 Daniels' top items [3075, 3076, 3077, 3078, 3079, 3080, 3081] 2735 ballot comment #48, chaining.. 3046 Dotted names within inlined constraints 3230 from SVBC to review by the committee 5. Next meetings January and February 2011 ----------------------------------------------------- Monday January 31 2011 Monday February 14 2011 Monday February 28 2011 FOR References: --------------------------------------------------------------------- =========== from January 17 2011 meeting =================== AI: 2848 Mehdi - hold this off for the next 3 or 4 sessions. AI: 1356 Tom/Team state the differences between extensions and inheritance. ============ 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