SV-EC Committee meeting Monday August 1, 2011 [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_August_1_2011_Minutes.txt ] Meeting number: 75% = 17 out of 23 meetings attended --------------- 22221111111111000000000 32109876543210987654321 Meeting Days: ------------- (01202021211102021213101) Day (18063951844762851730629) (00000000000011111000000) Month (87665544332121100998887) (11111111111111111111111) Year (11111111111100000000000) ------ Attendees ---------------------------- Members: 1. (AAAAAAAAAAAAAAAAAAAAAAA) Arturo Salz 23 - y Synopsys 2. (AAAAAA-AAAAAAAAAAAAA-AA) Dave Rich 21 - y Mentor 3. (AAA-AAAAAAAAAAAA--AAAAA) Francoise Martinolle 20 - y Cadence 4. (AAAAAAA-AAAAAAAAAAAAAAA) Mehdi Mohtashemi 22 - y Synopsys 5. (-AAAAAAA-AAAAAAAAAAAAAA) Neil Korpusik 21 - y Oracle 6. (AAAAAAAAAAA-AAAAAAAAAAA) Ray Ryan 22 - y Mentor 7. (AAAA-AAAAAAAAAAA-AAAAAA) Gordon Vreugdenhil 21 - y Mentor 8. (AAAAAAAAAAAAA-AAAAAAAAA) Steven Sharp 22 - y Cadence 9. (AAAAAAAAAAAAAAAAAAAAAAA) Mark Hartoog 23 - y Synopsys 10. (A-A-AAA-AA-AAAAAAAAAA-A) Tom Alsop 18 - y Intel 11. (A-A-AAAAAAA-AA--AAAA--A) Neil S 16 - y Marvel 12. (-AAAAAAAA-A-AAAAAA-A--A) Alex Gran 16 - y Mentor 13. (-AAAAA----AAAA-A-------) Brandon Tipp 10 - y Intel 14. (AAA-AAAAAAAAAA---------) Scott Little 13 - y Freescale 15. (------------------AAAAA) Swapnajit Chakraborti 5 Cadence 16. (--------A--------------) Dennis Brophy 1 Mentor 17. (A-AAAA--AAAA---A-AAAAAA) Daniel Schostak 16 - y ARM 18. (------AA---------------) Mike Burns 2 - Oracle 19. (-------------A---------) John Havlicek 1 Freescale 20. (AA--AA-----------------) Stu Sutherland 4 - Editor 21. (AAAAA-----AA-AAAAAAAAAA) Jonathan Bromley 17 - 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 16 people will have voting rights in the next meeting http://standards.ieee.org/develop/corpchan/mbrs1.html // IEEE-SA members ** Minutes taken by Jonathan Bromley and Mehdi Mohtashemi ////////////////// August 1 2011 ///////////////////////// Agenda Agenda 0. Approval of Agenda ------------------------------------------------------ Additions/modifications to the agenda by members. Move: Gord to approve the agenda Second: Tom 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 meeting minutes: --------------------------------------------------------------- Minutes from July 18 2011 meetings will be posted later. 3. Updates from P1800 WG --------------------------------------------------------------- Next meeting August 11 2011. Rev 2 was out on 29th, Stu: 53 Mantis items have been incorporated in Draft 2.. Members were asked to check section numbering in their proposals as the new draft has added some sections w.r.t. 1800-2009. Neil S: if there was a deltas-list showing which Mantis items contributed to the draft. Stu: information is available but might need to be extracted manually. 4a. Continue Review and discussion of top 25 issues and categories: --------------------------------------------------------------- Review of the top 25 [+10+3]; 9 have been approved. 2506 Coverage Scott: changes have been made to the proposal. Francoise: concern that it is now more limited Scott: it is not ideal but the best solution. Jonathan: could we consider a new coverpoint constant expression, to use in the BNF, such as "coverpoint_const_expression" to capture those parts of the syntax where expressions are treated in this way? may alleviate the concern about maintaining the list. Ray: that maybe cleaner, could be used as a convenient hook for syntactic restriction Scott: I can create a new BNF item and include these Steven: in BNF you may have a note on it, and indicate the semantic rules Gord: nearest parallel to this is constant expression, does grammer duplication Arturo: maybe grammer with semantics notes is better. Gord: have no problem with going that way it is an expression and here is the semantics of the items, but that was not the way we worked it to constant expression. It will be difficult This is an expression and here is the semantics limitations. Francoise: that would be my preference Steven: the point is that it does not include all expressions Gord: such as if condition, and coverpoint expression themselves are not required to be constants. Scott: you want the coverage space to be constant Ray: you can identify which expressions you want to be constant and which not. if it ends up duplicating a lot of grammer i would prefer not to do it. Gord: problems with constructs such as "open_range_list", and doesn't want extensive duplication of grammar. Scott: would it raise flag with champions? Gord: It maybe worthwhile to send email to Brad on this, and ask about grammer. and see if he has any concern. Francoise: I do like the fact that we create a new bnf but it has duplications. Gord: It maybe more reasonable to define a covergroup constant expression, Ray: second paragraph would be better to be divide into two paragraphs. Gord: Does Stu have any opinion on the parenthetical comments? Stu: it does seem awakward, how do we change it? Gord: the first bullet after third paragraph, (constants are allowed) it should say "output or NON-CONST ref" so that the parenthetical comment is just explanatory. Scott: changed the variable to z instead of x. Scott: the third change, I made it to 'legal expression', Francoise: why say legal, it should be legal. Discussion on 19.5.1 Steven: Pointed out "number" should be "integral expression"; Scott: Instead of all of this we could say 'integral expression is allowed in the square brackets' Jonathan: any considerations for negative or non-positive expressions? Gord: I assume they are self determined, do we find out the type of these in unpacked array section 7.2, it says 'or a positive number' integer array, providing number of elements it can not be negative, Jonathan: 0 maybe there, it would be good to clarify it. Scott: is 7.4.2 paragraph ok. can we say single positive integer, Gord: except you want to use integral expression, that is what is used in 7.4.2. Ray: Does 7.4.2 indicate that zero is not allowed. Gord: 0 is not in positive integers Arturo: size 0 is not allowed. Arturo: there is ambiguity with 0 bin, we may exclude it there is consensus let us say explicitly say non-zero. Scott: will use 'single positive integral' Scott: the next change making it more consistent. the final change was on page 10 AI: Scott to send an email to sv-ec and poll Brad and Shalom for their comments. 1356 Interface Classes [Multiple inheritance] [Tom, Brandon] 1356_Interface_Classes_rev4.pdf Tom: are there major issues here or clarifiations? Gord: grammar is wrong, some are clarifcations, but some need closure. for example, 16,17 & 18, deal with combination, need to know what we mean we should be careful about semantics of words usage. decision on what we think the right answer should be, Tom: it is mostly to do with extend vs. implement Gord: I am concerned about borrowing "inheritance" language to describe "implements". Tom: We were under impression that corner cases were mostly worked out, I thought he got consensus on them. Mehdi: I thought we agreed on some, for example 16 Gord: the wording sounds more like inheritance. every place that class handle is talked about, Francoise: I would have expected the prototype for function f should be there and it would be easier. Gord: my last statement is there at the end of 16 Tom: then do you mean #17 is the way to go? Gord: in item #16 , abstract base class, need to be carefull when there is a problem with class structure and the prtotype is stronger. does an abstract base class gain declarations of the prototypes in an interface class it implements, or must it repeat those declarations? Arturo: why can't that be illegal, you will provide implementation Gord: but this is an abstract class. would prefer the abstract base class to have the prototypes explicit. Tom: is it possible to create some exhaustive list/spreadsheet showing various conditions/interactions? Will get a review on these and send it to the alias. NOTE: Tom had to leave the call at 12:04 PDT Mehdi: Lets go through the list that Gord has, I hope to complete this today if we can. Arturo: The most important issue in my mind is #18, make corner cases illegal. Gord: easy ones, are items 2,3 are grammer issues, list of arguments should not be there item #4 is simple item #5 $cast, Arturo: that would require a $cast, Gord: $cast is needed, but the source and destination interface types could be very remote from one another. Gord: continuning in the list.. item #6 is just minor rewording items #7 & #8 are similar item #9 question about accessing parameters is it OK to access interface class's parameters by dotted selection through an interface class handle? Francoise: did not know you can have IFclass as a variable. Gord: if you have variable of IF class type, you need the functionality, Francoise: Do you have constructors for IFC? Gord: No, they are like abstract classes, Francoise: but you can assign to them some object Gord: you can call method by IFC class handle, are you allowed to do with IFC hand IFC.parameter_name? Intf classes have no static methods, my preference is to not allow this, not allow access to parameters - safer to be conservative now, maybe relax later. Francoise: they do not have any data members Ray: no reference to static data members or parameters. Jonathan: practical limitations for users, can not have access to the parameter in functions Arutro: it is true within the implementation, Gord: yes, however no visibliity inside the implementation Francoise: if object implementing class, Jonathan: we could go either way, but better to chose conservative one. Gord: items #10, 11, 12,13 are just clarificaiton/rewording. skip item #14, obsolete concern. item #15: three choices, if base extends other things that has f in it if it is virtual it needs to have an f regular class requirement is clear, f has to be there or in some base class Gord: back to item #16, if prototype doesn't exist in the implementing abstract base class then it's an "unacknowledged contractobligation". Arturo: it is in the implementation of IFC, then you have all of the prototypes there Gord: this is related to the language that we have, 17 & 18 interact to it. Arturo: concerned it's hard to define this unambiguously/clearly. Gord: like to use the terminology of 'contract' agreement is that the prototype should be explicit, if agreement is there on 17 & 18, then we can rewrite the wordings Gord: do we agree on with item #16, Francoise: I agree with it, Arturo: yes, but the question is when would you not need the definition. NOTE: It was suggested that the conservative resolution (require implementing class to repeat the prototypes even if it's an abstract base class) is appropriate given the current time pressure. Clear error messages could be given to users if this is not done. Gord: now on item #17, virtualness is contained again consensus on the conservative approach, require implementing class to provide virtual keyword ("implements".then doesn't affect base class's behavior). Arturo: implemtation here is ok, should not be no ambiguity Gord: base class which implements IFC, should satisfy f, I do not like changes to the behaviour to the method. Arturo: We simply apply rules, implementation always require it for the virtual methods. Gord: if something is virtual in base class, then you have also virtual here satisfying obligation implicitly cause the item to be virtual. if not making it virtual then it is confusing. Arturo: the only way not to make it virtual is to define one that collides with virtual. what if the implementation and ifc are virtual? Gord: if it is vritual function T you can not hide it, we have make it for sure virtual. Jonathan: again it should be ok to use the word 'virtual' Arturo: I can see that it may make sense. Gord: There should not be fundamentally different Arturo: Yes, it will remove ambiguity. Gord: NOw on item #18, it now becomes more clear, it evolves into a regular class declaration, decision forced by the conservative solution to #17: intf class method must be defined as virtual, thereby hiding the non-virtual base class method. Jonathan: that is what happens today, Gord: you could hide base::f, by virtual funcion in class, or function in base be virtual. Jonathan: that would be more helpful. Arturo: How deep in heirarchy do you have to go to find the inconsistencies? Gord: Depends how helpful the tool wants to be, it has to walk through. Arturo: How much you need to search to give this error? Gord: single inheritance check for regular class, for IFC, multi-way derivation path, no way around that. Gord: item #19 is a question, can we call randomize via IFC class handle? The randomize() is virtual, implicit interface requirement, could imagine every class implements randomize() . Potentially you call randomize by itself. Ray: one way to do this to declare a variable with IFC, construct antoher in implementation then you could say x.randomize after that. Gord: No, with x.randomize you get to call the virtual randomize, Ray: Ok, since you can not construct the IFC, then x.randomize does not work Gord: you do not have any visible names, inline constraint, you look at the type of handle, IFC handles do not have data members may not be useful with{} construct, constraint_mode, etc. Steven: with clause is not virtual, Gord: Best allow it, but LRM should note the limitations. Steven: can you call to randomize if it does not have random variable? Arturo: Yes, because you could extend it but you can not use a with clause in IFC, it would be error Gord: item #20 (streaming and $bits on interface class handle) is a bit of question, streaming operators are already problematic for regular classes, further extends the bizzare behaviour, preference is for $bits and streaming to be illegal for interface classes at this time. Mehdi: f2f did not go through, extended ones did not go through, would like to ask email discussions also let us know if you can writup any proposal for any of the remaining mantis items and upload it to the database for discussion. 5. Next meetings 2011 ----------------------------------------------------- Monday August 15 2011 Regular biweekly Monday September 12 2011 Regular biweekly Monday September 26 2011 Regular biweekly ----- rest of mantis items for review [information purposes] 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] 2794 - Clarify queue methods return status (related to sv-bc) 1067 (LRM consistency issues regarding access to nonexistent array elements). 1067-proposal-revA.pdf 3589 - Created for editorial issues. FOR References: --------------------------------------------------------------------- =========== from August 1 2011 meeting =================== AI: 256 Scott to send an email to sv-ec and poll Brad and Shalom for their comments. =========== from July 18 2011 meeting =================== =========== from June 20 2011 meeting =================== AI: Mehdi, find out from Stu a compiled list of items in draft =========== from June 6 2011 meeting =================== AI: 1356 Brandon: to upload the modified document AI: 3531 Mark : create the modified proposal. - create an sv-ec mantis item for editorial issues =========== 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