The updated list is attached. Neil Neil Korpusik wrote: > 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. Attendees: ---------- 1. v- Stu Sutherland --- 2. v- Surrendra Dudani --- 3. v- Brad Pierce --- 4. v- Francoise Martinolle --- 5. v- Shalom Bresticker 6. v- John Havlicek 7. -- Dave Rich 8. -* Neil Korpusik 9. -- karen Pieper Champions Feb 25 - Continuation of the February 14th meeting Monday 8-10AM PST 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. For: Brad, Francoise Abstain: Stu Brad Question -- what is the defintion 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". Stu 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. 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. For: Brad, Stu, Francoise 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. For: Brad, Stu, Francoise 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. For: Brad, Stu, Francoise 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. For: Francoise No: Brad Reason -- 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? Stu 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. 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. For: Brad No: Stu I will change my vote to Yes if the following friendly amendment is made: Near the end of the proposal, the sentence: "Variables may be declared in unnamed blocks as well as in named blocks" should be changed to: "Variables may be declared in unnamed blocks." The change is necessary because the rest of the paragraph refers to this sentence, but only applies to variables in unnamed blocks. Francoise friendly amendment: The word instantiated for a data type is not proper. We should probably replace " This can then be instantiated as follows:" "The named data type can then be used as follows" Need clarification for the following sentence: Does this imply anything on variables declared inside a fork block? "The lifetime of a fork...join, fork...join_any, or fork...join_none block shall encompass the execution of all processes spawned by the block." 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. For: Brad, Francoise Friendly amendments: Brad 1) "So for example," --> "Hence in particular," 2) "or have its elements" --> "or have their elements" (two occurrences) No: stu The bullet list in the new text to be added is preceded by "for example". This makes the entire bullet list informative, rather than normative. I do not think this is the intent, but feel the AC committee needs to clarify this, rather than my suggesting a friendly amendment. 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. For: Brad, Stu, Francoise 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. For: Brad, Stu, Francoise Friendly amendments: Stu I vote yes, but note that there is a minor typo in the instructions for the last change to be made. "Syntax 15-2" should be "Syntax 30-2". 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. For: Francoise No: Brad Reasons -- 1) This is currently in Feedback state 2) elaboration_system_task should not be added two places in the BNF, but only once in module_or_generate_item_declaration Stu I vote No for two reasons: First, I object to the entire concept of adding executable user code to elaboration time outside the context of a generate block. Second, if I understand the first example correctly, the proposal is adding the ability to define executable code outside of any context that clearly indicates when the code should be executed (i.e. no "generate, "initial", "always"", "assign", or "assert" context). 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. For: Brad, Stu, Francoise 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. For: Brad, Stu, Francoise 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. For: Brad, Francoise No: Stu I vote no because this change potentially impacts many aspects of the standard. For example, the proposal adds a large number of new operators and keywords that have not been reviewed an accepted by other committees. Other committees need several weeks to consider this mantis item. This change is much too large to be introduced this late in the standardization process for a proposed 2008 standard. Friendly amendments: Brad Friendly amendment to reconcile the new 'next' keyword with the enum method 'next' in the BNF. Add to built_in_method_call | enum_method_call Add to A.8.2 enum_method_call ::= enum_method_name . [ ( list_of_arguments ) ] enum_method_name ::= method_identifer | next And in 6.19.5.3 and 6.19.5.7, make 'next' bold. 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. For: Brad, Francoise No: Stu calls should not be allowed The comma-separated clauses "...shall not refer to an automatic variable, other than a loop control variable, declared outside of the action block" is ambiguous. Does the last clause modify the first part of the sentence, or the clause immediately before it? I do not know the author's intent, and therefore cannot suggest correct wording. 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. For: Brad, Francoise No: Stu This change is not backwards compatible, at least the way I interpret it. The new text "then the default data type is logic if it is the first argument or if the argument direction is explicitly specified" implies that even when a data type has been specified, the next time a direction is given, the previously defined data type is dropped, and the data type is changed to "logic". I don't think that is how current implementation work. Also, what if "ref" is specified instead of a direction? 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. For: Brad, Stu Abstain: Francoise 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. - Brad - 2110 depends on 1900, which is still in the Feedback state For: Abstain: Brad - depends on 1900, which is still in feedback state No: Stu Checkers is too big of a change to the standard to be added at this late date. Checkers affect, or are affected by, many different parts of the standard. All SV committees need several weeks to study the impact of checkers. Abstain: Francoise 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. For: Brad, Stu, Francoise Friendly amendments Stu I vote yes, but would like to note that since the AC committee seems hell-bent on adding checkers to the standard, the use of the word "checkers" in this mantis item will need to be changed. 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. For: Brad, Stu No: Francoise what is the VPI model for those sequence methods? Needs to be passed to VPI Brad Note to editor ? the ?ended?, ?triggered? and ?matched? in BNF should be red 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. For: Brad, Francoise No: Stu I am not clear on what is meant by "does not wait on or receive data back from any attached subroutine". It seems like "does not" should be "shall not", and what if the subroutine is a function call? The assertion would "receive data back" as part of return of the function.Received on Mon Feb 25 08:02:34 2008
This archive was generated by hypermail 2.1.8 : Mon Feb 25 2008 - 08:02:34 PST