SV-EC committee meeting. Monday September 27 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_September_27_2010_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 000000 654321 Meeting Days: ------------------------------------------------------------------------ (213101) Day (730629) (000000) Month (998887) (111111) Year (000000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAAA-AAA) Arturo Salz 6 - y 2. (AAA-AAAAAAAA) Dave Rich 5 - y 3. (-AAAAAAAAAAA) Francoise Martinolle 5 - y 4. (AAAAAAAAAAAA) Mehdi Mohtashemi 6 - y 5. (AAAAAAAAAAAA) Neil Korpusik 6 - y 6. (AAAAAAAAAAAA) Ray Ryan 6 - y 7. (AAAAAA--AAAA) Gordon Vreugdenhil 6 - y 8. (AAAAAAAAAAAA) Steven Sharp 6 - y 9. (-A--AA--AAAA) Heath Chambers 3 10. (---AAA----AA) Don Mills 3 11. (AAAAAAAAAAAA) Mark Hartoog 6 - y 12. (AAAA-AAAAAAA) Tom Alsop 5 - y 13. (AAAAAAA--AAA) Jonathan Bromley 6 - y 14. (AAA--AA--AAA) Neil S 4 - y Marvell 15. (-AAAAA--AA--) Cliff Cummings 5 - y 16. (-----------A) JL Gray 0 17. (A-A--AAAAAAA) Alex Gran 3 - y 18. (AAAAAAAAA--A) Daniel Schostak 6 - y 19. (-----------A) Kevin Johnston 0 20. (---------A--) John Halvicek 0 21. (---------A--) Scott Little 0 22. (-------A--AA) Tracy McDermott 0 23. (-AAAAA------) Swapnajit Chakraborti 5 - y 24. (AAA---------) Linc Jepson 3 - y 74ze 17 people will have voting rights in the next meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// September 27 2010 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Mark to have read Second: Jonathan Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_September_13_2010_Minutes.txt Move: Dave to approve Second: Jonathan Abstain: Alex (was not present at the meeting) Opposed: Passed/approved unanimously 3. Updates from P1800 ------------------------------------------------ Participation and voting guidelines, other updates. [if any available] Next meeting October 14 2010. 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. [Please take a look at Action Items per last meeting, appended at the end of this email] 2505 class select: what is allowed after the dot? Gord - "read-only mode" this terminology isn't correctly worded. - initial $display ((v.T)'(3.45)); //ILLEGAL: Data type parameters cannot be accessed - This example is illegal, but the description is too general - using property access versus :: Can only be accessed with :: Jonathan - could change the example to show how it could be accessed Dave - Illegal as a LHS expression (versus read-only mode) - the example may not even be necessary Gord - strike the 2 illegal lines from the example on page 2. Mehdi - what about the first example? Are those changes useful? Gord - the references used in the next example use this. Gord - "There are no restrictions on the data type of a class property" - This sentence bothers me. - it is not strictly the data type The qualifier is also part of it. This statement doesn't really add anything. - mentioning the illegal read-only part is not needed here. Neil S. - was addressing the questions in the mantis writeup Gord - visibility questions are valuable to address the mantis item. giving an example of p.ERR_UNDERFLOW is addressed elsewhere. - both lines concerning read-only mode should be removed. Gord - ILLEGAL: Data type parameters cannot be accessed - Suggested rewording "Accessing data types via a class handle is not allowed" - the current wording for this example could be interpreted as being more restrictive than it is. Jonathan - perhaps there should be a list of what can be accessed by '.' and '::' Gord - initial $display ((v::T)'(3.45)); // Legal initial $display ((v.T)'(3.45)); // Illegal Dave - the text right above it is correct. - Just saying illegal for this example should be sufficient. Gord - using dot to access a type is only allowed in interface port case Gord - From: "Accessing data type parameters of a class using object instance name for operations such as type casting is not allowed.' To: ...using a class handle to access a data type is illegal [NOTES: Neil S. updated the proposal during the meeting. Towards the end participants reviewed the last updated proposal document, the discussion and the recommended changes/modifications are noted right before topic 5 of these minutes, below] 3003 constraint composition Jonthan - expects this one to be a challenge - he would like to start an email discussion on this one. Ray - implied constraints complicate it Dave - users would like to extend a class with additional constraints - could have a list of objects where they are specified to have a different set of constraints. Gord - if don't introduce new names it would be simpler. Arturo - existing OOP could possibly be used. could specify a list of objects to be randomized. Jonathan - it is an interesting idea to allow a list to be specified. Arturo - if the constraints are referencing items in a class how would it be done? Steven - they all refer to members of the superclass Jonathan - want to be able to refer to a list of constraints that are specified. Ray - need to determine how to resolve names in the with-clause Dave - create an object whose only purpose is to add new constraints, not to add new members. Steven - it feels like a kluge. Dave - people want to be able to pass constraints to a task - inline constraints are in-between the procedural and the object worlds. Arturu - can use OOP - The limitation is that we can only go one step down in the hierarchy. Dave - testbuilder is the way that he is headed Arturo - testbuilder was written in c++ - he has done some work that was similar. Dave - would be ok with an existing way in SystemVerilog. - Would like to review what Arturo has already done in this area. Steven - could specify all constraints that might be used. turn constraints on and off. Some would be off by default. Then the with-clause could be used to turn on/off. Ray - a name mapping from the with-clause to the class is needed. Steven - could just use the with-clause to turn on/off. Ray - is it acceptable that additional constraints must be declared in the context of the original or derived class? Ray - if just want to randomize two, that can be done today. - what would be the point, unless there is some cross-naming? - bringing a set of constraints in, how do name mapping into the context the constraints are brought into. Gord - we need to know what the expected behavior is. Steven - bringing in the text like a macro is not how things work today. Gord - if not consistent with existing things it will be tough to get it to work. Dave - is one object meant to be an extension of another? Tom - no Steven - completely different properties with the same names? Jonathan - want to pass constraints through a task port Gord - how much parameterization Ray - we are not converting to a symbolic language. Gord - these are the core problems on several fronts. naming issues consistency of the whole flow needs to be addressed Jonathan - extensible enumerations might open the door to a lot of this Gord - there will be tough questions about when you would know the full list of enum tags. Languages that support this have a global name problem. Designs are too big for us to go down this path. Tom - inlining of constraints is what we envisioned Arturo - that sounds like AOP for constraints Gord - 'let' is restrictive - need to know a lot very early for let - like a package macro - won't help much in this context Jonathan - a constraint is like a function - from a high-level Ray - there is a very big difference The solver needs to know semantics inside a constraint You never need to know the internals fo a function. Gord - if a constraint is like a let. There would be a bunch of restrictions. It would reduce to just a rewriting and you only save some typing. It sounds like people want things to be more dynamic. Gord - from a language perspective, if we compose more dynamic, we get more interpretive in nature. Tom - more than just name scoping? Gord - if names resolved required before solving, and don't know name binding up front Ray - parameterized constraints would be more doable Gord - users need to propagate types through the design. It then becomes less useful. Ray - can't wait until runtime to know these details. Gord - parameterized functions would be similar in feel to what would be required. Need to be able to resolve the type. Need to propagate all of that to the point where express the constraint. Jonathan - a parameterized class with a static method inside it. Tom - the bundling up not clear Ray - the with-clause needs to have actuals that will be mapped to. Steven - passing is separate the with-clause knows all is different Ray - the types in the function are parameterized. used in a class. it is getting complicated. - how get something into a with-clause from the outside? Ray - this random variable with this constraint on it. You have to tell us with variable goes with it. Arturo - what if put the extra constraint in a method? Dave - how do you build up a list? -- this is the dynamic part Gord - if have a bunch of methods that describe constraints member function pointers, like c++ would be closer to this idea. Ray - procedurally create randomization context add a with clause add a with clause .. now randomize Dave - something like that. how tell a call to randomize, which constraints are applicable to a call? Ray - if a randomize call with a with-clause, if want to add a constraint, now pull all of those issues up though several levels of hierarchy. we have all the same problems we just mentioned. Jonathan - constrainer class Dave - can't pick and choose a set of extensions at runtime. Gord - if a methodology solution that uses language features, ok. if first-class language features all of these problems become global in nature. That is what we need to worry about. - if restrict these changes to just test bench that might be more doable. If generic language features, it would be tougher to add. Mehdi - Jonathan has some ideas for starting the email discussion. AI/Tom - will get feedback on specific examples. (see 18.7 for information on the with-clause) 3082 Daniels' top items for discussion and review [NOTE: this inculdes a few mantis items:: 3075 to 3081] 3075 Undefined elaboration order of instances created by 'bind' causes portability problems Daniel - questions about bind - are hierarchical references allowed? Gord - yes, that is allowed, there aren't any issues with that. - a bind deposits an instantiation. Steven - can't use hierarchical references in constant expressions. - the wording of this has been a bit relaxed over time. Mark - the bnf is where that restriction was mentioned. Steven - not sure if new text was added to account for this Mark - I'm not sure where it was added (thinks not added) - parameters are allowed in constant expressions. Gord - nothing in LRM to support restriction about ordering of binds. - ordering in this context should not be relevant. - Objects to adding restrictions that ordering of elaboration would possibly affect hierarchical references. Steven - the LRM says it is illegal binding into something that was also a bind. Gord - bind was originally used to add assertions into a design. The only way to do it was to allow module instantiation. Bind was originally never intended to be a multiple level problem Arturo - assertions assumed to only be reading values Mark - you can now use bind for anything. Gord - a bound module that would then bind something to another part of the hierarchy seems to illegal. - given what is allowed now, it would be possible to allow other cases without adding any additional complexity. Steven - defparam resolution in the presence of binds can be problematic. fully qualified path, versus a new hierarchy added by bind, this could change the xmr resolution. Now this xmr resolution becomes order dependent. Mark - there is some text saying that it is an error if any defparsms are different after elab versus current values is an error. Steven - defparam is the only area of a possible problem. 3076 Format of $typename return value should be standardized Arturo - We should just get a concrete proposal for this one Gord - the values returned by $typename should only be descriptive - prefers to just punt on this. Say that it is just descriptive text and not meant for comparisons within user code. Gord - parameters of a class, and those could be typed. It would be a mess Arturo - yes, it would be a mess. Gord - agrees there are some cases where it would be useful. - typename could possibly support modes where for some simple cases there could be agreement. It would take a lot of work to get vendor agreement. Not sure it is worth our investment of time to go down this path. Steven - what is the goal? Daniel - useful debug information. Gord - $unit handling comes into it. It gets down to how a vendor tool works. Debugging is a tool-specific feature. - getting all vendors to agree will be difficult back to 2505 class select: what is allowed after the dot? Friendly amendments for the last document in the mantis database. Remove: - The data type of a class property determines the usage of that property. - The illegal read-only lines. (a total of 5 changes) A new version was made available during the meeting: 1) Text added in last paragraph From Accessing parameterized data types using a class handle is not allowed. To Accessing data types using a class handle is not allowed. 2) Example From: // Typecasting using parameterized data types To: // Typecasting 3) Remove extra blanks var1 = p. ERR_OVERFLOW; var2 = p. buffer_size; 4) Move an existing sentence "Such an expression is not a constant expression." It was agreed to wait for this next set of changes before voting on 2505. Possible email vote on this one. Mehdi - 2505 marks the 8th mantis of the 25 that we have completed. Francoise 2 Arturo 2 Gord 2 Tom 1 (mult inheritance) Dave 1 --------------- 8 done; 8 are in progress 5. Other 'trivial' sv-ec mantis items [close/duplicate] ------------------------------------------------------ Can we plan on email vote on trivial mantis items? 6. Action items review ------------------------------------------------------ Review action items from last 3 meetings, appended below. 7. Next meetings August and September 2010 ----------------------------------------------------- Monday October 11 2010 Monday October 25 2010 -------- for reference only ------------------------------ --------------------------------------------- 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) -------------------------------------------------------------- FOR References: --------------------------------------------------------------------- ============ 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 rights == 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