SV-EC committee meeting. Monday November 8 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_8_2010_Minutes.txt ] Meeting number: 75% == 7 out of 9 meetings attended ------------------------------------------------------------------------- 000000000 987654321 Meeting Days: ------------------------------------------------------------------------ (021213101) Day (851730629) (111000000) Month (100998887) (111111111) Year (000000000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAAAA) Arturo Salz 9 - y 2. (AAAAAA-AA) Dave Rich 8 - y 3. (AA--AAAAA) Francoise Martinolle 7 - y (75% attendance) 4. (AAAAAAAAA) Mehdi Mohtashemi 9 - y 5. (AAAAAAAAA) Neil Korpusik 9 - y 6. (AAAAAAAAA) Ray Ryan 9 - y 7. (AA-AAAAAA) Gordon Vreugdenhil 8 - y 8. (AAAAAAAAA) Steven Sharp 9 - y 9. (A---A--AA) Heath Chambers 4 10. (AA----AAA) Don Mills 5 - y (2 of last 3) 11. (AAAAAAAAA) Mark Hartoog 9 - y 12. (AAAAAAA-A) Tom Alsop 8 - y 13. (AAAAAAAAA) Jonathan Bromley 9 - y 14. (--AAAA--A) Neil S 5 Marvell 15. (--A-AAAAA) Cliff Cummings 6 16. (AAAA-A--A) Alex Gran 6 - y 17. (-A-AAAAAA) Daniel Schostak 7 - y (75% attendance) 18. (----AAAAA) Swapnajit Chakraborti 5 19. (A-AAAA---) Linc Jepson 5 - y (2 of last 3) 20. (AA-------) Tony Tsai 2 - y (2 of last 3) 21. (-A-------) Brandon Tipp 1 16 people will have voting rights in the next meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// November 8 2010 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Jonathan Second: Mark Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_October_25_2010_Minutes.txt Neil: Everyone shows Move: Jonathan Second: Gordon Abstain: Heith, (was not here) Opposed: Passed/approved unanimously AI/Mehdi - will check for consistency between the left and right sides for the attendance. 3. Updates from P1800 --------------------------------------------------------------------------- Participation and voting guidelines, other updates. [if any available] Tech sub-committee reports Neil: May not have a meeting on 11/11/2010. Neil: Champion email vote 3028, was approved, Shalom was suggesting to syntax to be added. 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] Mantis 3028 constraints for unique array elements. Neil - Has Champions feedback Jonathan - He will add the syntax snippet that Shalom requested Mantis 1356 Interface Classes [Multiple inheritance] Tom - a few items on this to go over this two questions: section 8.25.1 : extension vs. implements Gordon - all examples are trivial pass through. - Other situations need to be added to the examples. Mantis 3278 and 3279 describe what is needed. Virtual method overrides requires that things are the same. - not legal if names of types don't match, legal in implementation context Jonathan - what is the intent, second line of examples: you may want to change the name Tom - name hiding Jonathan - didn't quite follow what was being qualified here, with the email changes. Tom - Gord's example will hopefully be more clear. Tom - the second change was related to a forward typedef Gord - can't do a direct assignment, need a $cast() $cast(get_ref, put_ref); Gord - if going to appeal to the actual object to know type we had better define what NULL means. Jonathan - there is already an issue with NULL for $cast today Arturo - Gord is referring to class handles that happen to be NULL - Using NULL directly should be allowed. Steven - we would need to specify a special case for NULL in the LRM. Tom - We need to specify what it means when the source in a cast has the NULL value. Steven - want it to be ok or illegal, not throw an error. Returns success or failure when make a call to $cast. Tom - can we decide now if it is legal or not Steven - use same rules for dynamic cast for two types. Sometimes can look at them and determine always illegal. Gord - there seems to be some divergence today - it becomes a global question, Needs to be defined in terms of the dynamic semantics. Steven - may end up searching for any class that implements both. Jonathan - It boils down to what users are doing with $cast. $cast with a literal null same as a null assign If an argument to $cast happens to be null, happy for it to be an error. Arturo - a literal NULL has to be allowed. Steven - if NULL, assign null, else do the $cast Users could already do this on their own. Gord - would not want an implementation to have to statically determine if the assign would EVER be possible. Steven - it is too messy with multiple inheritance to check that. Mehdi - not yet clear if we are going for a complete clarification. - do we need a new mantis item? Gord - would oppose changes unless NULL is also addressed. Gord - the rules for virt method override also needs to be rewritten. - we would most likely need a new mantis item. Ray - we should be able to work on other mantis items that happen to be affected by something being worked on. Mehdi - agrees that we should open two new mantis items for these items. Ray - any mantis item that is a prerequisite for an approved mantis item should also be approved. Gord - covariant type extension is also affected When you allow methods that don't have the same signature. Allows methods that are derived from the original type. - There is also the notion of contravariance. Argument types change in same direction or opposite direction. Steven - derived type handle Gord - covariance is strictly not a dependency but if we are changing this text, we should deal with it now as opposed to leaving it as implementation specific to avoid divergence. Gord - there is a definite difference between covariant and contravariant - if implementations are already doing this, and we need to change the same rules already, we should address it simultaneously while we are making these changes. Steven - they are definitely already supporting some of this. Gord - it would be silly for the WG to disallow it being worked on. Steven - the OVM people would like to have that. Gord - the prototype must be identical. If there were parameters, they would not match. The existing rules are too restrictive. This will be a big problem when we get to MI. Jonathan - not intended to support truly different types though? Gord - we need to at a minimum change this restriction. - It will most likely not be hard to do, but it requires a set of systematic updates through this area of the LRM. - need to ensure there aren't any lingering assumptions in this area. Steven - if there are type parameters, they could be coming down two different paths. Arturo - overloading would be an additional mess Gord - overloading resolution would be very difficult in SystemVerilog Getting to a good description of what makes sense in what constitutes an "identical match" should not have to be a textual match. We need to generalize all of that text, there is already one exception stated in this part of the LRM. Gord - It shouldn't be a surprise that these extra issues are falling out from the work on MI. AI/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) Gord - 2nd para of 8.19 uses the word "exactly". Virtual methods provide prototypes for the methods that later override them, i.e., all of the information generally found on the first line of a method declaration: the encapsulation criteria, the type and number of arguments, and the return type if it is needed. Later, when subclasses override virtual methods, they shall follow the prototype exactly by having matching return types and matching argument names, types, and directions. It is not necessary to have matching default expressions, but the presence of a default shall match. 3003 constraint composition Jonathan - no proposal A bit nervous to work on this, since other issues seem to be more important to users. - He misunderstood something that Arturo had mentioned. (?) 2506 coverage space shapes - covergroups (from John Halvicek [Freescale]) Mehdi - we will need to have John H. attend the meeting. Arturo - we can start discussing it without John in the meeting. - motivation is for crosses or coverpoints that are not rectangular in shape. - specifying bins for one quadrant or a triangular shape - also want to be able to specify a type for a coverpoint, today it is the type of the expression being covered. Ray - 1. type specification 2. procedural bin specification 3. complex cross Arturo - a big change is moving to a more procedural approach instead of a declarative approach. It allows for complex crosses. - A number of users have asked for something along these lines for crosses. Jonathan - can do this today by mapping, but the bin labels then become meaningless. Could allow users to specify names for how they did the mapping. Arturo - it is even more complex than that. See the apple, cherry, plum example in the proposal. These could be arbitrarily complex. - It would be very difficult for users to try to accomplish this. Jonathan - In the end you end up mapping a bunch of values to a bunch of bins. Arturo - the values are parametrically related. A triangular shape is very hard to create today. Jonathan - the proposed approach looks attractive. Arturo - the new syntax wouldn't collide with existing syntax. We would just need to agree on the semantics. Ray - the dist stuff doesn't make sense yet. AI/John H. - put the proposal into pdf format (Francoise had a problem with it) Mehdi - Dave Rich suggested an email vote on the following 2 mantis items 2900 - Associative array should consider the context of an lvalue to create an entry 3254 - 18.5.6 if-else constraints mistakenly uses the work "block" when it means "set" will be discussed in conference call next time. - are there any others that could be added to it? Ray - question on 2999 - solve a set of constraints before others Tom - converting e-code to SV, these came out of that process. Ray - there is also mention of treating a handle as NULL. SV constraints never treat handles as random values. Steven - a class handle is always treated as a state variable. Mantis 2900 Associative array should consider the context of an lvalue to create an entry Gord - lvalue versus a read Dave - first a write, before it becomes a read. write, read, write Gord - first portion of the example. associative array of integer, indexed by integer associative array is empty a[1]++ What is the result? - This proposal is trying to clarify this. - if the operation creates a new element. The element is created before it is used. Arturo - why do we need a special rule for this? Gord - 2 things in play here default value write operation - when reading with ++ operation, what is returned? Steven - read the default and then write a new value. Gord - you don't re-evaluate the expression. Dave - simpler case is a struct. Steven - clearly you need to create the whole thing Jonathan - there is a long-standing problem here. Steven - need to create the whole associative array element, not parts of it. Gord - the default value of an associative array is not contained within the associative array, a mythical element. Arturo - what you read is the default value, Gord - what are you updating, the associative array or that mythical element? Steven - if passing by ref to a ref argument. Someone may want to write to it. Arturo - thinks the ref should be null, why would you want to operate on a null value Stegen - used as an lvalue creates it Gord - understands Arturos argument, but whether the default is created out of thin air needs to be clearly articulated. - not clear what constitutes a "write" context. Arturo - early proposal was that ++, -- would behave like a function. That was rejected by the committee. Gord - not sure that this is trivial. Not sure that he is in agreement with the direction of the proposal. Steven - the reader doesn't care about if a mythical value Gord - it does matter when passing by ref. Steven - is it just an expression or the actual value. Gord - is it first created and the referenced? That is a key question. Francoise - we should look at other languages to help decide. in the context of updating arrays. Steven - mixing a potential write with a pre-read Jonathan - the stable door is wide open. Francoise - if the write first requires a read Jonathan - a[1] = a[1]+1 is already allowed Arturo - creating an entry while referencing in a sub-expression, you will end up with implementation divergence. Dave - why not create the entry first Arturo - what if same value referenced twice in the expression? Gord - class handle in the element. (?) - need an agreement on what constitutes creating an entry. Steven - for a class handle, not a write operation, just a read. Gord - now need to determine what a reference means. 2505 Neil S. : class select 2993: Arturo : Coverage 3082 Daniels' top items [3075, 3076, 3077, 3078, 3079, 3080, 3081] 2735 ballot comment #48, chaining.. 3046 2506 [coverage] 3278, 3279: Gord 5. Next meetings November and December 2010 ----------------------------------------------------- Monday November 8 2010 Monday November 22 2010 -- Steven & Francoise out, Cadence shutdown Monday December 6 2010 ?? Monday December 20 2010 ?? synopsys shutdown Monday January 3 2011 ???? Monday January 17 2011 --------------------------------------------------------------------- ==== for reference ========================================================== ============ 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