Hi Champions, Our next conference call is scheduled for February 25th, 8-10am PST. This is a continuation of our February 14th conference call. Thursday February 25th, 2008 8-10am PST Toll Free Dial In Number: (866)839-8145 Int'l Access/Caller Paid Dial In Number: (865)524-6352 ACCESS CODE: 9301228 Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Since this is a continuation of the Feb 14th meeting I am using the same numbering for Mantis items that was used in the first portion of the meeting. Items 1. through 10. and 12. through 14. were completed in the last meeting. All of the Mantis items on this list were either on the agenda from the Feb 14th conference call or they were on the Email ballot which ends Feb 23. They are the same set of Mantis items that you have already been reviewing. I don't yet have the results compiled for the email vote. When I get the rest of the votes I will update this list and resend it. I am expecting several of the Mantis items on this list to be approved by the email vote and dropped from the agenda for the Feb 25th conference call. 11. 1995 SV-AC Allow concurrent assertions and checkers in for loops - Fixed - The latest proposal contains updates based on feedback from the Champions. I placed the Mantis item into the feedback state since this latest proposal hasn't been approved by the sv-ac. - I would like to determine how much opposition there is to this Mantis item. In the email vote which ended Feb 4th, there was one no-vote. Please review the latest proposal, even though the Mantis is in the feedback state, so that we can provide any additional feedback to the sv-ac. - The one no-vote from the Champions: Dave - This proposal is essentially creating a generate block within a procedural context. I'm fine with limiting this to assertion statements for now, but that does alleviate addressing all the issues surrounding generated code. For example each assertion statement is replicated in the loop (including nested loops) and a generate block label needs to be created for every instance of each. The loop iterator should be treated as a genvar constant within each instance of the assertion statement. - 2/9 - Neil placed into feedback state - a new proposal was posted 2/12 - new proposal was re-approved by svac Move: Brad - approve the proposal for Mantis item 1995 Second: Shalom Abstain: Dave - see his original email for his reasons Francoise - seems problematic - extra rules being added Stu - concerned that spec is not clear enough - implementations could diverge. Passed with 3 abstain (4 approved) Input from Steven Sharp (email of Feb 21, 2008) Steven is requesting that Mantis 1995 be sent to the svbc for review. -------- Original Message -------- Subject: [sv-ac] RE: [sv-ec]e-mail ballot Closes Wednesday February 20 2008, 11:59pm PST Date: Thu, 21 Feb 2008 18:02:14 -0500 (EST) From: Steven Sharp <sharp@cadence.com> Reply-To: Steven Sharp <sharp@cadence.com> To: Arturo.Salz@synopsys.com, Mehdi.Mohtashemi@synopsys.com, sv-ec@eda-stds.org, dmitry.korchemny@intel.com CC: sv-ac@eda.org, sv-bc@eda.org >From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com> >In general, checkers seems strange. They are structural constructs that >may be instantiated inside procedural code where no other structural >component may be instantiated, but they are also considerable limiting >since they may contain only a few constructs. > > > >[Korchemny, Dmitry] The checkers are similar to concurrent assertions: >if a concurrent assertion is written inside procedural code, it does not >mean that it is executed together with the procedural code, and it has >(almost) the same effect as being written outside the procedural code. >Writing concurrent assertions and checkers inside procedural code is >sort of syntactic sugaring, and it is aimed to improve assertion >usability only. Unfortunately, this claim is violated by Mantis 1995 and 2110. Mantis 1995 proposes to allow concurrent assertions in procedural code to be affected by procedural loops in a bizarre way. It is similar to pretending that the procedural loop is a generate loop for instantiating the concurrent assertions. Since procedural loops are quite different from generate loops, there are problems with trying to pretend this. Mantis 1995 should have been submitted to SV-BC for review and approval before being sent to the Champions, as procedural code falls within the SV-BC scope. I would urge the Champions to withdraw their approval of it until such a review has been done and the problems have been fixed. Failing that, I would urge the WG to reject it and send it back. Steven Sharp sharp@cadence.com 15. 1728 SV-AC Introduce "let"statement - Fixed - Was sent back to the svac by the Champions The proposal was updated and approved by the sv-ac. - Unanimously passed by voice vote 12/04/07. - The proposal failed in the Champions email vote which ended on Feb 4th, 2008. Failed with 1 no-vote - Dave - It seems very odd that the let statement is allowed on an immediate assertion, which is no more complex than a 'if' statement, but not allowed in any Boolean expression. I understand the SV-AC rush to add features to the language and limiting those features to assertions, but limited this kind of feature to assertions does not serve the end user and the language very well. If there are issues preventing wider adoption of this feature, let then be flushed out now. - John - friendly amendment: p. 3, I think that there is a parenthesis mismatch (too many ")") in the let in the package pex_gen9_common_expressions. - Dmitry has placed it into the feedback state - 2/10 It is now back in the resolved state - reapproved by svac 2/12 Brad - Dave please give us input on this one. Dave - constructs specific to assertions only thinks it is a bad thing to do. Brad - doesn't want let in the general language. - thinks of assertions as a sub-language. 16. 1447 SV-EC Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 and 5.8) - Fixed - Failed in the Champions email vote that ended Feb 4th - The proposal was updated and approved by the sv-ec - The proposal was unanimously approved by the SV-EC in the February 4, 2008 conference call. - Part of the email vote ending Feb 23. 17. 2249 SV-BC 11.4.3.1 merge issue on net and variable types - Fixed - On February 4, 2008 the SV-BC unanimously approved the attached proposal. - Part of the email vote ending Feb 23. 18. 2233 SV-EC Allowed types for randc - Fixed - Unanimously approved by the sv-ec in the conference call of February 4, 2008. - Part of the email vote ending Feb 23. 19. 2229 SV-EC Clarify summary description for "inactive" random varaibles. - Fixed - Unanimously approved by the sv-ec in the conference call of February 4, 2008. - Part of the email vote ending Feb 23. 20. 2183 SV-EC Only simple identifiers allowed in solve-before constraint - Fixed - Unanimously approved by the sv-ec in the conference call of February 4, 2008. - Part of the email vote ending Feb 23. 21. 2106 SV-BC Clarifications needed for declaration before use of objects and type - Fixed - Has been bouncing back and forth between the Champions and the sv-bc Matt has confirmed that the latest uploaded proposal is the one that the Champions should review. - On February 4, 2008 the SV-BC unanimously approved the attached proposal. - Part of the email vote ending Feb 23. 22. 2091 SV-AC Need a clarification where concurrent assertions may appear - Fixed - 2008-01-29: Voice vote approved all friendly amendments, 8y/0n/0a. - Part of the email vote ending Feb 23. 23. 2005 SV-AC Solution for glitch problem in immediate assertions - Fixed - 2008-01-30: e-mail vote passed, 8y/0n/2a <currently in the feedback state - we will not discuss> 24. 1827 SV-BC JEITA: 20.3.1 Update the OS Reference - Fixed - On February 4, 2008 the SV-BC unanimously approved the attached proposal. - Part of the email vote ending Feb 23. 25. 1772 V-1364 inconsistent timecheck/timestamp condition terminology - Fixed - On February 4, 2008 the SV-BC unanimously approved the attached proposal. - Part of the email vote ending Feb 23. 26. 1769 SV-AC Elaboration time user assertion and error reporting tasks - Fixed - 2008-01-29: Voice vote approved revised proposal that addresses all friendly amendments, 8y/0n/0a. - Part of the email vote ending Feb 23. 27. 1758 SV-AC Boolean implication -> and equivalence <-> - Fixed - Was sent to svbc for review by Champions. SV-BC requested a few changes. SV-AC made and approved the requested changes - 2008-02-05: The changes requested by SV-BC have been made and approved by voice vote, 9y/0n/0a. - Part of the email vote ending Feb 23. 28. 1648 SV-AC Default reset for assertions - Fixed - Sent back to the committee from the Champions The proposal was updated and approved by the committee. - Was sent to the sv-ec for review by the Working Group The sv-ec chose to take no action at this point in time. - Was sent back to the svac from the champions The proposal was updated and approved by the svac. - 2008-02-05: voice vote to approve the proposal dated 2008-01-31. 8y/0n/0a. 29. 1601 SV-AC new keyword for untyped formal arguments - Fixed - Feedack was provided by the svbc - Sent back to the committee by the Champions Was updated and approved by the svac. - Failed to pass in the Champions email vote Updated and approved by the committee - Was sent to the sv-ec for review by the Champions The svec chose not to take any action at this point in time. 30. 0675 SV-BC Ballot Feedback Issue 203: Packed unions shall not be restricted to equal length items. - No change required - On January 21, 2008 the SV-BC unanimously approved resolution of this issue with no further action - Part of the email vote ending Feb 23. 31. 1932 SV-AC -- requested by John - now in resolved state - Fixed - 2008-02-12: Voice vote approved minor changes, 8y/0n/0a. - Part of the email vote ending Feb 23. 32. 2150 SV-AC -- requested by John - now in resolved state - Fixed - 2008-02-05: Voice vote approved friendly amendments. - The friendly amendments were made to the proposal. - Part of the email vote ending Feb 23. 33. 1340 SV-BC -- requested by Shalom - Fixed - On August 20, 2007 the SV-BC unanimously voted to accept the attached proposal. - 1 no vote from Champions email vote of Sept 17, 2007. - Unofficial explanation: (from Shalom) At the last meeting of SV-BC, the committee decided to re-approve the proposal as is. With respect to the Champions' feedback bringing up larger issues, SV-BC decided not to address them within the scope of 1340, but rather to open a new Mantis (maybe two) that addresses them, but time does not allow them to be resolved now. I will file the new Mantis (or two) today or tomorrow. Then Matt will officially update 1340 on Mantis. New Mantis item is 2273. - On February 4, 2008, the SV-BC unanimously approved resolution of this issue per the attached proposal. - Part of the email vote ending Feb 23. 34. 2168 SV-AC Formal semantics for edge-sensitive clocks - Fixed - 2008-02-11: Passed by e-mail vote, 6y/0n/3a - Part of the email vote ending Feb 23. 35. 2110 SV-AC Allow checkers in procedural for loops - Fixed - 2008-02-11: Passed by e-mail vote, 5y/0n/4a. There were friendly amendments. - Friendly amendments approved by voice vote on 2008-02-12, 8y/0n/0a. - Part of the email vote ending Feb 23. 36. 1987 SV-AC "verification statement" should be italicized and added to the glossary - Fixed - 2007-12-24: Passed by e-mail vote, 6y/0n/4a. A friendly amendment was added and approved. - Champions sent it back to the sva for review; Jan 17, 2008 - Changes were made and approved 2008-02-11: Passed by e-mail vote, 8y/0n/1a - Part of the email vote ending Feb 23. 37. 1830 SV-AC JEITA: A.2.10 There are no Sequence methods(ended, triggered, matched) in the BNF - Fixed - 2008-02-19: The friendly amendments were approved by voice vote, 6y/0n/0a. - Part of the email vote ending Feb 23. 38. 1686 SV-AC assertion evaluation does not wait on subroutines - Fixed - 2008-02-14: Passed by e-mail ballot, 8y/0n/1a - Part of the email vote ending Feb 23.Received on Sat Feb 23 19:13:19 2008
This archive was generated by hypermail 2.1.8 : Sat Feb 23 2008 - 19:13:22 PST