Hi Folks: Below are notes from the Champions meeting on 2008-01-17. J.H. ------- Start of forwarded message ------- X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-champions@eda.org using -f Date: Wed, 23 Jan 2008 18:50:02 -0800 From: Neil Korpusik <Neil.Korpusik@Sun.COM> Subject: [sv-champions] Minutes from the Jan 17, 2008 conference call To: sv-champions@eda.org Reply-To: Neil.Korpusik@Sun.COM X-eda.org-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-sv-champions@eda.org X-eda.org-MailScanner-Information: Please contact the ISP for more information X-eda.org-MailScanner-From: owner-sv-champions@server.eda.org X-OriginalArrivalTime: 24 Jan 2008 02:51:25.0723 (UTC) FILETIME=[02BBC6B0:01C85E34] This is a multi-part message in MIME format. --Boundary_(ID_uwdDaBQtjihhNNfhKt7wZQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_uwdDaBQtjihhNNfhKt7wZQ) Content-type: text/plain; name=m011708.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=m011708.txt Champions meeting minutes of January 17, 2008 Attendees: ---------- 1. * Stu Sutherland 2. Surrendra Dudani - was traveling 3. * Brad Pierce 4. Francoise Martinolle 5. * Shalom Bresticker 6. * John Havlicek 7. * Dave Rich 8. * Neil Korpusik Review IEEE patent policy ------------------------- ref: http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Brad - assume the patent policy was read Second: Dave Passed unanimously List of Mantis items ready for review: ------------------------------------- 1. 1648 SV-AC Default reset for assertions - Fixed - Voice vote approved the latest change on 12/4. - Was sent to the SV-EC by the Working Group - The SV-EC chose to not make any changes at this time. Shalom - (from email of Jan 17,2008) - Mantis 1648 adds the following in 16.15: (page 5) "Furthermore, the default extends to any nested module, interface, or program declarations." I think that sentence should include nested generate blocks as well John - agrees. It wasn't worded this way on purpose. "local generate block" used in the proposal Brad - doesn't extend to generates in a different module Shalom - (from email of Jan 17,2008) "The effect of a default disable iff item is independent of the position of the declaration within that scope." For consistency, I think "item" should be "declaration" here. - "Declaring more than one default disable iff item within the same module, interface, program declaration, or generate scope shall be an error." I think 'generate scope' should be 'generate block'. - // Disable condition is rst - no explicit specification, inferred // from default disable statement I think the 2nd line of the comment should be // from default disable iff declaration Brad - you can't declare a declaration... Shalom - there are 2 sentences there that call it an "item". - "item" should be changed to "declaration" Dave - his original concerns were addressed in the first round of updates. Stu,Shalom - want the first issue flagged by Shalom to be reviewed by the svac. Shalom - has svcc reviewed the proposal? John - thinks it might have been reviewed some time ago (not sure) Move: Shalom - send it back to the svac for review Second: Brad Passed unanimously AI/Neil - notify the svcc about the changes to vpi diagrams 2. 1682 SV-AC Future value functions - Fixed - 2007-12-24: Passed by e-mail vote, 7y/0n/3a. Shalom - Has a minor Editorial comment - The proposal adds functions to 19.12 - that is not an issue They should also be in the list of 19.1 Move: John - approve the proposal for Mantis item 1682 Second: Brad Passed unanimously AI/Neil - add a note to the Editor for this. (Stu was OK with this) AI/Neil - notify the svcc about it (touches callbacks) 38.4.2.1 3. 1336 SV-EC Rules for allowed statements in a function - Fixed - Problems flagged by Champions (Nov 28) were addressed. - Approved on January 7 2008, unanimously Brad - mentions cases of creating a thread by always, initial or fork block. Dave - it must also cover the case of descendent threads created by a fork Move: Brad - approve the proposal for Mantis item 1336 Second: Dave Passed unanimously AI/Neil - note to editor on word 'new' needs to be bold in the examples. 4. 1987 SV-AC "verification statement" should be italicized and added to glossary - Fixed - 2007-12-24: Passed by e-mail vote, 6y/0n/4a Brad - there is a note to Editor within the proposal. Shalom - 16.2 - assert, assume, cover - is expect missing from the list? John - 16.16 expect is defined - blocking, waiting on a property, can have an action block Shalom - need to check how "verification statement" is used. Stu - thinks that 'expect' is procedural code, not a background process. John - 'expect' is a blocking mechanism. Stu - in draft 4 - only used in concurrent assertions. - could even refer to force/release as a verification statement Shalom - in the glossary - only used in section on concurrent assertions. Stu - not sure he likes the choice of the use of this phrase. Ok with it. John - immediate assume and immediate cover were added over time. - people thought that the word assertion was more dangerous. Shalom - can live with it Stu - note to editor - 16.14 - Glossary is not normative John - link to 16.2 Stu - will use 16.2 John - page 1, 16.2 "Assertions appear as a verification statement " - "An Assertion appears as a verification statement" AI/Neil - add this to a note. John - bottom of page 2, "when an assertion..." when should be in blue. Shalom - "shall" may no longer be the correct term after making this change. John - don't want to say this point for a cover. Shalom - how do I know when an assertion requires something to be true? - the text should be more explicit. John - "an assertion that is an assert or assume shall..." Dave - expect - the only difference was when the state machine starts. concurrent assertion. Stu - no, a concurrent assertion doesn't block Dave - blocks until assertion fails or succeeds. John - the description of Expect doesn't mention: - default severity - tool must count failures? Shalom - not taking a position on this, just asking about how expect is currently defined. Move: Stu - send back to the svac 1) should expect statement be listed in any of the changes? 2) rephrase the paragraph in 16.3 Second: Dave Passed unanimously 5. 2037 SV-BC Setting parameters in Configurations - Fixed - Enhancement - Approved unanimously by SV-BC on Jan. 7, 2008. Brad - Don mills (Microchip?) requested this enhancement - Doesn't believe it is implemented by anyone yet. Stu - This capability is part of VHDL today Brad - Thinks that no tools actually have implemented it though. Shalom - People don't want to use proprietary stuff since non-portable Neil - Accellera required donations to be based on existing implememtations. The rule about implementation went away when we moved to the IEEE. Dave - The proposal has been scrutinized a lot already. AI/Neil - notify the svcc Move: Brad - approve the proposal for Mantis item 2037 Second: Stu Passed unanimously 6. 2102 SV-BC Unnecessary difference between packed and unpacked objects - Fixed - It wasn't clear to the Champions which proposal to review last time around - On December 17, 2007 the SV-BC unanimously approved Shalom's proposal (uploaded on December 18, 2007). Move: Brad - approve the proposal for Mantis item 2102 Second: Stu Passed unanimously 7. 1863 SV-BC Add $system - Fixed - On December 17, 2007 the SV-BC unanimously approved the attached proposal. Move: Stu - approve the proposal for Mantis item 1863 Second: Dave Passed unanimously 8. 2131 SV-BC Parallel_case equivalent needed for case and if statements - Fixed - On December 17, 2007 the SV-BC unanimously approved the attached proposal. Brad - an enhancement - was implemented before Shalom - new keywords in table in section 21.... AI/Neil - add a note to the Editor about keywords needing to be added to 21 Move: Stu - approve the proposal for Mantis item 2131 Second: Brad Passed unanimously 9. 1984 SV-BC 22.2.2.3: bad example? - Fixed - On December 17, 2007 the SV-BC approved with one abstain Brad (should address ballot issue 228 and make current text legal) Dave - doesn't expect any simulators to report as an error(?) Shalom - LRM must still be correct Move: Brad - approve the proposal for Mantis item 1984 Second: Stu Passed unanimously 10. 1602 SV-BC 12.4.3: behavior of task/function inout arg with default is ambiguous - Fixed - On December 17, 2007 the SV-BC unanimously approved the attached proposal. Move: Brad - approve the proposal for Mantis item 1602 Second: Stu Passed unanimously 11. 1809 SV-BC forward references into $unit package - Fixed - The attached proposal was approved by the SV-BC on December 17, 2007. Opposed: Brad (not suitable to send to champions) Shalom (to which scopes does the algorithm apply?) Gord (language is not correct for LRM. Concerns about impact of proposal to interactions with $unit) Brad - admonish the svbc for working the system this way. (time pressure situation) Move: Dave - Send it back to svbc, expects it to get better consensus. Second: Brad Passed unanimously 12. 2097 SV-BC release/deassign with variables driven by continuous assignments - Fixed - The SV-BC unanimously approved the attached proposal via e-mail vote that closed December 17, 2007. Dave - there was a note from Gord - Mantis 2235 was filed Move: Brad - send back to svbc to address latest Email thread (see 2235) Second: Stu Passed unanimously 13. 2106 SV-BC Clarifications needed for declaration before use of objects and type - Fixed - Sent back to the svbc by the Champions Dec 20th. Shalom updated the proposal but it wasn't uploaded to Mantis - The SV-BC unanimously approved the attached proposal via e-mail vote that closed on December 17, 2007. - Input from Shalom (Jan 13, 2008) "I don't believe 2106 is ready for the Champions. SV-BC approved a revision to that proposal, but the revision has not yet been merged into the proposal on Mantis." Shalom - a revision was approved, but not yet on mantis Neil - has procedurally become an issue, bouncing back and forth in-between the Champions and the sv-bc AI/Brad - put into the feedback state. Move: Stu - send back to svbc , to ensure correct proposal is uploaded. Second: Brad Passed unanimously 14. 2184 SV-BC Data query and array query system functions allowed in constant expressions - Fixed - On December 10, 2007 the SV-BC unanimously approved the attached proposal. Move: Brad - approve the proposal for Mantis item 2184 Second: Dave Passed unanimously 15. 1619 SV-BC allow specification of default input values for module ports - Fixed - On December 10, 2007 the SV-BC approved the attached proposal. Opposed: Cliff - concerned that it removes important port connection checks Abstain: Mike (did not have time to follow details) Stu - relaxed some checking with respect to .* Shalom - an IP provider could add a new port, changing default behavior... Move: Stu - approve the proposal for Mantis item 1619 Second: Shalom Passed unanimously 16. 0997 V-1364 4.1.4 -- expression evaluation short circuiting - Fixed - On December 10, 2007 the SV-BC unanimously approved the attached proposal. Brad - makes some implementations not backward compatible - short-circuiting situations in expressions - fa && 0 - won't get a function call today in some implementations the proposal forces the function call. - makes things more deterministic, and more formal verification friendly Move: Dave - approve the proposal for Mantis item 997 Second: Shalom Abstain: Stu - thinks the tool should decide on short-circuiting. - has some concern about backward compatible Passed with one Abstain 17. 2225 SV-BC corrections to upwards hierarchical resolution - Fixed - On December 10, 2007 the SV-BC approved the attached proposal. Shalom abstained. He believes the proposal is an improvement, but he feels the text referring to hierarchical name in 22.8 should be combined with this. Shalom - not as good as it could be... (won't vote against - it is an improvement). Move: Brad - approve the proposal for Mantis item 2225 Second: Dave Passed unanimously 18. 1683 SV-AC Relax rules for building multiclocked properties - Fixed - 2007-12-24: Passed by e-mail ballot, 8y/0n/2a John - strict requirements on changing the clocks. - intent to make assertions synthesizeable - relaxing some restrictions on when clock changes can occur - PSL - has no such restrictions on clock changes - now ##0 can be followed by changing of the clock if coincident with ending of previous sequence. - several examples added to demonstrate the changes. Stu - do current tools enforce the current restrictions? John - Thier internal tool is able to evaluate without the restrictions Shalom - "leading clock" - what does it mean? - used a lot. John - clock can change during ... - the governing clock at the beginning of the property Shalom - the change in terminology is confusing - first usage - 16.15.1 reference earlier usages don't have a reference - "leading clock" versus "semantic leading clock" Stu - agrees with Shalom Neil - address separately? Dave - can be addressed separate from this proposal AI/Neil - open a new mantis item for this issue, flag as champions feedback Dave - page 8, inherited - changed to italic John - it is an intermediate symbol Dave - why isn't first usage italicized as well? John - that is an inconsistency. AI/Neil - friendly amendment - first item in list at bottom of page 8. Stu - p 3. "overlapping tick" - very large space there. John - may want to add commas here. Move: Stu - approve the proposal for Mantis item 1683, with friendly amendment Second: John Passed unanimously 19. 1702 SV-EC queue syntax issues - Fixed - Approved unanimously Dec 10, 2007. Brad - what about empty q. can't write an empty q with ` in front of it? Dave - not addressed by this issue. `{} still illegal Brad - 519 Shalom - svcc needs to look at this - new semantics - some people thought some of the examples were illegal. AI/Neil - notify svcc of this mantis item Move: Dave - approve the proposal for Mantis item 1702 Second: Brad Passed unanimously 20. 2137 SV-EC Some assertion contexts should be procedural - Fixed - Approved on December 17, 2007 unanimously. Move: Dave - approve the proposal for Mantis item 2137 Second: Brad Passed unanimously <--- at this point we ran out of time and did not address the following ---> 21. 2181 SV-EC Ambiguity in implicit declaration of production variables in randsequence - Fixed - Approved on December 17, 2007 with 2 abstain votes. Abstain: Mike burns - no time to review Steven - not happy about inability to return multiple values (Ray - it would require creating backward compatibility issues to fix that ) 22. 1447 SV-EC Contradictory statements about unsized array dimensions (5.1 versus 5.7 and 5.8) - Fixed - Approved on December 17, 2007 unanimously. 23. 0958 SV-EC dynamic array size method unclear when empty - Fixed - Approved on December 15, 2007 unanimously by Email vote. 24. 2227 SV-EC Incorrect comparison of $random and $urandom - Fixed - Approved on December 15, 2007 unanimously by Email vote. 25. 1668 SV-AC Local variable initializers. - Fixed - Was partially reviewed in Champions meeting of Nov 8th. There was a dependency on 1549 (which was sent back to the committee). 1549 has since been approved. - Approved by voice vote, 9y/0n/0a Next Meeting: ------------- Champions Feb 14 P1800 Jan 31 Feb 28 Mar 27 --Boundary_(ID_uwdDaBQtjihhNNfhKt7wZQ)-- ------- End of forwarded message ------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 23 19:23:42 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 19:23:56 PST