SV-EC committee meeting. Monday November 22 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_November_22_2010_Minutes.txt ] Meeting number: 75% = 8 out of 10 meetings attended ------------------------------------------------------------------------- 1000000000 0987654321 Meeting Days: ------------------------------------------------------------------------ (2021213101) Day (2851730629) (1111000000) Month (1100998887) (1111111111) Year (0000000000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAAAAA) Arturo Salz 10 - y 2. (AAAAAAA-AA) Dave Rich 9 - y 3. (AAA--AAAAA) Francoise Martinolle 8 - y (75% attendance) 4. (AAAAAAAAAA) Mehdi Mohtashemi 10 - y 5. (AAAAAAAAAA) Neil Korpusik 10 - y 6. (AAAAAAAAAA) Ray Ryan 10 - y 7. (AAA-AAAAAA) Gordon Vreugdenhil 9 - y 8. (-AAAAAAAAA) Steven Sharp 9 - y 9. (AA---A--AA) Heath Chambers 5 - y (2 of last 3) 10. (-AA----AAA) Don Mills 5 - y (2 of last 3) 11. (AAAAAAAAAA) Mark Hartoog 10 - y 12. (AAAAAAAA-A) Tom Alsop 9 - y 13. (AAAAAAAAAA) Jonathan Bromley 10 - y 14. (A--AAAA--A) Neil S 6 15. (---A-AAAAA) Cliff Cummings 6 16. (AAAAA-A--A) Alex Gran 7 - y (2 of last 3) 17. (--A-AAAAAA) Daniel Schostak 7 18. (-----AAAAA) Swapnajit Chakraborti 5 19. (AA-AAAA---) Linc Jepson 6 - y (2 of last 3) 20. (AAA-------) Tony Tsai 3 - y (2 of last 3) 21. (A-A-------) Brandon Tipp 2 - y (2 of last 3) 22. (A---------) John Halvicek 1 23. (A---------) Scott Little 1 17 people will have voting rights in the next meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// November 22 2010 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Heath Second: Dave Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ November 8 2010 meeting [not yet uploaded to sv-ec site] 3. Updates from P1800 November 11 2010 meeting --------------------------------------------------------------------------- Participation and voting guidelines, other updates. [if any available] Tech sub-committee reports Neil - All new proposals should have a title indicating which Mantis item they are associated with. - Also, the Champions should review all proposals for their conformance to the formats specified for proposals in addition to the proposal's technical content. - Technical committees need to elect and relect chair and co-chair. - WG has agreed that TC can work on 'pre-cursor, pre-requisite' along with the mantis item of part of 25. It is up to the committees to work on these. - The voting rigths is gone to Governers, CAG, If approved the following will be the new participation rules - The rules will become more rigid. Only Advanced members will be able to vote - The new rules will go into effect in January, if they get approved. - The CAG Won't consider changes for 6months, once approved - P1800 TCs can allow a few experts for a limited number of meetings (3 times/year) Possibly a rotating pool of experts - Accellera is currently planning to have one DR and one DRA. The proposal would allow up to 3 DRA for Accellera. SI2 is also currently an Advanced member of the IEEE-SA. SI2 could also have a DR and up to 3 DRAs. Dave - various mechanisms for people to attend, Accellera can assign couple of folks to attend, one DR and one DRA.. Neil - First draft of the new LRM by end of Feb 2011, feature freeze date is October 1st. 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. 2848, 2845 Francoise has posted proposals 2848 "It shall be illegal to use an interface containing declarations with a strong datatype for the declaration of a virtual interface, and access those declarations through the virtual interface. A strong type is a datatype that only matches itself in its instantiating scope: it does not match the same declared type in a different instantiation. Strong types include class types, enumeration types, unpacked struct and union types." Francoise - "strong type" not declared It means they only match themselves. Jonathan - does the type compatibility section have any language for this? Possibly 6.22 Francoise - 6.22.1 (d) seems to be useful Jonathan - It is illegal to use an interface that contains any declaration whose type that would not match in a different instance of the same interface. Gord - that is too strong, they don't have to match. Two arrays should not cause it to become illegal. If they have types that are not assignment compatible is closer to what we want. It boils down to, The types in the VI are "safe to use". Suspects it boils down to assignment compatability Jonathan - assignment compatible even has some drawbacks. Gord - arrays with different bounds, accessed through a VI, is it ok? Ending up with different bounds is unusual, eg defparam. How closely defined do the interfaces does it need to be? Gord - if access with definite bounds or indicies could be an issue. Francoise - could we just list what isn't allowed? Arturo - trying to define matching VI types Gord - the types of xxx are defined to be different in each instance. Francoise - illegal to use an interface that contains a type that can't match the same type in a different instance of the same interface Arturo - doesn't like the term "strong type". - non-integral type? Gord - disallow an unpacked array? - If they match (ie same bounds) they should be allowed. - for a class - each is different. Arturo - typedef for an unpacked array Gord - a typedef won't change the rules for matching. It is just an alias. Jonathan - "instance specific data type" could possibly be a better approach Arturo - isn't it just an issue for class? Gord - struct, class, enum, union all behave the same way Mark - only unpacked? Jonathan - the restrictions on unpacked arrays wouldn't be a good idea Gord - if can't use a VI reference for an interface that contains an unpacked array seems to be too limiting. For a class it is less limiting, and seems less likely what you really wanted. Jonathan - wants the restriction A base class, in interface a class derived from the base class. Would like to be able to do that. Gord - determining when you want the errors. Making illegal only when "accessed" is tough to define. Possible runtime errors. Would like to be able to check before runtime. Would need to avoid the "halting problem" if we go with the "if not accessed" approach. Francoise - The proposed wording wouldn't work for arrays. Unpacked arrays with different bounds would be an issue. Jonathan - if we don't allow defparams, that couldn't happen. Francoise - should it be a warning? Arturo - likes the use of the "instance specific" wording. Francoise - a typedef inside an interface of just the xxx type Jonathan - that is also true of unpacked arrays. Francoise - this is the first time we have defined this concept. Gord - it is just clarifying 6.22 paragraph 3. - packed vectors are not included. - the set of types for which instances don't match. Gord - backed to thinking it should be "matched" Francoise - doesn't think the two mantis items should be combined. - could add the appropriate notes to the Editor. Arturo - believes it is "matching types". 2845: virtual interface It shall be illegal to use an interface for the declaration of a virtual interface if there is a defparam to a parameter declared in that interface or any of its sub-instances. Francoise - didn't understand Gord's email comment Gord - a defparam from within an interface? - a defparam from outside the interface to a type inside an instance of an interface. - if inside an interface, all of the interfaces will be the same. - only concerned about a defparam that is outside the interface. Mark - is ok limiting it, such that a defparam is not allowed to an interface parameter, whether it is inside or outside the interface. Gord - only reason is that if customers are already doing it inside, we will need to continue to support it. We could make it more narrow to address the specific issue. Ok to leave it more general. Francoise - will add a note to the Editor in the proposal. Mehdi - we will vote on the proposal next time. 1356 Interface Classes [Multiple inheritance] Tom - would require about a half hour to get into more detail. We will do it next time. 2505 Neil S. : class select Neil - There was discussion on accessing enum constants using the dot operator. Francosie - parameters can be accessed via a dot thinks enum constants should also be allowed. Arturo - What is the benefit for having two ways (eg. scope operator today). Gord - part of the member of the class. static reg can also be accessed via dot. Hierarchical name to it using dot. Jonathan - agrees could have some code that accesses items in an object, would be clumsy if have to switch modes. It would be useful to be able to write macros to access items without having to fiddle around. Arturo - concerned about having two different ways to access them Gord - thinks enum constants should be visible via the dot. - the label can be accessed, not the type. Arturo - also will be true for modules? (not just classes) Gord - yes. - if a localparam would be visible, an enum constant should also be visible. Mehdi - hopefully we can vote on it next meeting. 2506 Coverage Shapes [ for 2953 & 251 ] Mehdi - this was in replacement from 2953, algorithmic generation of covergroup bin contents, John H. - Assumes there could be changes required to the current proposal. - Issue is for entities being crossed that have non-trivial constraints. - proposing to add a mechanism to the cg to address that need - constructs from coverpoints and some for the cross Symbolic representation of those representations. An expression or a function call used to determine when the value is interesting. not correlating with other coverpoints at this point. - Would like to be able to call a function or write an expression - crosses - the criteria is wrt what is being crossed. An algorithmic way to generate the combinations. - Several people, both freescale and synopsys have contributed. Would like to declare the type of a coverpoint, as opposed to the self-determined type of an expression used. - Will use a coverpoint name later, so need to know its type. Mehdi - need to make sure it fits with the p1800-2009 LRM, as well this is to be in pdf with name having the mantis item number 2506 in it. Gord - it is in section 19, 19.5 looks to be right John H. - the proposal was done back in 2009. - this type may not be critical, but it seems like a good idea. Jonathan - it is a really good idea, if doing arithmetic on it John - Coverpoint bin specification Ray - with-expression returns true or false John H. - the tool will conceptually iterate over the candidate space. Gord - Some text describes when things are being done. Need to describe what a function like my_func is allowed to reference. Can it access a class method, or class members? Visibility questions need to be addressed. - Agrees with the intent of giving flexibility to implementations. Need a larger set of restrictions if allow this flexibility. - Can there be an assertion in such functions? - fork/join, etc. - If not carefully disallowed, users may start using things that were never intended. John H. - being conservative at this point is alright. Gord - can't be an arbitrary system space that interacts with the algorithmic space. - Want to make sure it is closed enough that implementations could do things symbolically or in other forms and that doing other things is not valid. John H. - the use cases motivating this don't require crazy things. Ray - eliminating duplicate values - what if we have a fixed number of bins? The examples all show the number of bins being dynamic. - eg 3 bins and 27 values - if 6 are selected to be true, based on the function call, how are they divided into the fixed number of bins? John H. - if specify a fixed number of bins, could weed out values doesn't remember how they thought it was suppose to work. They did consider this scenario. Expression based list of values and range-specifications were intended to coexist harmoniously. - Cross bin 'with' clause section Assuming a product of bins of coverpoints being crossed. Made up some of the terminology used in this section. There are several different policies that could be in place. - If an expression is satisfied, the tuple is accepted - If all expression are satisfied, include the tuple - Proportions could be combined bins two[] = b with ((item % 2) ==0) // ==0 was missing bins three[] = b with ((item % 3) ==0) Jonathan - users may find the "cherry" example to be confusing. Intuition is that only if a==b would end up in cherry bin. Ray - either default will make some users unhappy. A bin doesn't necessarily match a single value. Once that is understood, this makes more sense. Jonothan - it has 'with (a==b)', that is the source of the confusion. bins cherry = (binsof(b) intersect [0:50] && binsof(a.foo) intersect [0:50]) with (a==b); Ray - this proposal now makes a lot more sense. Concern - dist 0.5 bins apple = X with (a+b < 247) dist 0.5; The definition should be done such that different vendors chose the same thing. What if vendors interpret 0.5 in different ways? John H. - the number of values in a bin could also become large. Approximation techniques could also skew results. The controlling bins in most of their cases are single valued. - until there are other use-cases we don't need to allow it. - If can define the functionality without having to use all of this, would possibly be a better approach. Ray - "if see this many" is another approach. - need a special way to say you want all, may not know how many that would represent. John H. - reformatting the proposal will the the easy part. - user can use a procedural mechanism to specify bins that are created. Both for a coverpoint and for a cross. Bin tuples that go into a cross bin. Ray - wouldn't that need a way to refer to a bin? for a cross, need a way to reference a bin to do that. John H. - the proposal just goes through values and a section mechanism. Arturo - the mechanism is used to create the desired shape. Ray - cross - doesn't see how to explicitly specify, versus using a selection mechanism. John H. - A cross is similar to creating a struct. User specified array is required. aXb : cross a, b { bins one = < '{ '{1,2}, '{3,4}, '{5,6} } >; // bin tuples } Ray - '{1,2} means the bin with value 1 and bin with value 2 Gord - could have ',' following this set of 3 pairs, and then have another list. Arturo - yes, but would need sizes to be appropriate. Gord - the functions are computing one set of pairs for one bin element function cg::aXb::CrossQueueType myFunc2(int f_lim); for (int i = 0; i < f_lim; ++i) myFunc2.push_back(cg::aXb::CrossValType'('{2*i,2*i})); endfunction AI/John H. - put the proposal into the required format AI/ everyone to review and be ready to discuss during next time. 2993: Arturo : Coverage 2506 [coverage] 3003 constraint composition 3082 Daniels' top items [3075, 3076, 3077, 3078, 3079, 3080, 3081] 2735 ballot comment #48, chaining.. 3046 5. Next meetings November and December 2010 ----------------------------------------------------- Monday December 6 2010 Regular biweekly Monday December 13 2010 Special meeting [if required] Monday December 20 2010 -- NO MEETING Monday January 3 2011 -- NO MEETING Monday January 10 2011 Special meeting [if required] Monday January 17 2011 Regular biweekly Monday January 31 2011 Regular biweekly FOR References: --------------------------------------------------------------------- ============ from November 22 2010 meeting =================== AI: 2848, 2845; Franocoise update the proposals. AI: 2505; Neil S., update the proposal. AI: 2506; put the proposal into the required format AI: everyone to review and be ready to discuss during next time. ============ from November 8 2010 meeting =================== AI: Minutes; Mehdi - will check for consistency between the left and right sides for the attendance. AI: for 1356 Multiple Inheritance (interface classes) Mehdi - will make a request to the WG on this. General statement about being allowed to work on mantis items that are affected. AI: Jonathan - NULL within $cast AI: Gord - the OVM people would like to have that. Covariant and Contravarianct type extensions. you allow method that do not allow exact type signature of over-written method, but can return the objects of the type of original return type, impact of that would be on Interface classes. AI: Gord - Overwriting of virtual method section AI: Tom - update the proposal (to number 4) ============ from October 25 2010 meeting =================== AI: 1356 Tom - update the proposal, make corrections and more normative text. All - provide more detailed feedback to Tom. ============ from October 11 2010 meeting =================== AI: related to 2505 All - should we allow enum constants to be accessed by the dot? AI: 2953 Mehdi - make 2953 a child of 2506 Mehdi - make a request in this week's P1800 meeting to work on 2506 AI: 2080, 1672, 802 Neil - update the mantis items (3 of them) AI: 251 Mehdi, leave mantis 251 open AI: 2794 Mehdi, reopen mantis item for feedback Jonathan: update AI: 2949 Jonathan: send email to Brad to get clarification on his feedback. ============ from September 27 2010 meeting =================== AI: 3003 Tom - will get feedback on specific examples. (see 18.7 for information on the with-clause) AI: 3003 Jonathan - will get an email discussion going. ============ from September 13 2010 meeting =================== AI: Coverage item Swapnajit - will provide a note for clarification, to be added to Mantis 1802 AI: Coverage item Swapnajit - will put together a proposal for this issue. [related to 19.5.3 wildcard specification] AI: 2848 Francoise - Will do a write-up for this proposal. AI: 2845 Francoise - will try to write-up for this. ============ from August 30 2010 meeting =================== AI:2956 Mehdi making a note to the editor for adding cross reference. AI: 2794 Jonathan will make the friendly amendment. AI:3028 Jonathan create a proposal and upload it for more discussion and vote next meeting. ============ from August 16 2010 meeting =================== AI: 3028 Jonathan - write up the parallel proposals. AI: 2794 Jonathan - add text for the case where indices are x, z AI: 1442 Steven - check if Shalom's comments make this issue moot. AI: 1349 Steven: create the proposal for 1349 AI: 2451 Steven put a proposal together. AI: 2993 Tom; will check internally to see if these meet their needs AI: 2993 Mehdi; upload the email as a note to the mantis item AI: 2993 Arturo; will donate their implementation. ============ from Aguust 2 2010 meeting =================== AI: 1706 Steven put together an email for bc to provide feedback on 4 options Mehdi can send to sv-bc AI: 2993 Swapnajit: add a note to the mantis item as to where we currently are in the process. AI: 2953 Ray - take a look at this one ============ from July 19 2010 meeting =================== AI:Tom get confirmation from users about exact intent of the original request for 3001 AI: Francoise will add a note to the mantis item 2848 AI: Gord will write up a proposal for 3046 AI: Ray will add a bugnote 2999 ============ from June 21 2010 meeting =================== AI/Mehdi - For number 30 on the list, 'no-mantis item 6' send email to Matt about linking this request to mantis 2991. AI/ALL - assigned leaders/champions to start looking at the top 25 items on the list and plan for proposals/discussions/reviews. ============ from June 7 2010 meeting =================== AI/Tom - some examples would be useful [mantis 2987, soft constraints] AI/Cliff - what is actually required. [mantis 2117] Allow extending of covergroups in classes AI/Cliff, John H. - more details on this request, item number 30 [no mantis 6: allow re-use of enumerated names (slide 31) AI/All - find mantis items that can be closed, or easily resolved. - any of the 0.5h estimate items could be considered as well. ============ from May 24 2010 meeting =================== AI/Tom and others: mantis 3002 AOP: any more clarifications from users perspective. AI/users: mantis 1356: Multiple inheritance:what are the particular requests? clarifications. AI/Tom - Mantis 3003, we need more clarification from user base ============ from May 10 2010 meeting =================== AI/Jonathan - create mantis items for No-Mantis-10. Completed action items: ============ from April 26 2010 meeting =================== AI/Mehdi - add a column for enhancement versus clarification AI/Mehdi - add a column for amount of work required. AI/Mehdi - add sheets for the various categores in the Google doc. AI/Mehdi - send out a link to the p1800 spreadsheet. AI/Mehdi - add a column for duplicates AI/All - send input on the list of categories. AI/ALL - until May 5th to provide any inputs on the spreadsheet. ============ from April 12 2010 meeting =================== AI/Mehdi - Look at the Google Docs and creaet spreadsheet for collaborative efforts. Also add cross committee column to the spreadsheet. AI/All - send inputs on any new items by April 24 2010, this is deadline for any item that is not already in the mantis database. AI/All - prioritize and categorize list of items that are in the spreadsheet to be reviewed during the next two sv-ec meetings. AI/Neil - email to cliff on proxy right --------------------------------------------- Summary table: Assigned Lead/Champions --------------------------------------------- 1 2848 Francoise 2 3002 Tom, Dave, Jonathan, Francoise, Arturo, Neil S., Cliff, Gord 3 3046 Gord, Franocise, Mark, Ray 4 1356 Tom [same with 3002] 5 3001 Jonathan, Tom, Francoise 6 2999 Tom, Ray, Arturo, 7 3003 [2987, 2988] Jonathan, Tom, Ray, Arturo, 8 3082 Daniel, Jonathan, 9 2845 Francoise, Mark, Alex Neil S., Gord? 10 2956 Steven, 11 2505 Neil S., Mark, Francoise 12 2735 Arturo, Steven, Gord, 13 1706 Mark, Steven, Francoise, 14 2488 Steven, Francoise, 15 2112 Dave, Steven, 16 3028 Arturo, Ray, Neil S., Mehdi, 17 2950 Francoise, 18 2794 Jonathan, Steven 19 2993 Tom, Ray, Swapnajit (cadence) 20 1442 Steven, 21 2953 Ray 22 1349 Steven 23 2949 Jonathan, Steven 24 2451 Steven, 25 2987 Jonathan (combining 2987, 2988, see 3003) ------------------------------------- [next 10] 26 3006 Ray, Steven, 27 3004 Tom 28 2998 Tom 29 2117 Cliff?? 30 No Mantis 6 could be linked with 2991 with sv-bc 31 2928 Ray, Arturo, 32 2787 ?? (Daniel)?? 33 2972 ?? (Daniel)?? 34 2996 Tom, 35 2988 already assigned (see 3003) 36 No Mantis 4 related to AOP (already covered) -------------------------------------------------------------- == List with estimates ======= hrs top 2t mantis Id 4 1 2848 12 2 3002 1 3 3046 16 4 1356 2 5 3001 3 6 2999 5 7 3003 8 8 3082 4 9 2845 0.5 10 2956 3 11 2505 4 12 2735 1 13 1706 2 14 2488 2 15 2112 2 16 3028 2 17 2950 1 18 2794 4 19 2993 0.5 20 1442 6 21 2953 0.5 22 1349 0.5 23 2949 4 24 2451 4 25 2987 92 total 46 (2hr sessions) 0.5 26 3006 4 27 3004 2 28 2998 4 29 2117 4 30 No Mantis 6 0.5 31 2928 4 32 2787 2 33 2972 2 34 2996 0 35 2988 0 36 No Mantis 4 23 total 11 sessions ====================================== top 25 Id Number of Votes weighted vote Summary Degrees of difficulty Cateogory Sub-Category 1 2848 7 159 Is it legal to assign an interface containing class declaration to a virtual interface med Virtual Interface and class 2 3002 8 125 Aspect Oriented Programming (AOP) features High class constraints 3 3046 8 112 Dotted names within inlined constraints Low class Strings/Arrays 4 1356 6 112 Multiple Inheritance High class Strings 5 3001 9 102 Proper Polymorphic behavior of instantiation low class Arrays 6 2999 7 99 Class Handle reference inside of Constraints med class constraints 7 3003 6 98 Constraint Composition High Randomization Strings 8 3082 7 96 (4) Ambiguity resolution (see slide 10 for examples of parts of the Standard that have been interpreted differently by different simulators) 9 2845 4 84 virtual interface type checking versus interface type that had been defparam'ed high Virtual Interface Misc / function proto 10 2956 4 76 clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5) low Process control 11 2505 4 76 class select: what is allowed after the dot? low class 12 2735 4 73 Ballot Comment #48: Chaining of method calls med class constraints 13 1706 4 72 Meaning of static prefix for virtual interface assignments Virtual Interfaces 14 2488 4 69 Are virtual method calls legal within class constructors? med VI OO classes 15 2112 6 69 Remove restrictions on NBA assigments to class members med class constraints 16 3028 6 68 constraints for unique array elements. Med Randomization 17 2950 4 67 virtual method prototype matching low class 18 2794 4 64 Clarify queue methods return status low class 19 2993 4 63 Cross cover points across different cover groups med Built-in Methods 20 1442 3 63 Clocking blocks legal in modports, missing from text description in 20.9 Functional Coverage 21 2953 6 61 Algorithmic generation of covergroup bin contents high clocking block 22 1349 5 61 fork/join_none: what if parent thread terminates without blocking statement? Functional Coverage 23 2949 4 60 LRM is silent about the semantics of referencing a clocking block output low Process control constraints 24 2451 6 58 Omitting body defaults med clocking block constraints 25 2987 6 56 Soft Constraints med class Misc / function proto 26 3006 5 55 LRM doesn't say explicitly what should happen if null pointer is randomized low class Data Types 27 3004 5 55 Ability to declare/qualify classes/methods/variables/constraints final med class Virtual Interface 28 2998 4 55 Solve Before enhanced low Randomization class 29 2117 3 52 Allow extending of covergroups in classes high Functional Coverage class 30 No Mantis 6 5 51 (3) Allow reuse of enumerated names (slide 31) cross-committee Randomization 31 2928 3 50 ambiguous restriction on function calls in constraint expressions low Randomization Randomization 32 2787 3 50 reference via scope operator to parametrized superclass item med class Randomization 33 2972 3 49 add class constructor/method, task/function overloading High class Randomization 34 2996 4 49 Method overloading High class Randomization 35 2988 2 48 Defaults Constraints med Randomization Process control 36 No Mantis 4 2 47 (1) AOP when-inheritance (slide 31) Class/AOP Functional Coverage