SV-EC Committee meeting Monday June 6, 2011 [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_June_6_2011_Minutes.txt ] Meeting number: 75% = 15 out of 20 meetings attended --------------- 21111111111000000000 09876543210987654321 Meeting Days: ------------- (02021211102021213101) Day (63951844762851730629) (00000000011111000000) Month (65544332121100998887) (11111111111111111111) Year (11111111100000000000) ------ Attendees ---------------------------- Members: 1. (AAAAAAAAAAAAAAAAAAAA) Arturo Salz 20 - y Synopsys 2. (AAA-AAAAAAAAAAAAA-AA) Dave Rich 18 - y Mentor 3. (-AAAAAAAAAAAA--AAAAA) Francoise Martinolle 17 - y Cadence 4. (AAAA-AAAAAAAAAAAAAAA) Mehdi Mohtashemi 19 - y Synopsys 5. (AAAAA-AAAAAAAAAAAAAA) Neil Korpusik 19 - y Oracle 6. (AAAAAAAA-AAAAAAAAAAA) Ray Ryan 19 - y Mentor 7. (A-AAAAAAAAAAA-AAAAAA) Gordon Vreugdenhil 18 - y Mentor 8. (AAAAAAAAAA-AAAAAAAAA) Steven Sharp 19 - y Cadence 9. (AAAAAAAAAAAAAAAAAAAA) Mark Hartoog 20 - y Synopsys 10. (-AAA-AA-AAAAAAAAAA-A) Tom Alsop 16 - y Intel 11. (AAAAAAAA-AA--AAAA--A) Neil S 15 - y Marvel 12. (AAAAAA-A-AAAAAA-A--A) Alex Gran 15 - y Mentor 13. (AAA----AAAA-A-------) Brandon Tipp 8- y Intel 14. (-AAAAAAAAAA---------) Scott Little 10 - y Freescale 15. (---------------AAAAA) Swapnajit Chakraborti 5 Cadence 16. (-----A--------------) Dennis Brophy 1 Mentor 17. (AAA--AAAA---A-AAAAAA) Daniel Schostak 14 - y ARM 18. (---AA---------------) Mike Burns 2 - Oracle 19. (----------A---------) John Havlicek 1 Freescale 20. (-AA-----------------) Stu Sutherland 2 - y Editor 21. (AA-----AA-AAAAAAAAAA) Jonathan Bromley 14 - y Accellera Observers: 1. (--A-AA-A-AAAA-------) Tony Tsai 8 Cisco 2. (--A-AA-A-A----------) Mark Strickland 5 Cisco Former participants: 1. (-------A-AAA---A--AA) Heath Chambers 7 2. (-------AA--AA----AAA) Don Mills 7 3. (-------A-----A-AAAAA) Cliff Cummings 7 Sunburst 4. (-------AA-AA-AAAA---) Linc Jepson 8 5. (---------A----------) Dave Gates 1 AMD 17 people will have voting rights in the next meeting http://standards.ieee.org/develop/corpchan/mbrs1.html // IEEE-SA members ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// June 6 2011 ///////////////////////// Agenda Agenda 0. Approval of Agenda ------------------------------------------------------ Additions/modifications to the agenda by members. Neil: Some Mantis items did not pass May 11th email vote: 3531, 3394, 3298, 3054 are not on the agenda, place back on the agenda 3531 null should be allowed in constant expressions 3394 invalid example for dynamic array 3298 Use of 'this' in a coverpoint expression 3054 $countones and $onehot system functions in constraints Move: Gord approve Second: Mark Abstain: Opposed: Unanimoulsy approved. 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Mark to assume it has been read Second: Steven Abstain: Opposed: Unanimoulsy approved 2. Approval of previous meetings minutes: ------------------------------------------------------ Minutes from May 23 2011 meetings http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_May_23_2011_Minutes.txt Will leave for next meeting to approve. 3. Updates from P1800 WG --------------------------------------------------------- Neil: Next meeting is on the June 16th 2011. Champions email vote going on ending this Saturday. 10 sv-ec to be voted on. (all svec mantis items in the resolved state are included) 3254 18.5.6 if-else constraints mistakenly uses "block" when it means "set" 2905 BNF bug for attribute instance along with timeunits_declaration 2935 Correction to example in 9.7. in 1800-2009 0245 Array of queues 2985 Multi-dimensional queues 3297 text 18.6.2 font size issue 3181 minor incorrect syntax in with clause in example in 18.5.7.2 2952 text Identifier case error in 25.9 virtual interface example 3405 text Virtual interface example typos 2506 Non-trivial coverage space shapes and joint conditions 4a. Update and Review from email vote (ended June 6 2011) --------------------------------------------------------- Top 3 items below (in 4b) [3 mantis items: 3278, 3279, 3293] 3278 YES: Mark, Dave, Daniel, Alex, Francoise, Ray, Neil S., NO: Arturo [amendment], Neil K.[comment] Gord [amendment] 3279 YES: Arturo, Mark, Dave, Neil K., Scott, Daniel, Gord, Francoise, Ray, Neil S., 3293: YES: Mark, Neil K., Scott, Daniel, Ray, Neil S., NO: Gord [amendment], Francoise [Amendment] 4b. Continue Review and discussion of top 25 issues and categories: ------------------------------------------------------ Review of the top 25 [+10+3]; 9 have been approved. 3278: virtual method type rules [Francoise] [Was part of the June 6th email vote.] Gord - ok with the new version that was uploaded today (June 6th) Brandon - was asking about why return types weren't mentioned. Steven - it would have been a lot more wording to do that. It might be useful to add it at some point in the future. Move: Steven 3278-v4.pdf approve Second: Gord Abstain: Opposed: 3278 is approved 3279: Enhance method override rules to allow covariant typing [Francoise] [Was part of the June 6th email vote.] Mehdi - was approved, now that 3278 has been approved we can resolve 3279 3293: Clarify $cast behavior on class handles [Jonathan ] [Was part of the June 6th email vote.] Gord - see the last sentence of the first paragraph, that is the part of the text his comment addressed. Jonathan - the detailed rules that follow this spell it out. - agrees that Gord's rewording is preferable. Mehdi - Francoise had some additional comments Gord - ancestor and "higher in the inheritance tree" are not well defined in the LRM. 17.3.1 is the only other place ancestor is used. Arturo - it was there before Mehdi - it was in Jonathan's original version of the proposal. Gord - ok leaving the word ancestor in the proposal. Not ok with Fransoise's first proposed change We aren't defining a new rule here, so it shouldn't imply that we are. FROM: It is always legal TO: It shall always be legal... Arturo - could say "any superclass of the expression type" instead of using the word 'ancestor'. Jonathan - would this be ok with multiple inheritance? Gord - it should be ok. Steven - interface classes are not strictly a superclass - if just say superclass, it may not be enough if we pass 1356. - using 'ancestor' might be preferable Mehdi - agrees with using ancestor. Prefers not to introduce issues with multiple inheritance Steven - if the individual rules spell it out, is it then ok to use a not well defined term earlier? Jonathan - it was meant to be introductory text Steven - it is useful to give the reader a summary of the situation before diving into detailed rules. Mehdi - let's just leave 'ancestor' in their, just a restatement Mehdi - what about Francoise's next comment? Gord - the following one is making things more explicit. FROM: a superclass variable to a variable of one of its subclasses TO: a variable of a superclass type to a variable of one of its subclass types Arturo - didn't think it was necessary, but was ok with it. Gord - the others are similar. Arturo - doesn't want to take all of these suggested changes directly. - the text refers to the 'type' already, adding in the word type is redundant. Steven - is assuming you intend class to be shorthand for class type. Arturo - yes. Gord - using 'superclass variable' should be sufficient, as Arturo says. [Back to Gord's email vote comment] Gord - explained it to Arturo (now that Arturo rejoined). The existing text in the proposal is too restrictive. Arturo - This is a new update that Mehdi made(?). Mehdi - I only changed the color. Arturo - is willing to make that change. Move: Arturo 3293-proposal-v4.pdf to be approved Second: Gord Abstain: Opposed: Passed unanimously 1356: Interface Classes [Multiple inheritance] [Tom, Brandon] Brandon - sent a new proposal with a set of updates to Tom to upload. - how handle conflicts was one area changed. instead of hiding the conflicts, if inherit conflicting symbols, the user must provide an overriding symbol to hide the conflict. The overridden symbol needs to be redefined where there would have otherwise been a conflict. - When extend multiple xxx need to define what would have been a conflict. Jonathan - now have the same symbol redeclared again. sounds like extra work for the user. Brandon - the alternative would be to have to reach up through the hierarchy to get access to the symbol. - now it becomes a locally accessible symbol name. Steven - do you have to refer all the way up to do this? Brandon - you could just go up one level, since it is available there. Steven - you have to define it if there is a conflict, only if used? Brandon - no, all the time. - if you don't redeclare it, you are denied access. Gord - the way users will eventually write an implementing class referring to types in an interface class, if have a method to provide an implementation for. - Need to provide types for the implementing class. When refer to that type ::T, he wants to ensure there is as little confusion as possible. Cutting and pasting ability. User today has no way of expressing which variable would be the dominant one. Neil s. - do we know how many users are interested in multiple inheritance of interface classes? Arturo - it is a short-hand, you could inherit one at a time. Gord - we are adding multiple inheritance on top of things that are parameterized. - Can get conflicts due to parameters, anywhere there are concrete names. - In java, there usually is not much confusion. With parameterization, type name issues occurs everywhere. Arturo - are you suggesting single inheritance for interface classes? Gord - is still struggling with what would be the best approach. A set of examples is probably required to know. - Expects to have to choose from a set of non-optimal solutions. Mehdi - a more restrictive version might be best for now, until we get more experience. Jonathan - would like to encourage users to use composition over inheritance Gord - concern, if make choices now, it will cause us to not be able to go back later. Gord - the way you want to talk about type names gets complex if there isn't an easy way to quantify it. Mehdi - another modification was made? Brandon - a new way of virtual method overrides Conflicting method name, the prototype needs to be identical Now need to have a way to override it. The subclass could override them. Gord - the override could be done as long as it would be legal? Brandon - yes. Need to be legal simultaneously be able to override both. Gord - if have a handle of one interface class. Behavior is probably ok, not sure about the typing though. The typing on the reference side. Brandon - everything needs to be in the same package. Gord - where it this? Brandon - we discussed it a long time ago. Gord - that was never my intent. - probably don't want interface classes to be passed as type parameters. Brandon - don't know that the method requirements are. Gord - but packages need to be known ahead of time. - It would be a big restriction to not allow this. Alex - UVM issues could exist. Would need all in the UVM package. Steven - the package info will be available, that is how they are defined to work . Gord - know about the package when compiling in a reference to a package. Brandon - it wasn't clear from the BNF if this was allowed. Mark - can see forbidding forward typedefs, and passing as a parameter, but not this. Mehdi - wasn't the original discussion on a different topic? Gord - the discussion was about parameters versus type parameters. There are certain obligations about opaque types. - only an issue if a type parameter. Steven - or a type pulled out of an interface. Mehdi - we would like to see the new proposal. Gord - doesn't believe there is consensus on how to handle conflicting names yet. Gord - toy examples are just toys, we need to look at more complex scenarios. Mehdi - would like to see real examples. Brandon - doesn't see a use of interface classes extending more than one other interface class. Doesn't understand why Java allows it. - In an implementing class, nothing is inherited. Steven - need to use a class scope to get at them? Brandon - yes. Gord - if no name collisions can do it directly. - will need to know the derivation tree in some situations. Would like to avoid resorting to that. Steven - not allow an interface class from extending multiple interface classes. We might want to entertain this option. Gord - can upload a pdf version of the .doc that Brandon has. Steven - it sounds like the leading contenders avoid potential future backward compatibility issues. Brandon - is there a really useful case that we are not thinking of? (for disallowing multiple extends) Gord - Multiple inheritance vs multiple extends - not much difference The way methods are resolved - there are rules for this. In the multiple implements scenario, would require scope references in a lot of places (unconditionally). Brandon - will send the doc to Gord, or Mehdi for uploading to mantis. 3531: null should be allowed in constant expressions Failed to pass in the May 11 email vote. Mark - where is null legal? Gord - could be used in conjunction with parameters Steven - parameter - required, unless integral type or real. - the only time you can leave the 'type' off a parameter is when the expression is integral type or real. Mark - not sure where can use null in a constant expression. Steven - where the types allow it. Arturo - what is the concern? Mark - has a concern if it isn't well defined where null can be used. Arturo - there are type checks for a lot of situations. Mark - his concern is that the BNF will make it look like null can be used in more places than it can be. constant_primary ::= null Steven - was having trouble finding the text about parameters that are real or integral. It may have been lost in the merge. Mark - null would have only been in the SystemVerilog LRM back then. - null can only be used in certain constant expressions. Gord - heavily macroized or parameterized code can cause excessive use of null. A 'let' expression is another possible situation. Mark - can assign a dynamic array type to null? Steven - no. Jonathan - if assign a type parameter to null, it gives a type to that null AI/Mark - come up with a modified proposal. ----- remainder of the mantis items to be reviewed 2848 Is it legal to assign an interface containing class declaration to a virtual interface [Francoise] [hold for next few meetings: sv-bc is also looking at interfaces] 2845 virtual interface type checking versus interface type that had been defparam'ed [Francoise] 3002 Aspect Oriented Programming (AOP) features [Tom] Mantis3002_AOPproposal.pdf 3046 Dotted names within inlined constraints [Gord] 2987 Soft Constraints [Tom] 2988 Defaults Constraints [Tom] 2993 Coverage Cross cover points across different cover groups [Arturo, Swapnajit] 3082 Daniels' top items [3075, 3076, 3077, 3078, 3079, 3080, 3081] 3003 constraint composition [Jonathan, Tom, Ray, Arturo] 2735 ballot comment #48, chaining.. [Arturo, Steven, Gord] 3001 Proper Polymorphic behavior of instantiation [Jonathan, Tom, Francoise] 2999 Class Handle reference inside of Constraints [Tom, Ray, Arturo] 1706 Meaning of static prefix for virtual interface assignments [Mark, Steven, Francoise] 2488 Are virtual method calls legal within class constructors? [Steven, Francoise] 1442 Clocking blocks legal in modports, missing from text description in 20.9 [Steven] 3254 18.5.6 if-else constraints mistakenly uses the work "block" when it means "set" 3230 task should be function in definition of static functions 2112 Remove restrictions on NBA assignments to class members [Dave, Steven] 2112_NBA.pdf 2900 - Associative array should consider the context of an lvalue to create an entry [Dave] 3254 - 18.5.6 if-else constraints mistakenly uses the work "block" when it means "set" [Dave] 3254_constraint_set.pdf 2794 - Clarify queue methods return status (related to sv-bc) 1067 (LRM consistency issues regarding access to nonexistent array elements). 1067-proposal-revA.pdf 5. Next meetings 2011 ----------------------------------------------------- Discussion on Face-to-Face and weekly meetings Monday June 20 2011 Regular biweekly Monday July 4 2011 [No meeting, July 4th holiday] Monday July 11 2011 [possible meeting] Monday July 18 2011 Regular biweekly Monday August 1 2011 Regular biweekly FOR References: --------------------------------------------------------------------- =========== from June 6 2011 meeting =================== AI: 1356 Brandon: to upload the modified document AI: 3531 Mark : create the modified proposal. =========== from May 23 2011 meeting =================== AI: Mehdi - create an sv-ec mantis item for editorial issues [already done: mantis 3589 ] AI: 1356 Tom to put an example for virtual class extending an IC, virtual classes extending IC is same as extending another virtual class. =========== from May 9 2011 meeting =================== AI: (3278) Francoise to update the 3278 proposal AI: (3293) Arturo - update the proposal in preparation for an email vote. =========== from April 25 2011 meeting =================== AI: 2506 Scott and Mike to update the restrictions (straw poll) =========== from April 11 2011 meeting =================== AI: 3181 unanimously approved AI: 3297 unanimously approved. AI: 2985 unanimously approve: CLOSE as duplicate of 245 AI: 245 CLOSE 245 as already implemented vote: yes Abstain: Gord: The summary says array of queues - not sure that what exists is as general as what was requested. Persistence of elements is a key point with this. AI: 3254 Dave:change the coloring, also no underlining, and add mantis item to the top of the proposal. AI: 2952 unanimously approved AI: 3405 Mehdi The proposal needs be deleted, [Close as duplicate of 2952] AI: 3230 Mehdi contact the svbc - the svec wants to take ownership of 3230 AI: 3230 Gord will update 3230 and scrub related text for any additional changes that might be required. AI: 2900 Dave to update the proposal. =========== from March 28 2011 meeting =================== AI: 2506 Scott to get more input from the user community (Freescale). All, Please respond when information hits the reflector. All, Please consult with the users to get their feedback. =========== from March 14 2011 meeting =================== AI: 2506 All - Scott to send out clarification email to the alias. =========== from February 14 2011 meeting =================== AI: 2506 All - discuss this proposal over email. =========== 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