SV-EC committee meeting. Monday July 19 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_July_19_2010_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 0 0 1 Meeting Days: ------------------------------------------------------------------------ (1) Day (9) (0) Month (7) (1) Year (0) ------ Attendees -------------------------------------------------------- 1. (AAA-AAA) Arturo Salz 2. (AAAAAAA) Dave Rich 3. (AAAAAAA) Francoise Martinolle 4. (AAAAAAA) Mehdi Mohtashemi 5. (AAAAAAA) Neil Korpusik 6. (AAAAAAA) Ray Ryan 7. (A--AAAA) Gordon Vreugdenhil 8. (AAAAAAA) Steven Sharp 9. (A--AAAA) Heath Chambers 10. (A----AA) Don Mills 11. (AAAAAAA) Mark Hartoog 12. (AAAAAAA) Tom Alsop 13. (AA--AAA) Jonathan Bromley 14. (AA--AAA) Neil S 15. (A--AA--) Cliff Cummings 16. (------A) JL Gray 17. (AAAAAAA) Alex Gran 18. (AAAA--A) Daniel Schostak 19. (------A) Kevin Johnston 20. (----A--) John Halvicek 21. (----A--) Scott Little 22. (--A--AA) Tracy McDermott 23. (A------) Swapnajit Chakraborti ** Minutes taken by Jonathan Bromley and Neil Korpusik ////////////////// July 19 2010 ///////////////////////// NOTE on voting rights: - The voting rights are being reset now that we are a Working Group again. Everyone will have voting rights at the next meeting. Special Note: - Mehdi started the meeting and asked Dave to chair the rest of the meeting. 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt The chair directed everyone's attention to the patent policy. Mark, Arturo - move to assume that the patent policy was read. Agreed unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_June_7_2010_Minutes.txt Move: Tom to approve Second: Francoise Abstain: None Passed/approved unanimously 3. Updates from p1800 WG ----------------------------------- Dave - reported back. Now that there is a PAR in place, voting rights are reset with effect from this meeting (July 19th 2010). At this and the next two meetings, all attendees are eligible to vote; after that, attendance at two of the previous three meetings is required. We have not yet had official clarification from DASC on the entity-based participation requirements, and so the existing rules remain in place temporarily. 3. Estimates for the top 25 issues and categories: ------------------------------------------------------ The top 25 items/issues from SV-EC were presented to p1800WG on May 13 2010. Refer to this presentation: http://www.eda.org/sv-ec/Minutes/SVEC_to25_13May2010.pdf The spreadsheet updates (June 7 2010) http://www.eda.org/sv-ec/Minutes/svec_top25_June7_2010result.xlsx NOTES: Jonathan had specific requests for clarification of requirements for items 3001 and 3003, these were taken first. 3001 (Polymorphic behaviour of instantiation): Jonathan - Noted that there are two obvious candidate syntactic forms, base_handle = derived_class::new(args) base_handle = new derived_class(args) It was pointed out that base_handle = derived_class'new(args) might also be appropriate. Jonathan - expressed a preference for the first of these, because it's more natural way of providing constructor arguments; but feared that the use of :: might give rise to confusion since new is not a static method. Gord: pointed out that new() is special in various other ways so there's no real confusion. Jonathan - also pointed out that none of these forms is truly polymorphic since the type of the constructed object is determined statically by the code, whereas the copy constructor syntax base_handle = new other_handle creates an object of the same type as that referenced by other_handle. Arturo and others pointed out: that a polymorphic constructor is not useful in SV because there's no way of supplying its arguments appropriately. Tom - agreed to go back to his users to confirm the exact intent of the original request. [AI:Tom get confirmation from users about exact intent of the original request for 3001] 3003 (Constraint composition) 2987, 2988 - overridable and soft constraints 3003 Jonathan - requested clarification of this request, particularly the idea of constraint as an object. Dave - Constraint composition, think about a constraint as an object, as opposed to just part of a class. - you can't pass a set of constraints to a task. Tom - Can only pass them around if they are bundled inside an object. Cliff - What does it mean to pass constraints? Dave - Today there are two options a. extend the class b. use the 'with' option (the on-the-fly-mechanism) If want to use an in-line constraint. if want to embed the inline constraint. Jonathan - if that task wants to call randomize with. Arturo - A constraint is an expression, so this is really pass-by-name -it is a big enhancement, and one that would apply in other places not only constraints. Dave - people have extended a class just for extending constraints - if can point to a set of objects that apply to a class, it would be more flexible. Arturo - this is similar to functional programming. Aspects would be another approach to resolving it. AOP would help here. Heath - has used AOP to add constraints in other languages. Ray - one set of constraints, then used in several places? Tom - it is more than just that, That doesn't allow composition. Ray - but you want to have a way to refer to a constraint which is a bit different from AOP.if constraints can be written with arguments, that might avoid the worst of the scoping/name issues Jonathan - a class type argument is what it sounds like - it is pass by name Arturo - it is a very useful feature, but it is a bit ambitious, Some of this can be done with SV today Tom - we are interested in the feature, not necessarily a specific way to support it. Dave - scv has this capability 2848 - Is it legal to assign an interface containing a class declaration to a virtual interface? Francoise - perhaps this one should be moved to the sv-bc Gord - type compatibility from outside of the VI is problematic. Arturo - what is the user motivation for this? Francoise - having a type in a VI? Arturo - yes Francoise - not sure. (gave some ideas) Dave - an interface was designed to contain types that could be referenced through the port. Jonathan - you can point to the class that is inside of it. Arturo - it is a bit strange from a methodology point of view. Francoise - an enum inside an interface is similar Arturo - it would most likely be external Dave - can access those types through interface ports. Arturo - interfaces were originally for point-to=point connections Dave - there are plenty of people that only use interfaces for testbench Gord - There would only be one instance of that type. Not legal to reference things with strong type via VI reference or say that we can't have strong type def inside of an interface. Could reference enum, structs, class. Arturo - an interface could point to something else. Mark - classes, enum or struct ok in the VI, but can't be referenced from outside of the interface, that should be ok. Arturo - could be used in a static context. The VI context is what is problematic. Jonathan - should be fairly easy to write it up Gord - typedef, type parameters, these need to also be mentioned. This would be a significant restriction if these can't be referenced. Mark - if a class was declared in module top, and passed to an interface, That would be ok. ... Gord - we need to very careful of the wording here. typedefs, etc. Can't cheat on strong typing by using Virtual Interfaces. Arturo - if assignment compatible Gord - a global type analysis problem is probably not the direction that we want to go in. Bigger problem than hierarchical references, don't know at elab time, what the type is. Runtime type checking would then be required. Gord - we most likely need some structural restrictions here. - if we restrict typing allowed in a VI, if not exportable through modports, will fall out of the potentially referenceable items. Arturo - whatever is allowed by a hierarchical reference today should also be allowed here, since we already have to support that. Dave - if it comes out of the VI that should be fine, only those types created inside a VI are a problem. You would then just add this to the VI type checking. Francoise - will add a note to this mantis item. 3002 Aspect Oriented Programming (AOP) features Tom - the committee requested some examples - He has been given a bunch of examples, and is working on consolidating those. Heath - could possibly take a look at what he has. Gord - the e approach requires a global source analysis. He will have a big problem with that requirement here. Cliff - maybe we could come up with a new construct that would constrain the scope of the global analysis. Gord - people should keep this in mind when they come up with examples. Dave - it might be similar to packages. - Most users may not know what these issues are up-front. Gord - name resolution issues will be a big part of what we come up with. parameterization is also a big part of this. 3046 Dotted names within inlined constraints Gord - this one is fairly straight-forward. Dave - did we have a term for the first name in a dotted name? Gord - we have been referring to it as "anchor" - not in the LRM though. - looking to follow similar rules some of the verbiage is in 23.8 - wants those rules to also apply here as well, for struct Gord - will write up a proposal for 3046 1356 Multiple Inheritance (assigned to Tom) Dave - there is a link to his DVCON paper in the mantis Tom - There is a link to 2997 (a duplicate) - The most recent note, shows a java style interface approach Dave - There are two types of functionality that should be split out a. true multiple inheritance (like C++) b. java interfaces - This mantis item title should probably mention 'java interface' Tom - this particular user was adamant that he did not want the complexity of the C++ approach. Arturo - especially with the complexity of parameters, constraints. Arturo - do we need both AOP and Multiple inheritance? Tom - we looked at all the features that come with AOP, etc. - It might be best to take a step back and re-examine all of the features that come with each. Arturo - with AOP you keep adding additional functionality with multiple inheritance you create new classes. - If have both, users need to chose which to select. - if one base functionality is an aspect, you could use AOP. (A way to get by without multiple inheritance) Gord - philosophically if get into a compositional problem. If look at it as an inheritance problem you need multiple inheritance. You could also view it as an aspect. - It is a question of how to design your project. - Agrees that adding one or the other would add additional leverage into the language. - There isn't a single author to dictate the approach. If we have both, it will be a big mess. - doesn't want to see both, there will need to be a tradeoff made for those that view it one particular way. There will be unhappy users, they may need to view their solution in a different way, depending on which approach we go with. Gord - if you get one in this PAR, you will have a fight to the death on the next par, if you try adding the other. Gord - you will need to cripple one of the features if you add both. There would be compositional problems arising. Arturo - the committee is not in the position of dictating methodology. Gord - willing to talk about this in committee. will be important to recognize that choosing one will most likely close the door to the other one. Dave - Multiple Inheritance - we are all in-sync with the Java approach. Tom - where are we with this one? Dave - what are the user problems that are behind the request. Tom - has a couple of examples in mantis 2997 Cliff - "when inheritance" Arturo - "when inheritance" is a way to have insight into a class that is built up-front. Jonathan - had some objection here.... Heath - the variable can change type at runtime. There is a difference between parameters and "when inheritance" Gord - layout of objects is done in a global sense. Doesn't want to have to do this in SystemVerilog - It is very powerful, there is a lot of flexibility. - It is a very interesting way of doing things. - There are a lot of assumptions about the underlying .... - we need tighter constraints on what needs to be analyzed. Tom - they internally tried to do something, but it became convoluted. Gord - it is clear how to do this in any language, but the problem is how it effects large systems. - we don't want to end up with a feature that can't be used in large systems. Gord - all the layout of an e object is done with regards to all of the possibilities. - There can be data explosion problems when one variation is large. - It is way too early to come up with a proposal. - Need examples, and requirements for now. Cliff - would like to see AOP examples. - AOP is asked about way more in his classes (vs Multiple Inheritance) Gord - something more stand-alone, vs tied to a specific methodology. More complete code would help. Don't want an OVM specific approach. Once you talk about a methodology, there will be a lot of assumptions. - We need to ensure we recognize any corner cases. Arturo - we need to know the philosophy behind the request. 2999 Class Handle reference inside of Constraints Dave - a shortcut in constraints. Tom - it will be a month or so before we get to this one. - AOP and Multiple Inheritance will be addressed first. Ray - handles in sub-classes could possibly lead to circular dependencies. Ray - will add a bugnote 3003 Constraint Composition Jonathan - any sensible definition might be sufficient Gord - 3075 - we may not want to touch this one. Gord - existing implementation behavior can influence a desired position Jonathan - contradictory warnings from various tools. Gord - there is currently a lot of variation among tools. If we tighten it up, we need to go with something that all existing vendors can agree to. Dave - Some of these appear to be svbc issues Dave - 3078, 3077 - the only ones that really are for the svec. 2845 virtual interface type checking versus interface type that had been defparam'ed Francoise - this is more Virtual Interface stuff. Dave - is this the same issue? Francoise - what is the type of a VI? - parameters of an interface, vs local parameters Jonathan - defparam can be used to change parameters in an interface? Mark - they are talking about sub-interfaces. - if change the sub-interface, are they the same type? - we could say that parameters in interface and any sub-interfaces must be equivalent Arturo - we don't need to add extra verbiage to address something that is deprecated (eg. defparam) Mark - if different, then not assignment compatible for a VI. Gord - does the VI ref need to track all of those parameters? Mark - we don't allow defparam in a VI. Gord - if you say it isn't equivalently typed, you need to have a way to describe it. Francoise - you could have a defparam in an interface. Jonathan - if the reference is not allowed to reach it, there is no problem. Francoise - You could change local param's of an interface Gord - the signature of an interface itself. Only need to worry about an external defparam. Dave - if a VI creates an actual interface that could be used to check for an illegal assignment. Francoise - not sure we can resolve ti this way. Gord - defparam are deprecated ** - Can't use an interface on the right hand side of assign to a VI if that interface was the target of a defparam. (there was general consensus on this approach). 2956 clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5) Arturo - thinks this one was a mistake, an omission Dave - this one is for Steve (on vacation) 2505 class select: what is allowed after the dot? (2735 is on chaining) Arturo - enum name? (ie the labels) Gord - it should probably address everything possible. - there was some question about a parameter Arturo - that was resolved the last time around. - :: can refer to type. can be used in a pre-elab context. - can we have a hierarchical reference to an enum label (in a static context)? Dave - an enum label is similar to a parameter Arturo - there should probably be a note about a hierarchical reference to an enum label. - It isn't clear that we are all in agreement on what these are. 2735 Ballot Comment #48: Chaining of method calls Arturo - isn't this just a bnf issue? Ray - There are some ambiguous cases When prefix is a function call, is it referring to part of an object? Can also use the dot to refer to something in the function. Dave - could require parens when doing chaining. Arturo - he is ok with that restriction. Ray - the requirement on parens should not be dependent on the type of a function Gord - is next.next.next be allowed? Arturo - that not allowed when next is a member. Ray - doesn't like the idea that the need for parens is dependent on the contents of the parens. Francoise - should probably require () when chaining. Gord - never liked the idea of making () optional. Mark - was also ok requiring them here. Dave - there was a question related to the svac about sampled values - he couldn't remember details of the example. 4. Next meetings June and July 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 Gord?, 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 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