SV-EC committee meeting. Monday May 24 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_May_24_2010_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 0000 0000 4321 Meeting Days: ------------------------------------------------------------------------ (2121) Day (4062) (0000) Month (5544) (1111) Year (0000) ------ Attendees -------------------------------------------------------- 1. (-AAA) Arturo Salz 3 2. (AAAA) Dave Rich 4 3. (AAAA) Francoise Martinolle 4 4. (AAAA) Mehdi Mohtashemi 4 5. (AAAA) Neil Korpusik 4 6. (AAAA) Ray Ryan 4 7. (AAAA) Gordon Vreugdenhil 4 8. (AAAA) Steven Sharp 4 9. (AAAA) Heath Chambers 4 10. (--AA) Don Mills 2 11. (AAAA) Mark Hartoog 4 12. (AAAA) Tom Alsop 4 13. (-AAA) Jonathan Bromley 3 14. (-AAA) Neil S 3 Marvel 15. (AA--) Cliff Cummings 2 Sunburst Design 16. (---A) JL Gray 1 Verilab 17. (AAAA) Alex Gran 4 Mentor 18. (A--A) Daniel Schostak 2 ARM 19. (---A) Kevin Johnston 1 Verilab 20. (-A--) John Halvicek 1 Freescale 21. (-A--) Scott Little 1 Freescale 22. (--AA) Tracy McDermott 2 Sunburst Design ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// May 24 2010 ///////////////////////// One NOTE on voting rights: - We are going with 2 out of last 3 (or 75% of total started from April 12 2010) for voting eligibility, please attend official meetings so you do not lose your eligibility. 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt The chair reviewed the patent policy. Cliff, Steven - move to assume that the patent policy was read. Passed unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ April 26 2010 and May 10 2010 meeting minutes http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_April_26_2010_Minutes.txt http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_May_10_2010_Minutes.txt Move: Alex, May 10 attendee list days for Alex should be 3 not 2. Second: Tom Passed unanimously 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 P1800WG has requested the committees to provide a time-estimate/schedule for this list, how many can be completed by the deadline of October 2011. We need to provide the schedule/time-line by June 10 2010. Here is the list of 25 plus 10 that we had agreed during prvious sv-ec meeting. [NOTE: the estimated hours are listed in a table appended at the end of this minuts for reference] Cliff - have roughly 35 meetings available until October 2011 We could go weekly if we need to, we can assign hours, 1/4 hours or larger, certain number of hours. Mehdi - was talking about categories to determine number of hours Issue 1 -- 2848 Mark - we could just declare this one case to be illegal. Gord - struct in an interface Mark - cases with virtual interfaces, would be the only exception Gord - we need to make sure that users are clear on this Gord - when an interface contains a struct, an instantiation of that interface creates a unique struct for each instance of the interface. Referencing different types. Steven - when create a different instance, they are different types. - when use a virtual interface, you can get to more than one instance. You don't know at runtime, which type is to be used. Mark - you could put those types in a package and reference them from the package. Cliff - 4h estimate - assuming we require users to use a package for the situation with virtual interfaces. Steven - two types in the same design unit which are parameterized the same way, that could be another approach. Gord, Mark - not keen on that approach. Francoise - if the embedded class is only used within the interface, it is ok - the problem is only for external references. Steven - any external reference through the virtual interface is illegal. There was some consensus on this. Issue 2 -- 3002 -- AOP Gord - my vote is no (doesn't want to add this to the language) Cliff - extending enum is a problem - as mentioned in svbc Steven - enums are hard. Gord - AOP is tough to do, given what vendors need to assume to have scalable systems. - You need to compile entire universe of design, otherwise you end up with a large set of issues. Cliff - users may want this bad enough to live with that problem. Gord - in 'e' there is a distinct division between testbench and design. - for SystemVerilog there isn't a way to distinguish between the two Steven - not everyone uses program blocks. Gord - early on tried to make a distinction between the two Dave - interfaces, binds, virtual interfaces, configurations. Gord - it isn't a clean easy thing to do. Cliff - could it be confined to programs only? Steven - what if don't want the reactive region? Dave - classes can be placed in packages, you don't know if they will be used in a program. Tom - if only used in program block? Gord - you still need to know the entire universe. - object layout issues. Steven - doesn't sound likely to be able to strictly associate a testbench with a program. - there are too many ways to cross module boundaries. Tom - would like to get feedback from his users on the need for AOP. Gord - what problem do they want to solve? This might help. Cliff - 12h - assumes we get input on what we really want to do as users. - keep bubbling stuff up - after 12h we decide if we punt or go forward. - This is how much time to get to a decision point Mehdi - we can take this type of estimate. Gord - the 12h is just to determine if it is feasible to do something. Cliff - agrees that it sounds risky to be able to get full AOP Dave - parameterized types is also an issue Mark - yes, that is not something in other languages that support AOP. AI/Tom and others, any more clarifications from users perspective. Issue 3 -- 3046 Gord - 1h - it should be straight-forward Issue 4 -- 1356 - multiple inheritance Mark - there is the C++ way and the Java way Dave - thought it might be trivial, until looked at parameterized classes. - library developers want it. - it will be hard, but not as hard as AOP Cliff - 12h Gord - parameterized class and a few other language features. - Will require a serious discussion on types. SystemVerilog may require dynamic typing for certain parts of LRM. We would need to come up with reasonable scenarios. There could be serious stone walls to doing this. Francoise - who wants it? Heath - has some support for it, AOP seems to limit it. Tom - not high on the list. Mark - C++ has it, but it is complicated, makes it hard to use. - can be hard to predict what functions will get called. - The Java approach uses java interfaces. It doesn't really provide code reuse. Dave - the ansi version of c++ tried to address issues. Mehdi - thinks this is harder than AOP Gord - not harder than AOP - there will be deep technical issues on both AOP and multiple inheritance Cliff - 16h Mark - there should be one group that talks about AOP and multiple inheritance. Heath - There are situations where AOP comes in handy - you may be trying to write to a new standard that hasn't come out - you may want to use the same generation mechanism, but need to just add a new aspect when know more about the new information. AI/users - what are the particular requests? Issue 5 -- 3001 Tom - 2h Gord - yes, this one is easy Issue 6 -- 2999 Ray - using handles in "solve class1 before class2" - This is to avoid having to specify all class members Steven - just another way to do what you can do today. Ray - it seems to be legal today, but not sure it does what you want. - it probably wouldn't do anything if you specified it today. Steven - they are referred to as variables today. - sounds like syntactic sugar. Cliff - 3h Issue 7 -- 3003 - constraint composition Tom - wants one constraint to be able to refer to other constraints Ray - has an issue with it being procedural instead of declarative - there are also some issues about name resolution - we need a more detailed set of requirements Tom - myObject1.contains(myObject2); myObject1.randomize(); Cliff - 5h AI/Tom - we need more clarification Issue 8 - 3082 - set of differences between different vendors Gord - some are straight-forward, some will cause animated discussion Francoise - some of these are very different items. The list from page 10 1. Elaboration order of bind directives (e.g. bind interfaces into DUT and then reference bound interfaces in succeeding bind directive; can also have effect on random stability) 2. Format of $typename return value should be standardized 3. Order of randomization method invocations if randomizing nested objects 4. Should default argument be repeated in class method out-of-block declaration? 5. Result of $sformatf("%0b", value) if value[] === x (is string representation padded with leading zero?) 6. Should .name() for escaped identifier include "\"? 7. Should $value$plusargs("=%s", value) set value to "" or "0" for += / +=""? Gord - 3075 elaboration order - this would be tough to define Daniel - he suggested having more stability within a single implementation Steven - if tool options are changing the order, that is more of a vendor issue Mehdi - some of these items appear to be for the sv-bc Gord - the little ones can be done in either committee Mehdi - 1, 2, 3 are the big ones Gord - typenames should be in svec, parameterized classes is the big one Steven - 2. not so bad until consider parameter values Mark - parameterized classes create a lot of odd corner cases. Gord - $typename for structs, recursive problems can occur. - $typename should not be taken as being type matching. Should just view it as a string to be set. Steven - that sounds more like a debug type of thing. Gord - 1, 2 - easily one meeting each. Mehdi - 8h Issue 9 - 2845 - Gord - we could say just don't do that, but it won't help users. Steven - instead of adding defparam to the list, prevent from allowing on a virtual interface. Mark - there are some cases that it would be appropriate. Gord - it will take some time to decide what we can agree to. Steven - would require a set of new rules to be defined. Mehdi - 4h - to decide what to do Issue 10 - 2956 - "process" definition Dave - this one should be simple Steven - he can do this one. Mehdi - 0.5h Issue 11 - 2505 - trivial Gord - was raised late in name resolution discussion. Thought there was some difference of opinions among vendors. Mehdi - 3h Issue 12 - chaining of method calls Steven - it is just allowing multiple calls back to back. Gord - an issue if consider the unparenthesized call form. Ray - that creates ambiguity Steven - scope into the function, etc. Gord - if require a paren, ,there are some other gotchas. - should be doable if people agree on a set of restrictions. Gord - an assignment operator in the middle of the set of calls. Steven - an embedded array select would also be problematic Gord - virtual interface reference being returned and then use a dot - would that change the meaning? Cliff - 4h Issue 13 - 1706 - virtual interfaces intf i(); initial C::i = i; // assigning to a virtual interface always_comb x = C::i.x; Steven - if everyone agrees, it could be straight-forward Gord - if just say doesn't count on either side, it is easy to state. - Users may not like it (eg always_comb) - it could go fairly quickly Mark - classes are intended to be synthesizable, so rules that apply to just synthesis need not apply to classes. Gord - boils down to whether we need a resolution function. Mehdi - 1h Issue 14 - 2488 - use of virtual methods in class constructors Gord - there will definitely be some discussion on this one. Mehdi - 2h - assuming we don't allow it and there is consensus. Issue 15 - 2112 - use of nba in a class Dave - will help with generalized mailbox Mark - to a variable name. member (not a handle) Steven - is useful to avoid classic race conditions. Gord - need to be careful about when a handle gets changed. - still have a valid reference until the actual assign Steven - mailboxes, queues - heard requests in this area. - nba to a queue using $. If do it twice, you could end up extending the length twice. This could be problematic. The Q could have also been shortened before the assign occurs. - We need to split apart the assignment and extension. - If extend this to Q and mailboxes, it will be much tougher. Gord - there are potential possibilities of getting outdated references. Steven - for classes, we have already separated instantiation and assign. Steven - 2h - if just for classes. Mehdi - 2h Issue 16 - 3028 - constraints for unique array elements Ray - giving clues as to the intent would improve performance - might be useful to not restrict it to just arrays. Mehdi - yes, that sounds interesting. Ray - it sounds like we could converge on this one quickly Ray - we already have the unique keyword, that will help. Mehdi - 2h Issue 17 - 2950 - virtual prototypes Francoise - protected, local Dave - a local virtual method doesn't make sense Gord - once protected, it should stay protected. Dave - the same rules that exist today for virtual (not required in derived class) should apply to protected. Steven - doesn't like that rule. Cliff - he teaches coding style to always specify it Mehdi - 2h Issue 18 - 2794 - queue method return status Gord - it should be easy Mehdi - 1h 4. Next meeting ----------------------------------------------------- Monday June 7 2010 11:00-1:00pm Tom, Heath - not available on June 7th. FOR References: -------------------- ============ 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 19 2993 20 1442 21 2953 22 1349 23 2949 24 2451 25 2987 26 3006 27 3004 28 2998 29 2117 30 No Mantis 6 31 2928 32 2787 33 2972 34 2996 35 2988 36 No Mantis 4 ====================================== 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