-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions Feb 25, 2008 - Continuation of the February 14th meeting Monday 8-10AM PST 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 (v indicates those that voted in the Champion's email vote) (* indicates those that attended the Feb 25, 2008 conference call) 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 ended Feb 23. This writeup contains the results of the Champion's email vote which concluded on Feb 23, 2009. Six of the Champions participated in the email vote. 11. 1995 SV-AC Allow concurrent assertions and checkers in for-loops - Fixed - The one no-vote from the Champions email vote (which ended Feb 4th). 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 it into the feedback state The latest proposal was still being reviewed by the svac. 2/12 - a new proposal was re-approved by svac - now resolved again - The following vote was from the Champions meeting of Feb 14th. Move: Brad - approve the proposal for Mantis item 1995 Second: Shalom Abstain: Dave - See above for his reasons for abstaining Francoise - It seems problematic - extra rules are being added Stu - Concerned that the specification isn't clear enough - Implementations could diverge. Passed with 3 abstain (4 approved) - After holding the Champions conference call of Feb 14th, we got the following request from Steven Sharp. Steven is requesting that Mantis item 1995 be sent to the svbc for review. 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 Shalom - Steven is not raising a new point. Brad - Dmitry will be discussing this with Steven (in person) Stu - We should ask the svbc if it wants to review it or not. Brad - It was discussed at the last svbc meeting. Stu - He has reviewed it and would now vote no on it, after having had a chance to do more review. John - A number of proposals: let, checkers, loops, etc. There is a definite need for these changes. - Formal verification tools have a need for checkers. Parameterized immediate asserts need 'let'. - bc and ec have time to review these but it doesn't leave much time for the committees to converge Karen - All of the committees know that we have these issues. - Gord - restricting ac issues to ac is the best we can get. - This discussion has been going on for a long time, people had an opportunity to participate. Stu - Proposals from the ac are just now coming out in a stable form. - These aren't just assertion types of things, they do affect the rest of the language. Dave - Within Mantis 1995 - the action block is regular SystemVerilog code It isn't just assertion related. Shalom - 1995 - the title isn't quite right anymore - checkers in loops is now covered by a different Mantis item. Dave - This could come to a head in the Working Group. Brad - Doesn't expect the bc to be able to resolve it. Dave - It has been up to the ac to make sure things work for assertions. No one has been looking at the impact to the overall language. Brad - Steven and Gord discussed this a lot in the last bc meeting. Gord didn't like it but he seemed to be resigned to it. Dave - As long as it didn't affect other parts of language Gord was ok with it. - Dave doesn't think that means Gord agrees with the proposal. Karen - No one else is coming up with a proposal for user issue. So users are doing it themselves. Dave - These seem to go beyond what was expected as enhancements. - Design by committee is not a good thing. Karen - Most of these have been implemented by Intel. Dave - But only in other languages. Karen - That was also the case for the rest of SystemVerilog. - Generates were also a problem with previous versions of the LRM. The issues were worked out in subsequent versions. Brad - Steven was new to this proposal. - Brad doesn't think the bc can do anything about it. - Simulators don't do loop unrolling, only synthesis does. There might be a Synthesis bias within the svac. Shalom - Not sure that is a bad thing. Stu - It does affect the rest of the language. - We need to give the bc a chance to look at it. Dave - There are a lot of Mantis items that should have been reviewed. Move: Stu - Withdraw approval for Mantis item 1995 and send it to the svbc for approval. Second: Dave Abstain: Shalom, John, Surrendra Oppose: Brad, For: Stu, Dave Motion failed - the proposal will be sent to the Working Group. 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 Champion's 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. ------< this is where we left off in the Feb 14 conference call >---- Stu - let as a keyword - possible collisions in existing legacy code? Shalom - let is used in other languages for a similar construct Dave - assertions can creep into procedural code - expect and covergroups Shalom - covergroup and let? Dave - You can use a sequence in a covergroup. - An 'expect' can definitely be used with a sequence. - Allows a sequence to be used in procedural code. Brad - expect is part of the ac sub-language. Shalom - Is an expect the same as an immediate assert? Dave - It is slightly different. Brad - You can't ignore an expect. John - The "assertion controls" affect immediate assertions. They wouldn't affect an "if". Dave - Not that he wants 'let' in the general language, but restricting them to assertions says people are not comfortable with let. Would rather get people comfortable with let and not have the artificial restrictions. Stu - Let seems to be similar to `define as a language construct but without a macro. Could be useful elsewhere in the language. Brad - Doesn't want to allow let into the general language. - Not a fan of let. Dave - Not really limited to assertions. Could also be used in an "if". Brad - Sequences are also macro like. let is more consistent with assertions today . Dave - Can only use sequences with concurrent assertions. - let in immediate assertions - immediate used all over the place. - Doesn't think of immediate assertions as a separate language. Surrendra - How important is it to have 'let' in immediate assertions? John - It is one of Dmitry's key motivations. Shalom - concurrent - property John - It does give more flexibility - can move contents between the two. - Can compartmentalize in a let and then use in either assertion. Shalom - It is annoying today, with two forms. Dave - It is similar to the ova boolean - which was rejected from the original ova donation to Accellera. - I wanted to use parameterized functions to deal with this. Surrendra - The template idea was translated into sequences. Dave - The design side wants parameterized functions. - Assertion restrictions are for synthesis reasons, the same as designer restrictions. Move: Brad - accept the proposal for Mantis item 1995 Second: Shalom Abstain: Oppose: Dave - see previous comments Stu - too large a change to make at the end, Needs more time to review by all Technical Committees Motion passes, with 2 opposed 16. 1447 SV-EC Contradictory stmts about unsized array dimensions (5.1 vs. 5.7 and 5.8) - Fixed - Failed in the Champion's email vote that ended Feb 4th - The proposal was updated and then unanimously approved by the sv-ec in the February 4, 2008 conference call. - Part of the champion's email vote ending Feb 23. For: Brad, Francoise, John, Surrendra Abstain: Stu, Shalom <approved by email vote> Feedback from the email vote: Brad Question -- 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". 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. Shalom 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" Shalom Comment on Brad's - This issue is already there - not a new problem AI/Neil - create a new mantis item for shalom's feedback AI/Neil - create a new mantis items for Brad's question 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 19. 2229 SV-EC Clarify summary description for "inactive" random variables. - Fixed - Unanimously approved by the sv-ec in the conference call of February 4, 2008. - Part of the Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 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 Champion's email vote ending Feb 23. For: Francoise, Surrendra, Shalom, John No: Brad, Stu Brad 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. Neil - both Stu and Brad have concerns about the same sentence. Move: Brad - send Mantis item 2183 back to the svec Second: Stu Passed unanimously 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 Champion's email vote ending Feb 23. For: Brad, Surrendra, Shalom, John No: Stu, Francoise 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." Stu - For this we can make a friendly amendment. Shalom - Thinks all the comments are on existing LRM text. Dave - Agrees with that. Stu - Doesn't see them as that important. Dave - There is other text to explain the fork join question. Move: Stu - open a new Mantis item for Francoise's issue, and for Stu's change. Second: Shalom Passed unanimously AI/Neil - open a new Mantis item for these issues on the existing text. Rephrasing from Shalom on one of the issues: From: "Variables may be declared in unnamed blocks as well as in named blocks" To: "Variables may also be declared in unnamed blocks." 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 Champion's email vote ending Feb 23. For: Brad, Francoise, Surrendra, Shalom, John No: Stu 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. Friendly amendments: Brad 1) "So for example," --> "Hence in particular," 2) "or have its elements" --> "or have their elements" (two occurrences) John - Change "in an assertion" to "in a concurrent assertion" in the bullet that begins "Automatic variables and members or elements of". - Change "All variables in an assertion" to "All variables in a concurrent assertion". Rationale for both: 1987 says that "assertion" alone includes both immediate and concurrent assertions. These statements do not apply to immediate assertions. John - Agrees with Stu, the intent was for it to be normative. Brad - Was suggesting the same thing. Move: Brad - accept the proposal for Mantis item 2091 with: 1) Friendly amendment on "so for example". 2) Note to editor to fix subject verb agreement in bullets. 3) John's two changes. Second: John Passed unanimously 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Shalom, John, Surrendra <approved by email vote> 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, John, Shalom 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". Move: Shalom - approve the proposal for Mantis item 1772 with the friendly amendment. Second: Brad Passed unanimously 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 Champion's email vote ending Feb 23. For: Francoise, John, Surrendra, Shalom No: Stu, Brad Brad 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). John - Suggestions - It is counterintuitive to me that in the example with "module test #(N=12)", the default value of the parameter N is not within the required range from 1 to 8. Stu - had a question about keywords? - the 'if' (not sure when it should be executed, thought it might be an illegal example) Shalom - endgenerate - syntactically redundant, He prefers to see the endgenerate himself. John - The proposal went to the bc for review and was updated. 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 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. <we ran out of time before discussing this item> 29. 1601 SV-AC new keyword for untyped formal arguments - Fixed - Feedback 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. <we ran out of time before discussing this item> 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 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 Champion's email vote ending Feb 23. For: Brad, Francoise, Shalom, Surrendra No: Stu, John 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. John Rationale for negative vote: The semantics of "next" described in the clock rewrite rule in F.3.1.2 is not aligned with the semantics of PSL. I strongly believe that it should be aligned. I also have some concern about using the derivations of the derived operators for the definition of the "|=^{non}" relation. Since "|=^{non}" depends on syntax, it may be that the derivations do not give good results. Friendly amendments: Brad 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_identifier | next And in 6.19.5.3 and 6.19.5.7, make 'next' bold. John Friendly amendments for non-Annex F: - The paragraph at the bottom of p. 5 and continuing at the top of p. 6 is not consistent with the changes in 1648. I think that there will be no conflict as long as the editor understands that 1932 is not undoing the changes of 1648. - p. 7, change "these operators require parenthesis" to "these operators require parentheses". - p. 7, 16.12.1. In describing the semantics of sequence properties, "sequence_expr" is used in the syntax, but the matching condition is described referring to "sequence". For clarity, I recommend changing strong(sequence_expr) evaluates to true if, and only if, there is a nonempty match of the sequence. to strong(sequence_expr) evaluates to true if, and only if, there is a nonempty match of sequence_expr. and changing weak(sequence_expr) evaluates to true if, and only if, there is no finite prefix that witnesses inability to match the sequence. to finite prefix that witnesses inability to match sequence_expr. Also, there are many font inconsistencies in this subclause. Hopefully the editor can fix them. - p. 13. 1987 is eliminating "verification statement". I recommend changing "verification statement" to "concurrent assertion" in two places (adjust leading articles as appropriate). I think "concurrent assertion" is the right term because immediate assertions do not have implicit always. Also, the reference to 16.13.4 does not seem to be correct. Should this be to 16.14? Check also in 1987. - p. 15, discussion of p2 and p4. Change "there exist a current or future clock tick" to "there exists a current or future clock tick". - p. 15, discussion of p3. There are font mistakes with "a" and "b" -- they are set in roman and should be courier. - p. 15, 16.12.13. Starting the sentence "The s_eventually property_expr evaluates" is awkward. I recommend deleting "The". - p. 16. Change "there exist a current or future clock tick" to "there exists a current or future clock tick", multiple places. - p. 17, 16.12.15. There are font mistakes with commas in courier bold that should be ordinary roman. - p. 17, 16.12.15, there is a comma splice in last sentence of first paragraph. I recommend changing "are weak, they don't impose" to "are weak: they don't impose". - p. 17, 16.12.16. There are font mistakes with commas in courier bold that should be ordinary roman. - p. 21, 16.13.3. There are font mistakes with commas in courier bold that should be ordinary roman. - p. 21, 16.15.1. m should be in italic in strong(m) and weak(m). b, q, q1, q2 should be in italic in multiple places. Friendly amendments for Annex F: - F.2.3.1, F.2.3.2. The fonts are chaotic and not aligned with the current usage in Annex F. In the derived forms, terminals are set in courier. This includes "(", ")", "[", "]", "1", "+", ":", etc., etc. - F.2.3.2.1, change "when used in a cover or expect verification statement" to "when used in a cover property or expect statement". This is to align with 1987. - F.2.3.2.1, change "when used in an assert or assume verification statement" to "when used in an assert property or assume property statement". This is to align with 1987. - F.3.1.1. The parentheses that are part of the syntax should be in courier. There is a parenthesis mistake in the rule for intersect. first_match requires parentheses around its argument. I think that there are extra parentheses in the [*0] and [*1:$] rules. - F.3.1.2. I think P and Q are interchanged in "produces a property P from a property Q and a clock c". - F.3.3.3. In the rules for "disable iff" and "accept_on", the wrong symbol is used for satisfaction in a number of places. ---------< end of Friendly amendments >------------ John - ac should vote on 'next' change Stu - all committees should review it John - svac doesn't really care too much about what keywords are used. - trying to align with psl - the ltl operators require new keywords. - didn't go to the bc for review Dave - would have to use methods to get around keyword problems John - the ltl operators come in weak/strong pairs Stu - does want other committees to review - possible effects on legacy code, etc. - others may want to use new constructs as well. Dave - strong.xxx could possibly be used in place of new keywords john - psl uses a trailing ! to signal being strong - hdl logical negation in SystemVerilog Brad - use _s at the end for strong Dave - next as a keyword - clashes a lot? John - next_time is possible Stu - weak.next - is it possible? Surrendra - how should svac resolve it? Dave - find an approach that doesn't require keywords Brad - weak is not in table b. (weak0, weak1) Stu - other technical committees should review the keywords Dave - won't allow next AI/Neil - send it to the sbac with friendly amendments - still in feedback state 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 Champion's email vote ending Feb 23. For: Brad, Francoise, Shalom, John, Surrendra No: Stu Stu 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. Friendly amendments: John - "can only be of a type allowed in 16.5.1" --> "shall be of a type allowed in 16.5.1" - "as an argument to subroutine call" --> "as an argument to a subroutine call" - "associate arrays" --> "associative arrays" Stu - there are a couple of places that the wording is awkward. John - an action block can declare variables Stu - can't get that from the way it is worded. From: The action block of an assert statement shall not refer to an automatic variable, other than a loop control variable, declared outside of the action block. TO: The action block of an assert statement shall not refer to an automatic variable declared outside of the action block, other than a loop control variable. The Same change in should also be made in two other places. Move: Stu - approve mantis item 2150 with the friendly amendments. Second: John Passed unanimously <finished here - we ran out of time> 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 Champion's email vote ending Feb 23. For: Brad, Francoise, Surrendra, Shalom, John No: Stu 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 Champion's email vote ending Feb 23. For: Brad, Stu, Surrendra, Shalom, John Abstain: Francoise <approved by email vote> 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 Champion's email vote ending Feb 23. For: Surrendra Abstain: Brad - depends on 1900, which is still in feedback state Shalom - I think this should be postponed till approval of 1900. Francoise No: Stu, John 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. John Rationale for negative vote: I think that 2088 is changing in response to comments from SV-EC in a way that will not be consistent with the conditional changes on pp. 4-5. In particular, I am concerned about whether a covergroup declaration will be allowed in a checker. Friendly amendments: John - Smart quotes should not be used in the courier examples. - In the example beginning at the bottom of p. 2, the sampled value of ok is 1'b1 in the first timestep in which there is a posedge of clk due to the initialization assignment. It is true, although perhaps misleading, to say that the sampled value is always equal to (my_bits[3] == 0). This assumes, of course, that no other code updates my_bits. The declaration of control_variable_copy is not shown, and we do not know what its sampled value is in the first timestep in which there is a posedge of clk. 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 Champion's email vote ending Feb 23. For: Brad, Stu, Francoise, Surrendra, Shalom, John <approved by email vote> 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 Champion's email vote ending Feb 23. For: Brad, Stu, Surrendra, Shalom, John No: Francoise 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 Champion's email vote ending Feb 23. For: Brad, Francoise, Surrendra, Shalom, John No: Stu 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. Next meeting March 13 - Thursday 8-10am PSTReceived on Sat Mar 8 17:18:48 2008
This archive was generated by hypermail 2.1.8 : Sat Mar 08 2008 - 17:18:51 PST