SV-EC Committee Meeting Tuesday March 3 2008 11:00am - 1:00pm PST [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_March_3_2008_Minutes.txt ] With the new calculations for voting rights below (rounded)... 3/4 rule = 0.75 * 38 = 28.50 Meeting number: ------------------------------------------------ 0000000000000000000000000000000000000000 0000000001111111111222222222233333333333 1234567890123456789012345678901233445678 Meeting Days: ------------------------------------------------ (1212020201020201013112020201012120110200) Day (4815936048825059560415936067159263077243) (0000111111000000000000000000111111110000) Month (8899001122112233444566778899000112221123) (0000000000000000000000000000000000000000) Year (6666666666777777777777777777777777778888) ------ Attendees ---------------------------- (-AAAAAAAAAAAAAAAAA-AAAA-A--AAAAA*AA*AAAA) Arturo Salz 33 (--AAA-AAAAAAA-AAAAAAAAAA--A-A-AAA*A*AAAA) Cliff Cummings 30 (AAAAAAA-AAAAAAAAAAAAAAAAAAAAAAAAA*A*AAAA) Dave Rich 37 (AA-A-AAA-AAAAAAA---AAAAAAAAAAAAAA*A*AAAA) Francoise Martinolle 32 (-AAAAAAAAAAAAAAAAAAA-AAAAAAAAA-AA*A*AAAA) Mehdi Mohtashemi 35 (AAAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAA*A*AAAA) Neil Korpusik 37 (AAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA*A*AAAA) Ray Ryan 37 (AAAAAAAAAAAA-AAA---AAA-AAAAAAAAAA*A*A-AA) Gordon Vreugdenhil 32 (AAAAAA--AAAAA-A--AAAAAAAAA-AAAAAA**AAAAA) Steven Sharp 32 (--AAAA-A-------------------------*-*----) Phil Moorby 05 - Non-voting (---AA-AAA-AAAA-AA-A--------------*-*----) Doug Warmke 12 - Non-voting (AAAAAAA---AA-A-AAAAAAA---AAAAAAAA**AA--A) Stu Sutherland 28 - Non-voting (-AAAA--AAAA-A-AAAAA-AAAA-AAAAAAAA*A*-AAA) Heath Chambers 30 (-AAAAAA-A----AAAAAAAAA--AAAAAAA-A*A*AAAA) Don Mills 29 (--AA--A---A-AAA--A-AAAA-A-A--A--A*-*AA--) Jonathan Bromley 18 - (2 of last 3) (--A------------------------------*-*----) Logie Ramachandran 01 - Non-voting (----AAA--------------------------*-*----) Melvin Cardoza 03 - Non-votings (-----A-AAAAAA-AAAAAAAAAAAAAAAAAAA*A*AAAA) Mark Hartoog 31 (-------A-------------A-----------*-*----) Satia (from Intel) 02 - Non-voting (--------AAA----------------------*-*----) Rob Slater 03 - Non-votings (-------------A-------------------*-*----) Alex Gran - Mentor 01 - Non-voting (---------------A-AAA-AAAAA--A-AA-*A*A---) Mike Mintz 14 - (2 of last 3) (------------------AAAAAAAAAAAA-A-*-*----) Geoffrey Coram 13 - Non-voting (-------------------AAAAAAAAAA-AAA*A*AAAA) David Scott - Mentor 18 - (2 of last 3) (------------------------A--------*-*----) Benjamin Chen - Cisco 01 - Non-votings (---------------------------AAAAAA*A*-AA-) Mike Burns - Freescale 09 (2 of last 3) (----------------------------------*A----) Harry King - Cisco 01 - Non-voting (--------------------------------------A-) Karen Pieper 01 - non-voting on March/3/2008 [for next meeting] 15 people (other than the chair) currently have voting rights ** Minutes taken by Neil Korpusik and Mehdi Mohtashemi ////////////////// March 3, 2008 ///////////////////////// Agenda: ------- 1. Review IEEE patent policy ------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Cliff - Assume that the patent policy was read Second: Mark Abstain: None Opposed: None Passed unanimously 2. Review minutes of previous meetings ------------------------------------------ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_February_4_2008_Minutes.txt Move: Cliff - approve the meeting minutes of February 4, 2008 Second: Heath Abstain: None Opposed: None Approved 3. Updates from p1800WG February 28 2008 meeting and champions meeting -------------------------------------------------- Working group Feb 28 2008 meeting: 9 sv-ec mantis items that were approved. for sv-ec: 3 mantis items were approved for work, till end of March 2008 extension given to sv-cc 2 weeks on VPI related issues coming from sv-ac 1897, 2242, 2243 sv-bc allowed to work on one additional. sv-ac to work on comments on from other committees, till April 15 2008. still remains the same. Stu: next draft pushed out by two weeks due to sv-cc extensions. draft 5: April 29th, in couple of weeks as preliminary draft5, by end of March. over 550 changes going to Draft 5, some editorial correction, Champions: two conference calls and email votes. email vote ended 2/4/2008: Mantis items 2227, 958, 520, 2003 - passed Mantis item 1447, 1858 - failed Mantis items 2181 - not enough Champions voted on it. 4. Immediate issues to review ----------------------------------------------------------- a) Review email ballot results for mantis items 2088 and 2089 which did not pass. http://www.eda.org/svdb/view.php?id=2088 http://www.eda.org/svdb/view.php?id=2089 mantis 2088: Gord: reasonably ok with the proposals for 2088 and 2089. rules for checker instantiation and covergroup instantiation inside the checkers. on the detailed by those proposals are reasonably. - checker instantiations in procedural code, a bit concerned here Concerned about checkers in general. - covergroup in a checker - thinks it is now clear enough. - checker instantiations - need to define the rules for these: semantics naming forces - assertions within checkers seem to be another class of assertions We now seem to have 4 types of assertions. 1. concurrent 2. immediate 3. deferred assertions 4. assertions inside checkers - glitches - see mantis 2005 - special type of immediate assertion with delayed reporting. - It could be difficult to deal with all 4 types at once - A covergroup can now only be instantiated in a checker (not declared in a checker). Arturo - his issue has also been addressed - a new type introduced in a looping situation was his concern. Cliff - wants to review several svac mantis items as a group: 1900, 1549, 1681, 1648, 1728, 1682, 2088, 2089 - raising the larger issue, not specific to 2088 and 2089 Gord - checkers can have untyped formals. This is a bit different as to when you know information. Steven - free variables allowed in cg? Gord - coverage seems to be allowed on a freevar Steve - seems as though the simulator just selects one of the legal values - one formal proof with a freevar covers all possible values. - simulation coverage on a freevar is very different Gord - cg with a freevar as an argument - will give unreliable results. Francoise - why no cg declarations allowed in a checker? Gord - as soon as you do that - the presence of untyped things and name resolution. Some things are thought of as static. Is each cg redeclared whenever enter? (the answer was no). - Requested that it not be allowed to simplify things. If it is important, we would need to work out all the details. Cliff - won't be able to vote yes at this point until this set of svac mantis items is addressed together. Stu - This requires much more analysis. - checkers are adding a bunch of new keywords that could conflict with legacy code. - Everything involving checkers needs to be reviewed together. Move: Arturo - approve the proposal for Mantis 2088 Second: Steven Abstain: Gord - Ray - not against these specific proposals Steven - wants the whole group of checker proposals to be reviewed by ec as a group. Francoise - not sure how the coverage will be calculated Opposed: Cliff, Don, Heath, Dave - same reason as Steven Stu - wishes he could also vote no In Favor: Arturo, Neil, Mark, David 12 with voting rights are on-line The Motion failed. Cliff - wants at least the list above to be reviewed by svec Gord - some of the feedback that he got from ac was to look at other mantis items. Dave - checkers cross into the general language. - they tried to address in the assertions area but it is a more general problem. - There should have been a cross-committee group Gord - also sent feedback on the group back to the svac Mark - there are some issues that do cross boundaries into ec, bc hierarchical references, force, etc. - people seem to be saying that checkers is an assertions issue Cliff - they crossed into procedural code and how instantiations work Ray - it will most likely become a ballot level issue. Gord - if it gets to a ballot issue, there would be limited possible solutions available. Cliff - wants to hear someone explain the mantis items. Would also like to hear the reasoning behind creating these mantis items. - keywords issues Stu - checkers can be bound into other code. The compatibility flag won't help in these situations. Gord - not sure if that is allowed, if it is that would be another whole set of issues. Arturo - thinks checkers is an extension of the bind mechanism. Ray - uncomfortable with the reasoning that "what they are trying to do seems to make sense", so lets approve it. Steven - the answers to a lot of the questions seemed to not be in the proposal. Mark - extending some of the procedural context. concurrent asserts not really in the procedural code. Gord - doesn't agree. Mark - this is already in the 2005 lrm. Gord - if something is severely broken, it should be fixed, even if it is in the 2005 lrm. Not sure this is completely broken. Mark - the forum for concurrent assert in procedural context is just shopping for another committee to be debating the issue. Steven - people in the ac tend to think in terms of synthesis viewpoint. Cliff - thinks that some more oversight of the ac changes are needed. Arturo - is there a technical issue? Cliff - not sure. Dave - most people accept the motivation for what they are doing. It is the soluation that he has an issue with. Steve - 1995 - assertions in loops - already approved by WG SVDB 1900 - Checkers - 1900 references these others SVDB 1549 - add missing formal argument types SVDB 1681 - global clocking SVDB 1648 - default disable SVDB 1728 - "let" statements SVDB 1682 - Future value functions SVDB 2088 SVDB 2089 AI: Neil & Mehdi - draft a note for svac and WG on this topic. b) additional mantis items (permission granted by p1800WG) 1897, 2242, and 2243 http://www.eda.org/svdb/view.php?id=1897 http://www.eda.org/svdb/view.php?id=2242 http://www.eda.org/svdb/view.php?id=2243 2242 - correction to 1897 Arturo - expects that using a real data type here will create problems. - could use an "unweighted" value. David - avg of 75 and 100 is 87.5 which is still real - He will do a re-write today. It will be a substantial change and but it will simplify things. 2243 David - added a note on "Database loading behavior may be vendor specific." Arturo - thought it would be useful to mention the inability of one implementation to read data produced by another implementation. Neil - the way the data is stored will be vendor specific. Artuto - we don't define merging. Gord - what is the obligation of the implementation? - could define things such that all the info must be there. - Could allow it to be tool dependent on what is actually stored. Arturo - need to save a particular set and could save more if desired. Arturo - why not say that "When false implementations are not required to save instance specific information" David - should the change be made in 1897? - add a note to 2242 (leave 1897 alone) From Champions 1447 - 2 new mantis items will be created for the champions feedback 1447 SV-EC Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 and 5.8) What is the definition of 'compatible'? Is it the same thing as "assignment compatible"? If so, this should either say "assignment compatible" instead of "compatible", or we should get rid of the "assignment" in "assignment compatible". Shalom - This issue is already there - not a new problem I abstain because from a user's point of view the new wording is just as muddy as the original wording. I assume it means something more exact to those that implement SystemVerilog tools. I think there is a contradiction between the following two statements that should be resolved: In 7.4.2: "If an unpacked array has one or more dynamic, associative, or queued dimensions, it is considered a variable-size array." In 7.5: "integer mem[2][]; // Fixed-size unpacked array composed of 2 dynamic subarrays of integers" AI:Mehdi - send email to Mike Burns (possibly Jonathan) 2183 SV-EC Only simple identifiers allowed in solve-before constraint I don't know what "simply identify" means? Sounds like a "simple_identifier" to me, which is roughly what was already there. What's an example of an "expression" that can "simply identify" something without being a "simple_identifier"? Also, just an observation, not a strong objection, this is hardly the only place in the BNF that would have the content "expression { , expression }". See case_item, rs_case_item, and assignment pattern. So why the need for a special production for it here? The new sentence "Each expression in an 'expression_list' must simply identify a random variable." is not well worded. What is meant by "must simply"? The word "must" should be "can", "may" or "shall" (I am guessing that the intent is "shall, but I am not sure). The word "simply" should be deleted or rephrased. Mantis 2183 was sent back to the svec Gord - 2235 - had a similar issue. Ray - this case is a bit more restrictive (only rand variables) Artuto - making the bnf follow the rules is not too simple. - we seem to be in agreement on the rules. Gord - leaving it the way it is might be the best approach and trying to clean it up in next LRM. Arturo - a state variable Ray - any indicies used in the expression shall only contain state variables Francoise - the prefix of the expression must refer to a random variable. Gord - the word variable is already at issue (svbc has been discussing) Ray - want within a foreach construct to use the index variable x.y.z[i] within a foreach constraint Steven - possibly use some text from the foreach discussion. - .name[i] Gord - only the last set of brackets are significant Steven - cant the first set of brackets in a multi dim array be fixed? Ray - cant put a solve before constraint before a foreach construct Steven - seems like it needs to be specified. - the semantic rule needs to be specified more carefully. - have a semantic rule that specifies that is allowed. AI:Ray - rewrite the semantic rules. 5. Next meetings in 2008 ---------------------- Monday March 17 2008 - Gord will be in India [ note: Thursday March 27 - p1800 Working Group meeting] Monday March 31 - SNUG week -- several people will have conflicts May need to do it the week before or after.