SV-EC Committee meeting Monday April 25, 2011 [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_April_25_2011_Minutes.txt ] Meeting number: 75% = 13 out of 17 meetings attended --------------- 11111111000000000 76543210987654321 Meeting Days: ------------- (21211102021213101) Day (51844762851730629) (00000011111000000) Month (44332121100998887) (11111111111111111) Year (11111100000000000) ------ Attendees ---------------------------- Members: 1. (AAAAAAAAAAAAAAAAA) Arturo Salz 17 - y Synopsys 2. (-AAAAAAAAAAAAA-AA) Dave Rich 15 - y Mentor 3. (AAAAAAAAAA--AAAAA) Francoise Martinolle 15 - y Cadence 4. (A-AAAAAAAAAAAAAAA) Mehdi Mohtashemi 16 - y Synopsys 5. (AA-AAAAAAAAAAAAAA) Neil Korpusik 16 - y Oracle 6. (AAAAA-AAAAAAAAAAA) Ray Ryan 16 - y Mentor 7. (AAAAAAAAAA-AAAAAA) Gordon Vreugdenhil 16 - y Mentor 8. (AAAAAAA-AAAAAAAAA) Steven Sharp 16 - y Cadence 9. (AAAAAAAAAAAAAAAAA) Mark Hartoog 17 - y Synopsys 10. (A-AA-AAAAAAAAAA-A) Tom Alsop 14 - y Intel 11. (AAAAA-AA--AAAA--A) Neil S 12 - y Marvel 12. (AAA-A-AAAAAA-A--A) Alex Gran 12 - y Mentor 13. (----AAAA-A-------) Brandon Tipp 5 - Intel 14. (AAAAAAAA---------) Scott Little 8 - y Freescale 15. (------------AAAAA) Swapnajit Chakraborti 5 Cadence 16. (--A--------------) Dennis Brophy 1 Mentor 17. (--AAAA---A-AAAAAA) Daniel Schostak 11 ARM 18. (AA---------------) Mike Burns 2 - y Oracle 19. (-------A---------) John Havlicek 1 Freescale Observers: 1. (-AA-A-AAAA-------) Tony Tsai 7 Cisco 2. (-AA-A-A----------) Mark Strickland 4 Cisco Former participants: 1. (---AA-AAAAAAAAAA) Jonathan Bromley 12 Verilab 2. (---A-AAA---A--AA) Heath Chambers 7 3. (---AA--AA----AAA) Don Mills 7 4. (---A-----A-AAAAA) Cliff Cummings 7 Sunburst 5. (---AA-AA-AAAA---) Linc Jepson 8 6. (-----A----------) Dave Gates 1 AMD 14 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 ////////////////// April 25 2011 ///////////////////////// Agenda 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt The Chair brought the patent policy to everyones attention. Move: Gord Second: Neil S. Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meetings minutes: ------------------------------------------------------ Minutes from April 11 2011 meetings http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_April_11_2011_Minutes.txt Move: Gord Second: mark Abstain: Opposed: Passed/approved unanimously 3. Updates from P1800 WG --------------------------------------------------------- Face-to-face meeting, April 14 2011 updates. Neil: The P&P was updated with the template, changed it have not seen the new all the changes have to be approved, P1800 WG need to vote on it first before it gets into effect. Observers, chair of technical committees to use their judgements. Gord: Observers will not be able to make motion or vote. Neil: Side discussion is fine, copy on email. There isn't an NDA in effect. Next meeting is early May 12th. Neil: all the email aliases are scrubbed, First draft has come out. Francoise: I had a problem with downloading the first draft. Neil S. - Had an IEEE account problem Scott - He had a similar problem, Dennis sent him instructions. Neil - Mantis items in the completed state have been added to the first draft. 4. Continue Review and discussion of top 25 issues and categories: ------------------------------------------------------------------ Review of the top 25 [+10+3]; 9 have been approved. Francoise: can we make it more formal and vote on the agenda. Mehdi: yes, people can send email ahead of the meeting to adjust the agenda Francoise: the svcc does review the agenda at the beginning of the meeting can we re-arrange the agenda. Mehdi: sure we can put this in the agenda, if anyone wants to re-arrange or modify the mantis items that we need to work on. 2506 [2953] Coverage [Scott] [related to 1356] Gord - text on x, z or 0 (page 5) Scott - that text was borrowed from the assertions section. Arturo - can't we just say the with clause returns a value of bit, if it is ambiguous it would be set to false. Gord - that should be ok. Arturo - wants to avoid a 4-state type Gord - not the same as a cast to a bit Arturo - it would be the same for a single bit Mike - we could possibly strike some of this text. Gord - prefers to strike 2 sentences in 19.5.1.1 Mike - doesn't want it to imply a restriction on these expressions when such a restriction doesn't exist. Scott - this was meant to be a clarification of a procedural if. Was unable to find a good reference so added the redundant text. Arturo - It is described in a different way, it may be confusing. Mike - we don't need to create a new definition of what "true" means. The intention was for it to be the same as what true means for the usage of an expression anywhere else. Gord - "constant expressions (see 11.2.1), instance constants (for classes only), or non-ref arguments to the covergroup." Assumes this refers to an embedded cg Can't refer to a cg that is not lexically visible. Scott - yes, that is correct. Gord - if there is a cg outside the context of a class, but there is a handle reference to it, you could reference that instance constant reference. This is not disallowed by the current wording. - At the point of construction, everything must be constant. The class reference example isn't since you can change the handle. Scott - How should it be reworded? Gord - The parenthetical "(for classes only)" is hard to understand. Steve - "of the current instance of the class" would work Gord - "instance constant" - const variable in a class - If allow a handle and '.' reference to an instance constant, there would be a problem if the handle was then changed. Francoise - "locally visible instance constant" Gord - is that term defined? Arturo - an instance constant of the enclosing class. Gord - For an embedded cg it has visibiliy to instant constants of the enclosing class. - We are all in agreement of what the intent is, but we need to ensure the text does allow the case of access through a handle. Arturo - We could delete the part about "Other identifiers bind according to normal SystemVerilog name binding rules" Mike - bare identifiers are ok, but can't go through a handle. Steven - is there a defined order of cg creation? Arturo - it is created after the class. Gord - the instance constant could be initialized after cg creation. - which value of instance constant gets picked up? The current value or the initialized value? Steven - this is a problem created by allowing cg creation by new. Arturo - that was done for constraints. Gord - if we disallow the explicit initialization of instance constants after the construction of embeded cg's we would avoid the problem. Arturo - That would be a new restriction on instance constants. - Would we do that for instance constants not used in a cg? Gord - Trying to ensure consistency between implementations. Arturo - we could just add a note. Gord - That creates more divergence between implementations. - It would create problems later. - It will happen if allowed by the LRM. Arturo - Believes an informative note should be added to explain how initializing should be first, and then say it would otherwise be undefined. Gord - Prefers to require a new rule for all Arturo - We have a problem today when one instance constance is dependent on another. Gord - But that case is well defined - This case would become undefined. Steven - Adding new rules could create backward compatibility issues. Arturo - We already have this problem. We could plug it, or just document it. Scott - Doesn't like the idea of creating a backward compatibility issue. Arturo - if people are relying on uninitialized values, not good style. - it is probably not a big backward compatibility problem. Gord - could we just disallow the use of instance constants in the with-expressions? Scott - should also then disallow in the open-range-list Francoise - that would then create a different backward compatibility issue. Arturo - if we do the analysis we should disallow it. Steven - inclined to make it undefined since the open-range-list already has a problem. Gord - not thrilled about leaving it undefined. - extending a problem to another place instead of fixing the first problem is not what he prefers. Francoise - prefers to make it an error. Steven - if we make the check too general you would disallow cases that don't have a problem. - it could be hard for users to untangle the issue and recode. - is it that it can only initialize once? There could be if else. Francoise - the assignment can be only done once. Steven - lexically once or execute once? Mehdi - executes once. Steven - that means it can only be checked at runtime. Mehdi - straw poll Arturo - should we add a new restriction to LRM, or add a note. With regards to assignment to instance constants after cg construction. Mike - compile-time error if check for instance constants that are affected used before being set. 1) add a note about undefined behavior 2) add a restriction (specific) Neil - 2 Arturo - 1 Francoise - 2 Gord - 2 Mike - Abstain Scott - 2 Ray - 2 Mark - 2 some restriction would be good (narrow) Steven - Abstain (doesn't like the broad restriction, even though easier to implement) Tom - Abstain Neil S. - Abstain Alex - 2 Mehdi - the general trend was towards adding a restriction. Mike - could possibly write the restriction so that it is easy to check - could just scan the constructor for things initialized after construction of the cg, that are used in the cg. Steven - it would be very difficult to do the complete analysis for cases where you try to limit the minimal number of cases. Being more general is a lot easier. AI: Mike and Scott write up this restriction 2) "Calling any non-pure user-defined system task or function is illegal." Gord - "pure" only applies to DPI. - any $tf is potentially overridable by the user. - does anyone even want the ability to use system functions here? Steven - if we allow c-code to be called here, the implementation won't be able to do any analysis. Mike - most people will end up using DPI for interfacing with C-code. Gord - there is legacy code around. - pure dpi is probably ok. Steven - "constant system functions" could be used, not sure if defined. Scott - last paragraph in 19.5.1.1 Ray - the usage of the word "may" in this paragraph opens the door for implementation divergence. In particular, for the default behavior case. "If the open_range_list includes the same value multiple times, the with clause may select that value to appear in the bin multiple times." Scott - John H. was pushing for "set behavior", but some existing cg text was precluding that. This was why we ended up with "may" in the proposal. Gord - the usage of the with-clause could utilize the set behavior - not good to allow the implementations to decide where to do removals. Scott - can change it to "order and duplication are preserved". - there is no notion of changing what is in the open range list. "However, implementations are not required to schedule the evaluation events when calculating the values in the bin; all, some, or none of the events may be scheduled." Gord - doesn't understand this text. Mike - this was written for formal verification, it is related to vpi Gord - if use line callbacks, that would get you into trouble. - it shouldn't be necessary to have this text. - update events on bins would then come into play. All of this is not well defined. Mike - ok to strike this one sentence. "This allows for the use of non-simulation analysis techniques to calculate the bin (for example, formal symbolic analysis), or for caching of previously calculated results." Gord - Change first part to be "The intent of the rules was to allow.." Scott - the next set of changes are on page 11, 19.6.1.3 Ray - do we need to add text stating that a cross creates a scope? - it says the cross has a scope if it has a label. Gord - page 12, still uses <> type notation. Mike - it specifies a cp bin tuple. Gord - this way of showing it, could cause confusion in that it looks like syntax. Ray - the example on page 12 takes some time to digest. - there will need to be a bnf change to allow functions in a cross. Gord - adding a scope for a cross needs to be checked in detail. - the new set of names now allowed needs to be scrutinized. - Prefers the other approach to specifying prefixes for function calls. Scott - will lift this restriction up to a higher place in the writeup. [from the agenda] 3278 virtual method type rules [Francoise] 3279 Enhance method override rules to allow covariant typing [Francoise] 3278-v1.pdf & 3279-v1.pdf [^] 3293 Clarify $cast behavior on class handles [Jonathan ] proposal-3293-B.pdf 1356 Interface Classes [Multiple inheritance] [Tom, Brandon] 3002 Aspect Oriented Programming (AOP) features [Tom] 2993 Coverage Cross cover points across different cover groups [Arturo, Swapnajit] 3046 Dotted names within inlined constraints [Gord] 3082 Daniels' top items [3075, 3076, 3077, 3078, 3079, 3080, 3081] 3003 [2987, 2988] constraint composition [Jonathan, Tom, Ray, Arturo] 2735 ballot comment #48, chaining.. [Arturo, Steven, Gord] 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] 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 ----------------------------------------------------- Monday May 9 2011 Regular biweekly Monday May 23 2011 Regular biweekly Discussion on Weekly meeting to meet the schedule Gord - I will not be available for weekly meetings. Ray - not sure if meeting more often would be best. - work would be required off-line to quickly review. Gord - possible f2f in June Fransoise - f2f only useful if there are proposals and issues spelled out. Steven - we need to be realistic about which have good likelihood to complete and focus on those. Francoise - hard to get approval for attending an F2F Gord - need to consider if one of the major vendors can't attend. FOR References: --------------------------------------------------------------------- =========== 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