SV-EC committee meeting. Monday September 13 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_September_13_2010_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 00000 54321 Meeting Days: ------------------------------------------------------------------------ (13101) Day (30629) (00000) Month (98887) (11111) Year (00000) ------ Attendees -------------------------------------------------------- 1. (AAAAAAA-AAA) Arturo Salz 5 - y 2. (AA-AAAAAAAA) Dave Rich 4 - y 3. (AAAAAAAAAAA) Francoise Martinolle 5 - y 4. (AAAAAAAAAAA) Mehdi Mohtashemi 5 - y 5. (AAAAAAAAAAA) Neil Korpusik 5 - y 6. (AAAAAAAAAAA) Ray Ryan 5 - y 7. (AAAAA--AAAA) Gordon Vreugdenhil 5 - y 8. (AAAAAAAAAAA) Steven Sharp 5 - y 9. (A--AA--AAAA) Heath Chambers 3 10. (--AAA----AA) Don Mills 3 11. (AAAAAAAAAAA) Mark Hartoog 5 - y 12. (AAA-AAAAAAA) Tom Alsop 4 - y 13. (AAAAAA--AAA) Jonathan Bromley 5 - y 14. (AA--AA--AAA) Neil S 3 - y Marvell 15. (AAAAA--AA--) Cliff Cummings 5 - y 16. (----------A) JL Gray 0 17. (-A--AAAAAAA) Alex Gran 2 18. (AAAAAAAA--A) Daniel Schostak 5 - y 19. (----------A) Kevin Johnston 0 20. (--------A--) John Halvicek 0 21. (--------A--) Scott Little 0 22. (------A--AA) Tracy McDermott 0 23. (AAAAA------) Swapnajit Chakraborti 5 - y 24. (AA---------) Linc Jepson 2 - y 74ze 16 people will have voting rights in the next meeting ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// September 13 2010 ///////////////////////// Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Cliff to have read Second: Heath Abstain: Opposed: Passed/approved unanimously 2. Approval of previous meeting minutes: ------------------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_August_30_2010_Minutes.txt Move: Cliff to approve Second: Jonathan Abstain: Heath (was not there) Opposed: Passed/approved unanimously 3. Updates from P1800 ------------------------------------------------ Participation and voting guidelines, other updates. [if any available] Next meeting October 14 2010 4. Continue Review and discussion of top 25 issues and categories: ------------------------------------------------------ 2993 - coverage item will be first [as suggested in previous meeting] Arturo - no porposal yet for this, next meeting. Swapnajit had posted some questions regarding coverage. http://www.eda.org/sv-ec/hm/7467.html Swapnajit - two items, two clarifications, open_range syntax for specifying the range of a bin Gord - 19.5 at end, there is an example at the end of that section that seems to agree with what Swapnajit is saying. The values used in bins for bin construction are effectively captured at cg construction time. Mehdi - we could add a clarifying sentence on this point. Arturo - constants as per the construction of the cg Jonathan - should we allow escaping references into the class be allowed as constructor arguments as well? Gord - would be fine with that as long as it was clear that the values of those references were used at the point of construction. Steven - there could be user confusion, but there is no technical problem. Gord - it is similar to "normal confusion" that we already have today. Steven - sees no problem accessing any variable in the design. Dave - is this the same as 1802? mantis 1802 discusses a similar issue Arturo mentioned in that mantis item that there could be an issue with coverage merging if we allowed this. Gord - in 1802, Doug was suggesting a change similar to what Jonathan is now suggesting. Steven - same problem as when different values are passed in? Gord - 19.11.3 Type coverage computation AI: Coverage item Swapnajit - will provide a note for clarification, to be added to Mantis 1802 For the second item in above discussion: Swapnajit - There was another question about the following 2 sub-clauses 19.5.3 wildcard specification 19.5.6 Arturo - there is indeed a contradiction between them. A change was made to the LRM at some point, which created it. Jonathan - for non-wildcard bins 19.5.3 says x,z are ok. - From 19.5.3 "When a bin definition includes an X or Z, it indicates that the bin count should only be incremented when the sampled value has an X or Z in the same bit positions, i.e., the comparison is done using ===." Jonathan - we could delete 3rd bullet in 19.5.6 b) "If b yields a value with any x or z bits." Arturo - I never thought this had any value Ray - you many want to cover x values when you are dealing with the software world. Steven - you may also want to make sure that injecting x or z values will yeild reasonable results. Gord - we could possibly get rid of point 3) from b) in 19.5.6 - we care about the singleton value b in this situation. - For ranges it isn't definable. - In a non-wildcard bin you use === Arturo - is it a bug to cover an x value, or a feature? Jonathan - thinks that issuing a warning in this case is still appropriate. AI: Coverage item Swapnajit - will put together a proposal for this issue. 2848 Francoise - the sv-bc spent a fair amount of time discussing interfaces - possibly weakening the type checking of modports having modports carrying type information - interfaces have a lot of problems today. It would be difficult to make changes that are backward compatible. Mehdi - this was with regards to the email from Peter Flake? Steven - a modport could encapsulate a "thing". - most issues seem to be in the test bench area Mark - the sv-bc decided not to pursue this modport idea. Steven - Dave and Jonathan have a DVCON paper that described how a class based solution can be used for some testbench situations. Mark - one possible svec issue would be virtual interface type compatibility. Today there are a lot of restrictions on equivalences. Not everything would actually need to have the same value. Steven - encapsulating the pieces that you want to get at, might allow these rules to be relaxed (sub-interface). Francoise - that affects the layout Steven - would need some indirection. If encapsulate the piece that you will access, it can be put into a sub-interface. Francoise - you then connect to the sub-interface. Steven - the sub-interface is then an access method. Francoise - there is no change to the design. Steven - you can then place one of the sub-interfaces into lots of interfaces. Mehdi - should we expand 2848 to cover this concept? Steven - Jonathan mentioned that this adds an extra level of hierarchy which makes it non-synthesizable. Jonathan - has thrown in the towel on this whole concept. The users don't seem too interested in raising the level of abstraction, which is what this was all about. Steven - different instances of classes are different types. Gord - why not disallow a virtual interface to a member of an interface which is a strong type, as opposed to a type imported from a package. Francoise - putting the type in a package is an easy work-around Steven - we could move to structural equivalence Mark - doesn't want to go down that route. Gord - for classes we can't use that approach (base classes, etc.) Mark - telling users to use types in a package seems to be a reasonable approach. Users may not like it though. - if a class references a lot of signals from an interface, it will need to be rewritten if you are to use a package. Jonathan - could use a virtual base class and derive from it. Gord - if users are willing to live with this, it is the simplest. Jonathan - would be strongly in favor of this restriction. - enums should be in a package AI: 2848 Francoise - Will do a write-up for this proposal. Will not be in the next meeting. - can post it earlier, will be in at the Oct 11th meeting. 2845 virtual interface type checking vs. interface type that had been defparam'ed Francoise - type checking, values and types of the interface. Parameters inside an interface seem to have been omitted. Jonathan - parameters in port list are not local (top-level) parameters inside are local Gord - can't defparam into a sub-interface Mark - can only use defparam to change parameter inside a task/function - these don't seem to be local parameters. Francoise - what need to specify for an interface definition Steven - the definition of what it means to have the parameters be the same will need to be extended Gord - if a parameter cannot be named via an instantiation (not visible via an instantiation) and it is overridden by a defparam it can't be used on the RHS of an assign. - Would be willing to just make this situation illegal - It is a restriction that is relatively easy to state and it seems to cover the corner cases that we are concerned about. Mehdi - It would be useful to show some examples of what isn't legal Steven - it will help users understand what the restriction means. Gord - defparam is still being used in some places. AI: 2845 Francoise - will try to write-up for this. 3028 constraints for unique array elements Jonathan - would it be ok to have constants or expressions? or list of variables or non-rand variables, we could for example swithch the rand mode. the proposal doesn't allow an expression nor a constant. Arturo - can also specify non-rand variables in there. Jonathan - yes, we have to allow that Steven - the example shows how to work-around being not able to specify a constant. Jonathan - expressions could contain both rand and non-rand variables. Steven - people are using nested foreach today. Arturo - when they use nested foreach, they know it is O(N*N). Dave - what if the types are not the same? Jonathan - that is already covered. Dave - should also say something about if not the same size they get padded. Ray - last time we said they need to be of equivalent type. Dave - byte and int - users may demand that this works. Arturo - that would be an error if we say they must be equivalent. - hasn't seen any users trying to break such a rule. Steven - an array of values covers most of the situations. - used to spelling out the extension rules, but Arturo is not comfortable with it. We could keep it this way for now. Ray - can't specify a cast expression with this approach. Steven - there are work-arounds Jonathan - array of byte and an int. Ray - the bytes would just extended to the size of the int and then make sure they aren't the same values. Mehdi - is happy leaving in the restrictions in the current proposal. proposal-3028-21-1 Francoise - what about a dynamic array? Steven - a dynamic array is an unpacked array - what about an associative array? Ray - the existing set of entries can be randomized. Mehdi - do we want to point out cases where failures may occur? Ray - there are a number of ways that the randomization could fail. Dave - would like to take a crack of relaxing some of the restrictions. - we could put it up for an email vote. - all variables have to be equivalent types. Arturo - there could be some mismatches? (he sent an email) - there could be truncation Ray - when is the expansion done versus when do the assignment. - if assign values first and then truncate, that is a problem. Jonathan - this type of problem must already be handled in the solver. enums are currently handled. Ray - in some cases the solver will be able to realize what is being requested and it will be fast, in other cases the solver could be slow. - is ok with either solution. Dave - why not allow constants? (sized constants) Mehdi - willing to put it up to an email vote. Ray - solvers don't ever assign 4-state values. Dave - 'rand logic' is not equivalent to 'rand bit' - why not just say all of the items must be of equivalent width? Ray - if use methods we get back to the issue with expressions. Arturo - we don't have a definition of defining what it means to have the same number of bits. Dave - bit stream casting defines this. Steven - we could leave it the way it is written and extend it later - expects the array case to take care of most user cases. Move: Jonathan - approve the proposal for mantis 3028 Second: Arturo Abstain: none Opposed: Dave (reason: equivalence is too restrictive, would rather have a restriction on expression bit-width.), poroposla for 3028 passes with one Opposed. 5. Other 'trivial' sv-ec mantis items [close/duplicate] ------------------------------------------------------ Review any trivial mantis items? 6. Next meetings September and October 2010 ----------------------------------------------------- Monday September 27 2010 Monday October 11 2010 Monday October 25 2010 -------- for reference only ------------------------------ --------------------------------------------- Summary table: Assigned Lead/Champions --------------------------------------------- 1 2848 Francoise 2 3002 Tom, Dave, Jonathan, Francoise, Arturo, Neil S., Cliff, Gord 3 3046 Gord, Franocise, Mark, Ray 4 1356 Tom [same with 3002] 5 3001 Jonathan, Tom, Francoise 6 2999 Tom, Ray, Arturo, 7 3003 [2987, 2988] Jonathan, Tom, Ray, Arturo, 8 3082 Daniel, Jonathan, 9 2845 Francoise, Mark, Alex Neil S., Gord? 10 2956 Steven, 11 2505 Neil S., Mark, Francoise 12 2735 Arturo, Steven, Gord, 13 1706 Mark, Steven, Francoise, 14 2488 Steven, Francoise, 15 2112 Dave, Steven, 16 3028 Arturo, Ray, Neil S., Mehdi, 17 2950 Francoise, 18 2794 Jonathan, Steven 19 2993 Tom, Ray, Swapnajit (cadence) 20 1442 Steven, 21 2953 Ray 22 1349 Steven 23 2949 Jonathan, Steven 24 2451 Steven, 25 2987 Jonathan (combining 2987, 2988, see 3003) ------------------------------------- [next 10] 26 3006 Ray, Steven, 27 3004 Tom 28 2998 Tom 29 2117 Cliff?? 30 No Mantis 6 could be linked with 2991 with sv-bc 31 2928 Ray, Arturo, 32 2787 ?? (Daniel)?? 33 2972 ?? (Daniel)?? 34 2996 Tom, 35 2988 already assigned (see 3003) 36 No Mantis 4 related to AOP (already covered) -------------------------------------------------------------- FOR References: --------------------------------------------------------------------- ============ from September 13 2010 meeting =================== AI: Coverage item Swapnajit - will provide a note for clarification, to be added to Mantis 1802 AI: Coverage item Swapnajit - will put together a proposal for this issue. [related to 19.5.3 wildcard specification] AI: 2848 Francoise - Will do a write-up for this proposal. AI: 2845 Francoise - will try to write-up for this. ============ from August 30 2010 meeting =================== AI:2956 Mehdi making a note to the editor for adding cross reference. AI: 2794 Jonathan will make the friendly amendment. AI:3028 Jonathan create a proposal and upload it for more discussion and vote next meeting. ============ from August 16 2010 meeting =================== AI: 3028 Jonathan - write up the parallel proposals. AI: 2794 Jonathan - add text for the case where indices are x, z AI: 1442 Steven - check if Shalom's comments make this issue moot. AI: 1349 Steven: create the proposal for 1349 AI: 2451 Steven put a proposal together. AI: 2993 Tom; will check internally to see if these meet their needs AI: 2993 Mehdi; upload the email as a note to the mantis item AI: 2993 Arturo; will donate their implementation. ============ from Aguust 2 2010 meeting =================== AI: 1706 Steven put together an email for bc to provide feedback on 4 options Mehdi can send to sv-bc AI: 2993 Swapnajit: add a note to the mantis item as to where we currently are in the process. AI: 2953 Ray - take a look at this one ============ from July 19 2010 meeting =================== AI:Tom get confirmation from users about exact intent of the original request for 3001 AI: Francoise will add a note to the mantis item 2848 AI: Gord will write up a proposal for 3046 AI: Ray will add a bugnote 2999 ============ from June 21 2010 meeting =================== AI/Mehdi - For number 30 on the list, 'no-mantis item 6' send email to Matt about linking this request to mantis 2991. AI/ALL - assigned leaders/champions to start looking at the top 25 items on the list and plan for proposals/discussions/reviews. ============ from June 7 2010 meeting =================== AI/Tom - some examples would be useful [mantis 2987, soft constraints] AI/Cliff - what is actually required. [mantis 2117] Allow extending of covergroups in classes AI/Cliff, John H. - more details on this request, item number 30 [no mantis 6: allow re-use of enumerated names (slide 31) AI/All - find mantis items that can be closed, or easily resolved. - any of the 0.5h estimate items could be considered as well. ============ from May 24 2010 meeting =================== AI/Tom and others: mantis 3002 AOP: any more clarifications from users perspective. AI/users: mantis 1356: Multiple inheritance:what are the particular requests? clarifications. AI/Tom - Mantis 3003, we need more clarification from user base ============ from May 10 2010 meeting =================== AI/Jonathan - create mantis items for No-Mantis-10. Completed action items: ============ from April 26 2010 meeting =================== AI/Mehdi - add a column for enhancement versus clarification AI/Mehdi - add a column for amount of work required. AI/Mehdi - add sheets for the various categores in the Google doc. AI/Mehdi - send out a link to the p1800 spreadsheet. AI/Mehdi - add a column for duplicates AI/All - send input on the list of categories. AI/ALL - until May 5th to provide any inputs on the spreadsheet. ============ from April 12 2010 meeting =================== AI/Mehdi - Look at the Google Docs and creaet spreadsheet for collaborative efforts. Also add cross committee column to the spreadsheet. AI/All - send inputs on any new items by April 24 2010, this is deadline for any item that is not already in the mantis database. AI/All - prioritize and categorize list of items that are in the spreadsheet to be reviewed during the next two sv-ec meetings. AI/Neil - email to cliff on proxy rights == List with estimates ======= hrs top 2t mantis Id 4 1 2848 12 2 3002 1 3 3046 16 4 1356 2 5 3001 3 6 2999 5 7 3003 8 8 3082 4 9 2845 0.5 10 2956 3 11 2505 4 12 2735 1 13 1706 2 14 2488 2 15 2112 2 16 3028 2 17 2950 1 18 2794 4 19 2993 0.5 20 1442 6 21 2953 0.5 22 1349 0.5 23 2949 4 24 2451 4 25 2987 92 total 46 (2hr sessions) 0.5 26 3006 4 27 3004 2 28 2998 4 29 2117 4 30 No Mantis 6 0.5 31 2928 4 32 2787 2 33 2972 2 34 2996 0 35 2988 0 36 No Mantis 4 23 total 11 sessions ====================================== top 25 Id Number of Votes weighted vote Summary Degrees of difficulty Cateogory Sub-Category 1 2848 7 159 Is it legal to assign an interface containing class declaration to a virtual interface med Virtual Interface and class 2 3002 8 125 Aspect Oriented Programming (AOP) features High class constraints 3 3046 8 112 Dotted names within inlined constraints Low class Strings/Arrays 4 1356 6 112 Multiple Inheritance High class Strings 5 3001 9 102 Proper Polymorphic behavior of instantiation low class Arrays 6 2999 7 99 Class Handle reference inside of Constraints med class constraints 7 3003 6 98 Constraint Composition High Randomization Strings 8 3082 7 96 (4) Ambiguity resolution (see slide 10 for examples of parts of the Standard that have been interpreted differently by different simulators) 9 2845 4 84 virtual interface type checking versus interface type that had been defparam'ed high Virtual Interface Misc / function proto 10 2956 4 76 clarify class 'process' definition (9.7 vs 18.13.3, 18.13.4, 18.13.5) low Process control 11 2505 4 76 class select: what is allowed after the dot? low class 12 2735 4 73 Ballot Comment #48: Chaining of method calls med class constraints 13 1706 4 72 Meaning of static prefix for virtual interface assignments Virtual Interfaces 14 2488 4 69 Are virtual method calls legal within class constructors? med VI OO classes 15 2112 6 69 Remove restrictions on NBA assigments to class members med class constraints 16 3028 6 68 constraints for unique array elements. Med Randomization 17 2950 4 67 virtual method prototype matching low class 18 2794 4 64 Clarify queue methods return status low class 19 2993 4 63 Cross cover points across different cover groups med Built-in Methods 20 1442 3 63 Clocking blocks legal in modports, missing from text description in 20.9 Functional Coverage 21 2953 6 61 Algorithmic generation of covergroup bin contents high clocking block 22 1349 5 61 fork/join_none: what if parent thread terminates without blocking statement? Functional Coverage 23 2949 4 60 LRM is silent about the semantics of referencing a clocking block output low Process control constraints 24 2451 6 58 Omitting body defaults med clocking block constraints 25 2987 6 56 Soft Constraints med class Misc / function proto 26 3006 5 55 LRM doesn't say explicitly what should happen if null pointer is randomized low class Data Types 27 3004 5 55 Ability to declare/qualify classes/methods/variables/constraints final med class Virtual Interface 28 2998 4 55 Solve Before enhanced low Randomization class 29 2117 3 52 Allow extending of covergroups in classes high Functional Coverage class 30 No Mantis 6 5 51 (3) Allow reuse of enumerated names (slide 31) cross-committee Randomization 31 2928 3 50 ambiguous restriction on function calls in constraint expressions low Randomization Randomization 32 2787 3 50 reference via scope operator to parametrized superclass item med class Randomization 33 2972 3 49 add class constructor/method, task/function overloading High class Randomization 34 2996 4 49 Method overloading High class Randomization 35 2988 2 48 Defaults Constraints med Randomization Process control 36 No Mantis 4 2 47 (1) AOP when-inheritance (slide 31) Class/AOP Functional Coverage