SV-EC committee meeting. Monday August 2 2010 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_August_2_2010_Minutes.txt ] Meeting number: ------------------------------------------------------------------------- 00 00 21 Meeting Days: ------------------------------------------------------------------------ (01) Day (29) (00) Month (87) (11) Year (00) ------ Attendees -------------------------------------------------------- 1. (AAAA-AAA) Arturo Salz 2. (AAAAAAAA) Dave Rich 3. (AAAAAAAA) Francoise Martinolle 4. (AAAAAAAA) Mehdi Mohtashemi 5. (AAAAAAAA) Neil Korpusik 6. (AAAAAAAA) Ray Ryan 7. (AA--AAAA) Gordon Vreugdenhil 8. (AAAAAAAA) Steven Sharp 9. (AA--AAAA) Heath Chambers 10. (AA----AA) Don Mills 11. (AAAAAAAA) Mark Hartoog 12. (-AAAAAAA) Tom Alsop 13. (AAA--AAA) Jonathan Bromley 14. (-AA--AAA) Neil S 15. (AA--AA--) Cliff Cummings 16. (-------A) JL Gray 17. (-AAAAAAA) Alex Gran 18. (AAAAA--A) Daniel Schostak 19. (-------A) Kevin Johnston 20. (-----A--) John Halvicek 21. (-----A--) Scott Little 22. (---A--AA) Tracy McDermott 23. (AA------) Swapnajit Chakraborti ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// August 2 2010 ///////////////////////// Everyone will have voting rights at the next meeting. Agenda: 1. Review IEEE patent policy ------------------------------------------------------ http://standards.ieee.org/board/pat/pat-slideset.ppt The chair directed everyone's attention to the patent policy. Cliff, Jonathan - 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_July_19_2010_Minutes.txt Move: Jonathan to approve Notes/discussion on the minutes in general: Jonathan: It is impossible to capture all technical discussions. Neil: Never view the minutes as accurate record of all discussions, it is intended to capture the main points, Second: Mark Abstain: None Opposed: Passed/approved unanimously 3. Updates from P1800 ------------------------------ Participation and voting guidelines, other updates. [if any available] Neil: no new item, still waiting to receive a faq from the IEEE. We will continue to use the existing Policys and Procedures until we hear from the Working Group. Next meeting for p1800WG: August 12 2010. 4. Continue Review and discussion of top 25 issues and categories: ------------------------------------------------------ Review of the top 25 [+10] started last meeting, 1 through 12th were discussed. Will continue with the list below. [Please take a look at Action Items per last meeting, appended at the end of this email] --------------------------------------------- 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 Meaning of static prefix for virtual interface assignments Mark, Steven, Francoise, Mark: I have not had time to work on this. Gord: in particular in the presence of an always_comb, Would be ok saying they behave similar to a class. Steven: some of the "dynamic" restrictions in the LRM are not about dynamic objects. Jonathan: one main question, what would be for example the semantics if a variable is written by a procedural always comb, writing to that same variable through virtual interface Gord: potentially driving any instance by procedural driver, would that do anything here. Dave: also modport, virtual interface that has modport associated with it, if it has an output, there is a potential for a virtual interface to drive it procedurally. It may not be so big issue if modports are used. Gord : we still need to define the behavior without modports. Steven : last write wins, is one possibility. Could also disallow situations of procedural and non-procedural drives. Steven : continuous assign and a procedural write to the same var is currently disallowed. There are longest static prefix rules. Mark : how do you determine if a task is never called? Steven : you need to dig down to get that information. Dave : it doesn't matter if it is never called, you should get a compiler error if you define such a task. Steven : write in a task and a write in an always_comb. Only allowed if the task is called from that always_comb. Gord : want to guarantee certain behavior for some design styles. How strong should the guarantee be? One possibility is to define the straight-forward situation and then mention that implementations may issues warnings and errors. Francoise : prefers to be more strict. Steven : how do you enforce that when there are Virtual interfaces? it becomes too difficult to check, then need to solve the Halting Problem. Mark : the virtual interfac in an always_comb is not synthesizable. Steven : need to keep in mind where these constructs were inteded to be used. Gord : Could specify where it is well-defined and mention where it isn't. : prefers not to add a synthesis engine into the SV LRM. Mark : single writer rule is optional? Steven : no it is a requirement. Gord : in reality, there is a balance between LRM adherence and some switches to turn some things on/off. A clear, reduced definition might be best, and not have to define all of the edge cases. Steven : Some customers want to drive interfaces using continuous assigns and others will use tasks within the interface. They want the option of choosing which approach. Gord : if we say you are on your own in certain cases, it would allow for a simpler well-defined behavior description. Mehdi: this one will clearly require more discussion. Steven : we should find a direction that we need to go. for sensitivity list - ignore them, and for multiple drivers - be conservative? Mark : do you do analysis over the whole design? Gord : the current LRM says you do. Arturo : maybe the always_comb should not have tasks inside of them. Mark : people prefer to not be required to get the sensitivity list correct and rely on the tools to do it for them. Steven : are we just allowing people to think they are getting the full list, when they are not really. Arturo : always_comb is for a specific purpose. Straw Poll (Steven's list of 3 options) 1. assigns or reads through a VI or class handle are ignored for the purpose of a sensitivity list and the multiple drivers rule. The sensitivity list is already ignored for class references. implementations won't check - user must not do it. Opposed - Dave - possible to do this, but doesn't want rules to be relaxed for multiple drivers. - not concerned about synthesizable code since this isn't synthesizable code. Used in testbench. 2. Conservative - assume the universe of what could be referenced. Static analysis that could be difficult to do. 3. Illegal to have a VI or class handle reference inside an always_comb Mehdi : sounds like 2 is what people are leaning towards. (ie make it illegal). Cliff : this is just for always_comb? Steven: longest static prefixes are only used in these two places. Mark : a simulation time check could possibly be required. Francoise: checking for multiple drivers could be very hard. (agreement) Gord: these runtime checks could be quite expensive. if ran a sim for 2-weeks and it dies with a runtime check. Users are not happy with that situation. Steven: some of these situations are things that people would never do. Mark: There are 3 issues to look at in this context, 1. sensitivity list 2. writing from multiple processes 3. write from both continuous and procedural assignments Steven: continuous assign and always_comb are almost the same, we can check for multiple processes writing to same var. if it can be done for an always_comb it can be done for a cont assign Mark: Most users understand the procedural rule of last write wins. Not clear what last write wins means for always_comb Steven: what about a 0-time glitch. Is that written or not? Gord : the root of this is to approximate synthesis behavior. always_comb gives the hint of being purely combinational. The implementation should probably complain if it isn't being used that way. Users cared about conflicting behavior. We are moving a bit away from that. Mark : users writing synthesizable code wanted to know early, before getting to synthesis. To prevent having to redo simulation. Dave : mixing procedural and continuous assign is not a synthesis issue Steven: Some Superlog types were only allowed for variables. The only way to get around it was to allow continuos assigns to variables. Mehdi : Back to the straw poll... Arturo: should always_comb be restricted to be synthesizable? Mehdi : you think always_comb is the root of most of these issues? Arturo: yes. Gord : there are key users that drove this topic in the first place. need to get input from the user community. Tight behavior or catch my dumb errors? Dave : Testbench connected to the dut. Testbench drives through vi and dut has a continuous assign. Mark : that is an error Dave : yes, and it should be caught. Steven: how strict? check whole universe? runtime check? Dave : they should be using a modport, that will tell you what will happen to that variable. A virtual interface today can only be procedurally assigned. Steven: the modport directions aren't really meaningful. They are really only comments to the user. They all actually mean ref. Francoise : it looks like we can't make up our mind right now. Steven: we can do the following: 1. we ignore these constructs and say user beware. VI selects, class selects. Any dynamic reference (Any object whose name can refer to another object.) 2. Make it illegal 3. Have an intermediate check that tries to be a bit smarter. would require the algorithm to be specified. 4. runtime check In the above cases, 2,3 are similar Gord: is against the above number 4. Gord : can't answer this question until hear from big users. I can not give any names in this meeting. Arturo: we should extend the discussion to the sv-bc. some of those customers are in the committee, also give Shalom a chance to chime in. Steven: agrees that this should be user driven Don: has a strong opinion on this topic. AI/Steven: put together an email for bc to provide feedback on 4 options Mehdi can send to sv-bc 14 2488 Are virtual method calls legal within class constructors? Steven, Francoise Gord : we could use the C++ approach Jonathan: ok with any approach as long as it is well-defined. Steven: in C++ the this pointer changes type as you work your way out through the class-hierarchy Jonathan: making it illegal is another possible option Gord : making it illegal is too restrictive. Jonathan: we need to define what super. means in a constructor. Gord : doesn't think there is a special case to be considered for that Jonathan: the current description in the LRM for super. could be improved thinks that Gord is probably correct about this not being a special case for this proposal, but would like to see the description of super. to be changed so that this is well defined. 15 2112 Remove restrictions on NBA assignments to class members Dave, Steven, Dave : he doesn't think there is much discussion required. Steven: writing to a queue can also cause an element to come into existence. Gord : as far as class semantics - what about nba to an object that no longer has valid references? Steven: you would have to capture a live handle to make it work. Gord : an nba would then need to be sufficient to get a reference to an object Steven: if there isn't a problem using an nba, we just need to define the situation. Gord : ok with the direction that you are going in. concern about the nba having no effect. If the NBA matures, then the handle would be released. 16 3028 Arturo, Ray, Neil S., Mehdi, 17 2950 Francoise, 18 2794 Jonathan, Steven 19 2993 Cross cover points across different cover groups Tom, Ray, Swapnajit (cadence) Swapnajit: wanted to discuss this one now, Tom had sent out a proposal on this one. example: class cg1 cg2 want to use cg1 inside cg2 he sent out some questions on the proposal for 2993 cg1 cg1_inst = new; <<----- This will not be allowed as "cg1" is the instance name and not the type X: cross cg1_inst.A, cg1_inst.B; <<----- So, in order to make this work so we need to think about some modification Jonathan: why is there this extra instantiation? can't we just reference one to another? Arturo: what do we do if one uses posedge and the other uses negedge? that is why we didn't do this initially. requiring two instantiations makes it more complex. Ray: we need to first decide what the goal is. Then we can decide where we need to impose restrictions. Then we would work on the actual syntax. Gord: it is way too early to be talking about syntax. Swapnajit: we currently can't define new() for a cg; he suggested that we do all of this in the constructor. Gord: you may be treating this proposal as being more mature than it really is. Gord: multiple inheritance brings about a whole other set of issues. embedded covergroups may be impacted by multiple inheritance. AI/Swapnajit: add a note to the mantis item as to where we currently are in the process. 20 1442 Steven 21 2953 Algorithmic generation of covergroup bin contents [originally assigned to Gord, we re-assigned this one to Ray] Gord : raised this based on discussion from Xilinx. Arturo: isn't this just a syntax issue? Gord : it depends on where you allow a generate to exist. 2506 - is related Arturo: 2506 is more general Gord : 2953 is more "generative" rather than "predicated". Gord : we do need to have some discussion on bin generation Mehdi: asked Ray to take a look at both 2953 and 2506 Ray : he can start to help sort it all out. Swapnajit: 2506 is exhaustive, a more complete proposal. AI/Ray - take a look at this one 22 1349 Steven 23 2949 Jonathan, Steven 24 2451 Steven, 25 2987 Jonathan (combining 2987, 2988, see 3003) 5. Next meetings April and May 2010 ----------------------------------------------------- Monday August 16 2010 (agreed to in the meeting) -------- 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 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